劉 冊
一、引言
ASON作為下一代傳送網，其主要特點是將控制平面與傳送平面分離，通過控制平面上信令協議的交互來實現對傳送光網絡的智能管理。 其中，鏈路資源作為業務的承載實體，無論是對于傳送平面的數據信息還是對于控制平面的信令協議都是至關重要的，它的管理機制是否有效直接影響到網絡的實際運營狀態，因而也倍受業界所關注。
二、鏈路資源管理技術標準化進程
各大國際標準化組織在推動ASON相關技術標準化進程方面，都投入了很大的精力。
ITU關于ASON的建議框架相對完備：G.8080定義了ASON控制平面的參考體系結構，規定了主要的功能模塊以及相互之間的作用；G.7712描述了數據通信網（DCN）的體系結構；G.7713規定了實現自動呼叫和連接操作所進行的處理需求，適用于UNI和NNI之間的分布呼叫和連接管理（DCM，distributed Call and connection management）；G.7714描述了用于網絡資源管理和選路的自動發現技術；G.7715描述了用于建立SC和SPC的路由功能的需求和體系結構；G.7716、G.7717、G.frame等建議也在制定過程中。其中和鏈路資源管理相關的標準有G.7714/G.7714.1和G.7716，但G.7714/G.7714.1主要偏重于自動發現技術的相關規定，而G.7716的內容還不穩定，最初是關于鏈路管理體系與需求的，最近關注的是控制平面的初始建立、重配置和恢復的相關內容。
IETF主要致力于開發Internet的標準和規范。在ASON的建議制定過程中，發揮了在IP技術方面的優勢，繼承IP路由協議和MPLS的信令體系，提出了GMPLS系列標準草案。其中和鏈路資源管理相關的部分是GMPLS鏈路管理——LMP協議。它是運行于兩個相鄰節點間用于流量工程（TE）鏈路管理的協議，包括控制通道管理、鏈路屬性關聯、鏈路連通性驗證、鏈路故障管理4個功能，前兩項是必備的核心功能，后兩項是用于應對控制通道與物理通道分離情況的可選擴展功能。
OIF致力于加速光互聯網的部署，其目標是提供提供終端用戶、設備制造商、業務提供商一體的光網絡解決方案，促進網絡互操作。在OIF開發的UNI標準中，是通過擴展的LMP來實現UNI對資源的管理。
不難看出，在目前的眾多協議中，LMP協議對鏈路資源管理的闡述是相對完整的，下面將主要論述LMP關鍵技術的相關內容。
三、鏈路管理協議——LMP(link Management Protocol)
LMP協議主要是針對網絡日益復雜、龐大，相鄰節點之間光鏈路數目不斷增加，如何能實現對鏈路的有效、智能管理，如何能實現鏈路故障的快速定位而提出的；其消息形式是基于IP封裝的。它包括以下4個功能：
3.1 控制通道管理
控制通道管理是用來建立和維護相鄰物理節點的控制通道，以便進行參數協商和信令信息的傳遞。它要求相鄰節點之間至少有一條可用的雙向控制通道（多條控制通道可作為備份）；并且要求相關傳送平面的本地和遠端節點的連通性和接口ID是已知的（通過管理平面或使用自動發現機制獲得），遠端節點支持傳送平面接口與電路蹤跡對象之間的關聯信息，對于SDH網絡，LMP使用SDH 電路蹤跡標識符（TTI, Trail Trace Identifier）。其工作機理如下：
1） 初始化配置過程
控制通道隨參數協商而開始被激活，使用的是Config, ConfigAck,和ConfigNack 消息。這些消息包括了建立控制通道所需的參數，參數可分為可協商和不可協商兩類，可協商的對象可以讓LMP雙方同意某一確定的值，而不可協商的對象用來指示某特定的值。
節點發送Config消息，控制通道進入配置狀態（當兩節點同時發送該消息時，NodeID編號大的享有發送優先級，編碼小的停止發送并且響應Config消息），如本節點收到對方的ConfigAck或ConfigNack消息響應，或者超時仍未收到ConfigAck或ConfigNack消息，本節點將停止發送Config消息，否則將周期發送Config消息。
2） 控制通道的維護
只有當節點發送或接收到ConfigAck消息，控制通道才進入激活（UP）狀態，此時通過周期性發送HELLO消息來實時維護通道的連通性；其中，HELLO消息的間隔時間（HelloInterval）和死亡間隔時間（HelloDeadInterval）在進行初始化的Config消息中配置。HELLO消息包括兩個重要的序列號：發送序列號（TxSeqNum）其初始值為1，隨后每發送一個HELLO消息加1；接收序列號（RcvSeqNum）啟動或重啟動時其值為0；（值得注意的是當一端節點HELLO消息重新啟動時，其發送序列號回到初始值1，接收序列號回到初始值0，而另一端節點在收到此消息時，會繼續累加記數，這時發送序列號和接收序列號將不是相差1；）HELLO消息的處理流程如圖1所示。
圖1 Hello消息的處理流程
另外，為了在管理需要的時候關閉控制通道，在LMP包的通用頭部（Common Header）中設置了一個ControlChannelDown標志。控制通道關閉的過程可能在超過 HelloDeadInterval時間之后停止發送Hello消息，當節點接收到一個設置了ControlChannelDown 標志LMP包時，它應該發送一個Hello消息（其中攜帶已經置位的ControlChannelDown標志），并且使控制通道切換至Down 狀態。
3） 故障管理
由于控制通道和相關聯的數據鏈路在物理上存在相互分離的可能，當出現故障，沒有可利用的控制通道時，數據鏈路仍在使用。若因此而關閉一條正在使用的數據通道顯然是不可被接受的。故此時應將數據鏈路置為降級（Degraded）狀態，并應通知路由管理，使其不再接收新的連接。
3.2 鏈路屬性關聯
鏈路屬性關聯可以將多條數據鏈路匯聚成一條TE鏈路，并同步鏈路屬性，這將大大減少網絡中鏈路狀態廣播（LSA）消息的發送。在鏈路屬性關聯過程中可進行鏈路綁定，可以修改、關聯和交換鏈路的流量工程參數，最終確保相鄰節點之間TE鏈路屬性的一致，使相鄰節點就數據鏈路的性質和容量等參數達成共識。LMP鏈路屬性關聯消息有：LinkSummary,LinkSummaryAck和LinkSummaryNack。其處理流程與控制通道管理初始化相似：鏈路進入UP狀態，周期性發送LinkSummary消息，如對方節點同意LinkSummary消息中所有屬性和端口映射關系則返回LinkSummaryAck 消息，否則返回LinkSummaryNack消息并指明不同意的屬性和端口映射。
3.3 鏈路連通性驗證
鏈路連通性驗證用來驗證數據鏈路的物理連通性，以及本地ID到遠端ID的映射；其最大的好處是通過驗證可以得到一張標有確定鏈路狀態的本地——遠端ID映射表。
LMP鏈路連通性驗證過程通過控制通道上的BeginVerify 消息來協調，并且需要控制通道和數據通道協同進行。這是一個可選的過程，由參數協商過程配置可協商的驗證標志（VerificationFlag）決定。具體過程如下：
源端向遠程節點發送BeginVerify消息（攜帶認證間隔、數據鏈路數目、編碼類型、認證傳輸機制、傳輸速率、波長等信息），如果遠程節點回應BeginVerifyAck消息，其必須攜帶32bit的Verify ID（用于唯一標志特定的鏈路連通性驗證實例），并且被其他所有在源和目的之間驗證關聯消息拷貝共享；如果遠程節點回應BeginVerifyNack消息即表示遠程節點不能或者不愿意進行鏈路連通性驗證。
在源端收到BeginVerifyAck消息后，表明協商成功，驗證開始。源端節點將會在指定數據鏈路上發送Test消息（攜帶了該數據鏈路編號和源端節點端口/接口編號），遠程節點用Verify ID來加速特定的驗證過程，并且映射遠程接口ID給相應的本地值。接著通過控制通道傳送TestStatusSuccess消息（攜帶遠程節點接口ID）返回源端節點（如果遠程節點不能在認證間隔內收到Test消息，則通過控制通道發送TestStatusFailure消息給源端節點報告錯誤）。
此時源端節點將通過控制通道返回TestStatusAck消息進行確認，當所有數據鏈路驗證結束，源端節點將通過控制通道發送EndVerify消息，遠程節點收到EndVerify消息后返回EndVerifyAck消息結束整個驗證過程，其驗證過程如圖2。
圖2 鏈路連通性認證過程
需要指出的是在驗證過程中只有Test消息是在數據鏈路上傳遞的，其他消息是在相應的控制通道上傳遞的。另外，在認證初始狀態中BeginVerify消息中鏈路區域的本地鏈路ID（LOCAL_LINK_ID）一般情況下應為非0值，其目的是為了限制鏈路認證程序通過特殊TE鏈路，例如一條正在使用的鏈路；如果此區域為0值，則代表驗證所有鏈路。
3.4 鏈路故障管理
LMP提出的故障定位的機制是由下游檢測到數據鏈路故障的節點發起，通過通道故障消息以及回復消息的交互，沿著LSP向上游逐跳檢測鏈路狀態，直到定位到發生故障的鏈路。這種方式的好處是可對故障作出快速反應并可精確定位故障是否發生在本地節點。
LMP故障管理過程基于通道狀態（ChannelStatus） 交換，其使用的消息有：通道狀態（ChannelStatus）, 通道狀態應答（ChannelStatusAck）,通道狀態請求（ ChannelStatusRequest） 和通道狀態響應（ChannelStatusResponse）。
1）故障定位的判決
故障探測是在物理層完成。連接兩個節點的TE鏈路可能包括多個數據鏈路。如果兩個節點間一個或更多的數據鏈路發生故障，必須有一個用于快速故障通知的機制，以產生適當的保護/再生機制。如果故障隨后就被清除，則必須有一個機制用來通知故障以被清除，鏈路狀態OK。對于全光交換設備其故障探測僅限于光信號本身，目前比較常見的一種方式是探測光衰耗（LOL），而故障定位依據探測結果進行判決，但其本身是獨立于探測機制的。
2）故障定位過程
如果光交叉連接設備（OXCs）之間的數據鏈路發生故障，所有下游接點的監控系統將探測到LOL并且顯示故障發生。為避免同一故障的多重報警， ChannelStatus消息可提供某單個數據通道失效，多個數據通道失效或者整個TE鏈路失效三種顯示方式；基于接收到故障通知，在每個節點實現了故障關聯。為把故障定位在兩個相臨的OXCs之間的特殊鏈路，探測到故障的下游節點將發送一個ChannelStatus 消息到它的上游相鄰節點，顯示故障已經發生（所有故障數據鏈路的通知都綁定在一起）。接收到ChannelStatus 消息的上游節點應返回一個ChannelStatusAck 消息到下游節點，顯示它已經接收到ChannelStatus消息。上游節點應該關聯故障，看看故障是否也在相應LSP的本地被探測到。如果說，故障在上游節點的入口或內部被標注并上報網管，那么上游節點便定位好了故障。一旦故障被關聯，上游節點應該發送一個ChannelStatus消息到下游節點顯示通道失效。如果ChannelStatus消息沒有被下游節點接受到，它應該發送一個ChannelStatusRequest 消息，若此時下游節點收到ChannelStatusRequest 消息它將返回一個ChannelStatusResponse消息并顯示被詢問的數據鏈路的狀態。
可見，通過上述4個功能，已經初步形成一個對數據通道和控制信道管理的閉環系統，基本滿足了人們在最初設計時的初衷。當然，在具體應該過程中，各個廠商會根據自己的設備、網絡的結構以及業務運營商的需求對各個功能進行細化和取舍。
四、總結
LMP協議作為一個相對完整鏈路資源管理協議，在傳送平面上已經可以完成對數據鏈路的分類、綁定、標識、可用性以及故障定位的管理，在控制平面上也可以完成對控制通道自身的維護，初步實現了智能化。然而，傳送光網絡的
智能化是期望人為的干預盡量減少，網絡的自我調節能力，合理分配鏈路資源的能力不斷增強。這不僅需要鏈路資源管理協議的進一步細化、完善，更需要相關的機制配合發展，如自動發現機制、光鏈路性能的監測技術以及與管理平面數據交換能力的提高，它們是相輔相成、相互制約的有機整體。值得注意的是，并不是功能越多，甄測的性能數據越多，鑒別的帶寬資源越細化，網絡的利用率越高，網絡的服務質量越好，網絡越健壯。這猶如一柄雙刃劍，當一個過于復雜的管理協議出現在網絡中時，必然增加各個節點
信息處理負擔，阻礙網絡資源的有效傳送。所以把握尺度，整合各功能模塊協調運作是發展的關鍵。
