基于SDN的寬帶接入網(wǎng)用戶認(rèn)證方式研究

劉漢江+毛宇+陳文華

【摘 ? ?要】通過介紹SDN的層次結(jié)構(gòu)和OpenFlow的工作原理，分析了現(xiàn)有寬帶接入業(yè)務(wù)的2種典型認(rèn)證方式，討論了它們?cè)赟DN技術(shù)構(gòu)建的寬帶接入網(wǎng)中的實(shí)現(xiàn)方式、網(wǎng)絡(luò)結(jié)構(gòu)和優(yōu)缺點(diǎn)，證明了IPoE認(rèn)證方式更適合應(yīng)用于未來的SDN寬帶接入網(wǎng)絡(luò)。

【關(guān)鍵詞】寬帶接入網(wǎng) ? ?SDN ? ?OpenFlow ? ?認(rèn)證

中圖分類號(hào)：TN929.5 ? ?文獻(xiàn)標(biāo)識(shí)碼：A ? ?文章編號(hào)：1006-1010（2014）-22-0056-04

Research on User Authentication Methods for Broadband Access Network

Based on SDN

LIU Han-jiang， MAO Yu， CHEN Wen-hua

（Guangzhou Research Institute of China Telecom Co.， Ltd.， Guangzhou 510630， China）

[Abstract]The hierarchical structure of SDN and working principle of OpenFlow are introduced. The existing two typical authentication methods of broadband access network are analyzed， in the meantime， their implementations， network structures， advantages and disadvantages of the two authentication methods in broadband access network constructed by SDN technology are discussed. It is proved that IPoE authentication mode is more suitable for SDN broadband access network in the future.

[Key words]broadband access network ? ?Software Defined Network （SDN） ? ?OpenFlow ? ?authentication

1 ? 前言

隨著三網(wǎng)融合應(yīng)用的不斷推進(jìn)，用戶消費(fèi)行為和行業(yè)發(fā)展發(fā)生了深刻地變化，網(wǎng)絡(luò)流量正以爆發(fā)式的方式增長(zhǎng)，這就給寬帶接入網(wǎng)提出了新的需求，全業(yè)務(wù)、高帶寬、易運(yùn)行維護(hù)、安全穩(wěn)定可控成為了未來寬帶接入網(wǎng)的發(fā)展趨勢(shì)。為了實(shí)現(xiàn)用戶對(duì)于“高帶寬”的需求，電信運(yùn)營商正在不斷加大光纖接入網(wǎng)的建設(shè)力度，目前我國很多小區(qū)已經(jīng)實(shí)現(xiàn)了100M帶寬的光纖接入。以PON（Passive Optical Network，無源光網(wǎng)絡(luò)）為主的FTTB（Fiber to The Building，光纖到樓）、FTTC（Fiber to The Curb，光纖到路邊）、FTTH（Fiber to The Home，光纖到戶）技術(shù)有效地解決了網(wǎng)絡(luò)容量的問題。

為了實(shí)現(xiàn)寬帶接入業(yè)務(wù)的運(yùn)營，運(yùn)營商在網(wǎng)絡(luò)中引入了諸如認(rèn)證、鑒權(quán)、計(jì)費(fèi)、帶寬限速、用戶隔離、業(yè)務(wù)標(biāo)識(shí)、QoS（Quality of Service，服務(wù)質(zhì)量）、DPI（Deep Packet Inspection，深度報(bào)文檢測(cè)）等功能，從而使得寬帶接入業(yè)務(wù)可管可控，形成了不同帶寬產(chǎn)品之間的區(qū)隔，保證了用戶的安全[1]。但是，日益增長(zhǎng)的互聯(lián)網(wǎng)流量和復(fù)雜多樣的承載業(yè)務(wù)給寬帶接入網(wǎng)的運(yùn)維管理帶來了巨大的挑戰(zhàn)[2]。而SDN（Software Defined Network，軟件定義網(wǎng)絡(luò)）技術(shù)作為一種新興的網(wǎng)絡(luò)技術(shù)，為運(yùn)營商降低網(wǎng)絡(luò)運(yùn)維管理的復(fù)雜程度，實(shí)現(xiàn)網(wǎng)絡(luò)與業(yè)務(wù)的強(qiáng)關(guān)聯(lián)、業(yè)務(wù)的快速部署提供了技術(shù)手段。

