專利名稱：狀態(tài)機(jī)震蕩預(yù)防的方法和相應(yīng)的通訊設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)通訊領(lǐng)域，尤其涉及一種狀態(tài)機(jī)震蕩預(yù)防的方法和相應(yīng)的通訊設(shè)備。
背景技術(shù)：
PPP(The Point-to-Point Protocol，點(diǎn)到點(diǎn)協(xié)議)協(xié)議指定了一種在點(diǎn)對(duì)點(diǎn)鏈 路上傳輸多個(gè)協(xié)議數(shù)據(jù)報(bào)文的方法并包含了三個(gè)主要組成部分封裝多個(gè)協(xié)議數(shù)據(jù)報(bào)的方 法；建立、配置和測(cè)試數(shù)據(jù)鏈路連接的LCP(The Link Control Protocol，鏈路控制協(xié)議)以 及建立和配置不同網(wǎng)絡(luò)層協(xié)議的NCP(Network Control Protocol，網(wǎng)絡(luò)控制協(xié)議)家族。在設(shè)定、維持和終止點(diǎn)對(duì)點(diǎn)鏈路的過程里，PPP鏈路需要經(jīng)過幾個(gè)階段，如圖1所 示。當(dāng)然圖1只是一個(gè)概圖，并沒有給出所有的狀態(tài)轉(zhuǎn)換。從圖1可知，只要PPP鏈路收到了載波信號(hào)，那么PPP鏈路就進(jìn)入鏈路建立階段， 即LCP協(xié)商。通訊雙方交換LCP數(shù)據(jù)報(bào)文來(lái)配置鏈路。只有該階段完成之后，才會(huì)進(jìn)行下 一階段的協(xié)商。因此LCP階段是PPP鏈路后續(xù)過程的基礎(chǔ)。如果LCP協(xié)商不成功，將直接 導(dǎo)致PPP鏈路不可用。當(dāng)通訊的某一端(在此稱之為第一通訊設(shè)備，比如為一路由器)LCP狀 態(tài)Opened(開啟狀態(tài)，表明鏈路可用)之后，通過循環(huán)定時(shí)的方式發(fā)送?；钫?qǐng)求 (Echo-Request)來(lái)維護(hù)鏈路，第二通訊設(shè)備收到保活請(qǐng)求報(bào)文時(shí)，只有在自身LCP狀態(tài)也 是Opened的情況下，才會(huì)進(jìn)行回應(yīng)。因此第一通訊設(shè)備并不確定能否收到第二通訊設(shè)備的 ?；罨貜?fù)(Echo-R印Iy)。如果能收到，認(rèn)為該鏈路是正常的。反之，第一通訊設(shè)備就認(rèn)為鏈 路可能出現(xiàn)了異常，默認(rèn)連續(xù)發(fā)了 5次以后，都沒有收到回復(fù)，就會(huì)主動(dòng)發(fā)起LCP的重協(xié)商。但是，在實(shí)際的應(yīng)用過程中，可能會(huì)出現(xiàn)LCP狀態(tài)機(jī)震蕩的情況。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題提出一種狀態(tài)機(jī)震蕩預(yù)防的方法和相應(yīng)的通訊設(shè)備，以 防止LCP狀態(tài)機(jī)循環(huán)震蕩。為了解決上述問題，本發(fā)明提供一種狀態(tài)機(jī)震蕩預(yù)防的方法，包括通訊設(shè)備采用點(diǎn)到點(diǎn)協(xié)議(PPP)進(jìn)行通訊時(shí)，當(dāng)判斷滿足鏈路控制協(xié)議(LCP)狀 態(tài)機(jī)震蕩條件時(shí)，則依次執(zhí)行該層終止(TLD)動(dòng)作、發(fā)送斷鏈請(qǐng)求(STR)動(dòng)作和發(fā)送配置請(qǐng) 求(SCR)動(dòng)作。優(yōu)選地，上述方法具有以下特點(diǎn) 當(dāng)所述通訊設(shè)備LCP?；钍r(shí)，則所述通訊設(shè)備判斷滿足LCP狀態(tài)機(jī)震蕩條件。優(yōu)選地，上述方法具有以下特點(diǎn) 當(dāng)所述通訊設(shè)備LCP?；钍?，依次進(jìn)入請(qǐng)求-發(fā)送(Request-Sent)和確認(rèn)-接 收(Ack-Received)狀態(tài)后，再次LCP?；钍r(shí)，則所述通訊設(shè)備判斷滿足LCP狀態(tài)機(jī)震 蕩條件。
優(yōu)選地，上述方法具有以下特點(diǎn) 所述通訊設(shè)備執(zhí)行TLD動(dòng)作之后，執(zhí)行STR動(dòng)作執(zhí)行之前，還執(zhí)行初始化重啟計(jì)數(shù) 器(IRC)動(dòng)作。為了解決上述問題，本發(fā)明提供一種通訊設(shè)備，包括判斷模塊和執(zhí)行模塊；所述判斷模塊用于在所述通訊設(shè)備采用PPP進(jìn)行通訊時(shí)，當(dāng)判斷滿足LCP狀態(tài)機(jī) 震蕩條件時(shí)，通知所述執(zhí)行模塊；所述執(zhí)行模塊用于根據(jù)所述判斷模塊的通知，獲知滿足LCP狀態(tài)機(jī)震蕩條件時(shí)， 依次執(zhí)行TLD動(dòng)作、STR動(dòng)作和SCR動(dòng)作。優(yōu)選地，上述通訊設(shè)備具有以下特點(diǎn)所述判斷模塊進(jìn)一步用于當(dāng)所述通訊設(shè)備LCP?；钍r(shí)，則判斷滿足LCP狀態(tài) 機(jī)震蕩條件。優(yōu)選地，上述通訊設(shè)備具有以下特點(diǎn)所述判斷模塊進(jìn)一步用于當(dāng)所述通訊設(shè)備LCP?；钍?，依次進(jìn)入Req-Sent和 Ack-Rcvd狀態(tài)后，再次LCP?；钍r(shí)，則判斷滿足LCP狀態(tài)機(jī)震蕩條件。優(yōu)選地，上述通訊設(shè)備具有以下特點(diǎn)所述執(zhí)行模塊進(jìn)一步用于執(zhí)行TLD動(dòng)作之后，執(zhí)行STR動(dòng)作執(zhí)行之前，還執(zhí)行IRC動(dòng)作。本發(fā)明在不增加任何成本的情況下，解決了 PPP狀態(tài)機(jī)循環(huán)震蕩的問題，使得PPP 狀態(tài)機(jī)的穩(wěn)定性和健壯性得到極大的提高。


