MPLS JAPAN 2007

パケット伝送実現に向けた OAM 技術～ ITU-T におけるパケットトランスポートの取り組みについて～

09/Oct/2007
栃尾 祐治(株)富士通研究所 ネットワークシステム研究所

お話しすること
 NGN におけるパケット伝送における要求事項
 ITU-T におけるパケットトランスポートの取り組み
 ITU-T におけるパケット関連の勧告
 Ethernet 関連…は割愛します T-MPLS T-MPLS 要求
 G.8110.1 ならびに T-MPLS ネットワークアーキテクチャ
 T-MPLS のメリットと課題
 T-MPLS OAM• OAM ツールの現状• IETF との差分
• 実現にむけた課題

 まとめ2All Right Reserved, Copyright FUJITSU LIMITED 2005

ITU-T における Packet Transport への要求
 IPトラフィックの普及ならびに、NGN活動の本格化ともない、TDM(SDH) 主体のネットワークは、パケットベースのネットワークへの変換が求められている
 ITU-T SG13 で定めたNGN R1 requirements (Y.2201) としては、パケットベースのネットワークとして以下のことを要求
 IPトラフィックを収容でき、Point to Point ならびに、Point to Multipoint

Connectivity 確保できるトランスポートストラタムの実現
 QoS 実現
 OAM 機能の充実化
 Protection (Survivability) の実現
 Interconnectivity

 期待されること より高機能化かつ高信頼性化されたパケットベースのネットワーク
 特にパケットベースの OAM と OAM を用いて実現する、Survivability 実現

3All Right Reserved, Copyright FUJITSU LIMITED 2005

ITU-T におけるパケット伝送の勧告化状況
 主に SG15, WP3 (Optical and other transport network
infrastructures, OTN structure)で担当
 ただし、OAM だけがSG13 Q5 (NGN OAM) で担当

 テクノロジーとしては、Ethernet と T-MPLS が主体
 MPLS も扱うが、現在 SG15 では、T-MPLS に移行
 SG13 では、引き続き (IP/)MPLS も対象になるが伝送には特化していない。

どちらかというと、サービスとしての MPLS に近い

4

All Right Reserved, Copyright FUJITSU LIMITED 2005

ITU-T における活動状況 ITU-T SG15 (+ SG13)におけるパケット関連の勧告一覧

SG15

Q

Ethernet

T-MPLS(IP/)MPLS

Q9

Protection: G.8031, G.8032
Equipment: G.8021

Protection: G.8131, G.8132
Equipment: G.8121

Protection: Y.1720

Q11

Service: G.8011.x
UNI/NNI: G.8012

NNI: G.8112

Q12

Architecture: G.8010, G.pbb-te

Architecture: G.8110.1

Q13

Packet over TDM: G.8261,G.8262, G.8263, G.8264

Q14Management: G.8051,G.8052

Management: G.8151, G.8152

Q5/13

OAM 要求: Y.1730
OAMメカニズム: Y.1731

OAM要求: G.8113/Y.1372
OAMメカニズム: G.8114/Y.1373

Architecture:G.8110

OAM要求: Y.1710, OAM
メカニズム: Y.1711
Framework: Y.1714
他: Y.1712, Y,1713

SG13

Q7/13
Q12/13

Interworking: Y.1415 (MPLS)

Interworking(IW):Y.1415 (Ether), Y.1413(TDM), Y.1411, 2 (ATM),
C-plane IW 他:
Y.1416, Y.1417

その他: QoS(Q4/13, Q16/12): Y.enet, Y.123qos, Y.M/Etraff (traffic and congestion control), Y.racf_mpls
Performance (SG12): Y.1561, Y.ethperf, etc
5

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS Requirements
 T-MPLS: そもそも、どんなネットワーク目指しているのか ITU-T SG15 では要求をまとめ D-plane では以下を規定；
CO-PS (connection-oriented packet switched technology)

