SRv6 Mobile User Plane(MUP) の紹介とMUP-BGPのOSS実装に おける相互接続性について 2023/05/18（木） シン・ITRC meeting 53 BBSakuraNetworks/はやさか たける

発表者自己紹介 ● 早坂 彪流 (Hayasaka Takeru|@takemioIO) ● 仙台市出身, 京都市在住 ● 社会人3年目（24歳） ● 前職は京都にあるゲーム会社。今の上司（@higebu) に誘われて現職へ 仕事の中身がSwitchからSwitchにSwitchすることになりネットワークに関する開発へ... ● SRv6 MUPでは主にC-plane,D-planeとAgentを担当 ● 普段はモバイルコアの実装&設計を担当 ○ keyword: Linux, XDP, PGW ● 好きな技術: eBPF/XDP ● 趣味はSFアニメ・漫画、散財とか ○ 最近今更「魔法少女リリカルなのは」を見終わった。

● BBIXとさくらインターネットの合弁会社 ● 2019年8月1日設立 ● ネットワークサービスのソフトウェア開発 ○ 親会社を通じてソフトウェアを世に出している ● すべての「モノ」がつながる社会の実現に向け、プラットフォーム(OCX)提供を通じて ネットワークサービスのクラウド化を進めてます 開発や運用をしているサービス ● さくらのセキュアモバイルコネクト ● さくらのショートメッセージサービス ● BBIXお客様向けポータル ● OCX (Open Connectivity eXchange)

アジェンダ ● SRv6 Mobile User Plane(MUP)概要 ● BBSakuraで取り組んだ MUP関連の開発の紹介 ● IETF 116で行った相互接続性検証について

SRv6 Mobile User Plane(MUP)概要

なぜ SRv6 MUP をやってるのか ● 自社開発のモバイルコアを使ったサービスを運用した経験から SRv6 MUP と いう技術に対して将来性を感じているから ● 親の親会社であるソフトバンク株式会社のプレスリリースにもコメント させていただいています ○ MECやネットワークスライシングを低コストかつ容易に実現する「SRv6 MUP」の開発に成 功 | 企業・IR | ソフトバンク

SRv6 Mobile User Plane(MUP)概要 ● モバイルネットワークのUser PlaneをSRv6で置き換える技術 ● IETFで標準化中 ○ draft-mhkk-dmm-srv6mup-architecture-05 ■ 全体的なアーキテクチャについて ○ draft-ietf-dmm-srv6-mobile-uplane-24 ■ パケットフロー、SRv6 Behaviorについて ○ draft-mpmz-bess-mup-safi-02 ■ BGP-MUP SAFIについて ○ draft-murakami-dmm-user-plane-message-encoding-05 ■ U-planeでのGTP-U Message-SRv6変換について

3GPP 5G Architecture UE gNB SMF AMF UPF DN UPF N3 N9 N6 N4 N11 N1 N2 ● SMF がセッション毎の GTPv1-U トンネルの管理を N4 で行う ● N3、N9 のところにセッション毎の GTPv1-U トンネルが生成される ● 実際の環境では全ての Function が複数ある ● MEC のような用途では DN も複数あり、標準仕様では UPF でバケツリレー。。。 UE: User Equipment gNB: gNodeB, next generation Node B AMF: Access and Mobility Management Function SMF: Session Management Function UPF: User Plane Function DN: Data Network GTPトンネル:

SRv6 MUP Architecture UE gNB SMF AMF MUP-PE DN MUP-GW N3 N6 N11 N1 N2 ● 5.3. Enhanced mode with unchanged gNB GTP-U behavior のときの構成 ● N3 は GTPv1-U のまま、N9 が SRv6 になりフラットなネットワークに...! ● 4種類の経路情報を使う（ISD, DSD, ST1, ST2） MUP-C: MUP Controller MUP-GW: MUP Gateway MUP-PE: MUP Provider Edge MUP-C BGP Type 1 ST Route Type 2 ST Route Interwork Segment Discovery Route Direct Segment Discovery Route N9 未定義の Northbound API GTPトンネル: SRv6トンネル:

