SRv6頭壓縮技術(shù)方案研究

龔霞，陳華南，朱永慶，伍佑明，阮科

SRv6頭壓縮技術(shù)方案研究

龔霞1，陳華南2，朱永慶1，伍佑明1，阮科1

（1. 中國電信股份有限公司研究院，廣東 廣州 510630；2. 中國電信天翼云科技有限公司，廣東 廣州 510245）

數(shù)字化、智能化承載網(wǎng)絡(luò)成為網(wǎng)絡(luò)建設(shè)與運營的主要目標(biāo)，承載協(xié)議作為實現(xiàn)網(wǎng)絡(luò)互聯(lián)與業(yè)務(wù)承載的關(guān)鍵技術(shù)，直接決定了網(wǎng)絡(luò)規(guī)模部署能力與業(yè)務(wù)承載效率。面向一致性體驗與差異化融合承載需求，IPv6段路由（IPv6-based segment routing，SRv6）作為IPv6演進的關(guān)鍵技術(shù)，成為未來網(wǎng)絡(luò)承載協(xié)議的發(fā)展方向。基于SRv6技術(shù)原理，剖析了SRv6頭壓縮需求，并結(jié)合業(yè)界典型的SRv6頭壓縮方案分析了各方案的優(yōu)劣，為SRv6技術(shù)規(guī)模部署提供指引。

SRv6；頭壓縮；承載協(xié)議

0 引言

網(wǎng)絡(luò)技術(shù)的發(fā)展以IP/Ethernet技術(shù)體系為基礎(chǔ)，通過網(wǎng)絡(luò)架構(gòu)優(yōu)化及技術(shù)創(chuàng)新，滿足各類應(yīng)用/業(yè)務(wù)的承載需求。面向5G與云網(wǎng)融合時代，新型業(yè)務(wù)不斷涌現(xiàn)，如云VR/AR、物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)等。業(yè)務(wù)多樣化發(fā)展的同時，對網(wǎng)絡(luò)實現(xiàn)各類用戶/業(yè)務(wù)的融合承載與差異化服務(wù)等方面也提出了更高要求。雙千兆接入[1]、云網(wǎng)一線互聯(lián)實現(xiàn)了網(wǎng)絡(luò)對固、移、云多業(yè)務(wù)的融合接入[2]，以及toB/toC/toH等差異化業(yè)務(wù)的一體化承載。SRv6作為新型承載協(xié)議具備underlay轉(zhuǎn)發(fā)、overlay業(yè)務(wù)可編程能力[3]，可滿足網(wǎng)絡(luò)與業(yè)務(wù)靈活編排，具備較好的應(yīng)用前景，受到了產(chǎn)業(yè)界的廣泛關(guān)注。

SRv6基于源路由技術(shù)，輔以分段標(biāo)識（segment ID，SID）編碼，可實現(xiàn)業(yè)務(wù)及路徑可編程。同時，結(jié)合以太虛擬局域網(wǎng)（Ethernet virtual private network，EVPN）技術(shù)可簡化網(wǎng)絡(luò)協(xié)議，這成為未來IP網(wǎng)絡(luò)承載技術(shù)的發(fā)展趨勢。然而，SRv6在提升網(wǎng)絡(luò)靈活性的同時，也帶來了網(wǎng)絡(luò)承載效率降低的問題，為此，SRv6頭壓縮技術(shù)應(yīng)運而生[4]。本文對SRv6頭壓縮技術(shù)需求進行分析，探討業(yè)界典型SRv6頭壓縮實現(xiàn)方案，并基于不同場景對各方案的承載效率進行仿真分析，為后續(xù)SRv6技術(shù)的規(guī)模部署提供參考。

1 SRv6技術(shù)基礎(chǔ)