複数のネットワーク階層サポート、具体的には• Label stack による階層管理• TCM (Tandem connection monitoring) が該当

運用・管理・制御の共通化 集中 NMS をベースに、分散 C-plane のサポート
→G.8110.1
 同要求における OAMは以下を規定；
コネクション管理ならびにパフォーマンスモニタリングサポート
 障害管理・プロテクションメカニズムのサポート
 IP 機能のないところでのサポート
→G.8113 (要求) & G.8114 (メカニズム)
 参考までに、IETF MPLS (PWE3) の要求は、上下レイヤとは関係なく Path が提供できること i.e. すでにある MPLS ネットワークのデザインに影響なく、MPLS (PW) が上に提供できること
6All Right Reserved, Copyright FUJITSU LIMITED 2005

Transport MPLS (G.8110.1)
 アーキテクチャ勧告 G.8110.1 がいわば基本勧告
Architecture of Transport MPLS (T-MPLS) Layer Network 定義(G.8110.1 の 1章ならびに、6.1 章から抜粋)
 Data Plane のみ (C & M planeは対象外)
• 関連 RFC は 3031, 3032, 3270, 3443,

CO-PS (Connection Oriented Packet Switching) network であること
 Label merge (ならびに ECMP) 非サポート
• CO-PS であるから。(connection はマージしない)
PHP (Penultimate Hop Pop) 非サポート• 理由は、Y.1711 での使用を薦めていないことが発端

Bi-directional LSP: まずは、uni x 2 (uni の組み合わせ)から• 現時点は、結果論的に双方向(行き帰り同じ経路)で LSP が張られていることだけの定義• シグナリングはスコープ外なので、あくまで結果論

TTL: RFC3443 準拠
 Diff-Serv: RFC3270 準拠 (E-LSP, L-LSP 双方サポート)• TTL, DIffServ いずれも、 pipe と short-pipe models をサポートし、uniform は非サポート

ラベル空間: global or per interface 双方をサポート
 OAM :Y.1711 をベースに検討したが、現在は、G.8114 も考慮 Protection switching and survivability: G.8131(liner), G.8132 (Ring) 準拠• Y.1720 はもはや対象外 また、Fast ReRoute は T-MPLS protection という解釈はできない
7All Right Reserved, Copyright FUJITSU LIMITED 2005

Transport MPLS の主な定義 (続き) G.8110.1 の議論を通してのT-MPLS の定義と解釈
 Layer: IP/MPLS とは別 (Disjoint)。IP/MPLS は、Server/Client の関係• 同時に、Control Network (Management/Signaling Communication Network)
からも独立の関係• 現在は MPLS とは peer しないとしているが、Server/Client の関係は、Interworking の観点から再検討必要 Control Plane: G.8110.1 コンセプト外• Control plane 検討開始したばかり、ASON ベース• まずは、ASON (G.8080) をパケットに拡張する作業から開始
 Management Plane: G8110.1 コンセプト外• Q.14/SG15 で、T-MPLS NE management の検討を開始• G.8151: Management aspects of the T-MPLS network element• G.8152: Protocol-neutral management information model for the T-MPLS
network element

8

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLSが考えるそのメリット
 Connectivity の確保と監視機能の提供
CO である MPLS (ベース)からの構築が Packet Transport への第一条件
 T-MPLS としては、Server layerを考慮した管理体系の実現
 さらに、SCN 機能の実装により LSP (connection) 管理のセグメント化実現
 伝送系として、Packet ベース層の提供による伝送装置のしてのflexibility実現• Aggregation を効率した管理• Full mesh の回避 (P-MP の場合のアプリケーションの場合の効率的収容) Robustness の確保
例えば、D-plane ではProtection メカニズムの多様性提供
 以下に示す2 項目もある意味も含まれる
 Data系は IP 非依存化 (C-planeへの集約)
D-plane において、IP 依存の routing に基づく connection 提供を行わない D-plane (Network)の障害を起こすことで、C-plane系に波及することの阻止
 その逆も同様
 Control/management Network分離
