蔡 浩 代博蘭 熊 馳

1 武漢鐵路職業(yè)技術學院 武漢 430205

2 中國船舶重工集團公司第七二二研究所 武漢 430079

3 武漢船舶職業(yè)技術學院 武漢 430050

引言

隨著光纖到用戶(FTTx)技術的發(fā)展和普及，我國互聯(lián)網(wǎng)已經(jīng)進入寬帶網(wǎng)絡時代。各種各樣類型豐富的通信及媒體網(wǎng)關也逐步進入到萬千公司、企業(yè)和家庭。這類家庭網(wǎng)關(簡稱網(wǎng)關)設備，一方面能夠很好地適用于FTTx各類用戶的各種業(yè)務場景，另一方面也給網(wǎng)關設備廠商和電信運營商的海量維護工作帶來巨大挑戰(zhàn)。通常，通信產(chǎn)品在布放到最終用戶時或者在運維管理過程中，都會遇到設備軟件需要進行固件升級的情況。對這類網(wǎng)關設備的固件進行升級的活動，需要設備廠商和電信運營商投入相當多的人力、物力、財力來進行升級、運維、保障。

本文基于IP組播技術提出一種僅通過比較簡單的技術實現(xiàn)和輔助設備組網(wǎng)，就能同時完成多臺網(wǎng)關設備的固件或者XML配置升級的方法，避免重復性的人力投入，提升運維管理工作效率。

1 組播技術固件升級場景

在運維管理過程中，電信運營商基于終端綜合管理系統(tǒng)(ITMS)或者網(wǎng)元管理系統(tǒng)(EMS)的網(wǎng)管系統(tǒng)，通過光線路終端 (OLT)設備完成其下掛網(wǎng)關設備的遠程固件和XML配置升級操作。以家庭網(wǎng)關的固件升級場景為例，各網(wǎng)元組網(wǎng)關系如圖1所示。

圖1 運營商網(wǎng)關固件升級場景

但網(wǎng)關設備在某些情況下，不能夠被網(wǎng)管系統(tǒng)管理到，比如EMS/ITMS網(wǎng)絡條件不具備或者需進行網(wǎng)關設備批量替換的情況時。這類網(wǎng)關由于沒有被網(wǎng)管系統(tǒng)注冊認證過，無法通過圖1所述方法實現(xiàn)其固件升級[1]。這時，電信運營商不得不組織人員，對待布放網(wǎng)關設備進行逐臺設備手工固件升級。1臺網(wǎng)關設備進行固件升級，軟件升級過程大約需要耗時3分鐘，操作人員的操作過程和升級后版本驗證需2分鐘。當網(wǎng)關設備數(shù)量多時，整個升級過程耗時長，人工成本較高。同時，人員由于重復勞動，難免出錯且工作效率很低。

如果操作人員按圖2所示對待升級網(wǎng)關設備進行組網(wǎng)，實現(xiàn)“一對多”的通信場景，就可以讓一臺固件升級服務器(簡稱服務器)同時處理多臺網(wǎng)關設備的固件升級操作。整個固件升級過程的工作效率，就能夠呈現(xiàn)數(shù)量級的提升；因此，通常會考慮采用廣播或者組播技術來實現(xiàn)網(wǎng)關設備固件升級場景。廣播或者組播技術具有如下優(yōu)點。1)減少人力成本，減少服務器空載時間，提升工作效率。2)使“一對多”傳輸成為可能，實現(xiàn)固件升級的分布式應用。但是，在網(wǎng)關設備的固件升級過程中，既可能存在網(wǎng)關個體的升級進度差異，又可能存在部分網(wǎng)關無需升級或者被重復升級的情況。如圖3廣播技術固件升級場景所示，服務器和網(wǎng)關間無法避免大量不必要的網(wǎng)絡流量，因此，在升級場景中采用廣播技術時，難以控制網(wǎng)絡流量和消除流量冗余情況。而組播技術的IGMP(Internet Group Management Protocol，互聯(lián)網(wǎng)組管理協(xié)議)報文處理機制，可以很好地規(guī)避組播服務器和網(wǎng)關間的流量冗余情況。網(wǎng)關固件升級場景，可以看成是組播服務器向網(wǎng)關推送組播節(jié)目的過程，加入組播節(jié)目組的網(wǎng)關能夠接收到服務器的組播服務。如圖4組播技術固件升級場景所示，組播升級方式可以有效規(guī)避部分網(wǎng)關無需升級或者被重復升級的情況。

