“IOAM+SRv6”方案設計及實現

劉博聞，王嘉楠，吳軍平

（1.武漢郵電科學研究院，湖北武漢 430074；2.烽火通信科技股份有限公司，湖北武漢 430073）

OAM 是操作、維護、管理的融合統一。操作主要是完成對日常網絡和業務進行的分析、預測、規劃和配置工作；維護、管理主要是對網絡及其業務的測試、對故障進行管理[1]。IOAM 作為一種新的帶內遙測技術，用于業務在網絡中的質量檢測等功能。網絡遙感是一種網絡信息采集技術，目的是為了采集網絡中的信息，網絡遙感一般分為兩種，分別是主動探測和被動探測。被動探測以思科的Netflow 技術為代表，而主動探測則大多數類似于微軟Everflow中的guided probe 組件。它會在發送端的虛擬機中注入一種“探測數據包”，并在網元上設置一些探測識別點，探測數據包每經過一個網元都會上傳狀態信息，但是主動探測“注入探測數據包”會對當前網絡中的流量作出一些影響。被動探測以思科的Netflow 和INT（Inband Network Telemetry）為代表，具體應用為IOAM。Netflow 是一種帶外采集技術，而INT 是一種新型的“帶內網絡遙感技術”，具體實現方式是將監測檢查點插入數據包的內部，也就是途中的OAM 層，INT 通常的做法是在數據包的頭（Header）和數據包內部數據（Payload）之間插入一塊OAM 層，然后數據包經過每一個網元，都會將探測信息插入OAM 層中，包括網元對數據包的行為，是轉發還是丟棄，最后數據包到達終點，數據包中的OAM 層被剝離出來，通過信息導出協議上傳到遠程的分析服務器[2-5]。IOAM 的檢測方式目前已經應用在公司設備R8000E 上，為運營商提供服務。

1 原理概述

1.1 IOAM原理

報文從入接口進入，在封裝節點將OAM 數據報文嵌入在數據報文中，在轉發節點根據算法將相關的OAM 信息填入OAM 數據中，在解封裝節點，判斷IOAM轉發節點填入的OAM信息校驗路徑是否與配置的路徑一致，并將OAM 數據報文移除，如圖1所示。

圖1 IOAM網絡部署圖

IOAM 層由兩部分組成，一部分為instruction，即指令，另一部分為data，即數據，指令中攜帶需要收集的信息，Translation Node 只需要根據指令把相應的信息塞入data 部分中即可完成數據的收集。

IOAM 協議的承載形式有很多種，包括GRE、IPV6、SRv6、VXLAN-GPE、NSH、GENEVE 等。文中主要討論IOAM 承載SRv6 隧道。

1.2 SRv6隧道

SRv6 技術基于已經普及的IPv6 技術擴展報文頭部，對數據報文進行轉發處理[2]。當分段路由應用于IPv6 數據平面時，會引入一種路由擴展報頭—分段路由報文頭部[IPv6-SRH]。分段路由報文頭部(Segment Routing Header，SRH)將一些元數據添加到IPv6 數據包中，其中包含數據包必須經過轉發路徑元素的列表，并由IPv6 地址表示[3-10],如圖2 所示。

圖2 IOAM轉發模型

在Ingress 入口節點添加SID[N]和帶內流量信息遙測(In-situ Flow Information Telemetry,IFIT)的報文頭部，進行SRv6 動作類型的實現和網絡遙感的監測（IFIT 頭部）。其中SID 是使能SRv6 節點維護的一個本地SID（Local SID）表，該表包含所有在該節點生成的SRv6 SID 信息[11-12]，通過該表可以生成一個SRv6轉發表。Local SID 表有以下用途：定義本地生成的SID，例如End.X SID；指定綁定到這些SID 的指令；存儲和這些指令相關的轉發信息，包括出接口和下一跳等[13-17]。SRv6 SID 有很多類型，不同類型的SRv6 SID 代表不同的功能[9-10]，例如：