ASON拡張により実現することで、protocol independent な provisioning 提供
 C-plane (装置)の障害で、D-plane （Network）に影響を及ぼす危険は回避
 MCN, SCNの提供
• Network operator の選択による自由度向上
9

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS の対 MPLS における課題
 IETF から見た主な課題として
 Ethertype (0x8847) の使用
IETF からの懸念
 MPLS と同じものを使用することになり、プロトコル上での識別が困難、ひいてはミスコネクション時の検出ができなくなる 実は、同様の懸念は、GFP (SDH/SONET)でも生じるのだが、、、
 MPLS との Interconnection
IETF と解決を図る方向で検討は進めるが、まだまだ検討が必要 現在は、MPLS over T-MPLS のマッピングとしては、間に Ethernet をはさむ形でのしか案しか存在しない (G.8110.1 Appendix & IETF PWE3 transport ID) 実は、MPLS(PW) over MPLS も同様の課題を抱えているのだが、、、
 IETF での手続き
RFC4929：Change Process for MPLS and GMPLS Protocols and Procedures
 T-MPLS においても、使用する OAM label =14 (RFC3429) に影響が生じる
 RFC3429 はいずれ修正(追記)要 その他、C-plane (まだ検討開始なのでどういう形で課題が出るかも不明) とか、
DiffServ に関しての具体的な検討が今後の課題
10

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS Layer Architecture G.8110.1 にて、informative であるがSDH like にChannel / Path / Section の定義を行い、階層化の実現を行っている

Client Service

unidir p2p services
bidir p2p services
unidir p2mp services
IndividualBundle1

 T-MPLS C Channel (TMC): Service layer に相当
2

PW モデルでいう PW ラベル

3

 T-MPLS Path (TMP): Network layer trunk に相当
T-MPLS Channel (TMC)

T-MPLS Path (TMP)

4

いわゆる MPLS トンネル

5
T-MPLS Section (TMS)(optional)

 T-MPLS Section (TMS) [Option]:
MPLS section = LSR 間の MPLS link 相当
 この区間でのOAMも定義
Æ Ring Protection で使用97689Termination function
may include one or more
Circuit (PDH, SDH, OTN)
layer termination points

PHY MEDIA

TMS
TMP

TMC

TMP

11All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS OAM Network Architecture 話は、Ethernet OAM でもある Y.1731(IEEE802.1ag)にも該当

 MEG (Maintenance Entity Group)の提供
OAM 管理区間 (OAM packet の起終点間)が属するネットワークの定義
 Inter-Domain (Operator, Provider) 間, End-End (UNI-UNI)での規定
 MEG level の規定
1 LSP 管理区間に対して、複数の管理レベルの形成 例えば MS PW のケースでは PE1 ～ PE3 全区間の管理に加え、PE1 ～ PE2, PE2 ～ PE3の管理が必要になる。但し、ラベルスタック上での区別ができないので、MEG level を規定し、それぞれを管理する (下の図参照)
 Tunnel でも同様に特定区間の管理を規定する際に、TCM を設置の上、階層化を実現
 MEG level coding は後のページ参照
 MEP, MIP と呼ばれる管理点の規定
End point (MEP: 矢印) だけでなく MIP (中間点: 丸印) を規定。MIP は Loopback, Link
Trace 系にのみ使用

Labelstack

PE2

PE1

PE3

MEL level =1

PW
MEL level =0 (for PW1)TCM

MEL level =0 (for PW2)

TCM

Tunnel#1
12

All Right Reserved, Copyright FUJITSU LIMITED 2005

ITU-T T-MPLS OAM の変遷
 T-MPLS OAM をどう定義するかというのは大きな案件であったが、複雑な事情で複数の勧告に定義が記載
 2005年12月の SG15 (+ SG13) 中間会合で Y.1711 ベースにするということがAlcatel (当時) の主張により合意


