MPLS Japan 2007

IP/MPLSマルチキャストの運用管理技術への期待
2007年10月10日
NTTコミュニケーションズ株式会社
上手 祐治
1

アジェンダ はじめに マルチキャスト通信の管理 キャリアOAM
 サービスOAM
 まとめ2

はじめに マルチキャスト通信の管理について、技術の側面から考えてみたいと思います。
レイヤ2〜3制御を対象として

3

背景： マルチキャストの課題
 経路制御 IP:multi-topology routing, static等
 MPLS: P2MP-TE
 信頼性担保

IP: 上位レイヤでFEC (Forward Error Correction)
RTP/RTCP

MPLS: TE/FRR Protection
 運用管理← 本発表のメイン
4マルチキャスト管理の悩み
 運用で難しい点
到達性監視：
全受信端末まで到達しているか？（障害検知含む）

経路監視：
どんなツリー形状になっているか？

（受信端末）（送信端末）

障害の切分け：（トラブルシューティング）

5

運用管理： IPマルチキャスト
 ツールはいくつかあるけど、課題も多い…
対象 ツール機構

適用範囲

課題

IP

ICMP Echo応答
でend-end検知

到達性監視・キャリアとカスタマの境界が曖昧【後述】・切分け（traceroute）不可

ping（マルチキャスト宛）（低レート前提）障害切分け

・下流からの逆流探索となり実データの流れと異なる。
・状態系チェックであり、転送系障害は検知できない。

IPmtrace

マルチキャスト経路をトレース

IP

CLI

show ip mrouteで 経路監視ルータのエントリ（S,G）をトレース・管理システムの整備。
・定期ポーリングの負荷。
・ベンダ依存

IPMIB

ﾏﾙﾁｷｬｽﾄMIB,経路監視
PIM MIB等で監視・管理システム整備。
・定期ポーリングの負荷。
・NW機器の対応状況にば
らつき
6

悩み
 IPの悩み ユーザ側の利用プロトコルとしてはおそらく必須 ただし、通信事業者網でIPマルチキャストをそのまま使うと、運用管理面で無理が生じることも IP以外の技術も考える必要 Ethernetのカバレッジが増えている回線サービス、送受信対応機器
 MPLSマルチキャスト技術の拡張

P2MP-TE, multicast LDP

 組み合わさったとき、運用管理はどうなるか。
7

運用管理： MPLS, Ethernet最近
 マルチキャストで期待されるツール
対象

ツール

機構

適用範囲

MPLS

P2MP-Ping

LSP-PingのP2MP版。
送信側からのツリー
Traceにも対応

到達性監視

Cf. draft-ietf-mpls-p2mp-lsp-ping（低レート前提）、

障害切分け

Cf. draft-ietf-mpls-mcast-cv

定常的なツリー監視をス 到達性監視
ケーラブルに実現。BFDを利用

MPLS

CLI、MIB（P2MP-TE関連）

ヘッドエンドLSRだけで 経路監視
ツリー形状全体が見える

Ether

Etherのマルチポイント
Ether OAM CC, LB（マルチキャスト送出） 接続性に対応したOAM

MPLSMulticast CV

到達性監視

802.1ag、 Y.1731
8実際に適用を考える際の注意： 運ぶ物（カスタマ側）：

IP (IP-VPN, Pure IP)
Ethernet (VPLS)
他
 転送する物（事業者網側）

MPLS （！）

9通信網の構造 マルチキャストの機構

カスタマはEnd-Endでマルチキャスト通信
中継Providerはカスタマのマルチキャストを階層化することができる（スケール性の観点から）
Customer
Customer
Provider
Pで分岐PE
CE

階層化

P

PEで分岐
Customerサイト内で分岐
10通信網の構造に着目
 コアツリー (キャリア網：Intra-NNI) P2MP-TE, Multicast LDP等

Customer

ProviderMPLSで制御した網内ツリー

Customer11

通信網の構造に着目
 カスタマ側ツリー (サービス：UNI)
 IP Multicast, Ethernet