圖2 網(wǎng)關升級場景

圖3 廣播技術固件升級場景

圖4 組播技術固件升級場景

2 IP組播、IGMP Snooping和IGMP分析

IP組播屬于端到端的服務，它的尋址機制是借助組播地址(即IP組播地址)，實現(xiàn)數(shù)據(jù)信息從組播源發(fā)送到一組接收者的過程。同時，還必須提供一種技術將IP組播地址映射為數(shù)據(jù)鏈路層的組播MAC地址。以太網(wǎng)傳輸單播IP報文的時候，目的MAC地址使用的是接收者的MAC地址。但是在傳輸組播數(shù)據(jù)包時，其目的地不再是一個具體的接收者，而是一個成員不確定的組，所以要使用組播MAC地址?；ヂ?lián)網(wǎng)編號分配委員會(Internet Assigned Numbers Authority，IANA)規(guī)定(如圖5所示)，IPv4組播MAC地址的高24位為0x01005E，第25位為0，低23位為IPv4組播地址的低23位。IPv4組播地址與MAC地址的映射關系如圖6所示。例如，組播IP地址224.8.8.8就映射為組播MAC地址01-00-5e-08-08-08[2]。

圖5 IP地址到MAC地址的映射

IANA將D類地址空間分配給IPv4組播使用，范圍從224.0.0.0到239.255.255.255，具體分類及其含義如表1所示[2]。

表1 IPv4 組播地址的范圍及含義

通常，把工作在數(shù)據(jù)鏈路層的IP組播稱為“二層組播”，相應的組播協(xié)議稱為“二層組播協(xié)議”，包括IGMP Snooping、組播VLAN 等；把工作在網(wǎng)絡層的IP組播稱為“三層組播”，相應的組播協(xié)議稱為“三層組播協(xié)議”，包括IGMP、PIM、MSDP、MBGP 等。

互聯(lián)網(wǎng)組管理協(xié)議窺探(Internet Group Management Protocol Snooping，IGMP Snooping)是運行在二層設備上的組播約束機制，通過窺探和分析主機與三層組播路由器之間交互的IGMP報文來管理和控制組播組，可以有效抑制組播數(shù)據(jù)在二層網(wǎng)絡中的擴散[2]。IGMP Snooping功能需要借助于二層交換機的組播MAC地址轉發(fā)表機制。如圖6所示，通常網(wǎng)關B會接收到網(wǎng)關A的成員關系報文(Membership Report)，發(fā)現(xiàn)是相同的組播組地址，而自己產(chǎn)生抑制的情況。這時，交換機將抑制網(wǎng)關A的請求報文傳送到網(wǎng)關B和組播服務器處(如圖6步驟3所示)。從而有效避免交換機由于不能接收到網(wǎng)關B的請求報文，而不能建立正確的組播MAC地址轉發(fā)表的情況。

圖6 交換機IGMP Snooping抑制消息報告

IGMP Snooping協(xié)議工作原理如圖7所示，交換機“窺探”網(wǎng)關與服務器之間的交互報文，跟蹤組播組信息及申請的端口。當交換機“窺探”到網(wǎng)關朝服務器發(fā)出的成員關系報文時，交換機便把該端口加入組播MAC地址轉發(fā)表中；當交換機“窺探”到網(wǎng)關離開(IGMP Leave)報文時，交換機便把該端口從表中刪除[3]。服務器會定時發(fā)送通用查詢(General Query)報文，交換機在收到Query報文后，如果在一定的時間段內(nèi)沒有收到網(wǎng)關的IGMP Report報文，便把該端口從表中刪除。

圖7 IGMP Snooping工作過程

