1 / 17

Setup and Maintenance of Pseudo-Wires Using RSVP-TE

This document discusses the setup and maintenance of pseudo-wires using RSVP-TE, including inter-domain traffic engineering, scalability, PW resilience, routing, QoS, and OAM requirements.

tsamantha
Download Presentation

Setup and Maintenance of Pseudo-Wires Using RSVP-TE

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. Setup and Maintenance of Pseudo-Wires Using RSVP-TE Draft-raggarwa-rsvpte-pw-02.txt Rahul Aggarwal (Juniper) Kireeti Kompella (Juniper) Arthi Ayyangar (Juniper) Dimitri Papadimitriou (Alcatel) Peter Busschbach (Lucent) Nurit Sprecher (Siemens)

  2. Agenda • Why RSVP-TE ? • Meeting the MS-PW Requirements • Discussion

  3. Why RSVP-TE ? • Inter-Domain Traffic Engineered Pseudo-wires (PWs) • Intra-domain PSN tunnels are RSVP-TE LSPs • Look at the entire picture with all the pieces • Multi-Segment (MS) PWs scalability with • PW TE and • PW resiliency and • MS PW routing • RSVP-TE provides existing mechanisms to address all of the above • RSVP-TE (RFC 3209, 3473) and LSP-Hierarchy (draft-ietf-mpls-lsp-hierarchy) • Same tools as those used for inter-domain RSVP-TE PSN Tunnels

  4. Inter-Domain TE PW Signaling using RSVP-TEOverview • Instantiate a multi-segment PW as a RSVP-TE LSP • Two unidirectional LSPs or one bi-directional LSP – PW ID TLV along with the SESSION & SENDER_TEMPLATE identifies the PW • This “PW LSP” is nested in intra-domain PSN RSVP-TE LSPs between PW segment end-points • Targeted RSVP-TE signaling messages between PW segment end-points • QoS signaling using TSPEC etc • PW Explicit/Record routing using ERO/RRO • Single sided signaling possible to ensure the same MS PW path in both directions • Resiliency using Fast-Reroute - draft-ietf-mpls-rsvp-te-fast-reroute • MS PW Path computation and routing follows inter-domain RSVP-TE

  5. MS-PW TE using RSVP-TE Example MS-PW partial path computation to next ASBR PATH RESV CE2 Nesting over pre-provisioned intra-region TE PSN LSP CE1 PE1 ASBR1 ASBR3 PE2 P P AS2 AS1 PE3 ASBR2 ASBR4 MS-PW with TE from PE1 to PE2 Dynamic setup of intra-region TE PSN LSP Forward MS-PW setup request to next ASBR

  6. Meeting the MS-PW Requirements • MS-PW TE Motivation / Requirements – RSVP-TE applicability analysis • Based on MS-PW Requirements effort - draft-ietf-pwe3-ms-pw-requirements-00.txt • Scalability • Routing • Inter-domain routing and signaling • Resiliency • QoS and CAC • OAM

  7. MS-PW TE and RSVP-TEScalability Requirements • Not always desirable to setup a direct signaling adjacency between U-PEs • Avoid a full mesh of signaling adjacencies between the U-PEs • Avoid a full mesh of end-to-end PSN tunnels • Instead a U-PE maintains a single RSVP-TE targeted adjacency with the neighboring S-PE from the same or the next domain • S-PE maintains a single RSVP-TE targeted adjacency with the neighboring S-PE or U-PE from the same or the next domain

  8. MS-PW TE and RSVP-TERouting Requirements • U-PE signaling the MS-PW must have the ability to select the S-PEs on the MS-PW path that meet the QoS/policy requirements • RSVP-TE Explicit routing - RFC 3209 • Inter-domain support • RSVP-TE inter-domain explicit routing support • Dynamic re-routing around failure points • Global repair i.e re-routing triggered by error messages

  9. MS-PW TE and RSVP-TEInter-Domain Routing/Signaling Requirements • Inter-Domain PWs • RSVP-TE already supports inter-domain signaling • draft-ietf-ccamp-inter-domain-framework-01.txt and draft-ietf-ccamp-inter-domain-rsvp-te-00.txt • Inter-domain path computation follows RSVP-TE inter-domain work in CCAMP WG • Ability to treat underlying PSN LSPs as FAs – LSP hierarchy • RSVP-TE Crankback support - draft-ietf-ccamp-crankback-04.txt • Places MS PW development in a position to automatically leverage PCE WG work

  10. MS-PWs and RSVP-TE Resiliency Requirements • End-to-end backup MS-PW • RSVP-TE allows primary and backup PWs to be associated with each other and share resources on common segments – RFC 3209 • Ability to traverse different S-PEs i.e. avoid fate sharing • draft-ietf-ccamp-rsvp-te-exclude-route-04.txt • Mechanisms to perform a fast switchover from a primary PW to a backup PW upon failure detection • RSVP-TE error notification allows global repair

  11. MS-PWs and RSVP-TE Resiliency Requirements… • Node protection in case of S-PE failure • RSVP-TE fast reroute draft-ietf-mpls-rsvp-lsp-fast-reroute • PW segment protection • RSVP-TE fast reroute • Mechanisms to propagate PW segment failure to other MS-PW segments • RSVP-TE PathErr/ResvErr/Notify – Regular procedures

  12. MS-PW TE and RSVP-TEQoS and CAC Requirements • End-to-end MS-PW bandwidth reservations • RSVP-TE QoS signaling – RFC3209 • RSVP-TE can support diverse QoS models • RSVP-TE support for diffserv, traffic priorities • Resource/policy admission control into RSVP-TE PSN Tunnels at U-PE and S-PE • Based on hierarchical RSVP-TE a la draft-ietf-mpls-lsp-hierarchy • RSVP-TE inter-domain signaling • Failure notification and crankback support

  13. MS-PW TE and RSVP-TEOAM Requirements • End-to-end MS PW OAM • Uses mechanisms already specified in LSP-Ping, BFD for MPLS and VCCV • VCCV capability negotiation remains to be specified • Segment PW OAM • Requires extensions that remain to be specified • Conceivable that these extensions will be primarily protocol independent • PSN Tunnel and Segment OAM defect propagation requires extensions that remain to be specified

  14. MS PW and RSVP-TEMPLS PW Encapsulations • No change to existing MPLS PW encapsulations • No change to existing PW OAM encapsulation

  15. MS PW and SS PW Signaling Protocols • What is the relationship with the existing SS PW Signaling protocols i.e. LDP and L2TPv3 ? • SS PWs continue to be signaled using LDP and/or L2TPv3 • RSVP-TE for MS-PWs will co-exist with existing SS PW protocols • Should we consider signaling single PW segments using LDP, triggered by MS PW RSVP-TE setup messages ? • LDP exchanges PW segment parameters, labels • RSVP-TE signals MS PW and supports TE, resiliency, inter-domain routing, explicit routing, QoS

  16. Extensions Needed to RSVP-TE for MS-PW TE • Let us be clear about the extensions needed, extensions that have been specified and extensions that have not been specified yet • PW Identification • PW ID TLV • Carried in a new SENDER_TSPEC/FLOWSPEC that remains to be specified • Control word Negotiation • Carried in the new SENDER_TSPEC/FLOWSPEC • All OAM mechanisms not specified yet [discussed earlier] • Error codes in PathErr and ResvErr to signal PW specific errors/status • Not fully specified yet

  17. Conclusion • There are SPs with SS-PWs who see a reason to deploy a different technology for MS-PW TE – namely RSVP-TE • There are multiple vendors who want to implement it • There are no substantive technical issues with it • SPs that deploy RSVP-TE for FRR, make-before-break and/or QoS want the same features for MS-PWs • Operational ease is a bonus • PWE3 must look at the big picture and address all elements of MS-PW TE • MS-PW scalability and • MS PW TE • MS PW Resiliency • MS routing and signaling • A piece meal approach would be short-sighted

More Related