李仕鵬，王志謙，李 青

(北京郵電大學a.信息光子學與光通信研究院;b.信息網絡中心，北京 100876)

當前，隨著信息技術的不斷進步和經濟的高速發(fā)展，中國的Internet用戶也在不斷增長，到2011年底，中國的網民人數已經高達5.13億[1]。在高速Internet的接入下，網絡能提供各種創(chuàng)新服務的能力也在不斷上升，特別是基于IP的實時通信業(yè)務，如VoIP、視頻會議等，迅速地擴展開來。用戶發(fā)現(xiàn)他們已經被各種各樣的客戶端和媒介類型所包圍。因此，需要一種新的技術將諸如VoIP通信和語音視頻等業(yè)務綜合于一個網絡中，這樣才能以高效的方式來提供高質的服務。

PakcketCable是由美國CableLabs及其會員企業(yè)以及主要通信供應商共同開發(fā)的一套新的技術規(guī)范，旨在通過擴展有線電視運營商現(xiàn)有的互聯(lián)網協(xié)議服務環(huán)境，構建一個全新的體系結構，加速語音、視頻、數據和移動技術的融合。PacketCable建立在成熟的DOCSIS架構上，為用戶提供高QoS的服務。

1 PacketCable 2.0整體框架概述及EUE的Provisioning框架

PacketCable 2.0的整體框架是在IMS(IP Multimedia Subsystem)框架的基礎上改動而來，主要的框架如圖1所示[2]。

圖1 PacketCable 2.0整體框架結構

PacketCable 2.0 稱用戶為UE，在PacketCable 2.0 中為SIP－based用戶增加了一系列可以使用的載體，如軟電話和硬電話、智能電話、無繩和有繩電話、即時通信UE、視頻通信終端機等。UE可通過各種本地網絡(以太網、WiFi、藍牙等)連接到接入網中。接入網可以是DOCSIS接入網，或者其他接入網(包括其他不在Cable開發(fā)者所擁有的PacketCable協(xié)議控制下的Cable接入網)。網絡邊緣層為UE和接入網提供了接入到SIP基礎設施的控制組件。核心層提供了SIP服務和協(xié)商數據的基本組件。交叉連接層提供了與其他對等網絡的交叉連接(如PSTN，peer NetWork和 PacketCable E－MTAs)。PacketCable多媒體層在DOCSIS接入網上定義了一個基于IP的平臺來傳輸加強的QoS媒體服務。應用服務層主要是為UE提供一些應用服務器來在S－CSCF上發(fā)起或者中斷請求，另外，該層還包含一些其他的功能組件(如MRF和PSF)。可操作平臺系統(tǒng)為UE提供了計費和Provisioning功能。

本文主要研究的是E－UE的Provisioning，即E－UE從開機到上線的整體流程。PacketCable 2.0是在SIP和IMS的基礎上設計的，支持多種UE。本文只考慮一種特殊的UE，即嵌入了一個DOCSIS CM的UE，定義成EUE，在這種情況下，UE不可能處于NAT和FireWall之下，并始終通過DOCSIS來接入網絡。簡而言之，E－UE是一個單獨的物理裝置，其中嵌入了一個服從eDOCSIS規(guī)范的DOCSIS CM(eCM)和一個服從 eDOCSIS，eSAFE和PacketCable規(guī)范中UE要求的eUE。

E－UE的Provisioning分為兩部分來構成，一部分為eCM的Provisioning，另一部分為eUE的Provisioning。本文主要從E－UE如何動態(tài)獲得IP等網絡配置參數著手進行研究，因此中間會省去一些與DHCP無關的配置(如CM與CMTS測距，eUE與DNS，KDC交互等)。另外，E－UE也支持eCM及eUE的IPv6配置，但本文中未對相應的DHCPv6內容進行討論，更詳細的內容請參閱相應技術規(guī)范[3]。

2 常規(guī)DHCP流程

當一個DHCP Client接入到網絡時，就會啟動DHCP進程。常規(guī)DHCP流程如下[4]:

1)DHCP Client廣播一個DHCP Discover消息。若Client已經有IP地址等網絡參數，則廣播一個DHCP Inform消息;若Client的Lease庫中有該網絡的相關信息，則廣播一個DHCP Request消息來快速請求它之前的網絡參數。

2)DHCP Server在收到客戶端傳來的DHCP Discover消息后，則會從它的數據庫中預分配一個IP地址，以及網絡的其他參數，然后廣播DHCP Offer消息。

3)DHCP Client會等待接收DHCP Offer，當收到一個或多個DHCP Offer時，一般會選擇最先到達的那個DHCP Offer，然后按該DHCP Offer消息中承諾的網絡參數，向DHCP Server廣播DHCP Request消息。

