本發(fā)明涉及數(shù)據(jù)通信技術(shù)領(lǐng)域，尤其涉及一種CMC系統(tǒng)中CM上線過程中的報文識別方法。

背景技術(shù)：

CMC原文是“Cable Media Convert”, 有線電纜媒介轉(zhuǎn)換設(shè)備。它是C-DOCSIS系統(tǒng)中的頭端設(shè)備。

CM原文是“Cable Modem”,電纜調(diào)制調(diào)解器。負責連接用戶的PC與HFC網(wǎng)絡(luò)，對網(wǎng)絡(luò)和用戶數(shù)據(jù)進行調(diào)制/解調(diào)并傳輸，實現(xiàn)網(wǎng)絡(luò)與用戶數(shù)據(jù)的雙向交互。

DOCSIS原文是“Data-over-Cable Service Interface Specification”, 電纜數(shù)據(jù)業(yè)務(wù)接口規(guī)范, 它的基本功能是在頭端和用戶側(cè)設(shè)備間透明傳輸IP報文。

HFC原文是“Hybrid Fiber Coaxial”, 光纖-同軸電纜混合網(wǎng)。

C-DOCSIS原文是“China DOCSIS”,DOCSIS在中國演進生成的標準，可以簡單看作是DOCSIS系統(tǒng)的一個子集，C-DOCSIS系統(tǒng)由C-DOCSIS頭端、C-DOCSIS終端、配置系統(tǒng)和網(wǎng)絡(luò)管理系統(tǒng)組成，主要應用于廣電系統(tǒng)網(wǎng)絡(luò)中。

C-DOCSIS頭端連接同軸分配網(wǎng)絡(luò)和匯聚網(wǎng)絡(luò)，負責它們之間的數(shù)據(jù)轉(zhuǎn)發(fā)，通過匯聚網(wǎng)絡(luò)接入運營商的配置系統(tǒng)和網(wǎng)絡(luò)管理系統(tǒng)。

C-DOCSIS終端設(shè)備連接運營商的同軸分配網(wǎng)絡(luò)和用戶設(shè)備，負責它們之間的數(shù)據(jù)轉(zhuǎn)發(fā)。

C-DOCSIS配置系統(tǒng)提供C-DOCSIS系統(tǒng)的業(yè)務(wù)和設(shè)備配置服務(wù)，實現(xiàn)CM配置文件的生成、下發(fā)、終端軟件升級等功能，包括DHCP服務(wù)器、配置文件服務(wù)器等。配置系統(tǒng)與CM及CPE可能處在不同的物理網(wǎng)段的網(wǎng)絡(luò)。

C-DOCSIS系統(tǒng)初始化主要包括兩部分,首先是頭端CMC完成基本初始化，之后CM的初始化上線需要與頭端CMC和配置服務(wù)器進行多次交互才能最終完成。CM的初始化上線包括以下5個基本步驟：

1.CM下行頻道掃描與CMC同步下行流。

2.CMC獲取上行參數(shù)。

3.CMC測距，自動調(diào)節(jié)物理參數(shù)與CM適配。

4.CM建立IP連接（如圖1所示）。

5.CM注冊。

步驟1-3為硬件射頻模塊自動完成，4,5為軟件系統(tǒng)完成。

步驟4建立IP連接為本發(fā)明主要關(guān)注內(nèi)容。IP連接過程包括如下兩部分：

CM通過與配置系統(tǒng)中的DHCP服務(wù)器交互，獲取IP地址，網(wǎng)關(guān)地址，CM配置文件服務(wù)器和文件名。

CM在獲得IP地址后，通過TFTP從配置服務(wù)器下載CM配置文件，該配置文件保證CM上線后正常工作。

在實際應用場景中，由于配置系統(tǒng)與CM可能不在一個VLAN，之間可能經(jīng)過二層交換匯聚網(wǎng)絡(luò)，那么CM建立IP連接過程中與配置服務(wù)器交互的DHCP、TFTP報文需要標記其所屬的VLAN ID，才能正常通信完成連接，而這部分的處理由頭端CMC完成。

頭端CMC需要識別CM發(fā)送到配置服務(wù)器的DHCP、TFTP報文，并添加包含正確VLAN ID的VLAN TAG，而對于配置服務(wù)器回應給CM的DHCP、TFTP報文則需要在CMC上剝除VLAN TAG后發(fā)送給CM。

