...

光コアネットワークのSDN化 への取り組み

by user

on
Category: Documents
8

views

Report

Comments

Transcript

光コアネットワークのSDN化 への取り組み
SDN JAPAN 2016
光コアネットワークのSDN化
への取り組み
~広域ネットワークでのSDN実現に向けて~
富士通(株) 山田亜紀子
[email protected]
SDN JAPAN 2016
SDN:簡単なおさらい
App
多種多様なアプリ
‐‐‐‐‐‐‐‐‐‐‐ Open Interface (NBI) ‐‐‐‐‐‐‐‐‐‐‐‐ プログラマビリティ提供
Control or Control or Control
Plane
Plane
Plane
様々なコントローラ
‐‐‐‐‐‐‐‐‐‐‐ Open Interface (SBI) ‐‐‐‐‐‐‐‐‐‐‐‐
Merchant
Switching Chips
Vertically Integrated
Closed, proprietary
Slow innovation
Horizontal
Open interfaces
Rapid innovation
出典:“How SDN will shape networking”, Nick McKeown, 1st Open Networking Summit (2011/10)
単純なスイッチ製品
Lagopus
NEC
DELL
HP
IBM
Cisco
Juniper
Pica8
Arista
BROCADE
FUJITSU
etc…
SDN JAPAN 2016
SDNに特に期待するポイント
ネットワークをプログラムで変えられる
ネットワークやさんの視点:
⼿動でのネットワーク変更は怖いけど、SDNコントローラによる変更はテスト済だから
安⼼!
集中制御アーキなので、SDNコントローラ機能もいろいろ作って追加しやすい
ネットワークを使うユーザ視点:
ネットワーク設定をPlug&Playで⾃動化できるとGOOD
(⾃動的に設定してくれるアプリがSDNによってできるよね)
SDN JAPAN 2016
どうしてネットワークをプログラムで変えたいの?
ユーザ視点の例
“いつもはコネクティビティがあればいいけど、⼤事な会議のときに映像が絶対
に途切れないようにしたい”
⼤事な会議のセッティング
とあわせて
オペレータ視点の例
“ユーザAさんはネットワークを⽉〜⾦までしか使わない。⼟⽇は他の⼈に使っ
て(買って)もらいたい”
⼟⽇に使いたい⼈に
あわせて
SDN JAPAN 2016
広域SDNで、例えばこんなことができる
本社
本社
1G
1G
WAN
支社
1
500M
500M
本社
1G
WAN
支社
2
契約時に必要帯域を想定
BEFORE:変更不可
支社
1
100M
900M
WAN
支社
2
支社
1
900M
100M
あるときは・・・またあるときは・・・。
AFTER:⾃在に変化
支社
2
SDN JAPAN 2016
広域SDNのメリット
柔軟な広域ネットワーク活⽤で得られる様々なメリット
センサーを配置したら
Plug&Playでクラウドにデータ
を集めはじめてくれる
光コアネットワークの
SDN
マルチレイヤ連携で、光も使いこなす
SDN JAPAN 2016
光コアネットワークSDN
広帯域が必要なコネクションには、パケットトランスポートでAggregationせず、広
帯域・低遅延保証が可能な光コアネットワークを直接利⽤することも可能に
パケットトランスポート
ネットワーク
光コア
ネットワーク
パケットトランスポート
ネットワーク
光コア
ネットワーク
スイッチネットワーク
スイッチネットワーク
BEFORE
AFTER
SDN JAPAN 2016
光コアネットワークSDNを実現するには
1. SDNによる制御管理のための単純なリソースモデル
複雑な光コアネットワークでのプログラマビリティの実現
2. 上位レイヤサービスとのシームレスな連携(マルチレイヤ)
光コアネットワーク
パケットトランスポートネットワーク
OTN/WDMをターゲットに検討
スイッチネットワーク
SDN JAPAN 2016
マルチレイヤ連携のために
マルチレイヤをオーケストレーションするSDNコントローラの
実現が必要
 レイヤに依存しないリソースモデル
 レイヤ間連携のための汎⽤的な機能
SDN JAPAN 2016
マルチレイヤSDN制御アーキテクチャ
Viewer
Operator/User
/ Application
PCE
SDNユーザ
SDNコントローラ
SDN OS
レイヤ間連携のための仮想
ネットワーク操作機能を具備
仮想ネットワーク
リソース
仮想ネットワーク
操作機能
パケットNW
リソース管理制御
ID
mapping
仮想ネットワークリソースは、
レイヤ⾮依存で統⼀的に扱える
光コアNW
リソース管理制御
NWリソースへの要求と連動し、
管理制御機能が動作
ID
mapping
物理ネットワーク
(パケットノード、光コアノード)
SDN JAPAN 2016
SDN OS:
ネットワーク管理制御プラットフォーム@O3 Project
 広域ネットワークのSDN実現のための技術研究開発を推進
 ネットワーク管理制御プラットフォーム⽤
