L3 inter-domain VPNの現状と展望
KDDI株式会社
熊木 健二
ke-kumaki@kddi.com
2002/11/07

MPLS JAPAN2002

Agendaz Inter-AS VPNモデル
z End-to-End QoSz Securityz Scalabilityz 現状の問題点
z 今後の展望2002/11/07

MPLS JAPAN2002

Inter-AS VPNモデル
z 2547bis section10– Type(a):vrf-to-vrf approach– Type(b):MP-eBGP between ASBRs approach(RFC3107)– Type(c):Multihop-eBGP between RRs approach(RFC3107 section6)z 2547bis section9– CsC
z その他にも、、、– GRE tunnel
2002/11/07

MPLS JAPAN2002

現状でのInter-AS VPN
SP B

SP A

(b)MP-eBGP

RR

ASBR

ASBRMP-iBGP for

RR
MP-iBGP for
VPNv4 route

VPNv4 route

MPLS網PEPE(a)static,eBGP
IPv4 update

2002/11/07

companyA

MPLS網

IPv4 update

MPLS JAPAN2002

companyB

companyB

companyD

vrf-to-vrf approach – control plane(bottom label)
IPv4 update

IPv4 update

RR

RR

ASBR2

MP-iBGP
Net:IPv4 prefix

ASBR1
AS1

AS2

2002/11/07

companyA

Net:IPv4 prefix
NH:ASBR1
Label:AS1a

NH:ASBR2
Label: AS2a RD AS2:L

MP-iBGPRD AS1:L

PE1PE2MPLS JAPAN2002

companyB

companyB

companyD

vrf-to-vrf approach – control plane(top label)
LDP

Net:IPv4 prefix

LDP

IPv4 update

Net:IPv4 prefix

IPv4 update

Label:POP

NH:ASBR2

RR

Label: POP

Net:IPv4 prefix

Label: AS2a’

2002/11/07

companyA

P2
PE2

Net:IPv4 prefix

AS1

AS2

MPLS JAPAN2002

companyB

RR
LDP

ASBR1

ASBR2

LDP

NH:ASBR2

NH:ASBR1

companyB

P1
PE1

NH:ASBR1
Label:AS1a’companyD

vrf-to-vrf approach-forwarding plane
SP B

SP A

RR
MP-iBGP for

RR

ASBR

ASBR

MPLS網

MP-iBGP for
VPNv4 route

VPNv4 route

MPLS網

PE

PE

IPv4 update

IPv4 update

2002/11/07

companyA

MPLS JAPAN2002

companyB

companyB

companyD

MP-eBGP between ASBRs approach– control plane (bottom label)
ASBRs can:• Set next hop self
• Redistribute connected subnets

RRRR

ASBR2 MP-eBGP

MP-iBGP
Net:IPv4 prefix

ASBR1
AS1

AS2

Net:IPv4 prefix
NH:ASBR1

Label: AS2a RD AS1:L

Label:AS1b RD AS1:L

2002/11/07

companyA

MPLS JAPAN2002

companyB

Net:IPv4 prefix
NH:PE1
Label:AS1a

NH:ASBR2PE2

MP-iBGPcompanyB

PE1

RD AS1:L

IPv4 update

companyD

MP-eBGP between ASBRs approach– control plane (top label)
LDP

Net:IPv4 prefix

LDP

NH:PE1

Net:IPv4 prefix

Label:AS1a’

NH:ASBR2RRLabel: POP

Net:IPv4 prefix
NH:ASBR2
Label: AS2a’

2002/11/07

companyA

P2
PE2

Net:IPv4 prefix

AS1

AS2

MPLS JAPAN2002

companyB

LDP

ASBR1

ASBR2

LDP

RR

companyB

P1
PE1

NH:PE1
Label:POP

IPv4 update

companyD

MP-eBGP between ASBRs approach– forwarding plane
SP B

SP A

RR

ASBR

ASBR

MP-iBGP for

RR
MP-iBGP for
VPNv4 route

VPNv4 routePE

PE

IPv4 update

IPv4 update

2002/11/07

companyA

MPLS JAPAN2002

companyB

companyB

companyD

