1. Cloud Days Tokyo 2014 Spring
P-20C SDN/OpenFlow
80分でばっちり理解するOpenFlow
2014年3月7日
NEC 宮永 直樹
（提供：ONF）

2. 自己紹介
▌ 宮永 直樹
 データセンター系ソリューションの拡販、コンサルに従事
 ProgrammableFlowというOpenFlow対応製品の拡販
 オーム社より「マスタリングTCP/IP OpenFlow編」を出版
あきみち、宮永直樹、岩田淳
Page 2
© NEC Corporation 2013

3. アジェンダ
▌
▌
▌
▌
▌
OpenFlowの標準化動向
OpenFlowの基本動作
OpenFlowの基礎的なメッセージ
OpenFlow1.0でラーニングブリッジに挑戦！
OpenFlowの２つのユースケース
•ECMP
•セキュリティアプライアンスへのリダイレクト
▌ ネットワークの仮想化
▌ OpenFlow 1.0以降に追加された仕様
▌ OpenFlow対応製品の適用状況
▌ OpenFlowとSDN
Page 3
© NEC Corporation 2013

4. ＯｐｅｎＦｌｏｗの歴史と研究開発＆標準化動向
▌ 2007年:スタンフォード大学 “Clean Slate Program”が始まる
▌ 2009年 : スタンフォード大学 “Clean Slate Laboratory” 設立
 OpenFlowコンソーシアムにて
OpenFlowプロトコルの研究開発＆標準化
▌ 2011年３月: Open Networking Foundation 設立
 OpenFlow/SDNの標準化、プロモーション
▌ 2012年5月: Open Networking Research Center (ONRC) 設立
 OpenFlow/SDN関連次世代技術の研究開発
▌ 2013年４月: OpenDaylight 発足
 OpenFlow/SDNのオープンソース開発
Page 4
© NEC Corporation 2013

5. OpenFlowの標準化動向（ONF）
▌ONFの構成
2011年3月に設立、１２４社が加盟(2014年1月時点)
OpenFlowの標準スペックを策定（現在のスペックは1.4)
議論は基本的に非公開、グループ会社で１票の投票権
・Board：
Google, Facebook, DT, Verizon, Microsoft,
NTT Communications, Yahoo, GoldmanSachs,
Stanford, UC Berkeley, D.Pitt(Executive Director)
・TSG：
Broadcomm, NTT Communications, Microsoft,
BigSwitch, Google, HP, Cisco, GoldmanSachs,
Stanford
・Council：WG議長とE.D.で構成
・WG構成（WG議長）：
Extensibility WG (HP)
Configuration & Management WG (Microsoft)
Testing & Interoperability WG (IXIA)
Hybrid WG (CISCO)
Market Education WG (Ciena)
Architecture & Framework WG (Big Switch)
Forwarding Abstractions WG (Brocade)
Page 5
© NEC Corporation 2013

6. OpenDaylight Project
▌ 主要ネットワーク関連ベンダ18社により発足されたLinux Foundationの
SDNのオープンソースプロジェクト（2013年4月8日）
▌ 参加企業が自社の持つSDN関連コードをプロジェクトに寄贈し、
SDNフレームワークの構築を進める
▌ 最初のコードは、2014年２月リリース開始
出典：http://www.opendaylight.org/project/technical-overview
Page 6
© NEC Corporation 2013

7. Network Function Virtualization （NFV）
▌2012年10月ドイツで開催されたSDN and OpenFlow World Congressにおいて
世界の大手１３のキャリアがNetwork Function Virtualization （NFV）関する
ホワイトペーパーを発表
（AT&T, BT, CenturyLink, China Mobile, Colt, Deutsche Telekom, KDDI, NTT, Orange, Telecom Italia, Telefonica, Telstra, Verizon）
▌目的は、現状「専用装置」で構成されている固定／モバイルＮＷを「汎用サーバー
上の仮想アプライアンス」で構成することにより、コモディティ化すること
他、ベンダロックインの回避、コストの削減、標準化によるサービス追加・変更の
容易化など
▌ＥＴＳＩの下部組織として
NFV を検討する Industry
Specification Group （ISG）
を立ち上げ
※メンバーはONFに近いメンバー
出典：
http://portal.etsi.org/NFV/NFV_White_Paper.pdf
Page 7
© NEC Corporation 2013

