SDNという名のデータプレーンプログラミングの歴史

Transcript

1. SDNという名の データプレーンプログラミングの歴史 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken

   ENOG84 SDN温泉＠月岡温泉 白玉の湯 泉慶 （2024/11/22） 海老澤 健太郎 | Twitter (X) @ebiken | @ebiken.bsky.social 背景：月岡温泉 白玉の湯泉慶 https://www.senkei.com/

2. ENOG84 Meeting https://enog.jp/archives/2927 • 14:00~14:20 “導入” 浅間 正和 (有限会社銀座堂) •

   14:20~15:00 海老澤 健太郎 (Arrcus, Inc.) • “SDNという名のデータプレーンプログラミングの歴史” • 15:00~15:40 進藤 資訓 (ヴイエムウェア(株) / Broadcom) • “SDNのHype Cycleを一通り経験してみて思うこと” • 15:40~16:20 中嶋 大輔 (F5) • “F5XCの分散コントローラとデータプレーンアーキテクチャについて～ SDNを利用したNaaSサービスの展開～” • 16:20~17:00 堀場 勝広 (アマゾンウェブサービスジャパン合同会社) • “テレコムキャリア網を前提に考えていたSDNのあれこれ” SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 2

3. Table of Contents • 本プログラムにおけるSDNの分類 • “Software Defined” とは “API”

   である • OpenFlow == データプレーンのAPI • OpenFlow(純粋SDN)の課題 • 課題(1) 自由なAPI（OpenFlow）<=> 不自由なデータプレーン（スイッチ） • データプレーンプログラマビリティとは？ • プログラマビリティのジレンマ • OpenFlow(純粋SDN)の課題 • 課題(2) SDNを欲しかったのはネットワークオペレーターでは無かった？ • サーバーサイドでの “ネットワーク機能のアクセラレーション” • サーバーサイドにおけるデータプレーンプログラマビリティ • まとめ SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 3

4. SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken Research &

   Support Engineer Netmarks Mar 1998 ~ Jun 2001 Regional manager, Global Support Center Network Appliance Jul 2001 ~ Dec 2006 Director of Service Development Operation SGI Japan Feb 2007 ~ Sep 2008 • Product Intro and Support for Operators • Data Center Operation (energy efficiency) • Technical Team Management Network (Enterprise / Telecom / ISP) ATM, VPN(IPsec), xDSL, MPLS Content Delivery Network & Storage Web/Streaming Cache & LB, NFS/SAN Data Center & SaaS (MEX/SGI) Energy Efficiency, DesktopVPN (SaaS) ~10 years Senior Product Manager Sable Networks Apr 2008 ~ Nov 2010 Solution Architect Parallels Dec 2010 ~ Mar 2014 VP of Technology Riava Jul 2014 ~ Sep 2015 Principal Engineer Lumina Networks Nov 2018 ~ Aug 2020 Co-Founder, CTO Ponto Networks Dec 2015 ~ Jun 2018 Network Automation SDN Controller, Orchestrator OpenFlow, FPGA, WhiteBox NOS Switch Design & Development Flow Router, IPv6/v4 Translation (nat64) Service Automation & Container Operation/Business Support System • Product Design and Development • Management and Board member of Startup Companies • Support Japan Market Entry • Technical Consulting / Support • Open-Source Community 10~20 years Lagopus OF Switch Kentaro Ebisawa（海老澤 健太郎） https://www.linkedin.com/in/ebiken/ Principal Researcher TOYOTA Motor Corp. Nov 2016 ~ Dec 2023 Network Infra for Connected Cars Research Professor NTT Ltd. Dec 2020 ~ Nov 2023 Operator Network Technology TOYOTA InfoTechnology (Nov 2016 ~ Mar 2019) Merged to TOYOTA Mortor Corp on Mar 2019 ~25 years Principal Engineer | Arrcus, Inc. Jan 2024 ~ current Virtualization of Data Plane 4

5. 本プログラムにおけるSDNの分類 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken （再掲：浅間さん資料から）

   狭義のSDN ([PCOVD]の定義によるSDN) • 広義のSDN • 機器の設定自動化や自律分散型プロトコル経由で制御するネットワーク • 純粋SDN • 従来の自律分散型プロトコルによらず全ての データプレーンを集中管理されたコントロール プレーンから直接制御するネットワーク • SDNライト • 従来の自律分散型プロトコルも用いた上で、 差分を制御するネットワーク 5

