PWE3 Working Group Internet Draft Document: draft-balus-mh-pw-control-protocol-00.txt Expires: August 2005 Dave McDysan Florin Balus MCI Mike Loomis Jeff Sugimoto Nortel Networks February 2005 Multi-hop Pseudowire Setup and Maintenance using LDP Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract [MH PWE3 Requirements] describes the requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. A MH-PW is defined as a PW that spans a number of PW aware, tandem nodes called PW switching points (S-PE) in these domains. Balus et.al Expires August 2005 Page 1 Internet Draft draft-MH-PW-ldp.txt February, 2005 The current specification of the PW Architecture [PW ARCH] defines the PW as a single hop entity, connecting attachment circuits between two ultimate PEs (U-PE). The current procedures for establishing a single hop PW (SH 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 tandem 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 [MH-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........................................3 4. Relevant SH and MH-PW Architectures...........................4 5. Motivations and Resulting Design Requirements.................5 5.1 Satisfy the MH-PW requirements in [MH PWE3 Requirements].....5 5.1.1 Scalability and Inter-Domain Signaling and Routing.........5 5.1.2 Signaling Requirements.....................................6 5.2 Operational Consistency with SH-PWs..........................7 5.2.1 Service Identification and Provisioning Models.............7 5.2.2 OAM........................................................8 5.3 Service Resiliency...........................................8 6. MH-PW TLV Design..............................................8 7. S-PE List TLV Design.........................................10 8. Signaling Procedures.........................................11 8.1 Double-Sided Provisioning using PWID FEC Example............11 8.2 General Procedures..........................................12 9. Service Resiliency...........................................13 10. OAM Considerations...........................................13 10.1 MH-PW Capabilities........................................13 10.1.1 PW Status Capability Negotiation.........................13 10.1.2 VCCV Capability Negotiation..............................13 10.2 PW Status Notification Operation..........................14 10.3 VCCV Operation............................................14 10.4 MH-PW Traceroute..........................................14 11. Security.....................................................14 12. IANA Considerations..........................................14 13. Full Copyright Statement.....................................14 14. References...................................................15 15. Author Information...........................................15 1. Acknowledgements The editors gratefully acknowledge the following contributors: Elizabeth Hache, Hamid Ould-Brahim. Balus et.al. Expires August 2005 Page 2 Internet Draft draft-MH-PW-ldp.txt February, 2005 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 MH-PW. . Single-Hop PW(SH-PW). A PW setup directly between two (U-)PE devices. . Multi-hop PW (MH-PW). A static or dynamically configured set of two or more contiguous PW segments (SH-PW) that behave and function as a single point-to-point PW. Each end of a MH-PW by definition MUST terminate on a U-PE. . PW Switching Point (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments (SH-PW) in a MH-PW. A PW Switching Point is never the S-PE and the U-PE for a MH-PW. A PW switching point runs necessary protocols to setup and manage PW segments with other PW switching points and ultimate PEs. . MH-PW NE Multi-hop PW network elements. A device which can process or act on MH-PW TLVs. Both U-PE and S-PE are MH-PW NE. . PW Segment. A part of Multi-hop PW, which is set up between two PE devices, U-PEs and/or S-PEs. . Extended LDP session (E-LDP) an LDP session established using targeted discovery mode [RFC3036bis] 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 MH-PW is defined as a PW that spans a number of PW aware nodes in these domains. The current specification of the PW Architecture [PW ARCH] defines the PW as a single hop entity, connecting attachment circuits on just 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 typically 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 PW 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]. Balus et.al. Expires August 2005 Page 3 Internet Draft draft-MH-PW-ldp.txt February, 2005 The proposed procedures follow the guidelines defined in [RFC3036bis] and enable the reuse of existing addressing schemes (L2FECs) and other TLVs already defined for SH-PWs in [PW Control]. 4. Relevant SH and MH-PW Architectures The following two figures describe the reference models [MH PWE3 Requirements] to support SH and MH-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 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: MH-PW Reference Model Balus et.al. Expires August 2005 Page 4 Internet Draft draft-MH-PW-ldp.txt February, 2005 Figure 2 extends this architecture to show a multi-hop case. UPE1 and UPE2 provide a pseudowire from CE1 to CE2. Each UPE resides in a different PSN domain. As described in [MH PWE3 Requirements], a PSN domain may be different providers or a subset of nodes within a single provider domain. 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-hop PW (MH-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 MH-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. 5.1 Satisfy the MH-PW requirements in [MH PWE3 Requirements] 5.1.1 Scalability and Inter-Domain Signaling and Routing If a MH-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 MH-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 possibly thousands or even ten- thousands of U-PE nodes may specify a small number of gateway nodes as switching points (S-PE) nodes 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 and Balus et.al. Expires August 2005 Page 5 Internet Draft draft-MH-PW-ldp.txt February, 2005 alleviates the control plane scalability requirements described in the previous paragraphs. It also enables the end to end PW signaling through a chain of (E-)LDP sessions, using either a statically configured or 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. 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 permit manual provisioning of the MH-PW, but also enable an end to end MH-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 MH-PW that does not require any manual intervention at the S-PE nodes. Additionally, the signaling model includes options allowing the source to specify an (a set of) intermediate S-PE node(s) that should be traversed in the path of the MH-PW. The specification of S-PE nodes may be used to pin the MH-PW onto particular gateway S-PE nodes for traffic steering or for Inter-provider MH-PW purposes. This draft allows for either the same set of S-PE nodes to be traversed in each direction of the MH-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 SH-PWs In a Service Provider network it is understood that SH and MH-PWs will co-exist, possibly for an indefinite amount of time. Furthermore, it is foreseeable that existing SH-PWs may one day be Balus et.al. Expires August 2005 Page 6 Internet Draft draft-MH-PW-ldp.txt February, 2005 forced to migrate to a MH-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 SH and MH-PWs. Operationally, the procedures for identifying (addressing), provisioning and troubleshooting a SH or a MH-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 SH-PW (PID FEC and GID FEC) to identify MH-PWs. From a provisioning perspective, the proposal is consistent with the existing models for SH-PWs. For MH-PWs, both a single ended and double ended model are possible as defined by [L2VPN SIG], with no user intervention required at any tandem S-PE node. In a MH-PW scenario, the tandem S-PE nodes are aware of the PW [PW Switching]. In the case of PWID addressing, in order to reuse the service identifiers for SH-PWs, the unique association between the U-PE pair and the PWID FEC must be maintained when transiting through the S-PE nodes. 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. 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. Balus et.al. Expires August 2005 Page 7 Internet Draft draft-MH-PW-ldp.txt February, 2005 6. MH-PW TLV Design In the current (SH) 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 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 MH-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 establish the MH-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 MH-PW. Specifically: . the identity of the PW source and destination 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 . the forwarding of received LM messages is not allowed In order to support dynamic end to end signaling [MH PWE3 Requirements], while maintaining a consistent operational model with SH PW, there is a need to specify new TLVs and signaling procedures to be used when transiting through an S-PE node, via multiple LDP sessions. We are introducing a new TLV, the Multi-Hop PW TLV, which is appended by the Source U-PE to the LDP messages related to a MH-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| MH-PW TLV (TBD) | MH-PW TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Source) PE (Mandatory) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Destination) PE (Mandatory) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 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. - MH-PW TLV (TBD) - To be assigned by IANA. Identifies this TLV as a MH-PW. The presence of this TLV in LDP messages indicates this is a MH-PW. Balus et.al. Expires August 2005 Page 8 Internet Draft draft-MH-PW-ldp.txt February, 2005 - MH-PW TLV Length - specifies the total length in octets of the TLV - Source 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 MH-PW NE for maintaining the uniqueness of PWID FECs and, optionally, in single sided provisioning the discovery of the remote U-PE by the dU-PE. When double sided provisioning is used, it is used to verify the remote U-PE against the provisioned value. - Destination 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 behaviour [L2VPN Signaling] or BGP AD procedures [BGP AD]. The destination PE address field is used to select the next hop through the MH-PW topology. The basic construct used to carry the Address of the Source, and Destination 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. - 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. Balus et.al. Expires August 2005 Page 9 Internet Draft draft-MH-PW-ldp.txt February, 2005 7. S-PE List TLV Design The S-PE List TLV addresses the requirements for manual configuration or provisioning of MH-PWs (see Signaling section in [MH PWE3 Requirements]) 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| S-PE List TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-PE 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-PE 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-PE n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 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. - S-PE List TLV (TBD) - to be assigned by IANA. Represents the type associated with this TLV. This is an optional TLV that is used when the signaling path is to be configured at the source U-PE. The presence of this TLV in any LDP messages acts as an indicator that the Signaling path is pinned to a certain set of S-PE nodes. - Length specifies the total length in octets of the following fields. - S-PEi represents the address of the tandem node number i, with the numbering scheme starting from the source to the destination. The same Prefix FEC format is proposed for the S-PE address: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the Prefix FEC Element were already covered in the previous section. Balus et.al. Expires August 2005 Page 10 Internet Draft draft-MH-PW-ldp.txt February, 2005 8. Signaling Procedures 8.1 Double-Sided Provisioning using PWID FEC Example The following section discusses an example of an end to end signaling walkthrough for a MH-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 MH-PW built using segments PW1 and PW3 and using LDP1 and LDP2 sessions. Here are the required steps to setup the MH-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 MH-PW TLV by inserting its loopback address in the source PE field and the address of U-PE2 in the destination PE field. Next it appends the MH-PW TLV to the label mapping message associating FEC 40 with the corresponding PW service label. 3. Using the address of dU-PE (U-PE2), U-PE1 selects the next hop (S-PE) from its MH-PW topology and forwards the label mapping. 4. On receipt of the LM message, S-PE performs the following tasks: a) Verifies it has a PSN tunnel to U-PE1. If no tunnel is found a label release message is sent. b) 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. c) Checks to see if it is the dU-PE by comparing the address within the MH-PW TLV d-UPE field with its own address. As the addresses are not the same, S-PE looks for a next hop to get to U-PE2 from its MH-PW topology and forwards its own label mapping message (for PWID 40) to U-PE2. 5. When U-PE2 receives the LM message containing the MH-PW TLV, it performs tasks outlined in step 4. 6. It 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 maybe retained by virtue of liberal label retention. 7. The remaining U-PE2 processing of the PW label mapping message is per pwe3 control signaling standard [PW Control]. ** MH-PW Topology could be derived from information obtained from one or more routing protocols or generated by a gateway auto- Balus et.al. Expires August 2005 Page 11 Internet Draft draft-MH-PW-ldp.txt February, 2005 discovery process. Also, optionally, the gateway S-PE(s) can be explicitly specified through provisioning at the source U-PE1 and transported in the S-PE List TLV. 8.2 General Procedures The following procedures are for routing of an MH-PW. 1. The PW FEC (PWID or Generalized ID) and destination U-PE (dU-PE) is provisioned on both U-PEs. If single sided provisioning or auto discovery is used, the destination U-PE only needs to be configured on one of the U-PEs. 2. The local U-PE builds the MH-PW TLV by inserting its local address in the source PE field and the address of dU-PE in the destination PE field. The MH-PW TLV and optional TLVs, (QOS, S-PE List TLVs) are appended to the Label Mapping (LM) message. 3. If the S-PE List TLV is present, it will be used to determine the next MH-PW NE (the detailed processing of the S-PE list will be described in Version 1 of this draft). If the S-PE List TLV is not present, using the dU-PE address within the MH-PW TLV, the MH-PW NE selects the next hop from its MH-PW topology and forwards the label mapping message. 4. When the next hop receives the LM message, it verifies a PSN tunnel exists to the upstream MH-PW NE. If a PSN tunnel is not available a label release message is sent. However if the Pseudowire endpoints are immediately adjacent, the PSN tunnel may not be necessary [PW Control]. 5. OAM parameters (vccv, status tlv support) are validated. If the request cannot be supported a label release message is sent to the upstream MH-PW-NE. 6. If the dU-PE address does not equal the MH-PW NE address, the mapping message must be forwarded to the next hop. Go to step 3. 7. When the dU-PE receives the LM message containing the MH-PW TLV, it attempts to match the L2 FEC with its local provisioning. a) If the L2 FEC and the sU-PE address do not match the local provisioning, a label release message is sent. b) If the local provisioning does not have the dU-PE provisioned, it accepts the label mapping and uses or learns the dU-PE for this PW (Single-sided Provisioning [L2VPN Sig]). c) If the L2 FEC is not provisioned, the label maybe retained by virtue of liberal label retention 8. The remaining dU-PE processing of the PW label mapping message is per pwe3 control signaling] standard [PW Control. Balus et.al. Expires August 2005 Page 12 Internet Draft draft-MH-PW-ldp.txt February, 2005 9. 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 MH-PWs. Options for end to end resiliency will be discussed in a future version 10.OAM Considerations 10.1 MH-PW Capabilities Common OAM capabilities should be supported on all U-PE and S-PE nodes in the MH-PW. MH-PW takes a least common denominator approach to OAM. The minimum OAM functionality supported on a MH-PW is label withdraw. 10.1.1 PW Status Capability Negotiation PW Status capability is negotiated across the MH-PW when the MH-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 MH-PW implement PW status TLV. 10.1.2 VCCV Capability Negotiation VCCV capability is negotiated across the MH-PW when the MH-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 MH-PW when it support VCCV itself and the label mapping messages from its upstream and downstream neighbors indicate support for VCCV for a given MH-PW FEC. 10.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. Balus et.al. Expires August 2005 Page 13 Internet Draft draft-MH-PW-ldp.txt February, 2005 10.3 VCCV Operation VCCV operation at the MH-PW NE occurs as described in [VCCV]. MH-PW NE generates and process VCCV messages. When an S-PE receives a VCCV message and the ttl = 0, it processes the message. If TTL > 0, it is not processed, it is switched to the downstream MH-PW NE. 10.4 MH-PW Traceroute To be addressed later 11.Security To be addressed later. 12. IANA Considerations To be addressed later. 13. 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. Balus et.al. Expires August 2005 Page 14 Internet Draft draft-MH-PW-ldp.txt February, 2005 14.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-MH-PW-requirements- 00.txt, IETF Work in Progress, December 2004 [PW Control] Martini et.al. "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-14.txt, IETF Work in Progress, December 2004 [BGP AD] Unbehagen et. Al. "BGP-based Auto-Discovery for L2VPNs" draft-hlmu-l2vpn-bgp-discovery-01.txt, IETF Work in Progress, October 2004 [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", draft-ietf-pwe3-vccv-03.txt, June 2004 [L2VPN SIG] Rosen et. al. "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-02.txt, IETF Work in Progress, September 2004 [PW Switching] Martini et.al. "Pseudo Wire Switching", draft- martini-pwe3-pw-switching-01.txt, IETF Work in Progress, October 2004 15. Author Information David McDysan MCI 22001 Loudoun County Pkwy Ashburn, VA 20147 dave.mcdysan@mci.com Florin Balus Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA balus@nortel.com Jeff Sugimoto Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA sugimoto@nortel.com Mike Loomis Nortel Networks 600, Technology Park Dr Billerica, MA mloomis@nortel.com Balus et.al. Expires August 2005 Page 15