1 / 10

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-00.txt>

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-00.txt>.

caldwell-flores
Download Presentation

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-00.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. Extensions to G/RSVP-TE for Point to Multipoint TE LSPs<draft-raggarwa-mpls-rsvp-te-p2mp-00.txt> 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)

  2. Achievements since Seoul (1) • A single solution framework: merge between • <draft-raggarwa-mpls-p2mp-te-02.txt> • <draft-yasukawa-mpls-p2mp-rsvp-te-04.txt> • 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 • <NO_CONSENSUS> 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)

  3. 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)

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

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

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

  7. Open Issue 3: Re-optimization Impact of partial re-optimization requires extra identifier => P2P Sub-LSP ID (+ scope) Refers to the following requirements: • Do we need partial re-optimization ? • definition of partial re-optimization (functional) • mechanism of partial re-optimization (signaling) • 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 • Is it acceptable to only support full tree re-optimization (no data replication) ?

  8. 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)

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

  10. 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 • <draft-raggarwa-mpls-rsvp-p2mp-te-00.txt> is a reasonable basis for continuing this work • Consensus to make this document a MPLS WG I-d ?

More Related