MPLS Japan 2012

通信事業者としてのSDN/OpenFlowに対する期待と課題	  	  2012年年10⽉月15⽇日	  NTTコミュニケーションズ株式会社	  佃 　昌宣	  m.tsukuda@ntt.com
Copyright © 2012 NTT Communications

1

Agenda	  • SDN/OpenFlowの概要と期待すること	  • 実際に既存のいろいろな製品を触ってみる	  • WANへ適⽤用する場合を考えてみる	  • まとめ	  SDN/OpenFlowの概要と期待すること	  Copyright © 2012 NTT Communications

3

SDN/OpenFlowとは？	  
• SDN（Software Defined Network）とは？	  
– 明確な定義はない？	  

• ソフトウエアコンポーネントによってネットワークをダイナミックに制御する	  – http://itpro.nikkeibp.co.jp/article/NEWS/20121010/428930/	  • ネットワーク構成を動的に設定するために、ネットワーク全体をソフトウェアで制御（定義）	  する	  – http://cloud.watch.impress.co.jp/docs/interview/20120925_560748.html	  – 特徴：C/D分離離、集中制御、直接的なプログラマビリティ	  • OpenFlowとは？	  

– OpenFlowはSDNを実現する技術の⼀一つ	  – OpenFlowSW、コントローラー、OpenFlowプロトコルの3つで構成される	  – OpenFlowSWはFlowTableに基づいてパケットを転送していく	  Copyright © 2012 NTT Communications（引用）ONS-Tutorial	

4

OpenFlowは何が新しいのか？	  
元々装置の内部にあった２つの機能を分離離した	  • アーキテクチャを変えただけ	  • ネットワーク⽅方式に対し、何か新しい技術をもたらしたわけではない	  App

NMS/Provisioning

App

Srvc

API等	  OpenFlow Controller
CLI、SNMP等	  AppSrvc

App

OpenFlowプロトコル	  Srvc

コントロール	   標準プロトコル	  プレーン	  コントロール	  プレーン	  OF-Agent

OF-Agent

データプレーン	  データプレーン	  データプレーン	  データプレーン	  AppSrvc

コントロール	  プレーン	  OF-Agent

データプレーン	  データプレーン	  現在の⼀一般的な構成	  Copyright © 2012 NTT Communications

OpenFlowの構成	  5

OpenFlowの標準化動向	  2006-2011.02

2011.03-

基礎的	  
研究活動	  研究と	  実装活動	  デファクト標
準と	  オープンソー
ス配布	  
標準化団体	   　(*)NTT Comは設⽴立立当初よりメンバとして参画。2011年年12⽉月よりボードメンバー就任	  2010年年1⽉月
2011年年2⽉月
2011年年12⽉月
2012年年4⽉月	  OF v1.0
12Tupleのテーブル、テーブルミスマッチ時にPacket-In	  OF v1.1
マルチテーブル、グループテーブル、MPLS	  OF v1.2
マルチコントローラ、可変⻑⾧長マッチフィールド、IPv6	  OF v1.3.0
帯域情報、SecureChの負荷分散、PBB、ミスマッチ時のPacket-In⾒見見直し	  OF v1.3.1（予定）	  （バグフィックス）	  2013年年1⽉月〜～	  OF v1.4（予定）	  （v1.3と少し間をあけて実装を促す）	  Copyright © 2012 NTT Communications

6

OpenFlowがなぜ注⽬目されているのか？	  

API等	  AppOpenFlow
Controller
OpenFlow
プロトコル	  （標準化、開⽰示）	  OpenFlow
スイッチ	  Copyright © 2012 NTT Communications

上位システム（プログラム等）からネットワークの制御が可能	  →	  SDN (Software DefinedNetworking)の実現	  ⾃自動化による	  OPEXの削減	  コントローラ上に独⾃自のアプリを実装することで、差異異化が可能	  新機能の早期実現	  パケット転送の振る舞いをプログラミング	  コモディティ化した安いスイッチの利利⽤用が可能	  CAPEXの削減	  7

