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