在網(wǎng)絡(luò)的諸多功能中，用戶認(rèn)證方式作為可運(yùn)營、可管理的核心，一直受到包括運(yùn)營商、制造商的密切關(guān)注。因此，在基于SDN構(gòu)建的寬帶接入網(wǎng)絡(luò)中，用戶認(rèn)證仍然是運(yùn)營商需要關(guān)注的核心問題。

2 ? OpenFlow概述

軟件定義網(wǎng)絡(luò)（SDN）的核心理念是使網(wǎng)絡(luò)軟件化并提供靈活的開放接口，使得網(wǎng)絡(luò)能夠像軟件一樣便捷、靈活，從而提高網(wǎng)絡(luò)的創(chuàng)新能力[3]。如圖1所示，軟件定義網(wǎng)絡(luò)（SDN）的邏輯架構(gòu)由基礎(chǔ)設(shè)施層、控制層和應(yīng)用層組成。其中，基礎(chǔ)設(shè)施層主要為轉(zhuǎn)發(fā)設(shè)備，實(shí)現(xiàn)轉(zhuǎn)發(fā)功能;控制層由SDN控制軟件組成，可通過標(biāo)準(zhǔn)化協(xié)議與下層進(jìn)行通信，實(shí)現(xiàn)對(duì)基礎(chǔ)設(shè)施層的控制;應(yīng)用層不同的應(yīng)用邏輯可通過控制層開放的API管理能力控制設(shè)備的報(bào)文轉(zhuǎn)發(fā)功能[4-5]。

如圖1所示，軟件定義網(wǎng)絡(luò)（SDN）具有2種不同的網(wǎng)絡(luò)API接口：北向接口和南向接口。OpenFlow是一種業(yè)界普遍認(rèn)可的標(biāo)準(zhǔn)化南向API，該協(xié)議由負(fù)責(zé)監(jiān)管OpenFlow協(xié)議的標(biāo)準(zhǔn)組織開放式網(wǎng)絡(luò)基金會(huì)（ONF）制定發(fā)布。其中，OpenFlow交換機(jī)是整個(gè)OpenFlow網(wǎng)絡(luò)的核心部件，其轉(zhuǎn)發(fā)行為由流表進(jìn)行控制。OpenFlow交換機(jī)接收到數(shù)據(jù)包后，首先在本地的流表上查找轉(zhuǎn)發(fā)目標(biāo)端口，如果匹配則執(zhí)行流表指定的動(dòng)作，如果不匹配則將數(shù)據(jù)包轉(zhuǎn)發(fā)給控制器，由控制層決定轉(zhuǎn)發(fā)端口。控制器和交換機(jī)之間的信息交互采用OpenFlow協(xié)議，交換機(jī)的流表也由控制器通過OpenFlow協(xié)議下發(fā)。

3 ? 現(xiàn)有寬帶接入網(wǎng)的認(rèn)證方式分析

目前運(yùn)營商采用的認(rèn)證技術(shù)主要包括IPoE和PPPoE這2種方式。endprint

PPPoE認(rèn)證過程如圖2所示。PPPoE是運(yùn)營商廣泛采用的接入認(rèn)證技術(shù)，利用以太網(wǎng)發(fā)送PPP包的傳輸方法在同一以太網(wǎng)上建立多個(gè)PPP連接。其中PPP協(xié)議提供了通訊雙方身份驗(yàn)證的功能，從而實(shí)現(xiàn)用戶接入認(rèn)證和管理。但是，PPP協(xié)議是一種點(diǎn)對(duì)點(diǎn)的協(xié)議，協(xié)議中沒有提供地址信息，必須使用PPPoE再進(jìn)行一次封裝提供在以太網(wǎng)廣播鏈路上進(jìn)行點(diǎn)對(duì)點(diǎn)通信的能力。

