基于GMPLS光網絡的分布式多層故障定位方法

田軍，崔賀

（西安郵電學院 通信工程系，陜西 西安 710061）

在GMPLS全光網絡[1]下，要求具有高速的數據傳輸率的同時還要維持較高的服務質量（QOS），在這個推動力的作用下，需要對光的運行狀況進行監控。而在光網絡中出現故障是不可避免的，所以保障網絡的魯棒性[2]以及傳輸業務的可靠性的關鍵是快速的故障定位[3-4]。

一般來說，由于光網絡的大容量性[5]，故障的定位并不是一件容易的事情。由于光層故障的傳播性，有限的故障定位時間，有限的可利用的數字信息，在光網絡中故障定位更加復雜。并且由于光層傳輸的透明性，一個故障可以引發大量的告警，導致告警的冗余。而故障定位機制是則根據由不同網絡監控設備產生的告警（這些監控設備監控不同的運行參數，這些參數就是OSI不同層的運行參數）。也就是說，告警的性質和數量取決于監控設備放在哪個層以及這個監控設備的功能（能測什么樣的參數）。

由于光網絡內部的復雜性，傳統的定位故障根源的方法是從單層開始的。典型的多層網絡的恢復策略同樣也是基于單層的觀點。在光網絡中，常用的一個方法是自下向上的故障恢復（第一層進行故障的定位），第一層（光層）嘗試恢復發生故障的連接，假如沒有成功，則由上層（第二層）嘗試發起恢復。本文分析故障的發現，故障定位中面臨的挑戰，并在現有的GMPLS標準的基礎上，提出了一種改進的故障定位方案。

1 GMPLS網絡的故障管理

在GMPLS全光網絡中因為故障的傳播特性，故障定位的主要問題出現在網絡核心結點或鏈路上（骨干網上），尤其對中等或大型網絡更是如此。例如：如圖1所示，相鄰的結點（A，B）之間有一個故障，由于數據向下游流動，它會影響下游的數據鏈接（B，C），（C，D）。 從而導致大量的告警，進而引發故障的定位和保護/恢復處理。由于故障的傳播，一個鏈路的故障會對其他鏈路產生影響，從而增加了定位故障根源的復雜性。更糟糕的是可能會引起沒有必要的保護和恢復機制操作。

圖1 故障的傳播Fig.1 Spread of failure

故障定位的方法可分為：分布式和集中式。集中式的方法利用單個實體（故障管理體系），它接收由監測設備發出的所有告警，然后進行過濾和告警的相關操作，根據全局信息去定位故障的根源。分布式的方法則是在全光網絡的每個結點放置一個故障處理單元，然后在運行一個協議去傳播故障管理的信息，從而定位故障的根源。

對于分布式方案，依靠實時的信息或通知消息去定位故障的根源。一個具有代表性的分布式定位方法是LMP協議，它是GMPLS協議族的一部分。LMP需要另外分出一個監控信道去定位故障，因為當光纖發生故障時不會影響監控信道的工作。其他的方法都是在處理當故障影響監控信道時的故障定位，實質是對LMP協議的完善。

2 故障的發現以及跨層定位

多層網絡有兩個沒有解決的問題：1）各個層中功能重疊。也就是說，有些層執行類似的功能；2）一個故障會影響許多層。本節我們將關注應用到故障管理框架下的這兩個沒有解決的問題。

2.1 多層故障的發現

因為節點的每一層都安裝了檢測裝置，所以當故障發生時每一層都能檢測到。而由于光網絡中故障的傳播，許多其他的下游光路會發出告警。一個故障引發許許多多的告警，有效的多層故障發現的機制隨之產生。必須強調的是多層故障發現的告警提供的是冗余信息、互補信息還是其他信息？當這個告警的目的是引發恢復機制時，存在兩個主要策略會避免多層同時啟動恢復機制。這兩個策略是規定延時時間和恢復標志信號。換句話說，多層的故障發現告警對于時間順序結構是互補的，但是在某一時刻的時間是冗余的。

2.2 跨層的故障定位

對于看到的癥狀對應最有可能的解釋是一個NP困難問題。但是，上層需要下層提供的服務（下層決定上層），所以經常會出現一個現象：一個很小的下層問題會對上層的業務產生很大的影響。所以，在故障管理中要融合跨層的故障診斷。目前，很難實現上述的目標，因為故障在向上層傳時語義也隨之改變。其次，建立一個體系模型是非常困難的，以及在這個系統中分析也是很復雜的。由于在兩個節點相同層之間的故障的水平傳播，以及在節點內，故障的垂直傳播。目前還沒有完善的故障定位技術。總之，要完全的解決上述問題需要融合不同的技術。

在數據高速率傳輸的網絡中另一個非常重要的方面是故障定位的時延。因為它直接影響到業務量的丟失。當發生故障時，數據包將一直丟失，直到把連接轉換到備用連接上才可以進行正常的通信（這個備用連接是在鋪設網絡時預留的，或在發現故障時快速臨時建立的）。故障定位的時延Tloc=Tdet+Thold-off+Tnotif。Tdet是故障發現的時間 （由監控技術決定）。Thold-off是截止時間，由多層網絡中故障定位策略決定（定時器或恢復標志信號）。Tnotif是故障的通知時間，當定位了故障根源并把它隔離后完成送信息的時間（由故障的通知方法和信息傳遞的時間決定）。

