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

Rahul AggarwalJuniper Networks

Slide 2

Authors

Rahul Aggarwal (Juniper)Liming Wei (Redback) George Apostolopous

(Redback)Kireeti Kompella (Juniper)John Drake (Calient)

Rahul Aggarwal (Juniper)Liming Wei (Redback) George Apostolopous

(Redback)Kireeti Kompella (Juniper)John Drake (Calient)

Slide 3

Agenda

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

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

Slide 4

Solution Basic Requirement

Rpe1

Spe1

Rpe2

Rpe3P2P1

1. Setup a P2MP TE LSP from Spe1 to Rpe1, Rpe2, Rpe32. Minimize Enhancements to Current RSVP-TE

Slide 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

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

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

SolutionMechanism

• RSVP-TE already supports the notion of multiple P2P LSPs per session

• Extend this notion to build P2MP LSPs

• RSVP-TE already supports the notion of multiple P2P LSPs per session

• Extend this notion to build P2MP LSPs

Slide 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

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

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

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

Solution Example

Rpe1

Spe1

Rpe2

Rpe3P2P1

L1

L2

L3

L3->{L1, L2}

L4->{L5}

Slide 12

Enhancements since version 00

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

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

• 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

Thank You!

http://www.ietf.org/internet-drafts/draft-raggarwa-mpls-p2mp-te-02.txt

rahul@juniper.nethttp://www.juniper.net