SRv6 - yuuk1's Digital Garden

# SRv6 ## 定義 SRv6（Segment Routing over IPv6）は、パケット自体に完全な経路情報を埋め込むソースルーティング技術である。IPv6 拡張ヘッダに Segment List（経由すべきノードの順序付きリスト）を格納し、スイッチは動的な経路計算を行わず単純に Segment に従い転送する。AI スーパーコンピュータネットワーキングでは [[MRC]] および [[マルチプレーンClosトポロジ]] と組み合わせて、決定的転送と瞬時の障害回避を実現する。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) 主要特性: - **決定的転送**: 経路が送信元で事前決定済みのため予測可能な遅延 - **瞬時障害回避**: 障害パスを新パケットから即座に迂回できる（再ルーティング収束待ち不要） - **動的再計算不要**: OSPF/BGP の収束時間に依存せず、スイッチの状態機械を単純化 ## SONiCにおける実装(『実践SONiC入門』第10章) SONiC(SAI)におけるSRv6の実装は2017年のSAI 1.2.0まで遡るが、最初の実装元であったCavium XPliant ASICが2018年のMarvellによる買収でディスコンとなり入手不能になったため、SRv6標準化の進展とSAI Pipeline ModelのTunnel/MPLSとの整合性確保を目的に2021年に大幅に再設計された。標準的なSRv6 BehaviorであるEnd, End.DT46, H.Encaps.RedはSONiC.202111で実装され、以後SONiC.202211でuSID(マイクロSID)のuN, uA, uDX, uDTが追加された。SAI対応が必要な機能ではSONiC側の対応に加えSAI側の対応も必要であり、FRRをSRv6のコントロールプレーンとして使う対応(fpmsyncdの拡張)はSONiC.202405時点で未マージ、2024年11月のPRマージによりSONiC.202411で利用可能になる見込みとされる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] ch.10 §10.1.1) 実装対象のBehaviorのうち、End.DT46とH.Encaps.Redは対をなす。**End.DT46**は受信したSRv6パケットの内部パケットを取り出し(デカプセル化)、指定されたVRFのルーティングテーブルに従い転送する、SRv6トンネルの終端(egress)側の動作である。**H.Encaps.Red**はオリジナルパケット(IPv4など)を、指定した送信元アドレスとセグメントリストでSRv6ヘッダにカプセル化して送出する、トンネルの始点(ingress)側の動作である("Red"はセグメントリストの圧縮表現Reducedを指す)。データプレーン(Switch ASIC)ごとにサポートするBehaviorが異なり、2023年9月時点でIntel Tofino ASIC、Cisco Silicon One ASIC、Linux Kernelの3つがSRv6サポートを表明しているが、sonic-vs(Linux Kernel)は設定投入こそ可能でもデータプレーンとの連携が無いため、パケット変換動作の検証にはTofino ASIC搭載実機を要する。(Source: ch.10 §10.1.2, §10.3.1〜§10.3.2) 設定投入の経路は、CLIやCONFIG_DBを介した宣言的設定管理([[宣言的設定管理]])とは別に、`swssconfig`によるAPPL_DBへの直接投入という手段が使われる。これはCLI/`*mgrd`が未実装の新機能を先行利用するための経路であり、投入されたAPPL_DBエントリ(SRV6_MY_SID_TABLE, SRV6_SID_LIST_TABLE, ROUTE_TABLEのSRv6フィールド)は、orchagent内のRouteOrchとSrv6Orchの協調動作によりASIC_DBのSAIオブジェクト(SAI_OBJECT_TYPE_MY_SID_ENTRY, SAI_OBJECT_TYPE_SRV6_SIDLIST, SAI_OBJECT_TYPE_TUNNEL(type=SRV6), SAI_OBJECT_TYPE_NEXT_HOP(type=SRV6_SIDLIST), SAI_OBJECT_TYPE_ROUTE_ENTRY)へ変換される。(Source: ch.10 §10.2.1, §10.2.5, §10.3.3〜§10.3.4) ## 横断的知見 - **AI スーパーコンピュータネットワーキングの文脈(LinkedIn/arXiv記事)とSONiC実装(『実践SONiC入門』第10章)は、SRv6のヘッダ生成主体という点で対照的な役割分担を示す**: arXiv 原論文はSRv6のSegment Listを送信ホスト(NIC)自身がアルゴリズム的に計算し、EV(entropy value)から最終アドレスを都度生成すると説明する。一方SONiC第10章のH.Encaps.Red(ingress側のカプセル化Behavior)は、あらかじめ`SRV6_SID_LIST_TABLE`に定義したセグメントリストを、ネットワーク機器(スイッチ)側が`ROUTE_TABLE`のルックアップ結果に基づき静的に付与する動作であり、パケットごとに動的計算を行うホスト(NIC)側の仕組みとは異なる。両ソースを合わせると、「SRv6ヘッダをどこで・どう生成するか」には少なくとも2つの実装パターン——ホスト(NIC)が送信時にアルゴリズム的に計算する方式と、ネットワーク機器がルーティングテーブル参照に基づき静的なセグメントリストを付与する方式——が存在することが分かる。SONiC第10章はネットワーク機器側の実装(SAIオブジェクトとASIC_DBエントリ)を具体的に示すが、ホスト側でのSRv6ヘッダ生成については触れていない。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] §2.2〜2.3, [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] ch.10 §10.2.2, §10.3.2) - **SRv6 uSID(uN, uA, uDX, uDT)はAI supercompute記事群でも SONiC実装でも共通の語彙として現れるが、両者の記述の解像度は逆方向に補完し合う**: arXiv原論文はuN uSIDについてNIC側のアドレス生成アルゴリズム(左シフトによるuSID消費、EVマッピング)を詳細に述べる一方、これらのBehaviorがスイッチ側でどう処理されるかには触れない。SONiC第10章は逆に、uN, uA, uDX, uDTがSONiC.202211でSAI対応の必要な機能として追加されたことと、データプレーン(Switch ASIC)ごとにサポート状況が異なる(2023年9月時点でTofino/Cisco Silicon One/Linux Kernelのみ)ことを述べるが、個々のuSID Behaviorの内部動作までは踏み込まない。SRv6 uSIDの全体像は、ホスト側のアドレス生成(arXiv)とスイッチ側のSAI実装依存性(SONiC第10章)という2つの独立した制約を両方満たして初めて成立する。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] §2.2〜2.3, [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] ch.10 §10.1.1〜§10.1.2) - SRv6 の「送信元が経路を決める」アーキテクチャは、従来の分散型ルーティングプロトコル（OSPF/BGP）の収束遅延問題を根本的に回避する。AI 訓練クラスタのような均質なワークロードでは、経路決定を集中管理できるため SRv6 との相性がよい。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - [[マルチプレーンClosトポロジ]] の各プレーンを SRv6 で識別することで、障害プレーンのトラフィックを正常プレーンへ即時切り替えできる可能性がある。プレーン選択ロジックと SRv6 セグメントの対応関係は未確認。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - JANOG58 の発表は SRv6 を [[MRC]] の伝送経路制御手段として簡潔に言及するのみで、LinkedIn 記事以上の技術的詳細(実装方式やヘッダオーバーヘッドの扱い)は提供しない。ただし業界の複数ベンダー(AMD/Broadcom/Intel/Microsoft/NVIDIA)が関与するオープンプロトコルの文脈で SRv6 ソースルーティングが採用されている点が独立ソースから再確認され、単一ベンダー固有の技術ではないという傍証になる。(Source: [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]]) - **原論文(arXiv:2605.04333)で「経路情報はどこで計算されるか」という問いが解決した**: SRv6 の Segment List はコントローラベースの集中管理ではなく、**送信ホスト(NIC)自身がアルゴリズム的に計算する**。QP 起動時に NIC がノード固有の設定ファイルから汎用テンプレートアドレスを取得し、宛先ダウンリンク番号で特化した後、送信ごとに MRC の EV(entropy value)から plane・T0 uplink の bit を埋め込んで最終アドレスを生成する(Figure 3)。EV と SRv6 アドレスの間はアルゴリズム的マッピングで結ばれており、「同一パケットの複数コピーへの経路付け」ではなく EV 1 個が具体的な 1 経路に 1 対 1 対応する。LinkedIn 記事の「決定的転送」という抽象的な説明に、NIC 側の具体的な計算手順という実装詳細が加わった。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - **ダイナミックルーティングを無効化した理由は「2 つの適応機構の相互作用」という設計原則にある**: 原論文は、MRC の適応的負荷分散とスイッチのダイナミックルーティングを同時に動かすと、MRC が障害を検知し先に回避した直後にダイナミックルーティングが ECMP マッピングを変更して負荷分散を乱す、という相互作用が起きるため意図的にダイナミックルーティングを無効化したと明言する。LinkedIn 記事が挙げた「動的再計算不要」という利点(OSPF/BGP の収束時間に依存しない)は、単なる可用性の話ではなく、MRC という別の適応機構との衝突を避けるための意図的な設計判断だったことが原論文で裏付けられた。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - **SRv6 の静的経路が「高頻度プロービング」を可能にし、[[RDMAネットワーク監視]] の能動プローブ系統に新しい選択肢を加える**: 原論文は、SRv6 を使わない場合 ICMP プローブはコントロールプレーンで処理されレート制限を受けるが、SRv6 ではプローブパケットも他のデータトラフィックと同様にデータプレーンで処理されるため、Clustermapper がミリ秒単位の高頻度プロービングを継続的に行えると説明する。これは [[RDMAネットワーク監視]] が整理する「能動プローブ(R-Pingmesh)・受動トラフィック(Pulse)・フルスタック計装(Astral)」の三分類のうち能動プローブ系統に、"送信元へ戻る自己プローブ(pingmesh のような対向ノード宛プローブと異なり相手が落ちていても解釈しやすい)" かつ "経路が確定的なため曖昧さがない" という SRv6 固有の性質を加える。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) ## 未解決の問い - SRv6 ヘッダのオーバーヘッド（IPv6 拡張ヘッダ追加）は 10 万 GPU 規模でどの程度の帯域影響があるか。原論文はオーバーヘッドの定量値を示していない。 - uN uSID 方式でのスイッチ段数の上限はどこにあるか。左シフトのたびに uSID を 1 つ消費するため、経路長がスイッチのアドレス長(uSID フィールド数)で制約される可能性があるが、原論文はマルチプレーン Clos の 2 段(T0-T1-T0)構成のみを扱い、より深いトポロジでの制約は論じていない。 - MRC 以外のトランスポート(例えば NCCL の QP スケーリングや UCCL)と SRv6 静的ソースルーティングを組み合わせた場合、EV に相当する経路選択メカニズムをどう設計すべきか。 - AI supercompute記事群が説明するNIC側でのSRv6アドレス動的生成(EVマッピング)は、SONiC第10章が示すSAIオブジェクトモデル(SRV6_MY_SID_TABLE, SRV6_SID_LIST_TABLE等)とどう対応するのか。NICが生成したSRv6ヘッダを受信するスイッチ側では、生成された各SIDが`SRV6_MY_SID_TABLE`のエントリとして事前登録されている必要があるはずだが、動的に生成されるアドレス空間をスイッチ側でどう事前登録・管理するのかは両ソースとも明示していない。 - SONiC第10章はH.Encaps.Red(ネットワーク機器側での静的カプセル化)を示すが、AI supercompute文脈のようにホスト(NIC)がSRv6ヘッダを生成する場合、SONiCスイッチはEnd(またはEnd.X等の中間ノード向けBehavior)としてのみ関与するのか、それともH.Encaps.Redのような機器側カプセル化と併用されうるのか、本wikiが参照した各ソースからは判断できない。 ## 関連 - 概念: [[MRC]] / [[マルチプレーンClosトポロジ]] / [[RDMA]] / [[LLM分散学習]] / [[RDMAネットワーク監視]] / [[宣言的設定管理]] - 実体: [[SONiC]] / [[SAI (Switch Abstraction Interface)]] - ソース: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] / [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] ## 出典 - [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] - [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]](§2.2〜2.3 SRv6 uN uSID・EV マッピング Figure 2/3、§2.4 Clustermapper の高頻度プロービング) - [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]](§10.1.1〜§10.1.2 SONiCにおけるSRv6サポート状況、§10.2.2 APPL_DBスキーマ、§10.3.1〜§10.3.4 End.DT46/H.Encaps.Redのパケット変換とSAIオブジェクト)