8. キャリアインフラネットワークのＮＦＶ
▌ 汎用サーバ上にVMとして実装。ハードウェア（サーバ／ストレージ／ＮＷ）共通化
▌ 仮想アプライアンスの活用
▌ サービスチェーニング FW→LB→IPS→VM
Page 8
© NEC Corporation 2013

9. OpenFlowの基本動作
OpenFlowは
スイッチネットワークを作るための
標準化されたプロトコル
Page 9
© NEC Corporation 2013

10. フローテーブル
▌ １．０のフローテーブル
 ヘッダフィールド、カウンタ、アクションの３つ構成されるフロー
エントリを持つ
 パケットの１２個のフィールドを指定可能
 ヘッダフィールドでマッチするか条件を書き、転送やフィールド
の書き換えのアクションを行う
 複数の端末を同じIPアドレスにして、MACアドレスを書き換え
ながら転送するなんて荒業も
Ingress Dst
Port
MAC
Page 10
Src Ether
MAC Type
© NEC Corporation 2013
VLAN VLAN Dst Src IP
IP
id Priority IP IP Proto ToS
TCP/UDP TCP/UDP
Src Port Dst Port
Data

11. フローテーブルを扱う２つの方式
▌ リアクティブ方式
 スイッチのフローエントリをもとにスイッチング
 未知のパケットはコントローラに問い合わせる
 一般に、商用のHop-by-Hop方式の製品はこのタイプ
Page 11
© NEC Corporation 2013

12. フローテーブルを扱う２つの方式
▌ プロアクティブ方式
 事前に端末情報からフローを設定しておく方式
 タップソリューションやオーバーレイ方式のようなところで利用
Page 12
© NEC Corporation 2013

13. コントロールプレーン
▌ コントローラとスイッチ間を結ぶネットワーク
 データプレーンと別に構築
 一般にレガシーで構成（コントローラも含めて二重化）
 データプレーンの制御の自由度をあげる（障害時の切り替わりなど）
 インバンドで構成する標準化も
 OF-CONFIGではプラグアンドプレイの話題
Page 13
© NEC Corporation 2013

14. データプレーン
▌ ユーザの利用する通信用ネットワーク
 Hop-by-Hop方式
 オーバーレイ方式
 ハイブリッド方式
 LANをHop-by-Hop方式
 WANをオーバーレイ方式
Page 14
© NEC Corporation 2013

15. OpenFlowの基礎的なメッセージ
リピーターハブをモデルに
OpenFlowのコントローラとスイッチの
関係を見てみよう
Page 15
© NEC Corporation 2013

16. 基礎的なメッセージ
▌ 初期
▌ ハンドシェイク
▌ Echo
 TCP6633
 Feature要求・応答  Echo要求/応答
 SecureChannel  サポートされている  スイッチ・コントローラ
 TLS
機能の確認
両方から
 コネクション確立
 KeepAlive的に利用
 Helloメッセージ
 バージョンのネゴ
Page 16
© NEC Corporation 2013

17. 基礎的なメッセージ
▌ Flow-Mod
 スイッチのフローテーブルにフローエントリを書き込む
Page 17
© NEC Corporation 2013

18. 基礎的なメッセージ
▌ Packet-In
 （未知の）パケットをコントローラに送る
Page 18
© NEC Corporation 2013

19. 基礎的なメッセージ
▌ Packet-Out
 コントローラからパケットをスイッチに送り、送信させる
 スイッチのポートを指定、ブロードキャストなども可。
 Packet-Inしたパケットはこの処理が必要
Page 19
© NEC Corporation 2013

20. 基礎的なメッセージ
▌ Barrierメッセージ
 スイッチがどこまで処理が終わっているかを確認するメッセージ
 とっても重要