Multihop-eBGP between RRs approachz ASBRの保持する経路数及びtraffic量によりtype(c)も必要になる可能性もある– IPv4+labelを相手に流す必要がある→必要なIPv4+labelを受け取るためfilterしないといけない– BGP peerは相手のネットワークに依存するするため場合によっては不安定になる可能性もある– Scalabilityはある
2002/11/07

MPLS JAPAN2002

End-to-End QoS
z 当初はBEで十分だった。。。

– End-to-EndでのQoSのrequirementが出てきた– ところが。。。
• SP同士でQoSのpolicyが異なる（特にサービスに直結する）• IP precedence base,DSCP base• edge,edge+corez とりあえず方法としては（IP部分、MPLS部分）– Type(a):ASBR（marking:rewrite) and/or ingress
PE(marking+policing)– Type(b):ingress PE(marking+policing) and/orASBR(marking:rewrite)
2002/11/07

MPLS JAPAN2002

End-to-End QoS (Cont.)z 結局のところサービスとサービスのmappingをするしかない– どうやるの。。。（サービスの均一性）– Edge機能のQoSのmapping（IP Precedence,DSCP）– Core機能のQoSのmapping(Cos）z シームレスなサービスは無理なの？

– あくまで擬似的（QoSの粒度の違いなど）– ユーザの要求にもよる– でもなんとか。。。
2002/11/07

MPLS JAPAN2002

Securityz もちろん信頼できる相手とのpeeringである– ext-communityのfiltering(in,out)• 必要な経路以外はadvertise,receiveしない– IPv4+labelのfiltering– 場合によってはLDP/BGP sessionでMD5authenticationを用いる

2002/11/07

MPLS JAPAN2002

Scalabilityz RRからは必要なRTだけを受け取る– RRのフル経路は必要ない
z ASBRからは必要なRTだけを広報する
z 相互接続先ASBRからは必要なRTだけを受け取る

2002/11/07

MPLS JAPAN2002

現状の問題点z Traffic control– １つもしくは複数のASをまたいでのシームレスなtraffic制御（specific route等）ができない
z Protection– １つもしくは複数のASをまたいでの高速なprotectionができない(link/node protection)z End-to-End QoS– シームレスなEnd-to-EndでのQoSは提供できない– 帯域保証ができない
2002/11/07

MPLS JAPAN2002

現状の問題点 (Cont.)→結局のところ現状の問題を克服できるのは1domainのRSVP-TEを拡張すること(top labelの部分）
Diffserv aware inter-AS TE

2002/11/07

MPLS JAPAN2002

今後の展望z draft-zhang-mpls-interas-te-req-00.txt(55th IETF@Atlanta)
Raymond Zhang(Infonet Services Corporation)
Kenji Kumaki(KDDI Corporation)
JP Vasseur(Cisco Systems, Inc)
Paul Mabey(Qwest Communications)
Nadim Constantine(Infonet Services Corporation)– このdraftはあくまでinter-AS TEについての記述– draftの一部のシナリオをinter-AS VPNに適用する
2002/11/07

MPLS JAPAN2002

シナリオ(1)z 相互接続先のPoPにVPN userが多数ある
z 相互接続先のPoPを利用してPEを置く
z PEは相互接続先のIGP,BGP domainに属さないz シームレスさを保証するために相互接続先のPEから接続元ASBRまではinter-AS TE trunk(s)のLSPを張る
z End-to-End Diffserv pathを張るために、SPはDiffserv PHBをサポートする
2002/11/07

MPLS JAPAN2002

シナリオ(1) (Cont.)z Extended or Virtual POP for SPs
CE2
VPN-1

SP1

Inter-AS DS-TE
for Extended trunking
GW
CE3
VPN-1

GW

SP2
2002/11/07

V-POP
RTR

MPLS JAPAN2002

CE1
VPN-1

シナリオ(2)z 相互接続先のPoP先にVPN userが少数
z ASBRからは相互接続先CEにdirectにinter-AS TE LSPを張る– ASBRの足はvrfとする
z 複数のCEへLSPを張る場合にはPEでLSPの階層化を行ってもよい
z LSPの帯域は保証される
2002/11/07

MPLS JAPAN2002

シナリオ(2) (Cont.)z Extended or Virtual trunk
CE2
VPN-1

SP1
Inter-AS DS-TE
for Extended local loop

vrf
GW

CE3
VPN-1

GW

SP2
PE
2002/11/07

MPLS JAPAN2002

CE1
VPN-1

シナリオ(3)z End-to-Endで帯域保証– CE-CE間でEF trafficを通す
z CE-CE間でInter-AS TE LSPを張る

2002/11/07

MPLS JAPAN2002

シナリオ(3) (Cont.)z End-to-End Inter-AS MPLS/TE (CE-CE)
CE2
VPN-1

SP1
E2E Inter-AS DS-TE
GW
CE3VPN-1

GW

SP2PE
2002/11/07

MPLS JAPAN2002

CE1
VPN-1

シナリオに対する要求
z Inter-AS TEのサポート– ASBRを越えてシームレスにend-to-endでLSPが張れる（RSVP signaling)z Inter-AS DS-TEのサポート– draft-ietf-tewg-diff-te-reqts-06 section4.1を満たす必要がある
z LSPの階層化– シナリオ(1)(2)(3)のように１つのASBRから複数のinter-AS TE LSPを張る場合にはscalabilityの問題から階層化できることが望ましい
2002/11/07

MPLS JAPAN2002

シナリオに対する要求(Cont.)
z 最適化– Inter-AS pathは異なるIGP metricを持ついくつかのASをまたぐためIGP metricの正規化をする必要がある
z 異なる経路のinter-AS TE LSPのサポート– LSR間で複数のLSPを張ることが望ましい（特にシナリオ2の場合）• Link/SRLG/Node diversely routed inter-AS TE LSPをセットアップできること

2002/11/07

MPLS JAPAN2002

シナリオに対する要求(Cont.)z Fast Recovery– Inter-AS link障害時に高速にlocal protectionができること• Link/Node protection (Detour LSP,Bypass LSP)z Protocol Signaling and Path Computations– Inter-AS TE tunnel pathは(intra-AS segment in AS
x,inter-AS segment across inter-AS link,intra-AS
segment in AS y)からなる– ASBRのselectionはmanualとauto-discovery• Auto-discoveryではIGPのextensionが必要
2002/11/07

MPLS JAPAN2002

シナリオに対する要求(Cont.)– LSPのset up• manual:マニュアルでhopを指定（全て/一部）• automatic:IGP Extension(例えばdraftvasseur-mpls-ospf-te-cap-00.txt)を使用したPCS(Path Computation Sever)のdiscovery
mechanism、PCSにinter-AS TE LSPを計算する要求をするためにsignaling protocolの拡張が必要• RFC3107を使用してLSPを張ることも可能だがlabeled IP prefixを他ASに広報する必要はある
2002/11/07

MPLS JAPAN2002

シナリオに対する要求(Cont.)z 機密性– 他ASの詳細なhop-listを知らなくても他ASのASBRからそのASの最適なTE LSPを知ることができること
z TrafficをInter-AS TE tunnelにmapping– 特定のvrfにTE LSPをmappingできること（シナリオ(２)）

2002/11/07

MPLS JAPAN2002

シナリオに対する要求(Cont.)z Policy control– 異なるSP間ではpolicyが異なる（policy serverでも可）• FRRをサポートする？
• DS-TE bitの書き換え、TE metrics等• RSVP path attribute(affinities,preemption priorities)の書き換え• Bandwidth controlをサポートするか

z LSPの運用保守– lsp ping,tunnel trace,MPLS TTL…
2002/11/07

MPLS JAPAN2002

評価基準
z Scalability– IGP(IGP flooding frequency,link state
database size,SPF….等の影響）– BGP（BGPで追加で運ぶ情報の影響）– RSVP message flooding(RSVP message、LSPの数の影響）。。。

2002/11/07

MPLS JAPAN2002

評価基準（Cont.)z Performance– TE LSP setup time
– Inter-AS TE LSPの最適化指数。。。

2002/11/07

MPLS JAPAN2002

Securityz Inter-AS signaling requestをauthenticate/allow/denyできるようなモデルが必要

2002/11/07

MPLS JAPAN2002

Thank you
ke-kumaki@kddi.com