GTP-U and SRv6 Stateless Translation Algorithm 0 127 +-----------------------+-------+----------------+---------+ | SRGW-IPv6-LOC-FUNC |IPv4 DA|Args.Mob.Session|0 Padded | +-----------------------+-------+----------------+---------+ 128-a-b-c a b c Destination Segment ID (Last Destination IPv6 Addr) 0 127 +----------------------+--------+--------------------------+ | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | +----------------------+--------+--------------------------+ 128-a-b a b Source IPv6 Address IPv4 DA IPv4 SA UDP GTP H.M.GTP4.D: SRv6 -> GTP-U End.M.GTP4.E: GTP-U -> SRv6

Uplink Packet Flow MUP-GWの挙動 ● DSD（Prefix-SID）と ST2（TEID） を元に TEID 毎の SID を生成しておく ○ ※DSD と ST2 に含まれる Direct Segment ID で紐付けができる ○ UPF アドレスの Prefix と TEID を SR Policy と紐付けておく ● gNB から UPF アドレス宛ての GTPv1-U のパケットが来たら H.M.GTP4.D or End.M.GTP6.D (N3 のアドレスによ る) を行う ○ TEID をキーに SID を参照（SID Bとする） ○ IPv4 or IPv6, UDP, GTPv1-U ヘッダの decap ○ GTPv1-U ヘッダに含まれる TEID、QFI を SID B にコピー（Args.Mob.Session） ○ IPv6 DA、SRH を作り、パケットを転送（IPv6 DA または SID[0] が SID B になる） MUP-PEの挙動（End.DT4/6） ● IPv6 ヘッダを decap して転送 H.M.GTP4.D End.M.GTP6.D End.DT4/6 DN MUP-PE MUP-GW gNB N3 N6

Downlink Packet Flow DN MUP-PE MUP-GW gNB N3 N6 End.M.GTP4/6.E H.Encaps MUP-PE の挙動 ● ISD（Prefix-SID）と ST1（TEID/QFI/gNB Address）を元に UE アドレス毎の SID を生成しておく ○ ※ISD の Prefix に ST1 の gNB Address が含まれるかどうかで紐付けができる ● DN から UE アドレス宛のパケットが来たら、UE アドレスをキーに SR Policy を参照し、 SRv6 で Encap MUP-GW の挙動 ● SID で指定されている End.M.GTP4.E or End.M.GTP6.E を実行 ● End.M.GTP4.E: IPv6 ヘッダを decap、 IPv6 DA に含まれる IPv4 SA、DA と TEID を元に生成した IP、 UDP、GTPv1-U ヘッダで encap して転送 ● End.M.GTP6.E: IPv6 DA に含まれる TEID を元に生成した GTPv1-U ヘッダで encap、 SID[0]（ gNB アド レス）を宛先アドレスにして転送

SRv6 MUPの既存実装 ● 製品 ○ Arrcus Networks: Arrcus enables SoftBank Corp. to demonstrate automated 5G Network Slicing by Using SRv6 MUP with SRv6 Flex-Algo ○ 古河ネットワークソリューション: SRv6 MUP を作った話（公開版） ● OSS: 基本Uplaneのみ ○ VPP SRv6 Mobile Plugin: VPP(DPDK)によるU-plane実装（ドラフトの著者が開発） ○ ebiken/p4srv6: P4によるU-plane実装 ○ takehaya/Vinbero: XDPによるU-plane実装（発表者の早坂が学生時代に開発） ■ （おそらく）SRv6の高速な実装で一番最小なサブセットでLinuxさえあれば動くので 研究開発のコンテキストで改造にも適してます

ここまでのまとめ ● SRv6MUPは従来のモバイルアーキテクチャを変えるものである ● MUP-GW/PEを作るにはC-planeとU-planeを組み合わせる必要がある ● しかし、OSSにはU-planeしかなかった ● 俺たちでC-planeもMUP-GW/PEも作ればいいじゃない 野良OSS活動のすすめ by Yoshiyuki Kurauchi | Open Mobile Network Infra Meetup #3

BBSakuraで取り組んだ SRv6MUP関連の開発の紹介