Page 20
© NEC Corporation 2013

21. OpenFlow1.0でラーニングブリッジに挑戦！
OpenFlowを使ってネットワークを作る
＝コントローラを開発する
Page 21
© NEC Corporation 2013

22. OpenFlow１．０でラーニングブリッジに挑戦！
▌ パケットを受信
 Packet-In
Page 22
© NEC Corporation 2013

23. OpenFlow１．０でラーニングブリッジに挑戦！
▌ パケットを送信
 Packet-Out
 宛先PCがわからないので、フラッディングする
Page 23
© NEC Corporation 2013

24. OpenFlow１．０でラーニングブリッジに挑戦！
▌ 送信元のPC Aを学習
 PC AのフローエントリをFlow_modでフローテーブルに登録
Page 24
© NEC Corporation 2013

25. OpenFlow１．０でラーニングブリッジに挑戦！
▌ 返信パケットを受信
 PC Aは学習済みなので、転送
 コントローラには転送していない
→PC Bを学習していない！
普通の“ラーニングブリッジ”は
OpenFlow 1.0で、できない！
Page 25
© NEC Corporation 2013

26. OpenFlow１．０でラーニングブリッジに挑戦！
▌ １．０の限界
 宛先MACを学習する通常のラーニングブリッジは、１つのフロー
テーブルでは実現できない
▌ ワークアラウンド
 送信元MAC・宛先MACの組み合わせを、１つのフローとする。
ノード数が多いと組み合わせでフロー数が大きくなる
（現在市場にでているOpenFlow製品はこのタイプがベース）
 ARPを常にPacket-Inするよう、フローエントリを登録しておく。
コントローラで、ARPによるノード情報のアップデート処理を作る
IPはいいけど。。。
Page 26
© NEC Corporation 2013

27. OpenFlowの２つのユースケース
ECMP（イーコルコストマルチパス）
セキュリティアプライアンスへのリダイレクト
Page 27
© NEC Corporation 2013

28. ユースケース ECMP
▌ ECMP（イコールコストマルチパス）
 一般にL3のルーティングでコストが同じケースをいう
 コントローラで“L2ルーティング“を計算
 コストが同じ場合に複数経路を使用
 送信元アドレスやポート番号でフローごとに分ける
Page 28
© NEC Corporation 2013

29. ユースケース セキュリティアプライアンスへのリダイレクト
▌ DDoS対策製品へのリダイレクト
 Interop Tokyoで実施されたデモ
 DDoS時に関連するトラフィックをDDoS対策製品に「曲げる」
Page 29
© NEC Corporation 2013

30. ネットワーク仮想化
Page 30
© NEC Corporation 2013

31. なぜ今ネットワークの仮想化が話題になるのか？（おさらい）
▌ 事業者・企業においてサーバ仮想化が普及
→ ネットワークの対応が必要に
 VMマイグレーションのために、同じセグメントを複数のサーバに
接続しなくてはならない。
 同じセグメントを接続するために、スイッチも設定する必要がある。
 VLANが増えてくると、一つ一つのスイッチに設定するのが大変。
論理ネットワーク
物理ネットワーク
サーバ１
サーバ２
ルータ
VLAN ID:100
VLAN ID:
100,101
マイグレーション
VLAN ID:
100,101
VLAN ID:101
複数の物理サーバ間で、VMを
マイグレーションさせるために
VLANを延長
Page 31
© NEC Corporation 2013
スイッチ１
スイッチ２
サーバ追加時やセグメント追加時に
都度VLANを設定するのが面倒

32. ネットワーク仮想化の２つの方式 ①スイッチの集中管理
▌ VLANの設定を集中管理して、簡単に
 複数のスイッチを１台の大きなスイッチのようにする
 どこにつないでもOK！→どこにマイグレーションしてもOK
VLAN
100
VLAN
101
VLAN
100
VLAN
101
仮想スイッチ
HyperVisor
仮想スイッチ
HyperVisor
サーバ１
サーバ２
OpenFlow
スイッチ１
、
OpenFlow
スイッチ２
集中管理で各ポートへの
VLANの設定不要。
TAGをみて適切に処理
OpenFlow
コントローラ
 OpenFlowは、ただの「コンフィグの集中管理」ではなく
