Extensions to G/RSVP-TE for Point
to Multipoint TE LSPs
R.Aggarwal, D.Papadimitriou, and S.Yasukawa (Editors)
and contributors (L.Berger, I.Bryskin, D.Cheng, J.Drake, A.Farrel,
M.Jork, H.Kojima, K.Kompella, A.Kullberg, J-L Leroux, A.Malis,
K.Sugisono, G.Swallow, M.Uga, J.-P.Vasseur, and L.Wei)
Achievements since Seoul (1)
• A single solution framework: merge between
–
–
• P2MP TE LSP: set of P2P sub-LSPs, each from ingress to the leaf
• P2MP TE LSP Identification
– New P2MP SESSION C-Type with P2MP Id as destination
– SENDER_TEMPLATE and FILTER_SPEC objects remain unchanged
• P2P sub-LSP identification
– P2P SUB-LSP object with leaf destination address
– on sub-LSP ID in P2P SUB-LSP or sub-Group_ID in
SENDER_TEMPLATE object
• Multiple Path messages can be used to signal a single P2MP TE LSP
– Each Path message signals one or more P2P sub-LSPs
– When multiple P2P sub-LSPs in one Path message: ERO/RRO compression
scheme and processing (one sub-ERO per P2P sub-LSP)
Achievements since Seoul (2)
• Legacy LSR support + method(s):
– LSP stitching
– ( + P2P FA-LSP when applicable)
• Fast Reroute (MPLS only): Facility based + Detour style protection
• Reach consensus on solution requirements:
– support full refresh mechanisms (summary refresh optional but recommended)
– address message fragmentation (message size > MTU)
– support aggregated state management and incremental state updates
– metrics: messaging comparison + semantic + impact of protocol extensions
including on existing implementation
– node capabilities to be assessed and detailed in a routing specific document
• Single vs Multiple P2P sub-LSP in single Path message:
– dedicated section on refresh reduction (=> applicability of RFC 2961)
– dedicated section on incremental state updates and aggregate state management
• Remaining open issues identified and are under discussion (next slides)
Open Issue 1: State management
• As part of the state management discussion
• Issue: sub-Group ID versus sub-LSP ID
• Sub-Group ID: identifier of destination (set)
• Extreme case = sub LSP_ID on the other end
equivalent to the P2MP LSP_ID (ingress control)
• Disambiguate message size (single Path) and
group Path message together that collectively
represent the P2MP TE LSP
– Fragmentation and/or Aggregated state but still require
an ID for sub-tree re-optimization
– Investigate potential usage for incremental updates
Open Issue 2: Incremental state update
• RSVP [RFC2205] and G/RSVP-TE [RFC3473/RFC3209]
– signaling of resource reservation by full state communication and
synchronization in each state advertisement message
– [RFC2205] “Path and Resv messages are idempotent.”
• Refresh Overhead Reduction Extensions [RFC2961]
– improvements to message handling and scaling of state refreshes
– does not modify full state advertisement nature of Path/Resv messages
• Full state advertisement in Path/Resv has some drawbacks when only
portion(s) of previously advertised state modified => processing overhead
in identifying what state portion has changed + message overhead of
sending full state
• Extend RSVP to reduce message size and state processing associated w/
state change (support incremental state updates and optimize state change
processing) - on a hop-by-hop basis and particularly when Refresh
Reduction is also supported
Open Issue 2: Incremental state update
• Two documented proposals
– Based on refresh reduction
– incremental State/Message (iPath/iResv, iPathTear/iResvTear)
• Evaluation criteria
– is capability provided when refresh reduction is NOT supported
– is state management based on {session, sender_template}
– does adding, moving or deleting a sub-set of sub-LSPs, necessitate
creation of new state and separate management of the old states(s)
(timed out ?)
– how the method solves (~ implementation specific) these properties
=> performance gain vs cost of the mechanisms introduced
• Solution direction:
– new proposal based on sub-Group ID (sender_template encoding to be
refined)
– to be further elaborated
Open Issue 3: Re-optimization
Impact of partial re-optimization requires extra identifier => P2P
Sub-LSP ID (+ scope)
Refers to the following requirements:
1) Do we need partial re-optimization ?
– definition of partial re-optimization (functional)
– mechanism of partial re-optimization (signaling)
2) Do we need partial re-optimization if there is data replication
during transient ?
– there are mechanisms that are minimizing data replication
– from req i-d such mechanism SHOULD be defined
3) Is it acceptable to only support full tree re-optimization (no
data replication) ?
Open Issue 4: Re-merging
• Occurs when nodes receives two streams from at least two
different P_HOPs and data sent to the same or multiple
outgoing interfaces => differentiate case with and without
common segment after "re-merging" point
• Data plane impact (blocking issue)
• Control plane issue:
– aggregate state on “merging point” => if Path/Refresh message
with an incremental semantic then issue disappears
– since same SESSION and SENDER_TSPEC objects => rely on
P2P sub LSP_ID
• Example where re-merging would be allowed: change
color/priority in the middle of the P2MP tree (per sub-tree
due to administrative policies)
Open Issue 5: Recovery
• There is general agreement on Fast Reroute applicability
(MPLS only)
– Facility based protection
– Detour style protection
• Fast Reroute text to be moved in a separate document once
the base text is mature
• GMPLS remains to be covered
Conclusion + Next steps
• Building blocks of the single solution are in place
• Remaining open issues are being discussed and
should be resolved within a short timeframe
• Further progress achieved since draft was published
• More discussion from the MPLS WG list is also
expected
• is a
reasonable basis for continuing this work
• Consensus to make this document a MPLS WG I-d ?