IPoE使用DHCP（Dynamic Host Configuration Protocol，動(dòng)態(tài)主機(jī)配置協(xié)議）協(xié)議進(jìn)行動(dòng)態(tài)地址配置，DHCP協(xié)議本身并沒有用來認(rèn)證的功能，但是DHCP可以配合其他技術(shù)實(shí)現(xiàn)認(rèn)證，如DHCP+Web方式、DHCP+客戶端方式和利用DHCP+Option擴(kuò)展字段進(jìn)行認(rèn)證，所有這些方式都統(tǒng)稱為DHCP+認(rèn)證。國內(nèi)運(yùn)營商的IPTV、WLAN業(yè)務(wù)普遍采用了IPoE的認(rèn)證方式。

IPoE認(rèn)證的過程比較簡(jiǎn)單，以DHCP+Option擴(kuò)展字段認(rèn)證為例，主機(jī)和DHCP服務(wù)器之間只需通過DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK的交互即可完成認(rèn)證及地址分配（不包含DHCP與AAA之間的交互過程）。DHCP+Option擴(kuò)展字段認(rèn)證過程如圖3所示：

圖3 ? ?DHCP+Option擴(kuò)展字段認(rèn)證過程

4 ? PPPoE和IPoE認(rèn)證在SDN網(wǎng)絡(luò)中的

實(shí)現(xiàn)方案

PPPoE和IPoE這2種認(rèn)證方式在現(xiàn)網(wǎng)中均有較大規(guī)模的應(yīng)用。從幀結(jié)構(gòu)上講，由于PPPoE經(jīng)過PPP和PPPoE兩層封裝，終端和接入服務(wù)器需要更復(fù)雜的處理過程，對(duì)設(shè)備的性能要求也較高。PPPoE需要專門的接入服務(wù)器終結(jié)PPP報(bào)文，還原出IP數(shù)據(jù)包，而IPoE則省略了這一過程。PPPoE幀結(jié)構(gòu)如圖4所示：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

接入集中MAC地址（Access_Concentrator_mac_addr）

接入集中MAC地址（c） 主機(jī)MAC地址（Host_mac_addr）

主機(jī)MAC地址（cont）

以太網(wǎng)類型ETHER_TYPE=0x8864 v=1 t=1 代碼CODE=0x00

會(huì)話ID（SESSION_ID）=0x1234 長(zhǎng)度LENGTH=0x？？？？

PPP協(xié)議=0xc021 PPP凈荷

圖4 ? ?PPPoE幀結(jié)構(gòu)

在SDN技術(shù)構(gòu)建的網(wǎng)絡(luò)中，所有的轉(zhuǎn)發(fā)設(shè)備由OF交換機(jī)替代，部分業(yè)務(wù)網(wǎng)元功能也被應(yīng)用軟件虛擬化。BRAS（Broadband Remote Access Server，寬帶遠(yuǎn)程接入服務(wù)器）/SR（Service Router，全業(yè)務(wù)路由器）功能虛擬化后，仍然可以繼續(xù)采用PPPoE或IPoE來進(jìn)行認(rèn)證，這2種方式的網(wǎng)絡(luò)結(jié)構(gòu)和對(duì)設(shè)備的功能要求有較大區(qū)別。

采用PPPoE方式需要在網(wǎng)絡(luò)中選擇1個(gè)設(shè)備節(jié)點(diǎn)解析PPP報(bào)文，那么可以采用以下2種方式：

（1）在控制器上終結(jié)PPPoE?？刂破餍枰馕雒總€(gè)PPP報(bào)文，深度參與數(shù)據(jù)包的轉(zhuǎn)發(fā)，不但對(duì)控制器性能要求很高，也與SDN的控制與承載分離架構(gòu)不一致，相當(dāng)于BRAS網(wǎng)元增加了對(duì)下聯(lián)交換機(jī)的控制功能。

