LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)中DHCP協(xié)議的解碼方案研究

李丹鳳，張治中

(重慶郵電大學(xué) 通信網(wǎng)與測(cè)試技術(shù)重點(diǎn)實(shí)驗(yàn)室，重慶400065)

LTE是3G的長(zhǎng)期演進(jìn)，改進(jìn)并增強(qiáng)了3G的技術(shù)，在20 MHz頻譜帶寬下能夠提供下行100 Mbit/s與上行50 Mbit/s的峰值速率［1］。隨著中國(guó)移動(dòng)建設(shè)的TD-LTE演示網(wǎng)相繼在2010年的上海世博會(huì)、廣州亞運(yùn)會(huì)上登臺(tái)亮相，基于TD-LTE網(wǎng)絡(luò)的即攝即傳系統(tǒng)、移動(dòng)媒體采訪車(chē)運(yùn)用在2011年8月的深圳大運(yùn)會(huì)電視直播中，全球LTE商用網(wǎng)絡(luò)正在加速推進(jìn)，整個(gè)產(chǎn)業(yè)鏈也在逐步走向成熟［2］。基于這樣的現(xiàn)狀，為確保LTE網(wǎng)絡(luò)達(dá)到最佳運(yùn)行狀態(tài)，研發(fā)LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)具有重大意義。

LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)采用分布式、分層模塊化、可伸縮、可組合的架構(gòu)體系，針對(duì)不同用戶進(jìn)行個(gè)性化設(shè)計(jì)，保證監(jiān)測(cè)系統(tǒng)高效、可靠、穩(wěn)定運(yùn)行［3］。由于LTE是基于全I(xiàn)P的新一代通信網(wǎng)絡(luò)，作為能動(dòng)態(tài)獲取IP地址，租期內(nèi)使用IP的動(dòng)態(tài)主機(jī)配置協(xié)議(Dynamic Host Configuration Protocol，DHCP)在LTE網(wǎng)絡(luò)中其優(yōu)勢(shì)顯得尤為突出。在LTE網(wǎng)絡(luò)中通過(guò)PGW(Packet Data Network)來(lái)管理DHCP協(xié)議，DHCP協(xié)議的前身是Bootstrap引導(dǎo)程序協(xié)議(BOOTP)，DHCP不僅具有BOOTP的特性還對(duì)其進(jìn)行了擴(kuò)充。DHCP為改善IP地址短缺、充分利用網(wǎng)絡(luò)資源，新增動(dòng)態(tài)分配IP、租期內(nèi)使用IP地址的機(jī)制。DHCP工作在OSI的應(yīng)用層，基于UDP應(yīng)用，DHCP CLIENT(DHCP客戶機(jī))和DHCP SERVER(DHCP服務(wù)器)分別采用UDP端口號(hào)68和67來(lái)交接。該協(xié)議在協(xié)議棧中的位置如圖1所示。

圖1 DHCP協(xié)議棧結(jié)構(gòu)

由于不同的協(xié)議有不同的消息格式，所以在本監(jiān)測(cè)系統(tǒng)中采取以模塊化各個(gè)協(xié)議的處理辦法來(lái)應(yīng)對(duì)協(xié)議間功能和格式的差別，此方法可以推廣到LTE網(wǎng)絡(luò)中的其他協(xié)議［4］。本文研究的主要內(nèi)容就是如何利用模塊化思想，根據(jù)協(xié)議標(biāo)準(zhǔn)中規(guī)定的協(xié)議消息結(jié)構(gòu)進(jìn)行DHCP協(xié)議的解碼并能在LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)中形象直觀地正確顯示解碼結(jié)果。

1 DHCP協(xié)議的工作流程

一次成功的DHCPv4流程包含DHCP Discover，DHCP Offer，DHCP Request，DHCP Ack和DHCP Release這5個(gè)階段，其流程如圖2所示。

圖2 一次成功DHCP的流程圖

DHCP Discover(發(fā)現(xiàn)階段):DHCP Client(DHCP客戶機(jī))以廣播方式尋找DHCP Server(DHCP服務(wù)器)。

DHCP Offer(提供階段):DHCP Server響應(yīng)廣播信息，提供IP地址。

DHCP Request(選擇階段):DHCP Client確定選擇哪臺(tái)DHCP Server提供的IP地址及相關(guān)內(nèi)容。

