專利名稱：數(shù)據(jù)網(wǎng)絡(luò)設(shè)備及其管理控制方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)網(wǎng)絡(luò)設(shè)備，特別涉及用于在數(shù)據(jù)網(wǎng)絡(luò)設(shè)備上實(shí)現(xiàn)高可用性(HA，High Availability)的管理控制方法和控制裝置、以及具有這樣的控制裝置的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備。
背景技術(shù)：
高可用性實(shí)際意義隨著因特網(wǎng)(Internet)的飛速發(fā)展，使得網(wǎng)絡(luò)已經(jīng)涌入到社會(huì)生活的各個(gè)角落中，人們的生活越來越離不開網(wǎng)絡(luò)，Internet的關(guān)鍵應(yīng)用也越來越多，因此，對(duì)網(wǎng)絡(luò)的穩(wěn)定與可靠性的要求也越來越高。數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的每1分鐘的停(down)機(jī)，都會(huì)給運(yùn)營商和企業(yè)帶來很大的損失。根據(jù)Sterling Research公司的報(bào)告，一小時(shí)的down機(jī)會(huì)給紐約市一家股票交易所帶來六百五十萬美元的損失，而一個(gè)自動(dòng)提款機(jī)也會(huì)因此損失一萬五千美元。因此，高可用性已經(jīng)成為了電信級(jí)設(shè)備的基本需求。
另一方面，從運(yùn)營商的角度，他們對(duì)高可用性的關(guān)注也是日益增加。在BTexact Technologies最近所做的一個(gè)調(diào)查中，網(wǎng)絡(luò)運(yùn)營商將可靠性和穩(wěn)定性列為對(duì)網(wǎng)絡(luò)設(shè)備中最關(guān)注的方面。而Yankee Group的一份報(bào)告中也表明了相似的結(jié)果，在評(píng)分過程(1到10分)，運(yùn)營商將路由器的可靠性列為8.5分，而能夠?qū)崿F(xiàn)在線升級(jí)的能力列為8.75分。由此可見，是否具有高可用性已成為運(yùn)營商選擇設(shè)備的重要依據(jù)。
可用性的基本概念可用性并不是一個(gè)模糊的概念，實(shí)際上它能用數(shù)學(xué)方法來精確地表示。通常，可用性被定義為實(shí)際的服務(wù)時(shí)間和要求的服務(wù)時(shí)間的比值，常用百分比表示。簡單地講，一個(gè)高可用性系統(tǒng)就是一個(gè)用戶能隨時(shí)使用的系統(tǒng)，例如當(dāng)用戶需要在早上8點(diǎn)到下午5點(diǎn)啟用該系統(tǒng)時(shí)，該系統(tǒng)就應(yīng)該在這段時(shí)間內(nèi)保證良好的可用狀態(tài)，其余的時(shí)間可以用來進(jìn)行定期維修保養(yǎng)。許多電信級(jí)系統(tǒng)需要一天24小時(shí)、一年365天連續(xù)不間斷運(yùn)轉(zhuǎn)(有時(shí)也稱為7×24或365×24)。一個(gè)可用性為99.9％的365×24系統(tǒng)一年的平均故障時(shí)間為8.76小時(shí)(525分鐘)，而要想讓系統(tǒng)的中斷時(shí)間在一年中只有3分鐘的話，系統(tǒng)必須有99.999％的可用性，即在電信設(shè)備中通常所要求的5個(gè)9(Five Nine)的高可用性?？捎眯灾笜?biāo)可以利用所有系統(tǒng)軟硬件元件的統(tǒng)計(jì)模型計(jì)算出來，最簡單的元件模型是二元的，即元件要么處于工作狀態(tài)，要么處于非工作狀態(tài)?？捎眯钥梢杂檬蕘碛?jì)算，結(jié)果為平均無故障工作時(shí)間MTBF，也可以用故障修復(fù)時(shí)間來計(jì)算，結(jié)果為平均故障修復(fù)時(shí)間MTTR。將MTTR時(shí)間平均分?jǐn)偟組TBF周期內(nèi)可以計(jì)算出任意軟硬元件對(duì)平均故障的貢獻(xiàn)。例如，有一個(gè)對(duì)系統(tǒng)運(yùn)作至關(guān)重要的元件，它的MTBF時(shí)間為250,000小時(shí)，MTTR為1小時(shí)，則系統(tǒng)在一年中的不可用性時(shí)間為2.1分鐘(等于60(分鐘)×8760(小時(shí)/年)÷250,000(小時(shí)))。
高可用性的設(shè)計(jì)內(nèi)容高可用性的系統(tǒng)設(shè)計(jì)包括硬件支撐系統(tǒng)、硬件運(yùn)行系統(tǒng)和應(yīng)用軟件系統(tǒng)的高可用性，具體說明如下硬件外圍系統(tǒng)的高可用性這個(gè)層次包括機(jī)框、風(fēng)扇、電源和UPS等設(shè)備的高可用性。主要的措施是采用冗余電源和智能UPS系統(tǒng)等措施保證網(wǎng)絡(luò)設(shè)備硬件支撐系統(tǒng)的可靠工作。目前通常采用的是N∶1的電源模塊和風(fēng)扇單元。
硬件平臺(tái)系統(tǒng)的高可用性目前保證硬件運(yùn)行系統(tǒng)高可用性的主要措施也是采用冗余設(shè)計(jì)，通常包括1+1的主控處理器和交換單元，而在網(wǎng)絡(luò)接口卡上通常采用N∶1的備份方式。這樣，這樣在系統(tǒng)硬件出現(xiàn)故障時(shí)，備用(Backup)模塊可以接替原主用(Active)模塊繼續(xù)工作。
軟件系統(tǒng)的高可用性軟件系統(tǒng)的高可用性包括控制卡和線路卡上軟件的備份設(shè)計(jì)、主備倒換(Hot-swap)、故障檢測(Fault Detection)、系統(tǒng)容錯(cuò)(FaultTolerance)、在線升級(jí)(On-line Upgrade)和無中斷的業(yè)務(wù)轉(zhuǎn)發(fā)(Non-stopForwarding)等。
現(xiàn)有技術(shù)分析由以上分析可知，要提高系統(tǒng)的高可用性，必須使平均無故障工作時(shí)間(MTBF)盡量長，而平均故障修復(fù)時(shí)間(MTTR)盡量短。由于MTBF根據(jù)系統(tǒng)軟硬件的復(fù)雜度不同而不同，因此要使系統(tǒng)的可用性更高，必須要使MTTR盡量的小，即盡量使得系統(tǒng)從發(fā)現(xiàn)故障的發(fā)生到從故障中恢復(fù)的時(shí)間盡量的短。而本發(fā)明所要解決的也是如何盡量減少平均故障修復(fù)時(shí)間(MTTR)。
而平均故障修復(fù)時(shí)間(MTTR)是指從故障發(fā)生(出現(xiàn)軟硬件故障)，到故障恢復(fù)(數(shù)據(jù)網(wǎng)絡(luò)設(shè)備開始正常運(yùn)行業(yè)務(wù))，它主要由以下部分組成●故障檢測時(shí)間●異常處理的時(shí)間●加載以及啟動(dòng)備用板的時(shí)間●備用板恢復(fù)配置的時(shí)間●路由學(xué)習(xí)、聚合的時(shí)間從以上分析可以看出，提高系統(tǒng)的高可用性，關(guān)鍵在于兩方面，首先是必須要做到故障監(jiān)測(Fault Detection)時(shí)間要盡量的快，能夠達(dá)到秒級(jí)甚至毫秒級(jí)，其次是備用卡接替主用卡從啟動(dòng)、工作到網(wǎng)絡(luò)路由的收斂時(shí)間要盡量小。而前者取決于系統(tǒng)采用的故障檢測方式，而后者取決于系統(tǒng)采用的主備保護(hù)和恢復(fù)(Protection and Restoration)方式。而本發(fā)明正是從這兩方面實(shí)現(xiàn)設(shè)備的高可用性。而下文將分別從故障檢測以及保護(hù)和恢復(fù)方式兩方面對(duì)現(xiàn)有技術(shù)進(jìn)行分析故障檢測(Fault Detection)方法目前的技術(shù)方案中對(duì)故障檢測均采用了Heartbeat(心跳)或類似的機(jī)制。
具體實(shí)現(xiàn)如下首先，主用和備用之間通過定時(shí)器維護(hù)一定的Keepalive(保持存活)數(shù)據(jù)包(或其它功能相似的數(shù)據(jù)包)，如圖1所示。
如果某一端在一段時(shí)間內(nèi)沒有收到對(duì)方發(fā)過來的Keepalive包，則會(huì)Hold Timer定時(shí)器超時(shí)，這樣該節(jié)點(diǎn)就會(huì)認(rèn)為對(duì)端節(jié)點(diǎn)出現(xiàn)了故障。如圖2所示。
最后，當(dāng)前節(jié)點(diǎn)改變自己目前的狀態(tài)，并做相關(guān)的故障恢復(fù)處理。如果是主卡則通告?zhèn)溆每ㄊ?，如果是備用卡則將自己切換為主用卡的工作方式。如圖3所示。
優(yōu)缺點(diǎn)分析這種方法實(shí)現(xiàn)故障檢測，較為簡單可靠，但是存在著實(shí)時(shí)性較差的問題。由于采用了基于軟件的檢測方式，發(fā)現(xiàn)故障的時(shí)間往往較長，多為秒級(jí)，實(shí)時(shí)性較差而目前很多應(yīng)用需要對(duì)故障檢測的實(shí)時(shí)性較強(qiáng)，尤其網(wǎng)絡(luò)的核心節(jié)點(diǎn)對(duì)秒級(jí)的故障檢測時(shí)間是不允許的。
主備恢復(fù)和保護(hù)方式完全狀態(tài)同步(Full State Sync)所謂完全狀態(tài)復(fù)制的方法，是指在主用和備用之間維護(hù)完全的狀態(tài)同步。這種方式包括所有的上層協(xié)議狀態(tài)在主備之間完全的同步。如圖4，當(dāng)任何協(xié)議所需要同步的數(shù)據(jù)或狀態(tài)發(fā)生改變時(shí)，就會(huì)有更新消息從主用卡發(fā)送到備用卡。理論上說，如果采用完全的狀態(tài)同步，一旦主用卡軟硬件出現(xiàn)故障，備用卡可以接替并且不會(huì)對(duì)鄰居節(jié)點(diǎn)和網(wǎng)絡(luò)導(dǎo)致任何影響。
優(yōu)勢在出錯(cuò)時(shí)，這種方式對(duì)網(wǎng)絡(luò)導(dǎo)致的影響最小，并且所需的時(shí)間也最少。
可能存在的問題這種方式可能存在的最大問題是對(duì)路由協(xié)議等應(yīng)用帶來的性能上影響。為了實(shí)現(xiàn)主備之間完全同步，所有的同步必須是原子級(jí)的，這就意味著主用卡必須知道每一個(gè)信息被每一個(gè)備用卡正確接收并只處理一次。如果數(shù)據(jù)包被丟失，則會(huì)導(dǎo)致失步和不可預(yù)料性。
另一個(gè)問題是需要同步的數(shù)據(jù)量可能過于巨大，例如，對(duì)一個(gè)Internet的核心路由器來說，它需要維護(hù)數(shù)十萬條路由甚至上百萬條路由，如果在主備卡之間進(jìn)行完全同步，將可能導(dǎo)致系統(tǒng)資源的緊張(如對(duì)總線和背板)。因此，對(duì)于系統(tǒng)設(shè)計(jì)者來說，這種方式某種程度上來說缺少擴(kuò)展性。
實(shí)際應(yīng)用目前Alcatel公司和Avici公司采用了完全同步的方式，并應(yīng)用于其最高端的核心路由器中。
數(shù)據(jù)復(fù)制(Data Duplication)采用這種方式時(shí)，主用卡和備用卡會(huì)從同一時(shí)刻開始運(yùn)行相同的程序，兩個(gè)程序?qū)⑻幵谕耆嗤某跏紶顟B(tài)。而系統(tǒng)的底層負(fù)責(zé)將數(shù)據(jù)網(wǎng)絡(luò)設(shè)備所接收到的每一個(gè)數(shù)據(jù)包，發(fā)給主備卡同樣的一份拷貝(見圖5)。但是在發(fā)送方向，備用卡的OS(操作系統(tǒng))或協(xié)議棧則是簡單的將包丟棄，而主用卡可以將數(shù)據(jù)包發(fā)出。這種方法是基于以下考慮主用和備用從同樣的狀態(tài)啟動(dòng)，接收相同的輸入，按照相同的次序處理相同的事件和包，則可以在任何時(shí)刻維護(hù)相同的狀態(tài)。如果主用卡出現(xiàn)故障或備用卡檢測到一個(gè)內(nèi)部錯(cuò)誤，備用卡會(huì)迅速接管系統(tǒng)并開始正常工作，因?yàn)樗椭骺ǔ鲥e(cuò)前處在相同的狀態(tài)。
優(yōu)勢這種方法不需要對(duì)路由協(xié)議和其它應(yīng)用做任何改動(dòng)。
可能存在的問題由于這種方式要求主用和備用以相同的初始狀態(tài)啟動(dòng)并接收相同的輸入，因此它僅適合于主備同時(shí)啟動(dòng)的方式，并且中間不允許出現(xiàn)代碼更新、在線升級(jí)和卡的熱插拔。此外，由于主備控制卡采用同樣的鏡像、同樣的初始狀態(tài)和同樣的輸入，因此，如果主用卡出現(xiàn)故障，也將很有可能會(huì)導(dǎo)致備用卡出現(xiàn)相同的故障。
實(shí)際應(yīng)用由于這種方式存在明顯的缺陷，因此目前在HA Linux環(huán)境中有所應(yīng)用，并主要用于基于Linux的網(wǎng)絡(luò)應(yīng)用中(如Linux服務(wù)器群集)，而在商用的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備中使用較少。
協(xié)議擴(kuò)展(Protocol Extension)方式由于數(shù)據(jù)復(fù)制法無法解決主用和備用不同步時(shí)引起的問題，而狀態(tài)完全同步法盡管可以實(shí)現(xiàn)主用和備用之間的無縫切換，但是可能會(huì)導(dǎo)致主用和備用之間的通信量過大，因此，部分廠商采用了對(duì)現(xiàn)有的應(yīng)用協(xié)議進(jìn)行擴(kuò)展的方式，即采用Graceful Restart(平滑的重啟動(dòng))，并在IETF(因特網(wǎng)工程任務(wù)組)中對(duì)其進(jìn)行了標(biāo)準(zhǔn)化。這種方法的關(guān)鍵在于，當(dāng)網(wǎng)絡(luò)設(shè)備正常工作時(shí)，其對(duì)等節(jié)點(diǎn)和其主用控制單元建立起連接關(guān)系，并進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，如圖6所示。
發(fā)生主備倒換時(shí)，其對(duì)等節(jié)點(diǎn)將清除原有和主用之間連接，并和備用控制單元重新建立起會(huì)話關(guān)系，幫助系統(tǒng)的控制平面重新獲得失去的路由信息(圖7)。
但和普通的重啟動(dòng)不同，進(jìn)行Graceful Restart時(shí)，對(duì)等節(jié)點(diǎn)并不認(rèn)為該節(jié)點(diǎn)失效，并保留和該節(jié)點(diǎn)相關(guān)的路由消息，這樣，網(wǎng)絡(luò)上的其他節(jié)點(diǎn)并不認(rèn)為該節(jié)點(diǎn)失效，可以繼續(xù)向其轉(zhuǎn)發(fā)流量(見圖8)。
但需要注意的是，網(wǎng)絡(luò)設(shè)備必須采用控制平面和數(shù)據(jù)轉(zhuǎn)發(fā)平面分離的數(shù)據(jù)結(jié)構(gòu)，這樣在Graceful Restart的過程中，才能保證轉(zhuǎn)發(fā)平面還能繼續(xù)轉(zhuǎn)發(fā)流量。
以下將以路由器上的BGP(邊界網(wǎng)關(guān)協(xié)議)協(xié)議為例，來詳細(xì)介紹這種方法。
當(dāng)BGP和它的對(duì)等體建立起連接時(shí)，將會(huì)開始Graceful Restart能力協(xié)商，它們通過在交換BGP的Open消息中來通告給對(duì)端具有Graceful Restart的能力。此時(shí)，它將通告給它的對(duì)等體它能夠維護(hù)轉(zhuǎn)發(fā)信息的協(xié)議列表，如Ipv4、Ipv6或MPLS(多協(xié)議標(biāo)記交換)轉(zhuǎn)發(fā)。
當(dāng)路由器進(jìn)行主備倒換時(shí)，對(duì)等體和路由器的TCP連接將會(huì)被清除。通常，這會(huì)導(dǎo)致對(duì)端路由器清除和正在倒換路由器的相關(guān)所有路由，并通告給網(wǎng)絡(luò)上其它節(jié)點(diǎn)該節(jié)點(diǎn)失效，這樣就會(huì)導(dǎo)致網(wǎng)絡(luò)流量的中斷或者路由的重新學(xué)習(xí)收斂。而具有Graceful Restart能力的路由器，此時(shí)將所有和該路由器相關(guān)的路由置為“Stale(失效)”，但是繼續(xù)使用這些路由進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)。
當(dāng)路由器完成主備倒換后，備用卡(新主用卡)將和它的對(duì)等體重新建立Peer(對(duì)等)關(guān)系，此時(shí)，它的所有對(duì)等體將會(huì)把BGP相關(guān)的路由信息庫RIB發(fā)給它，當(dāng)完成所有的路由更新后，它的對(duì)等體將會(huì)發(fā)送End of RIB(EOR)標(biāo)識(shí)來通告它，路由重新學(xué)習(xí)完畢。當(dāng)路由器從所有的Peer中都收到EOR包后，它就知道網(wǎng)絡(luò)路由收斂已經(jīng)完成，然后開始重新進(jìn)行正常的最佳路由選擇。
優(yōu)勢這種方法開銷較小，且具有較高的可擴(kuò)展性。
可能存在的問題這種協(xié)議擴(kuò)展方式必須在數(shù)據(jù)網(wǎng)絡(luò)設(shè)備以及它的對(duì)等節(jié)點(diǎn)上同時(shí)使用，若對(duì)端節(jié)點(diǎn)不支持Graceful，則無法采用。因此，僅僅采用協(xié)議擴(kuò)展方式是無法實(shí)現(xiàn)在各種復(fù)雜網(wǎng)絡(luò)環(huán)境中的高可用性的。
實(shí)際應(yīng)用由于該方式具有較強(qiáng)的可擴(kuò)展性，因此目前Cisco Networks公司和Juniper Networks公司的高端產(chǎn)品均采用這種方式。

