論 PacketCable 2.0中 E－UE的DHCP流程

李仕鵬，王志謙，李 青

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

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

PakcketCable是由美國CableLabs及其會員企業以及主要通信供應商共同開發的一套新的技術規范，旨在通過擴展有線電視運營商現有的互聯網協議服務環境，構建一個全新的體系結構，加速語音、視頻、數據和移動技術的融合。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開發者所擁有的PacketCable協議控制下的Cable接入網)。網絡邊緣層為UE和接入網提供了接入到SIP基礎設施的控制組件。核心層提供了SIP服務和協商數據的基本組件。交叉連接層提供了與其他對等網絡的交叉連接(如PSTN，peer NetWork和 PacketCable E－MTAs)。PacketCable多媒體層在DOCSIS接入網上定義了一個基于IP的平臺來傳輸加強的QoS媒體服務。應用服務層主要是為UE提供一些應用服務器來在S－CSCF上發起或者中斷請求，另外，該層還包含一些其他的功能組件(如MRF和PSF)。可操作平臺系統為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規范的DOCSIS CM(eCM)和一個服從 eDOCSIS，eSAFE和PacketCable規范中UE要求的eUE。

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

2 常規DHCP流程

當一個DHCP Client接入到網絡時，就會啟動DHCP進程。常規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消息，若發現之前承諾的網絡參數已被占用，則發送回一個DHCP NAK消息。DHCP Server應保證DHCP ACK與DHCP Offer中提供的參數一致。

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

3 DOCSIS CM的DHCPv4流程。

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

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

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

3)CM在發送的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發送的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發送IP數據包的前向路由地址(Option code 3)。

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

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

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

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

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

1)eCM在發送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發送與DHCP Discover一致的DHCP Request消息。

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

eCM剩下的內容與DOCSIS規范中的內容是完全一致的。當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規范要求，獲得IP地址等參數后會去獲取ToD，eCM須將獲得的ToD參數傳給eUE。然后，eUE就開始啟動DHCP進程，其主要流程與eCM的DHCP類似，只在發送DHCP Discover和接收 DHCP Offer時有改動[3]:

1)eUE發送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中選擇最優的來使用。

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的運營支撐系統。在此基礎上對PacketCable 2.0和DOCSIS網絡上部署DHCP提供了一個對比與總結，可以通過修改通用DHCP程序相應部分而獲得在不同網絡上的DHCP程序。

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

[1]第29次中國互聯網發展狀況統計報告[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.