MUP-GW/PEを作るには？ ● C/Dのインテグレートをどんな技術でどうやって作るかを考える ● OSSのDplaneではVPPを採用 ○ VPPは機能が豊富で（論文上では）性能が良さそうなのが嬉しい(cf. XDP元論文 ○ Draftの提案者が自ら書いてて神なのでそれを良くしたい ● OSSのCplaneはGoBGPを採用 ○ 普段の開発でGoは大変慣れ親しんでいるので開発してもメンテしても 我々のスキルセットとして面倒が見れそう ○ GoBGPのメンテナンスが大変しっかりしてて、コードベースが綺麗である点に好感がある ● VPPにはGoVPPというAPIを自動生成する機能があり、それを経由すれば Goを利用した開発が綺麗にできる。GoBGPで経路を入れれば... ● しかしGW/PEの動作を実現するためには後述する取り組みが必要でした...

VPPで取り組んでいる機能 ● そもそもSRv6 MUP Uplane Pluginに対してのAPIの口がなかった ○ 37628: srv6-mobile: Implement SRv6 mobile API funcs （レビュー中） ○ 詳細: VPPにSRv6 MUP Plugin APIを追加している話 ● PEのDLの際に複数のSrcアドレスを適用したい ○ つまりN3の口になってるGWが複数ある場合を想定しており、これによりDLが実装可能に。 ○ 37863: sr: support define src ipv6 per encap policy （マージ済み） ● GWのULでLookupの際にTEIDを見る機能がない ○ https://github.com/takehaya/vpp/tree/mup_ctl_develop ○ Draftの提案者が実装したものを僕らが使うDplaneに移植 ○ (初めは独自実装の作業してましたが、後から提案者の方と話しててそちらをupstreamに入 れたいとのことだったのでこちらを移植して使えるようした) ○ これによりULが実装可能になる

GoBGPで取り組んでる機能 ● 実装済みの機能 ○ Initial support for BGP-MUP SAFI and Extended Community #2567 ○ Fixes for BGP-MUP SAFI and support Prefix SID attribute in Interwork/Direct Segment Discovery route #2583 ○ その他 nitsなfixや改善...etc(合計 14個のPRが取り込まれている） ● 今後追加したい機能 ○ VRFにSegment情報を設定したら広報できる機能 ● 詳細: GoBGPにBGP Extensions for the Mobile User Plane (MUP) SAFIを 実装した話 | BBSakura Networks Blog

MUP-VPP-Agent ● GoBGPとVPPを繋ぐAgentの実装（🚧作業中🚧） ● 4つの経路を受け取り、指定された設定に合わせて経路の組み合わせから、 VPPに対して経路を注入や更新削除などが可能な実装を目指します ● 特定の経路の組みとあらかじめ指定したActionを元に動作 ○ 指定したAction(e.g. H.Encap)の紐付けはどのRT（VRF）に保存されてるかで決定する ● ULではST1&DSD Routeの組み ○ Direct Segment IDをキーに組みを作る ● DLではST2&ISD Routeの組み ○ gNB Addressをキーに組みを作る

その他の取り組み ● 複数の実装を通じてSRv6MUPを広めたり利活用を進めたい ● FRRouting ○ https://github.com/higebu/frr/tree/bgp-mup ○ 鋭意作成中... ● ExaBGP ○ https://github.com/Exa-Networks/exabgp/pull/1142 ○ 実装完了済み！ ○ アップストリームに取り込み済み:) ○ 合計8つのPRがマージ済み

IETF 116で行った 相互接続性検証について

IETF116 Hackathon ● https://wiki.ietf.org/en/meeting/116/hackathon ● BGP-MUP SAFI Implementation and Interop ● これはいくしかない！ ● チームBBSakura(OSSBGPd野郎Bチーム) として@higebuとGoBGP＆ExaBGP の二つの実装を担いで 2日間参加してきました

IETF116 Hackathonの雰囲気

BGP-MUP SAFI Implementation and Interopの結果 ● CML2上のブリッジ機能を通じて各機能の相互接続を検証した ● Arrcus(ArcOS), Furukawa(FX), Cisco(XRd),GoBGP,exaBGPの 5つの実装のinteropが無事成功した🎉🎉

Interopの結果得た洞察その1 ● RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop ● テスト環境はBGPのトランスポートがIPv6 ● しかし広報する経路情報に含まれるプレフィックスがIPv4の場合がある ● その場合にNLRIに含まれるNext hopにIPv6のみを受け入れる実装とそうでない (IPv4も受け入れる)実装がありました。 ○ つまりAFIがIPv4でNLRIのNHがIPv6のケースを許容するか ● GoBGP, ExaBGPでは最初にIPv4のNHにしていたためエラーを返されました ● 結論: 経路広報時はAFIがv4でもトランスポートがv6ならNHにはv6を入れよう ○ RFC8950にはSAFI=128,129の時にRDをつけるということが書いててMUPに関してはまだ 書かれてないのでどうする？という話がありましたが、とりあえず世の中にある既存実装 はRDなしで動くようになってます

Interopの結果得た洞察その2 ● Type 1: Interwork Segment Discovery Route (ISD) の Prefix ● ISD の Prefix は明確に 以下のように書いてる ○ Prefix Length (1 octet) ○ Prefix (variable) ● 3GPP 5G の場合は gNodeB の N3 インターフェースのアドレスになるということからか、 /32 固定で実装してしまうことがあります。→これは間違い ● どうするべきか？/24であれば3byte, /16は2byteで表現をするべきでこれはBGPでは一般的 ● つまり10.0.1.0/24 という表現の場合は 4byteを入れるのではなく3byteの値をフィールドに入れ ようということです。 ● 結論: 書いてある通り、BGPで一般的に使われている Prefix として実装しましょう。 +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Prefix Length (1 octet) | +-----------------------------------+ | Prefix (variable) | +-----------------------------------+

Interopの結果得た洞察その3 ● Type 4: Type 2 Session Transformed Route (ST2) の TEID ● Endpoint Length が BGP でよくある Prefix Length と同等ではない ● つまり以下の長さが含まれる ○ Endpoint Address ○ TEID ● つまりEndpointAddressがIPv6でTEIDの最大値ならEndpointLengthは160、 TEIDが最小値なら129になります。 ● 結論: 書いてある通り、BGPで一般的に使われている Prefix として実装しましょう。 ● 普通のモバイルだとTEID も Prefix のように扱って集約可能という発想にならない感じがしますが これこそが3GPPアーキテクチャとSRv6MUPアーキテクチャで異なるところで、 経路として扱うことで集約できるという良いところです。そのように実装しましょう。 +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Endpoint Length (1 octet) | +-----------------------------------+ | Endpoint Address (variable) | +-----------------------------------+ | Architecture specific Endpoint | | Identifier (variable) | +-----------------------------------+ 3gpp-5g Specific BGP Type 2 ST Route +-----------------------------------+ | TEID (0-4 octets) | +-----------------------------------+

時間が許せば 相互接続検証体験Demo

Demo ● CML2上に用意した簡単なトポロジで4つの経路Typeの送受信ができるかの InteropDemoをexabgp, gobgpを用いて行う ● 双方向から受送信して受けれてるかを見てみる ○ ここで聴講者限定✨豪華お土産✨Demoを再現するためのコンフィグ ■ CML2を持ってる人向けコンフィグ(自分の環境向けにsshkeyとかは変えてください): demo_cml2_mup_exabgp.yaml ■ CML2持ってないnetns至上主義者向けコンフィグ: BGP Extensions for the Mobile User Plane (MUP) SAFI for exaBGP ens3:10.0.1.1 ens3:10.0.1.2

まとめと宣伝 ● SRv6 MUPを動かすためにOSSに対してコントリビュートしてる ● Dplane/Cplaneを合わせてMUP-GW/PEにするAgentを実装している ● IETF116でBGP-MUPの相互接続の検証を完了した ○ （デモをやってたら）「皆さんも無事相互接続性を検証できましたね！」 ● 相互接続の結果、実装のポイントが存在することがわかった ○ 百戦錬磨の開発者たちでも仕様を勘違いするレベルの難しさの洞察を得れたのが良かった ● We are hiring中です！ ○ この発表にワクワクできて、ドラフトやRFC,3GPP等を読み解くのが好きで、Go,C,Python などを読み書きできて、LinuxやSRv6,BGP,k8s,public cloud(GCP)に詳しく、 高速パケット処理系や可用性の高いネットワークとコントローラーの実装ができるよ！ って方をお待ちしてます！:) ○ 僕らと一緒にモバイルの未来をこの手で作りましょう！