1）End SID 表示Endpoint SID，用于標識網絡中的某個目的地址前綴（prefix）；

2）End.DT4 SID 表示PE 類型的Endpoint SID，用于標識網絡中的某個IPv4 VPN 實例；

3）End.DX6 SID 表示PE 類型的三層交叉連接的Endpoint SID，用于標識網絡中的某個IPv6 CE。

還有多種類型用于實現不同功能。IFIT 報文頭部格式如圖3 所示。

圖3 IFIT報文頭部格式

Type：類型指示，表示擴展數據類型，顯示是否攜帶擴展頭；

Length：IFIT 長度，默認為8 字節；

L：Loss Flag，丟包測量染色標記；

D：Delay Flag，時延測量染色標記；

R：R Flag，保留位，預留未來擴展使用；

Flow ID：用于唯一標識一條業務流。

當芯片判定SRH 的標志位為1 時，表明SRH 攜帶了IOAM，然后通過IFIT 的Length 字段判斷IOAM的長度，同時根據HTI 字段判斷IOAM 的檢測方式，包括從入節點到出節點的端到端檢測和在轉發過程中的逐點檢測[6]。

IOAM 的報文轉發檢測需要經過源節點、中間節點和宿節點。IOAM 報文的封裝在源節點完成，其中包含IOAM 引導標簽和流標簽以及正確的L-bit、D-bit。運用IOAM 對報文進行篩選，通過ACL 匹配UNI 側流信息，對匹配上的報文進行封裝[7]。ACL 周期性的指向A Block 或B Block，CPU 實現L 的交替標記，在標記周期上添加Counter 功能，可以進行L 的標記統計，而D 報文則是每個周期標記一個。

中間節點則是對IOAM 進行L 統計和D 報文識別，宿節點是對RX/TX 方向的L 和D 數據進行性能統計，并將IOAM 標簽剝掉，完成IOAM 的轉發[8]。

2 IOAM+SRv6的方案設計

2.1 數據結構設計

IOAM中的數據流向是從平臺FDPO下發，傳遞給驅動層DDPO 數據結構，DDPO 數據從驅動層下發到數據轉發平面層，再從數據轉發平面層傳遞給微碼層面進行相應處理[4]。如圖4所示，代碼中接口是在驅動層從FHDRV接口開始調用，在FHDRV中調用數據轉發平面層接口，再通過Y接口進行寫入數據等操作。

圖4 驅動接口調用層次圖

FDPO 和DDPO 是兩種不同層面的數據結構體，通過IDE 工具構建而成。數據由FDPO 發送，傳遞到DDPO 數據模型中。IOAM 功能中，FDPO 的數據結構體需要定義不同字段并實現對應功能。

DDPO 是根據FDPO 定義的字段進行改動，定義驅動層需要的字段，構建DDPO 時，需要設計DDPO中的普通字段、驅動返回值、字段映射關系和DDPO依賴鏈關系。

DDPO 中定義了數據報文在IOAM 功能中傳輸所需的字段，如表1 所示。

表1 IOAM傳輸字段

這些字段根據不同的映射關系，通過數據結構依賴鏈從對應的FDPO 結構體中獲取數據。

在FDPO 中，數據的下發也是通過外鍵關聯，根據依賴鏈逐步下發的，相對應的DDPO 需要設計出數據下發的依賴鏈關系，如圖5 所示為IOAM 數據結構的依賴鏈關系。

圖5 DDPO依賴鏈關系

依賴鏈以IOAM_CFG 結構體為起始類，通過ifindex、first_nni_ifindex 和second_nni_ifindex 外鍵關聯到IFMGR_IF_NET 結構體，對于部分字段，還需通過index、if_foreign_key 和flexe_client_foreign_key 外鍵迭代到UES_IF、IFMGR_IF_LAG、FLEXE_CLIENT數據結構體，獲取對應的字段數據。