6. 本プログラムにおけるSDNの分類 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken （再掲：浅間さん資料から）

   狭義のSDN ([PCOVD]の定義によるSDN) • 広義のSDN • 機器の設定自動化や自律分散型プロトコル経由で制御するネットワーク • 純粋SDN • 従来の自律分散型プロトコルによらず全ての データプレーンを集中管理されたコントロール プレーンから直接制御するネットワーク • SDNライト • 従来の自律分散型プロトコルも用いた上で、 差分を制御するネットワーク “純粋SDN” を中心にお話しします 6

7. “Software Defined” とは “API” である SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜

   海老澤 健太郎 @ebiken 7

8. “Software Defined” => APIを利用した、柔軟なアプリケーション開発 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤

   健太郎 @ebiken ネットワークのアプリケーション （例） • 仮想専用線（オーバーレイ・QoS） • セキュリティ（検知・フィルタリング） • トラフィックエンジニアリング（ 検知・冗長 ・負荷分散） “純粋SDN” は上記の “フローの粒度” での実現を目指した 純粋SDNのネットワーク 再掲：浅間さんの資料 API 8

9. SDN以前のネットワーク・アプリケーション開発の制約 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken •

   ルーティングプロトコルレベルの機能と、“設定・監視” に限られたAPI • オペレーターが必要な機能を自由に拡張できない（機器ベンダ依存） 広義のSDNのネットワーク 再掲：浅間さんの資料 SDNの実現には（フロー粒度のプログラミングには） “新しい（データプレーンの）API” が必要 • ネットワーク機器の硬直化 • “設定” はできても “プログラミング” はできない • 機器ベンダによるブラックボックス化 • イノベーションの阻害 9

10. ネットワークの革新には “抽象化” が必要 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎

    @ebiken “Networking Needs Abstractions” , Scott Shenker, 2011 YouTube: https://www.youtube.com/watch?v=YHeyuD89n1Y&t=259s • 抽象化 == API • 各レイヤで独立＆互換性のあるイノベーション 10

11. OpenFlow == データプレーンのAPI SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎

    @ebiken 11

12. OpenFlow Switch OpenFlow == Dataplane API SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉

    ｜ 海老澤 健太郎 @ebiken • Flow Table に Match/Action Entry を設定 • テーブルを順次処理（パイプライン） Controller OpenFlow (set Flow Table entries) 参考：OpenFlow 仕様 “OpenFlow Specification Summary” https://speakerdeck.com/ebiken/openflow-specification-summary 12

13. OpenFlow(純粋SDN)の課題 • 課題(1) 自由なAPI（OpenFlow） ó 不自由なデータプレーン（スイッチ） • 課題(2) SDNを欲しかったのはネットワークオペレーターでは無かった？ SDNという名のデータプレーンプログラミングの歴史

    ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 注：Software Switch (OpenVSwitch) は課題(1)は該当しない 13

14. OpenFlow(純粋SDN)の課題 (1) 自由なAPI（OpenFlow）<=> 不自由なデータプレーン（スイッチ） データプレーンプログラマビリティとは？ プログラマビリティのジレンマ SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉

    ｜ 海老澤 健太郎 @ebiken 14

15. 課題(1) 自由なAPI（OpenFlow）ó不自由なデータプレーン（スイッチ） • 仕様に記載された機能を全て網羅するスイッチの不在 • APIがあっても、既存機能＋ACL以上のプログラムできない • ハードウェアの制約に合わせたプログラミングが必要 • 固定的なパイプライン

    • 限られたテーブル数、エントリ数 • 固定されたマッチフィールドやアクション SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken データープレーンプログラマビリティによる解決 15

16. データプレーンプログラマビリティとは？ SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken ヘッダフォーマットの定義

    パースグラフの構築 ヘッダ解析 （Parse） 処理対象＆ 内容の決定 （Match） マッチフィールドの定義 （Exact / Masked / LPM） MAC address IPv4 address proto + TCP ports ( any header fields ) 変更・転送 （Action） アクションの定義 （ヘッダフィールド変更・追加・削除） bit shift (<<) (>>) add(+) sub(-) multiple(*) drop forward copy push / pop 複雑な処理も基本処理を順に実行することで実現可能（パイプライン処理） 16

