"OPEN NETWORKING" に向けた Management / Data Plane の動向

"OPEN NETWORKING" に向けた
Management / Data Plane の動向
海老澤健太郎 | Twitter: @ebiken
ENOG#41 ＠佐渡 | 2016/10/28

“OPEN NETWORKING” とは？
"OPEN NETWORKING" に向けた Management/Data Plane の動向 | ENOG#41 @佐渡 | 2016/10/28 2
オープン＝自由
選択の自由
（disaggregation / decoupling）
機能変更・追加の自由
※ オープン！＝オープンソース（Open Source Software だけに限定されない）
「ユースケースに合わせたネットワーク機能」が
「コモディティハードウェア」で実現可能に

スイッチ基礎知識
スイッチの構成と機能
マネジメント・プレーン
• ユーザーインターフェース
• 設定管理
• モニタリング・ログ機能の提供
パーサー
パケット処理パイプライン
変換・転送
エンジン
OF L2 L3 ACL
マッチ・テーブル（OF/FIB/ACL）
Layer 2/3 エージェント
ルーティング
テーブル（RIB）STP BGP OSPF
User Interface
CLI API
Management Features
SNMP LOG CONFIG
コントロール・プレーン
• ルーティングプロトコルの処理
• RIBの集約
• FIBの更新
データ・プレーン
• パケットヘッダの解析
• パケットの返還・転送

OPEN NETWORKING 前夜
Giantsの取り組み

• データセンター間のトラフィック制御
• 2010 検証開始～ 2012 公開
• 管理システムから集中管理可能な
スイッチが無かったため自作
• 構成
• ASIC (Merchant silicon)
• 10Gbps x 100 ports
• OpenFlow + BGP/ISIS/OSPF (Quagga)
Google : B4 (G-Scale Network)
参考資料：
• Open Network Summit 2012
• http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf
• ONF Case Study Doc: Inter-Datacenter WAN with centralized TE using SDN and OpenFlow
• https://www.opennetworking.org/images/stories/downloads/sdn-resources/customer-case-studies/cs-googlesdn.pdf
• B4: Experience with a Globally-Deployed Software Defined WAN (Paper at ACM SIGCOMM 2013)
• https://people.eecs.berkeley.edu/~sylvia/cs268-2014/papers/b4-sigcomm13.pdf

• ネットワーク機器（ToR Switch）をサーバー（Linux Based）と同様に運用したい。
• 分散管理システムにネットワーク機器を統合
• アプリケーションエンジニアがネットワークをサーバーと同様に扱えるように
Thriftベースの抽象化レイヤをスイッチASIC APIのレイヤに追加
• 構成
• Wedge: ToR Switch ハードウェア設計（OCPで公開）
• FBOSS: ASIC制御＋CLI （OCPで公開）
• Routing Daemon: 内製（非公開）
• Management tools: 内製（非公開）
• Base OS: Open Network Linux (By Big Switch Networks)
Facebook : Wedge + FBOSS
参考資料：
• Open networking advances with Wedge and FBOSS (Facebook Code, 2015/11/20)
• https://code.facebook.com/posts/145488969140934/open-networking-advances-with-wedge-and-fboss/
• Facebook Open Switching System ("FBOSS") and Wedge in the open (Facebook Code, 2015/03/11)
• https://code.facebook.com/posts/843620439027582/facebook-open-switching-system-fboss-and-wedge-in-the-open/
• Introducing “Wedge” and “FBOSS,” the next steps toward a disaggregated network (Facebook Code, 2014/06/19)
• https://code.facebook.com/posts/681382905244727/introducing-wedge-and-fboss-the-next-steps-toward-a-disaggregated-network/

• LinuxベースのNOSで管理システムと統合しや
すくし、自動化を進める
• 2016年３月公開
• 開発・利用は数年前から
• SAI: OCP Contribution Dec 2014
• その他、具体的な内容は未発表？
• Azure運用管理アプリケーションの移動・拡充？
（Aristaで動かしていた）
• より速いイノベーションを求めオープン仕様に
Microsoft: SONiC
参考資料：
• Microsoft showcases “Software for Open Networking in the Cloud (SONiC)”
• https://azure.microsoft.com/ja-jp/blog/microsoft-showcases-software-for-open-networking-in-the-cloud-sonic/
• Ansible on SONiC （スイッチのデプロイメント用）
• https://github.com/Azure/sonic-mgmt/tree/master/ansible

