現階段幾種常用的認證計費技術比較
BRAS(寬頻接入伺服器)是借鑑窄帶接入的成熟運作模式,在資料網路由窄帶向寬頻演進的趨勢下,使寬頻網路可以像窄帶接入一樣運營管理。不像窄帶網路尚需要提供PSTN的接入,寬頻網路通常已具備完整的接入網路(ADSL、Ethernet、HFC),因此BRAS的主要功能是結合路由器或交換機等網路裝置,完成對寬頻使用者的3A接入控制如下:
(1)認證(Authentication):驗證使用者的身份與可使用的網路服務。
(2)授權(Authorization):依據認證結果開放網路服務給使用者
(3)計帳(Accounting):記錄使用者對各種網路服務的用量,並提供給計費系統
如果沒有實現合理的3A接入控制,寬頻網路只能提供基於埠、包月制的資費方案,如果沒有基於使用者身份的認證,也很難建立增值服務的發展空間。因此隨著業務競爭越趨激烈,3A接入控制已成為寬頻運營商的首要之務。
二、寬頻接入的實現過程
寬頻使用者3A接入控制的實現過程如下:
使用者端裝置-BRAS(AAA Client)-AAA Server(Radius)-Billing System
一般來講,從BRAS到AAA Server之間的實現方法都是大同小異,通常採用RADIUS協議,而AAA Server和Billing系統一般採用集中建制,以支援使用者漫遊和減少建制成本。而目前最困擾運營商的是如何有效實現從使用者端裝置到BRAS之間的有效連線,目前主要的實現方式有:MAC/VLAN、PPPoE、PPTP/L2TP、802.1x、WEB/VLAN、WEB/IP。
關於這幾種認證方法都有各自的特點,其優缺點在業界也是一個討論的熱點,本文將針對這些技術對它們從實現原理上進行一些探討。
三、MAC/VLAN技術評估
MAC/VLAN是通過使用者的MAC地址或VLAN ID來確認使用者身份,屬於最早期的寬頻認證技術。MAC/VLAN的認證不需要客戶端軟體,也不需要使用者輸入口令及代號,對使用者非常友好。但是由於MAC/VLAN不存在使用者登入的認證過程,因此無法計算時長,只能支援包月制的資費方案,同時在推動增值服務時也存在著很大的計費爭議,因此本文中不再討論。
四、PPPoE技術評估
PPPoE通常與ATM Router結合成為Broadband RAS,後來開始有廠家在BRAS上提供GB或FE的埠,以支援基於乙太網絡的寬頻接入。PPPoE要求在客戶端設定PPPoE客戶端軟體,從接入認證角度來看,PPPoE與大家熟悉的窄帶撥入相同,都是在客戶端起一個PPP聯機,以撥號方式撥入PPPoE伺服器。
雖然PPPoE技術普遍應用在ADSL接入認證,但是在乙太網絡上卻面臨了許多問題:
網路規劃問題
在客戶端進行撥號時,首先會發出廣播包以找尋PPPoE伺服器,待收到響應後即建立PPP連線,因此PPPoE伺服器與客戶端必須存在一個二層網路。這在ADSL不成問題,因為每個客戶端與PPPoE伺服器間都存在一個單獨的PVC電路。但是在乙太網路上,PPPoE伺服器卻需要與成千上萬名客戶端在同一個二層網路,而二層網路越大管理越困難,問題也越多。如果每個小區甚至樓宇就使用一個三層網路,卻又存在PPPoE伺服器的成本與管理問題。
封包分割問題
通常路由器或客戶端的MTU都是設定成1500Byte,由於PPPoE在將IP封包封裝在一個Ethernet Frame內,因此封包的Payload就只剩下1492Byte,碰上大小為1500Byte的封包時,就必需將封包分割。根據實際應用的資料顯示,封包分割會對路由器及客戶端的IP封包傳輸造成50%以上的額外壓力。
客戶端CPU負載問題
由於PPPoE對每一個IP封包都要封裝在Ethernet Frame內,因此網路流量越大,耗用客戶端的CPU效能就越多。因此對需要高頻寬的多媒體應用非常不利。
客戶支援問題
PPPoE技術的另一個問題是客戶端必需要有專用軟體,不論在安裝、設定及升級上都比較複雜,客服成本非常昂貴。雖然這不算一個技術上的問題,但是在實施上卻有可能造成很大的困擾。具體案例是某家擁有70萬ADSL使用者的電信運營商在客戶端使用EnterNet撥號軟體。當EnterNet升級時,該運營商在網站上提供免費下載。結果有大約5%的使用者在升級時遇到困難,該運營商的客服中心足足忙了幾個月才接完電話。
五、PPTP/L2TP技術評估
隨著VPN技術的發展,開始有運營商考慮使用PPTP/L2TP等技術提供使用者接入服務。由於PPTP/L2TP可通過三層網路提供使用者接入,因此可以有效解決PPPoE網路規劃的困難。同時由於Windows 2000已經內建VPN撥號功能,因此客服成本較低。
採用VPN來提供寬頻接入的確是一個非常有創意的方式,目前大家在觀察的是一個本來是企業級的技術方案,當應用在電信服務上是否會有一些無法預見的問題。到目前為止,已發現的問題大致跟PPPoE類似:
封包分割問題
PPTP是將IP封包封裝在GRE封包內,L2TP是將IP封包封裝在UDP封包內。跟PPPoE類似,當碰上大小為1500Byte的封包時都需要分割,對路由器及客戶端的IP封包傳輸造成50%以上的額外壓力。
客戶端CPU負載問題
PPTP與L2TP跟PPPoE類似,都要佔用客戶端的CPU以進行封裝的動作。尤其是如果進行加密傳輸(如IPSec)時,CPU壓力更大。對企業VPN來說,保密性高於效能考慮,但是對於寬頻運營商來說,是否能夠支援多媒體應用是一個很重要的考慮因素。
客戶支援問題
雖然Windows 2000已經內建PPTP/L2TP客戶端軟體,但是對VPN撥號功能的設定對沒有IT支援的普通使用者來說仍然是一個比較複雜的問題,因此對使用者的支援最終往往還是落到運營商身上,對客服來說仍然有較大的壓力。
六、802.1x技術評估
不像有線網路通過固定線路連線組建,無線網路的網路空間具有開放性和終端可移動性,因此很難通過固定線路來界定網路。而802.1x協議起源於802.11協議,後者是標準的無線區域網協議,802.1x協議的主要目的是通過認證和加密來防止非法接入企業無線網路。
類似PPTP/L2TP,目前大家在觀察的是802.1x本來是企業級的技術方案,當應用在電信服務上是否會有一些無法預見的問題。目前已發現的問題如下:
客戶端CPU負載問題
802.1x為了解決無線網路在空中傳送的安全性問題,採用了高度的加密規範,需要佔用客戶端大量的CPU效能以進行加解密。針對這個問題,目前業界的看法是未來802.1x的加解密必需在網絡卡上通過硬體實現,802.1x才能支援寬頻應用與服務。
標準規範問題
目前802.1x的規範有70%以上都尚未確認,因此目前所有宣稱支援802.1x的廠家都是基於猜測來設計產品,運營商部署802.1x的風險仍然很高。此外雖然許多交換機廠商都承諾未來可通過軟體升級來支援802.1x,但是大多數交換機的CPU 效能比客戶端的Pentium還差,因此業界的看法是未來支援802.1x的交換機必需具備硬體加解密,才具備寬頻運營的實用性。
網路規劃問題
根據目前已確認的規範,802.1x認證技術的操作粒度為埠,合法使用者接入埠之後埠處於開啟狀態,因此其它同一埠的使用者不需認證即可接入網路。因此在實施上,必需在樓宇層交換機支援802.1x協議。在實施上,這些低價、不具備硬體加解密功能的樓宇層交換機未來是否能夠升級支援802.1x,或者升級後能否提供足夠的網路效能都是個問題。
客戶支援問題
跟PPPoE、PPTP/L2TP類似,802.1x必需安裝特定的客戶端軟體或是使用Windows XP,對沒有IT支援的普通使用者來說仍然是一個比較複雜的問題,因此運營商仍然存在相當的客戶支援壓力。
七、WEB/VLAN技術評估
WEB/VLAN技術是從MAC/VLAN改良而來的接入控制技術。當用戶尚未完成認證時,使用者的VLAN只能到達交換機內建或外接的WEB認證模組。當用戶通過認證後,WEB認證模組再命令交換機將使用者的 VLAN ID開啟。WEB/VLAN技術提供了基於使用者身份的認證,在客戶端也不需要配置特別的客戶端軟體。但是WEB/VLAN仍然存在著下述的問題:
實施條件問題
WEB/VLAN的授權是通過VLAN的開關實施,因此實施的基本條件是每個使用者都必需要有一個單獨的VLAN,而且要終結在WEB/VLAN交換機上。當已部署的樓宇層交換機不支援VLAN Trunk功能時,就無法實施基於WEB/VLAN的使用者認證。
網路規劃問題
WEB/VLAN跟PPPoE類似,要求在客戶端與WEB/VLAN伺服器存在一個二層網路,二層網路越大管理越困難,問題也越多。如果每個小區甚至樓宇就使用一個WEB/VLAN交換機,卻又存在部署成本與管理問題。
開機爆量問題
這個問題出現在較早期的WEB/VLAN交換機上,主要是因為早期的WEB/VLAN交換機採用外接的WEB認證模組,當用戶完成認證後,WEB認證模組必需通過Telnet Script或SNMP Set命令將使用者的VLAN開啟。由於開機瞬間會有大量使用者同時進行認證,造成交換機無法承受大量的命令而產生宕機現象。
八、WEB/IP技術評估
WEB/IP跟WEB/VLAN技術非常類似,當用戶尚未完成認證時,使用者的IP只能到達路由器內建的WEB認證模組。當用戶通過認證後,WEB認證模組再將使用者的IP地址加入WEB/IP路由器的授權表。跟其它技術相比,WEB/IP技術具備了以下的特點:
工程實施
WEB/IP技術的授權粒度為IP,跟以太駐地網的DHCP架構可以進行無縫連線,因此實施迅速。另外由於採用三層結構,可以將WEB/IP路由器部署在POP點以匯聚多個小區的認證需求,對初期開通率低的都會網路可以有效節省建置成本。
客戶支援
WEB/IP不需要特定的客戶端軟體,客服的工作量大大減少。
網路效能
WEB/IP沒有PPPoE/PPTP/L2TP的封包封裝問題,對客戶端CPU沒有負擔,可以有效支援VOD等寬頻應用。
封包分割
WEB/IP沒有PPPoE/PPTP/L2TP的封包封裝問題,自然也沒有因為MTU改變產生的封包分割問題,不會增加路由器或客戶端的負擔。
在WEB/IP技術發展的初期,存在一些如對使用者上網時間計算不精確、對使用者私接無法控制等情況,目前這些問題在一些公司設計的接入控制器上都得到了很好的解決。