キャリアサービスに求められるOAM機能

MPLS Japan 2007
NTTコミュニケーションズ
大澤 浩

はじめに

OAMとは？
広義のOAM‒ 保守運用管理の仕組み

じゃあNMSとかコマンドラインも？

狭義のOAM‒ 故障検出、切り分け、性能測定、（装置間の）故障通知、故障回復（Protection/Restoration）に使用される技術
今回はこちらに絞ります（用語の定義）
故障検出 …CC（Continuity Check） （常時監視）…Loopback （オペレータがOn-demandで行うもの）
切り分け …Trace
性能測定 …PM（Performance Monitoring）
故障通知 …AIS/RDI
故障回復 …Protection※全てこのプレゼン内だけの勝手な定義ですOAMの要求条件（概略）

オペレータが求めるものを簡単に言うと…

故障の発生をオペレータが認識でき、（冗長区間であれば）自動で切り替わる事必要であれば網外の装置に通知できる事

利用者視点のOAM分類１

利用者に取って、本当にこれが望ましいのか？

故障検出/切り分け/性能測定
PM（Performance Monitoring）

Trace

変換

Loopback

AIS/RDI
CC
結果

結果

Protection

利用者視点のOAM分類２
故障検出/切り分け/性能測定
Trace

PM（Performance Monitoring）

CC

Loopback

変換
AIS/RDICC

結果

理想論はこうなる？（できるできないはおいといて…）⇒ビットエラー、順序逆転も検知 結果⇒特定パケットサイズのみのエラーも検知（Loopback）⇒性能（Throughput/Delay/Jitter）劣化も検知（PM）⇒検出と同時に故障箇所まで特定（Trace）

Protection

現状現状のMPLS （PWE）網とOAM（CC）
Pingによる監視
LSPのRefresh
構成例

Probe
装置

P
PE

USER

Probe装置

PE

Pseudo-Wire

パッチ
パネル

パッチ
パネル

P
L2/L3

USER

L2/L3

・L2（LOS/PPPのHello/LFS等）
・L3（ルーティングプロトコルのHello等）

現状のMPLS （PWE）網とOAM（Trace/Loopback/PM）
Probe装置からのPingによる試験（パケットロス/遅延測定）

Probe装置

USER

P・IP-Ping/Traceroute
・LSP-Ping/Traceroute

PEPE

Pseudo-Wire
Pseudowire Ping

L2/L3
測定器

Probe装置

PUSER

L2/L3

・MAC-Ping
・IP-Ping

Generator/Analyzerによる・Throughput試験
・ビットエラー試験

測定器

不満点（故障検出系）
遅い– L2/L3のHello系やLSPのRefresh

範囲が狭い（物理的・論理的）– 測定器試験以外


理想は保守範囲全てを網羅したい

信頼性が低い– 故障した装置自体が行うOAM全般


ソフトウェアの異常時にはなおさら。。。

お金が掛かる– 外付けProbe装置、測定器

面倒
– 測定器

（T-）MPLS専用線のOAM

専用線ってどんな感じ？


旧来の専用線ユーザはまだまだ多い（線じゃないのもありますが）– デジタル専用線、パケット交換（X.25とか）、FR、ATM– アナログ専用線とかもあります

旧来の専用線維持コストは年々上がる– 割り勘要員が減っていく– EOL設備の保守契約に追加費用を払ったり…
– EOL寸前に部品を山ほど買い込んで予備品にしたり…



専用線ユーザの要求品質は桁違い– 1秒切れて叱られる– 計画工事の回線借用が断られる


例えバックアップ利用であっても– 大地震でも切れたら駄目

専用線品質のMPLSサービス（MPLS専用線）を作るには？

OAMと階層化

オペレーションのドメインとレベル（レイヤ）の概念が必要– 保守範囲単位でOAMも分かれる– Y.1731で言うMEGレベルのような感じ

高いレベルは透過、同一/下位は終端など

プロテクションの階層化には注意– 基本的には下位レベル（レイヤ）ほど速く– 下位レベルの切り替えは上位に見せたくない