此處所說(shuō)明的附圖用來(lái)提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā) 明的示意性實(shí)施例及其說(shuō)明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中圖1是PPP鏈路協(xié)商階段劃分框圖；圖2是PPP鏈路目前存在的循環(huán)震蕩問題；圖3是本發(fā)明實(shí)施例中PPP狀態(tài)機(jī)震蕩預(yù)防基本流程圖；圖4是本發(fā)明實(shí)施例中PPP狀態(tài)機(jī)震蕩預(yù)防分解流程圖。
具體實(shí)施例方式在實(shí)際的應(yīng)用過程中，發(fā)現(xiàn)有這樣的一種情況第一通訊設(shè)備LCP的狀態(tài)為 Opened,但是此時(shí)第二通訊設(shè)備LCP的狀態(tài)卻是Ack-Received (確認(rèn)-接收，表明已經(jīng)發(fā)送 了一個(gè)配置請(qǐng)求Configure-Request，接收了一個(gè)配置確認(rèn)Configure-Ack。但是還沒有發(fā) 送Configure-Ack，因此期待接收到一個(gè)Configure-Request)。在這種情況下，第一通訊設(shè) 備發(fā)送Echo-Request，由于第二通訊設(shè)備此時(shí)不是Opened狀態(tài)，因此不會(huì)進(jìn)行回復(fù)，5次之 后，LCP保活失敗，第一通訊設(shè)備就重新進(jìn)行LCP協(xié)商，發(fā)送Configure-Request，第二通訊 設(shè)備收到后，回復(fù)一個(gè)Configure-Ack，狀態(tài)變成Opened，而此時(shí)第一通訊設(shè)備的狀態(tài)變成 了 Ack-Received。第一通訊設(shè)備和第二通訊設(shè)備互換角色，重新回到之前的狀態(tài)，并且將如 此往復(fù)，LCP將始終無(wú)法協(xié)商成功。上述的LCP循環(huán)無(wú)法協(xié)商成功的過程如圖2所示。至于通訊的兩端為什么一端處于Opened，一端處于Ack-Received的狀態(tài)，并不是本專利討論的范圍。同時(shí)，滿足圖2所示 的情況，做了這樣的一個(gè)假設(shè)第一通訊設(shè)備從Opened的狀態(tài)到?；钍“l(fā)生所用的時(shí)間 要小于第二通訊設(shè)備LCP超時(shí)的時(shí)間。因?yàn)楸；顣r(shí)間和LCP超時(shí)時(shí)間都是可以配置的，所 以在實(shí)際的運(yùn)行過程中，滿足這一條件并不構(gòu)成任何問題。 本發(fā)明就是針對(duì)使用PPP技術(shù)作為接入或傳輸時(shí)，防止上述LCP狀態(tài)機(jī)無(wú)限震蕩 提出的解決方案。具體地，可采用通訊設(shè)備采用PPP進(jìn)行通訊時(shí)，當(dāng)判斷滿足LCP狀態(tài)機(jī)震蕩條件時(shí)，則依次執(zhí)行 TLD (This-Layer-Down,該層終止)動(dòng)作、STR (Send-Terminate-Request，發(fā)送斷鏈請(qǐng)求)動(dòng) 作和SCR(Send-Configure-Request，發(fā)送配置請(qǐng)求)動(dòng)作。其中，當(dāng)兩端的通訊設(shè)備的LCP狀態(tài)分別處于Opened和Ack-Received，且通訊的 一端從Opened的狀態(tài)到?；钍“l(fā)生所用的時(shí)間要小于對(duì)端LCP超時(shí)的時(shí)間，則滿足LCP 狀態(tài)機(jī)震蕩條件，會(huì)發(fā)生震蕩。但是，由于一端通訊設(shè)備并不能完全知曉對(duì)端通訊設(shè)備的狀 態(tài)，所以在本發(fā)明實(shí)施例中，通訊設(shè)備可采用如下方式判斷是否滿足LCP狀態(tài)機(jī)震蕩條件1、當(dāng)LCP?；钍r(shí)，即判斷滿足LCP狀態(tài)機(jī)震蕩條件；2、當(dāng)LCP保活失敗，依次進(jìn)入Request-Sent和Ack-Received狀態(tài)后，再次LCP保 活失敗時(shí)，即判斷滿足LCP狀態(tài)機(jī)震蕩條件。當(dāng)然，還可以采用其它方式判斷是否滿足LCP狀態(tài)機(jī)震蕩條件，比如多次LCP?；?失敗等等，本發(fā)明并不僅限于上述兩種判斷方式。另夕卜，在執(zhí)行TLD動(dòng)作之后，執(zhí)行STR動(dòng)作執(zhí)行之前，還可執(zhí)行 IRC(Initialize-Restart-Count，初始化重啟計(jì)數(shù)器)動(dòng)作下文中將參考附圖并結(jié)合實(shí)施例來(lái)詳細(xì)說(shuō)明本發(fā)明。需要說(shuō)明的是，在不沖突的 情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的特征可以相互組合。如圖3所示，為本發(fā)明實(shí)施例的PPP狀態(tài)機(jī)震蕩預(yù)防方法包括如下步驟S31，設(shè)置PPP狀態(tài)機(jī)震蕩預(yù)防功能使能；本實(shí)施例中，在功能上將PPP狀態(tài)機(jī)震蕩預(yù)防功能作為一個(gè)可卸載的可靠性檢測(cè) 模塊，可以通過配置來(lái)決定該功能是否起作用。一旦使能了該功能，當(dāng)判斷滿足LCP狀態(tài)機(jī) 震蕩條件，自動(dòng)進(jìn)入PPP狀態(tài)機(jī)震蕩預(yù)防流程。S32，執(zhí)行PPP狀態(tài)機(jī)震蕩預(yù)防策略；所述的狀態(tài)機(jī)震蕩預(yù)防策略是指，進(jìn)入了 PPP狀態(tài)機(jī)震蕩預(yù)防流程的通訊設(shè)備需 要依次執(zhí)行如下流程執(zhí)行TLD動(dòng)作，該動(dòng)作具體為通訊設(shè)備的LCP執(zhí)行實(shí)體向NCP執(zhí)行實(shí)體發(fā)送網(wǎng)絡(luò) 層不可用事件，證實(shí)協(xié)議，或者指示NCP支撐的網(wǎng)絡(luò)層傳輸不再可用。進(jìn)一步地，執(zhí)行IRC動(dòng)作，該動(dòng)作具體為初始化LCP的計(jì)數(shù)器，設(shè)置的配置請(qǐng)求和 斷鏈請(qǐng)求的最大發(fā)送次數(shù)(通常為默認(rèn)的數(shù)值)。進(jìn)一步地，執(zhí)行STR動(dòng)作，該動(dòng)作具體為發(fā)送斷鏈請(qǐng)求(Terminal-Request)，使 第二通訊設(shè)備能夠感知第一通訊設(shè)備的鏈路不可用事件。進(jìn)一步地，執(zhí)行SCR動(dòng)作，該動(dòng)作具體為發(fā)送配置請(qǐng)求(Configure-Request)，重 新開始LCP的協(xié)商。
S33，PPP狀態(tài)機(jī) 恢復(fù)平衡；對(duì)應(yīng)于第二通訊設(shè)備，收到斷鏈請(qǐng)求，發(fā)送斷鏈回應(yīng)(Terminal-R印Iy)，同時(shí)將自 身的LCP狀態(tài)躍遷到Request-Sent (要求發(fā)送配置請(qǐng)求狀態(tài))。從而兩端的LCP狀態(tài)機(jī)重 新回到平衡。所述平衡是指，不再滿足LCP狀態(tài)機(jī)震蕩條件從而成功了避免了 LCP狀態(tài)機(jī) 循環(huán)震蕩的問題。S34，PPP狀態(tài)機(jī)協(xié)商成功通訊兩端的狀態(tài)機(jī)達(dá)到平衡，那么PPP狀態(tài)機(jī)協(xié)商成功是個(gè)必然的過程。圖4是本發(fā)明實(shí)施例中PPP狀態(tài)機(jī)震蕩預(yù)防分解流程圖，當(dāng)然圖4也只是將狀態(tài) 機(jī)的狀態(tài)和兩端需要交互的流程表示了出來(lái)，還有一些其它的操作需要文字描述。這樣處 理顯得更加簡(jiǎn)潔，卻并不妨礙理解。步驟S41，第一通訊設(shè)備由于LCP?；钍?，執(zhí)行TLD動(dòng)作，指示網(wǎng)絡(luò)層傳輸不再可用。進(jìn)一步地，執(zhí)行IRC動(dòng)作，即初始化LCP的計(jì)數(shù)器，設(shè)置配置請(qǐng)求和斷鏈請(qǐng)求的最 大發(fā)送次數(shù)。進(jìn)一步地，發(fā)送斷鏈請(qǐng)求(Terminal-Request)，告知第二通訊設(shè)備，使其能夠感知 第一通訊設(shè)備的鏈路不可用事件。步驟S42，緊接著，第一通訊設(shè)備重新發(fā)起LCP協(xié)商，發(fā)送配置請(qǐng)求，同時(shí)其LCP狀 態(tài)躍遷至 Request-Sent。步驟S43，第二通訊設(shè)備收到斷鏈請(qǐng)求，進(jìn)行斷鏈確認(rèn)，同時(shí)其狀態(tài)機(jī)狀態(tài)躍遷到 Request-Sent，這是很關(guān)鍵的一步。 步驟S44，第二通訊設(shè)備收到LCP配置請(qǐng)求，進(jìn)行LCP配置確認(rèn)，同時(shí)其狀態(tài)躍遷到 Ack-Sent0進(jìn)一步地，第一通訊設(shè)備收到該LCP配置確認(rèn)，狀態(tài)躍遷到Ack-Received。步驟S45，第二通訊設(shè)備在Ack-Sent狀態(tài)同樣也會(huì)發(fā)送配置請(qǐng)求，第一通訊設(shè)備 收到該請(qǐng)求后，執(zhí)行步驟S46。步驟S46，第一通訊設(shè)備在Ack-Received狀態(tài)收到配置請(qǐng)求，執(zhí)行配置確認(rèn)，同時(shí) 自身躍遷到Opened狀態(tài)。進(jìn)一步地，第二通訊設(shè)備在Ack-Sent狀態(tài)收到配置確認(rèn)，狀態(tài)機(jī)也需要進(jìn)行躍 遷，同樣到達(dá)Opened狀態(tài)。相應(yīng)地，本發(fā)明實(shí)施例的通訊設(shè)備，包括判斷模塊和執(zhí)行模塊；所述判斷模塊用于在所述通訊設(shè)備采用PPP進(jìn)行通訊時(shí)，當(dāng)判斷滿足LCP狀態(tài)機(jī) 震蕩條件時(shí)，通知所述執(zhí)行模塊；所述執(zhí)行模塊用于根據(jù)所述判斷模塊的通知，獲知滿足LCP狀態(tài)機(jī)震蕩條件時(shí)， 依次執(zhí)行TLD動(dòng)作、STR動(dòng)作和SCR動(dòng)作。所述判斷模塊可進(jìn)一步用于當(dāng)所述通訊設(shè)備LCP保活失敗時(shí)，則判斷滿足LCP狀 態(tài)機(jī)震蕩條件，或者，當(dāng)所述通訊設(shè)備LCP保活失敗，依次進(jìn)入Req-Sent和Ack-Rcvd狀態(tài) 后，再次LCP保活失敗時(shí)，則判斷滿足LCP狀態(tài)機(jī)震蕩條件。所述執(zhí)行模塊可進(jìn)一步用于執(zhí)行TLD動(dòng)作之后，執(zhí)行STR動(dòng)作執(zhí)行之前，還執(zhí)行 IRC動(dòng)作。
綜上所述，本發(fā)明在遵循PPP協(xié)議的基礎(chǔ)上，將一些技術(shù)手段結(jié)合起來(lái)，達(dá)到了防 止PPP狀態(tài)機(jī)循環(huán)震蕩的目的。 本領(lǐng)域普通技術(shù)人員可以理解上述方法中的全部或部分步驟可通過程序來(lái)指令 相關(guān)硬件完成，所述程序可以存儲(chǔ)于計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)中，如只讀存儲(chǔ)器、磁盤或光盤 等?？蛇x地，上述實(shí)施例的全部或部分步驟也可以使用一個(gè)或多個(gè)集成電路來(lái)實(shí)現(xiàn)，相應(yīng) 地，上述實(shí)施例中的各模塊/單元可以采用硬件的形式實(shí)現(xiàn)，也可以采用軟件功能模塊的 形式實(shí)現(xiàn)。本發(fā)明不限制于任何特定形式的硬件和軟件的結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技 術(shù)人員來(lái)說(shuō)，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修 改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種狀態(tài)機(jī)震蕩預(yù)防的方法，包括通訊設(shè)備采用點(diǎn)到點(diǎn)協(xié)議(PPP)進(jìn)行通訊時(shí)，當(dāng)判斷滿足鏈路控制協(xié)議(LCP)狀態(tài)機(jī) 震蕩條件時(shí)，則依次執(zhí)行該層終止(TLD)動(dòng)作、發(fā)送斷鏈請(qǐng)求(STR)動(dòng)作和發(fā)送配置請(qǐng)求 (SCR)動(dòng)作。
2.如權(quán)利要求1所述的方法，其特征在于，當(dāng)所述通訊設(shè)備LCP?；钍r(shí)，則所述通訊設(shè)備判斷滿足LCP狀態(tài)機(jī)震蕩條件。
3.如權(quán)利要求1所述的方法，其特征在于，當(dāng)所述通訊設(shè)備LCP?；钍。来芜M(jìn)入請(qǐng)求_發(fā)送(Request-Sent)和確認(rèn)-接收 (Ack-Received)狀態(tài)后，再次LCP?；钍r(shí)，則所述通訊設(shè)備判斷滿足LCP狀態(tài)機(jī)震蕩條 件。
4.如權(quán)利要求1 3中任意一項(xiàng)所述的方法，其特征在于，所述通訊設(shè)備執(zhí)行TLD動(dòng)作之后，執(zhí)行STR動(dòng)作執(zhí)行之前，還執(zhí)行初始化重啟計(jì)數(shù)器 (IRC)動(dòng)作。
5.一種通訊設(shè)備，其特征在于，包括判斷模塊和執(zhí)行模塊；所述判斷模塊用于在所述通訊設(shè)備采用PPP進(jìn)行通訊時(shí)，當(dāng)判斷滿足LCP狀態(tài)機(jī)震蕩 條件時(shí)，通知所述執(zhí)行模塊；所述執(zhí)行模塊用于根據(jù)所述判斷模塊的通知，獲知滿足LCP狀態(tài)機(jī)震蕩條件時(shí)，依次 執(zhí)行TLD動(dòng)作、STR動(dòng)作和SCR動(dòng)作。
6.如權(quán)利要求5所述的通訊設(shè)備，其特征在于，所述判斷模塊進(jìn)一步用于當(dāng)所述通訊設(shè)備LCP?；钍r(shí)，則判斷滿足LCP狀態(tài)機(jī)震 蕩條件。
7.如權(quán)利要求5所述的通訊設(shè)備，其特征在于，所述判斷模塊進(jìn)一步用于當(dāng)所述通訊設(shè)備LCP?；钍?，依次進(jìn)入Req-Sent和 Ack-Rcvd狀態(tài)后，再次LCP?；钍r(shí)，則判斷滿足LCP狀態(tài)機(jī)震蕩條件。
8.如權(quán)利要求5 7中任意一項(xiàng)所述的通訊設(shè)備，其特征在于，所述執(zhí)行模塊進(jìn)一步用于執(zhí)行TLD動(dòng)作之后，執(zhí)行STR動(dòng)作執(zhí)行之前，還執(zhí)行IRC動(dòng)作。
全文摘要
本發(fā)明公開一種狀態(tài)機(jī)震蕩預(yù)防的方法和相應(yīng)的通訊設(shè)備，其中，所述方法包括通訊設(shè)備采用點(diǎn)到點(diǎn)協(xié)議(PPP)進(jìn)行通訊時(shí)，當(dāng)判斷滿足鏈路控制協(xié)議(LCP)狀態(tài)機(jī)震蕩條件時(shí)，則依次執(zhí)行該層終止(TLD)動(dòng)作、發(fā)送斷鏈請(qǐng)求(STR)動(dòng)作和發(fā)送配置請(qǐng)求(SCR)動(dòng)作。本發(fā)明在不增加任何成本的情況下，解決了PPP狀態(tài)機(jī)循環(huán)震蕩的問題，使得PPP狀態(tài)機(jī)的穩(wěn)定性和健壯性得到極大的提高。
文檔編號(hào)H04L29/08GK102111445SQ201110005060
公開日2011年6月29日 申請(qǐng)日期2011年1月11日 優(yōu)先權(quán)日2011年1月11日
發(fā)明者于立元, 劉冬梅, 劉椿, 吳小祥 申請(qǐng)人:中興通訊股份有限公司