DHCP Ack(確認(rèn)階段):DHCP Server授權(quán)DHCP Client提供IP地址，并給出租借期限。

DHCP Release(釋放階段):DHCP Client釋放IP地址，告知DHCP Server回收IP地址。

DHCP保留登錄信息:對(duì)登錄過(guò)網(wǎng)絡(luò)的DHCP客戶機(jī)保留信息，以后再登錄無(wú)須再發(fā)送DHCP Discover發(fā)現(xiàn)信息，只需發(fā)送DHCP Request請(qǐng)求信息。不過(guò)當(dāng)前次使用的IP地址無(wú)法再分配時(shí)(比如此IP地址已分配給其他DHCP客戶機(jī)使用)，那就必須重新發(fā)送DHCP Discover發(fā)現(xiàn)信息來(lái)請(qǐng)求新的IP地址。

DHCP動(dòng)態(tài)獲得的IP地址、租期內(nèi)使用IP地址:DHCP Client動(dòng)態(tài)獲得IP地址的同時(shí)還會(huì)收到IP租借期限。當(dāng)租期過(guò)50%時(shí)，DHCP Client就自動(dòng)向DHCP Server發(fā)送更新其IP租約的請(qǐng)求，以延長(zhǎng)租期。當(dāng)租期滿后，DHCP Server便會(huì)收回出租的IP地址。

2 DHCP的報(bào)文格式

DHCP的報(bào)文格式，如圖3所示。

圖3 DHCP報(bào)文格式

圖3 中，各參數(shù)設(shè)置如下:若是Client送給Server的封包，OP設(shè)為1，反向?yàn)?;Htype為硬件類(lèi)別，若為Ethernet，則設(shè)為1;Hlen為硬件長(zhǎng)度，若為Ethernet，則設(shè)為6;若數(shù)據(jù)包需經(jīng)過(guò)Router傳送，Hops每站加1，若在同一網(wǎng)內(nèi)，則設(shè)為0;Transaction ID為事務(wù)ID，是個(gè)隨機(jī)數(shù)，用于客戶和服務(wù)器之間匹配請(qǐng)求和相應(yīng)消息;Seconds為由用戶指定的時(shí)間，指開(kāi)始地址獲取和更新進(jìn)行后的時(shí)間;Flags取0～15 bit，最左位為1時(shí)，表示Server將以廣播方式傳送封包給Client，其余尚未使用;Ciaddr為用戶IP地址;Yiaddr為客戶IP地址;Siaddr為用于bootstrap過(guò)程中的IP地址;Giaddr為轉(zhuǎn)發(fā)代理(網(wǎng)關(guān))IP地址;Chaddr為Client的硬件地址;ChCiHaddrPadd為用戶地址冗余位;Sname為可選Server的名稱(chēng)，以0x00結(jié)尾;File為啟動(dòng)文件名;MagicCookie為魔塊;Options為廠商標(biāo)識(shí)，可選的參數(shù)字段(針對(duì)不同DHCP消息，Option有不同的參數(shù)字段)。

3 DHCP的解碼實(shí)現(xiàn)

解碼設(shè)計(jì)框架如圖4所示。

圖4 DHCP的解碼設(shè)計(jì)框架圖

在LTE監(jiān)測(cè)系統(tǒng)中，保證網(wǎng)絡(luò)數(shù)據(jù)準(zhǔn)確無(wú)誤的解碼是監(jiān)測(cè)系統(tǒng)進(jìn)行后續(xù)的呼叫詳細(xì)記錄(CDR)合成、消息過(guò)濾、統(tǒng)計(jì)分析等功能的必備前提和基礎(chǔ)保證［5］。消息解碼由詳細(xì)解碼和簡(jiǎn)單解碼2個(gè)部分組成。詳細(xì)解碼和簡(jiǎn)單解碼都是對(duì)原始數(shù)據(jù)進(jìn)行解析，不同之處在于詳細(xì)解碼是對(duì)數(shù)據(jù)中的每個(gè)字節(jié)、每個(gè)比特位解析，而簡(jiǎn)單解碼只提取消息數(shù)據(jù)中的關(guān)鍵信息。詳細(xì)解碼結(jié)果經(jīng)封裝后在LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)界面上以樹(shù)形圖展現(xiàn)，方便用戶快速理解消息數(shù)據(jù)代表的信息，而且本監(jiān)測(cè)系統(tǒng)的詳細(xì)解碼采用中英文雙語(yǔ)形式，適用于更多的用戶。簡(jiǎn)單解碼結(jié)果經(jīng)封裝后用于在監(jiān)測(cè)系統(tǒng)界面上進(jìn)行過(guò)濾消息和列表顯示消息，而經(jīng)合成解碼封裝后則是用于消息的呼叫詳細(xì)記錄(CDR)合成。協(xié)議解碼由低到高依次每層進(jìn)行，只有在對(duì)下層協(xié)議進(jìn)行準(zhǔn)確無(wú)誤解析的同時(shí)成功提取上層協(xié)議PDU信息后才能對(duì)上層協(xié)議進(jìn)行解析。由于DHCP協(xié)議基于UDP層，那么就需要依次進(jìn)行Ethernet層、IP層、UDP層各層協(xié)議的解碼及獲取上層PDU才能最終成功解析DHCP。