4)DHCP Server在收到DHCP Request消息后，檢查它的數據庫，若可以分配這些參數，則返回一個DHCP ACK消息，若發(fā)現(xiàn)之前承諾的網絡參數已被占用，則發(fā)送回一個DHCP NAK消息。DHCP Server應保證DHCP ACK與DHCP Offer中提供的參數一致。

5)DHCP Client在收到DHCP ACK后，會使用該IP地址進行一個ARP地址檢測，若子網中無ARP回應，就使用該IP地址及網絡參數進行網絡配置，完成DHCP流程;若ARP返回一個應答，出現(xiàn)IP地址沖突，DHCP Client應向DHCP Server廣播一個DHCP Decline，然后返回第1步。若收到DHCP NAK，則返回第1步。

3 DOCSIS CM的DHCPv4流程。

當一個CM接入到DOCSIS網絡中時，CM首先進行掃描下行、獲取上行及測距等一系列DOCSIS規(guī)范中所要求的內容后，就開始建立IP連接，此時CM會啟動DHCP進程[5]。DOCSIS會在常規(guī)的DHCP流程上進行一些改動，主要的改動如下:

1)按照RFC2131的說明，不同的系統(tǒng)應當為之選擇一個合適的重傳機制。在DOCSIS中，最好使用隨機指數倒退重傳算法，初始重傳間隔為4 s，最大為64 s，在此基礎上隨機+1/－1來去同步。CM應當限制的最大重傳次數小于或等于5次。

2)在DHCP Client的Renewing和Rebinding中，也有一些改動，當無法重綁定一個IP地址時，常規(guī)DHCP流程會退回第1步廣播DHCP Discover消息。但是由于DOCSIS網絡上有不同的頻帶，CM應當返回到重新掃描下行頻帶。

3)CM在發(fā)送的DHCP消息中，htype字段必須設置為1(以太網)，hlen字段必須設置成6，chaddr字段必須設置成CM的RF接口的48 bit MAC地址。Option code 60[6](Vendor Class Identifier)必須設置成 ASCII編碼字符串“docsisy.z:xxxxxxx”，其中，“y.z”代表 DOCSIS Version，“xxxxxxx”代表十六進制編碼的CM性能參數設置，服務器會根椐這些參數來為CM分配不同的配置文件[4]。

4)CM發(fā)送的Option code 55(參數請求列表)中必須包含Option code 1(子網掩碼)，Option code 2(時間偏移)，Option code 3(路由選項)，Option code 4(時間服務器選項)和 Option code 7(日志服務器選項)[7]。

在DHCP服務器的響應中，如下的內容是CM上線所必須的，因此必須包含在響應中:

1)DHCP服務器為CM所分配的IP地址(yiaddr)。

2)CM下一步boot所需的TFTP服務器(siaddr)。

3)CM下一步boot所需的在TFTP服務器上的配置文件(file)。

響應中的如下內容并非至關重要的，但是如果響應中給出了，CM應該使用這些參數進行配置:

1)如果CM與DHCP服務器不在同一個子網上(通過DHCP relay agent)，響應中應有relay agent的IP地址(giaddr)。

2)CM所使用的子網掩碼(Option code 1)。

3)CM與UTC的時間偏移量(Option code 2)。

4)一系列CM發(fā)送IP數據包的前向路由地址(Option code 3)。

5)一系列ToD服務器的地址(Option code 4)。

6)一系列日志服務器的IP地址(Option code 7)。

當CM成功地建立了IP連接之后，CM就繼續(xù)進行DOCSIS規(guī)范中的其他上線步驟(獲得ToD，下載配置文件以及向CMTS注冊等)。

4 PacketCable中的E－UE 的上線流程[3]

當E－UE初次接入網絡中時，首先是eCM啟動上線進程，eCM的上線大體部分與DOCSIS中的相似，只在CM建立IP連接的過程中作了如下的改動:

1)eCM在發(fā)送DHCP Discover消息時，須在Option code 55(參數請求列表)中請求Option code 122(CL_OPTION_CCC)[6]。

2)一個支持PacketCable E－UE Provisioning的DHCP服務器在收到了DHCP Discover后，會返回相應的DHCP Offer，其中包含選項122(其中必須有副選項1)。如果DHCP Server禁止eUE和eCM的Provisioning，應當在Option 122中填入地址0.0.0.0阻止 eUE 使用該 Offer。一個DHCP Server對PacketCable一無所知，也可能會回復DHCP Offer。

3)在收到一個或多個DHCP Offer時，eCM應嘗試選擇一個包含有選項122的DHCP Offer。如果沒有一個DHCP Offer符合要求，則退回到第1步，運行指數倒退重傳機制(如2，4，8等)。若重傳結束后，仍沒有符合要求的DHCP Offer，則eCM必須從所有的Offer中選擇一個。接著向選擇的那個DHCP Offer的DHCP Server發(fā)送與DHCP Discover一致的DHCP Request消息。