IGMP是TCP/IP協(xié)議族中負責IP組播成員管理的協(xié)議，用來在IP主機和與其直接相鄰的組播路由器之間建立、維護組播組成員關系[4-5]；IGMP的TTL參數(shù)永遠是1，保證了IGMP的使用范圍；因此，IGMP消息不能被路由器轉發(fā)，只能限制在本地網(wǎng)段內(nèi)部。在網(wǎng)關的固件升級場景中，待接收固件升級的組播數(shù)據(jù)網(wǎng)關與服務器在同一個子網(wǎng)內(nèi)，不涉及路由選擇，無需考慮組播路由的相關協(xié)議。

目前，IGMP的版本有V1/V2/V3三種。如表2所示，需要在網(wǎng)關上開啟一個組播流接收進程，支持V1/V2/V3版本通用報文的處理；同時，服務器端也需要支持組播服務器端的IGMP報文處理。網(wǎng)關上的組播接收進程用來接收、校驗收到的IGMP報文和組播數(shù)據(jù)，并將組播數(shù)據(jù)組裝成固件升級文件供固件升級進程處理。

表2 IGMP報文分類

在網(wǎng)關固件升級場景中，如果同一組網(wǎng)環(huán)境下，同一時間段內(nèi)僅通過服務器對同一批網(wǎng)關進行同一固件版本的升級服務，則可以無需考慮在服務器端實現(xiàn)通用查詢報文的相關功能。但通常情況下，組網(wǎng)環(huán)境中的交換機需要開啟IGMP Snooping功能。如圖6所示，在開啟IGMP Snooping之后，交換機的MPU在收到網(wǎng)關的成員關系報文時，不會將報文轉發(fā)到其他端口。其他端口下的網(wǎng)關由于無法收到本網(wǎng)段內(nèi)此網(wǎng)關發(fā)出的成員關系報文，將不會自己產(chǎn)生消息報告抑制現(xiàn)象。這樣，交換機能夠學習到包含所有網(wǎng)關的完整組播MAC地址轉發(fā)表。但由于交換機的IGMP Snooping抑制了消息報告，成員關系報文將無法發(fā)送到服務器。這樣，服務器也將無法將用于固件升級的組播數(shù)據(jù)發(fā)送到相應的組播組子網(wǎng)內(nèi)，實現(xiàn)組播升級功能。為此，可以在交換機上，將本設備上的所有路由器端口都記錄在路由器端口列表中，并給這些路由器端口設置老化定時器。如果路由器端口老化定時器超時后，還沒有收到IGMP通用查詢報文，交換機就認為這個端口不再是一個路由器端口；因此，為保證連接服務器的交換機端口為路由器端口，需要保留服務器發(fā)送通用查詢報文的功能。這樣，交換機上與組播服務器連接的端口是路由器端口，可以轉發(fā)網(wǎng)關的成員關系報文，不影響正常的網(wǎng)關加入組播升級服務過程。

3 IGMP狀態(tài)機的修改與實現(xiàn)

在網(wǎng)關的固件升級場景中，服務器和網(wǎng)關間組成一個鄰接網(wǎng)絡，需要在服務器端實現(xiàn)組播源的UDP格式組播數(shù)據(jù)流播送功能及組播路由器的IGMP功能；在網(wǎng)關上實現(xiàn)組播主機的IGMP功能及組播數(shù)據(jù)與固件程序的接口功能。

服務器端只需維護一個鄰接物理網(wǎng)絡的組播組成員(網(wǎng)關)的列表和一個針對每個網(wǎng)關的定時器[6]。其IGMP功能是使用IGMP來了解它的物理網(wǎng)絡上的組播升級組擁有哪些網(wǎng)關。當服務器接收到了來自網(wǎng)關的成員關系報文，它就會把該網(wǎng)關的成員報告加入到一個組播組成員列表中，并且會為其成員關系設一個值為組成員生存周期的定時器，并通知組播源模塊開始播送UDP格式的組播數(shù)據(jù)流。其它網(wǎng)關的重復報告會刷新該組播成員關系定時器，該服務器會依據(jù)組播成員關系定時器，周期性地在這個鄰接網(wǎng)絡上發(fā)出通用查詢報文，請求得到網(wǎng)關的成員關系信息。

