Interop Tokyo 2014 三日目に参加した時のメモ雑記

1. Interop
Tokyo
2014
2014/6/13
Imamura
Yutaka

2. もくじ
1. モチベーション
2. So9ware
Defined
Network
– Juniper
Networks
3. 次世代ホームネットワーク
– NICT
4. Test
AutomaDon
– SQC
5. まとめ
6. 今後の取り組み

3. モチベーション
• SDNコントローラの傾向を視察
• 各SDNコントローラのターゲットの違いとかが
見えてきたらいいな
• さらに今からコントローラをスクラッチ開発す
るならどの辺りをターゲットにできそうか、ヒン
トがみつかればいいな

4. SOFTWARE
DEFINED
NETWORK
Juniper
Networks®

5. Juniper社のSDNコントローラ
• OpenContrailとNorthStarという二つのSDNコン
トローラ
– ちょっとしか説明聞けなかったですが。。。
• 事前知識
– OpenContrail
:
データセンター向けらしい
– NorthStar
:
WAN向けらしい

6. 説明を聞いてみて
• OpenContrail
:
Overlay
Networkの制御
• NorthStar
:
Underlay
Networkの制御
• 違う領域のネットワークを制御する、別々のソ
リューションだと考える

7. 各コントローラの問題領域
MPLSによる基盤網
Underlay
Network
IP/Ethによるテナント網
Overlay
Network
IP/Ethによるテナント網
Overlay
Network
VM
VM
VA
VM
VM
VA
Router
Router
Router
Router
OpenContrail
NorthStar

8. レイヤ化されたネットワーク
• Overlay
Network
– テナント別仮想ネットワーク
– 顧客のニーズによって構造は様々
– クラウドサービスプロバイダとかによる管理
• Underlay
Network
– 仮想ネットワークを支える基盤となるネットワーク
– MPLSを想定しているようだったけれど、BGP/
MPLS
IP
VPN
(RFC4364)とかを使うということ？
– 通信キャリアによる管理

9. 解らないところ
• Underlay
NetworkにてPCEPを使ってパス計算
をする目的ってなに？
（UnderlayはOverlayと比べるとあまり変化しな
いはずなのに、動的パス計算が必要なのか）
• Overlay/Underlayそれぞれで障害が出た時に
どう見るのか
or
どう対処できるのか
（SDNコントローラってこの辺あんま言及され
ないのが気になる）

10. 怒るところ
• なんでNorthStarはOSS化しないのか！！！
– ユーザとして通信キャリアを想定しているから安易に
OSS化したくないのかな？
– (
-­‐
3
-­‐
)
Boo
Boo
• 個人的な嗜好の問題かもしれないけど、Contrail
のランタイムはJVMにしてほしかった……
– 実行ファイルの移植性厨
– Polyglotなプラグインを組み込めるかもしれないのに、
もったいない

11. 他のコントローラ展示も見てみて
• SDNコントローラ超いっぱいある
• デファクト感出しているのはやはり
OpenDaylight
• 特色の出し方
– デフォルトで使えるプロトコルの数
– モデル/サービス開発のAgility
(YANGとか使う)
– 水平分散によるScalability
– OpenStackなどのミドルとの連携

12. 次世代ホームネットワーク
NICT

13. iHouse
• セットトップボックス上で起動するコントローラ
がおうちのカーテンやエアコン、照明を操作で
きる！
• 温度、湿度、気候などのデータ項目を収集す
ることでコントローラは自律的におうちを制御
する！
• こいつはSo9ware
Defined
おうち！

14. 説明を聞いてみて
• PLC
(Power
Line
CommunicaDon)という技術で電
力線に通信回線も多重しているって面白い
– 逆にEthernet回線に電力供給を多重するPower
over
Ethernetという技術も後で調べて知る
• ホームゲートウェイ開発がモリモリ来ないかと期
待
– Raspberry
Pi使ってホームゲートウェイ作っている人
いそう
– スマホ系の開発者もこちらへどうぞ、でしょうか
• 自家発電して余った電気をP2Pで別の家に転送・
供給とかもできるのかも

15. 解らないところ
• 安価にセキュアな通信回線を供給するにはど
うしたらいいのだろう？
• 専用線をひかずに今使っている通信キャリア
のインターネット回線に「安全に」ホームゲー
トウェイネットワークを多重するにはどうしたら
いいのだろう？
• →たぶんMVNOの話とかに行くんだろうな

16. TEST
AUTOMATION
SQC
Inc.

17. SQC
TestShell
• ラボ（検証）環境のネットワークの回帰テスト
自動化
• 機器の構成管理
• 機器の利用/予約状況をトラッキング
• L１スイッチで物理配線の自動化

18. 説明を聞いてみて
• 構成管理からテスト自動化まで面倒みますと
いうので、カバー範囲が広くて逆に怖い
（一社の製品にプロセスが依存すると思うと
ちょっと……）
• L1スイッチはOpenFlowスイッチで代替できる
はず→専用アプライアンス買うというのは無
駄っぽい

19. ネットワーク系のテストアプリケーショ
ンについて
• このTestShellの他にもSpirent
CommunicaDons社のTestCenter等がある
• どれにも言えるのは
• 何故かGUIでテストシナリオの制御構造を作
らせるということ
• これがけっこうくせ者……

20. ここから脱線する

21. GUIによるシナリオ作成の問題
• GUIによるシナリオ作成のメリットとして説明さ
れた一言
– 直感的に操作できる
• でもこれが有効なのはGUI表現がユーザのメンタルモ
デルと一致しているからこそ
• 制御構造がユーザの頭の中に図として浮かぶことが
あるのか？
• そんなの浮かぶくらいならプログラム書け
• →GUIでシナリオを作るのは実は大変

22. さらに問題点
1. GUIからテストシナリオの制御構造を記述
2. Gitにシナリオを登録
3. 複数人でそのシナリオを編集する
4. Conflictする
5. GUIからはマージが困難で、結局生成された
シナリオのソースコードを編集する
6. よってGUIによるテストシナリオの記
述は後々辛くなる

23. 脱線してでも言いたいこと
• GUI
＝ 使いやすい
• と、安直に考えるのはやめてください
• ベンダーの甘言に惑わされないで下さい
• テストシナリオの作成はもっとプログラマブル
でいいはずなんです
• （一応TestShellはそういうサポートもしている
ようです）

24. まとめ

25. まとめ
• SDN
– SDNコントローラ増殖の中でJuniper社のプロダクトは
ターゲットを絞ることで特色を出している
• ホームネットワーク
– そのネットワークで何を伝送するか、そのネットワーク
をどう提供するか、が大事
• 自動テスト
– ネットワーク機器の自動テストソリューションは大規
模・高価になりがち
– その割に手順やプロセスの進化が遅い気がする

26. 今後の取り組み

27. SDN界隈でのアクション
• 明確な問題領域を持っているメーカやキャリ
ア以外の人々にとっても導入しやすい、シン
プルで軽量なSDNソリューションってなんです
か
– というのを考えていきたい
or
事例を探したい
• クソダサいペラペラのSDNコントローラ作りた
い
• けれど柔軟にプロトロル実装できるPDUの
codecが必要そう