亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

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

        2012-01-31 05:21:12李丹鳳張治中
        電視技術(shù) 2012年9期
        關(guān)鍵詞:IP地址解碼消息

        李丹鳳,張治中

        (重慶郵電大學(xué) 通信網(wǎng)與測試技術(shù)重點實驗室,重慶400065)

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

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

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

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

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

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

        圖2 一次成功DHCP的流程圖

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

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

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

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

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

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

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

        2 DHCP的報文格式

        DHCP的報文格式,如圖3所示。

        圖3 DHCP報文格式

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

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

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

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

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

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

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

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

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

        switch(XXXXMSGTypeID)//XXXX消息類型號

        {

        Case1:

        Case2:

        ………………

        }

        采用將DHCP消息的消息類型定義為一個結(jié)構(gòu)體類型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請求"), _T("DHCP REQUEST")},

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

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

        };

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

        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é)議詳細解碼的實現(xiàn)

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

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

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

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

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

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

        {

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

        switch(*pData)

        {

        case BOOTP_C_OP_PAD://option的類型

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

        break;

        case BOOTP_C_OP_SUBNET_MASK:

        res=decode_op_subnet_mask(pData,pInfo,pDetail);

        break;

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

        }

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

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

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

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

        這里以Relay Agent Information這個Option為例來闡述攜帶了子Option情況的詳細解碼格式。Relay Agent Information的報文格式如圖11[6]所示。

        圖11 Relay Agent Information的報文格式

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

        對于Relay Agent Information里面的Suboption(子Option)的報文格式如圖12[6]所示。

        圖12 Relay Agent Information的Suboption的報文格式

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

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

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

        int nSubLength=0; //子Option長度

        ……

        while(nCLength<nLength)//nLength為父Option的長度

        {

        ……

        nCLength+=nSubLength+2;//2是子Option的編號,l長度所占的字節(jié)數(shù)

        }

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

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

        4 小結(jié)

        本文針對已經(jīng)開始商業(yè)試用的LTE網(wǎng)絡(luò)及現(xiàn)有國際環(huán)境,介紹了LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)的架構(gòu)與功能,分析了DHCP協(xié)議的信令流程及報文格式,提出了研究DHCP協(xié)議解碼的方案。此研究方案在LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)的軟件模塊中,采用VC++面向?qū)ο缶幊谭椒ǎ?]實現(xiàn)了DHCP協(xié)議解碼,該模塊通過大規(guī)?,F(xiàn)網(wǎng)測試論證了該研究方案的正確性、有效性、推廣性。在“重郵東電TD-LTE集中監(jiān)測系統(tǒng)”的應(yīng)用過程中穩(wě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逢天時地利人和只待時間窗口之東風(fēng)[EB/OL].[2011-10-09].http://www.c114.net/topic/3017/a646820.html.

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

        [4]魏輝,張治中.TD-SCDMA網(wǎng)絡(luò)測試儀中SCCP協(xié)議解碼及上層PDU獲取方案[J].重慶郵電大學(xué)學(xué)報:自然科學(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]沈嘉,索士強,全海洋,等.3GPP長期演進(LTE)技術(shù)原理與系統(tǒng)設(shè)計[M].北京:人民郵電出版社,2008.

        [8]嚴蔚敏,吳偉民.數(shù)據(jù)結(jié)構(gòu)[M].北京:清華大學(xué)出版社,2003.

        猜你喜歡
        IP地址解碼消息
        《解碼萬噸站》
        鐵路遠動系統(tǒng)幾種組網(wǎng)方式IP地址的申請和設(shè)置
        一張圖看5G消息
        解碼eUCP2.0
        中國外匯(2019年19期)2019-11-26 00:57:32
        NAD C368解碼/放大器一體機
        Quad(國都)Vena解碼/放大器一體機
        基于SNMP的IP地址管理系統(tǒng)開發(fā)與應(yīng)用
        黑龍江電力(2017年1期)2017-05-17 04:25:16
        消息
        消息
        消息
        丁香美女社区| 午夜一区二区三区免费观看| 日本二区在线视频观看| 成在线人av免费无码高潮喷水 | 国产高潮国产高潮久久久| 亚洲 无码 制服 丝袜 自拍| 一区二区三区日本美女视频| 亚洲开心婷婷中文字幕| 水蜜桃无码视频在线观看| 日韩在线视精品在亚洲| 亚洲成人av在线播放不卡| 伊人久久大香线蕉午夜av| 国产成人精品日本亚洲11 | 中文字幕一区二区三在线| 少妇被粗大进猛进出处故事| 久久久受www免费人成| 國产AV天堂| 狠狠久久av一区二区三区| 风韵丰满熟妇啪啪区老老熟妇| 久久99热久久99精品| 欧美激情中文字幕在线一区二区| 国产精品一区二区蜜臀av| 国产a∨天天免费观看美女| 日韩人妻无码一区二区三区久久99 | 久久中文字幕无码一区二区| 丝袜美腿诱惑一二三区| 国产精品亚洲一区二区三区| 国产专区国产av| 乱人伦人妻中文字幕不卡| 久久综合国产精品一区二区| 风流老熟女一区二区三区| 视频福利一区| 国产又色又爽的视频在线观看91| 久久国产成人精品av| a国产一区二区免费入口| 日韩一区二区三区中文字幕| 亚洲乱码av乱码国产精品| 亚洲色在线v中文字幕| 精品一区二区三区久久久| 国产一区二区三区的区| 亚洲国产精品久久人人爱|