如圖8所示，網(wǎng)關端需要實現(xiàn)組播主機的IGMP功能。當網(wǎng)關通過發(fā)送成員關系報文，加入到一個組播組(地址是224.8.8.8)后，它就能夠接收服務器發(fā)送過來的組播升級UDP數(shù)據(jù)包。由UDP協(xié)議棧保證收到的每個組播升級包的數(shù)據(jù)有效性，由組播數(shù)據(jù)與固件程序的接口功能保證整個升級數(shù)據(jù)的完整性。當升級數(shù)據(jù)驗證完整性后，其IGMP功能模塊發(fā)送離開報文，網(wǎng)關退出固件組播升級模式。當固件升級完成后，網(wǎng)關通過點亮相關LED燈，指示升級人員為此臺網(wǎng)關完成相應的升級任務。

圖8 固件服務器端功能模塊

如圖9所示，按RFC2236定義說明[7-9]，通常情況下組播主機的IGMP處理流程包含以下三個狀態(tài)，即“無成員”狀態(tài)、“滯留成員”狀態(tài)和“空閑成員”狀態(tài)。當一個組播主機(網(wǎng)關)加入了一個組播組，會立即發(fā)送針對此組播組的一個成員關系報文；當一個主機(網(wǎng)關)正常退出一個組播組時，它會發(fā)送一條離開報文給所有組播路由器組播組(地址為224.0.0.2)；當一個主機(網(wǎng)關)接收到了通用查詢報文或者特定組的查詢(Group-Specific Query)報文后[7-8]，該主機刷新查詢應答定時器，并在查詢報文中所設定的最大響應時間(Max Response Time)內(nèi)發(fā)送一個成員關系報文到該組播組中，其IP中TTL的值為1。組播服務器接收到成員關系報文后，將繼續(xù)維護該升級組播組的成員關系。

本方案如圖10所示，將RFC2236定義的組播主機狀態(tài)機進行了簡化，應用到網(wǎng)關端的IGMP處理流程中。網(wǎng)關的狀態(tài)機由“無成員”狀態(tài)和“有成員”狀態(tài)兩個狀態(tài)組成。網(wǎng)關端具體的IGMP行為由圖10所示的IGMP報文狀態(tài)機定義。網(wǎng)關上，通過實現(xiàn)Query Timer和Report Timer這兩個定時器及其超時處理，來維護其與服務器的IGMP協(xié)議通信。Report Timer定時器用來實現(xiàn)網(wǎng)關在組播組內(nèi)作為組播成員加入和離開場景的功能；Query Timer定時器用來應答組播服務器的查詢報文，并在查詢報文的Max Response Time內(nèi)應答一個成員關系報文，讓組播服務器維持組播升級組播組關系。

圖9 組播主機的IGMP狀態(tài)機

圖10 網(wǎng)關的IGMP狀態(tài)機

4 組播升級場景配置及測試驗證

綜上所述，網(wǎng)關和服務器間的組網(wǎng)關系非常簡單，僅通過二層交換機連接待升級的網(wǎng)關和服務器即可。以Dlink的二層交換機為例，組網(wǎng)結構如圖11所示。

圖11 組網(wǎng)結構圖

4.1 組播升級場景配置

網(wǎng)關組播升級場景，需要在此交換機上進行下列配置。1)創(chuàng)建VLAN；2)添加端口到VLAN；3)創(chuàng)建VLAN接口IP地址；4)IGMP Snooping使能。

Dlink交換機的參考配置如下。1)刪除默認VLAN default包含的端口1-28，config vlan default delete 1-28。2)創(chuàng)建VLAN名為vlan10，并標記VID為10，create vlan v10 tag 10。3)把端口1-26添加到VLAN10，config vlan v10 add untagged 1-26。4)創(chuàng)建虛擬的接口if10給VLAN10的VLAN子網(wǎng)，并且指定該接口的IP為192.168.1.254/24，創(chuàng)建后enable激活該接口，create ipif if10 192.168.1.254/24 v10 state enable。5)配置IGMP Snooping，config igmp all version 2 state enable//配置IGMP版本為2，enable igmp_snooping，config igmp_snooping all state enable。

4.2 測試驗證

服務器端需要開啟固件升級軟件，并進行如下配置操作。