SDN/OpenFlowに期待すること	  • Time-to-Marketの短縮	  – ベンダーの開発ロードマップやスケジュールに依存せず、⾃自社に必要な機能を早期に導⼊入することができる	  • サービスの差異異化	  – 市中製品の仕様に縛られず、上位システムや独⾃自アプリなどを連携させることでサービスの差異異化ができる	  • CAPEX/OPEXの削減	  – コモディティハードウェア利利⽤用によるCAPEXの削減	  – SO業務や運⽤用の⾃自動化によるOPEXの削減	  Copyright © 2012 NTT Communications

8

今後のネットワークの⽅方向感	  「スピード、柔軟性」と「⾼高速、⼤大容量量」の両⽴立立	  サービス基盤の柔軟な設計	  ﾊﾟｹｯﾄ多重	  ⼤大容量量化	  （100G化）	  波⻑⾧長/伝送	   NWサービス	  スピーディな対応	  ﾘｿｰｽのEndEndｺﾝﾄﾛｰﾙ	  ベンダロックイン回避	  ハードウェア処理理が適した領領域	  ソフトウェア処理理が適した領領域	  Next Gen PTN/OpticalSDN/OpenFlow

NWサービス機能を⽀支える波⻑⾧長／伝送は、ハードウェアでNWをコントロールする既存技術で対応する	  柔軟性でスピーディなNWサービス	  	  	  機能の実現に、ソフトウェアでNWをコントロールするSDNを導⼊入する	  Copyright © 2012 NTT Communications

9• SDN/OpenFlowのコンセプトはいろいろ良良いことがありそうだけど、実際に使っていくためには？	  
• いろいろ試したり考えてみたりして、課題をあげてみる 　これが解決すると 　SDN/OpenFlow
はより使えるかも！！！	  

• まずはいろいろ試してみる	  – 実際に既存のいろいろな製品を触ってみる	  • 通信事業者なので、、、	  – WANへ適⽤用する場合を考えてみる	  Copyright © 2012 NTT Communications

10

実際に既存のいろいろな製品を触ってみる	  Copyright © 2012 NTT Communications

11

やってみたこと	  • フローテーブル学習機能検証	  • フローテーブル書き込み検証	  Copyright © 2012 NTT Communications

12

フローテーブル学習⽅方法：概要	  • OpenFlow技術を⽤用いてフローテーブルを学習させる⽅方法	  – Reactiveモード	  OpenFlow
Controller• スイッチはUnknownパケット
Packet-In
Flow-Mod受信を契機にOpenFlow（Packet-In）を⽤用OpenFlow
いてControllerへ問合せ	  SW• Controllerから未学習パケット
Reactiveモード	  のフローを”Flow-Mod”で設定	  – Proactiveモード	  • フローエントリーを事前に“Flow -Mod“を⽤用いて設定	  Copyright © 2012 NTT Communications

OpenFlow
Controller

Flow-Mod（事前に）	
OpenFlowSW

Proactiveモード	   13フローテーブル学習機能：検証イメージ	  • ⽬目的	  • OpenFlowの特徴であるC-Plane/D-Planeの分離離に注⽬目し、ReactiveモードにてC-PlaneにFlow数の増⼤大や遅延があった場合の影響を検証	  0.0ms (東京〜～東京)
8.2ms 　(東京〜～札幌)
100ms
200ms (東京〜～London)

OpenFlow
Controller

C-Plane
D-Plane

遅延があった	  場合の影響	  テスタ	  遅延	  OpenFlow
SWOpenFlow
SWテスタ	  

Data
Data
Data
Data

Data
Data
Data
Data

Flow数を増⼤大させた場合の影響	  Copyright © 2012 NTT Communications

