ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

MPLSとT-MPLSにおけるOAM機能と運用上の課題

2007年10月9日
NTT 太田 宏© NTT 20071

アウトライン
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLS/T-MPLSの標準化概要• T-MPLSのOAM機能• MPLSのOAM機能• MPLSとT-MPLSの相互接続• 課題と今後の進め方について© NTT 20072

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

全体概要© NTT 20073

T-MPLS (Transport MPLS) とは？
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• ITU-T勧告G.8110.1がT-MPLSのアーキテクチャを記述• MPLSの仕様に基づいた、コネクションオリエンテッドなパケットベースの伝達レイヤ技術• 上位レイヤのクライアント信号に依存せず、様々な信号を運ぶことができる• 従来の伝送技術(SDH、ATM等)と同様なOAM機能を具備する• MPLSとは、同一レイヤでは接続されず、接続される場合は、カプセル化を行う。MPLSをT-MPLSでカプセル化する場合と、逆の場合と、両方のケースが規定される。

© NTT 20074

T-MPLSの標準化状況 (ITU-T SG13, SG15)
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

技術分野

勧告番号

概要

アーキテクチャ G.8110.1 T-MPLSアーキテクチャ

OAM

装置実装

標準化状況
2006.11承認済み

Y.1372/G.8113

OAM要求条件

承認手続き中Y.1373/G.8114

OAMメカニズム

承認手続き中G.8121

装置実装

2008.2改訂版コンセ
ント目標

G.8131

リニアプロテクション

改訂版承認手続き中

G.8132

リングプロテクション

2008.2コンセント目標

プロテクション

© NTT 2007

5

MPLSの標準化状況 (IETF)
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

技術分野
アーキテクチャ

OAM

RFC#等

概要

完成年月

RFC3031

アーキテクチャ

2001.1

RFC3032

ラベルスタックエンコーディング

2001.1

RFC3429

OAMパケット特定用ラベル

2002.11

RFC4377

OAM要求条件

2006.2

RFC4378

OAMフレームワーク

2006.2

RFC4379

故障検出(ping/traceroute)2006.2

draft-ietfpwe3-vccv-15

VCCV (Virtual CircuitConnectivity Verification)

ドラフト

draft-ietf-bfdmpls-04

BFD (Bidirectional
Forwarding Detection)

ドラフト

RFC3469

MPLSベースリカバリ機能フレームワーク

2003.2

RFC4090

Fast Reroute (FRR)

2005.5

プロテクション

© NTT 2007

6

T-MPLSのOAM機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

ITU-T勧告Y.1373により、各種OAM機能が規定されている。
機能名（略称）

概要

Continuity Check (CC)

接続性の確認，接続断の検出

Loopback (LB)

オンデマンドでの導通性確認，故障切り分け

Remote Defect Indication (RDI)

上流への故障通知

Alarm Indication Signal (AIS)

下流への故障通知

Test

スループット，パケットロス，ビット誤りの詳細測定

Locked (LCK)

試験中等でサービスが断であることを表示

Loss measurement (LM)

パケットロス測定Delay measurement (DM)

遅延測定

© NTT 2007

7

MPLSのOAM機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• RFC4379– LSP ping/traceroute (オンデマンドでの接続性確認、故障切り分け)• draft-ietf-bfd-mpls-04– BFD (接続性の常時監視、故障検出)• draft-ietf-pwe3-vccv-15– VCCV (PW (Pseudo Wire)の接続性確認)© NTT 20078

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

T-MPLSのOAM機能© NTT 2007

9

T-MPLSのOAM機能(1) – MEP, MIP, MEG
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

T- MPLS Opera tor A

Client Service(e.g. Ethernet)

T- MPLS Opera tor B

Ca 1a
Pa 1a

T- MPLS Channel(TMC)
T- MPLS Pa th(TMP)

Oa 1a

Ob1b

Oa 2aOb2alegend:

T- MPLS Section(TMS)

MEPMIP• OAM機能の適用対象をMEと呼ぶ。
• MEの両端のOAM処理機能をMEP、中間のモニタポイントをMIPと呼ぶ。
• マルチポイント接続に適用するためのMEの集合をMEGと呼ぶ。
ME: Maintenance Entity, MEG: ME Group, MEP: MEG End Point
MIP: MEG Intermediate Point© NTT 200710

