mpls-japan-2017-shtsuchi

Transcription

1 データプレーンのオープン化 Shishio Tsuchiya 1

2 Agenda これまでのデータプレーン NVO3 Encapsulation Consideration これからのデータプレーン 2

3 Traditional data center vs Cloud data center Source: Credit Suisse IT Survey, Jan 15 3

4 2011 年ごろのデータセンターネットワーク -MPLS Japan2011 パネル クラウド環境におけるネットワークの課題と展望 なども参考に - Ring Protocol STP フラットなレイヤー 2 のネットワークデザイン データセンター内ではスパニングツリーが使用 ベンダー独自のリングプロトコル ( または G.8032) がデータセンター間で使用される VM ライブマイグレーションは必要 (GARP によって移動を通知 ) VLAN がユーザ毎にアサインされる 4

5 問題点 データセンター間 / データセンター内 - VLAN スケーラビリティ > 4K - MAC アドレステーブルのスケーラビリティ - VM ライブマイグレーションや簡単に使うためのブロードキャストドメインの拡張 - East / West トラフィック帯域の増加 - 高速収束 - 自動化 / オーケストレーション データセンター間 - 要求に応じた帯域増強 - ベンダーロックイン技術からの解放 - 柔軟性のあるトポロジーデザイン - トラフィックエンジニアリング - BUM(Broadcast/Unknown unicast/multicast) トラフィックの最適化 ゲートウェイ - ARP/NDP スケーラビリティ - IETF ARMD(Address Resolution for Massive numbers of hosts in the Data center) Group は一つの informational RFC を発行 RFC6820 Address Resolution Problems in Large Data Center Networks 5

6 大規模データセンタールーティングでの BGP の使用 Spine Leaf Layer3 Layer スケールアウトする Clos デザイン 安定した標準的な BGP プロトコルを ToR/Leaf スイッチに使用 安定性にフォーカスし VM モビリティはラック内に留める 6

7 IP Clos デザインの利点 / ,64517* 65001,64517* 65002,64517* 65003,64517* /24 ECMP で全ての Leaf-Spine リンクを使用する それぞれのフローは ECMP ハッシュにてバランスされる ( 既に実装されている ) ルーティングパスは BGP パス属性により可視化される 7

8 問題に関するソリューション 技術 VXLAN NVGRE STT OTV Intend to on 1 st draft 結果 Experimental 2011 年 8 月 RFC7348 (Information) Informational 2011 年 9 月 RFC7637 (Information) Informational 2012 年 2 月 expire Standard 2010 年 4 月 expire 特許 NA Microsoft Nicira Cisco 実装 Linux 3.7 OVS Hyper-V DPDK Broadcom Trident2 Hyper-V DPDK Broadcom Trident2 OVS Hyper-V Cisco NX トランスポート UDP GRE TCP Like UDP ロードバランス 中間ノードの実装による Key Fieldまで計算 8

9 Virtual extensible LAN (VXLAN) フレームフォーマット フラグ (8 bits): - 有効な VXLAN のネットワーク ID の場合 I フラグは 1 をセットしなければならない 他の 7 ビット (R) は予約フィールドで送信時に 0 をセットしなければならず 受信時に無視される VXLAN セグメント ID/VXLAN ネットワーク識別子 (VNI): - これは 通信する VM が配置されている個々の VXLAN オーバーレイネットワークを指定するために使用される 24 ビットの値です 異なる VXLAN オーバーレイネットワーク内の VM は互いに通信できません 宛先ポート : - IANA は VXLAN のポートとして 4789 をアサインした このポートをデフォルトの宛先ポートとして使う 送信元ポート : - UDP ソースポート番号は ロードバランスの際のハッシュの計算に使用される 動的にプライベートポート範囲 である事が推奨される Outer UDP Header: Source Port Dest Port = 4789 UDP Length UDP Checksum VXLAN Header: R R R R I R R R Reserved VXLAN Network Identifier (VNI) Reserved 9