DHCP報文識別方法：UDP報文且目的端口號是68或69，CMC軟件解析報文過程相對簡單；TFTP雖然也是UDP報文，但除了客戶端發(fā)出的請求報文目的端口號固定為69，但后續(xù)的TFTP數(shù)據(jù)傳輸報文和ACK報文端口號不再固定，每個TFTP連接都由TFTP服務(wù)器動態(tài)分配。所以除了第一個TFTP請求報文識別簡單，后續(xù)的TFTP數(shù)據(jù)傳輸和ACK報文相對復雜。常見的方法就是記錄每個TFTP連接的客戶端源端口號和TFTP服務(wù)器端分配的源端口號，如果CM較多，CMC軟件解析記錄的TFTP連接數(shù)也隨之增多，不僅解析過程較為復雜，而且由于報文識別過程是每報文都要執(zhí)行的，還會降低CMC的轉(zhuǎn)發(fā)性能。

技術(shù)實現(xiàn)要素：

為解決上述問題， 本發(fā)明提供了一種CMC系統(tǒng)中CM上線過程中的報文識別方法。

所述系統(tǒng)包括運營商網(wǎng)絡(luò)、交換機、CMC、HFC、若干通過HFC與CMC連接的CM；運營商網(wǎng)絡(luò)、交換機、CMC、HFC、CM順次連接，其特征在于，所述CMC中存儲有一個CM信息表，所述CM信息表存儲有各個CM的MAC地址信息。

上述方法包括上行報文發(fā)送流程，該流程包括如下步驟：

步驟一：某個或者某些CM初始化，向CMC發(fā)送上行報文。

步驟二：CMC接收上行報文，順次對各個上行報文執(zhí)行如下操作：

步驟2.1：將上行報文頭中獲取的源MAC地址與CM信息表中的MAC地址信息逐一比較，判斷該源MAC地址是否為某個CM的MAC地址,如是的話則執(zhí)行后續(xù)步驟，否則繼續(xù)上行發(fā)送。

步驟2.2:判斷該上行報文是否具有VLAN Tag，如果沒有則視為TFTP報文，并執(zhí)行步驟2.3。

步驟2.3：給該上行報文標記上TFTP服務(wù)器所屬VLAN Tag，繼續(xù)上行發(fā)送;

步驟三：重復執(zhí)行步驟二，直到遍歷完所有上行報文。

進一步的，步驟2.2具體為：對上行報文進行類型判斷，判斷方法為：首先判斷該上行報文是否已經(jīng)標記VLAN Tag，如果已經(jīng)標記則說明是該報文是DHCP 報文，繼續(xù)上行發(fā)送且不再執(zhí)行后續(xù)步驟，如果沒有VLAN Tag則視為TFTP報文，并執(zhí)行步驟2.3。

進一步的，所述方法包括下行數(shù)據(jù)發(fā)送流程，包括如下步驟：

步驟一： CMC接收下行報文，順次對各個下行報文執(zhí)行如下操作：

步驟1.1：將下行報文頭中的目的MAC地址與CM信息表項中的MAC逐一比較，判斷該目的MAC地址是否為某個CM的MAC地址,如是的話則認為是發(fā)送給對應CM的管理報文，繼續(xù)執(zhí)行步驟三，否則直接繼續(xù)上行發(fā)送。

步驟1.2：檢查該下行報文是否包含VLAN Tag，如果包含則刪除VLAN Tag，然后執(zhí)行步驟四，否則執(zhí)行步驟四。

步驟1.3：繼續(xù)發(fā)送該下行報文。

步驟二： 重復執(zhí)行步驟1，直到遍歷完所有下行報文。

進一步的，所述CM連接有機頂盒和/或計算機和/或手機。

本發(fā)明的有益效果為：

本發(fā)明針對現(xiàn)有技術(shù)CM上線建立IP連接過程軟件識別TFTP報文過程復雜且會影響頭端CMC轉(zhuǎn)發(fā)性能的問題，提供了一種對TFTP報文簡化識別的方法，即不用像現(xiàn)有技術(shù)那樣解析報文內(nèi)容、跟蹤記錄每個TFTP連接端口號信息，而是將除了DHCP的報文均識別為TFTP報文，然后對報文進行VLAN Tag處理，上行報文添加VLAN Tag，下行刪除VLAN Tag。該方法不需要對報文內(nèi)容作深入解析，而是取出報文頭中的源MAC或目的MAC信息與CM信息表項中記錄的MAC地址比較，MAC相同且無VLAN Tag則識別為TFTP報文，處理邏輯簡單容易實現(xiàn)，且對CMC轉(zhuǎn)發(fā)性能無影響。

附圖說明

圖1是現(xiàn)有技術(shù)的流程圖。

圖2為CMC系統(tǒng)結(jié)構(gòu)示意圖。

圖3為上行報文發(fā)送流程圖。

圖4為下行報文發(fā)送流程圖。

具體實施方式

