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

MPLS-TPのOAM機能についての標準化動向

2008年10月28日
NTT 太田 宏© NTT 20081

アウトライン
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLS-TPの標準化経緯• ネットワークのOAM機能
ネク機能• MPLS-TPでのOAM機能実現
MPLS TPでのOAM機能実現• 課題と今後の進め方© NTT 20082

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

MPLS-TPの標準化経緯© NTT 2008

3

MPLSの基本標準の成立 – 2001/2002年 – IETF
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• 2001年から2002年にかけ、IETFにおいて、MPLSの基本 なる本となるRFCが成立。
成 。
– RFC3031: MPLSアーキテクチャ (2001/1)– RFC3032: MPLSラベルスタックエンコーディング (2001/1)– RFC3209: RSVP-TE (2001/12)– RFC3270: DiffServ (2002/5)© NTT 2008

4

MPLS OAMの標準化 – 2002/2003年 – ITU-T SG13
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• IETFにおけるMPLSの標準化進展に対し、ITU-T SG13において、MPLSお、OAM ((Operationpand Maintenance;;保守運用機能) の必要性が認識され、2000/11より、検討開始– Y.1710: MPLS OAMの要求条件 (2001/7)– Y.1711: MPLS OAMのメカニズム (2002/11)• 故障検出機能 (CV)、故障情報伝達機能(CV) 故障情報伝達機能 (FDI/BDI) を定義– RFC3429: IETFとITU-T SG13の連携により、MPLS OAM用パケットの識別のためのラベル番号 (OAM Alert Label (=14)) を定義 (2002/11)– Y.1720: MPLSにおけるパス切替機能 (2003/4)© NTT 20085

T-MPLSの標準化 – 2006年 – ITU-T SG15
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• ITU-T SG13/SG15におけるMPLSの標準化進展に伴い、上位、下位レイヤから独立したレイヤ 伝送技術として、上位、下位レイヤから独立したレイヤ２伝送技術として、Transport MPLS (T-MPLS) の検討が開始された。
– G.8110.1: T-MPLSアーキテクチャ (2006/11)• イーサネット OAMの標準化の成果を取り入れ、既にY.1711として標準化済みのMPLS
済OAMをT-MPLSOAMとして高度化することが提案され、その標準化が開始された (2006/4)。
(2006/4)– ドラフトG.8113 (T-MPLS OAMの要求条件)、ドラフトG.8114 (TMPLS OAMのメカニズム)) として勧告化が開始されるが、後に中断。

© NTT 2008

6

IETFとITU-Tの連携(1) – 2007年 – シカゴ・シュトゥットガルト合意
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• ITU-TにおけるT-MPLSの標準化に対し、IETF内では、MPLSと互換性のない技術がMPLSの名の下に標準化さ互換性 な 技術
名 下 標準化されることを憂慮する意見があり、2006年中頃からリエゾンによる意見交換がなされてきたが、早期解決を図るため
め、2007年7月のIETF-70会合（シカゴ）において、IETF、年 月会合（シカゴ） お
ITU-Tの役職者が会合を開き、今後、連携し、整合のとれた標準化を進めることを確認。
れた標準化を進めることを確認• さらに、2007年9月のITU-T SG15中間会合 (Q.12、シュトゥットガルト) において、ITUにおいて ITU-T
T、IETFの専門家による協IETFの専門家による協議が行われ、ここでも、連携した標準化推進を確認した。

© NTT 2008

7

IETFとITU-Tの連携(2) – 2008年 – JWT立ち上げ
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所•

2008年1月のITU-T SG13会合において、T-MPLS OAM関連勧告草案である G.8113 (要求条件)、G.8114 (メカニズム) が、承認手続きに付される予定であったが IETFから 多数の参加があり 意見きに付される予定であったが、IETFから、多数の参加があり、意見がまとまらず、勧告化が中断された。
– G.8113は、informationalな文書である、「supplement」として承認された••

2008年2月のITU-T SG15会合においては、上記の事態を考慮し、T-MPLS関連の勧告草案の承認を凍結し、IETFとの連携関係の明確化を図ることとなった。
確化を図ることとなった
上記会合において、IETFの役職者、専門家を招いて審議を行い、今後、IETF、ITU-T双方からの代表者による検討チーム JWT (JointWorking Team) を立ち上げ、連携の方法等を検討することとした。
を立ち上げ 連携の方法等を検討することとした© NTT 2008

8

IETFとITU-Tの連携(3) – 2008年 – JWTの結論
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• JWTの結論として、ITU-T、IETFで連携して標準化を進めることとなった。具体的には、IETFにおいて、伝達レイるな た。具体的 は、お、伝達 イ
ヤとしての要求条件の明確化を行い、必要があればMPLSを拡張する、というスタンスで検討していくこととな たなった。
– 技術は、MPLSであり、使い方がトランスポート向け、という位置づけとなるため MPLS-TPづけとなるため、MPLS
TP (Transport Profile) と呼ばれる。Tと呼ばれる TMPLSという用語は使用しないこととなった。
– ITU-Tで作成を進めてきたT-MPLS OAMなどのドラフトの今後の扱いは 現時点では不明である
扱いは、現時点では不明である。