發(fā)明內(nèi)容
由于現(xiàn)有的技術(shù)方案存在種種缺陷，因此本文提出一種全新的技術(shù)方案。首先在故障檢測上，它采用了軟硬件結(jié)合的方式對(duì)故障進(jìn)行檢測和定位，而在主備保護(hù)和恢復(fù)上采用了一種全新的自適應(yīng)的技術(shù)方案。
具體說來，就是在故障檢測的過程中，既保留了傳統(tǒng)的心跳(heartbeat)機(jī)制，通過軟件方式進(jìn)行檢測對(duì)方是否工作正常，同時(shí)，由一個(gè)系統(tǒng)硬件管理(Hardware Manager)進(jìn)程通過背板上的硬件管理信號(hào)對(duì)熱插拔或硬件故障等做出實(shí)時(shí)響應(yīng)。和傳統(tǒng)方案相比，本發(fā)明大大提高了故障檢測的速度和精度。
而在主備保護(hù)和恢復(fù)的方案中，本發(fā)明所提出的自適應(yīng)方案可以根據(jù)設(shè)備上的具體工作模式不同，采用不同的技術(shù)方案，即如果設(shè)備工作在非路由信令模式(不運(yùn)行路由和信令協(xié)議，但可以運(yùn)行靜態(tài)路由和二層協(xié)議)下，采用一種輕量級(jí)(Light-weight Level)的部分同步(Part Sync)方式，即實(shí)現(xiàn)主備用節(jié)點(diǎn)的配置消息(包括運(yùn)行的配置文件和存儲(chǔ)在存儲(chǔ)器上的初始配置文件)和路由轉(zhuǎn)發(fā)消息的同步，這樣，在不引入額外的信令和增加系統(tǒng)負(fù)擔(dān)的情況下，實(shí)現(xiàn)了系統(tǒng)的高可用性。如果網(wǎng)絡(luò)設(shè)備的方式為路由信令模式(需要運(yùn)行路由協(xié)議或MPLS信令)時(shí)，則在設(shè)備在和對(duì)等體建立連接時(shí)，首先判斷對(duì)方是否具備路由信令的協(xié)議擴(kuò)展能力，如果具備則采用了協(xié)議擴(kuò)展方式進(jìn)行保護(hù)，如果沒有則采用完全狀態(tài)同步的方式進(jìn)行保護(hù)。
這種方式靈活地根據(jù)網(wǎng)絡(luò)設(shè)備的不同工作模式采用不同的保護(hù)恢復(fù)方式。尤其是當(dāng)網(wǎng)絡(luò)設(shè)備工作在非路由信令模式時(shí)，由于采用了一種輕量級(jí)的部分同步的備份方式，避免了系統(tǒng)的內(nèi)部資源的耗費(fèi)和負(fù)擔(dān)，也不需要引入新的協(xié)議，大大減輕了系統(tǒng)設(shè)計(jì)者的負(fù)擔(dān)，并提高了數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的工作效率。而當(dāng)工作在路由信令模式下時(shí)，同樣也不是簡單地采用協(xié)議擴(kuò)展或者是完全狀態(tài)同步的方式，而是首先根據(jù)設(shè)備的對(duì)端節(jié)點(diǎn)是否具有協(xié)議擴(kuò)展能力來決定采用何種工作方式，這樣就使得本發(fā)明方案更加靈活和具有擴(kuò)展性。
根據(jù)本發(fā)明的一個(gè)方面，提供了一種數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備具有主用裝置和備用裝置，該方法包括檢測該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備是在非路由信令模式下運(yùn)行還是在路由信令模式下運(yùn)行；如果該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備在非路由信令模式下運(yùn)行，則采用部分同步方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；如果該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備在路由信令模式下運(yùn)行，則檢測與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)钠渌鼣?shù)據(jù)網(wǎng)絡(luò)設(shè)備是否都具備協(xié)議擴(kuò)展功能，如果與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)墓?jié)點(diǎn)都具備協(xié)議擴(kuò)展功能，則采用協(xié)議擴(kuò)展方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；否則，采用狀態(tài)完全同步方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)。
根據(jù)本發(fā)明的另一個(gè)方面，提供了一種與其它節(jié)點(diǎn)進(jìn)行數(shù)據(jù)傳輸?shù)臄?shù)據(jù)網(wǎng)絡(luò)設(shè)備，包括至少一個(gè)主用裝置和至少一個(gè)備用裝置，所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備包括工作模式獲取裝置，用于獲取該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的工作模式；協(xié)議擴(kuò)展功能判斷裝置，用于判斷與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)钠渌?jié)點(diǎn)是否都具有協(xié)議擴(kuò)展功能；保護(hù)方式確定裝置，根據(jù)所述工作模式獲取裝置所獲取的工作模式和所述協(xié)議擴(kuò)展功能判斷裝置的判斷結(jié)果，確定以何種方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；部分同步保護(hù)裝置，以部分同步方式執(zhí)行所述保護(hù)和恢復(fù)；協(xié)議擴(kuò)展保護(hù)裝置，以協(xié)議擴(kuò)展方式執(zhí)行所述保護(hù)和恢復(fù)；狀態(tài)完全同步保護(hù)裝置，以狀態(tài)完全同步方式執(zhí)行所述保護(hù)和恢復(fù)，其中，如果所述工作模式為非路由信令模式，則所述保護(hù)方式確定裝置確定由部分同步保護(hù)裝置執(zhí)行所述保護(hù)和恢復(fù)，如果所述工作模式為路由信令模式，則保護(hù)方式確定裝置指示所述協(xié)議擴(kuò)展功能判斷裝置執(zhí)行所述判斷，如果判定所述其它節(jié)點(diǎn)都具備協(xié)議擴(kuò)展功能，則所述保護(hù)方式確定裝置確定由協(xié)議擴(kuò)展保護(hù)裝置執(zhí)行所述保護(hù)和恢復(fù)，如果判定所述其它節(jié)點(diǎn)并不都具有協(xié)議擴(kuò)展功能，則所述保護(hù)方式確定裝置確定由狀態(tài)完全同步保護(hù)裝置執(zhí)行所述保護(hù)和恢復(fù)。
因此，本發(fā)明實(shí)現(xiàn)了一種在數(shù)據(jù)網(wǎng)絡(luò)設(shè)備上實(shí)現(xiàn)高可用性(HighAvailability)的方法，它在故障檢測上不同于傳統(tǒng)的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備中所采用基于軟件的故障檢測方式，而是采用了軟件和硬件相結(jié)合的方式，提高了故障檢測的速度和精度；而在主備保護(hù)和恢復(fù)的方式上，也不同于以往設(shè)備所采用的單一的協(xié)議擴(kuò)展(Protocol Extension)或是完全狀態(tài)同步(Full State Sync)的方式，而是采用了一種自適應(yīng)(Self-Adaptive)的主備保護(hù)和恢復(fù)方式，即根據(jù)數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的實(shí)際運(yùn)行狀態(tài)來采用不同的備份方式。具體說來，當(dāng)設(shè)備運(yùn)行在非路由信令模式時(shí)，采用一種輕量級(jí)(Light-weight Level)的部分同步(Part Sync)的方式，而運(yùn)行在路由信令模式時(shí)，它將首先判斷鄰接節(jié)點(diǎn)是否都具備協(xié)議擴(kuò)展功能，如果具備則采用協(xié)議擴(kuò)展方式進(jìn)行主備保護(hù)，否則才采用狀態(tài)完全同步方式。由于采用了自適應(yīng)的方式進(jìn)行保護(hù)，本發(fā)明可以靈活地根據(jù)不同的應(yīng)用環(huán)境采用最合適的方式，和現(xiàn)有的方式相比，使得系統(tǒng)開銷更小、適用的環(huán)境更廣，且靈活性更高，并具有更快的故障檢測速度，因此大大提高了設(shè)備的高可用性。本發(fā)明適用于目前和未來的寬帶Ipv4和Ipv6網(wǎng)絡(luò)中的接入層、匯聚層和骨干層等二三層路由交換設(shè)備，也適用于無線分組網(wǎng)中的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備。