T-MPLSのOAM機能(2) – マルチポイントのためのMEG
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

ME
T-MPLS node

• ME自体はポイント・ポイントとして定義される。
• マルチポイントネットワークのOAMは複数のMEを組み合わせて実現する。
• 上記、MEの集合をMEGと呼ぶ。

© NTT 200711

T-MPLSのOAM機能(3) - CC
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• 送信側MEPから定期的にCCパケットを送信し、受信側
では、定期的に受信することで、接続性を確認する。
• 受信したCCパケットのMEG IDをチェックすることで、意図しないMEPとの誤接続、ミスマージ等の検出も行う。

A'A(a) Simple loss of connection

A

A'B

B'(c) Swapped connection

ABA'(b) Misconnection

A
B

A'(d) Mismerging© NTT 200712

T-MPLSのOAM機能(4) - LB
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• オペレーションシステムからのコマンドにより、MEPから、MIPあるいは対向するMEPに対し、LBMパケットを送信。
• 受信したMIPあるいはMEPは、LBRパケットを送信元に返送。
• これにより、指定した区間の導通確認、故障箇所特定を行うことができる。
MEP

LBM

MIP

MIP

MEP

MIP

MEP

MIP

MEP

LBR
MEP

MIP

LBM
LBR

MEP

MIP

LBM
LBR

© NTT 200713

T-MPLSのOAM機能(5) – AIS
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所•••

故障を検出したレイヤの上位レイヤ（例えば、物理レイヤ故障に対応して、直上のLSP）において、故障検出点から下流にAISパケットを故障が継続している間、周期的に送信。
AISを受信したMEPは、LOCを検出してもOSSに故障を通知しない（すでに故障検出点からOSSに通知されているので通知不要であるため）。
これにより、下位レイヤの故障による不要な故障通知を抑止する。
Alarm suppression
Operation support system (OSS)
Report of link defectInsert AIS

AH

B

J
DC

E

FGK

Detection of dLOC + reception of AIS=> Alarm suppression© NTT 2007

14

T-MPLSのOAM機能(6) – その他の故障管理機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• RDI (Remote Defect Indication)– 故障検出を上流に通知• LCK (Lock)– 試験中であることを通知し、不要な故障通知を抑止• TST (Test)– 試験信号を流すことにより、導通確認、品質測定（ビット誤り、パケット損失、遅延時間）、帯域／スループット測定を実施。OSSからのコマンドにより、in-serviceあるいはout-of-serviceで実施する。

© NTT 200715

T-MPLSのOAM機能(7) – 性能管理機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• LM (Loss Measurement)– パケット損失を測定• DM (Delay Measurement)– パケット転送遅延を測定© NTT 200716

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

MPLSのOAM機能© NTT 2007

17

MPLSのOAM機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• LSP ping/traceroute– Ping: オンデマンドで、指定した２点間の導通性を確認– Traceroute: オンデマンドで、指定した２点間の経路を確認• BFD– 常時、２点間の導通性を監視。

• VCCV– Pseudo Wire におけるVC (Virtual Circuit) レベルでの導通確認。適用対象はMPLSに限らない。

© NTT 200718

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

MPLSとT-MPLSの相互接続© NTT 2007

19

MPLSとT-MPLSの相互接続シナリオ例 (1)ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

x

x/MPLS

x/MPLS/T-MPLS

x/MPLS

MPLS OAM

T-MPLS OAMMPLS OAMx

MPLS OAM• この例では、クライアント信号 x (例えばIP) をMPLSとT-MPLSが相互接続された網で伝送する。
• T-MPLS網内では、MPLSパケットがT-MPLSにカプセル化される。
• MPLS網内、およびT-MPLS網を挟んで両端のMPLS網間については、
MPLS OAMが、T-MPLS網内ではT-MPLS OAMを使用© NTT 200720

MPLSとT-MPLSの相互接続シナリオ例 (2)ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

x

x/MPLS

MPLS OAM

x

x/T-MPLSx

T-MPLS OAM