（2）在某臺(tái)OF交換機(jī)上終結(jié)PPPoE。控制器不參與包轉(zhuǎn)發(fā)過程，但是目前OpenFlow協(xié)議中規(guī)定的OF交換機(jī)匹配域和行動(dòng)并不支持對(duì)PPPoE幀的匹配及剝離報(bào)文頭，因此需要對(duì)OpenFlow協(xié)議進(jìn)行擴(kuò)展，匹配域需要增加PPPoE的代碼（code）、會(huì)話（session）、PPP協(xié)議等字段的匹配，并將凈負(fù)荷還原出來。

2種終結(jié)PPPoE方式的網(wǎng)絡(luò)結(jié)構(gòu)如圖5所示。采用IPoE方式的網(wǎng)絡(luò)結(jié)構(gòu)如圖6所示。

控制器通過packet out消息獲取用戶的DHCP報(bào)文，與DHCP服務(wù)器和AAA服務(wù)器等配合完成用戶的認(rèn)證、地址分配過程，再通過packet in消息將DHCP Offer和ACK報(bào)文發(fā)給用戶主機(jī)?？刂破鞲鶕?jù)用戶申請(qǐng)的業(yè)務(wù)和產(chǎn)品對(duì)交換機(jī)下發(fā)流表，控制轉(zhuǎn)發(fā)行為，此后控制器不再參與包轉(zhuǎn)發(fā)過程，直至用戶下線。用戶下線后，控制器拆除對(duì)應(yīng)的流表，并將時(shí)長(zhǎng)、流量等計(jì)費(fèi)信息發(fā)送給控制器。

5 ? 總結(jié)

根據(jù)上述分析，在SDN技術(shù)構(gòu)建的寬帶接入網(wǎng)絡(luò)中，采用PPPoE認(rèn)證方式需要在某臺(tái)OF交換機(jī)上終結(jié)PPPoE，需要對(duì)OpenFlow協(xié)議進(jìn)行擴(kuò)展;或者在控制器上終結(jié)PPPoE，需要控制器深度參與數(shù)據(jù)包的轉(zhuǎn)發(fā)過程，對(duì)控制器的性能要求高，也不符合控制與承載分離的架構(gòu)，實(shí)現(xiàn)較為困難。而采用IPoE方式，控制器僅參與用戶認(rèn)證階段的DHCP報(bào)文轉(zhuǎn)發(fā)，而后根據(jù)用戶業(yè)務(wù)屬性向交換機(jī)下發(fā)相應(yīng)的流表，實(shí)現(xiàn)起來較為簡(jiǎn)單。當(dāng)然，采用IPoE認(rèn)證方式還需要采取相應(yīng)的機(jī)制或策略來解決安全性、反地址欺騙、防DoS攻擊等問題。

參考文獻(xiàn)：

[1] 吳家林，趙永利，張杰，等. 網(wǎng)絡(luò)革命拂曉：SDN進(jìn)入智能寬帶接入網(wǎng)[J]. 通信世界， 2013（7）： 49-50.

[2] 王茜，趙慧玲，解云鵬. SDN標(biāo)準(zhǔn)化和應(yīng)用場(chǎng)景探討[J]. 中興通訊技術(shù)， 2013，19（5）： 2-6.

[3] 左青云，陳鳴，趙廣松，等. 基于OpenFlow的SDN技術(shù)研究[J]. 軟件學(xué)報(bào)， 2013，24（5）： 1078-1097.

[4] ONF White Paper. Software-Defined Networking： The New Norm for Networks[S]. 2012.

[5] ONF. OpenFlow Switch Specification Version 1.3.1[S]. 2012.endprint

PPPoE認(rèn)證過程如圖2所示。PPPoE是運(yùn)營商廣泛采用的接入認(rèn)證技術(shù)，利用以太網(wǎng)發(fā)送PPP包的傳輸方法在同一以太網(wǎng)上建立多個(gè)PPP連接。其中PPP協(xié)議提供了通訊雙方身份驗(yàn)證的功能，從而實(shí)現(xiàn)用戶接入認(rèn)證和管理。但是，PPP協(xié)議是一種點(diǎn)對(duì)點(diǎn)的協(xié)議，協(xié)議中沒有提供地址信息，必須使用PPPoE再進(jìn)行一次封裝提供在以太網(wǎng)廣播鏈路上進(jìn)行點(diǎn)對(duì)點(diǎn)通信的能力。

