專利名稱：智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后控制平面的恢復(fù)方法
技術(shù)領(lǐng)域：
本發(fā)明涉及光通信領(lǐng)域，特別涉及在智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后控制平面的恢復(fù)方法。
背景技術(shù)：
在智能光網(wǎng)絡(luò)中，有一條基本的原則控制平面的失敗不能影響業(yè)務(wù)平面，導(dǎo)致對(duì)業(yè)務(wù)的損害。因此，當(dāng)控制平面發(fā)生失敗，如節(jié)點(diǎn)重啟后，恢復(fù)原來(lái)的控制信息，重新對(duì)業(yè)務(wù)進(jìn)行控制顯得非常必要和重要。在智能光網(wǎng)絡(luò)中，控制平面的失敗可分為兩種情況一種是網(wǎng)元節(jié)點(diǎn)發(fā)生了失敗，如節(jié)點(diǎn)重啟，控制信息丟失，但底層的業(yè)務(wù)還保存下來(lái)了；另一種情況是控制通道失敗，如兩節(jié)點(diǎn)間的光纖斷了，它們之間的控制通道通訊中斷。本申請(qǐng)所涉及的只是節(jié)點(diǎn)重啟后，用于恢復(fù)控制平面的方法。
在現(xiàn)有的IETF(Internet Engineering Task Force，因特網(wǎng)工程任務(wù)組)、OIF(Optical Internetworking Forum，光網(wǎng)絡(luò)論壇)有關(guān)智能光網(wǎng)絡(luò)的標(biāo)準(zhǔn)和草案中，對(duì)于由RSVP(Resource reSerVation Protocol，資源預(yù)留協(xié)議)或RSVP-TE(Resource reSerVation Protocol with TrafficEngineering Extension，具有流量工程擴(kuò)展的資源預(yù)留協(xié)議)建立起來(lái)的連接，只給出了單節(jié)點(diǎn)發(fā)生重啟后用于恢復(fù)控制平面的方法，對(duì)于有多個(gè)連續(xù)的節(jié)點(diǎn)發(fā)生重啟后如何進(jìn)行恢復(fù)處理，則沒(méi)有給出解決方案。
上述關(guān)于單節(jié)點(diǎn)重啟后恢復(fù)控制平面的技術(shù)解決方案記載在“用戶網(wǎng)絡(luò)接口信令協(xié)議1.0，光網(wǎng)絡(luò)論壇，2000.125.7，2001年10月1日”(UserNetwork Interface(UNI)1.0 Signaling Specification，OIF2000.125.7，October，1，2001)中。
在上述已知的技術(shù)解決方案中，由于同步恢復(fù)是由上游節(jié)點(diǎn)通過(guò)發(fā)送帶Recovery_Label的Path消息來(lái)發(fā)起的，在重啟的節(jié)點(diǎn)上啟動(dòng)了RecoveryTimer(恢復(fù)定時(shí)器)，這樣，在多個(gè)連續(xù)的節(jié)點(diǎn)發(fā)生重啟的情況下，采用上述的協(xié)議中提供的解決方案會(huì)存在以下問(wèn)題。假設(shè)網(wǎng)絡(luò)中的某條連接經(jīng)過(guò)的兩個(gè)連續(xù)的節(jié)點(diǎn)B和C發(fā)生了重啟，而且節(jié)點(diǎn)C比節(jié)點(diǎn)B先完成重啟，這樣，節(jié)點(diǎn)C就有可能在Recovery Timer超時(shí)的時(shí)間內(nèi)收不到節(jié)點(diǎn)B發(fā)過(guò)來(lái)的帶Recovery_Label(恢復(fù)標(biāo)簽)的Path消息，因此，在Recovery Timer超時(shí)后，節(jié)點(diǎn)C會(huì)刪除底層的交叉連接。在光網(wǎng)絡(luò)中，控制層的失敗不應(yīng)影響業(yè)務(wù)層，即控制層的失敗不能導(dǎo)致業(yè)務(wù)層的失敗，而在上述情況下，控制層的失敗導(dǎo)致刪除了底層的交叉連接，影響了底層的業(yè)務(wù)，這種情況是不應(yīng)該發(fā)生的。
發(fā)明內(nèi)容
本發(fā)明正是針對(duì)上述現(xiàn)有的技術(shù)解決方案中的不足提出的，根據(jù)本發(fā)明的方法，可以實(shí)現(xiàn)連續(xù)多個(gè)節(jié)點(diǎn)重啟后的控制平面的恢復(fù)。本發(fā)明的所述方法是基于這樣一個(gè)基本原則來(lái)設(shè)計(jì)的，即只有上游節(jié)點(diǎn)同步恢復(fù)完畢了，才能發(fā)起對(duì)下游節(jié)點(diǎn)進(jìn)行同步恢復(fù)。
為實(shí)現(xiàn)上述本發(fā)明目的，體現(xiàn)上述基本設(shè)計(jì)思想，本發(fā)明提供一種用于在智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法，所述的智能光網(wǎng)絡(luò)是根據(jù)RSVP或RSVP-TE建立、刪除的連接，在該連接中至少有相鄰的三個(gè)節(jié)點(diǎn)A，B和C，其中，一個(gè)節(jié)點(diǎn)A為非重啟節(jié)點(diǎn)，位于其他節(jié)點(diǎn)B和C的上游，節(jié)點(diǎn)B和C為依次相鄰的重啟節(jié)點(diǎn)，所述方法包括以下步驟(1)所述非重啟節(jié)點(diǎn)A發(fā)現(xiàn)與相鄰節(jié)點(diǎn)B的通信中斷，向該節(jié)點(diǎn)B發(fā)送的Hello消息中Src_instance之值保持不變，Dst_instance之值設(shè)置為零，并且所述的非重啟節(jié)點(diǎn)A自刷新與該相鄰節(jié)點(diǎn)B相關(guān)的狀態(tài)；(2)與非重啟節(jié)點(diǎn)A相鄰的重啟節(jié)點(diǎn)B發(fā)生重啟后，向相鄰節(jié)點(diǎn)A和C發(fā)送Hello消息，該Hello消息中Src_instance之值相對(duì)于與該節(jié)點(diǎn)發(fā)生重啟前的Src_instance之值發(fā)生變化，Dst_instance之值設(shè)置為零；(3)與上述發(fā)生重啟的節(jié)點(diǎn)B相鄰的另一重啟節(jié)點(diǎn)C根據(jù)從節(jié)點(diǎn)B接收到的Hello消息中的Dst_instance＝0判斷出節(jié)點(diǎn)B尚未恢復(fù)同步，節(jié)點(diǎn)C向節(jié)點(diǎn)B發(fā)送響應(yīng)的Hello消息中Dst_instance＝0；(4)所述非重啟節(jié)點(diǎn)A接受到從節(jié)點(diǎn)B發(fā)來(lái)的Hello消息，如果該消息中的Src_instance之值相對(duì)于該節(jié)點(diǎn)B發(fā)生重啟前的Src_instance之值發(fā)生了變化，則判斷出節(jié)點(diǎn)B發(fā)生了重啟，節(jié)點(diǎn)A停止上述的自刷新，啟動(dòng)RecoveryTimer(恢復(fù)定時(shí)器)，向節(jié)點(diǎn)B發(fā)送的Hello消息中的Dst_instance之值保持為零，并且向節(jié)點(diǎn)B發(fā)送攜帶Recovery_Label的Path消息，用于節(jié)點(diǎn)B的同步恢復(fù)；(5)所述非重啟節(jié)點(diǎn)A在Recovery Timer超時(shí)后，發(fā)送到節(jié)點(diǎn)B的Hello消息中的Dst_instance之值設(shè)置成與節(jié)點(diǎn)B發(fā)送到節(jié)點(diǎn)A的Hello消息中的Src_instance之值相同，用于通知節(jié)點(diǎn)B同步結(jié)束；(6)節(jié)點(diǎn)B與節(jié)點(diǎn)A同步后，節(jié)點(diǎn)B啟動(dòng)Recovery Timer，向節(jié)點(diǎn)C發(fā)送的Hello消息中的Dst_instance之值保持為零，并且向節(jié)點(diǎn)C發(fā)送攜帶Recovery Label的Path消息，用于節(jié)點(diǎn)C的同步恢復(fù)；(7)所述節(jié)點(diǎn)B在Recovery Timer超時(shí)后，發(fā)送到節(jié)點(diǎn)C的Hello消息中的Dst_instance之值設(shè)置成與節(jié)點(diǎn)C發(fā)送到節(jié)點(diǎn)B的Hello消息中的Src_instance之值相同，用于通知節(jié)點(diǎn)C同步結(jié)束。
從上述本發(fā)明所述的適用于連續(xù)多個(gè)節(jié)點(diǎn)重啟后控制平面恢復(fù)的方法的技術(shù)方案中可以看出，本發(fā)明所述方法不同于現(xiàn)有協(xié)議，主要體現(xiàn)在以下幾個(gè)方面(1)前一節(jié)點(diǎn)只有在完成與上游節(jié)點(diǎn)的同步恢復(fù)過(guò)程后才能發(fā)起對(duì)下游節(jié)點(diǎn)的同步；(2)由上游未重啟的節(jié)點(diǎn)或已與上游節(jié)點(diǎn)同步恢復(fù)完成的節(jié)點(diǎn)啟動(dòng)Recovery Timer定時(shí)器；(3)在兩個(gè)相鄰節(jié)點(diǎn)沒(méi)有同步恢復(fù)結(jié)束之前，它們之間交換的Hello消息中的Dst_instance的值始終設(shè)置為0；由上游節(jié)點(diǎn)在Recovery Timer定時(shí)器超時(shí)后通知下游節(jié)點(diǎn)同步恢復(fù)過(guò)程結(jié)束，(4)通過(guò)將發(fā)往下游節(jié)點(diǎn)的Hello消息中的Dst_instance的值改為該節(jié)點(diǎn)從該下游節(jié)點(diǎn)收到的Hello消息中的Src_instance的值來(lái)實(shí)現(xiàn)。
因此，本發(fā)明的方法可以克服現(xiàn)有技術(shù)的不足，解決連續(xù)多個(gè)節(jié)點(diǎn)重啟后控制平面的正確恢復(fù)，不影響底層的業(yè)務(wù)。
圖1示意性地說(shuō)明了本發(fā)明提供的用于在連續(xù)多個(gè)節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法的流程。
具體實(shí)施例方式
為了方便本領(lǐng)域普通技術(shù)人員理解本發(fā)明，在解釋本發(fā)明的具體實(shí)施方式
之前，先做如下假設(shè)(1)圖1中的節(jié)點(diǎn)A、B、C為連續(xù)的三個(gè)節(jié)點(diǎn)，依次為上下游節(jié)點(diǎn)；(2)在發(fā)生節(jié)點(diǎn)重啟前，節(jié)點(diǎn)A發(fā)給鄰居的Hello消息中的Src_instance＝11，節(jié)點(diǎn)B發(fā)給鄰居的Hello消息中的Src_instance＝2，節(jié)點(diǎn)C發(fā)給鄰居的Hello消息中的Src_instance＝3；(3)節(jié)點(diǎn)A為非重啟節(jié)點(diǎn)(Non Restart Node)，節(jié)點(diǎn)B和C為重啟節(jié)點(diǎn)(Restart Node)。重啟后，節(jié)點(diǎn)B發(fā)給鄰居的Hello消息中的Src_instance＝22，節(jié)點(diǎn)C發(fā)給鄰居的Hello消息中的Src_instance＝33。
接下來(lái)，參照?qǐng)D1，說(shuō)明基于上述假設(shè)的本發(fā)明的用于在連續(xù)多個(gè)節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法。
1、節(jié)點(diǎn)B完成重啟后，向鄰居節(jié)點(diǎn)發(fā)送Hello消息節(jié)點(diǎn)B完成重啟后，分別向節(jié)點(diǎn)A和節(jié)點(diǎn)C發(fā)送Hello消息，Hello消息中的Src_instance＝22，Dst_instance＝0。
2、節(jié)點(diǎn)C在收到節(jié)點(diǎn)B發(fā)送所來(lái)得Hello消息后的處理根據(jù)本發(fā)明，節(jié)點(diǎn)C應(yīng)在節(jié)點(diǎn)B完成與節(jié)點(diǎn)A的同步恢復(fù)之后發(fā)生重啟。節(jié)點(diǎn)C根據(jù)從節(jié)點(diǎn)B收到的上述Hello消息中的Dst_instance＝0，判定節(jié)點(diǎn)B還沒(méi)有完成同步恢復(fù)。這時(shí)，節(jié)點(diǎn)C必須等待節(jié)點(diǎn)B完成同步恢復(fù)。在所述的等待過(guò)程中，節(jié)點(diǎn)C向節(jié)點(diǎn)B發(fā)送響應(yīng)的Hello消息中的Src_instance＝33，Dst_instance＝0。
節(jié)點(diǎn)B在收到來(lái)自節(jié)點(diǎn)C的響應(yīng)的Hello消息后，由于本節(jié)點(diǎn)還沒(méi)有完成同步恢復(fù)，所以發(fā)給節(jié)點(diǎn)A和節(jié)點(diǎn)C的Hello消息中的Src_instance＝22，Dst_instance＝0。
也就是說(shuō)，根據(jù)本發(fā)明，如果上游節(jié)點(diǎn)沒(méi)有完成同步恢復(fù)，該節(jié)點(diǎn)與其下游的鄰居節(jié)點(diǎn)之間交換的Hello消息中的Dst_instance＝0應(yīng)始終保持。
本發(fā)明正是通過(guò)這種機(jī)制保證在上游節(jié)點(diǎn)例如節(jié)點(diǎn)B沒(méi)有完成同步恢復(fù)前，其下游節(jié)點(diǎn)例如節(jié)點(diǎn)C就不會(huì)啟動(dòng)恢復(fù)過(guò)程。
3、節(jié)點(diǎn)A收到節(jié)點(diǎn)B發(fā)送過(guò)來(lái)的Hello消息后的處理如圖1所示，節(jié)點(diǎn)A為非重啟節(jié)點(diǎn)。如現(xiàn)有技術(shù)中已知的那樣，節(jié)點(diǎn)A一旦發(fā)現(xiàn)與鄰居的通信中斷，該節(jié)點(diǎn)向發(fā)生通信中斷的鄰居節(jié)點(diǎn)B的Hello消息中的Src_instance＝11，Dst_instance＝0。這時(shí)，節(jié)點(diǎn)A與節(jié)點(diǎn)B相關(guān)的狀態(tài)進(jìn)入自刷新?tīng)顟B(tài)。
根據(jù)前面的假設(shè)，在發(fā)生節(jié)點(diǎn)重啟前，節(jié)點(diǎn)B發(fā)給鄰居的Hello消息中的Src_instance＝2。然而，如前文所述，此時(shí)發(fā)生了節(jié)點(diǎn)B重啟，如上所述，節(jié)點(diǎn)A從節(jié)點(diǎn)B接收到的HELLO消息是Src_instance＝22，Dst_instance＝0。
節(jié)點(diǎn)A通過(guò)將其保存的節(jié)點(diǎn)B的Src_instance之值(Src_instance＝2)與剛收到的來(lái)自節(jié)點(diǎn)B的Hello消息中的Src_instance(Src_instance＝22)值相比較，二者發(fā)生了變化，據(jù)此，節(jié)點(diǎn)A可以判斷節(jié)點(diǎn)B發(fā)生了重啟。于是，節(jié)點(diǎn)A停止自刷新，啟動(dòng)Recovery Timer，向節(jié)點(diǎn)B發(fā)送Hello消息，該Hello消息中Src_instance＝11，Dst_instance＝0。值得注意的是，在未能與節(jié)點(diǎn)B完成同步恢復(fù)之前，節(jié)點(diǎn)A發(fā)給節(jié)點(diǎn)C的Hello消息中的Dst_instance應(yīng)始終為0。
同時(shí)，節(jié)點(diǎn)A根據(jù)所有與節(jié)點(diǎn)B有關(guān)的狀態(tài)生成Path消息，并攜帶Recovery_Label對(duì)象發(fā)送到節(jié)點(diǎn)B，以對(duì)節(jié)點(diǎn)B進(jìn)行同步恢復(fù)。
4、如果節(jié)點(diǎn)A啟動(dòng)的Recovery Timer超時(shí)，節(jié)點(diǎn)A會(huì)刪除沒(méi)有和節(jié)點(diǎn)B同步的狀態(tài)，節(jié)點(diǎn)A發(fā)給節(jié)點(diǎn)B的Hello消息中的Dst_instance被設(shè)置為22，而不再為0，這樣做是用于通知節(jié)點(diǎn)B同步結(jié)束。
5、節(jié)點(diǎn)B收到節(jié)點(diǎn)A發(fā)送過(guò)來(lái)的帶Recovery_Label的Path消息之后的處理與現(xiàn)有技術(shù)完全一致。簡(jiǎn)而言之，節(jié)點(diǎn)B首先檢查它是否有與所接受的Path消息相對(duì)應(yīng)的RSVP狀態(tài)。如果有與該P(yáng)ath消息相對(duì)應(yīng)的狀態(tài)，則按照正常的處理流程對(duì)該P(yáng)ath消息進(jìn)行處理。
如果沒(méi)有與該P(yáng)ath消息相對(duì)應(yīng)的狀態(tài)，并且該消息中沒(méi)有攜帶Recovery_Label對(duì)象，則該P(yáng)ath消息是用于建立一條新的LSP(標(biāo)簽交換路徑)的，做創(chuàng)建新的連接的處理；如果沒(méi)有與該P(yáng)ath消息相對(duì)應(yīng)的狀態(tài)，該消息中攜帶了Recovery_Label對(duì)象，就在交叉連接表中查找incoming interface(入接口)與Path消息中攜帶的incoming interface相同且incoming_label(入標(biāo)記)與Recovery_Label對(duì)象中攜帶的標(biāo)記相同的交叉連接。如果這樣的交叉連接沒(méi)有找到，就認(rèn)為該P(yáng)ath消息是用于建立一條新的連接的。
如果這樣的交叉連接找到了，則創(chuàng)建相應(yīng)的RVSP狀態(tài)。然后，向下游節(jié)點(diǎn)發(fā)送Path消息時(shí)，包含一個(gè)Suggested_Label(建議標(biāo)簽)對(duì)象，其值與該交叉連接的Outgoing_label(出標(biāo)記)的值相同，Outgoing Interface(出接口)與該交叉連接的Outgoing Interface的值相同。如果該節(jié)點(diǎn)的下一個(gè)節(jié)點(diǎn)也重啟了，則還要在Path消息中攜帶一個(gè)Recovery_label對(duì)象。
對(duì)于雙向LSP，就要在交叉連接表中查找incoming interface與Path消息中攜帶的incoming interface相同，incoming_label與Recovery_label對(duì)象中攜帶的標(biāo)記相同，outgoing_label與Upstream_lable(上行標(biāo)簽)中攜帶的標(biāo)記相同的交叉連接。如果這樣的交叉連接沒(méi)有找到，就認(rèn)為該P(yáng)ath消息是用于建立一條新的連接的。
如果這樣的交叉連接找到了，則創(chuàng)建相應(yīng)的RSVP狀態(tài)。該交叉連接就認(rèn)為被同步了。如果該節(jié)點(diǎn)不是LSP的末節(jié)點(diǎn)，則相應(yīng)的發(fā)送出去的Path消息中攜帶的Upstream_lable的值為該交叉連接的incoming_label的值。
6、節(jié)點(diǎn)B收到節(jié)點(diǎn)A發(fā)送過(guò)來(lái)的Hello消息后，若發(fā)現(xiàn)收到的Hello消息中的Dst_instance＝0，則說(shuō)明和節(jié)點(diǎn)A還沒(méi)有完成同步，節(jié)點(diǎn)B發(fā)給節(jié)點(diǎn)A的Hello消息中的Dst_instance仍設(shè)置為0；如果收到的Hello消息中的Dst_instance＝22，即與節(jié)點(diǎn)B發(fā)送給節(jié)點(diǎn)A的Hello消息中的Src_instance相同，則由此可以判斷節(jié)點(diǎn)A與節(jié)點(diǎn)B的同步恢復(fù)過(guò)程已完成。只有在節(jié)點(diǎn)B完成了與其上游節(jié)點(diǎn)例如節(jié)點(diǎn)A的同步恢復(fù)后，節(jié)點(diǎn)B才能發(fā)起與節(jié)點(diǎn)C的同步恢復(fù)過(guò)程。
7、節(jié)點(diǎn)B發(fā)起與節(jié)點(diǎn)C的同步恢復(fù)過(guò)程節(jié)點(diǎn)B發(fā)起與節(jié)點(diǎn)C的同步恢復(fù)過(guò)程的處理情況與節(jié)點(diǎn)A發(fā)起與節(jié)點(diǎn)B的同步恢復(fù)的處理過(guò)程類似。具體來(lái)說(shuō)，節(jié)點(diǎn)B啟動(dòng)Recovery Timer，向節(jié)點(diǎn)C發(fā)送Hello消息(Src_instance＝22，Dst_instance＝0)。同樣，在節(jié)點(diǎn)B未能與節(jié)點(diǎn)C完成同步恢復(fù)之前，節(jié)點(diǎn)B向節(jié)點(diǎn)C發(fā)送的HELLO消息中的Dst_instance始終為零。
類似于節(jié)點(diǎn)A對(duì)節(jié)點(diǎn)B發(fā)起的同步恢復(fù)，節(jié)點(diǎn)B也要根據(jù)所有與節(jié)點(diǎn)C有關(guān)的狀態(tài)生成PATH消息，并攜帶Recovery_Label對(duì)象發(fā)送到節(jié)點(diǎn)C，以完成對(duì)節(jié)點(diǎn)C的同步恢復(fù)。節(jié)點(diǎn)C收到節(jié)點(diǎn)B發(fā)送過(guò)來(lái)的Hello消息后，若發(fā)現(xiàn)收到的Hello消息中的Dst_instance＝0，則說(shuō)明和節(jié)點(diǎn)B還沒(méi)有完成同步，節(jié)點(diǎn)C發(fā)給節(jié)點(diǎn)B的Hello消息中的Dst_instance仍設(shè)置為0；如果收到的Hello消息中的Dst_instance＝33，即與節(jié)點(diǎn)C發(fā)送給節(jié)點(diǎn)B的Hello消息中的Src_instance相同，則由此可以判斷節(jié)點(diǎn)B與節(jié)點(diǎn)C的同步恢復(fù)過(guò)程已完成。
當(dāng)此連接中的連續(xù)節(jié)點(diǎn)A，B和C恢復(fù)同步后，控制平面的恢復(fù)即告完成。
需要說(shuō)明的是，在前述對(duì)本發(fā)明具體實(shí)施方式
的描述中，所說(shuō)的連接均指在智能光網(wǎng)絡(luò)中使用RSVP(RSVP-TE)協(xié)議進(jìn)行建立、刪除的光連接。所作的各種假設(shè)僅僅用于說(shuō)明之目的，不應(yīng)理解為對(duì)本發(fā)明的限定。本發(fā)明在現(xiàn)有方案的基礎(chǔ)之上，提出了適用于連續(xù)多個(gè)節(jié)點(diǎn)重啟后控制平面恢復(fù)的方法，所述方法應(yīng)遵循的幾個(gè)原則為(1)前一節(jié)點(diǎn)只有在完成與上游節(jié)點(diǎn)的同步恢復(fù)過(guò)程后才能發(fā)起對(duì)下游節(jié)點(diǎn)的同步；(2)由上游未重啟的節(jié)點(diǎn)或已與上游節(jié)點(diǎn)同步恢復(fù)完成的節(jié)點(diǎn)啟動(dòng)Recovery Timer定時(shí)器；(3)在兩個(gè)相鄰節(jié)點(diǎn)沒(méi)有同步恢復(fù)結(jié)束之前，它們之間交換的Hello消息中的Dst_instance的值始終設(shè)置為0；由上游節(jié)點(diǎn)在Recovery Timer定時(shí)器超時(shí)后通知下游節(jié)點(diǎn)同步恢復(fù)過(guò)程結(jié)束；(4)通過(guò)將發(fā)往下游節(jié)點(diǎn)的Hello消息中的Dst_instance的值改為該節(jié)點(diǎn)從該下游節(jié)點(diǎn)收到的Hello消息中的Src instance的值來(lái)實(shí)現(xiàn)。
本發(fā)明正是基于上述具有新穎性和創(chuàng)造性的幾項(xiàng)原則，實(shí)現(xiàn)連續(xù)多個(gè)節(jié)點(diǎn)重啟后控制平面恢復(fù)。本領(lǐng)域普通技術(shù)人員在本發(fā)明的上述教導(dǎo)下，根據(jù)本發(fā)明具體的應(yīng)用情形，可以對(duì)本發(fā)明進(jìn)行各種改型，然而，不偏離本發(fā)明上述思想的技術(shù)方案均應(yīng)受到本發(fā)明所附權(quán)利要求的保護(hù)。
權(quán)利要求
1.用于智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法，所述的智能光網(wǎng)絡(luò)是根據(jù)RSVP(Resource reSerVation Protocol，資源預(yù)留協(xié)議)或RSVP-TE(Resource reSerVation Protocol with Traffic Engineering Extension，具有流量工程擴(kuò)展的資源預(yù)留協(xié)議)建立、刪除的連接，在該連接中至少有相鄰的三個(gè)節(jié)點(diǎn)A，B和C，其中，一個(gè)節(jié)點(diǎn)A為非重啟節(jié)點(diǎn)，位于其他節(jié)點(diǎn)B和C的上游，節(jié)點(diǎn)B和C為依次相鄰的重啟節(jié)點(diǎn)，所述方法包括以下步驟(1)所述非重啟節(jié)點(diǎn)A發(fā)現(xiàn)與相鄰節(jié)點(diǎn)B的通信中斷，向該節(jié)點(diǎn)B發(fā)送的Hello消息中Src_instance(源實(shí)例)之值保持不變，Dst_instance(目的實(shí)例)之值設(shè)置為零，并且所述的非重啟節(jié)點(diǎn)A自刷新與該相鄰節(jié)點(diǎn)B相關(guān)的狀態(tài)；(2)與非重啟節(jié)點(diǎn)A相鄰的重啟節(jié)點(diǎn)B發(fā)生重啟后，向相鄰節(jié)點(diǎn)A和C發(fā)送Hello消息，該Hello消息中Src_instance之值相對(duì)于與該節(jié)點(diǎn)發(fā)生重啟前的Src_instance之值發(fā)生變化，Dst_instance之值設(shè)置為零；(3)與上述發(fā)生重啟的節(jié)點(diǎn)B相鄰的另一重啟節(jié)點(diǎn)C根據(jù)從節(jié)點(diǎn)B接收到的Hello消息中的Dst_instance＝0判斷出節(jié)點(diǎn)B尚未恢復(fù)同步，節(jié)點(diǎn)C向節(jié)點(diǎn)B發(fā)送響應(yīng)的Hello消息中Dst_instance＝0；(4)所述非重啟節(jié)點(diǎn)A接受到從節(jié)點(diǎn)B發(fā)來(lái)的Hello消息，如果該消息中的Src_instance之值相對(duì)于該節(jié)點(diǎn)B發(fā)生重啟前的Src_instance之值發(fā)生了變化，則判斷出節(jié)點(diǎn)B發(fā)生了重啟，節(jié)點(diǎn)A停止上述的自刷新，啟動(dòng)Recovery Timer(恢復(fù)定時(shí)器)，向節(jié)點(diǎn)B發(fā)送的Hello消息中的Dst_instance之值保持為零，并且向節(jié)點(diǎn)B發(fā)送攜帶Recovery_Label的Path消息，用于節(jié)點(diǎn)B的同步恢復(fù)；(5)所述非重啟節(jié)點(diǎn)A在Recovery Timer超時(shí)后，發(fā)送到節(jié)點(diǎn)B的Hello消息中的Dst_instance之值設(shè)置成與節(jié)點(diǎn)B發(fā)送到節(jié)點(diǎn)A的Hello消息中的Src_instance之值相同，用于通知節(jié)點(diǎn)B同步結(jié)束；(6)節(jié)點(diǎn)B與節(jié)點(diǎn)A同步后，節(jié)點(diǎn)B啟動(dòng)Recovery Timer，向節(jié)點(diǎn)C發(fā)送的Hello消息中的Dst_instance之值保持為零，并且向節(jié)點(diǎn)C發(fā)送攜帶Recovery_Label的Path消息，用于節(jié)點(diǎn)C的同步恢復(fù)；(7)所述節(jié)點(diǎn)B在Recovery Timer超時(shí)后，發(fā)送到節(jié)點(diǎn)C的Hello消息中的Dst_instance之值設(shè)置成與節(jié)點(diǎn)C發(fā)送到節(jié)點(diǎn)B的Hello消息中的Src_instance之值相同，用于通知節(jié)點(diǎn)C同步結(jié)束。
2.根據(jù)權(quán)利要求1所述的用于智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法，其中在步驟(4)中，節(jié)點(diǎn)A停止自刷新后，啟動(dòng)Recovery Timer，向節(jié)點(diǎn)B發(fā)送的Hello消息中的Dst_instance之值應(yīng)保持為零，直到節(jié)點(diǎn)B與節(jié)點(diǎn)B恢復(fù)同步。
3.根據(jù)權(quán)利要求1所述的用于智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法，其中在上述步驟(3)中，節(jié)點(diǎn)C等待上游重啟節(jié)點(diǎn)B與節(jié)點(diǎn)A完成同步恢復(fù)，在等待期間，節(jié)點(diǎn)C發(fā)送到節(jié)點(diǎn)B的Dst_instance之值應(yīng)保持為零。
4.根據(jù)權(quán)利要求1所述的用于智能光網(wǎng)絡(luò)中多節(jié)點(diǎn)重啟后恢復(fù)控制平面的方法，其中在步驟(5)中，非重啟節(jié)點(diǎn)A在Recovery Timer超時(shí)后，刪除未與節(jié)點(diǎn)B同步的狀態(tài)。
全文摘要
本發(fā)明提供用于連續(xù)多個(gè)節(jié)點(diǎn)重啟后控制平面恢復(fù)的方法，在恢復(fù)過(guò)程中，前一重啟節(jié)點(diǎn)只有在完成與上游節(jié)點(diǎn)的同步恢復(fù)過(guò)程后才能發(fā)起對(duì)下游重啟節(jié)點(diǎn)的同步；由上游未重啟的節(jié)點(diǎn)或已與上游節(jié)點(diǎn)同步恢復(fù)完成的節(jié)點(diǎn)啟動(dòng)恢復(fù)定時(shí)器；在兩個(gè)相鄰節(jié)點(diǎn)沒(méi)有同步恢復(fù)結(jié)束之前，它們之間交換的Hello消息中的Dst instance的值始終設(shè)置為0；由上游節(jié)點(diǎn)在恢復(fù)定時(shí)器超時(shí)后通知下游節(jié)點(diǎn)同步恢復(fù)過(guò)程結(jié)束；通過(guò)將發(fā)往下游節(jié)點(diǎn)的Hello消息中的Dst_instance的值改為該節(jié)點(diǎn)從該下游節(jié)點(diǎn)收到的Hello消息中的Src_instance的值來(lái)實(shí)現(xiàn)。因此，本發(fā)明的方法可以克服現(xiàn)有技術(shù)的不足，解決連續(xù)多個(gè)節(jié)點(diǎn)重啟后控制平面的正確恢復(fù)。
文檔編號(hào)H04B10/08GK1492601SQ02147440
公開日2004年4月28日 申請(qǐng)日期2002年10月25日 優(yōu)先權(quán)日2002年10月25日
發(fā)明者蔡軍州, 宋輝, 陳勇, 石興華 申請(qǐng)人:華為技術(shù)有限公司