2.2.2 NEXT-C-SID Flavor及工作范例

1．NEXT-C-SID Flavor

與REPLACE-C-SID類似 ，當NEXT-C-SID Flavor的C-SID被編碼到SRH之后，每次更新的SID不一定是128 bit的SID，也有可能是32 bit C-SID或16 bit C-SID，因而還需要定義32 bit C-SID或16 bit C-SID更新的動作。

為了指示SRv6 C-SID的處理，IETF草案draft-ietf-spring-srv6-srh-compression也定義了NEXT-C-SID Flavor^[4]，用于指示節點按照NEXT-C-SID flavor方式更新C-SID。

在NEXT-C-SID Flavor的編碼中，一個C-SID Container包含一個Locator Block和多個C-SID。以16 bit C-SID方案為例，圖2-12展示了NEXT-C-SID對應的C-SID Container編碼格式。

在轉發的過程中，只有當目的地址為NEXT-C-SID Flavor SID時，節點才會讀取該SID的Arguments字段。此時，Arguments字段可能攜帶后續的C-SID。節點在處理NEXT-C-SID Flavor的SID時，通過移動當前C-SID的非0 Arguments字段（后續C-SID），覆蓋當前的C-SID，即可完成整個IPv6 DA的更新，然后進行轉發。

以16 bit C-SID為例，簡化的NEXT-C-SID Flavor的偽代碼如下所示。詳細偽代碼請參見標準文檔（參考文獻^[4]）。

If ipv6 DA is a NEXT-C-SID Flavor SID        
   if DA.Arg!=0                 
      DA[Block..127-16] = DA[Block+15..127];          
      DA[127-16..127] = 0;     
   else:         
      DA = SRH[--SL];

當節點收到一個數據報文，其IPv6目的地址是一個NEXT-C-SID Flavor SID時，如果其中Arguments非0，則將后續的比特往左移動n位（n為16或32）到Locator Block右側，覆蓋當前C-SID。左移后產生的最右側的n位（n為16或32）需要補0。如果C-SID之后的數值為0，則更新下一個C-SID Container到IPv6 DA。以16 bit C-SID為例（Locator Block長度為64 bit），NEXT-C-SID Flavor的更新示例如圖2-13所示。

當一個C-SID Container處理結束且SL > 0時，節點需要將下一個128 bit的C-SID Container完整更新到目的地址中。如果下一個SID是一個128 bit的普通SRv6 SID，轉發動作就恢復成普通的SRv6轉發。可見，NEXT-C-SID序列也支持與128 bit的普通SRv6 SID在一個SRH中混編，從而支持從普通128 bit SRv6平滑演進到SRv6傳輸效率的提升方案。

以上為攜帶SRH時的處理邏輯，NEXT-C-SID也支持僅在DA中攜帶唯一的C-SID Container而不攜帶SRH。為此，需要在處理Upper-Layer擴展頭的代碼前插入NEXT-C-SID Flavor的處理代碼，從而支持在不攜帶SRH的情況下，執行NEXT-C-SID Flavor SID的轉發動作。

2．NEXT-C-SID Flavor工作范例

假設NEXT-C-SID Flavor方法使用的網絡拓撲如圖2-10所示，其中N1到N9所有節點都支持NEXT-C-SID Flavor方法。

網絡初始化之后，節點配置NEXT-C-SID Flavor的SID，并通過IGP、BGP、BGP-LS等協議發布到網絡中或上送給控制器。

為了體現16 bit傳輸效率提升的效果，此處全部使用從LIB中分配的C-SID進行編碼，省掉從GIB中分配的節點C-SID（若攜帶對應的GIB分配的C-SID，則攜帶的C-SID數目翻倍，壓縮效果等價于使用32 bit C-SID）。此處存在一個強制的要求，即必須逐跳指定SID，才能使得每個SID都能在對應的節點上正確處理；若存在跨AS多跳轉發的場景，則必須使用可路由的SID，因此C-SID數量也會相應增加。

各個節點配置SID可以遵循表2-2所示的規則，其中第一行的SID為擁有Node ID字段的可路由的SID，會被發布到其他節點，Locator Block的長度為64 bit，Node ID的長度為16 bit，Function ID的長度為16 bit，Arguments的長度為32 bit。第二行SID是其關聯SID，無Node ID字段，不可路由，僅在本節點有效，不會發布到其他節點，可進一步節省開銷。第三行SID是擁有Node ID字段的End.DT4 VPN SID，而最后一行是與之關聯的無Node ID的本地SID。

