150 likes | 163 Views
Detailed requirements for extending Pseudo Wires (PWs) across multiple domains and PSN tunnels, addressing scalability and security. It explains the concepts, terminology, applications, architecture, setup mechanisms, and resiliency requirements related to PWs.
E N D
Requirements for Inter Domain Pseudo Wiresdraft-martini-pwe3-mh-pw-requirements-01.txt Luca Martini (Cisco) Nabil Bitar (Verizon) Matthew Bocci (Alcatel)
Scope • Describe the necessary requirements to allow a service provider to extend the reach of PWs across multiple domains and PSN tunnels. Domains are: • ASs under one provider administrative control • IGP areas in one autonomous system • Different ASs under the administrative control of two or more service providers • administratively established PW domains
Multi-Segment Pseudo Wire Concept • A pseudo wire is composed of segments • Each segment is independently routed • Allow a pseudo wire to be stitched from one PSN tunnel to another at the end of one segment and the beginning of the next segment • But, the concatenation of segments must connect the two endpoints of a pseudo wire • The endpoints of a pseudo wire are called Ultimate PEs (U-PEs) • Intermediate segments (neither end of a segment is a PW endpoint) are delimited by Switching PEs (S-PEs)
Terminology Definition • Ultimate PE (U-PE): PE where customer-facing ACs are bound to a PW forwarder • SS-PW: Direct connection between two U-PEs. That is what PWE3 currently defines • MS-PW: A static or dynamically configured set of two or more contiguous PW segments that function as a single pt-pt PW. MS-PWs endpoints are on U-PEs • PW Switching Provider Edge (S-PE): A PE capable of switching the control and data planes of the preceding and succeeding PW segments in a MS-PW • PW Segment: A part of a single-segment or multi-segment PW, which is set up between two U-PEs and/or S-PEs
Applications • MS-PWs to alleviate scalability concerns in large Service provider networks • RSVP-TE tunnel meshness among the PEs for bandwidth-managed PWs • Number of targeted LDP sessions maintained by PEs for setting up PWs over an MPLS PSN • MS-PWs for Extending PWs to metro and access networks: • Conform to today’s network management practices • Deal with the increase in number of PEs – scalability concern • MS-PWs for extending PWs across provider boundaries to deal with: • Confidentiality and security requirements: • U-PE addresses in one provider domain not advertised to other-providers’ domains • Number of “authenticated” sessions that need to be managed between providers • The desire not to extend contiguous PSN tunnels (e.g., TE tunnels) between one provider and another provider • Interworking between different PSN tunneling technologies (e.g., MPLS and L2TP) • Mainly applies in interconnecting different providers’ networks
Architecture Requirements • S-PEs MAY only support switching PWs of the same PW type. • The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or an U-PE from the MS-PW architecture viewpoint. • The MS-PWs MUST use the same encapsulation modes specified for SS-PWs. • S-PEs MAY change the type or encapsulation mode • A MS-PW SHOULD be able to pass across PSNs of all technologies specified by PWE3 for SS-PWs. • Both directions of a PW segment MUST terminate on the same S-PE/U-PE.
Setup Mechanisms Requirements • Setup mechanisms • Mechanism1: • Static endpoint PW provisioning at U-PEs • Static PW segment endpoint configuration at S-PEs • PW segment signaling between a U-PE and S-PE or between an S-PE and S-PE • Mechanism 3: • Static end-point provisioning at U-PEs • Dynamic S-PE discovery and dynamic PW-segment placement between a U-PE and S-PE and between S-PEs. • A hybrid of mechanism1 and mechanism2
Setup Requirements • Static S-PE selection and PSN tunnel selection MUST be provided. • The MS-PW path MUST have the ability to be dynamically setup between the U-PEs by provisioning only the U-PEs. • Dynamic MS-PW pseudo wire setup requires that a unique identifier be associated with a PW and that contains sufficient information to determine the path to the remote U-PE • Procedures MUST be provided to allow dynamic setup of MS-PWs across providers when the providers do not advertise IP reachability information to routers in their network • Solutions MUST strive to minimize amount of configuration to setup an MS-PW. • MS-PW signaling procedures MUST define clear rules for triggering the setup of segments of a MS-PW. • The signaling procedures MUST be defined such that the setup of a MS-PW is considered successful if and only if all segments of the MS-PW are successfully setup. • Mechanisms MUST be developed to propagate setup explicit failure indications to the S-PEs and U-PEs associated with the failed MS-PW.
Resiliency Requirements • The ability to configure an end-end backup PW path for a primary PW path MUST be supported • The ability to configure a backup PW for a primary PW • PSN tunnel reroute MUST be transparent to the PW segments carried within the tunnel • Automatic Mechanisms to perform fast switchover from a primary PW to a backup PW upon failure detection SHOULD be provided to minimize packet loss. • Configuration Mechanisms to perform a switchover from a primary PW to a backup PW upon failure detection SHOULD be provided. • A mechanism to automatically revert to a primary PW from a backup PW MAY be provided and should be enable/disabled by administrative control. • Mechanisms for PW segment failure detection and notification to other segments of a MS-PW MUST be provided.
Traffic Engineering and QoS Requirements • Per PW/QoS class setup priority should be provided. • In case the PSN tunnel lacks the resources necessary to accommodate the new PW • a PW setup failure message MUST be returned and the PW MUST fail to setup. • Alternatively: an attempt to signal an new PSN tunnel, or increase the capacity of the existing PSN tunnel MUST be made. Failure of such attempts MUST result in PW setup failure • PW traffic parameter representations MUST be the same for all types of PW. • The PW signaling MUST enable separate traffic parameter values to be specified for the forward and reverse directions of the PW. • When setting up a MS-PW, S-PEs and U-PEs MUST be able to select a tunnel across the PSN that satisfies MS-PW QoS and bandwidth requirements • PW admission control into a PSN tunnel MUST be configurable. • S-PEs and U-PEs SHOULD be able to perform Admission control into a PSN tunnel to ensure that PW bandwidth and QoS requirements can be satisfied.
Routing Requirements • MUST support the setup of a statically configured segment of a MS-PW. ( static S-PE selection ) • The MS-PW MUST have the ability to automatically select the S-PEs along the MS-PW path. Some of the S-PEs MAY be statically selected • The PW Routing function MUST support dynamic re-routing around failure points when segments are setup using the dynamic setup method. • The PW Routing function MUST support re-routing around failures that occur between the statically configured segment endpoints. • Routing MUST support the operation of backup protection of primary paths. • Manual routing SHOULD be supported to allow diversity for 1:1 protected PWs. MS-PW MUST be able to traverse multiple IGP domains
OAM Requirements • MS-PW OAM SHOULD be supported end-to-end across the network • OAM activation/deactivation SHOULD be tied to MS-PW setup/tear down • The MS-PW SHOULD support a Forward Defect Indicator (FDI) • Single ended monitoring SHOULD be supported for both directions of the MS-PW • MS-PW OAM SHOULD support switch over between 1:1 protected LSPs end-to-end • End-end and segment-based In-band monitoring SHOULD be provided • At the S-PE, defect notifications on the upstream segment of PWs must be propagated to the downstream PW segment • All PE routers along the MS-PW MUST agree on a common PW OAM mechanism • At the S-PE, defects on an PSN tunnel must be propagated to all PWs that utilize that particular PSN tunnel • The directionality of defect notifications must be maintained across the S-PE • The S-PE should be able to behave as a segment endpoint for PW OAM mechanisms • The S-PE MUST be able to pass U-PE to U-PE PW OAM messages transparently
Next Steps and Questions • Add Security requirements • Add policy requirements • Consideration for any further refinement of the requirements based on group feedback • WG opinion on using the Multi-Segment terminology vs. Multi-Hop • Request WG to accept this document as a WG document