10 まとめ 事実として - VXLAN は RFC7348 で Informational で発行 - Linux/OVS/Hyper-V/DPDK/ASIC と多くの実装が存在 - ECMP ロードバランスやイーサチャネルでの実装も考慮 (IP/UDP: 送信元ポートのランダム化 ) - IPR( 知的財産権 : Intellectual Property Right) は特に無かった - VXLAN は実質的な業界標準のプロトコルとは言えるが IETF 標準では無い 10

11 Agenda これまでのデータプレーン NVO3 Encapsulation Consideration これからのデータプレーン 11

12 IETF NVO3(Network Virtualization Overlays) WG NVO3 WG はデータセンター内の仮想化を可能にする IP ベースのアンダーレイを基本としたプロトコル拡張を前提 NVO3 は仮想ネットワークにマルチテナントとワークロードの可動性にレイヤー 2 およびレイヤー 3 のサービスを提供 12

13 Geneve: Generic Network Virtualization Encapsulation Ver: - 0, 知らないバージョンの際は破棄 Opt Len: - オプションフィールドの長さ,Geneve の最小サイズは 8 バイト / 最大サイズは 260 バイト O ビット : - OAM ビット パケットはデータペイロードの代わりにコントロールパケットを含む C ビット : - Critical Option, このビットが設定されている時にはエンドポイントは解析をしなければならない Protocol Type: - 続くプロトコルのイーサタイプを定義 Outer UDP Header: Source Port = xxxx Dest Port = 6081 UDP Length UDP Checksum Geneve Header: Ver Opt Len O C Rsvd. Protocol Type Virtual Network Identifier (VNI) Reserved Variable Length Options 13

14 Generic UDP Encapsulation V ビット : - 0:Version 番号 C ビット : - コントロールメッセージの際にセット 無い場合はデータメッセージ Hlen: - GUE ヘッダーの長さ オプション拡張ヘッダーを含むが最初の 4 バイトヘッダーは含まない (header_len - 4) / 4 で計算され 全ての GUE ヘッダーは 4 の倍数となる 最大ヘッダー長は 128 バイト Proto/ctype: - C ビットが含まれてる場合には制御メッセージのタイプが表示される C ビットが含まれていない場合は encapsulate されたプロトコル番号が入る UDP Source port Destination port(6080) Length Checksum / V C Hlen Proto/ctype Flags ~ Extensions Fields (optional) ~ ~ Private data (optional) ~ 14

15 Ver: Generic Protocol Extension for VXLAN - 0:VXLAN GPE バージョン Instance ビット (I ビット ): - VNI が正常の時にセットする Next Protocol Bit(P ビット ): - Next Protocol フィールドが存在する時セット BUM Traffic Bit (B ビット ) - BUM(Broadcast/Unknown Unicast/Multicast) の際にセット OAM Flag Bit (O ビット ) : - OAM パケットの時にセット Next Protocol: - 続くプロトコルヘッダを提示 Outer UDP Header: Source Port Dest Port = 4790 UDP Length UDP Checksum VXLAN GPE Header: R R Ver I P B O Reserved Next Protocol VXLAN Network Identifier (VNI) Reserved 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4 : Network Service Header 0x5 : Multiprotocol Label Switching 15

16 NVO3 スタンダード Encapsulation で話されてる事 イーサネットヘッダー 外部 IP ヘッダー NVO3 ヘッダー オリジナルパケット 管理性 - ICMP/ECMP など既存の仕組みを実装可能か? 拡張性 - 将来的な拡張 :Telemetry/Security/GBP( セキュリティ /QoS) に適用可能か? イーサネットヘッダー 外部 IP ヘッダー NVO3 ヘッダー 拡張ヘッダー 拡張ヘッダー オリジナルパケット 16

