MPLS VPNの現状- MPLS TEを導入して KDDI株式会社
熊木 健二
ke-kumaki@kddi.com
2003/10/20

MPLS JAPAN2003

1

はじめにz MPLS網で実現しているサービス– L2VPN• 広域ethernet VPN– L3VPN• Intra-AS VPN• inter-AS VPN （他キャリアとの相互接続）– L2VPN <-> L3VPN （相互接続）
LDP、TDPで全て実現してきた
2003/10/20

MPLS JAPAN2003

2

MPLS TE導入への経緯

2003/10/20

MPLS JAPAN2003

3

MPLS網サービスの方向性
z MPLS網を使用したサービスも早3年が経過– ユーザからの視点が既に変わってきている• 繋がればいい → 安定性重視• edgeだけのQoS → end-to-endのQoS– voice等のtrafficは保証していない →voice等のtrafficの保証• サービス種類：少数 → サービス種類：多数– いろんなedge routerが必要になる → 問題も増える

ネットワークが高品質でないといけない
2003/10/20

MPLS JAPAN2003

4

品質とは
z 現状の尺度– SLA• 国内の場合：網内遅延(平均値35ms)、稼働率（99.9%)、障害通知30分目標、、、• 国際の場合：網内遅延（対地毎）、稼働率（99.9%)、、、これだけで品質をはかるのも。。。
MPLS TE導入前はせいぜいこの程度これからは他の要素が必要なのでは。。。
2003/10/20

MPLS JAPAN2003

5LDP（TDP）からの一部脱却
z backboneの高可用性・高信頼性– IGPに依存して切り替わります– IGPだけでも頑張れるが– HW/SWの障害の場合は高速なプロテクションが必要

z voice等のmission criticalなapplicationへの対応– backboneはジャブジャブ
– CoreでのQoSはなかった

帯域保証が必要z L2VPN traffic、L3VPN trafficの分離– IGPに依存したら同じパス通る– trafficの特性が明らかに異なる
2003/10/20

MPLS JAPAN2003

明示的なパスが必要
6

MPLS TE導入のメリット– 高可用性、高信頼性• FRR(link protection,node protection,pathprotection) etc– ネットワークリソースの最適化• Reoptimization• Bandwidth control• Traffic control (explicit path etc) etc– 帯域保証• DS-TE etc
2003/10/20

MPLS JAPAN2003

7

MPLS TE導入のメリット （続）z POP間Trafficの状況把握– 緻密なtraffic engineeringが可能– 回線増強計画がしやすい

2003/10/20

MPLS JAPAN2003

8

MPLS TE設計の話

2003/10/20

MPLS JAPAN2003

9

MPLS TEの設計
z TEの適応範囲– P router– PE routerz トポロジー– single area
– multi areaz TE tunnelの張り方– full mesh– partial meshz 帯域の設計等
2003/10/20

MPLS JAPAN2003

10MPLS TEの設計（続）z Primary tunnel– Metric• TE metric• IGP metric– Path• dynamic• explicit– Setup priority/Hold priority– bandwidth– Fast reroute– Record route 等のparameterがある
2003/10/20

MPLS JAPAN2003

11

MPLS TEの設計（続）z Backup tunnel– Link protection• どのlinkをprotectionするのか– 明示的に決める– dynamic (exclude option)– Node protection• どのnodeをprotectionするのか– 明示的に決める– dynamic (exclude option)
2003/10/20

MPLS JAPAN2003

12

MPLS TEの設計（続）z Scalability– Primary tunnel #本• full mesh : Rn*(Rn-1) （Rn:routerの数）– Backup tunnel• Link protection(NHOP tunnel) #本– Rn*D （D:routerが持つリンクの平均数）• Node protection(NNHOP tunnel) #本– Rn*D*(D-1)• Path protection #本– Rn*(Rn-1)
2003/10/20

MPLS JAPAN2003

13

運用の話

2003/10/20

MPLS JAPAN2003

14

今までの運用z Router configについて– TE LSPの設定はなかった• シンプル2003/10/20

MPLS JAPAN2003

15