L2の経路制御を集中管理→VLANの設計・設定から開放
Page 32
© NEC Corporation 2013

33. ネットワーク仮想化の２つの方式 ②エッジオーバーレイ
▌ L2のトンネルによりVLANを延長
 物理スイッチを変更せず、仮想スイッチやロードバランサ
によりサーバ間のセグメントを延長
VLAN
100
VLAN
101
VLAN
100
VLAN
101
仮想スイッチ
HyperVisor
仮想スイッチ
HyperVisor
サーバ１
サーバ２
仮想スイッチ間で
トンネリング
トンネルは一つのIP
通信となるので、物
理的なスイッチは変
更不要
スイッチ１
スイッチ２
 速度が必要な場合にはH/Wでオフロードする必要がある
 大きなL2ネットワークの運用はちょっと大変
Page 33
© NEC Corporation 2013

34. ネットワーク仮想化のイメージ
▌ ネットワーク仮想化
 複数の論理的なグループを物理ネットワーク上に作成
 １つの仮想ネットワークをスライス、VTN（バーチャルテナント
ネットワーク）などと呼ぶ
Page 34
© NEC Corporation 2013

35. OpenFlowによるネットワーク仮想化の実装
▌ FlowVisorという実装
 仮想ネットワークごとにコントローラを複数使うためのもの
 物理的なポート、VLAN、MACアドレスなどを指定して、
仮想ネットワークを構成することが可能
Page 35
© NEC Corporation 2013

36. OpenFlow 1.0以降に追加された仕様
Page 36
© NEC Corporation 2013

37. OpenFlowのバージョン
▌ 2009年12月 OpenFlow 1.0
▌ 2011年2月 OpenFlow 1.1
▌ 2011年12月 OpenFlow 1.2
▌ 2012年6月
OpenFlow 1.3
2012年9月
OpenFlow 1.3.1
2013年4月
OpenFlow 1.3.2
▌ 2013年8月
OpenFlow 1.4

38. パイプライン処理
OpenFlow 1.1
▌ ひとつのパケットに対して複数のフローエントリがマッチさ
れるようになった
▌ OpenFlow 1.0でもフローテーブルを複数持つことは可能
だった
ただし、OpenFlow 1.0では、マッチするフローエントリは
ひとつだけ
▌ OpenFlow 1.1では、Gotoインストラクションによって、こ
れを実現

39. パイプライン処理でラーニングブリッジ
OpenFlow 1.1

40. その他のOpenFlow１．１の変更点
OpenFlow 1.1
▌ グループテーブルの導入
Fast Failover（チャネル）
Select（ロードバランシング）
▌ IP TTL変更
▌ MPLSとVLANのタグをpush/pop
▌ マッチフィールドの追加
MPLS対応
SCTP対応
▌ その他
パイプライン処理で世界が変わった。
TTLいじれるようになったのは、1.1から

41. OXM（OpenFlow eXtensive Match）
OpenFlow 1.2
▌ OpenFlow 1.2における最大の変化
▌ OpenFlow 1.1までのような固定長マッチフィールド
を廃止
OpenFlow 1.2からTLV構造へ

42. OpenFlow 1.2
宛先イーサネットアドレス
（マスクあり）OXM TLVの例

43. OpenFlow 1.2
宛先イーサネットアドレスとIPv4アドレスのOXM TLV例

44. 基本的なIPv6対応
OpenFlow 1.2
▌ OXMによって実現可能に
逆にいうと、OXMの導入目的のひとつであった
OpenFlow 1.1までのマッチテーブル仕様では、IPv6に対
応しづらかった
▌ IPv6拡張ヘッダは対象外

45. その他のOpenFlow1.2の変更点
OpenFlow 1.2
▌ 複数コントローラの対応
▌ Flow-Modの仕様変更
存在しなければ自動的に追加、という仕様が廃止
▌ 用語の変化
仮想ポート、ロジカルポート、予約ポート
▌ その他
OXM TLVの導入で
いろんなプロトコルやフィールドに対応できるよう
になった。