14フローテーブル学習機能：検証内容	  • C-Plane性能試験	  – 未知のFlowを⼤大量量注⼊入した際のPacket-In、Flow設定の処理理	  – ①〜～⑥のEnd-End疎通までのPacket廃棄量量を測定	  (試験a) Flow数を増⼤大させた場合の影響(1〜～500Flow）	  (試験b) 遅延を増⼤大させた場合の影響（0〜～200ms）	  C-Plane①FlowTable
登録なし	  
⑤FlowTable
登録	  ③ Packet-In

OpenFlow
Controller

遅延	  ④ Flow-Mod

テスタ	  OpenFlow
SW

Data
Data
Data
Data
②⼤大量量Flow注⼊入	  Copyright © 2012 NTT Communications

Data
Data
Data
Data
⑥End-End疎通	  D-Plane①FlowTable
登録あり	  OpenFlowSW

テスタ	  15

フローテーブル学習機能：Flow数による影響	  • (試験a)	  Flow数を増⼤大させた場合の影響	  – 試験条件	  • フロー数：	  1フロー、10フロー、200フロー、500フロー	  • OpenFlow Channel 遅延：0ms

バースト的に新規フローが流流れてきた場合、CPU処理理の制約によりパケットが輻輻輳し、フロー数が多くなると最後のフローが登録されるまで時間がかかる 　	  Copyright © 2012 NTT Communications

16

フローテーブル学習機能：遅延による影響	  • (試験b) 遅延を増⼤大させた場合の影響– 試験条件	  • フロー数：1フロー	  • OpenFlow Channel 遅延：0.0ms、8.2ms、100ms、200ms
450ms相当	  遅延の増加に伴いフローテーブルの学習に時間がかかる	  Copyright © 2012 NTT Communications

17

フローテーブル書き込み検証	  • Proactiveモードによるフロー書き込み試験	  – バースト的にControllerからフローを書き込むことによる耐性試験	  •経路路切切り替えが起きた際のパフォーマンス確認のため	  – 最⼤大フローエントリー数の確認	  

OpenFlow
Controller

Flow-ModOpenFlowSW

Copyright © 2012 NTT Communications

18

フローテーブル書き込み検証：結果	  ベンダ	  製品名	  

測定値	  

備考	  

A社	  

A-1(10G)

768フロー	  Chip-X

A-2(GbE)

1637フロー	  Chip-Y

B社	  B-1

750フロー	   　	  Chip-XC社	  C-1

4096フロー	  Chip-Z• バースト的に書き込みを⾏行行ったが各スイッチ問題なく処理理をすることができた	  • フローテーブル数はネットワークプロセッサの影響が⼤大
きい	  • 既存製品レベルだとフローテーブル数が少ない	  Copyright © 2012 NTT Communications

19実際に触ってみて分かった（改めて分かった）課題	  • Packet-In過多時の影響	  – 重要パケットにはQoSをかけてPacket-Inさせる	  	  • C-Plane遅延による影響	  – コントローラ・スイッチの全体設計に考慮が必要	  • Proactiveモード	  Reactiveモード	  – 上の結果を踏まえるとProactiveモードを中⼼心として設定し、それ以外のパケットをReactiveモードで設定するのがよさそう	  – どちらの設定もできるような実装を希望	  • フローテーブル数	  – フローテーブル数を多く持てるコモディティスイッチは作れるか？	  
• これからに期待か	  – 既存Chipでも定義でテーブル領領域を⼤大きくすることは？	  
– 検索索するTupleを⼯工夫することでフローテーブル数を稼げるか？	  
– FPGAで安く作ることはできるのか？
Copyright © 2012 NTT Communications

20

WANへ適⽤用する場合を考えてみる	  Copyright © 2012 NTT Communications

21

OpenFlowネットワークと既存ネットワークとの接続	  • 既存ネットワークをOpenFlowネットワーク経由で接続	  – 経路路情報の伝播	  • 既存プロトコル（BGPなど）で実施 　→ 　スケーラビリティを考えるとこれがよさそう	  – Interop2012でのデモ	  • APIを介したシステム間で連携して実施することも可能？	  

• OpenFlowネットワークを既存ネットワーク経由で接続やOpenFlowネットワーク間接続（将来的に？）	  – これも実現⽅方法の検討が必要	  Copyright © 2012 NTT Communications

22

Interop2012でのデモ	  BGPのプロトコル処理理をコントローラ上で集中制御	  外部ネットワークからはIP-VPNと等価に⾒見見せかける	  Carrier Network Controller@NTTMCL
Customer/Operator Portal

NetworkController

CMDBeBGP

BGP
RouteController

VPN-1
VPN-2
VPN-3
VPN-4
VPN-5

OpenFlow Controller (RYU@NTT SIC)

eBGP
eBGP

CE11
CE31
CE41

CE7200

CE51

PE1P1PE3

CE32

CE23PE2P2PE4

CE12

CE43
CE53

ShowNet(Internet)

CE22

OpenFlow Based L3VPN

既存ネットワーク	  Copyright© 2012 NTT Communications

CE42

既存ネットワーク	  CE52

23

OAM機能	  • 適⽤用範囲を拡⼤大する為には、運⽤用に必要なネットワーク機能がまず先に必要	  – サービス／通信の正常性を確認する仕組み（開通時、運⽤用時）	  – 「物理理故障個所」と「サービス（論論理理NW）」の影響を特定	  – 異異常検知、異異常個所切切り分け、冗⻑⾧長構成切切り替えの仕組み、等	  • ソフトウェアで実装することで、汎⽤用スイッチで必要最⼩小限のOAM機能を実装できないか？

CPEBackbone NetworkAccessNetworkAAccessNetworkZ

CPE

End-to-end check(Continuity check)Segment check (Continuity check)
Copyright © 2012 NTT Communications

24

OAM監視機能:実現⽅方式１	  • OpenFlowネットワークと既存装置間監視	  – 既存装置との接続性	  

•L2：Ethernet OAM、L3：	  ICMP／BFD	  OpenFlow
Controller

OpenFlowSWと	  既存装置間	  Forward outside
OpenFlow NW
Copyright © 2012 NTT Communications

・Generate the OAM Packet 　（Packet-Out）	  OpenFlow network25

OAM監視機能:実現⽅方式2• OpenFlowネットワーク内の常時接続監視	  – フローエントリーの通りにパケットが疎通可能か確認できることが重要（開通、監視）	  •L2：Ethernet OAM、L3：	  ICMP／BFD•フローエントリーがMulti Tupleの場合の検討も必要	  

OpenFlow
Controller

1. OAM Packet’s aregenerated.（Packet-Out）	  OpenFlowネットワーク内	  vMEPvMEP
2. OAM frame is forwarded
end-to-end by Flow entry
table.
Copyright © 2012 NTT Communications

3. OAM frame is terminatedon the edge SW as virtual
MEP, and is forwarded toController for Packet-In.

26

（参考）分散型のOpenFlowコントローラ	  API等	  OpenFlow
Controller

API等	  コントローラ
連携基盤	  OFC

OFC

OFC

集中型のOpenFlowコントローラ	  （physically centralized）	  Copyright © 2012 NTT Communications

OFC

分散型のOpenFlowコントローラ	  （logically centralized）	  27OAM機能のアーキテクチャ検討１	  • 集中型（physically centralized）	  監視パケットの⽋欠落落を検出	  （常時）	   OFCPacket-Out
Packet-In
OFS
OFS
OFS

OFS
OFS
OFS

OFS
OFS

フロー数、スイッチ数の増加に伴い、コントローラの処理理能⼒力力がボトルネックになる。OFC－OFS間の断でもネットワークが切切れたことになる	  Copyright © 2012 NTT Communications

28

OAM機能のアーキテクチャ検討2• 分散型（logically centralized, physically distributed）	  監視パケットの⽋欠落落を検出し	  （常時）連携基盤に通知	  OFC

連携基盤	  
OFC

OFS

OFC

OFS

OFC

OFS

OFC

OFS

OFC

OFS

OFC

OFS

OFC

OFS

断を検出したOFCから通知	  

OFS

コントローラがボトルネックにならないように、分散配備したほうが良良い機能は分散的に実装する	  Copyright © 2012 NTT Communications

29	  29

OAM機能の検討（試験）	  • ループ試験	  – ①試験点、折返し点でのPacket-In/Outのテーブル設定	  – ②試験点から試験フレームのPacket-Out– ③折返し点でのPacket-In/Outによる折返し	   連携基盤	  – ④試験点での試験フレームのPacket-In– ⑤結果の通知	  
② ⑤
OFC ①
OFS ④

OFC
OFS
OFC
OFS

① OFC
OFS
③

OFC
OFS
OFC
OFS

OFC
OFS
OFC
OFS

試験フレームのヘッダを試験対象フローと同⼀一にすることで、同⼀一系路路上の導通確認が可能。試験フレームの⽣生成、挿⼊入、ドロップといった実装がソフトウェア化することでハードの実装を軽くできる	  Copyright © 2012 NTT Communications

30

TEをどうするか？	  
• マルチパス負荷分散	  – 複数経路路に効率率率的にトラヒックを流流したい	  • Applicationの要求品質に応じた経路路選択	  – 柔軟なサービスメニューの提供	  – オンデマンド／カスタマ制御でQOSを変化	  • 実現するためには	  – MPLSなどとHybrid 　→ 　OpenFlowとの連動	  – OF1.3のPer Flow Meters機能を利利⽤用	  – TEインテグレーション	  Low latency / High Cost
App#1

App#1
OFS

OFS

App#2

App#2
OFS

Copyright © 2012 NTT Communications

High latency / Low Cost / BE31

WANへ適⽤用する場合の課題	  • OpenFlowネットワークと既存ネットワークとの接続	  – 既存ネットワークをOpenFlowネットワーク経由で接続	  • 経路路情報の伝播– OpenFlowネットワークを既存ネットワーク経由で接続やOpenFlow
ネットワーク間接続（将来的に？）• これも実現⽅方法の検討が必要	  • OAM機能	  – 実現⽅方式	  • OpenFlowネットワーク	  －	  既存ネットワーク	  • OpenFlowネットワーク内	  – アーキテクチャ	  • 集中型	  • 分散型	  • TEをどうするか？	  
– マルチパス負荷分散	  – Applicationの要求品質に応じた経路路選択	  – 実現するためには	  Copyright © 2012 NTT Communications

32

まとめ	  Copyright © 2012 NTT Communications

33

課題のまとめ	  • 実際に触ってみて分かった（改めて分かった）課題	  – Packet-In過多時の影響設定可能フロー数の制限	  – セキュアチャネル遅延による主信号への影響	  – Proactiveモード Reactiveモード– フローテーブル数	  • WANへ適⽤用する場合の課題	  – OpenFlowネットワークと既存ネットワークとの接続– OAM機能– TEをどうするか？	  

Copyright © 2012 NTT Communications

34

機能配備の考え⽅方（案）	  コントローラ連携	  APP APP
連携基盤	  ーコントロ

APP APP
OFC

経路路交換、経路路設定（TEなど）	  低頻度度、数が少ない	   　→	  LB

Proactive/ Reactiveモード	  	  OFSCLI OF client
SW Firm

低頻度度、スピードが必要	   　→	  経路路切切替	  SWchip

常時⾏行行い、数が多い機能	   　→	  CC	  	  ラの設計

ＯＡ
Ｍなどの保守機能OFC（物理理分散）	  Proactiveな制御	   　→	  経路路設定、コンフィグ	  フローテーブル数	  Copyright © 2012 NTT Communications

35

スピードと柔軟性	  • 固定観念念にとらわれない	  – 誰もやったことがない	  – 何が正解か分からない	  • 考え込むよりも試してみる	  – まずプロトタイプを実装して試してみる	  – 経験を積むと⾒見見えてくる地平線が変わってくる	  • まずいところがあれば改良良する	  – 場合によっては最初からやり直す	  • オープンである事	  – スピード感のある技術開発	  皆さんと⼀一緒にいろいろやっていくことで、SDN/OpenFlowで出来ること、適⽤用領領域も	  変わってくると思います！	  
Copyright © 2012 NTT Communications36

ご清聴ありがとうございました	  Copyright © 2012 NTT Communications

37