© NTT 2008

9

MPLS OAMパケット識別用ラベル (14)について
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• IETF-71会合(2008/3)後、OAM Alert Label (14)について、Y.1711の使用状況を調査し、使用されていなければ、、使用状況を調査し、使用されなければ、別用途に転用することを検討した。
• IETF mpls WGおよびITU-T (Q.5/13)で調査したところ、複数社により既にインプリされており、転用は無理との結論となった。
• MPLS-TP用に別にラベル特番(13)を定義し、今後規定義後されるOAMおよびその他の拡張機能については特番(13)を用いることとなった。
(13)を用いることとなった© NTT 2008

10

IETF-72での動向 – 2008年 – MPLS-TP初期ドラフト
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• JWTの結論に従い、IETFにおいて、MPLS-TP要求条件、フレームワーク、OAM要求条件等の関連ドラフトの作成
ワ ク、要求条件等 関連 ラ作成が開始された。
• ドラフトのWG item採択時、ラストコール開始時など、節目ごとに、ITU-Tにリエゾンを送付し、連携を図ることとなった。
• 現時点では、要求条件、フレームワークの検討が中心で、メカニズムについての検討は、要求条件が明確化され、必要性が認識された後に開始される予定である。
必要性が認識された後に開始される予定である© NTT 200811

（参考） MPLS-TP関連ドラフト
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

タイトル

ファイル名

MPLS-TP Requirements

draft-jenkins-mpls-mpls-tp-requirements-00

A Framework for MPLS in Transport Networks

draft-blb-mpls-tp-framework-00

Requirements for OAM in MPLS Transport
Networks

draft-vigoureux-mpls-tp-oam-requirements-00

MPLS-TP OAM Analysis

draft-sprecher-mpls-tp-oam-analysis-02

Multiprotocol Label Switching Transport Profile
Survivability Framework

draft-sprecher-mpls-tp-survive-fwk-00

MPLS TP Network Management Requirements

draft-gray-mpls-tp-nm-req-01

Assignment
gof the Generic AssociatedChannel Header Label (GAL)

draft-vigoureux-mpls-tp-gal-00
gp pg

MPLS Generic Associated Channel

draft-bocci-pwe3-mpls-tp-ge-ach-00

Operating MPLS Transport Profile LSP inLoopback Mode

draft boutros mpls tp loopback 00
draft-boutros-mpls-tp-loopback-00

JWT Report on MPLS Architectural
Considerations for a Transport Profile

draft-bryant-mpls-tp-jwt-report-00© NTT 200812

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

ネットワークのOAM（保守運用）機能© NTT 2008

13

OAM (Operation and Maintenance) 機能とはﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所•

ネットワークの運用状態を把握し、故障、性能劣化を検出する以下の機能– 性能監視– 故障検出– 切替– 故障情報の伝達
故障情報 伝達– 故障箇所の特定•

これまでの伝送技術（PDH、SDH、ATM、OTN等）において、ネットワーク構成のための基本技術として実現しており、MPLS網、IP網、イーサネット網においても、キャリアクラスの網機能を実現するためッ 網 おも、キャリ クラ網機能を実現するに、OAM機能の実現が期待されている。

© NTT 2008

14

OAM機能(1) – 性能管理機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所••

ATM、MPLS、イーサネット等のパケットベースの伝送技術においては、パケット損失および伝送遅延が代表的な性能の指標とされており れら 監視 測定機能が検討され きたり、これらの監視、測定機能が検討されてきた。
基本的なメカニズムとしては、測定を行う区間の送信側で、送信パケット数、送信時刻等のデ タを搭載した測定用の ケットを挿入し、ケット数、送信時刻等のデータを搭載した測定用のパケットを挿入し、受信側では、受信パケット数と受信した測定用パケットのデータおよび受信時刻から性能を測定する。

性能測定用パケットを挿入

受信した性能測定用パケットと、受信ユーザパケットから性能測定© NTT 2008

15

OAM機能(2) – 故障検出機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所••

ATM、MPLS、イーサネットにおいて、故障検出機能を実現するメカニズムとして、送信側から定期的に故障検出用パケットを送信し、受信側では、定期的に受信することで、接続性を確認する方法が用いられている (CC: Continuity Check機能)。
受信した故障検出用パケットの情報をチェックすることで、意図しない送信元との誤接続、ミスマージ等の検出も行うことが可能である。

A'A(a) Simple loss of connection

AA'B

B'(c) Swapped connection

ABA'(b) Misconnection

ABA'(d) Mismerging

Continuity Check機能の動作例© NTT 2008

16

OAM機能(3) – 切替機能
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• SDH、ATM、MPLS、イーサネット等の技術では、故障発生時に予備経路に切替える とで、故障時のサ時に予備経路に切替えることで、故障時のサービス中断を中断を回避するメカニズムが用いられている。
現用経路

故障時に切替、サービス中断を回避

予備経路