Alternative (比較対象) は、LSP ping, MPLS BFD

 2006年01月、SG13 本会合で新展開
Y.1731 (Ethernet OAM) コンセント Y.1731 ベースに、T-MPLS OAM 拡張するべきという提案を富士通から起こす(ALU との 15カ月にわたる論争の始まり)
 2006年2月、SG15 本会合にて、Y.1711 ベースに、G.8112 (T-MPLS NNI勧告) に記載し、コンセント。(Version 0)
この OAM ツールを、G.8112/Y.1711 と複数の勧告を結んだ表現をすることがある。
 IP (LSR ID + LSP ID )に関する定義を行う TTSI に関しては用いない or 曖昧(FFS) 2006年4月、 SG15 (+ SG13) 中間会合にて、Y.1731 ベースに T-MPLS OAMの拡張を合意 2007年4 月、 メカニズム勧告 G.8114 (ex Y.17tom) と 要求勧告 G.8113(Y.17tor) コンセント。G.8114 を Version 1 と呼ぶここともあり
 つまり T-MPLS OAM にはG.8112 定義 (ver0) と G.8114 定義 (ver1) が存在
13All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS OAM Format
 Format の基本構成は G.8112, G.8114 共通
Label: Y.1711 (+ RFC3429) に乗っ取り、Reserved label の 14
 EXP: G.8114 に関しては、 MEL level を encoding• Y.1711 の将来の機能によって異なるcodingされる可能性があるということと、そもそもExperimental use (RFC3032) を勘案した結果

Function Type: OAM 機能の定義
 Version: G.8112 は 0 (と見なし), G.8114 で定義したものは 1 となる
 Flag: OAM PDU 依存
 BIP-16/TLV: Y.1711 の名残をもつ G.8112 はBIP-16 を有するが、G.8114 では、互換性を維持しTLV を定義• G.8112 生成の BIP-16 は、G.8114 対応装置受信においては無視する

Function Type

Label

EXP

S

TTL

Label (14)EXP(MEL)

S=0

TTL

Reserved(000)Version(0 or 1)

Flag

Reserved / TLV offset

OAM PDU payload area
BIP-16 / End TLV
赤字は、G.8114 定義機能

14

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS OAM Network Architecture Y.1731 で取り入れたMEG level の実装方法・動作は、Y.1731と異なる
 OAM alert label の EXP (Experimental) のincrement/decrement による管理

+1 以上の EXP には反応しない (Operator網内は、Transparent)
EXP で、問題があることが判明したら、PDU に同様のincrement/decrement fieldを移植

MEL=1transparent

TCM

MEL=0

TCM

aMEL=0

A

MEL=0

B

b

Bb 参考: FJ は Y.1731 で導入した MEG level field と同様の方式を提案したのだが、、、••

Ethernet OAM (Y.1731) の互換性で優位
Misconnection で MEG level が正しく動作しない危険性があり?

MEL=7

TCM

transparent

MEL=4TCM

a15

A

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS OAM (ver.0): G.8112/Y.1371
 Y,1711 は、IP/MPLS ベースの OAM として勧告化 (2004年)
 Y.1711 ベースに T-MPLS 向けに定義したのが、G.8112
 OAM alert label 14 を定義 (RFC3429), bottom stack 機能としてはCV/FFD, FDI/BDI のみが存在CV: connectivity verification (1s), FFD: Fast Fault Detection は CV の高速かつ周期可変版
 FDI/BDI: Forward/Backward Detect indicator T-MPLS OAM として G.8112 で再定義した際に、Y.1711 で定義した TTSI はいずれも機能 もとのY.1711 と異なる
CV: FFS (G.8114 定義の MEG/MEP 等の記載)
 FFD: FFS: (未来永劫未定義のまま ?) FDI/BDI 使用しないT-MPLS OAM Header
Label14[octet] 1FTCV01

EXP S

TMPLS Tunnel header

