[發明專利]多協議交換標簽的檢測、處理方法、裝置及系統

在審

• 申請號: 201610567070.4
• 申請日: 2016-07-15
• 公開（公告）號: CN107623584A
• 公開（公告）日: 2018-01-23
• 發明（設計）人: 彭少富
• 申請（專利權）人: 中興通訊股份有限公司
• 主分類號: H04L12/24
• 分類號: H04L12/24;H04L12/723
• 代理公司: 北京康信知識產權代理有限責任公司11240
• 代理人: 江舟,董文倩

技術領域

本發明涉及通信領域，具體而言，涉及一種多協議交換標簽的檢測、處理方法、裝置及系統。

背景技術

相關技術中，P2P(peer to peer)LSP ping/trace與P2MP(peer to multiple peer)LSP ping/trace通過將多協議交換標簽(Multi-protocol Label Switching，簡稱為MPLS)運行、管理和維護(Operation Administration and Maintenance，簡稱為OAM)報文按與MPLS數據報文轉發一致的路徑傳輸，數據平面不識別是MPLS OAM報文，當報文因標簽生存時間(Time To Live，簡稱為TTL)超時或到達egress節點等原因從數據平面上送至控制平面時，才由控制平面識別是MPLS OAM報文并作后續處理。rfc4379(標記交換路徑(Label Switching Path，簡稱為LSP)ping/trace)與rfc5884(MPLS BFD)都通過基于IP頭的TTL＝1與目的IP為127.0.0.0/8(IPv4)或0:0:0:0:0:FFFF:127.0.0.0/104(IPv6)這些標志來初步識別是MPLS OAM報文，以及rfc5586(MPLS g-ACH)通過GAL(特殊標簽13)標志來識別是MPLS OAM報文，但是這些都不適合于不想對報文做深度解析來識別具體報文的數據平面，當這些標志在數據平面沒有暴露，沒有導致MPLS OAM報文從數據平面上送至控制平面時，則數據平面不知道它是一個MPLS OAM報文。

數據鏈路層雖然定義了類型字段識別是MPLS單播報文還是組播報文(rfc3032，rfc5332)，但是并沒有相應的標準定義識別是MPLS OAM報文還是MPLS數據報文，除了以太鏈路定義了ethernet type用于特定的以太OAM機制(如802.1ag,802.3ah,Y.1731)以外，但是這些定義不能適用于MPLS OAM。

一些場景下，數據平面也需要通過某種快捷的方式提前感知是MPLS OAM報文，在遵循與MPLS數據報文轉發一致的前提下，做一些與轉發路徑無關的輔助處理。

相關技術中的P2P LSP ping/trace標準存在如下問題：

1)按照rfc4379，檢測的target FEC存在ECMP時，通過在控制平面模擬負荷分擔劃分multipath information為多個分片，然后基于劃分結果發送多個echo request(分別包含不同的multipath information分片)以期望遍歷出完整的路徑。存在的關鍵問題是：a)控制平面的模擬負荷分擔結果不一定與數據平面的實際負荷分擔結果相同；b)原始的multipath information可能無法滿足負荷分擔的分片需求，即存在不夠分的問題。這些都導致檢測失真。實際上，LSP ping的本質需求是檢測數據平面連通性以及保證數據平面與控制平面的轉發表項一致，只要我們將MPLS OAM報文嚴格的按照數據平面的真實負荷分擔轉發即可。

2)按照rfc6424，在檢測過程中若發生FEC change，需要感知FEC change的節點向Initiator節點返回FEC change信息，以便Initiator在后續echo request中攜帶變化后的target FEC stack。但是該標準存在一個明顯的缺陷是只適用于trace route模式，而ping模式時感知FEC change的節點是不會向Initiator節點返回FEC change信息，這意味著要只要發生了FEC change，執行LSP ping將會得到路徑不通的結果。

相關技術中的P2MP LSP ping/trace標準存在如下檢測低效與不充分的問題：

1)按照rfc6425，Initiator并沒有精確控制echo reply報文是否收齊后發起下一次echo request，也就是說，發送下一次request的時機是不定的。如果Initiator每收到一個echo reply就發送下一個echo request，那么它需要緩存大量的歷史echo request以便等待那些晚到的echo reply。

2)由于echo request的發送沒有嚴格控制，那么收到的echo reply可能會爆發而導致擁塞。雖然提出了解決方法，但是并不完美。比如，返回echo reply時隨機延時的方法會拖慢檢測過程；只讓特定節點返回echo reply的方法則僅支持指定單個節點或指定至單個egress的沿路節點。