クライアント信号 x のOAM機能で監視• この例では、クライアント信号 x をMPLS網により転送、相互接続点で一旦クライアント信号 x に戻し、その後、x をT-MPLS網で転送する。
• MPLS網内では、MPLS OAMを、T-MPLS網内ではT-MPLS OAMを使用する。
• 通しで監視するためには、クライアント信号 x におけるOAM を用いる必要がある。
© NTT 200721

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

課題と今後の進め方について© NTT 200722

運用上の問題点
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

••

•

•

•

T-MPLSとMPLSは、パケット構造やコードポイント、ラベルによる転送方法等、基本的なメカニズムは共通であるにもかかわらず、相互接続はカプセル化で行うため、実質的には別の技術として運用する必要がある。
T-MPLS用OAMは、故障管理機能、性能管理機能ともに定義されているが、MPLS用OAMは故障管理機能のみであり、また、AIS/RDIに相当する機能がないため、不要な警報を抑止することができないなど、監視機能がT-MPLSとMPLSで異なる。
既存のMPLS網の運用にはT-MPLSのOAM機能は使用できず、TMPLSをサーバレイヤとして使用する部分のみに適用するか、
MPLS網のクライアント信号としてT-MPLSを定義して、そこにTMPLSのOAM機能を適用する必要がある。
いずれの場合も、オペレータは、適用部分により、T-MPLS OAMとMPLS OAMを使い分ける必要があり、また、現状、両者で実現できる保守運用機能は異なるので、運用が複雑になる。
上記の理由から、既存のMPLS網に、T-MPLSを導入していく場合には、導入方法について、十分な考慮が必要となる。

© NTT 200723

標準化上の問題点
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLSの標準化はIETFにおいて、T-MPLSの標準化は、ITU-Tにおいて行われているため、両者の整合性を維持するためには、密な連携が必要となる。
• 密な連携のもとで標準化を進めるために、進捗が遅くなるおそれがある。
• 逆に、標準化促進を図ると、両者の標準の整合性が失われるおそれもある。
• 両者から、相反する要求が出された場合、その解決手順を確立する必要がある。

© NTT 200724

今後の標準化について
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• 現状、G.8110.1は、MPLSとT-MPLSの相互接続は、カプセル化で行うと規定しており、その点からは、別の技術であると認識されていると解釈できる。
• ただし、両者で独立に標準化を進めると、フレーム、コードポイントなどは共通で、別の技術が標準化されるおそれがあり、運用側に混乱を招くおそれがある。
• 長期的には、T-MPLSとMPLSを互換性のある方式として統合し、両者の標準化の成果を広い範囲で利用できるようにすることが望ましい。
• そのためには、IETFとITU-Tが密に連携して標準化を進める必要がある。

© NTT 200725

ITU-TとIETFの連携状況
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

••

•
•

2007年9月のSG15中間会合(Q.12/15、ネットワークアーキテクチャ関連)において、IESGの代表とITU-Tのメンバが今後のT-MPLSの進め方について協議。以下のように、今後は、密に連携して標準化を進めることとなった。
上記会合では、IETFとITU-Tは、今後、MPLSとT-MPLSの互換性、一貫性を維持するため、IETFをMPLSについての唯一の設計責任標準化機関と認識し、また、ITU-Tは伝達網インフラストラクチャについての専門知識を有することを認識した上で、協力して進めることをQ.12/15としてはサポートするとともにSG13およびSG15に勧める、とした。
今後は、ITU-T側とIETF側からそれぞれ専門家を出し、ジョイント検討チームを構成し、整合のとれた標準化を行う。
上記目的のため、必要に応じ、ITU-T側で勧告化を行ったり、IETF側でRFCを作成する。標準化手順は、ITU-T、IETFそれぞれ、通常の手続きとする（ITU-TのAAP、IETFのRFC4929）。

© NTT 2007

26

まとめ
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLSとT-MPLSのOAM機能について概説し、運用上、標準化上の問題点等について示した。
• 標準化については、ITU-TとIETFの連携が開始されたところであり、今後の動向について注目する必要がある。
• 運用については、標準化動向を把握しつつ、混乱のない運用のために、十分な検討が必要である。

© NTT 200727