縱觀網(wǎng)絡(luò)技術(shù)發(fā)展歷史，網(wǎng)絡(luò)承載技術(shù)經(jīng)歷了4個發(fā)展階段，分別為純IP承載階段、多協(xié)議標(biāo)簽交換（multi-protocol label switching，MPLS）承載階段、段路由（segment routing，SR）承載階段和SRv6承載階段。純IP承載階段以內(nèi)部網(wǎng)關(guān)協(xié)議（interior gateway protocol，IGP）/外部網(wǎng)關(guān)協(xié)議（border gateway protocol，BGP）為基礎(chǔ)，轉(zhuǎn)發(fā)面采用IP流量盡力而為的轉(zhuǎn)發(fā)方式。MPLS承載階段則增加了標(biāo)簽分發(fā)協(xié)議（label distribution protocol，LDP）/基于流量工程擴展的資源預(yù)留協(xié)議（resource reservation protocol-traffic engineering，RSVP-TE）等，實現(xiàn)了差異化業(yè)務(wù)承載及流量工程，進一步豐富了網(wǎng)絡(luò)應(yīng)用。隨著SR技術(shù)的發(fā)展，網(wǎng)絡(luò)技術(shù)進入SR承載階段，SR轉(zhuǎn)發(fā)面依然采用MPLS標(biāo)簽的轉(zhuǎn)發(fā)方式，但簡化了控制面協(xié)議，且基于源路由的承載方式可以更好地適應(yīng)軟件定義網(wǎng)絡(luò)（software defined network，SDN）體系。而SRv6則是IPv6演進技術(shù)創(chuàng)新發(fā)展的產(chǎn)物，控制面基于IGP/BGP擴展，轉(zhuǎn)發(fā)面則基于IPv6擴展報頭實現(xiàn)，進一步簡化了網(wǎng)絡(luò)承載。

1.1 SRv6定義

SRv6技術(shù)以IPv6報文頭為基礎(chǔ)，重新定義了路由擴展報文頭分段路由頭（segment routing header，SRH）[5]封裝SRv6 SID相關(guān)信息。SRH中通過封裝SID列表（Segment List）實現(xiàn)路徑定制。SRv6 SID采用IPv6地址格式，可用于標(biāo)識節(jié)點、接口及虛擬專用網(wǎng)（virtual private network，VPN）等信息。每個128 bit的SID可劃分為Locator、Function和Argument 3個部分，其中，Locator為節(jié)點標(biāo)識，用于路由尋址；Function為功能標(biāo)識，是實現(xiàn)SRv6可編程的關(guān)鍵字段；Argument為參數(shù)字段，通過攜帶參數(shù)信息可實現(xiàn)功能增強，為可選字段。

SRv6 SID基于上述特點，可在業(yè)務(wù)報文中顯示指定轉(zhuǎn)發(fā)路徑及VPN等業(yè)務(wù)功能，簡化了設(shè)備實現(xiàn)，提升了網(wǎng)絡(luò)靈活性。

1.2 SRv6承載難題

SRv6基于SRH實現(xiàn)網(wǎng)絡(luò)編程的方式，在一定程度上增加了報文的開銷；且隨著跳數(shù)增加，網(wǎng)絡(luò)承載效率將大幅降低。

（1）SRv6報文開銷大

SRv6網(wǎng)絡(luò)中，為實現(xiàn)端到端路徑定制，需要封裝SRH及Segment List，SRv6報文的封裝長度為：40 byte（IPv6頭）+8 byte（SRH固定頭）+16×byte（Segment List）。由此可見，Segment List長度越大（即越大），報文開銷越大。例如，假定載荷為256 byte，當(dāng)Segment List長度為1時，開銷占比為20%（開銷占比=開銷/（開銷+有效載荷））；當(dāng)Segment List長度為10時，開銷占比為44.8%。

SRv6隧道的封裝方式根據(jù)SRv6源節(jié)點位置不同分為兩種：封裝（Encaps）模式和插入（Insert）模式。SRv6隧道封裝方式如圖1所示。若在業(yè)務(wù)源節(jié)點封裝SRv6報文，可采用Insert模式封裝；若在網(wǎng)絡(luò)中間節(jié)點封裝SRv6隧道進行引流，則通常采用Encaps模式。

圖1 SRv6隧道封裝方式

以4層標(biāo)簽為例，當(dāng)采用SRv6-TE（Encaps模式）、SRv6-TE（Insert模式）及SR-MPLS-TE（SR-MPLS-TE采用MPLS封裝，每標(biāo)簽長度為4 byte）3種隧道封裝方式的情況下，不同TE隧道封裝開銷占比（4層標(biāo)簽）見表1。