3.1 DHCP協(xié)議簡(jiǎn)單解碼界面的實(shí)現(xiàn)

由于監(jiān)測(cè)系統(tǒng)設(shè)計(jì)的要求，DHCP協(xié)議的簡(jiǎn)單解碼部分只提取了DHCP消息類(lèi)型(DHCPMSGType)和事務(wù)號(hào)(TransactionID)用于監(jiān)測(cè)系統(tǒng)界面中每條數(shù)據(jù)的概要顯示，方便快速準(zhǔn)確地定位數(shù)據(jù)中的每條消息屬于哪一個(gè)信令流程。簡(jiǎn)單解碼在LTE監(jiān)測(cè)系統(tǒng)的界面顯示結(jié)果如圖5所示。

圖5 簡(jiǎn)單解碼在LTE監(jiān)測(cè)系統(tǒng)的界面顯示

特別是在LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)中對(duì)DHCPMSGType進(jìn)行處理的時(shí)候，改掉了以前在TD_SCDMA監(jiān)測(cè)系統(tǒng)中使用的預(yù)先用宏定義消息類(lèi)型，然后再用switch case匹配的方案:

switch(XXXXMSGTypeID)//XXXX消息類(lèi)型號(hào)

{

Case1:

Case2:

………………

}

采用將DHCP消息的消息類(lèi)型定義為一個(gè)結(jié)構(gòu)體類(lèi)型DHCP_MESSAGE_TYPE的三維數(shù)組DHCPMsgeTyp

eTable:

typedef struct DHCP_MESSAGE_TYPE{

int value;

char*strptr［2］;

}DHCPMessageType;

static DHCPMessageType DHCPMsgeTypeTable［］={

{1，_T("DHCP發(fā)現(xiàn)")， _T("DHCP DISCOVER")}，

{2，_T("DHCP請(qǐng)求")， _T("DHCP REQUEST")}，

{3，_T("DHCP選擇")， _T("DHCP OFFER")}，

…………………………………………

};

最后再利用for循環(huán)來(lái)實(shí)現(xiàn)消息類(lèi)型的匹配，不但節(jié)省了代碼空間，提高了代碼運(yùn)行速度，而且便于測(cè)試和修改:

int32 nDHCPMsgType=pResult-＞uDHCPMsgType;

m_DecResultItem［DHCPMSGType］.ItemValue.nenumValue=nDHCPMsgType;

for(int i=0;i＜sizeof(DHCPMsgeTypeTable)/sizeof(struct DHCP_MESSAGE_TYPE);i++)

{

if(DHCPMsgeTypeTable［i］.value==nDHCPMsgType)

{

_stprintf(m_DecResultItem［DHCPMSGType］.chNotes，_T("%s")，

DHCPMsgeTypeTable［i］.strptr［1］);

break;

}

}

3.2 DHCP協(xié)議詳細(xì)解碼的實(shí)現(xiàn)

在LTE監(jiān)測(cè)系統(tǒng)中對(duì)DHCP協(xié)議的詳細(xì)解碼做了一套完整的實(shí)現(xiàn)方案。DHCP協(xié)議詳細(xì)解碼設(shè)計(jì)方案如圖6所示。

圖6 DHCP協(xié)議詳細(xì)解碼設(shè)計(jì)方案圖