17 NVO3 Encapsulation Considerations 技術 Geneve GUE VXLAN-GPE トランスポート IP/UDP IP/UDP IP/UDP 基本ヘッダー長 8バイト 4バイト 8バイト (NSHとの組み合わせで16バイト 拡張性 可変長オプション 拡張フィールド 単独では拡張性がない NSHと組み合わせる必要がある 最大ヘッダー長 260バイト 128バイト 8バイト (264 バイト NSH) Next Protocol 識別子 Ether type Protocol ID New Registry NVO3 はデザインチームを構成し 提案中の encapsulation を比較検討した 現状のプロトコルにはハードウェアの実装や VXLAN との下位互換に問題 デザインチームでは Geneve がもっとも NVO3 の最初の標準化プロコトルにふさわしいと推薦した 17

18 まとめ IETF NVO3 WG ではスタンダードな encapsulation 方式を検討 Geneve/GUE/VXLAN-GPE の 3 つの候補があり 何れもハードウェア対応や VXLAN との下位互換には問題があるが Geneve を最初の標準プロトコルを目標にすると合意した 18

19 Agenda これまでのデータプレーン NVO3 Encapsulation Consideration これからのデータプレーン 19

20 NVO3 プロトコル ハードウェアで大変なところ イーサネットヘッダー 外部 IP ヘッダー NVO3 ヘッダー 拡張ヘッダー 拡張ヘッダー オリジナルパケット 技術 Geneve GUE VXLAN-GPE 筆者 IPR Intel vmware vmware (Royalty-Free) Facebook Huawei Microsoft cisco Cisco Intel 最大ヘッダー長 260バイト 128バイト 8バイト (264 バイト NSH) Next Protocol 識別子 N/A Ether type Protocol ID New Registry 固定長のヘッダーと違い 可変長 ものによっては並列に処理をしなければいけない どれがメインになるのかが分からない 20

21 ソフトウェアインプリメンテーション NVO3 イーサネットヘッダー 外部 IP ヘッダー NVO3 ヘッダー 拡張ヘッダー 拡張ヘッダー オリジナルパケット SRv6 イーサネットヘッダー IPv6 SRH SRL1 SRL2 オリジナルパケット この 3 つだけで十分か? SRv6 とかもやりたいの? 技術 Geneve GUE VXLAN-GPE 筆者 Intel vmware 実装状況 3.18 OVS DPDK Hyper-V Facebook Huawei Microsoft Cisco Intel OVS DPDK 21

22 Cavium XPliant Packet Architecture VXLAN RFC T2, TH etc 約 24 ヶ月のギャップ New Protocol XP / 各ヘッダー毎に並列処理を実施 フィールドアップグレード可能なチップセット XPA をプログラム可能にする API のオープン化 OpenXPS 2017 ソフトウェアアップグレードによる迅速なサポート 22

23 Broadcom BCM56870 SERIES High-Capacity StrataXGS Trident 3 Ethernet Switch Series Triden3 は既存の Trident2/Triden2+ の機能と互換性を持ちつつ フィールドアップグレード可能なシリコン GENEVE, NSH, VXLAN, GPE, MPLS, MPLS over GRE/UDP, GUE, ILA,PPPoE など新しいプロトコルもサポート XGS ファミリーは OpenNSL(Open Network Switch Library) も提供 23

24 P4+Barefoot Capilano/Tofino P4:Programming Protocol-Independent Packet Processors ターゲット非依存 :CPU/FPGA/SOC/NPU/ASIC プロトコル非依存 : ヘッダー情報などを直接記載する 再構成可能 : ターゲットが変わってもそのまま使用出来る様にする Tofino はスイッチング ASICS / Capilano SDE(Software Development Environment) と使用する事で P4 記載のコードを利用可能 24

25 Arista EOS Vision and P4 Vision NOS P4.org Fulcrum -FM BRCM- DNX BRCM- XGS CAVIUM -XPA A B Cisco UADP 2.0 Barefoot Tofino Arista EOS は既に 4 種類のシリコンファミリーで単一バイナリーでサポート また SDK や Open API を提供する事で多くのプログラム性を提供 P4 はターゲット非依存なネットワークプログラム言語を提供する事でサポート SDK 内での柔軟性を提供 25

26 まとめ ヘッダーチェーニングなどの今後の拡張性を踏まえて 各シリコンベンダーはプログラマブルパイプラインおよびフィールドアップグレード可能なチップをリリース P4 では更にプロトコル非依存 / ターゲット非依存のプログラム言語を定義する事で多くのユースケースで使用が可能か!? 26

27 Thank You Copyright Arista All rights reserved.