由表1可知，SRv6隧道封裝效率遠小于SR-MPLS隧道封裝效率，尤其對于小字節(jié)報文，SRv6隧道承載效率非常低。另外，與SR-MPLS SID在報文轉(zhuǎn)發(fā)過程中沿路徑逐跳彈出標(biāo)簽方式不同的是，SRv6報文轉(zhuǎn)發(fā)時沒有彈出操作，對沿途所有節(jié)點壓力基本一致，加劇了對網(wǎng)絡(luò)承載的壓力。

（2）SRv6報文硬件處理效率低

SRv6報文轉(zhuǎn)發(fā)過程需要硬件負責(zé)SRH的封裝和解封裝，并根據(jù)SID類型執(zhí)行對應(yīng)的動作。通常，網(wǎng)絡(luò)處理芯片，如網(wǎng)絡(luò)處理器（network processor，NP）或?qū)Ｓ眉呻娐罚╝pplication specific integrated circuit，ASIC），處理報文時按照流水線（pipeline）或運行至終結(jié)（run to completion，RTC）方式進行，然而芯片報文處理單元加載長度一般為固定字長，即預(yù)留封裝空間（通常小于144 byte）。SRH封裝即通過此預(yù)留封裝空間進行加載，按照144 byte長度計算，一次操作最多封裝6個SID。同理，SRH報文頭的操作與解封裝也占用了原始報文空間，需要通過預(yù)留固定字長進行處理。因此，當(dāng)報文頭中壓入較多SID時，芯片不能在一個處理周期內(nèi)完成報文頭處理，導(dǎo)致報文處理效率大幅下降。

表1 不同TE隧道封裝開銷占比（4層標(biāo)簽）

（3）SRv6報文棧深需求

按照國內(nèi)運營商網(wǎng)絡(luò)的構(gòu)建方式，跨地域長距離信息傳輸時，端到端指定路徑通常需要10跳。以新型城域網(wǎng)架構(gòu)[6]為例，若采用嚴(yán)格路徑指定方式，需要封裝10層標(biāo)簽（城域網(wǎng)3層+骨干網(wǎng)5層+城域網(wǎng)2層），另外，通常還會封裝1層業(yè)務(wù)標(biāo)簽（如VPN SID）實現(xiàn)業(yè)務(wù)編程。若采用Reduced模式，則SRH中不封裝源節(jié)點的下一跳，此時只需要封裝9層標(biāo)簽。

由此可知，指定端到端嚴(yán)格路徑時，SRH中封裝的Segment List長度將超過芯片一次處理空間長度，導(dǎo)致報文處理效率降低。解決設(shè)備硬件處理效率低的方法主要有如下3種方式。

（1）提升硬件能力

最容易想到的方式即增加芯片內(nèi)預(yù)留封裝空間的大小，以滿足一個周期能完成SRv6報文頭的處理。按照11層SID的封裝長度，所需的預(yù)留封裝空間長度至少為224 byte。然而，芯片研發(fā)周期長、成本高，短期內(nèi)難以滿足應(yīng)用與部署需求。

（2）BSID方案[7]

捆綁SID（binding SID，BSID）表示一個SRv6策略（SRv6 policy）路徑，通過BSID嵌套即可減少SRv6報文封裝的SID層數(shù)，變相減少了SRv6報文棧深，以提升硬件處理效率，實現(xiàn)大規(guī)模組網(wǎng)。假定報文的轉(zhuǎn)發(fā)路徑為R1-R2-R3-R4-R5，基于BSID的報文封裝方法如圖2所示。

然而，BSID需要在外層再次封裝IPv6報頭及SRH報頭，雖然提升了報頭處理效率，但仍存在報文傳輸效率問題。

（3）SRv6頭壓縮方案

SRv6頭壓縮方案是壓縮SRH中Segment List長度以減少SRH長度，從而達到提升報文處理和傳輸效率的目的。SRv6頭壓縮方案具有良好的應(yīng)用前景，受到了產(chǎn)業(yè)界的廣泛關(guān)注。

2 SRv6頭壓縮技術(shù)

