Establishing P2MP MPLS TE LSPs draft-raggarwa-mpls-p2mp-te-02.txt

1
Establishing P2MP MPLS TE LSPsdraft-raggarwa-mpls
-p2mp-te-02.txt

• Rahul Aggarwal
• Juniper Networks

2
Authors

• Rahul Aggarwal (Juniper)
• Liming Wei (Redback)
• George Apostolopous (Redback)
• Kireeti Kompella (Juniper)
• John Drake (Calient)

3
Agenda

• Solution Recap
• Identifiers
• Secondary P2MP LSPs
• Non-adjacent Signaling
• Fast Reroute
• LSP Hierarchy
• Conclusion

4
Solution Basic Requirement

• Setup a P2MP TE LSP from Spe1
• to Rpe1, Rpe2, Rpe3
• Minimize Enhancements to
• Current RSVP-TE

Spe1
Rpe3
P2
P1
Rpe1
Rpe2
5
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

6
SolutionRequirements

• 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
  !

7
SolutionMechanism

• RSVP-TE already supports the notion of multiple
  P2P LSPs per session
• Extend this notion to build P2MP LSPs

8
SolutionMechanism

• 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

9
SolutionMechanism

• 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

10
SolutionMechanism

• An upstream merge node follows RSVP-TE SE style
  merge semantics
• Allocates a merge label
• Merges RESV flowspecs
• Sets up a multicast label binding

11
Solution Example
Spe1
L3
Rpe3
P2
P1
L3-gtL1, L2
L4-gtL5
L2
Rpe1
L1
Rpe2
12
Enhancements since version 00

• Identifiers
• Secondary P2MP LSPs
• Non-adjacent signaling
• Fast reroute
• Hierarchy using P2P LSPs

13
Identifiers

• A constituent P2P LSP is identified by
• Common session object
• Unique sender template
• Session Object
• ltSource Address, Tunnel ID, Application IDgt
• Sender Template
• ltDestination Address, LSP-ID, Branch IDgt

14
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

15
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

16
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

17
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

18
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

19
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

20
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

21
Thank You!

• http//www.ietf.org/internet-drafts/draft-raggarwa
  -mpls-p2mp-te-02.txt
• rahul_at_juniper.net
• http//www.juniper.net