如圖2所示為現(xiàn)有技術(shù)中CMC系統(tǒng)的構(gòu)造示意圖。所述系統(tǒng)包括運營商網(wǎng)絡(luò)、交換機、CMC、HFC(Hybrid Fiber－Coaxial，混合光纖同軸電纜網(wǎng))、若干通過HFC與CMC連接的CM。所述CM連接有STB（Set-Top-Box ，機頂盒）和/或PC和/或手機等可聯(lián)網(wǎng)的終端設(shè)備。運營商網(wǎng)絡(luò)、交換機、CMC、HFC、CM順次連接。從CM或者與CM連接的終端設(shè)備向運營商網(wǎng)絡(luò)的數(shù)據(jù)傳輸方向為上行方向，發(fā)送的報文為上行報文，反之則為下行方向，發(fā)送的報文為下行報文。

與現(xiàn)有技術(shù)不同的是，所述CMC中預存一個CM信息表項，所述CM信息表項記錄了該CMC下所有CM包括MAC在內(nèi)的相關(guān)信息。該表可由DHCP軟件模塊創(chuàng)建。

CM在上線建立IP連接過程中會向運營商的配置系統(tǒng)發(fā)送上行報文，包括DHCP請求和TFTP請求。首先CM向配置系統(tǒng)發(fā)送DHPC請求報文，與配置系統(tǒng)中的DHCP服務(wù)器完成交互并為CM分配IP地址，接著CM向配置系統(tǒng)的配置服務(wù)器發(fā)送TFTP請求報文以獲取配置文件，配置服務(wù)器在接收到上行的TFTP請求報文后則向CM發(fā)送配置文件（下行報文），CM在接收到配置文件后進行配置和注冊，在完成注冊后CM上線初始化完成。

采用本發(fā)明的技術(shù)構(gòu)思，對上行報文的處理方法包括如圖3所示步驟:

步驟一：某個或者某些CM初始化，向CMC發(fā)送上行報文。

步驟二：CMC接收上行報文，順次對各個上行報文執(zhí)行如下操作：

步驟2.1：將上行報文頭中獲取的源MAC地址與CM信息表中的MAC地址信息逐一比較，判斷該源MAC地址是否為某個CM的MAC地址,如是的話則執(zhí)行后續(xù)步驟，否則繼續(xù)上行發(fā)送。

步驟2.2:判斷該上行報文是否具有VLAN Tag，如果沒有則視為TFTP報文，并執(zhí)行步驟2.3。

該步驟可以具體描述為：對上行報文進行類型判斷，判斷方法為：首先判斷該上行報文是否已經(jīng)標記VLAN Tag，如果已經(jīng)標記則說明是該報文是DHCP 報文，繼續(xù)上行發(fā)送且不再執(zhí)行后續(xù)步驟，如果沒有VLAN Tag則視為TFTP報文，

步驟2.3：給該上行報文標記上TFTP服務(wù)器所屬VLAN Tag，繼續(xù)上行發(fā)送;

步驟三：重復執(zhí)行步驟二，直到遍歷完所有上行報文。

CM上線過程中發(fā)送的上行報文包括了DHCP報文、TFTP報文，本發(fā)明與現(xiàn)有技術(shù)的區(qū)別之處就在于將CM發(fā)送的上行報文就簡單的區(qū)分為DHCP報文、非DHCP報文，而所有非DHCP報文都被簡略的認為成TFTP報文。這樣做的好處是非常的高效，雖然有可能在此過程中會有CM發(fā)送的其余種類的報文被認為成TFTP報文被發(fā)送TFTP服務(wù)器，但TFTP服務(wù)器不會對其進行任何處理，只處理真正的TFTP報文，不會影響CM的初始化。

采用本發(fā)明的技術(shù)構(gòu)思，對下行報文的處理方法包括如圖4所示步驟:

步驟一： CMC接收下行報文，順次對各個下行報文執(zhí)行如下操作：

步驟1.1：將下行報文頭中的目的MAC地址與CM信息表項中的MAC逐一比較，判斷該目的MAC地址是否為某個CM的MAC地址,如是的話則認為是發(fā)送給對應CM的管理報文，繼續(xù)執(zhí)行步驟三，否則直接直接執(zhí)行步驟四。

如果目的MAC地址不是CM的地址，則認為是發(fā)送給與CM連接的可聯(lián)網(wǎng)用戶終端設(shè)備的報文，對此種報文不做處理。

步驟1.2：檢查該下行報文是否包含VLAN Tag，如果包含則刪除VLAN Tag，然后執(zhí)行步驟四，否則直接繼續(xù)上行發(fā)送。

步驟1.3：繼續(xù)發(fā)送該下行報文。

步驟二： 重復執(zhí)行步驟1，直到遍歷完所有下行報文。

對下行報文的處理方式與現(xiàn)有技術(shù)類似。上述各個步驟的實現(xiàn)可以通過運行在CMC里面的軟件實現(xiàn)。