IPoE使用DHCP（Dynamic Host Configuration Protocol，動(dòng)態(tài)主機(jī)配置協(xié)議）協(xié)議進(jìn)行動(dòng)態(tài)地址配置，DHCP協(xié)議本身并沒有用來認(rèn)證的功能，但是DHCP可以配合其他技術(shù)實(shí)現(xiàn)認(rèn)證，如DHCP+Web方式、DHCP+客戶端方式和利用DHCP+Option擴(kuò)展字段進(jìn)行認(rèn)證，所有這些方式都統(tǒng)稱為DHCP+認(rèn)證。國內(nèi)運(yùn)營商的IPTV、WLAN業(yè)務(wù)普遍采用了IPoE的認(rèn)證方式。

IPoE認(rèn)證的過程比較簡(jiǎn)單，以DHCP+Option擴(kuò)展字段認(rèn)證為例，主機(jī)和DHCP服務(wù)器之間只需通過DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK的交互即可完成認(rèn)證及地址分配（不包含DHCP與AAA之間的交互過程）。DHCP+Option擴(kuò)展字段認(rèn)證過程如圖3所示：

圖3 ? ?DHCP+Option擴(kuò)展字段認(rèn)證過程

4 ? PPPoE和IPoE認(rèn)證在SDN網(wǎng)絡(luò)中的

實(shí)現(xiàn)方案

PPPoE和IPoE這2種認(rèn)證方式在現(xiàn)網(wǎng)中均有較大規(guī)模的應(yīng)用。從幀結(jié)構(gòu)上講，由于PPPoE經(jīng)過PPP和PPPoE兩層封裝，終端和接入服務(wù)器需要更復(fù)雜的處理過程，對(duì)設(shè)備的性能要求也較高。PPPoE需要專門的接入服務(wù)器終結(jié)PPP報(bào)文，還原出IP數(shù)據(jù)包，而IPoE則省略了這一過程。PPPoE幀結(jié)構(gòu)如圖4所示：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

接入集中MAC地址（Access_Concentrator_mac_addr）

接入集中MAC地址（c） 主機(jī)MAC地址（Host_mac_addr）

主機(jī)MAC地址（cont）

以太網(wǎng)類型ETHER_TYPE=0x8864 v=1 t=1 代碼CODE=0x00

會(huì)話ID（SESSION_ID）=0x1234 長(zhǎng)度LENGTH=0x？？？？

PPP協(xié)議=0xc021 PPP凈荷

圖4 ? ?PPPoE幀結(jié)構(gòu)

在SDN技術(shù)構(gòu)建的網(wǎng)絡(luò)中，所有的轉(zhuǎn)發(fā)設(shè)備由OF交換機(jī)替代，部分業(yè)務(wù)網(wǎng)元功能也被應(yīng)用軟件虛擬化。BRAS（Broadband Remote Access Server，寬帶遠(yuǎn)程接入服務(wù)器）/SR（Service Router，全業(yè)務(wù)路由器）功能虛擬化后，仍然可以繼續(xù)采用PPPoE或IPoE來進(jìn)行認(rèn)證，這2種方式的網(wǎng)絡(luò)結(jié)構(gòu)和對(duì)設(shè)備的功能要求有較大區(qū)別。

采用PPPoE方式需要在網(wǎng)絡(luò)中選擇1個(gè)設(shè)備節(jié)點(diǎn)解析PPP報(bào)文，那么可以采用以下2種方式：

（1）在控制器上終結(jié)PPPoE。控制器需要解析每個(gè)PPP報(bào)文，深度參與數(shù)據(jù)包的轉(zhuǎn)發(fā)，不但對(duì)控制器性能要求很高，也與SDN的控制與承載分離架構(gòu)不一致，相當(dāng)于BRAS網(wǎng)元增加了對(duì)下聯(lián)交換機(jī)的控制功能。