這里假設16 bit的NEXT-C-SID的GIB為0x0000～0x9FFF，LIB為0xA000～0xFFFF。全局可路由C-SID僅可從GIB中分配（如End SID中的k），而本地C-SID僅可從LIB中分配（如End.X SID中的F001）。在前面32 bit的REPLACE-C-SID工作范例中，Node ID和Function ID分別獨占不同的位置，不需要劃分GIB和LIB。

從表2-2可知，從GIB中分配的Node ID可以在使用時去掉，僅使用從LIB中分配的本地Function ID來指導轉發即可，從而進一步減少開銷。但由于LIB分配的數值僅本地有效，所以需要確保對應的本地C-SID僅在分配它的節點上被處理。

而為了支持單獨的LIB匹配，需要多配置一條本地的SID表項，用于匹配單獨使用LIB C-SID的情況。如節點N1分配的SID 2001:DB8:A:0:1:F001::，還需要額外增加一個對應的不攜帶Node ID的SID 2001:DB8:A:0:F001::（注意此處的Node ID 1被省略），用于匹配僅使用Function ID的C-SID。這是NEXT-C-SID使用GIB/LIB的代價之一，即表項比全部使用帶Node ID的可路由的普通SRv6或REPLACE-C-SID的本地轉發表項多一倍。

在這個案例中，假設報文將從N1轉發到N9，Segment List共包含9個SID。

● 前8個SID數值為2001:DB8:A:0:k:F001::，是由節點N1～N8分配的NEXT-C-SID Flavor的End.X SID，其Node ID為從GIB中分配的k，Function ID為從LIB中分配的F001。

● 2001:DB8:A:0:9:FF10::，End.DT4類型的VPN SID，其Node ID為從GIB中分配的9，Function ID為從LIB中分配的FF00。

在Segment List編碼為壓縮Segment List時，可將全部的Node ID忽略掉，僅使用對應SID的Function ID部分作為C-SID編碼到C-SID Container中即可，從而省掉從GIB中分配的Node ID的開銷，也就是從2001:DB8:A:0:k:F001::變為2001:DB8:A:0:F001::（若攜帶對應的GIB分配的C-SID，則攜帶的C-SID數量翻倍，傳輸效率提升的效果等價于使用32 bit C-SID）。但此處存在一個強制的要求，即必須逐跳指定SID，才能使得每個SID都能在對應的節點上正確處理；若存在跨AS多跳轉發的場景，則必須使用可路由的SID引導數據包到指定節點，再處理本地SID，開銷會相對增加。

圖2-14給出了經過編碼之后的NEXT-C-SID Flavor方法轉發示意。

NEXT-C-SID Flavor方法的轉發流程簡述如下。

① 節點N1封裝好數據包后，目的地址2001:DB8:A:0:F001:F001:F001:F001匹配到本節點發布的NEXT-C-SID Flavor End.X SID關聯的本地SID 2001:DB8:A:0:F001::/80（如果發布的SID中攜帶Node ID，則此處匹配的為關聯的無Node ID的SID）。由于IPv6 DA中Arguments非0，因此將F001:F001:F001左移，更新IPv6 DA為2001:DB8:A:0:F001: F001:F001::，然后將數據包從指定的接口發往N2。

② 節點N2收到數據包時，目的地址2001:DB8:A:0:F001:F001:F001::匹配到本節點發布的NEXT-C-SID Flavor End.X SID關聯的本地SID 2001:DB8:A:0:F001::/80，由于IPv6 DA中Arguments非0，因此將F001:F001左移，更新IPv6 DA為2001:DB8:A:0:F001:F001::，然后將數據包從指定的接口發往N3。

③ 同理，節點N3將數據包轉發給N4。

④ 節點N4收到數據包時，目的地址2001:DB8:A:0:F001::匹配到本節點發布的NEXT-C-SID Flavor End.X SID關聯的本地SID 2001:DB8:A:0:F001::/80，由于IPv6 DA中Arguments為0，因此下一個128 bit的C-SID Container中的內容2001:DB8:A:0:F001:F001:F001:F001更新到目的地址，然后將數據包從指定的接口發往N5。

⑤ 同理，后續節點N6～N8按照NEXT-C-SID的轉發方式將數據包繼續轉發。