圖1是示出心跳機(jī)制下主用處理器和備用處理器交換Keepalive(保持存活)消息的示意圖；
圖2是示出心跳機(jī)制下Hold Timer定時(shí)器超時(shí)表明對(duì)端節(jié)點(diǎn)出現(xiàn)故障的示意圖；圖3是示出心跳機(jī)制下的狀態(tài)跳轉(zhuǎn)的示意圖；圖4是示出完全狀態(tài)同步方式的示意圖；圖5是示出數(shù)據(jù)復(fù)制方式的示意圖；圖6是示出協(xié)議擴(kuò)展方式下的正常操作的示意圖；圖7是示出協(xié)議擴(kuò)展方式下的平滑重啟動(dòng)的示意圖；圖8是示出協(xié)議擴(kuò)展方式下平滑重啟動(dòng)時(shí)不停止轉(zhuǎn)發(fā)的示意圖；圖9是示出根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備中有關(guān)管理控制的主要組件的方框圖；圖10是示出根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法的流程圖；圖11是說明路由協(xié)議將生成的路由轉(zhuǎn)發(fā)消息存放入路由消息庫(RoutingInformation Base)并同步到轉(zhuǎn)發(fā)單元上的示意圖；圖12是示出采用本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的示例的框圖；圖13是示出采用本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的示例中與本發(fā)明相關(guān)的主要模塊的方框圖；圖14是示出協(xié)議相關(guān)單元的功能的示意圖；圖15是示出部分同步方式的示意圖；圖16是采用本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備上的示例數(shù)據(jù)流圖；圖17是采用本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的示例邏輯方框圖；以及圖18是示出線路轉(zhuǎn)發(fā)卡的結(jié)構(gòu)的邏輯方框圖。
具體實(shí)施例方式
下面參考附圖描述根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備及其管理控制方法。
圖9示出了根據(jù)本發(fā)明的與其它節(jié)點(diǎn)進(jìn)行數(shù)據(jù)傳輸?shù)臄?shù)據(jù)網(wǎng)絡(luò)設(shè)備中與管理控制相關(guān)的主要組件。本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備包括至少一個(gè)主用裝置和至少一個(gè)備用裝置(未示出)。如圖9所示，根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備包括工作模式獲取裝置10，用于獲取該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的工作模式；協(xié)議擴(kuò)展功能判斷裝置30，用于判斷與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)钠渌?jié)點(diǎn)是否都具有協(xié)議擴(kuò)展功能；保護(hù)方式確定裝置20，根據(jù)工作模式獲取裝置10所獲取的工作模式和協(xié)議擴(kuò)展功能判斷裝置30的判斷結(jié)果，確定以何種方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；部分同步保護(hù)裝置40，以部分同步方式執(zhí)行保護(hù)和恢復(fù)；狀態(tài)完全同步保護(hù)裝置50，以狀態(tài)完全同步方式執(zhí)行保護(hù)和恢復(fù)；以及協(xié)議擴(kuò)展保護(hù)裝置60，以協(xié)議擴(kuò)展方式執(zhí)行保護(hù)和恢復(fù)。
下面參考圖10描述根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法。
在數(shù)據(jù)網(wǎng)絡(luò)設(shè)備運(yùn)行過程中，在步驟S1，由工作模式獲取裝置10獲取該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的工作模式。如果工作模式為非路由信令模式，則進(jìn)入步驟S2，保護(hù)方式確定裝置20確定由部分同步保護(hù)裝置40以部分同步方式執(zhí)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)。如果工作模式為路由信令模式，則進(jìn)入步驟S3，保護(hù)方式確定裝置20指示協(xié)議擴(kuò)展功能判斷裝置30判斷與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)钠渌徑庸?jié)點(diǎn)是否都具備協(xié)議擴(kuò)展功能。如果判定其它鄰接節(jié)點(diǎn)都具有協(xié)議擴(kuò)展功能，則進(jìn)入步驟S4，保護(hù)方式確定裝置20確定由協(xié)議擴(kuò)展保護(hù)裝置60以協(xié)議擴(kuò)展方式執(zhí)行保護(hù)和恢復(fù)。如果判定其它鄰接節(jié)點(diǎn)并不都具有協(xié)議擴(kuò)展功能，則進(jìn)入步驟S5，保護(hù)方式確定裝置20確定由狀態(tài)完全同步保護(hù)裝置50執(zhí)行保護(hù)和恢復(fù)。
根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備還可以包括故障檢測模塊(圖9中未示出)，用于檢測數(shù)據(jù)網(wǎng)絡(luò)設(shè)備中的故障。本發(fā)明的故障檢測模塊通過軟件和硬件相結(jié)合的方式進(jìn)行故障檢測，因此該故障檢測模塊包括心跳機(jī)制模塊(圖9中未示出)，用于在主用裝置和備用裝置之間周期性地交換保持存活消息，當(dāng)主用裝置和備用裝置之一在預(yù)定時(shí)間內(nèi)沒有收到來自主用裝置和備用裝置中另一個(gè)裝置的保持存活消息時(shí)，確定所述另一個(gè)裝置發(fā)生故障；硬件管理器(圖9中未示出)，通過實(shí)時(shí)中斷方式或定時(shí)輪詢方式對(duì)硬件信號(hào)進(jìn)行監(jiān)視，以確定主用裝置和備用裝置是否在位、是否出現(xiàn)故障。
根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備還包括故障處理裝置(圖9中未示出)，其接收故障檢測模塊所通告的故障，并進(jìn)行相應(yīng)的故障處理，其中，當(dāng)檢測到主用裝置發(fā)生故障時(shí)，故障處理裝置將備用裝置切換為新主用裝置，并接替原主用裝置的工作；當(dāng)檢測到備用裝置發(fā)生故障時(shí)，故障處理裝置進(jìn)行相應(yīng)的故障恢復(fù)操作，并停止對(duì)備用裝置的同步和更新。
根據(jù)本發(fā)明的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備還可以包括動(dòng)態(tài)更新裝置和批量更新裝置(圖9中均未示出)。在正常工作時(shí)，由動(dòng)態(tài)更新裝置對(duì)備用裝置進(jìn)行動(dòng)態(tài)更新。而在主用裝置發(fā)現(xiàn)備用裝置剛啟動(dòng)時(shí)，由批量更新裝置執(zhí)行批量更新。
上述主用裝置和備用裝置可以分別是數(shù)據(jù)網(wǎng)絡(luò)設(shè)備(如路由器)中運(yùn)行協(xié)議的主用部件和備用部件。
本發(fā)明對(duì)系統(tǒng)硬件體系結(jié)構(gòu)有以下要求1.采用轉(zhuǎn)發(fā)和控制分離的體系結(jié)構(gòu)。因?yàn)槿绻趯?shí)現(xiàn)熱倒換的過程中，用戶的業(yè)務(wù)不會(huì)有任何丟失，必須將系統(tǒng)控制功能和高速轉(zhuǎn)發(fā)功能分離。
2.系統(tǒng)控制單元上統(tǒng)一維護(hù)路由轉(zhuǎn)發(fā)消息，而接口卡上保存轉(zhuǎn)發(fā)消息庫。
3.至少有兩塊系統(tǒng)控制卡，即要實(shí)現(xiàn)高可用性，必須在控制功能上實(shí)現(xiàn)硬件的冗余。
4.系統(tǒng)控制總線上提供硬件的系統(tǒng)管理功能，能夠?qū)τ布牟灏魏凸收线M(jìn)行監(jiān)視，并能通過中斷或輪詢方式進(jìn)行管理。
5.關(guān)鍵的部分，如交換單元、控制卡、電源和風(fēng)扇等采用1+1、1∶1或1∶N的備份。
圖11中說明了路由協(xié)議將生成的路由轉(zhuǎn)發(fā)消息存放入路由消息庫(Routing Information Base)，并同步到轉(zhuǎn)發(fā)單元上去。
圖12示出了典型的采用本發(fā)明方案的高可用性數(shù)據(jù)網(wǎng)絡(luò)設(shè)備，它采用了一主一備的控制卡，并且將轉(zhuǎn)發(fā)和控制功能分離，每一個(gè)線卡維護(hù)系統(tǒng)的轉(zhuǎn)發(fā)消息庫。
下面說明本發(fā)明的功能模塊。
圖13為本發(fā)明的功能模塊結(jié)構(gòu)圖，它包括以下模塊1.故障檢測模塊(Fault Detection Module，F(xiàn)DM)其中故障檢測模塊又分為兩部分即HBM(heart-beat module，心跳機(jī)制模塊)和HM(Hard-ware Manager，硬件管理器)，分別用來用軟件和硬件的方式來檢測產(chǎn)生的錯(cuò)誤。
2.容錯(cuò)模塊(Fault Tolerance Module，F(xiàn)TM)本發(fā)明的核心部分，實(shí)現(xiàn)自適應(yīng)地選擇保護(hù)和恢復(fù)方式，完成和其他模塊的接口，并根據(jù)其他模塊的輸入確定系統(tǒng)的工作模式，并決定系統(tǒng)的同步和更新方式。
3.協(xié)議相關(guān)單元(Protocol Specific Element，PSE)提供和協(xié)議(路由和信令協(xié)議)相關(guān)的狀態(tài)同步部分，每一個(gè)應(yīng)用協(xié)議對(duì)應(yīng)不同的協(xié)議相關(guān)單元。
4.介質(zhì)相關(guān)的通信模塊(Media-dependent Communication Module，MCM)提供主備控制卡之間的通信通道，提供庫函數(shù)為上層協(xié)議提供調(diào)用。它的底層通信介質(zhì)可以是任何系統(tǒng)內(nèi)部通信總線，如Ethernet、PCI、大容量的交換結(jié)構(gòu)Switch Fabric或者用戶自定義的私有總線等。
5.系統(tǒng)管理單元(System Manager)系統(tǒng)中的協(xié)議管理模塊，提供SNMP(簡單網(wǎng)絡(luò)管理協(xié)議)、CLI(命令行接口)和基于Web的多種管理方式，并能控制系統(tǒng)當(dāng)前的工作模式。
其中，圖9所示的工作模式獲取裝置10可以由圖13中的系統(tǒng)管理單元SM實(shí)現(xiàn)，保護(hù)方式確定裝置20、部分同步保護(hù)裝置40、狀態(tài)完全同步保護(hù)裝置50可以由容錯(cuò)模塊FTM實(shí)現(xiàn)，協(xié)議擴(kuò)展功能判斷裝置30可以由容錯(cuò)模塊FTM結(jié)合系統(tǒng)管理單元SM實(shí)現(xiàn)，而協(xié)議擴(kuò)展保護(hù)裝置60可以由協(xié)議相關(guān)單元PSE結(jié)合容錯(cuò)模塊FTM實(shí)現(xiàn)。
由于MCM模塊和SM模塊和具體平臺(tái)相關(guān)，因此本發(fā)明只需對(duì)其基本功能和接口進(jìn)行要求。而下文將對(duì)前三個(gè)模塊的具體組成和功能進(jìn)行具體說明。
一.Heartbeat模塊Heartbeat模塊實(shí)現(xiàn)的功能和實(shí)現(xiàn)如下1.主用和備用之間周期性交換消息Keepalive(保持存活)消息，并啟動(dòng)Hold timer定時(shí)器。備用節(jié)點(diǎn)上的Heartbeat模塊周期性發(fā)送Keepalive消息給主卡上的Heartbeat模塊。主用卡同時(shí)響應(yīng)一個(gè)Keepalive消息。
2.如果主用卡上的Heartbeat模塊的Hold Timer定時(shí)器超時(shí)，即說明在一個(gè)可配置的周期內(nèi)沒有收到備用Heartbeat模塊的Keepalive包，它會(huì)通告FTM模塊，進(jìn)行故障恢復(fù)操作(將不在進(jìn)行主備之間的動(dòng)態(tài)更新)。
3.如果備用卡的Heartbeat模塊的Hold Timer定時(shí)器超時(shí)，即說明在一個(gè)可配置周期內(nèi)沒有收到主用Heartbeat模塊的HB-Reply包，它就會(huì)通告FTM模塊進(jìn)行故障處理，并將自己從備用切換至主用狀態(tài)。
二.硬件管理器(Hardware Manager)HM所實(shí)現(xiàn)的功能和實(shí)現(xiàn)如下1.系統(tǒng)的背板通過Present#信號(hào)來反映系統(tǒng)中的各個(gè)電路板是否在位。
2.系統(tǒng)的背板通過Alarm#和Health#信號(hào)來反映各個(gè)電路板是否出現(xiàn)硬件故障。
3.HM通過實(shí)時(shí)中斷方式或定時(shí)輪詢方式對(duì)Present#、Alarm#和Health#進(jìn)行監(jiān)視。
4.HM通過以上機(jī)制一旦發(fā)現(xiàn)系統(tǒng)中出現(xiàn)熱插拔或硬件平臺(tái)出現(xiàn)故障，立即通告給容錯(cuò)模塊(FTM)，進(jìn)行相應(yīng)的故障恢復(fù)和處理。
三.協(xié)議相關(guān)單元(PSE，Protocol Specific Function)PSF是由每一個(gè)具有高可用性功能的協(xié)議所提供的。每一個(gè)協(xié)議有不同的PSF。當(dāng)協(xié)議單元和PSF模塊一起使用時(shí)，該協(xié)議就具備了在HA的功能，見圖14所示。
PSE的具體功能和實(shí)現(xiàn)如下1.PSE僅和每個(gè)具體協(xié)議相關(guān)，它維護(hù)每個(gè)協(xié)議中需要倒換的狀態(tài)消息，既要保證足以實(shí)現(xiàn)主用和備用之間的同步，同時(shí)又要做到以不犧牲系統(tǒng)性能為代價(jià)。
2.當(dāng)協(xié)議層內(nèi)部狀態(tài)發(fā)生變化時(shí)，主用卡上的PSE單元，產(chǎn)生并通過FTM發(fā)送更新(Update)消息到備用的相對(duì)應(yīng)的協(xié)議單元。
3.備用卡上的PSE單元從FTM接受到Update消息，并改變內(nèi)部協(xié)議的數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)和主用卡上的PSF單元的同步。
4.每一更新消息的操作必須保證是原子操作，并且必須獲得確認(rèn)。
四.容錯(cuò)FTM模塊FTM是本發(fā)明的核心部分，它通過和其他模塊的接口，實(shí)現(xiàn)自適應(yīng)地選擇保護(hù)和恢復(fù)方式，提供多種消息同步和更新方式，并根據(jù)其他模塊的輸入確定系統(tǒng)的工作模式。
具體功能和實(shí)現(xiàn)如下(一)、和SM模塊接口，獲取系統(tǒng)目前的工作模式，以確定系統(tǒng)目前所采用的保護(hù)和恢復(fù)方式。具體選擇的算法如下如果從SM接口中知道設(shè)備工作在非路由信令模式(不運(yùn)行路由和信令協(xié)議，但可以運(yùn)行靜態(tài)路由和二層協(xié)議)時(shí)，則采用一種輕量級(jí)(Light-weightLevel)的部分同步(Part Sync)方式，即實(shí)現(xiàn)主備用節(jié)點(diǎn)的配置消息(包括運(yùn)行的配置文件和存儲(chǔ)在存儲(chǔ)器上的初始配置文件)和路由轉(zhuǎn)發(fā)消息的同步。否則，若網(wǎng)絡(luò)設(shè)備的工作模式為路由信令模式，需要運(yùn)行路由協(xié)議或MPLS信令時(shí)，則在設(shè)備和對(duì)等體建立連接時(shí)，首先根據(jù)SM中的消息判斷對(duì)方是否具備路由信令的協(xié)議擴(kuò)展能力，如果具備則采用了協(xié)議擴(kuò)展方式進(jìn)行保護(hù)，否則沒有，則采用完全狀態(tài)同步的方式進(jìn)行保護(hù)。
(二)、接收FDM所通告的軟硬件故障，并針對(duì)不同類型的故障進(jìn)行處理。如果是主用模塊發(fā)生故障，備用模塊切換為主用并接替主用的工作；如果是備用模塊發(fā)生故障，則主用模塊進(jìn)行相應(yīng)的故障恢復(fù)(如復(fù)位備用卡)，并停止主備之間的更新。此外，針對(duì)軟硬件方式通告的故障，可以靈活地選擇不同的優(yōu)先處理方式，即可以優(yōu)先處理軟件通告故障，也可以優(yōu)先處理硬件通告的故障。
(三)、和MCM單元提供接口完成同步信息的發(fā)送，并提供多種消息同步和更新方式。具體說明如下其中，F(xiàn)TM提供兩種同步方式部分同步(Part Sync)和完全狀態(tài)同步(FullState Sync)，它由系統(tǒng)的工作模式?jīng)Q定。當(dāng)工作在完全狀態(tài)同步時(shí)，協(xié)議狀態(tài)發(fā)生任何變化時(shí)，均需要進(jìn)行同步，具體內(nèi)容由每一個(gè)PSE模塊提供(參見圖4和圖14)。而采用部分同步時(shí)，如圖15，主用和備用之間不需要同步所有的狀態(tài)消息，而只需在主用上配置和管理消息發(fā)生改變，或者路由消息發(fā)生改變時(shí)，才需要同步配置消息和路由消息庫(RIB)。由于保證了配置消息和路由轉(zhuǎn)發(fā)消息的同步，備用卡在主備切換時(shí)，仍能正常的進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，并且和完全狀態(tài)同步相比，不增加過多的系統(tǒng)負(fù)擔(dān)，也不需要引入額外的信令，是一種輕量級(jí)(Light-weight Level)的解決方案。
另外，在協(xié)議擴(kuò)展方式下，不需要專用的同步模塊；其同步的信息由PSE和FTM結(jié)合使用。
而FTM的更新方式也分為兩種，動(dòng)態(tài)更新(Dynamic Update)和批量更新(Bulk Update)，分別運(yùn)用于系統(tǒng)運(yùn)行的不同狀態(tài)。
動(dòng)態(tài)更新是指在正常工作時(shí)備用卡和主用卡在工作正常時(shí)保持同步。具體步驟如下1.當(dāng)主用卡檢測到內(nèi)部明顯的狀態(tài)變化時(shí)，它將構(gòu)造Update消息，并通過MCM模塊發(fā)送到備用卡。此時(shí)，它將保持現(xiàn)有狀態(tài)，直到它收到備用的確認(rèn)后。
2.如果備用卡從MCM模塊收到Update消息，則修改自己內(nèi)部相應(yīng)的協(xié)議和管理狀態(tài)，并向主用卡進(jìn)行確認(rèn)。
3.主用卡如果收到備用卡對(duì)于Update消息的確認(rèn)，則進(jìn)行新的操作，否則主用的FTM將會(huì)給出一個(gè)錯(cuò)誤的信號(hào)，而對(duì)這個(gè)錯(cuò)誤的處理將是和具體的PSE相關(guān)。
4.這樣的話，主用和備用之間將會(huì)在每一個(gè)復(fù)制操作完成后，保持同步，并且保證了每一個(gè)同步為原子操作。
批量更新的原理和上述過程類似，但它是發(fā)生在主用卡發(fā)現(xiàn)備用板啟動(dòng)之后。由于此時(shí)主用板和備用板之間的狀態(tài)差異可以非常大，F(xiàn)TM將在這期間集中進(jìn)行主用和備用之間的數(shù)據(jù)同步，以達(dá)到主備之間數(shù)據(jù)迅速一致的目的。完成備用更新后，系統(tǒng)將重新進(jìn)行動(dòng)態(tài)更新的過程。
動(dòng)態(tài)更新和批量更新的內(nèi)容將由系統(tǒng)采用的保護(hù)和恢復(fù)方式?jīng)Q定，如果采用完全同步則需要同步所有的協(xié)議狀態(tài)，否則只需要同步路由轉(zhuǎn)發(fā)消息和配置管理消息。
(四)、FTM還決定主備之間所采用的備份方式。通常有兩種備份方式熱備份和冷備份。冷備份時(shí)，主用與備用之間并不進(jìn)行運(yùn)行狀態(tài)和與運(yùn)行數(shù)據(jù)的同步，并且協(xié)議也不進(jìn)行完全地初始化，這樣發(fā)生主備倒換時(shí)，備用需要重新啟動(dòng)協(xié)議，并重新學(xué)習(xí)狀態(tài)；而熱備份時(shí)，則要求主用和備用維護(hù)相同的協(xié)議狀態(tài)，并運(yùn)行同樣的進(jìn)程。顯然，冷備份無法實(shí)現(xiàn)99.999％的高可用性，故在本發(fā)明中FTM采用熱備份的方式。
下面參考圖16描述本發(fā)明的典型數(shù)據(jù)流圖。
如圖16所示，示出了一個(gè)典型的數(shù)據(jù)流圖，具體說明如下1.主用卡初始化成功，F(xiàn)TM判斷系統(tǒng)中有無其他控制卡，若無則將自己置為主用模式，若有則通過HBM模塊和另外的控制卡進(jìn)行主備協(xié)商，確定主備，并開始Heartbeat通信，而協(xié)議相關(guān)單元完成在FTM模塊的通信庫函數(shù)注冊。
2.主用卡上的FTM通過和管理單元(SM)接口，判斷目前協(xié)議棧的運(yùn)行情況，如果工作在非路由信令模式，則FTM工作在部分同步(Part-SyncMode)模式；如果工作在路由信令模式，則首先判斷鄰居節(jié)點(diǎn)是否支持協(xié)議擴(kuò)展(Protocol Extension Mode)功能，如果是，則FTM工作在協(xié)議擴(kuò)展模式；如果否，則工作在完全同步方式(Full-Sync Mode)；3.備用卡初始化成功后，判斷系統(tǒng)中是否有其他控制卡，如果沒有則將自己置為主用模式；否則，則同步HBM模塊和主用卡通信，并請(qǐng)求批量更新(Bulk-Update Request)。
4.主用卡收到批量同步請(qǐng)求后，開始進(jìn)行批量更新操作，將通過批量更新消息，將所需同步的消息(具體同步內(nèi)容由FTM的工作模式?jīng)Q定)發(fā)送到備用卡，而備用卡收到每一個(gè)消息，將進(jìn)行確認(rèn)，直至結(jié)束。如果是部分同步模式下，只需同步配置管理消息和路由轉(zhuǎn)發(fā)表目；而在完全同步時(shí)，需要同步和每個(gè)協(xié)議相關(guān)的狀態(tài)消息。
5.完成批量更新后，主用備用之間開始動(dòng)態(tài)更新過程。動(dòng)態(tài)更新的內(nèi)容包括4中所涉及的內(nèi)容。需要注意的是，如果工作在完全同步模式時(shí)，必須在前一個(gè)更新消息得到確認(rèn)后，主用才能處理狀態(tài)同步過程。
6.FDM通過軟硬件兩種方式來監(jiān)視系統(tǒng)硬件的狀態(tài)，如果出現(xiàn)Hold Timer超時(shí)，或者系統(tǒng)的硬件管理總線產(chǎn)生硬件故障中斷或告警，F(xiàn)DM將通告FTM，并開始故障恢復(fù)過程。
7.如果是備用發(fā)生故障，主用停止和備用的Heartbeat過程，同時(shí)產(chǎn)生網(wǎng)管系統(tǒng)告警。而如果主用發(fā)生故障，則備用進(jìn)行故障恢復(fù)過程。如果FTM工作在部分同步和完全同步模式，則備用只需要接替系統(tǒng)的管理權(quán)即可；而如果FTM工作在協(xié)議擴(kuò)展模式下，備用則需要首先接替系統(tǒng)管理權(quán)，然后和鄰居重新建立起鄰接關(guān)系，并完成協(xié)議狀態(tài)同步。換句話說，在協(xié)議擴(kuò)展方式下，當(dāng)主用設(shè)備出現(xiàn)故障時(shí)，備用設(shè)備使用原有的路由信息進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)；而當(dāng)備用設(shè)備重新和對(duì)端節(jié)點(diǎn)建立起鄰接關(guān)系后，才使用新學(xué)習(xí)的的路由信息的轉(zhuǎn)發(fā)。
下面描述本發(fā)明的上述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的應(yīng)用實(shí)例，即在武漢烽火網(wǎng)絡(luò)公司的MAISP-8000上的具體應(yīng)用。
武漢烽火網(wǎng)絡(luò)公司研制的MAISP-8000是定位于城域網(wǎng)匯聚層和主干層的路由交換設(shè)備，它支持多種接口種類和具有靈活的業(yè)務(wù)生成能力。當(dāng)MAISP-8000定位于城域網(wǎng)匯聚層的網(wǎng)絡(luò)設(shè)備時(shí)，它主要完成對(duì)城域網(wǎng)中接入層上聯(lián)鏈路的匯接(Metro Aggregation)，在用戶側(cè)能夠接入Fast Ethernet、Gigabit Ethernet(千兆以太網(wǎng))和低速ATM(異步傳輸模式)等信號(hào)，并提供智能業(yè)務(wù)生成(Service Creation)功能，為運(yùn)營商提供各種增值功能，而在網(wǎng)絡(luò)層通過GE(千兆以太網(wǎng))或POS(SDH上的分組)和城域網(wǎng)主干層設(shè)備相連。此外，MAISP-8000也可以通過POS接口和SDH(同步數(shù)字系列)本地環(huán)連接，或者通過GE組成環(huán)形或星形網(wǎng)絡(luò)，組成城域網(wǎng)的主干，并通過OC-48 POS和主干網(wǎng)設(shè)備相連。
從組網(wǎng)的需求來看，MAISP-8000上需要實(shí)現(xiàn)RIP(路由信息協(xié)議)和OSPF(開放最短路徑優(yōu)先)等域內(nèi)協(xié)議和BGP-4等域間協(xié)議，在鏈路層支持PPP(點(diǎn)對(duì)點(diǎn)協(xié)議)、Ethernet(以太網(wǎng))、LAPS(鏈路存取協(xié)議-SDH)和HDLC(高級(jí)數(shù)據(jù)鏈路控制)等協(xié)議。從應(yīng)用的角度來說，MAISP-8000能夠提供實(shí)現(xiàn)單播、組播和MPLS轉(zhuǎn)發(fā)，并提供NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)、Firewall(防火墻)、VPN(虛擬個(gè)人網(wǎng)絡(luò))、Virtual Router(虛擬路由器)和移動(dòng)IP等應(yīng)用。此外，考慮到目前國內(nèi)接入層的組網(wǎng)方式，MAISP-8000上該能夠提供二層應(yīng)用(VLAN(虛擬局域網(wǎng)))的支持。作為提供給運(yùn)營商的增值功能，MAISP-8000目前可以提供基于端口和PPPoE Session(以太網(wǎng)點(diǎn)對(duì)點(diǎn)會(huì)話)的帶寬限制和QoS(服務(wù)質(zhì)量)保證。從對(duì)用戶的管理角度來說，MAISP-8000目前可以提供基于PPPoE(以太網(wǎng)點(diǎn)對(duì)點(diǎn)會(huì)話)，的認(rèn)證方式，并能通過Radius(遠(yuǎn)程驗(yàn)證接入用戶服務(wù))來實(shí)現(xiàn)對(duì)用戶流量的計(jì)費(fèi)。此外，還支持VLAN+IP+MAC(媒體接入控制)的三級(jí)綁定和Web認(rèn)證。
MAISP-8000的機(jī)架采用工業(yè)標(biāo)準(zhǔn)的19英寸機(jī)箱，盤位間距為25.4mm，總共16個(gè)槽位，其中主控CPU和交換盤占用7號(hào)和8號(hào)槽位，為1+1的備份，而剩余14個(gè)槽位提供給線卡使用，線卡為9U。
圖17顯示出本發(fā)明的應(yīng)用的邏輯視圖。圖中，實(shí)線箭頭代表高速數(shù)據(jù)總線，虛線箭頭代表高速控制總線。其中，高速的數(shù)據(jù)總線提供大容量的數(shù)據(jù)通道，而控制總線中提供了管理消息的通道，并提供了監(jiān)控硬件狀態(tài)的Health#、Present#和Alarm#等信號(hào)。整個(gè)系統(tǒng)采用3∶1的風(fēng)扇備份和1∶1的電源備份，提供了硬件的高可用性冗余支持。
此外，MAISP-8000采用了控制和轉(zhuǎn)發(fā)分離的體系結(jié)構(gòu)，其中控制和管理功能運(yùn)行在主控CPU上，它上面運(yùn)行了故障檢測模塊(FDM)、容錯(cuò)模塊(FTM)以及和每個(gè)協(xié)議相關(guān)的協(xié)議相關(guān)單元(PSE)，實(shí)現(xiàn)主用和備用之間的故障檢測和恢復(fù)。而線卡采用了基于網(wǎng)絡(luò)處理器轉(zhuǎn)發(fā)的體系架構(gòu)，如圖18，在每個(gè)線卡的核心為一個(gè)高性能的網(wǎng)絡(luò)處理器，它在SRAM和SDRAM中維護(hù)有全局的轉(zhuǎn)發(fā)消息庫(FIB)，因此在主備切換過程中，只要有流量進(jìn)入，仍能進(jìn)行正常的轉(zhuǎn)發(fā)。
綜上所述，由于MAISP-8000是定位于運(yùn)營商的電信級(jí)設(shè)備，它采用了冗余的硬件體系結(jié)構(gòu)和轉(zhuǎn)發(fā)和控制分離的實(shí)現(xiàn)方案，并實(shí)現(xiàn)了本發(fā)明的軟硬接合的故障檢測方式和自適應(yīng)的保護(hù)和恢復(fù)方式，實(shí)現(xiàn)了以下功能 1+1主備倒換機(jī)制——采用軟硬結(jié)合的方式對(duì)故障進(jìn)行檢測。通過Heartbeat協(xié)議和背板上的硬件管理信號(hào)，針對(duì)控制CPU卡實(shí)現(xiàn)主、備卡間的發(fā)現(xiàn)和協(xié)商；主、備線卡間的信息同步和熱備份；對(duì)于主、備線卡故障(軟件失效、硬件失效)的發(fā)現(xiàn)、通告和處理(如倒換和數(shù)據(jù)平滑等)；通過網(wǎng)管控制主、備間的強(qiáng)制熱倒換和數(shù)據(jù)平滑； N+1主備倒換機(jī)制——針對(duì)線卡實(shí)現(xiàn)主、備線卡間的發(fā)現(xiàn)和協(xié)商；主、備線卡間的信息同步和熱備份；對(duì)于主、備線卡故障(軟件失效、硬件失效、熱插拔)的發(fā)現(xiàn)、通告和處理；通過網(wǎng)管控制主、備間的強(qiáng)制熱倒換和數(shù)據(jù)平滑； 熱插拔機(jī)制——實(shí)現(xiàn)線卡熱插拔過程中通告、發(fā)現(xiàn)、類型識(shí)別和信息學(xué)習(xí)，針對(duì)不同類型的線卡都需要有不同的處理，以保證業(yè)務(wù)的不間斷 在線升級(jí)機(jī)制——針對(duì)主控卡和線卡保證在升級(jí)軟件的過程中，不會(huì)發(fā)生業(yè)務(wù)中斷，保證設(shè)備的高可靠性 控制和轉(zhuǎn)發(fā)分離——采用了基于網(wǎng)絡(luò)處理器轉(zhuǎn)發(fā)的體系結(jié)構(gòu)，實(shí)現(xiàn)了控制和轉(zhuǎn)發(fā)的分離，保證了在主用和備用切換的過程中，保證數(shù)據(jù)流的轉(zhuǎn)發(fā)。
自適應(yīng)的恢復(fù)和保護(hù)方式——如果即當(dāng)設(shè)備工作在非路由信令模式(不運(yùn)行路由和信令協(xié)議，但可以運(yùn)行靜態(tài)路由和二層協(xié)議)時(shí)，采用一種輕量級(jí)(Light-weight Level)的部分同步(Part Sync)方式，即實(shí)現(xiàn)主備用節(jié)點(diǎn)的配置消息(包括運(yùn)行的配置文件和存儲(chǔ)在存儲(chǔ)器上的初始配置文件)和路由轉(zhuǎn)發(fā)消息的同步。如果網(wǎng)絡(luò)設(shè)備的方式為路由信令模式(需要運(yùn)行路由協(xié)議或MPLS信令)時(shí)，則在設(shè)備在和對(duì)等體建立連接時(shí)，首先判斷對(duì)方是否具備路由信令的協(xié)議擴(kuò)展能力，如果具備則采用了協(xié)議擴(kuò)展方式進(jìn)行保護(hù)，如果沒有則采用完全狀態(tài)同步的方式進(jìn)行保護(hù)。
盡管參考本發(fā)明的優(yōu)選實(shí)施例具體展示和描述了本發(fā)明，但是本領(lǐng)域一般技術(shù)人員應(yīng)該明白，在不脫離所附權(quán)利要求限定的本發(fā)明的精神和范圍的情況下，可以對(duì)其進(jìn)行形式和細(xì)節(jié)上的各種修改。
權(quán)利要求
1.一種數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備具有主用裝置和備用裝置，該方法包括檢測該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備是在非路由信令模式下運(yùn)行還是在路由信令模式下運(yùn)行；如果該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備在非路由信令模式下運(yùn)行，則采用部分同步方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；如果該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備在路由信令模式下運(yùn)行，則檢測與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)钠渌鼣?shù)據(jù)網(wǎng)絡(luò)設(shè)備是否都具備協(xié)議擴(kuò)展功能，如果與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)墓?jié)點(diǎn)都具備協(xié)議擴(kuò)展功能，則采用協(xié)議擴(kuò)展方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；否則，采用狀態(tài)完全同步方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)。
2.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，還包括主用裝置和備用裝置通過心跳機(jī)制以軟件方式互相檢測對(duì)方是否正常工作；同時(shí)，通過背板上的硬件管理信號(hào)以硬件方式檢測硬件改變或故障。
3.如權(quán)利要求2所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，還包括當(dāng)主用裝置發(fā)生故障時(shí)，備用裝置切換為新主用裝置，并接替原主用裝置的工作；當(dāng)備用裝置發(fā)生故障時(shí)，主用裝置進(jìn)行相應(yīng)的故障恢復(fù)操作，并停止對(duì)備用裝置的同步更新。
4.如權(quán)利要求3所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，當(dāng)在協(xié)議擴(kuò)展方式下主用裝置發(fā)生故障時(shí)，該方法還包括新主用裝置與所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的對(duì)等數(shù)據(jù)網(wǎng)絡(luò)設(shè)備重新建立對(duì)等關(guān)系，并從所述對(duì)等數(shù)據(jù)網(wǎng)絡(luò)設(shè)備接收與相應(yīng)協(xié)議相關(guān)的路由信息庫。
5.如權(quán)利要求3所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，還包括選擇優(yōu)先處理以軟件方式檢測到的故障還是優(yōu)先處理以硬件方式檢測到的故障。
6.如權(quán)利要求2所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在所述心跳機(jī)制下，主用裝置和備用裝置周期性地交換保持存活消息，當(dāng)主用裝置和備用裝置之一在預(yù)定時(shí)間內(nèi)沒有收到來自主用裝置和備用裝置中的另一個(gè)裝置的保持存活消息時(shí)，確定所述另一個(gè)裝置發(fā)生故障；而在所述硬件方式下，通過實(shí)時(shí)中斷方式或定時(shí)輪詢方式對(duì)硬件信號(hào)進(jìn)行監(jiān)視，以確定主用裝置和備用裝置是否在位、是否出現(xiàn)故障。
7.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在部分同步方式下，只在主用裝置上管理配置消息或路由轉(zhuǎn)發(fā)消息發(fā)生改變時(shí)，才在主用裝置和備用裝置之間執(zhí)行管理配置消息和路由轉(zhuǎn)發(fā)消息的同步。
8.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在狀態(tài)完全同步方式下，協(xié)議狀態(tài)發(fā)生任何變化時(shí)，都執(zhí)行主用裝置和備用裝置之間管理配置消息和路由轉(zhuǎn)發(fā)消息的同步。
9.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在協(xié)議擴(kuò)展方式下，當(dāng)協(xié)議層內(nèi)部狀態(tài)發(fā)生變化時(shí)，主用裝置向備用裝置發(fā)送更新消息，備用裝置響應(yīng)于該更新消息而改變內(nèi)部協(xié)議的數(shù)據(jù)結(jié)構(gòu)，以實(shí)現(xiàn)與主用裝置的同步。
10.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，當(dāng)正常工作時(shí)，由主用裝置對(duì)備用裝置進(jìn)行動(dòng)態(tài)更新；而當(dāng)主用裝置發(fā)現(xiàn)備用裝置剛啟動(dòng)時(shí)，執(zhí)行批量更新。
11.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，主用裝置和備用裝置之間執(zhí)行熱備份。
12.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的控制裝置上統(tǒng)一維護(hù)路由轉(zhuǎn)發(fā)消息，而在所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的各個(gè)線路接口卡上保存轉(zhuǎn)發(fā)消息庫。
13.如權(quán)利要求1所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)平面和控制平面相分離，并且所述主用裝置和備用裝置分別是所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備中運(yùn)行協(xié)議的主用部件和備用部件。
14.一種與其它節(jié)點(diǎn)進(jìn)行數(shù)據(jù)傳輸?shù)臄?shù)據(jù)網(wǎng)絡(luò)設(shè)備，包括至少一個(gè)主用裝置和至少一個(gè)備用裝置，所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備包括工作模式獲取裝置，用于獲取該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的工作模式；協(xié)議擴(kuò)展功能判斷裝置，用于判斷與該數(shù)據(jù)網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)傳輸?shù)钠渌?jié)點(diǎn)是否都具有協(xié)議擴(kuò)展功能；保護(hù)方式確定裝置，根據(jù)所述工作模式獲取裝置所獲取的工作模式和所述協(xié)議擴(kuò)展功能判斷裝置的判斷結(jié)果，確定以何種方式進(jìn)行在主用裝置和備用裝置之間的保護(hù)和恢復(fù)；部分同步保護(hù)裝置，以部分同步方式執(zhí)行所述保護(hù)和恢復(fù)；協(xié)議擴(kuò)展保護(hù)裝置，以協(xié)議擴(kuò)展方式執(zhí)行所述保護(hù)和恢復(fù)；狀態(tài)完全同步保護(hù)裝置，以狀態(tài)完全同步方式執(zhí)行所述保護(hù)和恢復(fù)，其中，如果所述工作模式為非路由信令模式，則所述保護(hù)方式確定裝置確定由部分同步保護(hù)裝置執(zhí)行所述保護(hù)和恢復(fù)，如果所述工作模式為路由信令模式，則保護(hù)方式確定裝置指示所述協(xié)議擴(kuò)展功能判斷裝置執(zhí)行所述判斷，如果判定所述其它節(jié)點(diǎn)都具備協(xié)議擴(kuò)展功能，則所述保護(hù)方式確定裝置確定由協(xié)議擴(kuò)展保護(hù)裝置執(zhí)行所述保護(hù)和恢復(fù)，如果判定所述其它節(jié)點(diǎn)并不都具有協(xié)議擴(kuò)展功能，則所述保護(hù)方式確定裝置確定由狀態(tài)完全同步保護(hù)裝置執(zhí)行所述保護(hù)和恢復(fù)。
15.如權(quán)利要求14所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備，還包括故障檢測模塊，所述故障檢測模塊包括心跳機(jī)制模塊，用于在主用裝置和備用裝置之間周期性地交換保持存活消息，當(dāng)主用裝置和備用裝置之一在預(yù)定時(shí)間內(nèi)沒有收到來自主用裝置和備用裝置中另一個(gè)裝置的保持存活消息時(shí)，確定所述另一個(gè)裝置發(fā)生故障；硬件管理器，通過實(shí)時(shí)中斷方式或定時(shí)輪詢方式對(duì)硬件信號(hào)進(jìn)行監(jiān)視，以確定主用裝置和備用裝置是否在位、是否出現(xiàn)故障。
16.如權(quán)利要求15所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備，還包括故障處理裝置，用于接收故障檢測模塊所通告的故障，并進(jìn)行相應(yīng)的故障處理，其中，當(dāng)檢測到主用裝置發(fā)生故障時(shí)，故障處理裝置將備用裝置切換為新主用裝置，并接替原主用裝置的工作；當(dāng)檢測到備用裝置發(fā)生故障時(shí)，故障處理裝置進(jìn)行相應(yīng)的故障恢復(fù)操作，并停止對(duì)備用裝置的同步和更新。
17.如權(quán)利要求14所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在部分同步方式下，部分同步保護(hù)裝置只在主用裝置上管理配置消息或路由轉(zhuǎn)發(fā)消息發(fā)生改變時(shí)，才在主用裝置和備用裝置之間執(zhí)行管理配置消息和路由轉(zhuǎn)發(fā)消息的同步。
18.如權(quán)利要求14所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在狀態(tài)完全同步方式下，狀態(tài)完全同步保護(hù)裝置在協(xié)議狀態(tài)發(fā)生任何變化時(shí)，都執(zhí)行主用裝置和備用裝置之間管理配置消息和路由轉(zhuǎn)發(fā)消息的同步。
19.如權(quán)利要求14所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備管理控制方法，其中，在協(xié)議擴(kuò)展方式下，協(xié)議擴(kuò)展保護(hù)裝置在協(xié)議層內(nèi)部狀態(tài)發(fā)生變化時(shí)，使主用裝置向備用裝置發(fā)送更新消息，并使備用裝置響應(yīng)于該更新消息而改變內(nèi)部協(xié)議的數(shù)據(jù)結(jié)構(gòu)，以實(shí)現(xiàn)與主用裝置的同步。
20.如權(quán)利要求14所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備，還包括動(dòng)態(tài)更新裝置，用于在正常工作時(shí)，對(duì)備用裝置進(jìn)行動(dòng)態(tài)更新；以及批量更新裝置，用于在主用裝置發(fā)現(xiàn)備用裝置剛啟動(dòng)時(shí)，執(zhí)行批量更新。
21.如權(quán)利要求14所述的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備，其中，所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)平面和控制平面相分離，并且所述主用裝置和備用裝置分別是所述數(shù)據(jù)網(wǎng)絡(luò)設(shè)備中運(yùn)行協(xié)議的主用部件和備用部件。
全文摘要
本發(fā)明提供了一種數(shù)據(jù)網(wǎng)絡(luò)設(shè)備及其管理控制方法。在故障檢測上采用了軟件和硬件相結(jié)合的方式，提高了故障檢測的速度和精度。而在主備保護(hù)和恢復(fù)的方式上，采用了自適應(yīng)的主備保護(hù)和恢復(fù)方式。具體說來，當(dāng)設(shè)備運(yùn)行在非路由信令模式時(shí)，采用一種輕量級(jí)的部分同步方式，而運(yùn)行在路由信令模式時(shí)，首先判斷鄰接節(jié)點(diǎn)是否都具備協(xié)議擴(kuò)展功能，如果具備則采用協(xié)議擴(kuò)展方式進(jìn)行主備保護(hù)，否則才采用狀態(tài)完全同步方式。和現(xiàn)有方式相比，本發(fā)明系統(tǒng)開銷更小、適用環(huán)境更廣、靈活性更高，因此大大提高了設(shè)備的高可用性。本發(fā)明適用于目前和未來的寬帶Ipv4和Ipv6網(wǎng)絡(luò)中的接入層、匯聚層和骨干層等二三層路由交換設(shè)備，也適用于無線分組網(wǎng)中的數(shù)據(jù)網(wǎng)絡(luò)設(shè)備。
文檔編號(hào)H04L12/24GK1897538SQ20051008361
公開日2007年1月17日 申請(qǐng)日期2005年7月13日 優(yōu)先權(quán)日2005年7月13日
發(fā)明者吉萌, 余少華 申請(qǐng)人:武漢烽火網(wǎng)絡(luò)有限責(zé)任公司