為解決報文開銷大、承載效率低、硬件處理效率低等問題，產(chǎn)業(yè)界提出了多種SRv6頭壓縮方案，以滿足SRv6技術(shù)規(guī)模部署需求。SRv6頭壓縮是通過壓縮SID長度，從而減小SRH中Segment List的長度，達到指定路徑效果的同時，提升信息承載效率。SRv6頭壓縮作為SRv6規(guī)模部署關(guān)鍵技術(shù)，成為產(chǎn)業(yè)界主要的熱點方向，國內(nèi)外網(wǎng)絡(luò)運營商、設(shè)備提供商均提出了相應(yīng)的頭壓縮方案。

SRv6頭壓縮方案應(yīng)面向網(wǎng)絡(luò)/業(yè)務(wù)部署需求，充分利用現(xiàn)有網(wǎng)絡(luò)/設(shè)備資源，以減少實現(xiàn)成本與難度為目標(biāo)進行設(shè)計。綜合來看，SRv6頭壓縮方案在提高報文承載效率的同時，應(yīng)兼顧與SRv6/IPv6網(wǎng)絡(luò)的兼容性，具備可擴展性，以滿足規(guī)模部署需求。

圖2 基于BSID的報文封裝方法

目前，產(chǎn)業(yè)界提出了多種SRv6頭壓縮解決方案，根據(jù)實現(xiàn)方案的思路差異，主要分為共享方案和映射方案兩類。共享方案是指將SRv6 SID中的公共前綴（common prefix，CP）提取出來以Block字段承載，壓縮SID僅攜帶差異部分；映射方案則通過新定義較短長度的ID（如16 bit/32 bit），并將其與SRv6 SID建立映射關(guān)系，在報文轉(zhuǎn)發(fā)路徑的所有設(shè)備上存儲映射表項，SRH中則只需要攜帶較短的ID值即可。兩種方案都可減少SRH中Segment List長度。

共享方案兼容SRv6，具有較好的擴展性，且兼容SRH格式，數(shù)據(jù)平面易于實現(xiàn)，控制面只需要通過SRv6控制面擴展通告壓縮SID信息即可；映射方案壓縮效率高，但不兼容SRv6，數(shù)據(jù)平面也不兼容SRH格式，需要定義新的路由擴展頭以實現(xiàn)壓縮SID的封裝，且控制平面實現(xiàn)復(fù)雜，需要額外維護映射表項。目前，采用共享方案基本已成為產(chǎn)業(yè)界的共識，典型的共享頭壓縮方案包括G-SRv6壓縮（generalized SRv6 network programming for SRv6 compression，G-SRv6 for Cmpr）[8]和SRv6 uSID（SRv6 micro segment）[9]方案，產(chǎn)業(yè)界討論較多的映射方案則主要為段路由映射到IPv6（segment routing mapped to IPv6，SRm6）[10]方案等。

2.1 G-SRv6方案

G-SRv6主要采用“共享前綴”+“差異覆蓋”方式實現(xiàn)，其將128 bit的SRv6 SID劃分為Block、G-SID及參數(shù)（Arguments）字段。共享前綴是指將Segment List中每個SID冗余的Common Prefix移除，僅攜帶變化的G-SID，大幅減少SRv6報頭開銷；差異覆蓋則指更新IPv6報頭的目的地址（destination address，DA）字段時，只需要將差異部分的G-SID復(fù)制到DA相應(yīng)字段。G-SRv6報文封裝格式如圖3所示。

在G-SRv6方案中，定義了G-SRv6容器（G-SRv6 Container），標(biāo)識128 bit的封裝空間，因此可攜帶一個普通SRv6 SID或多個壓縮SID，從而實現(xiàn)SRv6 SID與G-SID混編。在DA字段中，新定義SID索引（SID index，SI）為DA中Arguments字段的最低2 bit，標(biāo)識G-SID在G-SID Container中的位置。將SL與SI字段結(jié)合，即可實現(xiàn)G-SID定位。

圖3 G-SRv6報文封裝格式

2.2 uSID方案

uSID方案主要采用“共享前綴”+“移位出棧”方式實現(xiàn)，同樣將SID劃分為uSID Block及uSID列表兩部分。共享前綴同樣將Segment List中公共前綴字段以uSID Block承載，剩余空間僅攜帶差異的uSID，從而減少SRv6報頭開銷；移位出棧則將DA中當(dāng)前活動uSID后的所有比特向前移位一個uSID長度，并在末尾填充0，從而實現(xiàn)報文逐跳轉(zhuǎn)發(fā)。uSID方案中SRv6報文的封裝方式如圖4所示。