フレームワーク“ODENOS”
Node
Port
Link
Flow
OAM, SDNガイドライン
http://www.o3project.org/ja/research/index.html
SDN JAPAN 2016
光コアリソース:詳細な物理情報をいかに隠蔽するか
Client
signal
TTP: Trail Termination Point
LO ODU Path
LO ODU Path
LO ODU Path
CTP: Connection Termination Point
Optical Node Example
CTPP: CTP Pool
SDN Model
・・・
ODU SW
ODU SW
λ SW
λ SW
複雑な階層構造、
Tributary Slot
ODU
layer
OCh Path
OCh Path
λ
・・・
実際の装置
(OTN/WDM)
WDM Link
OTN/WDMパス構成
OCh
layer
OMS
layer
Fiber Port
よりシンプルなモデル
SDN JAPAN 2016
SDN OS:ODENOS
ODENOSでは、ネットワークオブジェクトとして様々
なネットワーク資源を抽象化して管理
光コアリソース(OTN/WDM)を表現すると・・・
ODU
SW
ODU SW
ODU SW
ODU
SW
Abstracted OCh path
LinkLayerizer
λ SW
λ SW
NWC0-NWC1
Boundary
OCh path
λSW
光コア シンプルモデル表現
Node
Port
Link
λSW
ODU
SW
ODU
SW
光コアリソース (ODENOSモデル)
Flow
SDN JAPAN 2016
リソースの表現例(ごく一部)
Link
"links": {
“Link1": {
"nodes": {
Node
“NODE2": {
"attributes": {
"vendor": "Fujitsu“
"attributes": {
"latency": “5",
},
"max_bandwidth": "10000",
"node_id": “NODE2",
:
"ports": {
"CTPP1": {
},
:
"dst_node": “NODE2",
"dst_port": "CTPP3",
:
},
"CTPP2": {
:
Port
SDN JAPAN 2016
SDNコントローラ動作:
マルチレイヤのリソースを書きこみ
ODENOS ネットワークコンポーネント
OSAKA
パケット担当
マネージャ
これで、アプリが仮想リソース
として認識!
NAGOYA
TOKYO
パケットレイヤ
リソース
OPT2
OPT1
OPT3
OPT4
光リソース
(OTN/WDM)
ノードリソースや
最初に設定済みの
パスなどを登録します。
OCNRM
光担当
マネージャ
光ネット
リソース
情報
光ネットワークの
物理情報を変換
OCNRM:Optical Core
Network Resource Manager
SDN JAPAN 2016
SDNコントローラ動作:
マルチレイヤ間の接続情報を持つLinkLayerizer
ODENOS
パケット
リソース
レイヤ間の接続、情報伝達
(マルチレイヤ対応)は
“LINK LAYERIZER”
NAGOYA
OSAKA
というものを
作ってお任せしちゃいます。
TOKYO
OCNRM
OPT2
OPT1
OPT3
OPT4
光リソース(OTN/WDM)
SDN JAPAN 2016
SDNコントローラ動作:
アプリからの要求
Application
⼤阪-東京間に
“超・低遅延”パスを要求
ODENOS
event
パケット
リソース
東京
⼤阪
SDN Controller
NAGOYA
OSAKA
TOKYO
OPT1からOPT4に
超・低遅延パス
を作ればいいのね
パケット担当
マネージャ
OPT2
OPT1
OPT3
OPT4
event
光リソース(OTN/WDM)
OCNRM
光担当
マネージャ
SDN JAPAN 2016
光コアリソース設定の流れ
① 光パス割り当て(ODENOSモデル)
MF
OCNRM
②
物理設定パラメタに変換
(DPID、Port#、Tributary Slot、・・・)
ID
mapping
③ コマンド発⾏(OpenFlow光拡張)
ONF OTWGにて標準仕様策定(EXT-445,446)
RYU OTN
Extension
SDN JAPAN 2016
簡単なデモをご覧下さい
光コア担当マネージャ、アプリ
: 富⼠通
パケット担当マネージャ、アプリ : ⽇⽴製作所
ODENOS
: NEC
O3Project公式サイト http://www.o3project.org/ja/
GitHub https://github.com/o3project/
SDN JAPAN 2016
論物変換の話
シンプルなモデルで扱っても、最終的には装置の設定を細々と⾏う必要がある
?
SDN OSと、プロトコルで扱う
オブジェクト名が異なる
(DPID等)
SDN OSに無いテクノロジ
依存のパラメタ(Tributary
Slotなど)が必要
OTN/WDM
装置
ODENOS
OpenFlow
現状
別途、プロトコルと物理
リソースを意識した割当て、
変換を実施する機能あり
最も洗練された⽅法は??
★ SDN OSあるいは装置でプロトコルで定義されたオブジェクト名を扱う?
★ 細かいパラメタの割当ては装置がやってくれれば良い?
★ SDN OSのモデルでもっと細かいパラメタを抽象化して扱えるようにすべき?
MF
Management
Function
SDN JAPAN 2016
まとめ
必要な時だけ広帯域/低遅延なネットワークを使える光コアSDNを実現
マルチレイヤ連携 / シンプルモデル / OpenFlowの光拡張
OSSを使った動作をご紹介(物理装置まわりはダミー)
さらに、今年度は柔軟性をアップ、様々な帯域(1.25GbpsxN)を指定で
きるFlexible ODUにも対応
是⾮、O3プロジェクトのデモブースにもお⽴ち寄り下さい
ご静聴ありがとうございました
Fly UP