• アプリケーションの（パケット）遅延による問題を解決するため
• マイクロバーストによるバッファあふれを検知
• 必要な情報取得できない＆ベンダーは機能追加してくれないため、自社開発を決断
• その他の自社開発を決断した理由
• バグのタイムリーな修正（LinkedInのプライオリティに応じた）
• 自社で使用しない機能に由来するバグからの脱却
• Linux ベースの自動化ツールの必要性
• e.g. Chef/Puppet/CFEngine
• 時代遅れの監視・ログツールへの依存を軽減
• SNMP ⇒ Kafka (pub/sub messaging for telemetry)
• ライセンスやサポート費用のスケーラビリティ
LinkedIn: Project Falco
参考情報
• Project Falco: Decoupling Switching Hardware and Software
• https://engineering.linkedin.com/blog/2016/02/falco-decoupling-switching-hardware-and-software-pigeon

• 構成管理の自動化
• サーバー（Linux）運用管理ツールの利用
• 詳細情報の取得
• 必要な情報を取りたい
• 情報をスイッチ上でフィルタリングしたい。
• ログ収集サーバーへプッシュ（含むPub/Sub）
• 機能変更・追加
• ユースケースに合わせたカスタマイズ
• Routing Agent への機能追加・カスタマイズ
• トラフィックエンジニアリング（パケット処理ルール
を変更）
• 新しいプロトコルのサポート（実験）
• SFC/NSH, GTP etc.
"OPEN NETWORKING" でやりたい事
パーサー
変換・転送
エンジン
OF L2 L3 ACL
ルーティング
User Interface
CLI API
Management Features
SNMP LOG CONFIG

実現のために必要な変化
• Linux Shell の解放
• 既存サーバー管理ツールの動作
• 自作ツール・エージェントの実行
パーサー
変換・転送
エンジン
OF L2 L3 ACL
ルーティング
User Interface
CLI API
Management Features
SNMP LOG CONFIG
• L2/L3エージェントの変更・置き換え
• 欲しい情報の収集
• 新しいプロトコルへの対応
• 新しいヘッダへの対応
（パーサー＆マッチの変更）
• パケット処理方法の変更（アクション）

“OPEN NETWORKING” への流れ
“OPEN NETWORKING” accessible to non-giants.

• オープンな Linux Shell
• サーバーと同じ環境でプログラム・ツールの利用が可能
• Cumulus Linux (2010)
• ユーザープログラムの実行環境
• メーカーが用意した環境で動作可能
• Arista（最近では Cisco / Juniper なども）
• オープンな dataplane API
• ベアメタル（White Box）で動作するOpenFlowスイッチ
• Pica8, Big Switch Networks
オープンなスイッチの先駆け

• OpenSwitch (ops)
• http://www.openswitch.net/
• Released: 2015 Oct. (10月)
• Initial Contributors:
• Hewlett Packard, Accton, Broadcom
• Intel, Qosmos, VMWare, Arista.
• Under “Linux Foundation”
• Open Network Linux (ONL)
• http://opennetlinux.org/
• Released: 2014 Jan. (1月)
• Initial Contributor:
• Big Switch Networks
• Under “Open Compute Project (OCP)”
オープンな Network OS の登場

スイッチハードウェア
デファクトが登場
オープンな Network OS の登場（背景）
• Open Compute Project (OCP)
• ODM 通じて誰でも購入可能に
• Broadcom: OF-DPA/OpenNSL
• Mellanox: Open Ethernet API
• Cavium XPliant: OpenXPS
• Switch Abstraction Interface (SAI)
• Broadcom, Mellanox, Cavium XPliant
• OCP submitted de-facto standard
ASIC SDK/API の
オープン化・標準化

Switch Abstraction Interface (SAI)
Broadcom Mellanox Cavium
OF-DPA
OpenNSL
Open
Ethernet
API
OpenXPS SDK/API
ASIC Broadcom Mellanox Cavium
Switch Abstraction Interface (SAI)
Data Plane Abstraction
Broadcom Mellanox Cavium
Layer 2/3 Agents
(OSPF, BGP, STP, LLDP ...)
Data Plane Abstraction
SAI
Layer 2/3 Agents
(OSPF, BGP, STP, LLDP ...)
Plug-in
ASIC SDK/API のオープン化 ASIC SDK/API の標準化