46. Meterテーブルの追加
OpenFlow 1.3
QOSで利用される

47. そのほかのOpenFlow1.3の変更点
OpenFlow 1.3
▌ PBB（Provider Backbone Bridging）対応
▌ UDPによるOpenFlowチャネル
主にPacket-Inなど
▌ テーブルミスのデフォルト挙動変更
ベンダがついてこれなくなったので、いったん凍結。
2013年夏に相互接続に成功し、標準化再開。

48. OpenFlow 1.4の主な変更点
OpenFlow 1.4
▌ オプティカルデバイス用の機能
▌ TCP/UDPポート番号の変更
▌ 複数のOpenFlowメッセージをひとつの機能としてbundle
できるように
▌ 複数コントローラでの運用時の機能追加
▌ フローテーブルの空き容量に関する機能
▌ 各種エラーメッセージの充実
▌ その他色々
Layer1（物理レイヤ）への適用で
領域拡大

49. OpenFlow対応製品の状況
スイッチは1.0もしくは1.3でリリース済み。
コントローラがちょうど出揃った？！
Page 49
© NEC Corporation 2013

50. 各社OpenFlow参入状況
▌ 各社ともSDN/OpenFlowの市場に向けて続々と参入。クラウド・ネットワークの課題を解決す
るひとつのソリューションとして注目されている。
コントローラ
スイッチ
NEC
NEC
HP
HP
Brocade
IBM
IBM
Extreme
VMware（Nicira）
PICA8
Arista
BigSwitch
DELL
Stratosphere
Cisco
Juniper
NTT-DATA
Juniper（非OpenFlow）
NTT（自社内利用）
▌ その他、ロードバランサベンダや仮想サーバベンダーが、NVGRE、VxLAN等をベースとした
エッジオーバーレイ型のソリューションを実装するような流れもあり。
点線：対応を表明しているが、商用製品として販売開始していない製品
Page 50
© NEC Corporation 2013

51. OpenFlowの相互接続状況（NECの例）
▐ Interop Tokyo 2013 では、NECのOpenFlowコントローラである UNIVERGE
PF6800が、他社のOpenFlowスイッチとの相互接続に参加。
PF6800
Northband
API
A10
Radware
Software-Defined Networking
Arista
Multi-Vendor OpenFlow Network
Centec
Brocade
（トーメン）
DELL IBM
Juniper
PICA8
(NCLC)
▌ NECのOpenFlowスイッチである UNIVERGE PF5240は、他社
OpenFlowコントローラとの相互接続にも参加
IXIA
Page 51
NTTDATA
© NEC Corporation 2012

52. 現時点のOpenFlow製品の適用領域
IaaS基盤およびDCネットワーク、企業ＬＡＮ向けに対し適用可能
DC間やWANは製品でなく、「自作」の実績あり（Googleなど）
Page 52
Copyright (c) NEC Corporation 2012.

53. OpenFlowファブリックのイメージ
OpenFlowファブリック
•ネットワークアプリケーションを最初からバンドルした製品
•ユーザがOpenFlowのプログラムをする必要はない（隠蔽化）
クラウド・オーケストレータなど
API
ネットワークアプリケーション
・リンク検出・トポロジ管理機能
・経路制御機能
・可視化機能
など
（素の）OpenFlowコントローラ
OpenFlowプロトコル
OpenFlowスイッチ
Page 53
Copyright (c) NEC Corporation 2012.
OpenFlow
ファブリック
SDN
ソリュー
ション

54. OpenFlowを使った製品のアーキテクチャ
▌ L3機能もBOX型スイッチでできるのでスケールアウトが可能
 シャーシ型が不要なので、初期費が安い
コアのシャーシ型を搭載するため
ネットワーク専用ラックを準備
増設
L3機能のため、大型のシャーシ型
スイッチが必要
Page 54
OpenFlowならL2/L3機能もBOX型
スイッチで構成可能

