1 / 21

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

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). Agenda. Solution Recap Identifiers

ponce
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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) Slide 2

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

  4. Solution Basic Requirement • Setup a P2MP TE LSP from Spe1 to Rpe1, Rpe2, Rpe3 • Minimize Enhancements to Current RSVP-TE Spe1 P2 Rpe3 P1 Rpe1 Rpe2 Slide 4

  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 Slide 5

  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 ! Slide 6

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

  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 Slide 8

  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 Slide 9

  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 Slide 10

  11. Solution Example Spe1 L3 P2 Rpe3 P1 L3->{L1, L2} L4->{L5} L2 Rpe1 L1 Rpe2 Slide 11

  12. Enhancements since version 00 • Identifiers • Secondary P2MP LSPs • Non-adjacent signaling • Fast reroute • Hierarchy using P2P LSPs Slide 12

  13. 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

  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 Slide 14

  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 Slide 15

  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 Slide 16

  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 Slide 17

  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 Slide 18

  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 Slide 19

  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 Slide 20

  21. Thank You! http://www.ietf.org/internet-drafts/draft-raggarwa-mpls-p2mp-te-02.txt rahul@juniper.net http://www.juniper.net

More Related