Network OS components
Boot Loader
(Utilizing ONIE)
Bear Metal Switch (White Box / OCP based)
Merchant ASIC
(Cavium, Broadcom,
Mellanox, Intel)
Other Hardware
Management
Linux Kernel
Data Plane abstraction
(Per ASIC SDK)
CPU
DRAM
Network I/F
(Ethernet ports)
Fan, LED, Sensor
L2/L3
Protocol
Daemons
User Interface
(CLI / GUI / API)
OpenFlow
Agent
Common L2/L3/OF APIs
Stats / Status
(SNMP, Syslog)
CPU Board Packet Processing Board
OpenSwitch (ops)
NOSすべての部分
（Linux Kernel以外）
Open Network Linux
プロトコルエージェントや
ASIC管理を除いた部分
そのまま使える
Linux ベースのオープンNOS
プロトコルやASIC管理部分を
自作できるプラットフォーム

Open Switch (ops)
Open Network OS | Overview as of 2016/07/04 17
Open Switch (ops) Architecture
• Central System state database (including configuration)
• Based on “OVSDB-Server”
• “ops-switchd” to abstract datapath and manage ASIC.
• Based on “Open vSwitch (OVS)”
• OpenFlow functionality is not yet supported.
• Hardware support daemons
• Managing I2C peripherals using Config-YAML library.
• L2/L3 Protocol Daemons
• System Daemons
• Management / Monitoring Daemons
Reference: http://www.openswitch.net/documents/user/architecture

Open Network Linux (ONL)
Open Network OS | Overview as of 2016/07/04 18
Open Network Linux (ONL) Architecture
ONL architecture is well described in below slides
presented at “Okinawa Open Days 2014” by Rob Sherwood, Big Switch Networks CTO.
http://www.e-side.co.jp/okinawaopendays/2014/document/12_Rob-Sherwood.pdf

Open Network Linux as NOS Platform
Boot Loader
(Utilizing ONIE)
Merchant ASIC
(Cavium, Broadcom,
Mellanox, Intel)
Other Hardware
Management
Linux Kernel
Data Plane abstraction
(Per ASIC SDK)
CPU
DRAM
Network I/F
(Ethernet ports)
Fan, LED, Sensor
L2/L3
Protocol
Daemons
User Interface
(CLI / GUI / API)
OpenFlow
Agent
Common L2/L3/OF APIs
Stats / Status
(SNMP, Syslog)
CPU Board Packet Processing Board
Microsoft
+ SONiC
Facebook
+ FBOSS / Protocol Agents
SnapRoute
+ FlexSwitch
Bear Metal Switch (White Box / OCP based)

SnapRoute / FlexSwitch Architecture
SnapRoute / FlexSwitch
• Go + Pythonで記述
• 疎結合なアーキテクチャ
• カスタマイズ可能な機能パーツ
• サーバーツールの活用
• ペリフェラル管理はONLを利用

• Linux Shell の解放
• 既存サーバー管理ツールの動作
• 自作ツール・エージェントの実行
パーサー
変換・転送
エンジン
OF L2 L3 ACL
ルーティング
User Interface
CLI API
Management Features
SNMP LOG CONFIG
• L2/L3エージェントの変更・置き換え
• 欲しい情報の収集
• 新しいプロトコルへの対応
オープンなNOS の登場により、環境が整いつつある

パーサー
変換・転送
エンジン
OF L2 L3 ACL
ルーティング
User Interface
CLI API
Management Features
SNMP LOG CONFIG
• 新しいヘッダへの対応
（パーサー＆マッチの変更）
• パケット処理方法の変更（アクション）
データプレーンをカスタマイズ可能なASIC
データープレーン定義言語・仕様の登場

データ・プレーンのプログラマビリティ
Cavium XPliant
• 2016年9月リリース
• プログラマブル ASIC (non-NPU)
• プロファイル（＝レジスタ設定）切り
替えで起動時に動作変更可能
• パーサー（パケットヘッダ）
• ルックアップ・テーブル
• パケット処理ロジック
• パイプライン（マッチ・アクション）
• パケットヘッダ変更
• 3.2Tbps IO Throughput
• 100Gbps x 32 ports
diagram from: http://cavium.com/XPliant-Ethernet-Switch-Product-Family.html

Parser
Ingress
ACL
Multicast
&
Bridge(L2)
MPLS
Q-in-Q
(802.1q)
IP Unicast
(LPM)
Egress
ACL
Tx
Parser
OpenFlow
Table#0
OpenFlow
Table#1
OpenFlow
Table#2
OpenFlow
Table#3
Multicast
&
Bridge(L2)
IP Unicast
(LPM)
Tx
Carrier Routing & Switching Profile
OpenFlow + L2/L3 Hybrid Profile
パイプライン・プロファイル変更の例

