MPLS JAPAN 2005

GMPLSネットワークの構築・運用
2005年11月22日
NTTコミュニケーションズ株式会社
藤原和弘

1

はじめにNTTコミュニケーションズのGMPLSへの取り組み•映像伝送へのGMPLSの適用•HD非圧縮IP伝送/発局切り替えデモ（2005/06）•HD非圧縮IP伝送/GMPLSプロテクションデモ（2005/06）•GMPLSによる伝送網の高度化•実網を用いたフィールドトライアルの実施

これらの経験から「こんなことが出来ました」
ではなく、「こんなところで苦労しました」
を中心にお話します2

Agenda
回線開通
装置設定時のトラブル

予備検証時の問題（軽く）Cplaneの設計準備・設計

構築

運用

オペレーションツール
障害検出・切り分け
予期せぬPathTear
Cplane/Dplaneのアンマッチ
3

デモ構成例GMPLS対応 伝送装置
GMPLS対応 ルータ
非圧縮HDTV映像伝送装置（高信頼ATM伝送）
非圧縮HDTV映像伝送装置（IP伝送）
HD-CODEC＋IP映像伝送装置

ネットワーク
制御端末

GMPLS制御網
バーチャルスタジオ

GMPLS制御網

HDカメラ

2.4Gbps×2HDモニタ#1

ギガストリーム

IP伝送
HDモニタ#2 （非圧縮/圧縮 HD）

模型 HDカメラ（遠隔制御）

コントローラ映像
ﾌｧｲﾙ

ファイルサーバ

展示会場

大阪

高信頼ATM伝送（非圧縮HD）

PC

遠隔模型制御蓄積映像
ファイル転送東京

取材先の映像ファイル
4

準備・設計編（１）予備検証
特に相互接続は問題がまだ存在する

けいはんな相接WGやPILなどで相互接続性向上の取り組み中！（ここでは一例の紹介）

XC未設定時の挙動（実装に依存）
CplanePathMsg

PathMsgを送出してもよいと判断

XC未設定

SDH XC

セクションは上がっているのでIFはUP
Cplane

XC未設定

OTNやWDM系（多分PXCも）×

PathMsg

IFダウンと判断、PathMsgを吐かない

LOSやMS‑AIS送
出などまちまち5

準備・設計編（２）Cplane
GMPLSだとDplaneだけでなくCplaneも用意する必要がある！！
•コスト•Availability•信頼性•機能•etc

選択肢：•インターネット–安い、Availability高い/信頼性は？

•Cplane専用網を構築–信頼性高い、機能も選べる/高い、開通時間かかる•インチャネル/インファイバ（SDH DCCなど）–安く出来る/メディア限定•インターネットを使ってやりました•Cplane専用網
6準備・設計編（２）Cplane（Cont.）
インターネット•時間とお金が無いときに利用•セキュリティのため、トンネル（PPTP）を掘って使用•準備期間中はいつの間にかトンネルが切れてたりトラブルあり•「なにかあったらあきらめよう」のつもりが、何も問題なく終了（運が良かっただけ？）

Cplane専用網を構築•すでにある程度の設備がある場合に利用（お財布を気にせず。。。）•シグナリングをすべてキャプチャしたかったのでEther＋RSPANで設計•RSPANの設定で一時はまるが稼動してしまえば特に問題なし

インチャネル/インファイバ（SDH DCCなど）•装置によっては自由に使える場合あり•トポロジに制限を受ける場合あり、また生死を共にするリスクも。。。
•コスト的には一番安いが、利用できないケースが多い

適材適所で•でもやっぱり専用網が安心？
•信頼性の実現がキモ
7

構築編（１）回線開通など（余談）
GMPLS対応装置間（Cplane/Dplane）の回線をまず開通させる必要あり•装置の設定ミス•構内配線の誤接続•光レベル確認•AutoNegoエラー•etc

結構時間がかかる（GMPLS以前の問題）•GMPLS非対応な装置の保守者への通知‑LSP削除時/プロテクション実験時などの警報の非監視依頼

レイヤ０まで全てGMPLSで制御すれば解決？！

8

