PWE3 Working Group Internet Draft Document: draft-balus-mh-pw-control-protocol-01.txt Expires: November 2005 Florin Balus David McDysan Mike Loomis MCI Jeff Sugimoto Nortel Yuichiro Wada NTT Communications Andy Malis Tellabs Prayson Pate Overture Networks Paul Doolan Mangrove Systems Ping Pan Hammerhead Systems Vasile Radoaca May 2005 Multi-Segment Pseudowire Setup and Maintenance using LDP Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Balus et.al Expires November 2005 Page 1 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 Abstract [MH PWE3 Requirements] describes the requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. The current specification of the PW Architecture [PW ARCH] defines the PW as a single Segment entity, connecting the Attachment Circuits between two Ultimate PEs (U-PE). The current procedures for establishing a single segment PW (SS-PW) is described in [PW Control], where typically an LDP session is established between the ultimate PEs handling the Pseudowire End Service (PWES). No intermediate nodes, between the PEs, are aware of the PW. The purpose of this draft is to specify new LDP extensions, end to end signaling procedures to address the related requirements specified in [MS-PWE3 Requirements]. The proposed procedures follow the guidelines defined in [RFC3036bis] and enable the usage of addressing schemes (L2FECs) and other TLVs already defined for PWs in [PW Control]. Table of Contents 1. Acknowledgements..............................................3 2. Terminology...................................................3 3. Introduction and Scope........................................4 4. Relevant SS and MS-PW Architectures...........................4 5. Motivations and Resulting Design Requirements.................5 5.1 Satisfy the MS-PW requirements in [MH PWE3 Requirements].....6 5.1.1 Scalability and Inter-Domain Signaling and Routing.........6 5.1.2 Signaling Requirements.....................................7 5.2 Operational Consistency with SS-PWs..........................7 5.2.1 Service Identification and Provisioning Models.............7 5.2.2 OAM........................................................8 5.3 Service Resiliency...........................................8 6. Information Model for Dynamic Signaling of MS-PWs.............8 6.1 MS-PW TLV Design.............................................9 7. Signaling Procedures.........................................11 7.1 Double-Sided Provisioning using PWID FEC Example............11 7.2 General Procedures..........................................12 7.3 Determining the Next Signaling Hop..........................13 7.3.1 Static Provisioning of the next-signaling-hop.............13 7.3.2 "Discovery" Mechanisms for the next-signaling-hop.........14 8. Service Resiliency...........................................15 9. OAM Considerations...........................................15 9.1 MS-PW Capabilities..........................................15 Balus et.al. Expires November 2005 Page 2 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 9.1.1 PW Status Capability Negotiation..........................15 9.1.2 VCCV Capability Negotiation...............................16 9.2 PW Status Notification Operation............................16 9.3 VCCV Operation..............................................16 10. Security.....................................................16 11. IANA Considerations..........................................16 12. Full Copyright Statement.....................................16 13. References...................................................17 14. Author Information...........................................18 1. Acknowledgements The editors gratefully acknowledge the following contributors: Nabil Bitar (Verizon), Richard Spencer (British Telecom), Simon Delord (France Telecom), Bruce Davie (Cisco), Elizabeth Hache, Hamid Ould- Brahim, Praveen Muley, Arashmid Akhavain(Nortel). 2. Terminology The terminology used in this document is consistent with the terminology used in [MH PWE3 Requirements]: . Ultimate PE (U-PE). A PE where the customer-facing ACs (attachment circuits) are bound to a PW forwarder. An ultimate PE is present in the first and last segments of a MS-PW. . Single-Segment PW(SS-PW). A PW setup directly between two U-PE devices. Each LSP in one direction of a SS-PW traverses one PSN tunnel that connects the two U-PEs. . Multi-Segment PW (MS-PW). A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of a MS-PW by definition MUST terminate on an U-PE. . 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. It is therefore a PW switching point for a MS-PW. A PW Switching Point is never both U-PE and S-PE for the same MS-PW. A PW switching point runs necessary protocols to setup and manage PW segments with other PW switching points and ultimate PEs. . PW Segment. A part of a Single-Segment or Multi-Segment PW, which is set up between two adjacent PE devices, U-PEs and/or S-PEs. . Extended LDP session (E-LDP) - an LDP session established using targeted discovery mode [RFC3036bis] Balus et.al. Expires November 2005 Page 3 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 3. Introduction and Scope [MH PWE3 Requirements] describes the requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. A MS-PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. The current specification of the PW Architecture [PW ARCH] defines the PW as a single Segment entity, connecting attachment circuits on exactly two PEs. The current procedures for establishing PWs are described in [PW Control], where typically an LDP session is established between the PEs handling the pseudowire end service (PWES). The LDP session is referred to as "targeted" because it uses a targeted discovery (via hello messages) to establish an LDP session between the two PEs exchanging the PW labels. The tandem nodes between the PEs are unaware of the PW and are only involved with establishing a PSN tunnel between the (U-)PEs. The purpose of this draft is to specify new LDP extensions and end to end signaling procedures to address the requirements specified in [MH PWE3 Requirements]. The proposed procedures follow the guidelines defined in [RFC3036bis] and enable the reuse of existing addressing schemes(L2FECs) and other TLVs already defined for SS-PWs in [PW Control]. 4. Relevant SS and MS-PW Architectures The following two figures describe the reference models [MH PWE3 Requirements] to support SS and MS-PW emulated services. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | PW End V V V V PW End | V Service +----+ +----+ Service V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | Attachment Circuit (AC) Attachment Circuit(AC) native ethernet service native ethernet service Figure 1: PWE3 Reference Configuration Balus et.al. Expires November 2005 Page 4 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This architecture applies to the case where a PSN tunnel extends between two edges of a single PSN domain to transport a PW with endpoints at these edges. Native |<-----------Pseudo Wire----------->| Native Layer2 | | Layer2 Service | |<-PSN1-->| |<--PSN2->| | Service (AC) V V (AC) | +----+ +-----+ +----+ | +----+ | |UPE1|======== | SPE |=========|UPE2| | +---+ | |----------|.......PW1....|.........PW2...|---------|----| | | CE1| | | | | | | | |CE2| +----+ | |=========| |=========| | +---+ ^ +----+ +-----+ +----+ ^ | Provider Edge 1 ^ Provider Edge 2 | | | | | PW switching point | | (Optional PW adaptation function) | | | |<------------------- Emulated Service ----------------->| Figure 2: MS-PW Reference Model Figure 2 extends this architecture to show a Multi-Segment case. UPE1 and UPE2 provide a Pseudowire from CE1 to CE2. Each UPE resides in a different PSN domain. A PSN domain may correspond to a single Provider's network or to a subset of nodes within a Provider network. A PSN tunnel extends from UPE1 to SPE across PSN1, and a second PSN tunnel extends from SPE to UPE2 across PSN2. PWs are used to connect the Attachment circuits (ACs) attached to UPE1 to the corresponding ACs attached to UPE2. The PW segment on the tunnel across PSN1 is switched to a PW segment in the tunnel across PSN2 at SPE to complete the Multi-Segment PW (MS-PW) between UPE1 and UPE2. S-PE is therefore a PW switching point node and will be referred to as the PW switching provider edge (S-PE). PW segments of the same MS-PW (e.g., PW1 and PW2) MUST be of the same PW type, but PSN tunnels (e.g., PSN1 and PSN2) can be the same or different technology. Note that although Figure 2 only shows a single S-PE, a PW may transit more than one S-PE along its path. 5. Motivations and Resulting Design Requirements This section describes the motivations and highlights the architectural objectives of the proposal. Balus et.al. Expires November 2005 Page 5 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 5.1 Satisfy the MS-PW requirements in [MH PWE3 Requirements] 5.1.1 Scalability and Inter-Domain Signaling and Routing If a MS-PW deployment extends to large and far reaching portions of one or more networks, mandating an E-LDP session between all switching points of a MS-PW may lead to a control plane scalability issue [MH PWE3 Requirements]. Some network topologies have a natural hierarchy, as described in the use cases section of [MH PWE3 Requirements]. For example, multiple providers who wish to provide PWs that span two or more networks will likely have a relatively small number of gateway nodes as switching points (S-PE) that provide access to a larger number of end nodes (U-PE) forming a hierarchy. As another example, in some MPLS access network topologies, it is foreseeable that thousands or even tens of thousands of U-PE nodes may specify a small number of gateway nodes as switching points (S-PE) for access to the MPLS backbone, breaking the overall MPLS network into a well established hierarchy of MPLS "domains". In a more generic sense, [MH PWE3 Requirements] discusses a number of cases of a PW Service that has to span multiple domains: e.g. Inter-Provider, Inter-AS (same provider), MAN-WAN. In any of these cases the interaction between domains is controlled by certain gateways with a specific set of requirements for each individual scenario. This proposal eliminates the requirement for an E-LDP session between every pair of U-PE nodes for which a PW is required while at the same time preserving the necessary end to end signaling properties. In doing so it alleviates the control plane scalability requirements described in the previous paragraphs. Our proposal enables the end to end PW signaling through a "chain" of (E-)LDP sessions, using a dynamically determined set of S-PEs. If the S-PE and U-PE are identified by IP addresses, then IP routing protocols can distribute information to facilitate dynamic selection of a set of PEs between a Source U-PE and a Destination U-PE based upon parameters (e.g., metric, TE constraints, BGP attributes). U-PE reachability information could be reduced by assignment of IP address prefixes and/or prefix aggregation by a routing protocol. There could also be some Inter-Provider scenarios where the U-PEs located in a certain Provider domain may not be permitted to communicate directly via an (E)-LDP session to a U-PE in a different domain for operational and security reasons. For other reasons (e.g., security, administrative, etc.) the local U-PE may have no knowledge of the IP address of the remote U-PE. The requirements for these valid scenarios are still being specified and it is not clear whether or not a solution for dynamic end to end signaling is required or even allowed. A solution for these scenarios is for further study. Balus et.al. Expires November 2005 Page 6 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 5.1.2 Signaling Requirements The signaling described in this proposal is based on extensions to [RFC3036bis] and [PW Control]. The new elements (section 6) provide a flexible model that permits interoperability with manual provisioning models, but also enable an end to end MS-PW to be established with minimal number of OSS touches, ideally only one as specified in [MH PWE3 Requirements]. Specifically, the proposal enables the dynamic creation of an end-to-end MS-PW that does not require any manual intervention at the S-PE nodes. This draft allows for either the same set of S-PE nodes to be traversed in each direction of the MS-PW, or a different set. [PW Switching] specifies the case where the set of intermediate S- PEs is manually configured and the PW is stitched at these points by matching the L2FEC for each segment and associating this with the next segment. This case is not precluded by, and could interoperate with, the method described in this document. 5.2 Operational Consistency with SS-PWs In a Service Provider network it is understood that SS and MS-PWs will co-exist, possibly for an indefinite amount of time. Furthermore, it is foreseeable that existing SS-PWs may one day be forced to migrate to a MS-PW scenario for a number of reasons. In any case, it should be an advantage to vendors developing PW implementations as well as providers of PW services to minimize the differences between SS and MS-PWs. Operationally, the procedures for identifying (addressing), provisioning and troubleshooting a SS or a MS-PW should be similar. 5.2.1 Service Identification and Provisioning Models [PW CONTROL] specifies that a PW is uniquely associated with a set of connection identifiers: i.e. PWID (& U-PE pair) for PWID FEC or AGI, AII1, AII2 for the Generalized ID FEC. This proposal reuses the same service identifiers as SS-PW (PWID and Generalized ID FEC) to identify MS-PWs. From a provisioning perspective, this proposal is consistent with the existing models for SS-PWs. For MS-PWs, both a single ended and double ended model are possible as defined by [L2VPN SIGN], with no user intervention required at any S-PE node. In a MS-PW scenario, the S-PE nodes are aware of the PW. In the case of PWID addressing, in order to reuse the service identifiers for SS-PWs, the unique association between the U-PE pair and the PWID FEC must be maintained when transiting through the S-PE nodes. In the Generalized ID case a PW is identified by , Balus et.al. Expires November 2005 Page 7 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 PE2, > in one direction and by , PE1, > in the reverse direction [L2VPN SIGN]. This document proposes some extensions to LDP to address the requirements described above for consistent operational model across different PW types. The proposed solution re-uses the same L2FEC definitions as in [PW CONTROL] for identifying the virtual connections and a similar service provisioning model. The proposal does not preclude the use or support of existing Auto- discovery procedures (e.g. BGP-AD, RADIUS). 5.2.2 OAM It is important to support the end to end PW OAM concepts already described in [VCCV] and [PW Control]. To meet this requirement, the S-PE must participate in the negotiation of the PW OAM options and Status TLV. The current definition of PW OAM functions (e.g. VCCV (LSP-Ping, BFD)) [VCCV] are specified only for operation on a U-PE to U-PE basis. This means that the concatenation of PW switching of S-PEs in MS-PW appears as a PSN tunnel to the PW OAM function. Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis, will require changes in the OAM messages and procedures to indicate whether the OAM message is intended for the destination U-PE, intermediate S-PEs, or both. 5.3 Service Resiliency Several MPLS mechanisms exist today, including procedures defined in [RFC3036bis], [MPLS FRR], [Grace RS] etc. This draft does not preclude the use of any of these mechanisms. From a MS-PW perspective, Service Resiliency refers to the ability to choose a backup path in case of failure of the existing MS-PW path (including S-PE failure or any segment failure) [MH PWE3 Requirements]. 6. Information Model for Dynamic Signaling of MS-PWs In the current (SS) PW Architecture (see figure 1), the setup and maintenance of the PW connection is based on a direct, E-LDP Session between PE1 and PE2. As a result of the bidirectional nature of PWs, there is an association between the L2FEC, Source and Destination U- PEs. This association is derived from the information related to the (E-)LDP session between PEs and it is used as part of the end to end message exchange. In the case of a MS-PW (see figure 2), there is not an E-LDP session between U-PE1 and U-PE2. Instead two LDP Sessions are to be used to Balus et.al. Expires November 2005 Page 8 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 establish the MS-PW connection: LDP1 between U-PE1 and S-PE, LDP2 between U-PE2 and S-PE. The procedures defined in [PW Control] can not be applied to achieve the end to end signaling of the MS-PW. Specifically: . the identity of the PW endpoints can no longer be derived from the attributes of the local LDP session . the PWID U-PE pair association is lost. PWID becomes globally unique . for the Generalized ID the direct association between PW and <, PE2, > respectively , PE1, > is lost. . the forwarding of received Label Mapping (LM) messages is not allowed In order to support dynamic end to end signaling [MH PWE3 Requirements], while maintaining a consistent operational model with SS-PW, there is a need to carry the address of the Source and Destination U-PEs in the related LDP messages transiting through a (set of) S-PE node(s). This information could be transported in a number of ways: via new "fields" inserted in the existing Generalized ID FEC or via a new LDP TLV. Choosing one vehicle versus the other is orthogonal to the concepts described in this document as long as the Source and Destination information is explicitly carried in the signaling message and used to identify to route the PW signaling message from source to destination U-PE. We describe, in section 6.1, the details of the LDP TLV approach as it ensures backwards compatibility with existing deployments, offering support for both PWID and Generalized ID FECs. 6.1 MS-PW TLV Design We are introducing a new TLV, the Multi-Segment PW TLV, which is appended by the Source U-PE to the LDP messages related to a MS-PW. The following format is being proposed: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| MS-PW TLV (TBD) | MS-PW TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Source) U-PE (Mandatory) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Destination) U-PE (Mandatory) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Balus et.al. Expires November 2005 Page 9 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 - UF bits 00 - U equal 0 means that if the receiving PE does not understand the TLV, a notification must be returned to the message originator and the entire message must be ignored. - MS-PW TLV (TBD) - To be assigned by IANA. Identifies this TLV as a MS-PW. The presence of this TLV in LDP messages indicates this is a MS-PW. - MS-PW TLV Length - specifies the total length in octets of the TLV. - Source U-PE (Mandatory) - the address of the originating U-PE (e.g. U-PE1). In most of the cases it carries the IP loopback address of the Source U-PE, although other address types - e.g. IPv6, NSAP - could be supported. This field is used by a MS-PW Network Element for maintaining the uniqueness of PWID FECs and, optionally, in single sided provisioning the discovery of the remote U-PE by the Destination U- PE. When double sided provisioning is used, it is used to verify the remote U-PE against the provisioned value. - Destination U-PE (Mandatory) - the address of the Destination U-PE (e.g. U-PE2) Its value could be provisioned at the Source U-PE or is determined as part of the single-sided provisioning behavior [L2VPN SIGN]. The Destination U-PE address field is used to select the next hop through the MS-PW topology. The basic construct used to carry the Address of the Source and Destination U-PEs is the Prefix FEC Element which is already defined in [RFC3036bis]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (2) | Address Family | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC3232], IETF on-line data base, that encodes the address family for the address prefix in the Prefix field. Support for IPv4, IPv6, NSAP is already defined. Addition of other formats for further study: for example, AS numbers, URLs etc. Balus et.al. Expires November 2005 Page 10 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 - PreLen One octet unsigned integer containing the length in bits of the address prefix that follows. - Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary. 7. Signaling Procedures 7.1 Double-Sided Provisioning using PWID FEC Example The following section discusses an example of an end to end signaling walkthrough for a MS-PW using the architecture depicted in Figure 2. Let us assume that Double-sided provisioning and PWID FEC are being used to bring up the MS-PW built using segments PW1 and PW3 and using LDP1 and LDP2 sessions. Here are the required steps to setup the MS-PW between U-PE1 and U- PE2: 1. Service Provisioning a) at U-PE1: PWID = 40, Remote PE = U-PE2 (IP loopback) b) at U-PE2: PWID = 40, Remote PE = U-PE1 (IP loopback) 2. U-PE1 builds the MS-PW TLV by inserting its loopback address in the Source U-PE field and the address of U-PE2 in the Destination U-PE field. Next it appends the MS-PW TLV to the label mapping message associating FEC 40 with the corresponding PW service label. 3. Using the address of Destination U-PE (U-PE2), U-PE1 selects the next signaling hop (S-PE) using the information provided by the mechanisms described in section 7.3 and forwards the label mapping. 4. On receipt of the LM message, S-PE performs the following tasks: Verifies it has a PSN tunnel to U-PE1. If no tunnel is found a label release message is sent. a) Verifies it can support the requested OAM parameters (VCCV, Status TLV support). If the request cannot be supported a label release message is sent to U-PE1. b) If QoS information* was included in the LM message, it performs a CAC against the selected PSN Tunnel to U-PE1. If the CAC fails a label release message is sent to U-PE1. Balus et.al. Expires November 2005 Page 11 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 c) Checks to see if it is the Destination U-PE by comparing the address within the MS-PW TLV d-UPE field with its own address. If the addresses are not the same, S-PE looks for a next signaling hop to get to U-PE2 from its MS-PW topology and forwards the label mapping message to U-PE2, with the original L2FEC (for PWID 40) and MS-PW TLVs, replacing just the value of the service label in the Label TLV with one from its own label space. 5. When U-PE2 receives the LM message containing the MS-PW TLV, it performs tasks outlined in step 4. 6. U-PE2 then attempts to match the L2 FEC with its local provisioning. a) If the PWID FEC 40 and the U-PE1 address do not match the local provisioning, a label release message is sent. b) If the PWID FEC 40 is not yet provisioned, the label may be retained by virtue of liberal label retention. 7. The remaining U-PE2 processing of the PW label mapping message is defined in PWE3 control signaling [PW Control]. 7.2 General Procedures The following are generic procedures for signaling of an MS-PW. 1. The PW FEC (PWID or Generalized ID) and Destination U-PE is provisioned on both U-PEs. If single sided provisioning or auto discovery is used, the Destination U-PE needs only to be configured on one of the U-PEs. 2. The local U-PE builds the MS-PW TLV by inserting its local address in the Source U-PE field and the address of Destination U-PE in the Destination U-PE field. The MS-PW TLV and optional TLVs, (e.g. QOS TLV) are appended to the LM message. 3. When the next signaling hop receives the LM message, it verifies a PSN tunnel exists to the upstream MS-PW NE. If a PSN tunnel is not available a label release message is sent. However if the S- PE and the next signaling hop are directly connected, with no P device between them, the PSN tunnel may not be necessary [PW Control]. 4. If QoS information* was included in the LM message, the local NE performs a CAC against the selected PSN Tunnel to requesting NE. If the CAC fails a label release message is sent. 5. OAM parameters (VCCV, Status TLV support) are validated. If the request cannot be supported a label release message is sent to Balus et.al. Expires November 2005 Page 12 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 the upstream MS-PW NE. If the Destination U-PE address does not equal the MS-PW NE address, the mapping message must be forwarded to the next signaling hop. Note that the S-PE should not comply with the text of section 5.2.3 of [PW Control] i.e. should not initiate a LM message in the opposite direction towards U-PE1. Go to step 3. 6. When the Destination U-PE receives the LM message containing the MS-PW TLV, it attempts to match the L2 FEC with its local provisioning. a) If the L2 FEC and the Source U-PE address do not match the local provisioning, a label release message is sent. b) If the L2 FEC is not provisioned, the label maybe retained by virtue of liberal label retention 7. The remaining Destination U-PE processing of the PW label mapping message is as defined in PWE3 control signaling standard [PW Control] (if QoS information* is included it also performs tasks outlined in step 5). * The term "QoS Information" is used here to mean either one or both of Quantity (e.g. Bandwidth) and/or Quality (e.g. DiffServ) of Service. The detailed definition of the TLVs used to signal this information is outside the scope of this document. Description of possible TLV structures could be found in [RFC3270], [QoS TLV] or [TSPEC]. Note that the solution components described in this section allow for the Forward and Reverse Signaling directions to traverse the same or a different set of S-PEs. For example, to ensure the Reverse direction is going through the same set of S-PEs as the Forward one, the source U-PE and subsequent S-PEs in the Reverse direction may re-use the association between the ingress LDP session and the triplet (L2FEC, Source, Destination U-PEs), learned during the signaling of the PW segments in the Forward direction. The detailed mechanisms for ensuring the Forward and Reverse directions are traversing the same set of S-PEs depend on whether or not the other option (e.g. different Forward and Reverse paths) is required. Future version of the document will explore these details upon clarification of the related requirements in [MH PWE3 Requirements]. 7.3 Determining the Next Signaling Hop The procedures described in section 7.1 and 7.2 include a step where Source U-PE and the following S-PEs determine the next MS-PW capable node to which to forward the LDP message. We refer to this as next- Balus et.al. Expires November 2005 Page 13 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 signaling-hop. This information is used to identify the LDP session to forward the signaling messages to. The following section describes procedures that could be used to "discover" the next-signaling-hop in various portions of the network. 7.3.1 Static Provisioning of the next-signaling-hop The simplest way to build next-signaling-hop knowledge is by static provisioning. The provisioning of the next-signaling-hop (e.g., S- PE) is similar with the way IP static routes/default gateways are provisioned: e.g. in an U-PE, at nodal level, a default S-PE is provisioned manually when the MS-PW feature is enabled. This can be a simple and effective method, when the network topology is simple and well defined. Note that static provisioning may be used in combination with dynamic discovery. Indeed, some PW domains may use static provisioning while other PW domains along the multi-hop signaling path may use dynamic discovery within their domain. An example of this scenario is where many U-PEs in a given network will always use a well known primary and backup S-PE "gateway" as the next hop. This S-PE gateway may have many possible S-PE peers and may use a dynamic discovery mechanism to determine the next-signaling-hop of its S-PE peer for a given MS-PW. 7.3.2 "Discovery" Mechanisms for the next-signaling-hop The next-signaling-hop selection can also be determined by dynamically learning, for each PW Domain, the association between the Destination U-PE and the next-signaling-hop. There could be several mechanisms that allow dynamic discovery, advertisement of the next-signaling-hop. The focus of this section is on how this can be accomplished with BGP-based procedures. Note that these procedures may have an end-to-end scope (e.g. Inter-AS Use Case) or may be limited just to the PW Domain (e.g. MAN- WAN Use Case), depending upon the availability of BGP in the related MS-PW capable nodes. Since the Source U-PE knows apriori the address of the Destination U-PE, there is no need to advertise the above information per PW Attachment Circuit. The Destination U-PE will advertise only its loopback address (and not the Attachment Identifier (AI)) as part of well known BGP auto-discovery procedures - see [BGP AD], [L2VPN SIGN]. A new SAFI number is requested that indicates this advertisement is for Multi-Segment Pseudowires. The encoding of the U-PE address in the NLRI will be described in next revised versions of this document. Balus et.al. Expires November 2005 Page 14 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 As PW Endpoints are provisioned in the U-PEs, the Source U-PE will use this information to obtain the first S-PE hop (i.e., first BGP next hop) where the first PW segment will be established and subsequent S-PEs will use the same information (i.e. the next BGP next-hop(s)) to obtain the next-signaling-hop(s) on the path to the Destination U-PE. The procedures described in this draft are also compatible and could make use of the L2VPN provisioning models and related AD procedures described in [L2VPN SIGN] and respectively [BGP AD]. This will be applicable to the case where single-sided provisioning is desired, the auto-discovery procedures being run on a per PW basis, as new PWs are provisioned in the U-PEs. This is not an exhaustive list, merely examples of how discovery can be accomplished using BGP. It can also be envisioned, in some particular scenarios, that IGP with TE extensions could be used to control the selection of the next-signaling-hop, while avoiding non MS-PW aware devices (e.g. Ps, 2547 PEs). 8. Service Resiliency With the introduction of dynamic determination of the intermediate S-PEs, this proposal introduces the possibility of end to end (as well as segment) connection resiliency for MS-PWs. Options for end to end resiliency will be discussed in a future version 9. OAM Considerations This section deals with the Negotiation of the OAM Capabilities described in [VCCV], where the OAM functions (e.g. VCCV (LSP-Ping, BFD)) are specified only for operation on a U-PE to U-PE basis. Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis, require changes in the OAM messages and procedures to indicate whether the OAM message is intended for the destination U-PE, intermediate S-PEs, or both. These changes are for further study. 9.1 MS-PW Capabilities Common OAM capabilities should be supported on all U-PE and S-PE nodes in the MS-PW. MS-PW takes a least common denominator approach to OAM. The minimum OAM functionality supported on a MS-PW is label withdraw. Balus et.al. Expires November 2005 Page 15 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 9.1.1 PW Status Capability Negotiation PW Status capability is negotiated across the MS-PW when the MS-PW is first setup. Support for PW status notification is indicated by the presence of the status TLV in the label mapping message. PW Status capability negotiation at the U-PE occurs as described in [PWE3 CNTL]. It is strongly recommended that MS-PW implement PW status TLV. 9.1.2 VCCV Capability Negotiation VCCV capability is negotiated across the MS-PW when the MS-PW is first setup. Support for VCCV is indicated by the presence of the VCCV parameter in the interfaces parameter TLV. This parameter is included in the label mapping message within the parameter TLV as described in [VCCV] VCCV capability negotiation at the U-PE occurs as described in [VCCV] An S-PE successfully negotiates VCCV capability for the MS-PW when it support VCCV itself and the label mapping messages from its upstream and downstream neighbors indicate support for VCCV for a given MS-PW FEC. 9.2 PW Status Notification Operation PW Status notification at the U-PE occurs as described in [PWE3 CNTL]. When an S-PE receives a PW status notification message, the message is processed at the S-PE and propagated down stream along the control path. 9.3 VCCV Operation VCCV operation at the MS-PW Network Element (NE) occurs as described in [VCCV], with the S-PEs transparently forwarding these messages towards the destination U-PE. Support for MS-PW segment OAM, trace-route is for further study. 10. Security To be addressed later. 11. IANA Considerations To be addressed later. Balus et.al. Expires November 2005 Page 16 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 12. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13.References [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" draft- ietf-mpls-rfc3036bis-01.txt, IETF Work in Progress, November 2004 [MH PWE3 Requirements] Martini, Bocci, Bitar. "Requirements for inter domain Pseudo-Wires", draft-martini-pwe3-MS-PW-requirements- 01.txt, IETF Work in Progress, February 2005 [PW Control] Martini et.al. "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-16.txt, IETF Work in Progress, December 2004 [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", draft-ietf-pwe3-vccv-04.txt, February 2005 [L2VPN SIGN] Rosen et. al. "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-03.txt, Balus et.al. Expires November 2005 Page 17 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 IETF Work in Progress, February 2005 [PW Switching] Martini et.al. "Pseudo Wire Switching", draft- martini-pwe3-pw-switching-02.txt, IETF Work in Progress, February 2005 [RFC3270] Le Faucheur, et. al. "MPLS Support of Differentiated Services", RFC 3270, May 2002 [QoS TLV] Shah, et. al. "Qos Signaling for PW", draft-shah-pwe3-pw- qos-signaling-02.txt, IETF Work in Progress, February 2005 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 14. Author Information Andrew G. Malis Tellabs, Inc. 2730 Orchard Parkway San Jose, CA, USA 95134 Email: Andy.Malis@tellabs.com David McDysan MCI 22001 Loudoun County Pkwy Ashburn, VA, USA 20147 dave.mcdysan@mci.com Florin Balus Nortel 3500 Carling Ave. Ottawa, Ontario, CANADA balus@nortel.com Jeff Sugimoto Nortel 3500 Carling Ave. Ottawa, Ontario, CANADA sugimoto@nortel.com Mike Loomis Nortel 600, Technology Park Dr Billerica, MA, USA mloomis@nortel.com Balus et.al. Expires November 2005 Page 18 Internet Draft draft-balus-mh-pw-control-protocol-01 May, 2005 Paul Doolan Mangrove Systems IO Fairfield Blvd Wallingford, CT, USA 06492 pdoolan@mangrovesystems.com Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA, USA 94043 e-mail: ppan@hammerheadsystems.com Prayson Pate Overture Networks, Inc. 507 Airport Blvd, Suite 111 Morrisville, NC, USA 27560 Email: prayson.pate@overturenetworks.com Vasile Radoaca radoaca@hotmail.com Yuichiro Wada NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuke-ku Tokyo 163-1421, Japan yuichiro.wada@ntt.com