Customer

ProviderCustomer(S1, G1)ツリー(S2, G2)ツリー

ツリーはチャネルの数だけ存在する

中をどう通っているかは不問

12

キャリア網OAMと、サービスOAM
 マルチキャストOAMの２つの区分

キャリア網OAM
 コアツリーに対する監視、障害管理をする。

サービスOAM カスタマツリーに対する監視、障害管理をする。
 サービスはL3 (IP)の場合と、L2(Ether)の場合とがある

13

キャリア網のOAM： MPLS
 概念図

Customer

Provider（MPLS）

Customer14

キャリア網のOAM： MPLS
 MPLSを使うと：Customer

Provider（MPLS）

Customer
P2MP-Ping（障害切分け）

Multicast CV（到達性監視）P2MP-Ping, Multicast CVともにコアツリーの管理ポイントをチェックできる

15

サービスOAM： IPまたはEther 概念図
Customer

Customer

Providersender
ＩＰルータ orEtherスイッチ(S1, G1)ツリー(S2, G2)ツリー

PECE
16

サービスOAM(1/2) IPの場合
 MVPN(Multicast IP-VPN)の場合

IP Pingでやってみると…
ProviderCustomer

Customersender

ＩＰルータ/端末

一見End-Endでチェックできそう。しかし…

IP Ping
ﾏﾙﾁｷｬｽﾄ宛

17

サービスOAM(1/2) IPの場合（続き）
 MVPNの場合の問題点

カスタマ網と事業者網の境界が曖昧PEからvrf multicast pingを撃つと対向エンド端末まで染み出してしまい、カスタマの任意の（S,G）についての障害を、キャリア区間かカスタマ区間かを正確に切り分けられない

ＩＰ端末 Customer

ProviderCustomersender

端末まで突き抜けてしまう

このポイント(PE)が切り分けできない！

IP Ping
ﾏﾙﾁｷｬｽﾄ宛PE発（注） PE のVRF下にloopbackを切りstatic joinさせても、そこで書いた 固定的な(S,G)アドレスしかチェックできない。
18

サービスOAM(2/2) Etherの場合
 VPLSの場合

Ether OAMでやってみると…
Customer

ProviderCustomersenderEtherスイッチ/端末

EthOAM CC（ユーザドメイン）

EthOAM CC（事業者ドメイン）

カスタマ側と事業者網を区別できそう。しかし…

19

サービスOAM(2/2) Etherの場合（続き）
 VPLS（Ether）の場合の問題点

マルチキャストとブロードキャストを区別できない Ehter OAMでは正確なマルチキャストの到達性が分からない。

(S,G)に対するSnoopingの動作確認等で困ることも
Customer

Provider(S1, G1)の到達性

Customersender(S2, G2)の到達性
20

サービスOAM(2/2) Etherの場合（続き）
 技術的な理由：
 Ether OAMのSrc/DstはIEEE予約マルチキャストMACアドレスであって、真の意味でのデータストリームMACではないため
 IPデータ情報（中身）を一切関知しない機構になっているため

sender(S1, G1)の到達性(S2, G2)の到達性
ブロードキャスト化
Ether OAMでは、２つのストリームが区別できない！

EthOAM CC21マルチキャストOAM要件
 サービスOAMについて転送系障害を正しく検知・切り分けできること。
 任意の(S,G) (*, G)に対して確認できること。
 実際のユーザデータと同じ経路を通ること。
 キャリア網内では、極力、実際のユーザデータと同じフォーマットでカプセル化転送されていることが望ましい。
 キャリア内とカスタマ側との区別が明確であること。
特に、PE〜PE間で、カスタマOAMを終端できること（事業者の立場から）

22

まとめ
 マルチキャストOAMの整理

キャリア網のOAM
 P2MP-Ping, Multicast CV（相当）機能の実装が急務

カスタマ側のOAM
 既存のツールでは完全にはカバーできない所も 新技術、もしくは中間解の具体化、実装

ベンダの皆様に期待！

☺
23