對(duì)采集到的DHCP消息數(shù)據(jù)，首先進(jìn)入?yún)f(xié)議判別函數(shù)ISMe，由UDP端口號(hào)為68或者67來(lái)辨別是否為DHCP的數(shù)據(jù)，如果不是則結(jié)束解碼，如果是則進(jìn)入詳細(xì)解碼函數(shù)bootpc_fdecode開(kāi)始解析固定消息頭部分(即可選參數(shù)Option之前的部分)。由于DHCP是BOOTP的演進(jìn)，所以筆者在設(shè)計(jì)監(jiān)測(cè)系統(tǒng)的時(shí)候仍然包含了BOOTP協(xié)議的特性。下面的圖7、圖8和圖9分別是wirshark和筆者所研究的LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)(中英文版)對(duì)DHCP協(xié)議消息固定頭部分詳細(xì)解碼的截圖。

根據(jù)協(xié)議規(guī)范中對(duì)DHCP消息頭固定部分的規(guī)定以及和wirshark的解碼結(jié)果對(duì)比可得出，LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)對(duì)DHCP固定頭部分的解碼完全正確。

當(dāng)固定消息頭解碼完成之后，進(jìn)入可選參數(shù)類(lèi)型函數(shù)decode_bootp_op進(jìn)行Option類(lèi)型的匹配。先用while循環(huán)判斷消息數(shù)據(jù)解析到的位置是否為0xff，如果是則結(jié)束解碼，如果不是則開(kāi)始匹配Option類(lèi)型:

while(*((pInfo-＞pHeader)+(pInfo-＞nCurPos))!=0xff)

{

uint8*pData=(pInfo-＞pHeader)+(pInfo-＞nCurPos);//*pData從消息頭開(kāi)始到解碼所解析的位置

switch(*pData)

{

case BOOTP_C_OP_PAD://option的類(lèi)型

res=decode_op_pad(pData，pInfo，pDetail);//與Option相對(duì)的解碼函數(shù)

break;

case BOOTP_C_OP_SUBNET_MASK:

res=decode_op_subnet_mask(pData，pInfo，pDetail);

break;

…………………………….

}

當(dāng)匹配到某個(gè)Option類(lèi)型時(shí)，就進(jìn)入相應(yīng)的Option解碼函數(shù)decode_op_xxxx進(jìn)行解碼。解析完一個(gè)獨(dú)立的Option類(lèi)型后，pData將自動(dòng)增加該Option所占的字節(jié)長(zhǎng)度，然后再進(jìn)入while循環(huán)判斷、匹配。

下面是DHCP DISCOVER攜帶的Option(可選參數(shù))部分的詳細(xì)解碼結(jié)果圖如圖10所示。

圖10 DHCP協(xié)議里DHCP消息類(lèi)型的詳細(xì)解碼(截圖)

解讀協(xié)議規(guī)范可知，可變參數(shù)項(xiàng)Option還可能會(huì)攜帶子Option。對(duì)這種攜帶了子Option項(xiàng)的解碼方法基本和沒(méi)有攜帶子Option項(xiàng)的相同，只是會(huì)多判斷在父option中何時(shí)開(kāi)始和結(jié)束子Option的解碼。

這里以Relay Agent Information這個(gè)Option為例來(lái)闡述攜帶了子Option情況的詳細(xì)解碼格式。Relay Agent Information的報(bào)文格式如圖11［6］所示。

圖11 Relay Agent Information的報(bào)文格式

Code 82(父Option類(lèi)型號(hào)為82)占1 byte，Len(Option參數(shù)的長(zhǎng)度)占1 byte，N代表了整個(gè)Agent Information Field的長(zhǎng)度，不包含Code和Len所占的2 byte。i1，i2，i3，…，iN是Relay Agent Information里面的具體參數(shù)信息，長(zhǎng)度不定。

對(duì)于Relay Agent Information里面的Suboption(子Option)的報(bào)文格式如圖12［6］所示。

圖12 Relay Agent Information的Suboption的報(bào)文格式

1是Suboption的編號(hào)，占1 byte。N是Suboption的長(zhǎng)度，占1 byte，不包含SubOpt和Len所占的2 byte。s1，s2，s3，…，sN是Suboption里面具體的參數(shù)信息，長(zhǎng)度不定。

在父Option的長(zhǎng)度后面就是它所攜帶的子Option。父Option里面的1 byte就代表1個(gè)子Option，子Option和父Option有相同報(bào)文格式、子Option類(lèi)型號(hào)、長(zhǎng)度和值。因此子Option和父Option采用相同的解碼方式。因?yàn)?個(gè)父Option會(huì)攜帶多個(gè)子Option，故而必須對(duì)何時(shí)結(jié)束解碼做出判斷。在代碼中采用了下面這種方式來(lái)判斷所攜帶的子Option是否解完。在父Option中定義1個(gè)循環(huán)長(zhǎng)度的統(tǒng)計(jì)數(shù)和1個(gè)子Option長(zhǎng)度數(shù)。