17. 「ボトムアップ」 から 「トップダウン」 へ SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤

    健太郎 @ebiken データプレーンプログラミング “P4” の次の一歩 @ONIC2019 https://speakerdeck.com/ebiken/onic2019-p4-dataplane-programming "How We Might Get Humans Out of the Way - Keynote by Nick McKeown", ONF Connect 2019 https://www.opennetworking.org/onf-connect-2019-resources/ スイッチで実現したい機能 ⇒ ASICの機能 ASIC の機能 ⇒ スイッチが実現可能な機能 データプレーンプログラマビリティで実現可能なこと 17

18. データープレーンプログラマビリティの進化（スイッチASIC） SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken もっと昔からあったかも。。。ご存知の方は教えてください

    スイッチASIC 特徴 Caspian Apeiro (*) Þ Sable Networks (*) ASICではなくFlow Router の名前かも？ • マイクロコードの変更によるプログラミング • Caspian (Sable) が実施 • ユーザーによるプログラミングは不可（ASIC仕様非公開） Cavium XPliant • Excel的なツールを利用したパーサープログラミング • （ユーザーもプログラミング可能な場合もあり） • パイプラインのプログラミングは Cavium が実施 Barefoot Tofino • P4言語を用いたプログラミング • ユーザーによるプログラミングは可能（要ライセンス） 2003 2011 2013 18

19. スイッチASICの経済学 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken ASIC単価

    ＝ 開発コスト（膨大） ÷ 出荷数 生き残るためには「出荷数」が重要 => プログラマブルASICならではのキラーアプリは？ 開発コスト（膨大） ＜ ASIC単価 × 出荷数 19

20. プログラマビリティのジレンマ • カスタム機能は普及すれば標準機能になる • INT, NSH, SRv6, ... • 標準機能になれば（当然）プログラマビリティは不要

    • 標準機能にならない機能はニーズが少ない • ニーズが少ないので大量に販売できない • （Alibaba規模のネットワークでも買い支えられない） • プログラマビリティの活用にはエコシステムが必要 • エコシステムの成熟スピードが早くないと、従来品がキャッチアップし不要に • エコシステムが無いと利用者が増えず成熟しない（ニワタマ問題） SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 20

21. “Programmable” を売りにしていない ASIC もプログラマブルに SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤

    健太郎 @ebiken スイッチASIC 特徴 Caspian Apeiro (*) Þ Sable Networks (*) ASICではなくFlow Router の名前かも？ • マイクロコードの変更によるプログラミング • Caspian (Sable) が実施 • ユーザーによるプログラミングは不可（ASIC仕様非公開） Cavium XPliant • Excel的なツールを利用したパーサープログラミング • （ユーザーもプログラミング可能な場合もあり） • パイプラインのプログラミングは Cavium が実施 Barefoot Tofino • P4言語を用いたプログラミング • ユーザーによるプログラミングは可能（要ライセンス） Broadcom (NPL) • NPL言語を用いたプログラミング（C言語ライク） • ユーザーによるプログラミングは理論的には可能（要ライセンス） • https://github.com/nplang/NPL-Spec/ Cisco Silicon One • P4 Programmable?? • ユーザーによるプログラミングは不可（SDK非公開） 2003 2011 2013 2019 21

22. “Programmable” を売りにしていない ASIC もプログラマブルに SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤

    健太郎 @ebiken スイッチASIC 特徴 Caspian Apeiro (*) Þ Sable Networks (*) ASICではなくFlow Router の名前かも？ • マイクロコードの変更によるプログラミング • Caspian (Sable) が実施 • ユーザーによるプログラミングは不可（ASIC仕様非公開） Cavium XPliant • Excel的なツールを利用したパーサープログラミング • （ユーザーもプログラミング可能な場合もあり） • パイプラインのプログラミングは Cavium が実施 Barefoot Tofino • P4言語を用いたプログラミング • ユーザーによるプログラミングは可能（要ライセンス） Broadcom (NPL) • NPL言語を用いたプログラミング（C言語ライク） • ユーザーによるプログラミングは理論的には可能（要ライセンス） • https://github.com/nplang/NPL-Spec/ Cisco Silicon One • P4 Programmable?? • ユーザーによるプログラミングは不可（SDK非公開） 2003 2011 2013 2019 プログラマビリティを活用したのは ネットワークオペレーターではなく ネットワーク機器＆NOSベンダー 22

23. OpenFlow(純粋SDN)の課題(2) SDNを欲しかったのはネットワークオペレーターでは無かった？ サーバーサイドでの “ネットワーク機能のアクセラレーション” サーバーサイドにおけるデータプレーンプログラマビリティ SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜

    海老澤 健太郎 @ebiken 23