55. OpenFlowファブリックとしての強み（NECの例）
▌ ECMP（イコールコストパルチパス）
 経路制御はL2のショーテストパス（最短経路）
 イコールコストの場合最大８経路をフローベースでバランシング
ファイバの３重化、４重化が可能（Fat Tree）
 フローごとの経路指定も可能（利用例：iSCSIのパスを分けるなど）
▌ スケール
 コントローラ１式でスイッチ２００台、VTN１０００個
 UNCを使用するとコントローラ１０式、スイッチ２０００台、約９６０００ポート
▌ 切り替え時間
 OpenFlow1.3のグループテーブルにより障害時の大量FLOW_MODを抑制
 EtherOAMにより障害検出時間を短縮
 検証結果：約500mmsec程度で切り替わり
Page 55

56. 仮想ネットワークの実装イメージ（NECの例）
▌システムごとのネットワークを「テナント」として仮想化
サーバ仮想化のGuestOSのようなもの
▌サーバ仮想化のように機器の点数・機器費用を削減
仮想ネットワーク
VTN1
VTN2
物理ネットワーク
PFC
制御
Page 56
Copyright (c) NEC Corporation 2012.

57. 仮想ネットワークのイメージ（NECの例）
▌ 仮想化基盤の運用のための可視化機能
 物理ネットワークに加えて、仮想ネットワークの可視化が可能
 物理ネットワーク上、仮想ネットワーク上でフローが見える！
 GUI上からの設定も簡単！
通信経路表示
仮想ネットワーク
Page 57
Copyright (c) NEC Corporation 2012.
物理ネットワーク

58. 経路制御にみるうれしさ
Shortest Pathの経路制御アルゴリズムを標準搭載
DB化のメリット
経路制御の「オートマ」化によりSTPのような冗長設計が不要
→ポートの“VLANの設定”が不要に
論理NWは変わらない
vBr1
PFC
VTN1
vBr2
（VLAN100）
障害時に
コントローラに通知
障害
障害時には
再計算
（Shortest Path）
VLANの設定が
不要に
Page 58
Copyright (c) NEC Corporation 2012.
（VLAN101）
VTN2

59. 論理層の監視にみるうれしさ
▌ VTN FaultというSNMP Trap
 VTNの論理IF間で物理的な経路がなくなった場合に発生
▌ DB化のメリット
 どのお客様のシステムに影響がでているかを瞬時に把握
 NetConfやSNMPでやろうとすると、ユーザ側でDBを作成し、トポ
ロジもリアルタイムでアップデートするなど、ものすごく大変
論理ネットワーク上届かない
領域ができたことを検知
VTN Fault
VTN1
PFC
障害
障害
Page 59
クラウドのスケールアウト型では
二重障害の想定が必要！
Copyright (c) NEC Corporation 2012.

60. QOSの統合管理にみるうれしさ
▌ VTN単位のQOS
 VTNに所属する全論理IFに設定することが可能（ポリッシング）
 あるお客様が帯域を占有し、他のお客様に迷惑かけることを抑制
 DB化のメリット
 論理のVTN単位で指定するので物理ポート１つ１つに設定不要
（IFごとに帯域の足し算などの管理は必要）
vRouter
VTN
vBridge
vExternal
論理ポートに
ポリッシング設定
不要
Internet
SW１つ１つの
設定不要
Page 60
Copyright (c) NEC Corporation 2012.

61. OpenFlowとSDN
OpenFlowはプロトコル、
SDNはそのソリューション。
もとはONFのメンバーから。
Page 61
© NEC Corporation 2013

62. SDN（Software-Defined Networking）とOpenFlowの言葉の定義
▌ＳＤＮとは、ソフトウェアでネットワーク構成を定義・コントロールする仕組みと考え方
 ONFのボードメンバーから。コントロールプレートデータプレーンの分離。
 従来のＮＷ設計をエンジニアが静的にＮＷ装置に定義するのに対比したもの
 特定のファンクションを規定するモノではない ＝ 概念