（2）在某臺(tái)OF交換機(jī)上終結(jié)PPPoE。控制器不參與包轉(zhuǎn)發(fā)過程，但是目前OpenFlow協(xié)議中規(guī)定的OF交換機(jī)匹配域和行動(dòng)并不支持對(duì)PPPoE幀的匹配及剝離報(bào)文頭，因此需要對(duì)OpenFlow協(xié)議進(jìn)行擴(kuò)展，匹配域需要增加PPPoE的代碼（code）、會(huì)話（session）、PPP協(xié)議等字段的匹配，并將凈負(fù)荷還原出來。

2種終結(jié)PPPoE方式的網(wǎng)絡(luò)結(jié)構(gòu)如圖5所示。采用IPoE方式的網(wǎng)絡(luò)結(jié)構(gòu)如圖6所示。

控制器通過packet out消息獲取用戶的DHCP報(bào)文，與DHCP服務(wù)器和AAA服務(wù)器等配合完成用戶的認(rèn)證、地址分配過程，再通過packet in消息將DHCP Offer和ACK報(bào)文發(fā)給用戶主機(jī)?？刂破鞲鶕?jù)用戶申請(qǐng)的業(yè)務(wù)和產(chǎn)品對(duì)交換機(jī)下發(fā)流表，控制轉(zhuǎn)發(fā)行為，此后控制器不再參與包轉(zhuǎn)發(fā)過程，直至用戶下線。用戶下線后，控制器拆除對(duì)應(yīng)的流表，并將時(shí)長(zhǎng)、流量等計(jì)費(fèi)信息發(fā)送給控制器。

5 ? 總結(jié)

根據(jù)上述分析，在SDN技術(shù)構(gòu)建的寬帶接入網(wǎng)絡(luò)中，采用PPPoE認(rèn)證方式需要在某臺(tái)OF交換機(jī)上終結(jié)PPPoE，需要對(duì)OpenFlow協(xié)議進(jìn)行擴(kuò)展;或者在控制器上終結(jié)PPPoE，需要控制器深度參與數(shù)據(jù)包的轉(zhuǎn)發(fā)過程，對(duì)控制器的性能要求高，也不符合控制與承載分離的架構(gòu)，實(shí)現(xiàn)較為困難。而采用IPoE方式，控制器僅參與用戶認(rèn)證階段的DHCP報(bào)文轉(zhuǎn)發(fā)，而后根據(jù)用戶業(yè)務(wù)屬性向交換機(jī)下發(fā)相應(yīng)的流表，實(shí)現(xiàn)起來較為簡(jiǎn)單。當(dāng)然，采用IPoE認(rèn)證方式還需要采取相應(yīng)的機(jī)制或策略來解決安全性、反地址欺騙、防DoS攻擊等問題。

參考文獻(xiàn)：

[1] 吳家林，趙永利，張杰，等. 網(wǎng)絡(luò)革命拂曉：SDN進(jìn)入智能寬帶接入網(wǎng)[J]. 通信世界， 2013（7）： 49-50.

[2] 王茜，趙慧玲，解云鵬. SDN標(biāo)準(zhǔn)化和應(yīng)用場(chǎng)景探討[J]. 中興通訊技術(shù)， 2013，19（5）： 2-6.

[3] 左青云，陳鳴，趙廣松，等. 基于OpenFlow的SDN技術(shù)研究[J]. 軟件學(xué)報(bào)， 2013，24（5）： 1078-1097.

[4] ONF White Paper. Software-Defined Networking： The New Norm for Networks[S]. 2012.

[5] ONF. OpenFlow Switch Specification Version 1.3.1[S]. 2012.endprint