由圖4可知，在uSID方案中，通過定義uSID 載體（uSID Carrier），同樣可將Segment List中每128 bit空間進行封裝，攜帶一個普通SRv6 SID或多個壓縮uSID，從而實現(xiàn)SRv6 SID與uSID混編。

圖4 uSID方案中SRv6報文的封裝方式

2.3 SRm6方案

SRm6方案則通過采用16 bit或32 bit的SID（也稱為mSID）代替SRv6中128 bit的SID，并在兩者之間建立一一映射關(guān)系，將IPv6地址序列的SID轉(zhuǎn)變?yōu)楦套止?jié)的壓縮SID，從而減小Segment List長度，實現(xiàn)SRv6報文頭壓縮效果。SRm6方案的SRv6報文封裝方式如圖5所示。

3 SRv6頭壓縮方案對比分析

G-SRv6、uSID及SRm6頭壓縮方案實現(xiàn)方式各異，在技術(shù)實現(xiàn)上也各具優(yōu)勢。上述3種主流SRv6頭壓縮方案對比見表2。

圖5 SRm6方案的SRv6報文封裝方式

在壓縮效率方面，G-SRv6方案的壓縮效率與Locator Block規(guī)劃及G-SID長度有關(guān)，uSID方案的壓縮效率與Locator Block規(guī)劃及uSID長度有關(guān)，而SRm6方案則不受地址規(guī)劃影響，只與mSID長度相關(guān)。上述3種頭壓縮方案基于不同的實現(xiàn)原理，難以簡單比較各方案壓縮效率的優(yōu)劣，特別在處理跨域時，受實際部署場景影響較大。

表2 主流SRv6頭壓縮方案對比

本節(jié)針對普通SRH封裝、G-SRv6、uSID以及SRm6頭壓縮方案封裝的報文承載效率進行比較。假定原始報文長度為448 byte（互聯(lián)網(wǎng)流量平均字節(jié)長度），Locator Block為32 bit，理想情況下（SRH中所有SID均可壓縮），壓縮SID長度分別為16 bit或32 bit時，對各方案的報文承載效率進行網(wǎng)絡(luò)仿真計算，各方案報文承載效率比較如圖6所示。

總體來看，SRm6映射方案的報文承載效率優(yōu)于G-SRv6方案和uSID方案，這主要是因為SRm6方案無須攜帶公共前綴Block，且使用了更簡化的CRH報頭格式。針對G-SRv6壓縮方案與uSID壓縮方案：若壓縮SID長度為16 bit，uSID方案報文承載效率稍高于G-SRv6壓縮方案；若壓縮SID長度為32 bit，SID不超過7層情況下，uSID方案的報文承載優(yōu)于G-SRv6壓縮方案，SID超過12層后，G-SRv6壓縮方案更優(yōu)。

圖6 各方案報文承載效率比較

上述比較只針對單AS域（即公共前綴不變）的仿真結(jié)果，下面針對跨越多個AS域（假定同一AS域內(nèi)只經(jīng)過4跳Segment）的場景，對各方案的報文承載效率進行仿真，跨域場景下各方案報文承載效率比較如圖7所示。

圖7 跨域場景下各方案報文承載效率比較

由圖7可知，在跨域場景下SRm6方案報文承載效率仍然最高，uSID方案次之，G-SRv6壓縮方案報文承載效率最低。特別是當(dāng)壓縮SID長度為16 bit時，uSID方案相對G-SRv6方案更具優(yōu)勢。

4 結(jié)束語

總體而言，盡管SRm6方案報文承載效率最優(yōu)，但其不兼容SRv6/SRH，且需要定義新的CRH擴展報頭、引入全新的控制面協(xié)議擴展、硬件實現(xiàn)復(fù)雜，基本已被產(chǎn)業(yè)界拋棄。兼容SRv6/SRH的G-SRv6方案和uSID方案則更受產(chǎn)業(yè)界推崇，且兩者實現(xiàn)原理也有相通之處。近期，標(biāo)準(zhǔn)上也提出了兼容G-SRv6和uSID的融合方案[11]，但由于其融合了兩種實現(xiàn)機制，在控制面和轉(zhuǎn)發(fā)面實現(xiàn)上增加了復(fù)雜性，有待產(chǎn)業(yè)界進一步討論。目前，國內(nèi)主流設(shè)備廠商對G-SRv6支持度更高，最終產(chǎn)業(yè)界會采用何種方案，還要看產(chǎn)業(yè)鏈的支持情況。