TTL000 1 0x01

OAM Payload Fields

320182Res (0x00)

LSP TTSI

Padding (0x00)

BIP16

FFD1FT07

3201172Res (0x00)

LSP TTSI

Frequency

Padding (0x00)

BIP16

FDI

1 1
FTRes
02

BDIFTRes
03

220

4142DT

LSP TTSI (optional)DL

Padding (0x00)

BIP16

DT

LSP TTSI (optional)DL

Padding (0x00)

BIP1616All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS OAM (ver.1): G.8114/Y.1373
 G.8114 検討にあたっては、以下のことを念頭に進めた
G.8112 Interworking (Backward Compatibility) の確保
 差分機能または、 G.8113 (Requirement)で定めた機能を、Y.1731ベースで実現 よって、G.8114の体系は以下の通り
G.8114
G.8112 (2006) /Y.1711(Y.1731 既存)
PDU長維持Type値保持CVv0
FFD

Y.1731 のFlag(freq)に融合

FDI
BDI

Y.1731
CCM 導入Version field:0Æ1

CVv1(CC)+

FDI

Loopback
Connection trace (ÅLink trace)LM (Loss measurement)
DM (Delay measurement)
APS (Linear, Ring), LCK
TST, EXE,
Vender Specific(新規)

MCC (management communication channel)
SSM (Synchronize status message) → 実現性は低い
CSF (Client signal fail) : 上位サービスレイヤの警報通知

Y.1731 のFlag(RDI)に融合17

All Right Reserved, Copyright FUJITSU LIMITED 2005

T-MPLS OAM tools CV(CC), FFD: 周期的送信 (FFD は G.8114 には含まれない) FDI(, BDI): 警報転送・通知 (前方(F)・後方(B)通知)

BDI は、G.8114 には含まれず、CV(CC) に含まれるRDI を使用する形を想定

 LB (Loopback):
LSP 上での loopback. Bidirectional での適用前提
 Y.1731 同様で、中間(MIP) Node 含め、ターゲット装置アドレス指定。ノードで該当ヒットしたら折り返し Connection Trace または Link Trace:

詳細は未検討。アーキテクチャで P-MP が定まってから本格検討

 PM (Delay Measurement, Frame Loss Measurement):
Y.1731の思想の transfer で枠組みのみ
 DM: one-way と two-way が存在。 One-way は両端でのクロック同期が確立した環境が前提
 FLM: 両端測定の dual end と片側測定のsingle end の二種類が存在• Dual End は CV 機能の延長で使用

 APS:
Protection (Linear, Ring) で使用。

 その他、MCC (Management Communication Channel), CSF など


T-MPLS SSM (Synchronous status message) の定義もあるが、実現性は無いに等しい
18

All Right Reserved, Copyright FUJITSU LIMITED 2005

IETF MPLS OAM との関係
 IETF tools (LSP ping MPLS BFD) と比較して
 G.8114 から見ると
IP independent• 要求の通り、IP機能無でも動作することが前提

C-plane independent であること• D-plane でソリューション (=Transport 層に特化)を提供する

マルチレイヤ構成・マルチキャリア(セグメント)構成• ITUは、TCM or MEL でこの問題を解決の方向• IETF tool では MS PW でもどう実現するかが課題である



警報転送機能の定義• FDI のみでなく、上位レイヤの警報転送 (SDH の GFP で規定している CSF相当)も規定• pwe3-oam-mapping を実現できる機能を定義している点は、PWE3 としても注目したい

OAM による障害検出条件の明確化・細分化• ドラフトを読む限り、BFD は、LOC の検出についてはあるものの Mismerge(Misconnection) の検出について明確に規定がない• 下位レイヤの検出との関係

Performance Monitoring 機能の定義
 Protection (APS) の定義
• トリガ条件も含め、Work/Protection の管理は、G.8114 で完成している

19

All Right Reserved, Copyright FUJITSU LIMITED 2005

