MPLSオペレータからの声~Protection機能の運用の現状~
2003/10/20 MPLS JAPAN 2003
NTTｺﾐｭﾆｹｰｼｮﾝｽﾞ（株）
守山 貴庸
t.moriyama@ntt.com
2003/10/20

MPLS JAPAN 2003

＜1＞

t.moriyama@ntt.com

AgendaProtection機能導入の話
MPLS-NW概要
Protection強化の背景
FRRの動作と設計
FRRの導入と効果

今後の展開と課題まとめ

2003/10/20

MPLS JAPAN 2003

＜2＞

t.moriyama@ntt.com

MPLS-NW概要
NTT-Comでは、2000年よりmpBGP/MPLS
VPN(RFC2547bis)によるLayer3のIP-VPNサービスを提供
LDP/TDPベースのMPLSﾈｯﾄﾜｰｸを展開
エッジの数が非常に多い
数万LSPが存在
Stateを持たないLSPによる拡張性の確保

昨年度、Protection機能(FRR)導入を開始
2003/10/20

MPLS JAPAN 2003

＜3＞

t.moriyama@ntt.com

Protection強化の背景(1)
昨今ネットワーク品質(Availability)に対する要求は高まる一方
NWへの依存性拡大に伴う、NW断への危機感の高まり
数秒の通信断でもユーザ申告
今まで避けていたものをVPNに乗せるように成って来た→ ますます故障に敏感に（基幹系→Voice,Video etc.）

トラフィックがアグリゲートされるバックボーンの障害は、影響範囲が甚大
数秒断でも全体のAvailabilityには大きく影響冗長化されていても、故障検知、OSPF迂回、収束を考慮すると数秒断は発生。
2003/10/20

MPLS JAPAN 2003

＜4＞

t.moriyama@ntt.com

Protection強化の背景(2)より多様なケースで。。。
回線障害？
装置障害？

より早く復旧を。。。
異常に気づいて↓措置を考えて↓実行する

- PKG
- 筐体
- ・・・

論理障害？
- Protocol Down
- 不整合
- ・・・

すくなくとも、単純な回線/HW故障は瞬間的な迂回を実現したい！！
（検知されないレベル＝故障とならないレベル）

2003/10/20

MPLS JAPAN 2003

＜5＞t.moriyama@ntt.com

Fast Reroute（Local Repair)
ﾊﾞｯｸﾎﾞｰﾝの信頼性向上策には特に有効？
予め迂回路を用意（Detour-LSP）
Sonet Alarm等により故障を検知
Detour-LSPに迂回（スタック）
Protected LSP(Primary)HE

PLR①FRR(LocalRepair)
MP

TE

Detour LSP
PP
Detour-tunnel
2003/10/20

MPLS JAPAN 2003

＜6＞

Protected-tunnelLDPt.moriyama@ntt.com

Fast Reroute（Local Repair)
RSVPベースの技術
既存はLDPのみ→ そのまま適用できないが。。。
LDP over RSVP-tunnel が使える！
LSPの階層構成の適用・・・本数削減
ﾊﾞｯｸﾎﾞｰﾝだけの適用ならエッジには影響なし
Protected LSP(Primary)HE

PLR①FRR(LocalRepair)
MP

TE

Detour LSP
PP
Detour-tunnel
2003/10/20

MPLS JAPAN 2003

＜7＞

Protected-tunnelLDPt.moriyama@ntt.com

Fast Reroute（Local Repair)
FRR後の動き
Local Repair発生時に、Backup PathへのRe-routeと同時にPLRからHeadendへPathErrによる通知
HeadendではPathErrを受けてGlobal Repairを実施(Primary⇒Secondary)Primaryトンネルを落とさずにSecondaryに切り替えて(make before break)、迂回完了。
- PathErrでGlobal Repairが行われる装置は少ない？？
Protected LSP(Primary)②Global Repair(make before break)HE
PathErr

2003/10/20

MPLS JAPAN 2003

PLR

①FRR(LocalRepair)MP
Detour LSP

P
＜8＞

PTE

Secondary LSP
t.moriyama@ntt.com

Fast Rerouteの設計(1)FastRerouteにもいろいろありますが。
One-to-One or Facility Backup
Facility BackupがStartupとしては容易
もともとRSVPトンネルを意識した運用はしていないので、Link及びNode障害を束で物理イメージで扱う方が運用者の概念としてとらえやすい。
実装が若干多い。

FastReroute起動トリガは? ・・・検知が早くないと意味なし
まずは、SONET Alarmが必須。
その他、RSVP Hello等。

2003/10/20

MPLS JAPAN 2003

＜9＞t.moriyama@ntt.com

FastRerouteの設計(2)FRRの適用範囲とLSP設計概念
まずは中心から。。。
必要に応じて
FRR適応領域をエッジまで拡大

SP MPLS Network
Core
CE

Edge

CoreEdge

Core

LDP

CE

Labeled BGP or
LDP if CsC

VPNv4 BGP
LDP

3階層 Stack or
迂回時4階層 StackCore

FRR Protected Area

Core
Labeled BGP or
LDP if CsC

Core

LDP

RSVP
FRR Backup（LDP over RSVP）

2003/10/20

MPLS JAPAN 2003

＜10＞t.moriyama@ntt.com

FastRrerouteの設計(3)
導入範囲は？
FRR対応 〜 OSも変更か。。。
Tunnelの管理や、オペレータの習熟は大丈夫？

