Segment Routingを用いたEPEの活用事例と GoBGPへの実装

Segment Routingを用いたEPEの活用事例と GoBGPへの実装
- 三島航 (NTTコミュニケーションズ株式会社)
- 豊田安信 (慶應義塾大学/株式会社ブロードバンドタワー)
- 金谷光一郎 (東京大学)

ENOG77 イベントページ: https://enog.jp/archives/2657

Transcript

1. Segment Routingを用いたEPEの活用事例と GoBGPへの実装 Wataru Mishima NTT Communications Corporation Yasunobu Toyota Keio University / BroadBand Tower, Inc. Koichiro Kanaya The University of Tokyo 1
2. 1. Key Ideas of Egress Peer Engineering ◦ About Egress Peer Engineering ◦ D-Plane: SRv6 ◦ C-Plane: BGP-LS EPE 2. Our Activities about SRv6-EPE ◦ Performance Aware Egress Path Discovery for Content Provider with SRv6 Egress Peer Engineering ◦ QoE-Aware Content Oriented Path Optimization Framework with Egress Peer Engineering 3. GoBGP Implementation of BGP-LS EPE ◦ Development Background ◦ Steps in the Development of BGP-LS EPE 4. Conclusion & Future Works 5. Discussion Agenda 2
3. About us 3 Yasunobu TOYOTA Dr. student at Keio Univ. Researcher at BBTower, Inc. WIDE Project vSIX WG chair Koichiro KANAYA Master student at The University of Tokyo WIDE Project vSIX WG member Wataru MISHIMA Researcher & Developer at NTT Communications Corporation WIDE Project vSIX WG member watal_i27e https://github.com/watal yasnyannet https://github.com/yas-nyan kanaya516 https://github.com/kanaya516
4. vSIX (IPv6 Single-stack Infrastracture Experimental network) 活動： • IPv6 single-stack ASの運用（AS4690） • 次世代のインターネット運用技術の開発・検証 • ワカモノの育成 • インターネットコミュニティへの貢献 メンバー: 産学の若手エンジニアが中心に50人以上 vSIX WGについて 4 WIDE Project: https://www.wide.ad.jp vSIX WG: https://www.vsix.wide.ad.jp
5. 本セッションの目的 • EPEの運用と研究を通じて得られた知見を共有＆議論 ◦ EPEの可能性や活用に興味を持っていただくとともに、今後の研究につながる議論をしたい！ • 下記の2点を通じ、EPEについて紹介！ 1. EPEの技術説明とvSIX WGで運用・研究した活用事例紹介 ▪ SRv6 BGP-EPEを用いたBGP best path計測 ▪ コンテンツ毎にQoEを向上させるためのSRv6 BGP-EPEフレームワーク 2. EPEを広く使っていただくためのOSS Contribution - GoBGPへの実装事例の紹介 ▪ 開発背景・開発の流れやステップ ▪ 開発合宿の成果 5 本セッションに参加することで、EPEの魅力や活用手法などを体感いただけます！
6. 1. Key Ideas of Egress Peer Engineering 6
7. • EPEとは ◦ Egress Trafficに対し，利用するASBRと転送先のEgress Peerを指定し制御する技術 ▪ 従来はBGPパラメータを用いてNW全体で制御されてきたが、より細かい単位でも制御したい！ • EPEのモチベーション ◦ ユーザへのE2E通信品質が良い経路を利用したコンテンツ提供 ◦ 外部接続リンクの利用効率化 AS65003 AS65002 AS65001 What is “Egress Peer Engineering” ? 7 パスの 切り替え コンテンツプロバイダ（AS65000） ASBR Egress Peer Egress Peer Egress Peer Server X Server Y Server Z Data Center Network BGPベストパス 代替パス ASBR 通信品質の劣化
8. D-Plane: SRv6 EPE • SRv6: IPv6拡張ヘッダ（SRH: SRヘッダ）を用いるソースルーティング技術 ◦ IPv6フォーマットのSegment IDentifier（SID）によって中継ノード上で任意の機能を実行 ◦ PBR等と組み合わせIP Prefixに囚われない柔軟な経路制御も可能（C-Planeの工夫しどころ） ◦ • データプレーンの流れの例 1. head-end（Content Server）でSRヘッダをencap 2. DCNは通常のIPv6パケットとして透過 3. tail-end（ASBR）でSRヘッダをdecap，特定のネクストホップへ転送 8 packet SRH decap and forward to Egress Peer 1 via Egress Peer 1 packet Content Server DCN ASBR Egress Peer 1 Egress Peer 2
9. • 必要なC-Planeの機能 1. 特定のEgress Peerに対応するSIDの広告 ▪ BGP-LS（RFC9086） • RFC9086で提案されているが，実装はまだ発展途上 ▪ その他 (SDNで頑張る) C-Plane Requirements for EPE（1/2） 9 EPE-SID 1::1 for Peer 1 EPE-SID 2::2 for Peer 2 SIDの広告 EPE SID の発行 Content Server DCN ASBR Egress Peer 1 Egress Peer 2
10. 2001:db8::/64 への到達性アリ 2001:db8:1::/64 への到達性アリ • 必要なC-Planeの機能 2. SIDとPrefixの対応付け: ✔ RFC9086では，EPEコントローラが以下のどちらかを行い，head-endのencapsulationポリシー (EPEポリシー) を決定。（具体的なメッセージングフォーマットは未定義） • 1. EPEコントローラがASBRとiBGPピアを張り，Add-PathをASBRから受信 • 2. EPEコントローラがBMPを使用してASBRのAdj-RIB-Inを追跡 ▪ Egress Peerから経路の広告がなければ，その経路を宛先としてそのEgress Peer経由で パケットを転送してはならない C-Plane Requirements for EPE（2/2） 10 SIDとPrefixの広告 1::1 2::2 宛先2001:db8::/64 へは，1::1というSID をencapし送信して良 いんだな 宛先2001:db8:1::/64 へは，2::2というSID をencapし送信して良 いんだな EPEコントローラ Content Server DCN ASBR Egress Peer 1 Egress Peer 2
11. C-Plane Requirements for EPE（2/2） • 必要なC-Planeの機能 2. SIDとPrefixの対応付け: ▪ RFC9086では，EPEコントローラが以下のどちらかを行い，head-endのencapsulationポリシー (EPEポリシー) を決定。（具体的なメッセージングフォーマットは未定義） • 1. EPEコントローラがASBRとiBGPピアを張り，Add-PathをASBRから受信 • 2. EPEコントローラがBMPを使用してASBRのAdj-RIB-Inを追跡 ✔ Egress Peerから経路の広告がなければ，その経路を宛先としてそのEgress Peer経由で パケットを転送してはならない 2001:db8::/64 への到達性アリ 2001:db8:1::/64 への到達性アリ 11 SIDとPrefixの広告 1::1 2::2 宛先2001:db8::/64 へのエントリから， SID 1::1 を削除！ 宛先2001:db8:1::/64 へは，2::2というSID をencapし送信して良 いんだな EPEコントローラ Content Server DCN ASBR Egress Peer 1 Egress Peer 2
12. 2. Our Activities about SRv6-EPE 12
13. Our Activities • AS 4690の運用を通じたBGP-EPEの研究チーム ◦ EPEのもつ可能性を検証し、運用成果を研究につなげる ◦ IPv6 Single-Stackなネットワークを活かし、SRv6 BGP-EPEを運用中 • BGP-EPE活用手法を提案・検証！ ◦ EPEは意味があるのか？: BGP best pathの品質測定システムの提案＆計測結果の評価 ▪ Performance Aware Egress Path Discovery for Content Provider with SRv6 Egress Peer Engineering IEICE Inf&Sys 2023年5月号（出版予定） ◦ EPEは運用可能なのか？: コンテンツのQoEを向上させるEPEフレームワークの提案 ▪ QoE-Aware Content Oriented Path Optimization Frameworkwith Egress Peer Engineering CANDAR 2022 13 実用網やプロダクトでの活用事例を通じ、EPEの持つ利点やポテンシャルを紹介！
14. 2.1 Performance Aware Egress Path Discovery for Content Provider with SRv6 Egress Peer Engineering 14 IEICE Inf&Sys 2023年5月号（出版予定）
15. 15 コンテンツプロバイダから見たインターネット 15 そもそもウチのNW/コンテンツで、 EPEをすることによるメリットが あるのかわからないな... どのPeerの経路を優先すればいいのかな？ お客さんのISPにも依存するし、 サービスごとに必要な品質は違うしな... コンテンツプロバイダ の運用者
16. 定量的に外向きの経路(Egress Path)を評価する仕組みが必要 16 16 提案 評価機構の要件： ①様々なQoS Metricsを扱えること - 遅延以外の要素もコンテンツ配信には重要 ②実際のNW/アプリケーションで調べること - コンテンツアプリケーションの品質を向上させるために測るので、そのコンテンツ自体で測らないと意味がない。 ③デプロイメントのインパクトが小さいこと → SRv6 EPE とPassive End-to-End Measurementで、 自分のASでEPEが有効かどうか測りましょう！
17. ネットワーク： vSIX AS(AS4690)で実験を実施 17 評価実験：実験環境 調査対象としたコンテンツ： スマホ用のスピードテストアプリのテストトラフィック 1アクセス毎に6並列で100MBのダミーデータをHTTP GET Wi-Fiミレル | ネットワーク関連 | IODATA アイ・オー ・データ機器 ※バックエンドは https://inonius.net Special Thanks: iNonius Project, IODATA-san. ↓ 某学術系AS ↑ 商用系AS ←凡そ10万人が利用 ←殆ど日本からのアクセス
18. AS 4690 所属AS other ASs speedtest server ASBR SRv6 domain 評価実験： EPE トラフィックの流れ AS β AS α Internet IF つけられたSIDに基づいて どちらかのpeerに配送 DL TrafficをL4 ECMPで どちらかのSIDに SRv6 encap DL Traffic アプリ利用者 UL Trafficは BGP Best pathで流入 一度のスピードテストに6つのTCPセッションを利用。 各セッションはECMPによってどちらかのpeerへ配送 18
19. 19 評価実験：メトリクスの解析の仕組み トラフィックの品質そのものを 計測・保存 どのトラフィックが どのEPE-SIDを利用したか記録 配送に利用された(と推定される) BGP Pathの情報 ログの集約や紐付け どっちのPathが 良かったかを評価
20. 20 20 実験結果 当日のみご紹介します！お楽しみに！
21. 結論: EPEは意味があった！ SRv6 EPE と Passive End-to-End Measurement で 既存のNWに変更を及ぼすことなく Egress TEがQoS向上に有効かどうか調べられる！ 我々のAS・サービスでは、 15％のユーザの品質向上が期待出来ることがわかりました！ 23 23 大掛かりな仕組みを入れなくても EPEのメリットがわかって嬉しい！ ※IEICE Inf&Sys 2023年5月号で出版予定
22. 24 CANDAR 2022 2.2 QoE-Aware Content Oriented Path Optimization Framework with Egress Peer Engineering
23. コンテンツプロバイダ (AS65000) • COFFEE: Content-Oriented Flexible Framework of Egress Engineering ◦ インターネットを介したコンテンツのエンドツーエンドのQoEを向上が目的 ◦ インテント（EPEポリシー）を投入すれば，自動で計測・評価・制御が可能 ▪ 一部のトラフィックは計測用に利用 ▪ インテントの例: RTTが最小となる経路 AS65003 AS65002 AS65001 COFFEE: EPE framework for content quality 25 25 Egress Peer 2 Egress Peer 3 Egress Peer 1 サーバX サーバY サーバZ EPEポリシーの定義 DCN BGPベストパス 代替パス を計測/評価し， 評価結果に応じて制御 25 コンテンツ オペレータ ASBR 2 ASBR 1
24. ASBR 2 ASBR 1 1. コンテンツサーバ: EPEの計測・評価・制御．パケットにSRHをカプセル化する 2. ASBR: SRHを取り除き特定のEgress Peerへパケットを転送する 3. EPEパスアグリゲータ: コンテンツサーバの経路の正当性を保証（like EPEコントローラ） 構成要素 コンテンツプロバイダ (AS65000) ✔ ✔ ✔ ✔ ✔ BGPパスを反映 COFFEE enabled host packet SRH packet SRH via C decap Contents Server EPEパスアグリゲータ AS65003 AS65002 AS65001 Egress Peer 2 Egress Peer 3 Egress Peer 1 DCN encap 26
25. ③現在の状態を反映 • Kubernetesとは？ ◦ Kubernetesは，オープンソースのコンテナオーケストレーション・フレームワーク ◦ カスタムリソース・カスタムコントローラとして，独自のリソースやコントローラを定義可能 ▪ カスタムリソース：”あるべき状態”を定義 ▪ カスタムコントローラ：カスタムリソースの変更を検出し，宣言的な動作を行う ◦ 簡単かつ統一的にデータモデル・コントローラを定義可能であるため採用 27 Kubernetes Implementation カスタムリソース カスタムコントローラ ①変更を検出 Kubernetes spec: あるべき状態 status: 現在の状態 ②定義された 動作を実施
26. 28 28 実装（全体像） flow-assessor epe-path-con stats-mon sid-mon カスタムコントローラ カスタムリソース flow-score epe-egress- peer srv6-epe-rule epe-rule-con bgp-con EPEライフサイクル EPEライフサイクル リソースに反映 リソースの監視 以下のリソース，コントローラをスクラッチで定義・実装 カスタムコントローラ ではない
27. 29 29 実装（全体像） flow-assessor epe-path-con stats-mon sid-mon カスタムコントローラ カスタムリソース flow-score epe-egress- peer srv6-epe-rule epe-rule-con bgp-con EPEライフサイクル EPEライフサイクル リソースに反映 リソースの監視 以下のリソース，コントローラをスクラッチで定義・実装 カスタムコントローラ ではない こんなのを見せられても 何がなんだか 分からないよ！！！
28. 30 30 実装（全体像） flow-assessor epe-path-con stats-mon sid-mon カスタムコントローラ カスタムリソース flow-score epe-egress- peer srv6-epe-rule epe-rule-con bgp-con EPEライフサイクル EPEライフサイクル リソースに反映 リソースの監視 以下のリソース，コントローラをスクラッチで定義・実装 カスタムコントローラ ではない ということで， 一部分だけご紹介いたします
29. 31 31 実装: 経路切替の実現手法 カスタムリソース カスタムコントローラ （実際はサーバ内で動作） サーバ （server1） ②コマンドを実行 ip -6 route replace … srv6-epe-rule epe-path-controller Kubernetes上で, カスタムリソース＆カスタムコントローラにより経路切替を実現！ • srv6-epe-rule: どのようにFIBを制御するか．SIDや5-tupleに対する重み • epe-path-controller: srv6-epe-ruleを監視し，その変更内容を元にサーバのFIBを操作 Kubernetes ③現在の状態を反映 ①変更を検出 spec: dst 2001:db8::/64 sport 443 sid 1::1 weight 1 sid 2::2 weight 2 3 server-name server1
30. コンテンツプロバイダAS（AS4690） 重み: 3 重み: 3 コンテンツサーバ（live1.vsix.wide.ad.jp）からテストクライアントまでのパス • BGPベストパス: AS β 経由 • 代替パス: AS α 経由 32 32 実験: フィジビリティ検証 AS β AS α BGP ベストパス 代替パス ASBR 1 EPEパス アグリゲータ ASBR 2 DCN Contents Server Internet Test Client Egress Peer 1 Egress Peer 2
31. • コンテンツサーバはQoSメトリクスを収集 • BGPベストパス上に擬似障害が発生した場合に，FIBが変更するまでの時間を計測 ◦ 擬似障害の発生のため，tcコマンドを利用しトラフィックに遅延や帯域制限などを付与 33 33 実験: フィジビリティ検証（詳細） コンテンツプロバイダAS（AS4690） BGP ベストパス 代替パス tcコマンド で擬似障害 QoSメトリクス監視 FIB収束時間監視 重み: 1 重み: 3 AS β AS α ASBR 1 EPEパス アグリゲータ ASBR 2 DCN Contents Server Internet Test Client Egress Peer 1 Egress Peer 2
32. → RTT，スループット，ジッタ，パケットロス率，それらの複合でもフィジビリティ確認 • フィジビリティ検証として下記2点を検証 1. 擬似障害が発生し，BGPベストパスの重みが小さくなるか 2. 擬似障害が復旧し，BGPベストパスの重みが大きくなるか • 以下のグラフは，BGPベストパスと代替パスにおけるRTTの時系列データ ◦ ①とFIB変化①（②とFIB変化②）は共に1.12秒，1.57秒 結果: フィジビリティ検証 BGPベストパス 代替パス 擬似障害 → ← FIB 変化① ← FIB 変化② 擬似障害復旧 → ① ② 重みが1 重みが3 34
33. まとめ - Our Activities • EPEは意味があるのか？ ◦ EPEを利用して、実際のインターネットでの有効性を検証 ▪ (我々の環境では) コンテンツ配信のQoS向上に効果アリ • EPEは運用可能なのか？ ◦ EPE運用に必要な要素・機能を整理 ◦ SDNによるEPEフレームワークを開発・構築・運用し、フィジビリティを検証 ▪ “COFFEE”でコンテンツ配信のQoS向上を目的としたEPEは運用可能！ → ただ、まだ一般性に欠ける... 汎用C-Planeで実現した方が筋が良いかも？ ▪ フルルートは？ プロダクションルーターは？ ▪ 広く使える実装が欲しい ＆ 将来的には求める機能の実装がしたい！ 35 EPEはコンテンツ配信のQoS向上に効果アリ！ 運用も可能！ ただ、C-Planeの実装方法はもうちょっと考えたほうが良さそう. 更なる活用を見据え、汎用C-Planeと拡張性の両立を目指す！
34. 3. GoBGP Implementation of BGP-LS EPE 36
35. • 必要なC-Planeの機能 ◦ 特定のEgress Peerに対応するSIDの広告 ▪ BGP-LS（RFC9086） • RFC9086で提案されているが，実装はまだ発展途上 ▪ その他 (SDNで頑張る) (振り返り) C-Plane Requirements for EPE 37 Content Server ASBR Egress Peer 1 Egress Peer 2 EPE-SID 1::1 for Peer 1 EPE-SID 2::2 for Peer 2 SIDの広告 DCN EPE SID の発行
36. • 必要なC-Planeの機能 ◦ 特定のEgress Peerに対応するSIDの広告 ▪ BGP-LS（RFC9086） • RFC9086で提案されているが，実装はまだ発展途上 ▪ その他 (SDNで頑張る) → OSSのBGP-LS実装は存在しない！ ならば自分たちで作ってみよう！ (振り返り) C-Plane Requirements for EPE 38 EPE-SID 1::1 for Peer 1 EPE-SID 2::2 for Peer 2 SIDの広告 via BGP-LS EPEコントローラ EPE SID の発行 Content Server ASBR Egress Peer 1 Egress Peer 2 DCN
37. What is GoBGP? • Goで開発されたOSSのルーティングデーモン ◦ 高い拡張性と豊富な機能 ◦ gRPCによるデータ連携 ◦ Zebraを介したカーネル経路との連携 • BGP-LS EPEの開発にあたり、下記のポイントを考慮しGoBGPを選定！ ◦ OSS: 自分たちが欲しい機能を拡張可能 ◦ Goへの理解: 先程のCOFFEEフレームワークもGoで開発 → 各自経験あり ◦ BGP-LSの下地: IGP Link Stateについてはある程度開発済 39 https://github.com/osrg/gobgp
38. • タスクを整理＆コミュニティへ共有！ ◦ 実施内容＆目標を明確化 ◦ 他の開発者とのタスク分離＆作業内容衝突の回避 https://gobgp.slack.com BGP-EPEの実装に向けて 40 https://github.com/osrg/gobgp/issues/2616
39. • まずは実装に向けた流れを整理。大きく分けて4ステップ ◦ まずはSR-MPLSでStep2まで対応済 ▪ C-PlaneとgRPC APIを実装！ • vSIX EPE分科会の3名で開発合宿（各3日間） ◦ 第1回: C-Plane implementation（RFC9086） ◦ 第2回: gRPC API + Confederation いざ開発！ 41 1. BGP-LS EPE extentionのTLV実装 2. BGP-LSのgRPC対応 3. BGP peer up/down に伴うEPE SIDの発行/削除 4. FIB Install (Zebra APIの拡張)
40. GoBGPで新しいNLRI/PathAttrを作る流れ 42 データ型（構造体・Interface）を定義 1 ベンダ機器とのデータ送受信を確認 2 gRPC protoの拡張＆コンパイル 3 apiutilにUnmarshal/Marshalを実装 4 RFCから実装対象のPathAttr＆TLVを確認 パケットもキャプチャしつつ、データ型＆Methodの正しさを検証 まずはBGP RIBの確認が主目的。protoのコンパイルはREADME.mdの手順を参照 gRPCデータと構造体・Interfaceとの送受信が可能に！ パケットキャプチャを交えつつ動作を確認！ 5 TLVの有無や、計算が必須なLength等のパラメータもチェック！ Branch作成 PR提出！
41. • Cisco/Juniperと相互接続可能なBGP-LS EPEとgRPC APIを実装完了！ • GoBGPへのContribution ◦ BGP-LS EPEはGoBGP v3.10.0以降、gRPC機能はv3.11.0以降でそれぞれ利用可能！ ◦ 迅速な Review＆Merge＆Release ありがとうございました🙏 開発合宿の成果 🎉🎉 43
42. • (我々の成果物で) 皆様ができるようになったこと ◦ 標準的なBGP-LSを利用してEPE-SIDのメッセージングが出来るようになりました！ ▪ 現在SR-MPLSのみ。SRv6はまた形式が異なるが...(現在wg-draft) ◦ Cisco / JuniperとのInteroperability testにも成功しました！ ◦ (ついでに) BGP-LSの他の機能もgRPC経由で操作できるように。 • (開発をしてみて) 我々が成長したこと ◦ GoBGPに新しい機能を実装するコツがわかりました！ ▪ 迅速なコミュニティ対応は開発の大きなモチベーションになりました！ ◦ EPEに関連する機能で、現在のRFC/I-D・他社ルータの出来ること・出来ないことを認識 ▪ SRv6-EPEにはまだまだ未確定の部分が多く課題が多い。 44 44 まとめ - GoBGP Implementation of BGP-LS EPE GoBGPへのContributionを通じて、 C-Planeの勘所を把握 & EPE用の汎用C-Planeを獲得！ OSSへのコントリビューションって良いものですね
43. 4. Conclusion & Future Works 45
44. • vSIXでの研究＆開発＆運用の結果、EPEやSRv6の持つ可能性を検証＆提案 ◦ SRv6 EPEとE2E計測を利用し、EPEが有用であることを評価 ▪ 実環境においてASごとのBGP best pathの性能を測定 ◦ コンテンツ提供者ごとの要求に合わせたQoS/QoE向上を実現！ ▪ k8sを活用したSDNフレームワークを実装＆評価 • BGP-LS EPEを実装 & GoBGPへContribution！ ◦ 汎用的なプロトコルでの実装。研究成果が広く使われるための下地になることを期待 ◦ WGメンバーの開発能力＆プロトコルへの理解力向上 46 46 EPE活用＆BGP-LS開発を通じて得られたこと 今後もEPEの利便性を実証するとともに、誰もが使える世界を目指します！
45. 今後取り組むべき課題 • GoBGPへのさらなる機能追加 ◦ SR-MPLS Step3 & 4 ◦ SRv6実装 • C-Planeの整理 ◦ EPEのC-PlaneはEPE情報をどのように伝えるべきか ◦ 例えば経路と紐づけて送ることで、より効率的な経路制御が可能になるのでは？ • どうやって「最適なパス」を探すかの方式検討 ◦ コンテンツサーバーでの運用戦略の検討 • 標準化？ ◦ 必要なデータ(Prefix + SID)をC-Planeとして送る仕組み ◦ D-Planeの新たな用い方：End.DX6 • EPEの運用モデルのドキュメント化 ◦ 仲間探し！ 47
46. さらなる研究テーマ 48 以降は研究中の内容のため、会場のみでの公開とさせてください
47. WIDE Project vSIX WG www.vsix.wide.ad.jp Thank you for listening