3 改進的多層故障定位

在GMPLS多層網絡中，高效的故障定位應該考慮下面的參數：在維持少的定位時延下對于Capex和Opex的支出。Capex包括：故障發現以及全網絡的監控設施的投入（節點的各個層次的監控的投入）。Opex包括：在保證網絡的QOS和生存性的條件下，故障定位以及恢復策略。在GMPLS多層網絡故障定位，高效的故障定位要考慮下面的一些因素。1）故障的發現應盡可能近的接近故障的源頭；2）利用光層完成光復用有關的操作；3）利用多層的故障發現機制；4）利用上層的反饋；5）光路保護和鏈路保護的相結合。

綜合考慮上述因素，一方面，可以認識到高層OSI協議棧中包含容納故障的能力。其次在數據傳輸網絡中的大多數協議，他們為了發現傳輸過程中的故障檢測都對傳輸數據進行了冗余編碼。目前并不把這些反饋提供給物理層（光層）。但是，為了保證QOS，提出了利用上層反饋的跨層策略。另一方面，考慮到上層的監控設備。曾經在光網絡中應用的自下而上的策略恢復機制是可以應用在故障的定位。如果低層不能輕易的定位故障根源，則這個故障的定位的任務將交給上層的監控器。

3.1 實際中的GMPLS網絡的故障定位

在實際的GMPLS網絡中LSP是分層的，例如發端IP網絡要與一個收端IP網絡建立500 Mbps信道帶寬，則現實的網絡模型如圖2所示。

圖2 現實情況下的故障定位Fig.2 Fault localization in reality

利用GMPLS協議可以實現分層的LSP。則它的故障定位算法流程算法如圖3所示。

由GMPLS的節點可知LSR3與LSR4能夠檢測到WDM的故障與frame的故障，LSR2與LSR5能夠檢測到時隙幀的故障與分組的故障。LSR1與LSR6只能檢測分組的故障。

下面舉例說明：假如第1種情況，LSR1與LSR2之間發生故障則首先LSR3與LSR4的WDM監控檢測到故障，進行關聯操作之后，LSR3把WDM層的告警通知距離它最近的具有幀檢測能力節點進行時隙幀檢測，之后在和LSR2的幀檢測進行關聯操作，LSR1的分組檢測進行關聯操作，最終定位故障的根源LSR1的輸出鏈路上。假如第2種情況，在LSR4與LSR5之間發生故障，則LSR3與LSR4的WDM檢測沒有檢測到故障，但是LSR5的幀檢測檢測到故障，它與LSR3的第2層進行相關操作，進而定位故障在LSR3的輸出端。

3.2 算法中所用的故障定位協議

上述算法用到的協議是改進的LMP協議[6]。它是通過控制平面來實現故障的定位。當第1層發現故障時，則第一層的監控設備就會向控制平面發送一個告警信號，同理，第2層，第3層檢測到故障時，也會向控制平面發送告警信號。下文以第一層為例，說明改進的LMP協議。

圖3 有LSP分層的故障定位流程圖Fig.3 LSP hierarchical flow diagram of the fault localization

一般來說，兩個相鄰節點的數據鏈路故障可以影響許多下游鏈路（下游指的是數據的流動），從而造成許多告警進而觸發保護和恢復的處理。為了避免不必要的保護和恢復處理，提高網絡的效率，必須有一個快速，簡單的故障定位方案。雖然目前的GMPLS標準提供了方法去定位和數據鏈路的故障，但是這個方案沒有全面的考慮。造成了不必要的資源浪費。

通過對故障定位機制的定義，當一個數據鏈路故障發生時，每個發現故障的下游節點將通知上游臨近的節點一個消息。這個消息是故障鏈路信息中的一個—鏈路狀態信息。每個上游節點一旦收到這個故障通知信息，他就會給臨近的下游節點一個鏈路狀態信息收到的確認信息，目的是通知下游節點我已經收到了鏈路狀態信息。接著，凡是收到故障通知的節點將執行各自的故障相關處理。從而判斷故障是否是相應的LSP中的本身的故障。如果上游節點發現這個故障是自己內部的或輸出端口的，則這個上游節點定位這個故障，然后發送一個故障的告警去引發相應的路徑保護和恢復處理。同時，所有的收到故障通知的節點將給他的相應的下游節點發送一個信道狀態的信息去指示目前那個有問題鏈路的狀態（故障或正常）。如果下游節點沒有收到信道狀態信息，他將請求他的上游節點發送信道狀態信息，也就是下游向上游發送信道狀態信息請求信息。上游節點收到信道狀態信息請求信息必須回復一個信道狀態回復信息去告之下游節點鏈路的狀態。在目前的方案中，兩個相鄰節點故障定位的過程可以用圖4來說明。在一個擁有許多節點的網絡中，受到數據鏈路故障影響的所有相鄰節點有相同的過程。