• 実質的なスケーラビリティの向上
• 少数のコモディティなハードウェアで、様々なユースケースに対応
• コストだけでなく、スケールしなくて適用できなかった分野での利用可能性
• ハードウェアリソース、特にテーブル用（TCM、SRAM）は有限
• TCAMの有効利用
• 例：4Mbit TCAMに読み込み可能なエントリ数
• 40k : IPv4 5 Tuple [IP Src/Dst Addr, proto, Src/Dst Port] (64 + 8 + 32 = 104)
• 13k : IPv6 Src/Dst Addr + 5 Tuple (256 + 8 + 32 = 296)
• 11k : IPv4/v6 5 Tuple [IPv4/v6 Src/Dst Addr, proto, Src/Dst Port] (256 + 64 + 8 + 32 = 360)
• 200k : MPLS Label (20)
• TCAM -> SRAMへのテーブルの移動
• “TCAM : masked match” => ～数10Kルール
• “SRAM : Exact Match” =>数100K～ルール
パイプライン・マッチテーブル変更の意義

• P4: Programming Protocol-Independent Packet Processors
• パケット処理を定義する言語（オープンソース）
• パーサーの定義
• 処理ルールの定義（マッチ＋アクション転送モデル）
• APIの自動生成
• 動作環境：
• ASIC, FPGA, Network Processor (NPU), Software Dataplane (CPU)
P4 ... データ・プレーン定義言語

P4 データ・プレーン（モデル）
Diagram from: http://p4.org/wp-content/uploads/2015/03/p4-tutorial-12201423.pdf

P4: Programming Protocol-Independent Packet Processors
実行可能なアクション（例）
• フィールド値の変更（パケットヘッダ/メタデータ）
• ヘッダの追加・削除
• カウンター、メーター
パーサー（パケット・ヘッダ）マッチ＋アクションテーブル

P4: Programming Protocol-Independent Packet Processors
コントロールフローの定義

P4 サポート状況
• Barefoot
• P4論文著者（Nick McKeown）が
Co-Founder
• 6.5Tbps ASIC （2017年リリース予
定）
• Xilinx
• NetFPGA (NIC型)
• Netronome
• Smart NIC 上で P4で定義された
データプレーンが動作
• 既にSDKなどリリース済み。テスト
可能。（要NDA）
• Software Data Plane
• Linux Behavioral Model
• OVS (OpenVSwitch) + P4

"OPEN NETWORKING" の状況（まとめ）
"OPEN NETWORKING" の環境が整いつつある
自由に機能追加・変更可能なNOS（プラットフォーム）
入れ替え可能なプロトコル・エージェント
プログラミング可能なASIC （Cavium）・データプレーン定義言語の登場（P4）
完成した製品が突然リリース（発売）される事はない。
試して「何にどう使うか」フィードバックしながら前へ
コミュニティに参加（日本は少ないけど）
多くの人が使えるようになるほど
今は誰も想像してない使い方が生まれるはず

最近自分が取り組んでる事

Modular
Routing
Agents
"OPEN NETWORKING" に向けた Management/Data Plane の動向 | ENOG#41 @佐渡 | 2016/10/28
REST API
(WebAPI)
User
Apps
Linux shell
(CLI as an
Application)
Config Broker
(data store)
Modular
Routing
Agents
FEA (Forwarding Engine Abstraction)
Data Path
Profile
Manager
Flexible Data Plane
User
Apps
Management Plane
Data Plane
External Apps
Mngment System Operator
Flex ASIC
(XPliant etc.)
PontOS Concept & Architecture
Application
Friendly API
33
Linux Kernel
Network Stack
P4 (SmartNIC,
NPU, FPGA)
Native
Applications
Native
Applications
Native
Applications
SDK
(Language API)
Flexible
Data plane
Profile based selection of
Packet Processing Logic
Building Blocks made of Open Source,
and not a black box
Application friendly environment
to enable Network Programmability

Slides by 石黒邦宏（Hash-set） at ONIC Japan 2016
"Zebra 2.0 – SDN, NFV, Container時代の
Networking Softwareの設計と実装"
http://onic.jp/program-detail/#f07

Open NOS, Baremetal/WhiteBox Switch や P4 など、
興味あるかたお声掛けください。
技術調査、実験など一緒にやりましょう。
Twitter: @ebiken | email: ebiken.g [at] gmail.com

"OPEN NETWORKING" に向けた Management / Data Plane の動向

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to "OPEN NETWORKING" に向けた Management / Data Plane の動向 (20)

More from Kentaro Ebisawa (20)

"OPEN NETWORKING" に向けた Management / Data Plane の動向