パス切替機能の構成例
ス切替機能の構成例© NTT 2008

17

OAM機能(4) – 故障情報通知
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所•••

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

AH

B

J
DE

FGK

CDetection of dLOC + reception of AIS=> Alarm suppression

AISによる故障情報通知の例© NTT 2008

18

OAM機能(5) – 故障箇所の特定ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• 故障区間特定のため、オペレーションシステムからのコマンド
により、あるポイントから、折り返しポイントを指定し、パケットを送信し、指定した区間の導通確認、故障箇所特定を行うことができる。

Loopbackパケットによる故障箇所の特定例
パケ トによる故障箇所 特定例© NTT 200819

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

MPLS-TPでのOAM機能実現© NTT 2008

20

OAM機能として必要な要素
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLS-TPとしての以下の機能の実現方法– 性能監視– 故障検出– 切替– 故障情報の伝達– 故障箇所の特定© NTT 2008

21

性能監視
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• 現在、MPLSにおいて、パケット損失を測定する機能は定義されていない。LSP定義されな 。
pingにより遅延時間の測定は可pg より遅延時間 測定は可能であるが、LSP pingはIPレイヤに依存するため、IPレイヤに依存しない機能を新たに定義することが提案されている。
る• 勧告草案G.8114で検討されていたDM (DelayMMeasurement)、LMt) LM (Loss(LMMeasurement)t) 機能の利用も考えられる。

© NTT 2008

22

故障検出
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLSにおける故障検出機能として、BFDが定義されているが、検討中のMPLS
る 、検討中TP OAM要求条件を満たさない要求条件を満たさなので、以下の拡張が提案されている– IPに依存せずBFDパケットを転送するメカニズムの定義– 誤接続の検出などに対応するための網全体でユニークな識別子の定義• 勧告草案G
勧告草案G.8114で検討されている
8114で検討されている CC (ContinuityCheck) 機能の利用も考えられる。

© NTT 200823

切替ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLSにおいては故障端で切替を行う方式として、FRRが定義されている。
定義される。
• そのほか、パス端で切替を行う方式として、G.8131で定義されているリニアプロテクション、勧告草案G.8132で検討されているリングプロテクションの利用も考えられる。

© NTT 200824

故障情報の伝達
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• MPLSにおいては、故障情報の伝達機能は定義されていな 。
ない。
• 勧告草案G.8114で検討されている AIS (AlarmIndication Signal) 機能の利用も考えられる。

© NTT 200825

故障箇所の特定ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• LSP pingの、Traceroute機能により故障箇所の特定が可能であるが、LSP可能ある 、pingはIPレイヤに依存するため、pgはイヤ 依存するた 、MPLS-TPの要求条件を満たさない。そのため、IPレイヤに依存しないトレース機能の検討が望まれる。
• 故障箇所の特定手段として、ループバック機能の利用も考えられる。勧告草案G.8114で検討されている LB(L(Loopback)b k) 機能は、IP非依存であるので、この利用も機能は IP非依存であるので この利用も考えられる。

© NTT 200826

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

課題と今後の進め方© NTT 2008

27

IETFにおけるMPLS-TPの標準化推進
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所••••

現在議論中のドラフトに基づいた、要求条件の明確化
既存メカニズムの適用方法の明確化
既存メカニズムでカバーできない領域についての拡張
IP非依存のOAM機能の拡充© NTT 2008

28

IETFとITU-Tの連携
ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所• ITU-Tにおける、既に承認済みのT-MPLS関連勧告の扱いの明確化
明確化• OAM等、承認プロセスが中断している勧告草案の扱いの明確化• ITU-Tで検討済み成果（OAM、切替機能、装置アーキテクチャ、ネットワークアーキテクチャなど）の今後の活用© NTT 200829

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

技術分野
アーキテクチャ

OAM

RFC#等

概要

完成年月

RFC3031

アーキテクチャア
キテクチャ

2001 1
2001.1

RFC3032

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

2001.1

RFC3429

OAMパケット特定用ラベル

2002.11

RFC4377

OAM要求条件

2006.2

RFC4378

OAMフレームワーク

2006.2

RFC4379

故障検出( i /故障検出(ping/traceroute))2006 2
2006.2

RFC5085

VCCV (Virtual Circuit
Connectivity Verification)

2007.12draft-ietf-bfdmpls-07

BFD (BidirectionalForwarding Detection)

RFC Queue

RFC3469

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

RFC4090

Fast Reroute (FRR)

2005.5

プロテクション

© NTT 200830

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

ITU-T勧告草案G.8114では、以下のOAM機能が検討されていた。なお、本勧告草案は、2008年1月のITU-T SG13全体会合において、勧告化が中断されている。

機能名（略称）

概要

Continuity Check (CC)

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

Loopback (LB)

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

Remote Defect Indication (RDI)

上流への故障通知

AlAlarmIIndicationdi ti Si
Signall (AIS)

下流 の故障通知
下流への故障通知

Test

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

Locked (LCK)

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

Loss measurement (LM)

パケットロス測定

Delay measurement (DM)

遅延測定

© NTT 200831