Tunnelの長さは？
長くするか、数珠繋ぎで行くか？
Detour-Tunnelの長さは？
長くすれば本数増大(n!)- トラヒック交流がきめ細かく見れる- でもTunnel管理しきれるのか？ 混乱しないか？

OSPF-Areaを跨げるのか？

張り方はexplicit?
スタックするけど悪影響は？
2003/10/20

MPLS JAPAN 2003

＜11＞

t.moriyama@ntt.com

FastRrerouteの設計(4)FRR後はどうする？
GlobalRepairさせる? FRRのまま放って置く？
故障復旧後は自動で戻す？ 手動で戻す？

計画的な迂回操作はどうする？
短時間断でオペレーション可能な方法は？

LDP/物理IFとの共存関係はどうなる？
Tunnel張ると既存（LDP/物理IF）は使うことが無いのか？
2003/10/20

MPLS JAPAN 2003

＜12＞

t.moriyama@ntt.com

FastRerouteの導入
Default-Routeは通らない？
運用手順は面倒に。。。計画迂回など電話が増えた？

範囲限定していれば、Tun管理は容易だがNWトポロジー次第でしょうが。。。。

心配したTE/RSVP関連の変なトラブルは出ていない・・・・

2003/10/20

MPLS JAPAN 2003

＜13＞

t.moriyama@ntt.com

FastRerouteの効果
伝送路の障害では威力発揮。
概算ですが迂回に1秒はかかっていない。
- 故障箇所によるが数msec〜数百msec- NWエントリによって差がある- リアルタイム利用ユーザにとっても十分か？

正確な迂回時間がコマンドで測れるとうれしいが。。

フラップ故障で副次効果大！
自動で切り戻しさせていないので。。。
2003/10/20

MPLS JAPAN 2003

＜14＞

t.moriyama@ntt.com今後の展開と課題

2003/10/20

MPLS JAPAN 2003

＜15＞

t.moriyama@ntt.com

今後の展開Protection適用領域の拡大。
Protectionカバー範囲をNW全体に。
広くエッジまでFRR機能を自由に使いたい。
- 必要なところに必要なパスを。
- CEまで伸ばせる？

トンネルレベルの使い分け
現在の一律のトンネルからサービスレベルによる複数Tunnelの使い分けへ- COS単位で複数持たせるとか。
- Protectionレベルの使い分けなど。

その他
Multicastはどうする？
Videoユーザにも満足される迂回時間とは？
2003/10/20

MPLS JAPAN 2003

＜16＞

t.moriyama@ntt.com

課題１(InterArea)
OSPF InterArea RSVP
IGPスケーラビリティ及び安定性担保のため、OSPF
Area分けの存在
適用範囲拡大すれば、AreaまたがりのRSVPトンネルは避けられない。
現状、トンネルは張れても、TE DataBaseが共有できないため以下の問題がある。
- Reoptimizationがうまく働かない- ABRのNodeProtectionでRROのNNHOPがうまく取れないなど。
- Inter-ASとも共通な問題が存在。

HE

2003/10/20

MPLS JAPAN 2003

Area X

looseloose

ABR

ABRTE

Area0

Area YP＜17＞

t.moriyama@ntt.com

課題１(InterArea)２
OSPF InterArea RSVP課題解決に向けて
draft-kompella-mpls-multiarea-te-04.txt
draft-vasseur-mpls-loose-path-reopt-02.txt- Tunnel落とさずにERO再計算をABRに要求- Areaの向こう側でBetter Pathが見つかったのがわ

かったら、PathErrをHeadendに通知し、make beforebreakをHead-endで行う。

draft-ietf-mpls-nodeid-subobject-01.txt- ABRのFastReroute Node Protectionの実現

2003/10/20

MPLS JAPAN 2003

＜18＞

t.moriyama@ntt.com

課題２(Reoptimization)
Head-end以外からでもReoptimizatonしたい。
すべてのトンネルはBi-directional。
Reopmizationを行う際にいちいち両側のHead-endからやらなくてはならない。
Tail-endやMid-point LSRからReoptimizationがオペレータ起動できるととっても便利。
Head-endにPathErrを送って、Head-endにPathMessageを出してもらう。
- トンネルを落として切り替えるのではなく、やさしい切り替えを促す。
- draft-vasseur-mpls-loose-path-reopt-02.txtの拡張検討中(Single Areaにも応用)。
2003/10/20

MPLS JAPAN 2003

＜19＞

t.moriyama@ntt.com

課題３(LDP論理障害)
古くて新しい話
LDPセッションだけが切れたら、ブラックホール- そのLinkは使わないで欲しい- IGPルーティング自体を切り替えていい。
- 極端な話インタフェース落としてくれてもいい。

検知方法は？
- 断だけなく、Label不整合もありうる- まずはEnd-End検出(LSP pingその他)でもLocal検出

でもどちらでもよいので。。。

2003/10/20

MPLS JAPAN 2003

＜20＞

t.moriyama@ntt.com

課題４(LSP選択による差別化)
どのパケットをどのLSPに放り込むかの選択を自由に行いたい。・・・・差別化
エッジやCoreエッジで。
COS(EXP)に応じて選択。
ProtectionありLSPに入れる人とそうでない人の選別
選別はDestinationベースだけでなく

2003/10/20

MPLS JAPAN 2003

＜21＞

t.moriyama@ntt.com

まとめProtection機能の導入
Protection強化の背景
FRRの設計FRRの効果

今後の展開と課題
Inter Area
Reoptimize
LDP障害差別化
2003/10/20

MPLS JAPAN 2003

＜22＞

t.moriyama@ntt.com