OAMの要求条件 〜故障検出編〜 １
確実性‒ 全ての故障を確実に検出できる事
Data Plane
 Control Plane←こちらの方がより重要

高速性‒ 一瞬の故障でも検出できる事– 故障発生からProtectionによる回復までの時間短縮

Scalability‒ 多数の回線収容時にも検出が可能な事

OAMの要求条件 〜故障検出編〜 ２
装置内部まで含めてend-to-endで（特にシャーシ型）– 理想は保守範囲の端から端×FablicLine-cardCC

Line-card○CCOAMの要求条件 〜故障検出編〜 ３


物理的、論理的両方を考慮– データパケットとできる限り同じ扱いで…
Transitノード

Transitノード

CPUCPU

受信再生成

OAM

Fablic×○

駄目な例（受信して再生成）

良い例

Line-card

Data

Line-card

FablicLine-card

Line-card

Data

OAM

（OAMが通った事にも気付かない）

OAMの要求条件 〜故障検出編〜 ４


予備系についての正常性確認
Loopbackの単位は回線毎– １アクションで回線全体の正常性確認（特に回線開通時）スループット試験
BERTの機能があるとなお可帯域の浪費は特に気にしないでも良いOAMの要求条件 〜その他〜

故障通知（AIS/RDI）– UNI部分の故障通知
AIS/RDIのようなものでユーザと故障通知
 ユーザからのOAMはフィルタできる事
– OAMマッピング

場合により、OAMを変換あるいは透過できる事– 例：Ether-OAM ⇔ MPLS-OAM

Protection– Hold-timeやThresholdには柔軟性が欲しい

警報とフィルタ– 何らかのアラーム数抑止機能が必要（人的スケーラビリティ）– 理想論的にはNMS側でフィルタだが、現実問題としては装置側にも何らかの機能が必要かOAMまとめ

OAMの範囲は保守区分毎
単位は提供物（その網が提供する回線）
OAM
レベル

回線（サービス）保守区分
アクセス部分の保守区分

USER

バックボーンの保守区分

DSU

DSU

必要に応じて変換/透過

USER

今後のOAM

今時のサービスとOAM


CC、Trace、PM、AIS/RDI、Protection…
– 概念はSONETやATMができた頃から進歩なし？



今の売れ筋は網型サービス– ISP、IP-VPN、広域イーサネットなどなど



NWだけではなかなか食べていけない– 高レイヤとの組み合わせ– 動画等のコンテンツ系– セキュリティ系– P2P系（？）

MP-MPのOAM？


今現在やっている事は基本的にP-P
一部のアドレス間だけうまく通信できない事は（稀にだが）ある– とは言うものの、不特定多数間のOAMはどうすれば？

Probe装置

SW

SW

SW

Probe装置

SW

Probe装置

高レイヤのOAM？
故障検出は提供する機能要素毎に行うべき– 例：メールサービスで定期的に試験メールを出し、到達性や遅延をチェック– セキュリティ関連サービスであれば、セキュリティ監査サービスはある意味OAMのようなもの？
– Skype等は、（このプレゼン的には）高度なOAM機能を有しているとも言える


CC＋Protection

NW屋としては微妙なところ– 故障時にユーザが救われるのは嬉しい– 上位レイヤが故障の高速検知ができるようになるならば、下位レイヤではそれ以上の高速切り替えが必要まとめいろいろ言ってはみたものの…
本当の理想は？
– そもそも故障が起こらない– 操作が簡単Simple is Best. 多機能すぎるのも…
– 複雑な装置は壊れやすい

バグだらけで誤動作するOAMなら無い方がマシ– ものが高すぎると買えない– 分かりにくい技術のオペレーションは大変

まとめ

現状はいろいろ不満あり– 特に故障検出の範囲（物理/論理）の狭さ– 昔に比べると大分良くなってはきました

マイグレーションには専用線と同等以上のOAMが欲しい– 確実に故障や劣化を検出するのが最重要課題– OAMのドメイン、レベルの概念– (網全体で)数10万本ぐらいの回線提供をできるScalabilityOAMもサービスの性質に応じて変化すべき？とは言うものの、あまり複雑化しすぎても困るご清聴ありがとうございました