圖4 目前方案下相鄰節點的故障定位處理Fig.4 Adjacent nodes of the fault location processing

這個故障定位方案有兩個嚴重不足的地方從而導致網絡性能的下降。首先，所有收到故障通知信息的節點將執行故障相關的操作。事實上，沒有必要每個節點都執行故障相關的操作，只有那些與故障相鄰的節點執行故障相關的操作就已經足夠去定位故障。這將導致許多沒有必要的故障處理，而且因為占用許多網絡資源，會造成網絡節點的效率降低，影響其他的一些緊迫操作。其次，在目前的故障定位過程有許多的冗余信息。目前的故障定位處理過程中，受到故障影響的每對相鄰節點至少要3個信息的交互。而通過修改發送信息的順序，其實2個信息就足夠完成同樣的功能。當一個數據鏈路的故障影響許多節點時，冗余的信息交互很大的浪費了控制信道的資源，增加了網絡節點的負擔。

3.3 改進的故障定位方案

基于上述提到的問題，文中提出一個新的故障定位處理方法，該方法應用雙向數據鏈路故障通知方法取代最新的GMPLS標準下的方案。在此方案中，當一個節點發現一個數據鏈路故障時，他將同時向上游和下游節點發送鏈路狀態信息。發送到上游相鄰節點的信息被用來通知鏈路故障，他的作用幾乎和目前解決方案中發送的鏈路故障信息的作用一樣。發送到下游相鄰節點的鏈路狀態信息有兩個作用。一個是通知下游節點它們之間的鏈路是正常的。這樣就可以避免了正常的數據鏈路被錯誤的隔離以及消除不必要的故障相關操作；另外一個作用是通知下游節點它已經找到了鏈路的故障，它已經收到了從下游節點發來的故障通知信息從而避免了同樣的信息重復發送。

當一個節點收到故障通知信息時，將證實是否已經在它們之間的鏈路上發現了故障。如果節點沒有在它們之間的鏈路上發現故障的記錄，他將執行故障關聯處理，確定故障的位置，這個操作和目前故障定位的操作類似。一旦定位了這個故障，這個節點就發送故障告警信息發起相應的路徑保護和恢復處理。然后，通知它的下游相鄰節點這個問題的鏈路的狀態。相反，如果節點收到了故障通知消息，它正好也檢測到這個鏈路的故障，就確認這個故障發生在上游鏈路，這個節點沒有必要執行故障定位操作。所以這個節點忽略了故障通知信息。圖5說明了在有4個節點網絡的新方案。通過應用新的方案，有下面的優勢：

圖5 改進的故障定位方案Fig.5 Improved fault localization program

1）對于定位數據鏈路故障的信令的開銷可以大幅降低。除了在受到鏈路故障影響的大多數相鄰節點之間的信令的交互和目前的方案相同，其他的節點通過兩個方向同時通知鏈路發生了故障，用了兩個信令信息完成了相同的功能（目前的方案用3個信令信息）。因為數據鏈路的故障經常影響網絡中的許多節點，所以該方案可以大幅減少定位鏈路故障的信令的開銷。

2）大幅降低占用的網絡資源。在我們的方案中，受到故障影響的所有節點，僅僅一個節點需要執行故障相關操作。因此，網絡節點定位故障的時間大幅降低。由于減少了信令開銷，從而降低了控制信道的帶寬和節點的信息處理時間。

3）可以避免錯誤的隔離正常的鏈路。在此方案中，當一個數據鏈路故障發生時，受到影響的鏈路的狀態將快速的通知相應的受到影響的節點。這個方法可以避免正常數據鏈路由于上游節點的故障而被錯誤的隔離，這些正常的鏈路還可以用來支持新的連接建立的請求。所以避免了不必要的網絡資源浪費，降低網絡資源的阻塞率。

4 結束語

GMPLS光網絡作為下一代新型網絡，它需要具有高速的數據傳輸率以及高質的服務質量，因而一旦出現故障將會對網絡造成很壞的影響，所以故障的快速定位就顯得尤為重要。本文在GMPLS光網絡現有的標準下提出了一種改進的故障定位方案，完善了其故障定位方面的一些功能，這對GMPLS光網絡的發展有著一定意義。

[1]E.Mannie Ed.Generalized Multi-Protocol Label Switching（GMPLS） Architecture[S].Interface，2004.

[2]Pinart C.A multilayer fault localization framework for IP over all-optical multilayer networks[J].IEEE Network，2009（5）:4-9.

[3]GUO Hai-bo，KUO Geng-sheng.Improvements on fault localization in GMPLS-based networks[J].IEEE HPSR，2005（5）:94-99.

[4]Li G，Yates J，Wang D，et al.Control plane design for reliable optical networks[J].IEEE Communication Magazine，2002（2）:90-96.

[5]Banerjee A，Drake L，Lang L，et al.Generalized multiprotocol label switching:an overview of signaling enhancements and recovery techniques[J].IEEE Communication Magazine，2001（7）:144-151.

[6]Ed J L.Link management protocol （LMP）[J].IETF RFC 4204，2005（10）:12-15.