[1] 金姬. 中國電信構(gòu)建5G智慧生態(tài)圈上海邁向“雙千兆示范城市”[J]. 新民周刊, 2019(22): 84-85.

JIN J. China Telecom constructs 5G smart ecosystem and Shanghai marches towards “double gigabit demonstration city”[J]. Xinmin Weekly, 2019(22): 84-85.

[2] 王巍, 王鵬, 趙曉宇, 等. 基于SRv6的云網(wǎng)融合承載方案[J]. 電信科學(xué), 2021, 37(8): 111-121.

WANG W, WANG P, ZHAO X Y, et al. Cloud-network convergence solution based on SRv6[J]. Telecommunications Science, 2021, 37(8): 111-121.

[3] LEDDY J, VOYER D, MATSUSHIMA S, et al. Segment routing over IPv6 (SRv6) network programming[R]. RFC Editor, 2021.

[4] IETF. Compressed SRv6 SID list requirements[S]. 2022.

[5] IETF. RFC 8754, IPv6 segment routing header (SRH)[S]. 2020.

[6] 尹遠陽, 王志中, 姜有強, 等. 面向新型城域網(wǎng)的UMR技術(shù)方案研究與應(yīng)用[J]. 電信科學(xué), 2022, 38(2): 149-156.

YIN Y Y, WANG Z Z, JIANG Y Q, et al. Research and application of UMR technology for new metropolitan area network[J]. Telecommunications Science, 2022, 38(2): 149-156.

[7] IETF. RFC 8986, segment routing over IPv6 (SRv6) network programming[S]. 2021.

[8] IETF. Generalized SRv6 network programming for SRv6 compression[S]. 2022.

[9] IETF. Network programming extension: SRv6 uSID instruction[S]. 2022.

[10] IETF. The IPv6 compact routing header (CRH)[S]. 2022.

[11] IETF. Compressed SRv6 segment list encoding in SRH[S]. 2022.

Research on SRv6 header compression schemes

GONG Xia1, CHEN Huanan2, ZHU Yongqing1, WU Youming1, RUAN Ke1

1. Research Institute of China Telecom Co., Ltd., Guangzhou 510630, China 2. China Telecom Cloud Technology Co., Ltd., Guangzhou 510245, China

Digital and intelligent carrier network have become the priorities of network construction and operation. As a key technology to realize network interconnection and service carrying, carrier protocol critically decides the network scale and traffic efficiency. Facing the service consistent experience requirements, SRv6 as the most competitive technology of IPv6 evolution, has become the development direction in the future. Combined with the principle of SRv6 technology, the requirements of SRv6 compression were analyzed. Based on the main SRv6 compression schemes in the industry, the advantages and disadvantages of each scheme were analyzed, so as to provide guidance for the large scale deployment of SRv6 technology.

SRv6, header compression, carrier protocol

TN919

A

10.11959/j.issn.1000–0801.2022282

2022–07–05；

2022–11–02

龔霞（1991– ），女，現(xiàn)就職于中國電信股份有限公司研究院，主要研究方向為IP網(wǎng)絡(luò)、網(wǎng)絡(luò)虛擬化、云網(wǎng)融合等。

陳華南（1981– ），男，現(xiàn)就職于中國電信天翼云科技有限公司，主要研究方向為云網(wǎng)絡(luò)。

朱永慶（1974– ），男，中國電信股份有限公司研究院正高級工程師，主要研究方向為IP網(wǎng)絡(luò)、云網(wǎng)融合和5G。

伍佑明（1968– ），男，博士，中國電信股份有限公司研究院正高級工程師，主要研究方向為IP網(wǎng)絡(luò)、IPv6+和下一代互聯(lián)網(wǎng)。

阮科（1979– ），男，現(xiàn)就職于中國電信股份有限公司研究院，主要研究方向為IP網(wǎng)絡(luò)架構(gòu)、IP新技術(shù)和下一代互聯(lián)網(wǎng)。