2.2 SRv6轉發方案

SRv6 的轉發方案結合L3VPN 的流程進行了設計[13-14]，如圖6 所示。

圖6 SRv6 L3VPN流程

數據報文從intf 入接口進入，根據最長匹配算法查找路由表，得到l3_path_id，根據該索引值查詢l3path 表項，在l3path 表項中配置保護類型，包括無保護、frr 保護和ecmp 保護，同時得到查詢l3nhi 表項的索引值，在l3nhi 表項中，entry_type 類型置為SRv6,并繼續查詢srv6_path 表，同時查詢srv6_sid 表項，獲取sid 的動作類型，srv6_path 表可以提供故障保護，并為查詢srv6_attr 屬性表提供索引id，srv6_attr 屬性表中則包含了出口信息、arp_id 等，通過查詢arp 表項得到出口，將數據報文轉發出去。

3 測試過程和結果

對于IOAM 功能，首先配置一條采樣周期為30 s，檢測方式為端到端的L3VPN SRv6 數據流，分別在出口進行L 標記統計和D 標記時延統計測試。

3.1 L標記統計

測試驗證源宿包統計是否正常，兩站均采用SSUA4 單盤，從UNI→NNI 建立一條SRv6 業務，保證業務流通暢。然后在源站和宿站下的IOAM 配置建立一條flow 為2 的IOAM 配置。登錄設備進入驅動層，打開flow_id 為2 的打印，psn_tmtry_dbg_flow_switch(2)，圖7、圖8 分別為源站、宿站L 標記統計。

圖7 源站L標記統計

圖8 宿站L標記統計

比較圖7 和圖8 可以看出，源站L 標記收包為L:rx[253320363]，宿站L 標記收包為L:rx[253320363]，源宿統計的包數相等，所以L 包統計正常，測試結果成功。

3.2 D標記時延統計

D 標記作為時延測量標志位，需要測試源宿的時延獲取是否正常。先建立SRv6 業務流，保證業務流暢通，再在源站和宿站配置IOAM 信息，建立一條flow id為2的IOAM配置。登錄設備后進入驅動層，打開flow id 為2 的打印，psn_tmtry_dbg_flow_switch(2)。圖9、圖10 分別為源站、宿站D 標記時延統計。

圖9 源站D標記時延統計

圖10 宿站D標記時延統計

由圖9 和圖10 比較可以看出，源站D 標記收包時間為D:rx[18029232],宿站D 標記收包時間為D:rx[18061888],兩者時延差為32 656 ms，即32.656 s，D標記時延統計正常，源宿時延差在30 s 左右，屬于誤差允許范圍內，滿足要求，測試結果成功。

4 結束語

IOAM 技術屬于數據包粒度級別的丟包檢測，檢測對象更加精細，甚至可以獲取網絡中的丟包情況、原因和丟包位置；IOAM 作為一種帶內技術，可以捕獲到網絡中的時延或丟包的時刻；同時，由于IOAM可以獲取網絡中的每一條鏈路的時延、帶寬以及丟包情況，將這些信息整合，選擇最優的網絡傳輸路徑，實現智能路由和選路。但IOAM 技術也存在一些明顯的缺點，比如在運營商等網絡中，發送、接收的數據包數量是巨大的，對每一個數據包插入OAM層并收集監測信息，會產生巨大的信息量，這些信息的壓縮、重分析也是一個需要考慮的問題[18-19]。而且巨大的信息量，需要不斷地申請新的空間進行數據拷貝和新OAM 層的插入，會產生更大的性能消耗。由于數據包會被分片，插入的OAM 長度也會有所限制，經過轉發的設備數量必然不能太多[20]。目前的IOAM 技術基本都是基于硬件實現，并與軟件相配合，隨著技術的發展，如果能將IOAM 應用于軟件轉發，則將為數據監測提供更大的應用平臺。