⑥ 節點N9收到數據包時，基于目的地址2001:DB8:A:0:FF10::查表并匹配到FIB中的End.DT4 SID關聯的本地SID2001:DB8:A:0:FF10::對應的轉發表項，按照指令將外層報文頭解封裝，使用內層報文繼續在VPN轉發表中查表轉發。

3．總結

前文提到，只有NEXT-C-SID依賴較短的Locator Block，才能提供較好的傳輸效率。但在現實部署中，短前綴意味著大地址空間，也就意味著大量的地址被使用。一般的運營商很難提供48 bit甚至32 bit的GUA（Global Unicast Address，全球單播地址）前綴用于部署SRv6。因此，為了保證足夠的傳輸效率，在部署NEXT-C-SID時只能選擇本地地址，如ULA（Unicast Local Address，單播本地地址）。但選擇ULA會導致SID僅在AS內可路由，在需要提供全局可路由能力的場景里無法使用。由于ULA尚未完成標準化，存在未知風險，所以部署者需根據部署的實際情況選擇GUA或ULA的Locator Block。但無論選擇GUA還是ULA，都需要在AS邊界路由器上進行地址過濾配置，防止意外泄露SRv6相關的路由或SID到AS外。從這個角度看，ULA并不比GUA更安全，兩者在安全上沒有差異。

說明

RFC 4193僅定義了FD00::/8的ULA使用方法，FC00::/8還未標準化^[23]。

由于NEXT-C-SID的每一個C-SID Container都攜帶一定長度的Locator Block，當攜帶多個C-SID Container時，就攜帶了多份冗余的Locator Block信息，從而影響了傳輸效率。此外，由于需要攜帶Locator Block，若使用32 bit C-SID，一個C-SID Container最多僅編碼3個C-SID（Locator Block長度小于或等于32 bit）；當Locator Block長于32 bit時，一個C-SID Container最多僅編碼2個C-SID，傳輸效率較差。為提供更高的傳輸效率，NEXT-C-SID建議使用16 bit的C-SID而非32 bit的C-SID，因此更適合中小規模網絡。

使用16 bit的C-SID時，不可避免地需要將16 bit的空間劃分為GIB和LIB兩個部分，這在一定程度上增加了網絡規劃的復雜度。為了支持本地C-SID（16 bit Function ID）的單獨匹配和完整可路由C-SID + 本地C-SID的組合（16 bit Node ID +16 bit Function ID）匹配，需要在本地路由表中維持2個表項。與僅從GIB中分配的32 bit的REPLACE-C-SID和普通的128 bit SRv6 SID相比，這種方式增加了接近一倍的表項。

此外，在C-SID能完全放置在一個C-SID Container的場景中，為了減小報文頭開銷，SRH可能不會被加入IPv6報文。這雖然節省了8 Byte的開銷，但也帶來了額外的安全隱患。因為當前很多的SRv6安全措施基于SRH判斷是否需要過濾流量，以此避免通過源路由進行網絡攻擊，而不帶SRH的NEXT-C-SID List可以繞過這個限制實現攻擊。由此需要在部署時增加一些額外的配置，對不攜帶SRH的數據包也進行檢測和過濾。此外，沒有SRH而執行段路由也會在與其他IPv6擴展頭組合使用時帶來丟包和處理效率降低的風險；比如與IPSec系列報文頭[AH（Authentication Header，認證頭）與ESP（Encapsulate Security Payload，封裝安全載荷）]組合使用時，可能會造成中間節點因為沒有檢查到SRH而直接處理了IPSec報文頭，從而導致丟包或轉發性能顯著下降的情況。不攜帶SRH也會導致原本出現在SRH之后的DOH2字段意外出現在原本屬于DOH1字段的位置，導致本該在最終節點處理的DOH2字段變為逐個SRv6 Endpoint節點處理的DOH1字段。綜上所述，建議在使用NEXT-C-SID時，謹慎選擇不帶SRH，并建議在與其他IPv6擴展報文頭組合使用時攜帶SRH，從而避免潛在風險。

在某些情況下，為了降低報文頭開銷，SRv6有可能使用Reduced模式將放入DA的第一個C-SID Container省略掉，不攜帶到SRH中。這種方法的優點是減小了開銷，但對于16 bit的NEXT-C-SID方案，因為一個C-SID Container中包含了多個SID的信息，并在轉發過程中左移覆蓋，所以會導致報文轉發到目的節點時無法獲取完整的Segment List信息。尤其當僅有一個C-SID Container時，會完全丟失路徑信息。因此，對于需要跟蹤數據包轉發路徑的場景，要避免使用Reduced模式。