PPPoE認(rèn)證過程如圖2所示。PPPoE是運(yùn)營商廣泛采用的接入認(rèn)證技術(shù)，利用以太網(wǎng)發(fā)送PPP包的傳輸方法在同一以太網(wǎng)上建立多個(gè)PPP連接。其中PPP協(xié)議提供了通訊雙方身份驗(yàn)證的功能，從而實(shí)現(xiàn)用戶接入認(rèn)證和管理。但是，PPP協(xié)議是一種點(diǎn)對(duì)點(diǎn)的協(xié)議，協(xié)議中沒有提供地址信息，必須使用PPPoE再進(jìn)行一次封裝提供在以太網(wǎng)廣播鏈路上進(jìn)行點(diǎn)對(duì)點(diǎn)通信的能力。

IPoE使用DHCP（Dynamic Host Configuration Protocol，動(dòng)態(tài)主機(jī)配置協(xié)議）協(xié)議進(jìn)行動(dòng)態(tài)地址配置，DHCP協(xié)議本身并沒有用來認(rèn)證的功能，但是DHCP可以配合其他技術(shù)實(shí)現(xiàn)認(rèn)證，如DHCP+Web方式、DHCP+客戶端方式和利用DHCP+Option擴(kuò)展字段進(jìn)行認(rèn)證，所有這些方式都統(tǒng)稱為DHCP+認(rèn)證。國內(nèi)運(yùn)營商的IPTV、WLAN業(yè)務(wù)普遍采用了IPoE的認(rèn)證方式。

IPoE認(rèn)證的過程比較簡(jiǎn)單，以DHCP+Option擴(kuò)展字段認(rèn)證為例，主機(jī)和DHCP服務(wù)器之間只需通過DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK的交互即可完成認(rèn)證及地址分配（不包含DHCP與AAA之間的交互過程）。DHCP+Option擴(kuò)展字段認(rèn)證過程如圖3所示：

圖3 ? ?DHCP+Option擴(kuò)展字段認(rèn)證過程

4 ? PPPoE和IPoE認(rèn)證在SDN網(wǎng)絡(luò)中的

實(shí)現(xiàn)方案

PPPoE和IPoE這2種認(rèn)證方式在現(xiàn)網(wǎng)中均有較大規(guī)模的應(yīng)用。從幀結(jié)構(gòu)上講，由于PPPoE經(jīng)過PPP和PPPoE兩層封裝，終端和接入服務(wù)器需要更復(fù)雜的處理過程，對(duì)設(shè)備的性能要求也較高。PPPoE需要專門的接入服務(wù)器終結(jié)PPP報(bào)文，還原出IP數(shù)據(jù)包，而IPoE則省略了這一過程。PPPoE幀結(jié)構(gòu)如圖4所示：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

接入集中MAC地址（Access_Concentrator_mac_addr）

接入集中MAC地址（c） 主機(jī)MAC地址（Host_mac_addr）

主機(jī)MAC地址（cont）

以太網(wǎng)類型ETHER_TYPE=0x8864 v=1 t=1 代碼CODE=0x00

會(huì)話ID（SESSION_ID）=0x1234 長(zhǎng)度LENGTH=0x？？？？

PPP協(xié)議=0xc021 PPP凈荷

圖4 ? ?PPPoE幀結(jié)構(gòu)

在SDN技術(shù)構(gòu)建的網(wǎng)絡(luò)中，所有的轉(zhuǎn)發(fā)設(shè)備由OF交換機(jī)替代，部分業(yè)務(wù)網(wǎng)元功能也被應(yīng)用軟件虛擬化。BRAS（Broadband Remote Access Server，寬帶遠(yuǎn)程接入服務(wù)器）/SR（Service Router，全業(yè)務(wù)路由器）功能虛擬化后，仍然可以繼續(xù)采用PPPoE或IPoE來進(jìn)行認(rèn)證，這2種方式的網(wǎng)絡(luò)結(jié)構(gòu)和對(duì)設(shè)備的功能要求有較大區(qū)別。

采用PPPoE方式需要在網(wǎng)絡(luò)中選擇1個(gè)設(shè)備節(jié)點(diǎn)解析PPP報(bào)文，那么可以采用以下2種方式：