▌ＯｐｅｎＦｌｏｗとは、スイッチをコントロールするプロトコルの標準
 ＮＷ領域におけるソフトウェア化・オープン化
アプリケーション
アプリケーション
アプリケーション
サーバ管理ソフト
サーバ管理ソフト
ＮＷ管理ソフト
ＮＷ管理ソフト
SDN
ＳＷ
サーバ管理ソフト
Ｂ
SDN
Ｃ
ＮＷ管理ソフト
SDN
装置/
サーバ＋ソフト
その他
アーキテクチャ
装置
ＨＷ
その他アーキテクチャ
ルータ
スイッチ
レガシー
アーキテクチャ
ＯｐｅｎＦｌｏｗ
コントローラ
Ａ
ＯｐｅｎＦｌｏｗ
スイッチ
ＯｐｅｎＦｌｏｗ
アーキテクチャ
＊ベンダにより（Ａ/Ｂ/Ｃ）の解釈様々
Page 62
© NEC Corporation 2013

63. SDNによるソリューションの例
Interop Tokyo 2013 SDN ShowCaseデモ
IaaSにおけるネットワーク運用自動化のデモンストレーション
～ハイレベルな運用環境を
実現したい企業・事業者様むけ～
～カスタマイズしたい
SI力のある事業者様むけ～
クラウドマネージャ
クラウドマネージャ
Coud Manager
vDC Automation
サービス
利用者
仮想サー
バ
コントロー
ラ
仮想サーバ
コントローラ
ネットワークプール
サーバプール
ネットワークプー
ル
サーバプール
IaaS
管理者
ご協力：A10ネットワークス株式会社様（ロードバランサ）、フォーティネットジャパン株式会社様（ファイアウォール）
Page 63
Copyright (c) NEC Corporation 2012.

64. クラウド利用者による操作イメージ（ＮＥＣの例）
▐ IaaS利用者はWebベースのClound Managerに必要なリソースを入力
▐ このとき、仮想ネットワークもいくつ欲しいかを入力しておき、各VMが
どの仮想ネットワークに接続するかを指定
セルフサービスポータル画面イメージ
※WebSAM Cloud Managerによる画面
仮想マシン申込みフォーム
サービス選択メニュー
IaaS利用者むけ
Page 64
© NEC Corporation 2013

65. ＳＤＮによる自動化のイメージ（ＮＥＣの例）
▌事前にシナリオを設定しておくことで、Firewallやロードバランサも
含めて、仮想ネットワークの生成や設定を自動化
ＷｅｂＳＡＭ
ｖＤＣ Ａｕｔｏｍａｔｉｏｎ
テナント契約時
プログラマブルフロー
仮想ＮＷ作成
仮想マシン作成
VTN作成
ｖRT・ｖBR作成
VLink設定
ファイアウォール
仮想ＦＷ作成
ＦＷ・VLAN接続
ＦＷ設定
ロードバランサ
仮想LB作成
LB・VLAN接続
LB設定
SV作成
サーバ
ＬＢ設定
仮想ＳＶ
ロードバランサ
ファイアウォール
PFC
プログラマブルフロー
VTN
ｖＲＴ
Page 65
© NEC Corporation 2013
仮想ＬＢ
ＦＷ設定
仮想ＦＷ
ｖＢＲ
VLAN設定

66. まとめ
▌ OpenFlowの標準化
 １．０から１．３、１．４で大きく進歩
 非常にプリミティブ（原始的）なプロトコル
 なにに使えるの？→なにかをやろうとしたときに使えるもの
 詳しくは「マスタリングTCP/IP OpenFlow編」をどうぞ
▌ 製品の実装
 マルチベンダでスイッチ、コントローラがでてきてます。
 1.0、1.3の相互接続やってます。
 OpenFlowファブリック、そこそこ完成してきています。
▌ SDN
 課題は大規模な「クラウド」のネットワーク管理
 OpenStackのNW運用動化などのソリューション

67. Page 67
Copyright (c) NEC Corporation 2012-2013. All rights reserved.
© NEC Corporation 2013