24. 課題(2) SDNを欲しかったのはネットワークオペレーターでは無かった？ • プログラミングできるネットワークオペレーターの不在 • 本当に “自由” を欲しがっていたオペレーターはGoogleぐらい？（AT&Tは...） • 頑張ってプログラムした機能は数年待つと標準機能に（INT,

    NSH, SRv6 ...) • 広域ネットワーク・DCのスパインやコアネットワークに細かい制御は不要 • “SDNライト” ができれば十分：ACL＆ミニマムなトラフィックエンジニアリング • GoogleですらSDNライトへ（例：SONiC-DASH） SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 24

25. SDNを本当に必要としていたのは、サーバーサイドのインフラ • 仮想マシンやコンテナによる水平スケーリング • ネットワーク機能がサーバーに移動 • 粒度が高く、変化が早いポリシー（ペットと家畜） SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84

    SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 25

26. CPU周波数の頭打ち => マルチコア・マルチスレッドへの変化 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎

    @ebiken https://github.com/karlrupp/microprocessor-trend-data 周波数の頭打ち コア数の増加 Moore’s Law Amdahl’s Law Dennard Scaling Principles スケールアップから スケールアウトへ 26

27. アプリケーション構成の変化により、ネットワーク機能の場所も変化 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 27

    North-South Traffic 中心 アプライアンスがゲートウェイとして ネットワーク機能を提供 East-West Traffic 中心 サーバーに近い場所での ネットワーク機能提供が必要に Firewall Load Balancer Server Server Server Server Internet Server Server Server Internet micro-service 半導体（CPU）トレンドの変化による、アプリケーション構成の変化

28. OpenVSwitch (OVS/OVN) や NSX の活用 • 仮想基盤（Hypervisor）の一部としての Software Switch •

    各仮想マシン（VM）やアプリケーションに対してファイアウォールポリシーを細かく適 用し、横方向の攻撃（East-Westトラフィック）を防止 • セキュリティゾーンを細かく分割し、特定のサービス間通信のみを許可 • 仮想マシンやコンテナの生成削除と連携したネットワーク設定の自動化 • 新しいVMやアプリケーションを追加する際、自動的にネットワーク設定を適用 • ワークロード移行時にネットワーク設定を自動的に調整 • サーバーをまたがるトラフィックの分離 • トンネリングプロトコル（VXLAN、GRE、Geneve）による、 複数サーバー（ラック）でのマルチテナンシーの実現 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 28

29. ネットワークの高速化による アプリケーションが占めるCPU利用率の低下 • 2015 Google: Profiling a warehouse-scale computer •

    https://dl.acm.org/doi/10.1145/2749469.2750392 • They found that the diversity of workloads would benefit from flexible architectures, and identify a “datacenter tax” in the lower layers of the software stack that comprises nearly 30% of cycles across jobs and that are prime candidates for hardware specialization and acceleration. • 2020 Facebook: Accelerometer: Understanding Acceleration Opportunities for Data Center Overheads at Hyperscale • https://dl.acm.org/doi/10.1145/3373376.3378450 • Another study by Facebook published in 2020 found that microservices spend as few as 18% of CPU cycles executing core application logic. The remaining cycles were spent in common operations not core to the application logic, including I/O processing, logging, and compression. Facebook believed that accelerating standard building blocks can significantly improve data center performance and they built a model to project possible hardware speedup in microservices. SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 29 半導体（CPU）トレンドの変化による、アプリケーション構成の変化

30. サーバーサイドでの “ネットワーク機能のアクセラレーション” が必要に SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎

    @ebiken 30 Multi-core CPU ネットワーク基盤機能 仮想スイッチ、暗号化、ロー ドバランス、監視 アプリケーション① アプリケーション② アプリケーション③ Multi-core CPU アプリケーション① アプリケーション② アプリケーション③ SmartNIC ネットワーク基盤機能 仮想スイッチ、暗号化、ロー ドバランス、監視 アプリケーション④ アプリケーション⑤ アプリケーションのCPU利用率向上 ＆セキュリティの向上（アイソレーション） SmartNIC （IPU, DPU） アクセラレータの利用