構築編（２）装置設定時のトラブル
RSVP‑TEでパスを張るためにはまずOSPFでTE情報の広告が必要（装置初期設定）•XC基本設定＋GMPLS設定で、項目が倍増•うっかりXC設定などが残っていたら変な広告が。。。
•間違えた設定でもそのとおりTE情報を広告する場合も（CplaneとDplaneが別なので設定情報が神様）

結局
OpaqueLSAの中身をひとつひとつ確認
まだリンク数やノード数が少ないから対応可能だけど。。。

要望•TE情報のビジュアル化や確認機能の作りこみ（Mplaneの機能？）•LMP（Correlation機能）の実装

9

運用編（概要）
基本的な運用方法（模式図）
Telnet端末

架前端末（Dplane用）

ルーティング・シグナリング
LSP表示ツール

キャプチャ

映像伝送装置
（IP）

••
•

ルータ
伝送装置

Telnetでコマンド投入/故障切り分け
映像で疎通確認
伝送装置のDplaneの障害対応には架前端末も利用
10

運用編（1）オペレーションツール
ラボでは。。。
•わかっている人が触っている（わかっている人しか触らない）•CLIに抵抗なし•異常動作時の対応の経験も蓄積（CplaneとDplane両方あるので複雑）デモでは。。。
•何人もの説明員が交代で説明・操作•CLIはよくわからない•異常動作時の対応は困難（マニュアルを作っても。。。）

結局異常時などは「説明員に緊急時の連絡先を渡しておく」のが一番効果的でしたが、一応こんなものを作ってみました11運用編（1）オペレーションツール（Cont.）

なかなか重宝したが、デモでしか使えない荒業
だれにでも使えるオペレーションツールがほしい！
12

運用編（2）故障検出・切り分け
SyslogやSNMPを積んでいない装置あり（EMSは利用せず）
統合的な監視はあきらめる（期間も短いし。。。）
そうすると。。。

•装置のLEDを見て初めて故障に気づくケースもあり•各ノードにログインして、ログや状態を確認して切り分け
力技に頼る非効率な運用
要望•出来ればSyslogやSNMPを使って監視などしたい•LSPの状態などもMIBで取ってくることができればうれしい13運用編（3）予期せぬPathTearなど
GMPLS:伝送網も含めた自律分散的動作が可能なところも特徴のひとつ•On Demandな専用線•Dynamicに迂回する専用線などが実現可能

ところが。。。
•NWには何も変化がなかったときに、勝手にPathTearが吐かれる事象•一度はLSPがUpするのに勝手にDown/Upする事象が発生•切れてほしくないところで勝手に切れてしまった•原因は未だに不明

要望•勝手に切れない（切り戻らない）仕組み（PCパスを用いる？）•PathTearの原因もログに残す仕組み

14運用編（4）C/Dplaneのアンマッチ
InitiatorからPathメッセージ送信⇒Resvメッセージ受信
で、LSPがUpして見えるが、トラヒックは通らず。。。
切り分け疎通確認：pingではDplaneでIP awareなノード間でのみ確認可能

EROなど確認：中間ノードでFAを張っているとノードや経路の特定不可

ノードのLSP確認 ：一つ一つ追っかけていって状態表示⇒異常なし（Cplane）
XC状態確認：Cplaneで保持している状態と実際のXC設定にアンマッチあり（Dplane）（架前端末で確認）FA

15

運用編（4）C/Dplaneのアンマッチ(Cont.)
対処：結局CplaneとDplaneをそれぞれ手動で復旧させた
要望•IPレイヤ以外のPing/Traceroute機能（Dplane疎通確認機能）•ノード内でCplaneとDplaneの不一致を検出する機能•統合的にDplaneの状態確認や設定も出来る手段•Dplaneで起こっていることをCplaneでも通知して欲しい

16

まとめ
•いろいろなデモやフィールドトライアルの成功⇒GMPLSが使える技術であることを証明•サービスの実現に向けては運用上の課題も見えてきた•監視方式（異なるレイヤの装置の一元監視）•LSP管理（とくにOnDemandサービス対応）•確認、切り分け手段•今後はより実運用を意識した技術開発が必要！
•SyslogやTrap、MIBなどの実装の進展•Operation Toolの開発•PingやTracerouteなどの方式検討 など

17

ご静聴ありがとうございました

18