Establishing P2MP MPLS TE LSPs
draft-raggarwa-mpls-p2mp-te-02.txt
Rahul Aggarwal
Juniper Networks
Authors
Rahul Aggarwal (Juniper)
Liming Wei (Redback)
George Apostolopous (Redback)
Kireeti Kompella (Juniper)
John Drake (Calient)
Slide 2
Agenda
•
•
•
•
•
•
•
Solution Recap
Identifiers
Secondary P2MP LSPs
Non-adjacent Signaling
Fast Reroute
LSP Hierarchy
Conclusion
Slide 3
Solution
Basic Requirement
1.
2.
Setup a P2MP TE LSP from Spe1
to Rpe1, Rpe2, Rpe3
Minimize Enhancements to
Current RSVP-TE
Spe1
P2
P1
Rpe1
Rpe2
Slide 4
Rpe3
Solving the Practical Problem
• The problem is to introduce multicast
functionality in the MPLS data plane
– Optimize the data plane for high volume
multicast
– No need to optimize the control plane for
multicast
• P2MP TE is done in the data plane
• Control plane uses P2P LSPs as building
blocks
Slide 5
Solution
Requirements
• Operational simplicity
– P2P RSVP-TE is deployed and understood
– Leverage the existing control plane model
• Protocol simplicity
– Minimize complex protocol changes
• Implementation simplicity
– Minimize changes to deployed software:
Less Bugs !
Slide 6
Solution
Mechanism
• RSVP-TE already supports the
notion of multiple P2P LSPs per
session
• Extend this notion to build P2MP
LSPs
Slide 7
Solution
Mechanism
• P2MP LSP is setup by merging
individual P2P TE LSPs in the network
– Merge occurs in the data plane
– Not in the control plane: Minimal
enhancments to current RSVP-TE
• MPLS multicast label mappings are
setup at the merge nodes
Slide 8
Solution
Mechanism
• Spe initiates individual P2P LSPs to each
Rpe for a given P2MP LSP
– Common P2MP Session object
– Distinct Sender Templates for each P2P LSP
– Individual PATH messages
– P2P TE ERO in each PATH message
• Each Rpe originates a RESV message
Slide 9
Solution
Mechanism
• An upstream merge node follows RSVPTE SE style merge semantics
– Allocates a merge label
– Merges RESV flowspecs
– Sets up a multicast label binding
Slide 10
Solution
Example
Spe1
L3
P2
P1
L3->{L1, L2}
L2
Rpe1
L1
Rpe2
Slide 11
L4->{L5}
Rpe3
Enhancements since version 00
•
•
•
•
•
Identifiers
Secondary P2MP LSPs
Non-adjacent signaling
Fast reroute
Hierarchy using P2P LSPs
Slide 12
Identifiers
• A ‘constituent’ P2P LSP is identified by
– Common session object
– Unique sender template
• Session Object
– <Source Address, Tunnel ID, Application ID>
• Sender Template
– <Destination Address, LSP-ID, Branch ID>
Slide 13
Secondary P2MP LSPs
•
•
•
•
•
Multiple instances of a P2MP LSP
One instance is the primary
One or more secondary instances
Each instance has a different LSP-ID
Within an instance branch-ID of each P2P
LSP is different
• Instances may share resources
Slide 14
Non-Adjacent Signaling
• Optimization to reduce PATH message
processing and state on nodes that are along
the common path of 2 or more branch LSPs
• Ingress sends the successive PATH message
directly to the branch LSR where the new P2P
LSP branches from the first
– Path message does not contain a label request object
• Hence only one PATH message for a P2MP LSP
instance between two nodes
Slide 15
Make Before Break
• Entire P2MP Tree re-optimization
– A new P2MP LSP instance is signaled
– The old instance is torn down after ingress
moves traffic to the new instance
• Re-optimization of a specific branch
– The re-optimized branch is signaled with a
different branch ID
Slide 16
Fast Reroute
• Draft-ietf-mpls-rsvp-lsp-fastreroute-xx.txt
mechanisms apply
• Facility backup
– Link protection ‘just works’
– For Node protection the bypass tunnel can
only backup a set of branch LSPs that pass
through a common downstream MP from the
PLR
Slide 17
Fast Reroute ..cont
• One to one backup
– One or more of the branch LSPs can be
protected
– DETOUR object inserted in the backup PATH
message
– Node protection possible as long as there is
an alternate path to the destination
Slide 18
LSP Hierarchy
• A traditional P2P LSP can be used as a link of a
P2MP LSP
– P2P LSP is advertised as a FA by the ingress of the
P2P LSP
– FA is used by P2MP LSP head-end when computing
the path of each branch LSP
• Scalability: Transit LSRs along a FA do not
process P2MP control plane messages
• Legacy support: Transit LSRs along a FA do not
have to be P2MP capable
Slide 19
Conclusion
• The updated revision matures the solution
• Mechanism re-uses RSVP-TE machinery for
building P2MP LSPs and for protection
• Ability to signal different attributes along
each constituent P2P LSP can be useful in
inter-region TE
• Move this to a WG Doc.
• Comments
Slide 20
Thank You!
http://www.ietf.org/internet-drafts/draft-raggarwa-mpls-p2mp-te02.txt
[email protected]
http://www.juniper.net