Enabling a Connected Future.

おまけ BGP-MUP SAFI

BGP-MUP SAFI ● I-D.draft-mpmz-bess-mup-safi ● セッション情報をBGPの経路として配る仕組み ● BGP-MUP NLRI ○ Architecture Type ■ 1: 3gpp-5g ○ Route Type ■ 1: Interwork Segment Discovery route ■ 2: Direct Segment Discovery route ■ 3: Type 1 Stream Transformed (ST) route ■ 4: Type 2 Stream Transformed (ST) route ● BGP MUP Extended Community +-----------------------------------+ | Architecture Type (1 octet) | +-----------------------------------+ | Route Type (2 octets) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+

BGP MUP Extended Community ● IANA: BGP Transitive Extended Community Types ○ 0x0c SRv6 MUP Extended Community ● Sub-Type ○ 0x00 Direct-Type Segment Identifier type ● Value ○ 6 bytes Direct Segment Identifier ● Direct Segment Discovery routeとType 2 ST routeで使う 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0c | 0x00 | Direct Segment Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direct Segment Identifier (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BGP-MUP SAFI Route Types 1. Interwork Segment Discovery route (ISD) ○ Interwork Segmentを収容するPE(VRF)で生成される ○ 3GPP 5GではN3 RANインターフェース 2. Direct Segment Discovery route (DSD) ○ Direct Segmentを収容するPE(VRF)で生成される ○ 3GPP 5GではN6 DNインターフェース 3. Type 1 Session Transformed route (ST1) ○ MUP-Cが生成する ○ 3GPP 5GではUEアドレス、TEID、QFIなどUplink方向のSIDを生成するための情報を含む 4. Type 2 Session Transformed route (ST2) ○ MUP-Cが生成する ○ 3GPP 5GではgNBのN3アドレス、TEIDなどDownlink方向のSIDを生成するための情報を含む

1. Interwork Segment Discovery route ● RD ● Prefix Length ○ AFI_IP: 最大32 ○ AFI_IP6: 最大128 ● Prefix ○ gNodeBのN3アドレス(IPv4 or IPv6) ● Route Target Extended Community(MUST) ● Next hop(MUST) ○ PEのIPv6アドレス ● Prefix-SID Attribute(MUST) ○ Locator ■ PE ○ Function ■ AFI_IP: End.M.GTP4.E ■ AFI_IP6: End.M.GTP6.E +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Prefix Length (1 octet) | +-----------------------------------+ | Prefix (variable) | +-----------------------------------+

2. Direct Segment Discovery route ● RD ● Address ○ Unique PE identifier ● Route Target Extended Community(MUST) ● MUP Extended community(MUST) ○ Direct Segment Identifier ● Next hop(MUST) ○ PEのIPv6アドレス ● Prefix-SID Attribute(MUST) ○ Locator ■ PE ○ Function ■ End.DT4/6, End.DX4/6 or End.M.GTP4/6.E +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Address (4 or 16 octets) | +-----------------------------------+

3. Type 1 Session Transformed (ST) route ● RD ● Prefix Length ○ AFI_IP: 最大32 ○ AFI_IP6: 最大128 ● Prefix ○ UEアドレス ● TEID ○ gNodeB側のTEID ● QFI ● Endpoint Address Length ○ IPv4: 32 ○ IPv6: 128 ● Endpoint Address ○ gNodeBのN3アドレス ● Route Target Extended Community(SHOULD) ● Next hop(MUST) ○ MUP-Cのアドレス +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Prefix Length (1 octet) | +-----------------------------------+ | Prefix (variable) | +-----------------------------------+ | Architecture specific (variable) | +-----------------------------------+ 3gpp-5g Specific BGP Type 1 ST Route +-----------------------------------+ | TEID (4 octets) | +-----------------------------------+ | QFI (1 octet) | +-----------------------------------+ | Endpoint Address Length (1 octet) | +-----------------------------------+ | Endpoint Address (variable) | +-----------------------------------+

4. Type 2 Session Transformed (ST) route ● RD ● Endpoint Length ● Endpoint Address ○ UPFのN3アドレス ● TEID ○ コア側のTEID ● Route Target Extended Community(MUST) ● MUP Extended community(MUST) ○ Direct Segment Identifier ● Next hop(MUST) ○ MUP-Cのアドレス +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Endpoint Length (1 octet) | +-----------------------------------+ | Endpoint Address (variable) | +-----------------------------------+ | Architecture specific Endpoint | | Identifier (variable) | +-----------------------------------+ 3gpp-5g Specific BGP Type 2 ST Route +-----------------------------------+ | TEID (0-4 octets) | +-----------------------------------+