（1）在控制器上終結(jié)PPPoE?？刂破餍枰馕雒總€(gè)PPP報(bào)文，深度參與數(shù)據(jù)包的轉(zhuǎn)發(fā)，不但對(duì)控制器性能要求很高，也與SDN的控制與承載分離架構(gòu)不一致，相當(dāng)于BRAS網(wǎng)元增加了對(duì)下聯(lián)交換機(jī)的控制功能。

（2）在某臺(tái)OF交換機(jī)上終結(jié)PPPoE?？刂破鞑粎⑴c包轉(zhuǎn)發(fā)過程，但是目前OpenFlow協(xié)議中規(guī)定的OF交換機(jī)匹配域和行動(dòng)并不支持對(duì)PPPoE幀的匹配及剝離報(bào)文頭，因此需要對(duì)OpenFlow協(xié)議進(jìn)行擴(kuò)展，匹配域需要增加PPPoE的代碼（code）、會(huì)話（session）、PPP協(xié)議等字段的匹配，并將凈負(fù)荷還原出來。

2種終結(jié)PPPoE方式的網(wǎng)絡(luò)結(jié)構(gòu)如圖5所示。采用IPoE方式的網(wǎng)絡(luò)結(jié)構(gòu)如圖6所示。

控制器通過packet out消息獲取用戶的DHCP報(bào)文，與DHCP服務(wù)器和AAA服務(wù)器等配合完成用戶的認(rèn)證、地址分配過程，再通過packet in消息將DHCP Offer和ACK報(bào)文發(fā)給用戶主機(jī)?？刂破鞲鶕?jù)用戶申請(qǐng)的業(yè)務(wù)和產(chǎn)品對(duì)交換機(jī)下發(fā)流表，控制轉(zhuǎn)發(fā)行為，此后控制器不再參與包轉(zhuǎn)發(fā)過程，直至用戶下線。用戶下線后，控制器拆除對(duì)應(yīng)的流表，并將時(shí)長(zhǎng)、流量等計(jì)費(fèi)信息發(fā)送給控制器。

5 ? 總結(jié)

根據(jù)上述分析，在SDN技術(shù)構(gòu)建的寬帶接入網(wǎng)絡(luò)中，采用PPPoE認(rèn)證方式需要在某臺(tái)OF交換機(jī)上終結(jié)PPPoE，需要對(duì)OpenFlow協(xié)議進(jìn)行擴(kuò)展;或者在控制器上終結(jié)PPPoE，需要控制器深度參與數(shù)據(jù)包的轉(zhuǎn)發(fā)過程，對(duì)控制器的性能要求高，也不符合控制與承載分離的架構(gòu)，實(shí)現(xiàn)較為困難。而采用IPoE方式，控制器僅參與用戶認(rèn)證階段的DHCP報(bào)文轉(zhuǎn)發(fā)，而后根據(jù)用戶業(yè)務(wù)屬性向交換機(jī)下發(fā)相應(yīng)的流表，實(shí)現(xiàn)起來較為簡(jiǎn)單。當(dāng)然，采用IPoE認(rèn)證方式還需要采取相應(yīng)的機(jī)制或策略來解決安全性、反地址欺騙、防DoS攻擊等問題。

參考文獻(xiàn)：

[1] 吳家林，趙永利，張杰，等. 網(wǎng)絡(luò)革命拂曉：SDN進(jìn)入智能寬帶接入網(wǎng)[J]. 通信世界， 2013（7）： 49-50.

[2] 王茜，趙慧玲，解云鵬. SDN標(biāo)準(zhǔn)化和應(yīng)用場(chǎng)景探討[J]. 中興通訊技術(shù)， 2013，19（5）： 2-6.

[3] 左青云，陳鳴，趙廣松，等. 基于OpenFlow的SDN技術(shù)研究[J]. 軟件學(xué)報(bào)， 2013，24（5）： 1078-1097.

[4] ONF White Paper. Software-Defined Networking： The New Norm for Networks[S]. 2012.

[5] ONF. OpenFlow Switch Specification Version 1.3.1[S]. 2012.endprint