IETF MPLS OAM との関係
 一方で、G.8114 でできないことで IETF でできていること
LSP ping D-plane vs. C-plane verification• 具体的には、LSP ping 相当の FEC 確認など
G.8114 はもともとC-plane independent なので当然といえばそれまであるが
 T-MPLS ではReturn path の定義が厳密には無いため、Loopback,Linktrace (Connection trace), BDI は使用できるケースが少ない
BFD
 Path operation の宣言を、OAM パケットで行うことができる
 C-plane verification
 周期のダイナミックな変更• そもそもその必要性はトランスポートにあるのかどうかは要議論
 Security: 外部からの、不用(悪意)な OAM packet は裁かず(廃棄しないで)に、トランスパレントに処理する• Transport の観点として、廃棄するか・透過するかどっちがいいのか…?

20

All Right Reserved, Copyright FUJITSU LIMITED 2005

実装にむけた課題
 Common (or Architecture) Label 14 を識別することが前提なので、トップラベルが S=0 のパケットは必ず次のパケットを認識する必要があり
 Top Label =14 の処理 (TMS (section) OAM 実装時)
 MEG level coding (+ TCM)の実装• MEG level increment/decrement• 対向となる MEP - MEP をどう初期設定するかが課題 。マネージメント以外で実現できる手法があるか。誤設定をどう避けるか• MEG level 処理を用いないことも手ではあるが、その場合、MS-PWに見られる警報通知の水平展開処理 (i.e. S-PE での PWs 処理) は要考慮
Labelstack

PE1
T-PE

PE2
S-PE

PE3
T-PE

MEL level =1

PW
MEL level =0 (for PW1)TCM

MEL level =0 (for PW2)

TCM

Tunnel#1

21

All Right Reserved, Copyright FUJITSU LIMITED 2005

実装にむけた課題
 CV
IP/MPLS の環境でも導入は可能 最大の課題は、1 port/IF で多くの connection 数 and/or ミリ秒orderを処理すること• この話は、Y.1731 (Ethernet) でも BFD でも共通
Multicast 処理をしない分や、Y.1731 に比べるとまだまし?
BFD は Demand mode でこそ双方向での適用が可能だが、周期管理など処理が煩雑

LOC (周期 x 3.5 未受信) の場合と、ミスマージ系検出での処理• データを止めない LOC、データを止めるミスマージ

MEG, MEP ID 定義ルール (cf BFD: My & Your Discriminator)

 FDI, RDI

下位レイヤの障害をもとに、該当する connection (LSP) に、FDI をどう挿入するか• 中間ノード (LSR) でも Path 管理が必要であるとともに、下位レイヤとT-MPLS レイヤの関連づけ (i.e. Server/T-MPLS adaptation の定義) が必要



FDI, RDI 受信時におけるさらに上位レイヤへのアラームエスカレーション• つまり、T-MPLS/T-MPLS adaptation の定義。この概念は、IP/MPLS では存在しない



FDI, RDI, AIS は ITU-T 的には Protection のトリガにはならない点注意

 Loopback

双方向connection 上での、Source ならびに Destination Address の定義

22

All Right Reserved, Copyright FUJITSU LIMITED 2005

まとめ
 パケットトランスポート実現にむけては、高機能化かつ高信頼性化が必要で、OAM は重要な位置づけである
 ITU-T におけるその取り組み
 Ethernet: Y.1731, G.8031, G.8032 etc
 T-MPLS: G.8110.1, G.8114, G.8131, G.8132 etc

 T-MPLS ならびに T-MPLS OAM
 T-MPLS 要求
 G.8110.1 ならびに T-MPLS ネットワークアーキテクチャ
 T-MPLS のメリットと課題
 T-MPLS OAM• OAM ツールの現状• IETF との差分
• 実現にむけた課題

23

All Right Reserved, Copyright FUJITSU LIMITED 2005

24

All Right Reserved, Copyright FUJITSU LIMITED 2005