int nCLength=0; //循環(huán)中的長(zhǎng)度統(tǒng)計(jì)

int nSubLength=0; //子Option長(zhǎng)度

……

while(nCLength＜nLength)//nLength為父Option的長(zhǎng)度

{

……

nCLength+=nSubLength+2;//2是子Option的編號(hào)，l長(zhǎng)度所占的字節(jié)數(shù)

}

當(dāng)nCLength統(tǒng)計(jì)長(zhǎng)度比父Option的長(zhǎng)度nLength小的時(shí)候，表明父Option里面還有子Option，那么就繼續(xù)解碼，否則就結(jié)束子Option的解碼。

由于LTE監(jiān)測(cè)系統(tǒng)中對(duì)DHCP模塊測(cè)試時(shí)采用的是現(xiàn)有3G和2G網(wǎng)絡(luò)數(shù)據(jù)，所以無(wú)法從數(shù)據(jù)上在監(jiān)測(cè)系統(tǒng)中直接查看到帶有子Option型的可選參數(shù)結(jié)果圖形顯示，但是從前面的解碼結(jié)果圖中可以得出本研究方案改進(jìn)了之前版本監(jiān)測(cè)系統(tǒng)中處理代碼的缺陷，而且實(shí)施有效可行，能方便更多用戶參照消息更好地理解和分析協(xié)議。

4 小結(jié)

本文針對(duì)已經(jīng)開(kāi)始商業(yè)試用的LTE網(wǎng)絡(luò)及現(xiàn)有國(guó)際環(huán)境，介紹了LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)的架構(gòu)與功能，分析了DHCP協(xié)議的信令流程及報(bào)文格式，提出了研究DHCP協(xié)議解碼的方案。此研究方案在LTE網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)的軟件模塊中，采用VC++面向?qū)ο缶幊谭椒ǎ?］實(shí)現(xiàn)了DHCP協(xié)議解碼，該模塊通過(guò)大規(guī)?，F(xiàn)網(wǎng)測(cè)試論證了該研究方案的正確性、有效性、推廣性。在“重郵東電TD-LTE集中監(jiān)測(cè)系統(tǒng)”的應(yīng)用過(guò)程中穩(wěn)定、可靠，運(yùn)維良好。

［1］STEFM A S，TOUFIK L.MATI＇HEW B.LTE—the UMTS long term evolution from theory to practice［EB/OL］.［2010-03-15］.http://download.csdn.net/SOLlrce/l941542.

［2］于藝婉.TD-LTE逢天時(shí)地利人和只待時(shí)間窗口之東風(fēng)［EB/OL］.［2011-10-09］.http://www.c114.net/topic/3017/a646820.html.

［3］謝金鳳，張治中，李紅華，等.TD-SCDMA網(wǎng)絡(luò)集中監(jiān)測(cè)系統(tǒng)3G-324M協(xié)議監(jiān)測(cè)方案研究［J］.電視技術(shù)，2010，34(11):53-57.

［4］魏輝，張治中.TD-SCDMA網(wǎng)絡(luò)測(cè)試儀中SCCP協(xié)議解碼及上層PDU獲取方案［J］.重慶郵電大學(xué)學(xué)報(bào):自然科學(xué)版，2007，19(1):51-56.

［5］陳玉花，張治中，杜西亞.TD-SCDMA網(wǎng)絡(luò)Iu-PS口CDR合成方案［J］.電視技術(shù)，2009，49(11):53-56.

［6］PATRICK M.DHCP relay agent information option［EB/OL］.［2011-10-09］.ftp://ftp.rfc-editor.org/in-notes/rfc3046.txt.

［7］沈嘉，索士強(qiáng)，全海洋，等.3GPP長(zhǎng)期演進(jìn)(LTE)技術(shù)原理與系統(tǒng)設(shè)計(jì)［M］.北京:人民郵電出版社，2008.

［8］嚴(yán)蔚敏，吳偉民.數(shù)據(jù)結(jié)構(gòu)［M］.北京:清華大學(xué)出版社，2003.