4)與DOCSIS中基本一樣，但是若DHCP ACK中網絡參數與DHCP Offer中不一樣時，使用DHCP ACK中的網絡參數。

eCM剩下的內容與DOCSIS規(guī)范中的內容是完全一致的。當eCM成功地完成了Provisioning后，就立即開始eUE的初始化。eUE首選會根據eCM獲得的Option來進行IP地址版本選擇(本文不涉及IPv6的討論);其次，eUE會進行DHCP服務器選擇，在eCM獲得的Option 122的副選項1和2中，包含一個或兩個DHCP Server的IP地址，eCM將它傳給eUE，eUE將會在后面的DHCP流程中，用該地址來匹配收到的DHCP Offer;最后，eCM按DOCSIS規(guī)范要求，獲得IP地址等參數后會去獲取ToD，eCM須將獲得的ToD參數傳給eUE。然后，eUE就開始啟動DHCP進程，其主要流程與eCM的DHCP類似，只在發(fā)送DHCP Discover和接收 DHCP Offer時有改動[3]:

1)eUE發(fā)送DHCP Discover消息，其中須包含Option code 60(Vendor Class Identifier)，內容為“pkt2.0:xxxxxxx”，其中“xxxxxx”是十六進制的ASCII字符串，代表了eUE的性能參數。另外還須包含Option code 43。在Option code 55 中須請求 Option code 1，3，6，7，12，15，122。

2)eUE會收到DHCP Server返回的DHCP Offer。合法的 DHCP Offer中必須包含:Option code 1，3，6，7，12，15，122，且Option code 122中必須有副選項3和6，也有可能有其他副選項。DHCP選項122的副選項6會指出Provisioning過程中是使用哪種流來進行Provisioning，包括基礎流、混合流和安全流[8]，不同的流對DHCP Offer有不同的要求[9]。eUE使用之前eCM獲得的Option 122中的一個或兩個IP地址來匹配收到的DHCP Offer的相應DHCP Server的IP地址，只有匹配成功，eUE才使用該Offer。然后eUE會從所有合法的DHCP Offer中選擇最優(yōu)的來使用。

eUE余下的DHCP流程與上述一致，完成DHCP流程后，eUE完成接下來的與DNS，KDC，TFTP等的交互后就可以正常上線了[3]。

綜上所述，在PacketCable的DHCP流程中，eCM與eUE的DHCP是基本相互獨立的，這是由于提供接入的網絡運營商(如DOCSIS運營商)和提供QoS的運營商(如TSP)有可能并不相同造成的。eCM的DHCP Option code 122中返回了eUE的DHCP服務器地址，保證eUE通過正確的DHCP服務器來獲得SIP網絡框架的參數，使eUE能夠正常上線。

5 小結

本文主要介紹了PacketCable 2.0的運營支撐系統(tǒng)。在此基礎上對PacketCable 2.0和DOCSIS網絡上部署DHCP提供了一個對比與總結，可以通過修改通用DHCP程序相應部分而獲得在不同網絡上的DHCP程序。

隨著國家對三網融合的不斷推動，廣電網絡迎來了巨大的發(fā)展契機。美國“三網融合”的發(fā)展中，Comcast和時代華納公司PacketCable 1.5的VoIP業(yè)務取得了巨大的成功[10]。而PacketCable 2.0加強了對視頻和移動技術的融合必將會對未來有線行業(yè)產生深遠的影響，為我國的三網融合產生積極的意義。

[1]第29次中國互聯(lián)網發(fā)展狀況統(tǒng)計報告[EB/OL].[2012－01－20].http://www.cnnic.net.cn/research/bgxz/tjbg/20120116_23688.html.

[2]PKT－TR－ARCH－FRM－V06－090528，Packetcable architecture framework technical report[S].2009.

[3]PKT－SP－EUE－PROV－I06－110127，PacketCable 2.0 E－UE provisioning framework specification[S].2011.

[4]IETF RFC 2131，DHCP:dynamic host configuration protocol[S].1997.

[5]CM－SP－RFIv1.1－C01－050907，DOCSIS radio frequency interface specification[S].2005.

[6]CL－SP－CANN－DHCP－Reg－102－80306，CableLabs＇DHCP options registry specification[S].2008.

[7]IETF RFC 2132，DHCP options and BOOTP vendor extensions[S].1997.

[8]PKT－SP－SEC1.5－103－090624，PacketCable 1.5 security specification[S].2009.

[9]PKT－SP－PROV1.5－I04－090624，PacketCable 1.5 specification，MTA device provisioning[S].2009.

[10]吳生高，吳錚悅，季春.美國“三網融合”的經驗對我國的啟示[J].科技與經濟，2010(4):86－89.