今までの運用
z backbone traffic– interface毎のMIBを収集• Pathという概念はなかった• Trafficのfrom/toが正確にわからない• Per HOP trafficのみの統計

POP間のTraffic managementが不可能

2003/10/20

MPLS JAPAN2003

16

今までの運用（続）z 障害時– Link障害• OSPF依存– Node障害• OSPF依存
通常秒オーダーでの時間

2003/10/20

MPLS JAPAN2003

17

現在の運用z TE LSPの設定がとにかく大変– primary path,backup pathの数
z backup pathの設定落ちがないか– 確認するだけでも結構大変

バックボーン再構築時（ノードやリンクの拡張時）

2003/10/20

MPLS JAPAN2003

18

現在の運用（続）z backbone traffic– LSP毎のMIBを収集• Pathという概念ができる• Trafficのfrom/toが正確にわかる• LSP毎のTraffic量が正確に取れない場合がある
POP間のTraffic managementが可能になってきた
POP間の回線増強計画が立てやすい
さらに緻密なtraffic engineeringが可能になる
2003/10/20

MPLS JAPAN2003

19

現在の運用（続）z 障害時– Link障害• Link protectionが動作• Node protectionが動作– Node障害• Node protectionが動作
msec単位で切り替えが可能

2003/10/20

MPLS JAPAN2003

20

現在の運用（続）z Ｌink protection + reoptimization
Path error message
Link down

HEに送る

PLRMPTEHE

2003/10/20

MPLS JAPAN2003

21

現在の運用（続）z Node protection + reoptimization
Path error message
Node down

HEに送る

PLR
MP TEHE

2003/10/20

MPLS JAPAN2003

22

現在の運用（続）z EROの利用方法– 明示的なパスが確認可能• MIBからEROを取得することでTE-LSPを視覚的に表示できるz RROの利用方法– Pathに対するlabelが確認可能• NHOPに対してpushするlabelが確認できる• NNHOPに対してpushするlabelが確認できる
2003/10/20

MPLS JAPAN200323

現在の運用（続）z LSPのreoptimization– FRR後– Timer base– manual– event-driven

2003/10/20

MPLS JAPAN2003

24

現在の運用（続）z TE LSPの確認– control plane,data plane• per routerでのcheck• LSP ping,traceroutez L2/L3 VPNの場合はやはりVPN labelからの確認になる– L3:traceroute vrfが便利– L2:IETFで標準化中
MPLS OAMの実運用が望まれる
2003/10/20

MPLS JAPAN2003

25

運用での問題点
z Link protection path

– LSPに対して正常に動作するかの確認• 現状はrouterで1つ1つcheckしている

z Node protection path

– LSPに対して正常に動作するかの確認• 現状はrouterで1つ1つcheckしている
確認するのも大変、管理も大変→ routerを信じていいよね
視覚的に見える機能や確認commandが必要
2003/10/20

MPLS JAPAN2003

26

運用での問題点（続）z primary pathの設計・設定は大変
z backup pathの設計・設定はさらに大変– バックボーン再構築時はやってられない

自動でpathを張ることが必要
但しintelligentさがかけると使えない
2003/10/20

MPLS JAPAN2003

27

Interoperability問題
z TEに関して– Facility backup方式• Link protection• Node protection

両方の相互接続性を満たすrouterは検証当時なし
Interoperabilityに期待したい
2003/10/20

MPLS JAPAN2003

28

Interoperability問題（続）z Multi-area TE– IETFにおいても標準化はまだ• Reoptimizationの問題• ABR node protectionの問題• 。。。

– ちゃんとやろうとすると相互接続性が厳しい

2003/10/20

MPLS JAPAN2003

29

まとめ

2003/10/20

MPLS JAPAN2003

30

まとめz MPLS TEを導入したメリットz MPLS TEを導入して出た課題
z 今後導入したい機能のinteroperabilityの課題
MPLSの技術はまだ発展途上
運用面を含めもっとより高品質のネットワークを作っていきたい
2003/10/20

MPLS JAPAN2003

31

Thank you
ke-kumaki@kddi.com

2003/10/20

MPLS JAPAN2003

32