Upload
richard-sutton
View
225
Download
1
Tags:
Embed Size (px)
Citation preview
MPLS Multiple Topology Support
draft-zhao-mpls-ldp-multiple-topology-01 draft-zhao-mpls-rsvp-te-multiple-topology-01
IETF 80 – Prague
Quick Review for These Two Drafts
In the previous version of the drafts, we have
discussed a few application scenarios;
The basic ldp and rsvp-te protocol extensions to
support mpls multiple topology;
The forwarding options to support mpls multiple
topologies;
When we presented these two drafts in IETF77, one
of the comments we got is to work with service providers
to pin down the exact application scenarios where mpls
multiple topology can provide unique solutions;
The extended FEC TLV has the format as below:
Review: Extensions to LDP
FEC Element 1
MT-IDreserved
FU FEC(TBD)
FEC Element n
IETF 80 – Prague
Review: Extensions to RSVP-TE
Add MT Information into an object in a message
Add MT Information into SESSION object
Extended P2P SESSION object for IPv4
IPv4 Tunnel End Address
Extended Tunnel ID
Tunnel IDMT-ID (12 bits)Resv
IETF 80 – Prague
Review: MPLS Forwarding in MT
Option 1: MT is implied by Label
On a LSR, same FEC with different MT-ID mapped to different
Label
Advantages: No hardware changes
Disadvantages: Label space is limited
Option 2: MT is indicated by stacked Label
One extra label is stacked to indicate a topology
Advantages: Each topology has a full label space
Disadvantages: Forwarding is complicated
What is Done in this Version of the Drafts?
The prototyping is done and has been demonstrated for a few service providers;
There are a few scenarios added in these drafts: Protection Solution using MPLS Multiple Topology; Simplify the inter-AS VPN solutions;
IETF 80- Prague
Application Scenario Example 1: End-to-End mLDP P2MP backup LSP
The primary P2MP LSP set up in the red topology is backed up by the secondary P2MP LSP setup in the blue topology, where the red topology and blue topology don’t share the common links and nodes if it is required.
Application Scenario Example2
backbone
MAN MAN
AS x
MAN MAN
AS y
Province Network
AS9808
O&M serverBackbone router
Province router
In order to deploy MPLS VPN with entire network, there is a strong demand to support inter-AS connection and E2E O&M
AS O&Mbackbone network
Public AS: 9808
headquarter
province network
Private AS: x
province
Headquarter O&M
Province O&M
Solution for Inter-AS MPLS VPN• Three mature mechanisms have been used to Inter-
AS MPLS VPN
Optioin A
Option B
Option C• Option A/B/C can build inter-AS connection of MPLS VPN, but E2E O&M
can’t be achieved by them• We hope to use single AS to solve E2E O&M problem based on the
original multiple ASs network
Inter-AS VPN E2E O&M Solutions
AS #1
AS #2
AS #3
AS #3AS
#2
AS #1
A
B
AS #3AS
#2
AS #4
AS #1
Virtual Router
Solution A Solution B Solution C
Goal of the Solutions: Transfer inter-AS to Single AS
Inter-AS Single AS
A
B
Expand backbone
AS with new routers
Expand backbone AS
with virtual routers
Build new AS with
multiple-topology
CMnet backbone
Province AProvince B
Router with default topology
Inter-AS VPN E2E O&M
Router with VPN topology
CMnet backbone
AS #1
AS #2AS #3 AS #3
AS #2
AS #4
AS #1
Province AProvince B
O&M server
Headquarter O&M
Headquarter O&M
• Build New AS for MPLS VPN Using MPLS Multiple Topology– Use multiple-topology to create a new AS which merges virtual topologies
from backbone and province ASs together– Backbone can achieve E2E O&M within the new AS
Analysis
Most of Existing network routers can’t support the virtual router by software update. It’s also a high cost solution because of substituting the hardware and software
Multiple-Topology
Virtual Router
New Construction is simple and reliable. But the high cost and the inefficient use of existing network resources are not preferable
New Construction
Considering cost and scalability, utilization and evolution of the existing network, Multiple-Topology is the preferable solution
Multiple-Topology is an easy way to deploy by software update. With MT existing network resources could be efficiently used and the network can be of resilent expansion. But the standard is not mature enough
Next Steps
• We would like to identify more application scenarios in the next version of the draft.
• We will update the protocol extensions based on the findings from the prototyping in the next version of the drafts;
• The demonstrations will be given to customers who are interested;• We would like to get more feed back from the working group for this draft.
IETF 80 - Prague