專利名稱：：一種提高rsvp-te隧道可靠性的方法
技術領域：
：本發(fā)明涉及多協(xié)議標簽交換MPLS技術體系中的流量工程TE
技術領域：
，具體涉及一種提高資源預留協(xié)議RSVP-TE隧道可靠性的方法。
背景技術：
：(-)問題來由在MPLS技術體系中，流量工程是其中一個非常重要的應用。RSVP信令協(xié)議最初是用來在IP轉發(fā)的網(wǎng)絡里面建立綜合服務質量Inter-ServQos才莫型的應用，而RSVP信令的擴展(請求評i侖文檔RFC3209),則用來在MPLS轉發(fā)域里面建立TE隧道(RSVP-TEorMPLS-TE)，TE隧道是單方向的，因此標記交換路徑LSP路徑也是單方向的。RSVP信令協(xié)議主要包含的消息類型，如下表<table>tableseeoriginaldocumentpage3</column></row><table>RSVP-TE隧道建立的基本過程如圖1所示，5臺路由器Rl-R5組成的網(wǎng)絡，現(xiàn)要在Rl到R4上建立一條TE隧道，此TE隧道只包含一條LSP路徑，具體包括Rl首先要根據(jù)配置計算得出這條LSP路徑要經(jīng)過的設備，路徑是R2，R3，R4;然后，Rl發(fā)出Path消息給R2，R2處理此Path消息，然后再發(fā)送Path消息給R3,同樣R3處理此Path消息，然后發(fā)送Path消息給R4,R4收到Path消息，發(fā)現(xiàn)自己是最后的一個節(jié)點，于是在處理了此Path消息之后，按照原路徑，向R3發(fā)送Resv消息，R3處理此Resv消息，然后發(fā)送Resv消息給R2，同樣R2處理此Resv消息，再發(fā)送Resv消息給Rl,Rl是此LSP的頭結點，當Rl收到Resv消息之后，這條LSP就建立成功了；之后Path消息和Resv消息就在這幾臺路由器之間周期性的發(fā)送，用來保持LSP的狀態(tài)。RSVP協(xié)議建立LSP標簽轉發(fā)路徑是采用下游按需Downstream-On-Demand模型。Path消息中含有邀請標簽LABEL—REQUEST對象，而Resv消息中含有標簽LABEL對象，標簽值就在LABEL對象里面。在RFC3209的描述中，規(guī)定了"下游節(jié)點選擇一個標簽值來表示這條路徑"(Thedownstreamnodeselectsalabeltorepresenttheflow),并且說明了"如果標簽值發(fā)生變化，希望節(jié)點能在刷新時間超時前，發(fā)出Resv消息"(AnodeisexpectedtosendaResvmessagebeforeitsrefreshtimersexpireifthecontentsoftheLABELobjectchange)。RFC3209并沒有對標簽值發(fā)生變化之后，協(xié)議操作具體細節(jié)進行明確，這也就導致了各廠家在這個地方實現(xiàn)的差異。(二)現(xiàn)有處理方式在目前的實踐中，需要發(fā)生標簽改變的情況主要是在LSP的尾節(jié)點進行了采用了默認空implicit-null的配置，其它中間節(jié)點發(fā)生標簽改變的情況并不多，隨著技術發(fā)展，相信這樣的應用也會漸漸成熟。CISCO的路由器進行測試時，兩臺路由器直連，建立LSP，用路由器自帶的因特網(wǎng)包探索器ping工具，按照默認頻率在這條LSP上打ping報文，然后進行LSP尾節(jié)點標簽值變化操作，整個過程會造成LSP中斷1個ping^R文的發(fā)送時間！CISCO的實現(xiàn)是在標簽變化時，尾節(jié)點先發(fā)送路徑拆除ResvTear消息拆除LSP,然后頭結點發(fā)出PathTear，此時LSP就已經(jīng)被拆除了；然后頭結點再立刻發(fā)出Path消息重新建立LSP;這樣的實現(xiàn)，LSP中斷是必然。
發(fā)明內(nèi)容本發(fā)明需要解決的技術問題是如何提供一種提高RSVP-TE隧道可靠性的方法，避免在標簽變化時發(fā)生的LSP中斷。本發(fā)明的上述技術問題這樣解決，提供一種提高RSVP-TE隧道可靠性的方法，TE隧道下游節(jié)點在需要改變標簽值時直接發(fā)送更新標簽值的Resv消息給上游節(jié)點并在更新成功前同時接收對應新和舊兩個標簽值，成功后可只接收更新后的標簽值。按照本發(fā)明提供的方法，所述TE隧道下游節(jié)點是尾節(jié)點或中間節(jié)點。按照本發(fā)明提供的方法，該方法還包括所述上游節(jié)點接收所述Resv消息并更新自身標簽值映射表，完成后向下游節(jié)點所述發(fā)送用于確認的Path消息。按照本發(fā)明提供的方法，該方法還包括在所述下游節(jié)點在接收到所述Path消息之前同時4妄收對應新和舊兩個標簽值，在4妻收后只接收更新后的標簽值。按照本發(fā)明提供的方法，所述Path消息是周期發(fā)送，該周期與標準Path發(fā)送周期相同或不同。按照本發(fā)明提供的方法，所述Resv消息是周期發(fā)送，所述上游節(jié)點接收所述Resv消息發(fā)現(xiàn)標簽變化后更新自身標簽值映射表，該周期與標準Resv發(fā)送周期相同或不同。按照本發(fā)明提供的方法，所述TE隧道包含一條或者多條標記交換路徑LSP。按照本發(fā)明提供的方法，該方法僅適用于單播多協(xié)議標簽交換MPLS網(wǎng)。本發(fā)明提供的一種提高RSVP-TE隧道可靠性的方法，僅適用于單播MPLS網(wǎng)，在LSP的下游，不管什么情況，如果設備所使用的標簽(LABEL)需要發(fā)生變化，下游節(jié)點直接發(fā)送更新標簽值的Resv消息給上游節(jié)點并在更新成功前同時接收對應新和舊兩個標簽值，這樣能夠保證已建立成功的LSP在標簽變化的過程中不會發(fā)生流量中斷，確保經(jīng)過這條LSP的報文不會出現(xiàn)丟包。圖1是本發(fā)明一個示例的網(wǎng)路圖。具體實施方式下面結合附圖和具體實施例進一步對本發(fā)明進行詳細說明。首先，說明本發(fā)明的主要思想當下游節(jié)點需要改變標簽值的時候，如果是LSP的尾節(jié)點，則不需要發(fā)送拆除消息ResvTear來拆除LSP，而是直接發(fā)送更新標簽值的Resv消息給上游節(jié)點；如果不是尾節(jié)點，同樣是直接發(fā)送更新標簽值的Resv消息給上游節(jié)點。本發(fā)明的內(nèi)容涉及2類消息Path消息和Resv消息。第二步，舉例說明本
發(fā)明內(nèi)容如圖1所示，j艮設從路由器Rl到R4的LSP已經(jīng)建立起來，現(xiàn)在R4作為尾節(jié)點，要改變標簽值，變化之前的標簽值是a，現(xiàn)在要變成b(我們這里不考慮什么原因導致的變化)；則R4直接向R3發(fā)送更新標簽值的Resv消息(此Resv消息帶有更新標簽值的標志和新的標簽值)，R3收到Resv消息之后，發(fā)現(xiàn)標簽值3艮之前不一樣，并且?guī)в懈聵撕炛档臉酥?，R3立刻更新自己的標簽值映射表，然后采用新的標簽值來轉發(fā)報文；R3完成它自己的動作之后，立刻發(fā)送一個Path消息(此Path消息帶有一個更新標簽成功的標志)給R4用以確定；而R4在準備好新的標簽值之后，在發(fā)送更新標簽值的Resv消息之前，就要先準備好在從這個時候開始，要同時接受a和b這兩個標簽值，直到R4收到R3的帶確認的Path消息為止。如果R3更新標簽值失敗，同樣需要發(fā)送一個帶確認的Path消息給R4。具體消息格式參見后面的介紹。在上述的過程中，R3收到更新標簽值的Resv消息之后，更新自己的標簽映射表，然后使用新的標簽轉發(fā)報文并發(fā)送帶確認的Path消息。正常情況R3會周期性的給R4發(fā)送Path消息，但是這個帶確認的Path消息不在周期之內(nèi)，也可以不影響正常的Path發(fā)送周期。注意，每一個標簽值被成功更新，都需要Path消息確認；在一個Path消息中，可以確認一個標簽值的成功更新，也可以同時確i人多個。R4在發(fā)送更新標簽值的Resv消息之前，一定要準備好同時接受a和b這兩個標簽值，這樣才能保證LSP流量不發(fā)生中斷，直到R4收到了R3帶確認的Path消息之后，R4才可以放棄接受原來的標簽a。如果R4收到的是更新失敗的確認，則R4可能繼續(xù)嘗試更新標簽值，也可以放棄更新，繼續(xù)采用原來的標簽值a來處理報文。R4發(fā)送的更新標簽值的Resv消息，也可以在Resv消息發(fā)送周期之外。同樣，如果是R3(LSP的中間結點)需要改變標簽值，需要向上游節(jié)點R2發(fā)送更新標簽值的Resv消息，整個過程和上面描述的完全一樣。下面介紹更新標簽值的Resv消息和帶確認的Path消息為了保持跟RFC3209的兼容，本方法為這兩個消息定義了一個新的對象，叫做LABEL—CHANGE對象，CLASSNUMBER等于60。<table>tableseeoriginaldocumentpage7</column></row><table>此對象長度為4個字節(jié)，內(nèi)容是一個12位長的Flag字段和20位長LabelValue字段。Flag=1時,此RSVP消息必須為更新標簽值的Resv消息；此時LabelValue字段的內(nèi)容無效，新的標簽值由LABEL對象提供；Flag二2時，此RSVP消息必須為確認標簽更新成功的Path消息；此時LabelValue字段的內(nèi)容表示更新成功的標簽值，用來給下游節(jié)點進行確認，因為有可能出現(xiàn)下游節(jié)點同時更新多個標簽值的情況；Flag二3時，此RSVP消息必須為確認標簽更新成功的Path消息，表示標簽更新失敗，此時LabelValue字段的內(nèi)容表示更新失敗的標簽值。新的Path消息格式如下<PathMessage〉=〈CommonHeader〉[<INTEGRITY>]<SESSION><RSVP—HOP><TIME—VALUES>[<EXPLICIT—ROUTE>]<LABEL—REQUEST〉[<labelchangelist>][<SESSION—ATTRIBUTE〉][<POLICYDATA>...J〈senderdescriptor)<labelchangelist〉=<LABEL—CHANGE〉|[<labelchangelist〉]新的Resv消息才各式如下<ResvMessage〉=〈CommonHeader〉[<INTEGRITY>]<SESSION><RSVP—HOP><TIME—VALUES〉[<RESV—CO麗畫〉][<SCOPE>][〈POLICY一DATA〉…]<STYLE><flowdescriptorlist〉<flowdescriptorlist>::=<FFflowdescriptorlist>|<SEflowdescriptor><FFflowdescriptorlist〉=〈FLOWSPEO〈FILTER—SPEC><LABEL〉[<LABEL—CHANGE〉][<RECORD—ROUTE>]I<FFflowdescriptorlist><FFflowdescriptor><FFflowdescriptor)::=[〈FLOWSPEO]〈FILTER—SPEO<LABEL>[<LABEL—CHANGE〉][<RECORDROUTE>]<SEflowdescriptor)::=<FLOWSPEC><SEfilterspeclist><SEfilterspeclist>::=<SEfilterspec>I<SEfilterspeclist><SEfilterspec><SEfilterspec〉=<FILTER—SPEO<LABEL>[<LABEL—CHANGE〉][〈RECORD—ROUTE〉]消息格式的詳細信息請參考RFC3209。在本發(fā)明中，一個TE隧道可能包含一條或者多條LSP路徑，在LSP的下游，如果設備所使用的標簽(LABEL)需要發(fā)生變化(不管什么情況)，此方法可以保證已建立成功的LSP在標簽變化的過程中不會發(fā)生流量中斷，確保經(jīng)過這條LSP的報文不會出現(xiàn)丟包。本發(fā)明僅適用于單播的MPLS網(wǎng)絡。權利要求1.一種提高RSVP-TE隧道可靠性的方法，其特征在于，TE隧道下游節(jié)點在需要改變標簽值時直接發(fā)送更新標簽值的Resv消息給上游節(jié)點并在更新成功前同時接收對應新和舊兩個標簽值。2、根據(jù)權利要求1所述方法，其特征在于，所述TE隧道下游節(jié)點是尾節(jié)點或中間節(jié)點。3、根據(jù)權利要求1所述方法，其特征在于，所述方法還包括所述上游節(jié)點接收所述Resv消息并更新自身標簽值映射表，完成后向所述下游節(jié)點發(fā)送用于確認的Path消息。4、根據(jù)權利要求3所述方法，其特征在于，所述方法還包括在所述下游節(jié)點在接收到所述Path消息之前同時接收對應新和舊兩個標簽值。5、根據(jù)權利要求3所述方法，其特征在于，所述Path消息是周期發(fā)送。6、根據(jù)權利要求5所述方法，其特征在于，所述周期與標準Path發(fā)送周期相同或不同。7、根據(jù)權利要求1或3所述方法，其特征在于，所述Resv消息是周期發(fā)送，所述上游節(jié)點接收所述Resv消息發(fā)現(xiàn)標簽變化后更新自身標簽值映射表。8、根據(jù)權利要求7所述方法，其特征在于，所述周期與標準Resv發(fā)送周期相同或不同。9、根據(jù)權利要求1所述方法，其特征在于，所述TE隧道包含一條或者多條標記交換路徑。10、根據(jù)權利要求1所述方法，其特征在于，該方法適用的范圍包括單播多協(xié)議標簽交換網(wǎng)。全文摘要本發(fā)明涉及一種提高RSVP-TE隧道可靠性的方法，TE隧道下游節(jié)點在需要改變標簽值時直接發(fā)送更新標簽值的Resv消息給上游節(jié)點并在更新成功前同時接收對應新和舊兩個標簽值。這種方法適用于單播MPLS網(wǎng)，在LSP的下游，不管什么情況，如果設備所使用的標簽LABEL需要發(fā)生變化，都能夠保證已建立成功的LSP在標簽變化的過程中不會發(fā)生流量中斷，確保經(jīng)過這條LSP的報文不會出現(xiàn)丟包。文檔編號H04L12/56GK101257448SQ20081008959公開日2008年9月3日申請日期2008年4月3日優(yōu)先權日2008年4月3日發(fā)明者周蕙菁,張新林申請人:中興通訊股份有限公司