1)選擇服務器網(wǎng)卡。如果組播服務器是多網(wǎng)卡，那么需要選擇跟網(wǎng)關是同一個網(wǎng)段的網(wǎng)卡，如圖12示例選取192.168.1.2網(wǎng)段的網(wǎng)卡，設置組播組IP地址為224.8.8.8。2)選擇需要升級的版本，如圖13所示。3)組播升級，如圖14所示。4)家庭網(wǎng)關端組播升級結果判斷，如表3所示[10-11]。5)整個組播固件升級完成，停止組播升級，按“Stop”按鈕。

本方案在江蘇省移動運營商的網(wǎng)關固件升級場景下進行驗證，升級效率參考圖15所示。測試場景的硬件設備，由1 200臺待升級網(wǎng)關，1臺2層交換機和1臺PC機組成。按通常人工升級方式，需要兩名操作人員，至少3天，且每天連續(xù)工作10小時以上才能夠完成這些網(wǎng)關設備的固件升級工作；采用組播升級方式，兩名操作人員僅需要7小時就完成任務。而且采用組播升級方式，可保證在網(wǎng)關固件升級過程中，不會人為引入固件升級誤操作。

圖12 固件升級軟件配置界面

圖13 選擇需要固件升級的軟件版本

圖14 固件升級過程

表3 網(wǎng)關升級過程LED指示燈定義表

圖15 網(wǎng)關固件升級效率提升分析圖

目前，運營商的網(wǎng)關設備固件升級主要借助2種方式，即EMS/ITMS遠程升級和人工升級。如表4所示，組播升級方式為運營商在無網(wǎng)管網(wǎng)絡環(huán)境或者網(wǎng)管網(wǎng)絡暫時不具備的情況下，進行網(wǎng)關固件升級場景提供了更有效的技術手段。由表4可知，組播升級網(wǎng)關固件方式最適合小批量網(wǎng)關待升級，且無法滿足網(wǎng)關固件升級的網(wǎng)元組網(wǎng)條件的場景。

表4 網(wǎng)關升級場景分析

5 總結與展望

組播技術涵蓋了地址方案、成員管理、路由和安全等各個方面，其中組播地址的分配方式、域間組播路由以及組播安全等仍是目前研究的熱點。從目前的情況看，組成員管理普遍采用IGMP v2版本。本文僅嘗試了組播技術成員管理在局域網(wǎng)組網(wǎng)條件下的技術修改和功能實現(xiàn)，后續(xù)可以結合FTTx和光纖通信技術，探索組播技術中相關域間組播路由技術方向，嘗試提出更多、更有效的運營商遠程管理海量網(wǎng)關設備的方式和方法，為提升運營商的運維管理應用體驗，做更多有益的嘗試。

參考文獻

[1]中國電信.中國電信家庭網(wǎng)關與終端綜合管理系統(tǒng)接口技術要求[S].2012,9:6-9

[2] 尹海春.二層交換機上IGMP Snooping協(xié)議的實現(xiàn)研究[D].電子科技大學,2004:1-13

[3] 何英,陸正福,方剛.二層交換機中IGMP/MLD探聽機制的原理分析[J].云南民族大學學報:自然科學版,2005(1):78-82

[4]RFC 4286,Multicast Router Discovery[S].2005:1-18

[5] 柏勇,何春,王賞.基于IP組播的MPLS組播架構[J].通信技術,2010(10):62-64

[6] 梅瑜華,甘朝欽,馬雪嬌.EPON系統(tǒng)中IGMP的優(yōu)化實現(xiàn)[J].光通信技術.2013(2):15-17

[7]RFC 2236,Internet Group Management Protocol, Version 2[S].1997:1-16

[8]RFC 3376,Internet Group Management Protocol, Version 3[S].2002:1-53

[9]RFC 1112,Host Extensions for IP Multicasting[S].1989:1-17

[10]中國電信.中國電信“我的e家”技術規(guī)范-e家終端(e8)[S].2009:46

[11]中國電信.中國電信“我的e家”技術規(guī)范-e家終端與終端綜合管理系統(tǒng)接口[S].2009:6-9