31. サーバーサイド・アクセラレーション 実現方式の分類 • ソフトウェア (Software Based) • 主に Kernel Network

    Stack で実行される処理の軽減やバイパス • Linux Kernel と親和性あり • eBPF, XDP, AF_XDP (eXpress Data Path, Address Family XDP) • vDPA (virtio data path acceleration) • （コンテナなどアプリケーション基盤や、オブザーバビリティでの利用が多い） • Linux Kernel と親和性無し • DPDK (VPP, IPDK, OVS-DPDK) • （VPP等、NFVワークロードでの利用が多い） • ハードウェア (Hardware Based) • パケット処理に（CPUより）適した、ドメイン特化型のハードウェアを利用 • ASIC, NPU, FPGA, SoC（Many-coreプロセッサ＋暗号化・圧縮・特定演算用チップ） • NIC型のフォームファクタに搭載され、IPU/DPUとも呼ばれる(SmartNIC) SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 31 注：IPU/DPU/SoC/ASIC/NPU etc. は厳密な定義がなく、ベンダにより呼称が異なる 専用ハードウェア不要だが、 アプリケーションで利用可能 なリソースが制限される パケット処理に適した専用ハード ウェアで処理することにより、 高速化と同時に、アプリケーション のリソースを確保可能

32. DPUの内部構造（例：NVIDIA BlueField Networking Platforms） SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤

    健太郎 @ebiken 32 https://www.nvidia.com/en-us/networking/products/data-processing-unit/

33. Intel Infrastructure Processing Unit (IPU) SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜

    海老澤 健太郎 @ebiken 33 https://www.intel.com/content/www/us/en/products/details/network-io/ipu.html ※ Intel は専用ASICとFPGAどちらも “IPU” と呼称 P4 Programmable

34. AMD Pensando ~ DPU and SmartNIC SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉

    ｜ 海老澤 健太郎 @ebiken 34 Pollara 400 Adapters Salina DPU https://www.amd.com/en/products/accelerators/pensando.html P4 Programmable

35. サーバーサイドにおけるデータプレーンプログラマビリティ • インストール型 • キャッシュ型 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜

    海老澤 健太郎 @ebiken 35

36. SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken Datapath (DPU

    etc.) Flow Table #0 Flow Table #x Flow Table #N Software (CPU) Flow Table #0 Flow Table #x Flow Table #N Flow Table 投入 OpenFlow Agent Packet インストール型 36

37. SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken Datapath (DPU

    etc.) Flow Cache Table #x Software (CPU) Flow Table #0 Flow Table #x Flow Table #N OpenFlow Agent Packet キャッシュ型 （Cache Entry 無） Flow Cache 投入 問い合わせ 37

38. SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken Datapath (DPU

    etc.) Flow Cache Table #x Software (CPU) Flow Table #0 Flow Table #x Flow Table #N OpenFlow Agent Packet キャッシュ型 （Cache Entry 有） 38

39. SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken インストール型 キャッシュ型

    J 同じフローのパケットは遅延が同じ L 各フロー最初のパケットは遅延大 J 性能を予測しやすい。 L Datapath/CPU間のバスボトルネック L キャッシュ溢れ時パフォーマンス劣化 J Flow Entry毎の追加・変更が可能 L Flow Entry追加・変更時にCache Flush が必要 （Multi Table） L 使わないFlow Entryもハードウェア・リ ソースを消費 J 実際に流れたFlowのみハードウェア リソースを消費 • 性能安定性が必要なゲートウェイ型 • 対応可能なフロー数に制限 • コスト効率重視 • 多数のフローにも対応（キャッシュミス による性能劣化は許容） 39

40. まとめ • SDNとはAPIである • “純粋SDN”（フロー単位で制御）はデータプレーンAPIが必要（OpenFlow） • 不自由なデータプレーン（スイッチASIC）という課題 • プログラマブル・データプレーンの誕生 •

    純粋SDNを欲しかったのはネットワークオペレーターでは無かった？ • ネットワークオペレーターはSDNライトで十分 • 純粋SDNを本当に必要としていたのはサーバーサイドのインフラ • サーバーサイドで進む純粋SDNの利用 • OpenVSwitch + SmartNIC (Offload) • DPUプログラミング • データープレーンプログラミングがこの先生きのこる場所 • スイッチASIC → 技術としては標準装備に（但し、SDNを提唱した人の意図とは異なり、オペレーターは利用できない（利用しないから）） • サーバーサイド → 今でもOpenVSwitchは現役。今後も活用が進むと予想。 SDNという名のデータプレーンプログラミングの歴史 ｜ ENOG84 SDN温泉＠月岡温泉 ｜ 海老澤 健太郎 @ebiken 40