PWE3 Working Group Himanshu Shah Internet Draft Ciena Corp Matthew Bocci Mustapha Aissaoui Jason Rusmisel Alcatel Yetik Serbest SBC Nabil Bitar Verizon Expires: January 2006 July 2005 Multi-Segment Pseudo Wire Signaling draft-shah-bocci-pwe3-ms-pw-signaling-01.txt 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. 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 Shah et al Expires January 2006 [Page 1] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract The pseudowire switching [6] draft describes how a Pseudowire can span across multiple PSN domains. This multi-segment PW (MS-PW) threads through one or more PEs that are not the endpoints of the PW and are called switching PE (S-PE). The switching PE at each hop is configured a-priori with two single hops PW information that enables it to conduct splicing between the two. The configuration of such information at each S-PE for possibly thousands of MS-PWs is cumbersome. We describe a mechanism whereby a S-PE can identify and process the PW control signaling with the information present in the signaling message in a manner that eliminates the requirement to configure PW splicing information. In this mechanism source PE inserts information about the destination PE and the PW endpoint that is recognized by the receiving PE to identify his role as a switching PE and engage in propagating the PW signal towards the destination PE. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................3 1.1. Scope.....................................................3 1.2. Architectural Model.......................................4 1.3. Overview of the proposed solution.........................7 2. Terminology....................................................9 3. Applicability..................................................9 4. Multi-segment Pseudo Wire Configuration........................9 5. MS-PW Information in the Label Mapping Message................11 Shah et al Expires January 2006 [Page 2] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 6. Next Hop Selection............................................12 7. PW Loop Detection.............................................13 8. Explicit Route support........................................13 9. Signaling procedures..........................................13 9.1. MS-PW signaling in the Forward Direction.................14 9.1.1. The role of SU-PE...................................14 9.1.2. The Role of S-PE....................................15 9.1.3. The Role of TU-PE...................................17 9.2. MS-PW Signaling in the Reverse Direction.................18 9.2.1. The Role of the TU-PE...............................18 9.2.2. The Role of the S-PE................................19 9.2.3. The Role of SU-PE...................................20 9.3. Signaling role...........................................21 10. PW status processing.........................................21 11. Peer PW ID...................................................22 12. Mechanisms for using Generalized ID FEC......................23 13. Resiliency...................................................23 14. Scalability..................................................24 15. Aspects for Further Study....................................24 16. Security Considerations......................................25 17. Acknowledgments..............................................25 18. References...................................................25 18.1. Normative References....................................25 18.2. Informative References..................................25 Author's Addresses...............................................26 Intellectual Property Statement..................................27 Disclaimer of Validity...........................................27 Copyright Statement..............................................27 Acknowledgment...................................................27 1. Introduction 1.1. Scope The multi-segment pseudo-wire requirements draft [5] describes a multi-segment pseudo wire as a concatenation of multiple single segment pseudo wires. [6] describes a solution in which, at each hop, two pseudo wires are configured; one-half of the pseudo wire to the preceding hop and other half of the pseudo wire to the succeeding hop. When a switching Shah et al Expires January 2006 [Page 3] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 PE receives PW signal on any half of the pseudo wire, it triggers a PW signal on the other half of pseudo wire in order for the signaling to thread through each hop all the way to the destination. The requirement of pre-configuring the segments of a pseudo wire at each hop presents administrative overhead which increases as the number of multi-segment pseudo wires increase. In addition, it limits the flexibility of ultimate PE to dynamically re-route a multi-segment pseudo wire through a different set of one or more switching PEs. The goal of the solution proposed in this document is to: o Eliminate the need to pre-configure pseudo wire segments at switching PEs. o Provide QOS information to each switching PE in order for them to intelligently manage the network resources. o Build on, as far as possible, the existing pseudo wire control protocol methodologies. o Provide mechanisms to build a backup pseudo wire. The following sections describe the solution with definition of additional information elements, the role of the source PE, switching PE and target PE in the creation, maintenance and termination of the multi-segment pseudo wire. The document does not describe the permutations and combinations of different control planes and PSN technologies. This subject is covered in detail in [6]. Among the several cases described in [6], the only case undertaken in this document is the multi-segment PW consisting of a concatenation of single-segment pseudo wires that are signaled dynamically. The signaling protocol proposed is based on the PW control protocol [3] using Targeted LDP in Downstream Unsolicited mode. The proposal in this document is intended as a logical progression from the existing signaling standards for single-segment PWs. As such, the basic signaling is kept simple. 1.2. Architectural Model Shah et al Expires January 2006 [Page 4] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 The following two figures describe the reference models, which are derived from [5] to support 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 service native service Figure 1: PWE3 Reference Configuration Shah et al Expires January 2006 [Page 5] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 Native |<-----------Pseudo Wire----------->| Native Layer2 | | Layer2 Service | |<-PSN1-->| |<--PSN2->| | Service (AC) V V V V V V (AC) | +----+ +-----+ +----+ | +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ | |----------|........PW1.........|...PW3........|----------| | | CE1| | | | | | | | | |CE2 | | |----------|........PW2.........|...PW4........|----------| | +----+ | | |=========| |=========| | | +----+ ^ +----+ +-----+ +----+ | ^ | Provider Edge 1 ^ Provider Edge 3 | | | | | | | | PW switching point | | | | | |<------------------- Emulated Service ------------------>| Figure 2: PW switching Reference Model Figure 2 extends the single segment PW architecture to show a generalized multi-segmented PW case. PE1 and PE3 provide PWE3 to CE1 and CE2. These PEs reside in different PSNs. A PSN tunnel extends from PE1 to PE2 across PSN1, and a second PSN tunnel extends from PE2 to PE3 across PSN2. PWs are used to connect the Attachment circuits (ACs) attached to PE1 to the corresponding ACs attached to PE3. Each PW on the tunnel across PSN1 is stitched to a PW in the tunnel across PSN2 at PE2 to complete the multi-segment PW (MS-PW) between PE1 and PE3. PE2 is therefore the PW switching point and will be referred to as the PW switching provider edge (S-PE). PW1 and PW3 are segments of the same MS-PW while PW2 and PW4 are segments of another pseudo wire. PW segments of the same MS-PW (e.g., PW1 and PW3) MUST be of the same PW type. Note that although Figure 2 only shows a single S-PE, a PW may transit more than one S-PE along its path. Shah et al Expires January 2006 [Page 6] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 |<--------------Pseudo Wire----------->| | Provider Provider | AC | |<----1---->| |<----2--->| | AC | V V V V V V | | +----+ +-----+ +----+ +----+ | +----+ | | |=====| |=====| |=====| | | +----+ | |-------|.....PW1..........PW2.........PW3.....|-------| | | CE1| | | | | | | | | | | |CE2 | +----+ | | |=====| |=====| |=====| | | +----+ ^ +----+ +-----+ +----+ +----+ ^ | PE1 PE2 PE3 PE4 | | ^ ^ | | | | | | PW switching points | | | | | |<------------------- Emulated Service --------------->| Figure 3: PW Switching Interprovider Reference Model Figure 3 shows the inter-provider reference model [5]. In this case, the two PSNs are administered by provider 1 and provider 2 respectively. PE2 and PE3 represent both ASBRs for those providers, and S-PEs for the inter-provider PWs. An MPLS interface is assumed between PE2 and PE3, which are interconnected using an inter-provider PSN tunnel. 1.3. Overview of the proposed solution This document proposes signaling methodologies for U-PEs and S-PEs such that a multi-segmented PW can be extended across multiple PSN domains without having to configure the intermediate PE hops. The key points of the procedure are briefly described below. Detailed procedures are provided in subsequent sections. o Both U-PEs are locally configured with PW specific information relevant to the PW ID FEC. o Each U-PE determines its role with respect to MS-PW signaling, i.e., active or passive, based on local configuration of the MS- PW. If the local configuration does not specify it, a U-PE compares its IP address with that of its peer U-PE. The higher address value takes an active role and initiates the MS-PW signaling, while the lower address value takes a passive role. The passive U-PE waits for the MS-PW signaling message to arrive from its peer. Shah et al Expires January 2006 [Page 7] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o The active U-PE (known as the source U-PE or SU-PE) prepares a MS- PW TLV and sends the MS-PW Label Mapping message to one or more next hop T-LDP peers. Section 6. describes how the next hop can be chosen. However, details of PW routing are outside the scope of this draft. o The switching PE (S-PE) recognizes the MS-PW label-mapping message based on the PW type, processes it, adds its own label, and then forwards it to a subset of T-LDP peers, as described above. Note that the S-PE may receive more than one MS-PW label-mapping message for a given MS-PW FEC. The following sections describe how this case is handled. o One or more copies of MS-PW label-mapping message may arrive through one or more paths at the last PW segment where the Target U-PE (TU-PE) resides. All the S-PEs on the target segment recognize the TU-PE to be their T-LDP peer, and thus only send the MS-PW Label Mapping message to that TU-PE. o The TU-PE may receive multiple MS-PW Label Mapping messages for the same MS-PW FEC from the set of previous hop S-PEs. It selects one as its primary path from a penultimate hop S-PE, processes the message, and advertises the Label Mapping in the reverse direction. If the methods proposed in Section 6. are not used, a label release is issued for each of the received Label Mappings that were not selected. This triggers a tear down of the dangling PWs in the reverse direction that were not selected for return path. Note however that the TU-PE can select a backup path at the same time of the primary path. In this case, it issues a Label Mapping message on both the primary and backup paths. All other labels are released. o The selected penultimate hop S-PE finds the MS-PW record created during the forward path processing and selects the previous hop for the MS-PW in the reverse direction. o The MS-PW signaling in the reverse direction continues on to pin down the bidirectional PW at each segment. Only one copy of MS-PW Label Mapping message is expected to arrive at SU-PE, except when the TU-PE attempts to establish a backup MS-PW at the same time. The procedures in this case are explained later in this document. The following sections discuss the detailed signaling procedures, TLV definitions, QOS characteristics, resiliency, OAM handling, etc. Shah et al Expires January 2006 [Page 8] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 2. Terminology [5] provides terminology for multi-segment pseudo wires. This document defines the following additional terms: o Source Ultimate PE (SU-PE). An Ultimate PE (U-PE), which assumes the active signaling role and initiates the signaling for multi- segment PW. o Target Ultimate PE (TU-PE). An Ultimate PE (U-PE) that assumes the passive signaling role. It waits and responds to the multi-segment PW signaling message in the reverse direction. o Forward Direction: SU-PE to TU-PE. o Reverse Direction: TU-PE to SU-PE o Forwarding Direction: Direction of data plane traffic flow 3. Applicability Content for this section will be added in a future revision of this document. 4. Multi-segment Pseudo Wire Configuration As per the PW ID FEC model, only the U-PEs are required to be configured for the MS-PW. There is no configuration required at the S-PEs for the MS-PW Signaling. The information configured at the SU-PE is as follows: o PW type - This is a new PW type called "Multi-Segment PW" type to be assigned by IANA. Shah et al Expires January 2006 [Page 9] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o TU-PE's IP address. The IP address of the remote PE is always configured for each PW. However, when the PW type is MS-PW, SU-PE recognizes the difference in modus operandi that is required. o Active/Passive Signaling Role - This optional configuration selects signaling role to be of type Active since this is the Source U-PE. Note that when this configuration is used, a corresponding configuration at the TU-PE is necessary. o QOS requirements for forward and reverse directions, such as PW traffic parameters - the value used by all PEs. The manner in which these traffic parameters are used to reserve resources and apply admission control at PEs in the forward and/or reverse directions (if applicable) is determined by local policy. The QOS related configuration is OPTIONAL. o MS-PW type for the U-PE - the value used only by U-PEs and not S- PEs. The values correspond to the types as those defined for SH-PW [4]. o MS-PW ID for the U-PE - the value used only by U-PEs and not S- PEs. The value has the same meaning as that defined SH-PW [3]. The MS-PW ID is signaled in the MS-PW TLV and is different from the PW ID in the PW ID FEC. This latter is renamed "Peer PW ID" and its use is described in Section 11. o TTL - the value used by all S-PEs. This is OPTIONAL. o Creation of disjoint path backup PW for this MS-PW FEC. The information configured at the TU-PE is a somewhat smaller set as this PE plays a passive role in MS-PW signaling. o SU-PE's IP address - used to verify and accept MS-PW signal o Active/Passive Signaling Role - This optional configuration selects signaling role to be of type Passive since this is the Target U-PE. Note that when this configuration is used, a corresponding configuration at the SU-PE is necessary. o QOS requirements for forward and reverse directions, such as PW traffic parameters - the value used by all PEs. This is OPTIONAL. Note that the QOS requirements contained in the Label Mapping message in the forwarding direction takes precedence over the configured information on the TU-PE. Shah et al Expires January 2006 [Page 10] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o MS-PW type for the U-PE - this must be the same value as the one configured at the SU-PE. o MS-PW ID for the U-PE - this must be the same value as the one configured at the SU-PE. o TTL - the value used by all S-PEs. This is OPTIONAL. 5. MS-PW Information in the Label Mapping Message The following information is needed in the MS-PW signaling for PW ID FEC 128. These additional fields are inside the MS-PW TLV. The information for generalized ID FEC (129) is described later. o Direction. Set as either forward or reverse o SU-PE's IP Address o TU-PE's IP Address o PW role - active or passive. This is OPTIONAL. o MS-PW ID as configured at SU-PE and TU-PE. This PW ID has relevance only at U-PEs. o MS-PW Type as configured at SU-PE and TU-PE. This PW type has relevance only at U-PEs. o Hop count. Incremented by each S-PE o TTL. Set by SU-PE and decremented by each S-PE. When TTL becomes zero, a Label Release is triggered in the reverse direction o PW relative forwarding priority: this is set to zero by the SU-PE in the forward label mapping message. It is set to a value higher than zero by the TU-PE in the one or many reverse label mapping messages. If more than one PW is established, e.g. primary and backup, the TU-PE uses this field to indicate to SU-PE the priority order in which it intends to use the primary and backup PW paths to forward traffic. When SU-PE receives the labels for the successful paths, it will start forwarding traffic using the label of the highest priority PW. It will also expect to receive traffic over the label of that same PW. Shah et al Expires January 2006 [Page 11] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o Path TLV. LDP [RFC 3036] defines the use of a Path TLV to collect the LSR hops during LDP signaling propagation. [6] describes the use of a Path TLV in the MS-PW architecture to build path trace through S-PEs. The MS-PW signaling leverages this construct to ensure that the backup path is disjoint from the primary path. o Requested QOS TLV [7]. This is set by SU-PE. Each S-PE uses this to check availability of resources on the transport tunnel. This is OPTIONAL. o Available QOS TLV. This is set by SU-PE when signaling MS-PW and modified by each S-PE upward or downward. The TU-PE and S-PEs may use this as path selection criteria for MS-PW in the respective direction. The SU-PE initializes the available QOS TLV same as requested QOS TLV. This is optional and must be absent if Requested QOS TLV is not present 6. Next Hop Selection This scheme can make use of one or more of the following mechanisms to choose the next hop. Details of these mechanisms and PW routing in general, is outside the scope of this draft. This list is not exclusive. o Each PE may intelligently choose the set of next hop PEs based on I-BGP / E-BGP queries. For example, in the inter-provider case shown in Figure 3, PE2 in provider 1 is an ASBR for AS1 and PE3 in provider 2 is an ASBR for AS2. They both have E-BGP session between each other and hence know about each other. PE2 and PE3 would also have T-LDP sessions between each other. Once the MS-PW label mapping message reaches PE3 in AS2, it would use IGP/BGP to reach the S-PE which is connected to another AS. o Each S-PE checks the QOS and load capacity in reverse direction, enabling this S-PE to determine if it is a suitable S-PE for the establishment of both directions of the PW. o If the S-PE is an ASBR, including the AS number in the MS-PW signaling message and preventing propagation to an AS that it has already traversed. Shah et al Expires January 2006 [Page 12] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o By configuring a "gateway" capability on each PE. In general, there are many PEs on a PSN. Some may be U-PEs, some are S-PEs and some are both. For S-PEs, some may be inter-area boundary nodes, some may be inter-routing domain boundary nodes and some may be inter-AS boundary nodes. Of these, some may be PW switching capable while others are not. A service provider can select a small set of PEs that are gateways and only those would process the MS-PE signals. E-BGP, I-BGP does not use this attribute as a criterion for the best next hop selection. Adding this additional check further narrows the breadth of MS-PW signaling scope. The use of these methods will minimize signaling overhead. 7. PW Loop Detection In order to provide a loop detection mechanism, a S-PE MAY support the OPTIONAL PW switching point TLV and associated procedures as described in [6]. 8. Explicit Route support In some situations it may be required that the decision on which next hop the S-PE should choose must be given to the source U-PE. For example, there may be administrative reasons why PWs must be constrained to particular route. Also, the SU-PE may have access to a traffic-engineering database for its local domain and may wish to determine the preferred exit point from its domain at a given time. Mechanisms for PW routing are outside the scope of this draft. 9. Signaling procedures The signaling procedures are described based on the direction in which the MS-PW signaling message is traveling and how each PE processes a message. The forward direction is considered to be from the preceding to the succeeding side with respect to the SU-PE i.e. from SU-PE to TU-PE. The first step in the signaling procedure is the determination of the role of the U-PE. When a PW is configured on a PE, it first determines if the PW is of type MS-PW. Note that a MS-PW does not necessarily mean that it has to pass through multiple PW segments. It is entirely possible that TU-PE may be T-LDP peer of the SU-PE as it resides on the same PSN domain. However, if the U-PE is not T-LDP peer and the PW type is MS-PW, then each U-PE engages in determining Shah et al Expires January 2006 [Page 13] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 its role in MS-PW signaling by checking the local configuration. If such information is not configured, each U-PE compares his own IP address with its peer's IP address. If the value is higher, U-PE assumes an active role and initiates the MS-PW signaling message. This will be a Label Mapping message. This U-PE is referred to as Source U-PE, or SU-PE. The passive U-PE awaits this MS-PW signaling message to arrive and is referred to as the TU-PE. 9.1. MS-PW signaling in the Forward Direction 9.1.1. The role of SU-PE The SU-PE initiates the MS-PW signal in the forwarding direction. The SU-PE dispatches PW signaling as described in [3]. The PW ID, also known as the Peer PW ID, is set as described in Section 11. The PW-type is set to the new "Multi-Segment PW" type. The MS-PW TLV is added in the optional TLV field of the Label Mapping message and is initialized as follows. o Direction field is set to Forward. o MS PW ID is set to the value configured locally by the user. o MS-PW TYPE is set to PWE3 service type as defined in [4] and is based on the type of Attachment Circuit present at the U-PEs. This value is configured by the user. o SU-PE IP address is configured as the IP address of the LDP entity. o TU-PE IP address is configured as IP of address of the TU-PEÆs LDP entity. o TTL is configured by the user. The TTL field represents the maximum number of hops that MS-PW signal is willing to pass through. o Hop count is set to zero. Shah et al Expires January 2006 [Page 14] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o The optional QOS parameters are set in the QOS TLV to indicate to each PE the QOS expectations for the reverse direction traffic. Optionally, an additional QOS TLV can also be dispatched marked as available QOS TLV. Each receiving PE can then modify this TLV upward or downward fashion based on what PW QOS can they honor. o The PW relative forwarding priority is set to zero. o Path TLV is included if Disjoint Backup path is desired. The SU-PE sends a Label Mapping message in downstream unsolicited fashion to one or more next hop targeted LDP peers. The same PW label is advertised to each peer. An associated use count can be maintained to account for number of T-LDP peers the MS-PW signal was sent to. This is useful in processing Label Release messages from the T-LDP peers. 9.1.2. The Role of S-PE When a PE receives a Label Mapping message, it recognizes the PW to be of type "Multi-Segment PW" based on the PW type. The PE determines its role as an S-PE based on the IP address of the TU-PE present in the MS-PW TLV. Note that the rationale for using the PW type field to recognize MS-PW processing is to cover cases such as where the TU-PE is a T-LDP peer of the SU-PE (i.e. SS-PW), where penultimate hop S-PE processing the MS-PW, etc. As an S-PE, the PE must qualify itself as a suitable candidate based on the following criteria. Note that the following check list is in addition to normal PE behavior in support of any PW signaling message such as MTU, sequence number, fragmentation, etc. o Check against any configured policy (such as security, tariff, etc) that prevents this from being a suitable S-PE for this particular MS-PW signal. o Examine the QOS serviceability in the appropriate direction(s) based on the QOS TLVs and local policy, if present. Note that the S-PE checks for resources and commits once only for a given MS-PW as identified by the triplet {SU-PE, TU-PE, MS-PW ID}. Shah et al Expires January 2006 [Page 15] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o If the PE knows of any suitable next hop T-LDP peer. This also includes the case where TU-PE is its T-LDP peer. o Decrementing the TTL results in TTL greater than zero. o If the MS-PW FEC already exists, then the MS-PW label mapping message is a duplicate. The S-PE handles the duplicate MS-PW label mapping message in the following manner to determine its suitability in propagating the signal forward: o Based on the local policy, the S-PE is not suitable for this MS-PW. o If the Peer PW ID received from the predecessor for the MS-PW FEC is not unique, S-PE is not suitable for this MS-PW. o If the next hop T-LDP peer is not a TU-PE and the only suitable next hop T-LDP peer is the one already selected by a previous instance of the MS-PW signal for this MS-PW FEC, then S-PE is not suitable for this MS-PW. o Otherwise the S-PE is suitable. Note that allowing more than one instance of a MS-PW label mapping to transit through an S-PE for the same MS-PW FEC enables a previously disjoint backup path, which converges at the S-PE, to continue forward as a partially disjointed path. If S-PE determines itself to be unsuitable for forwarding the MS-PW signal, it issues the Label Release message to the sender of the Label Mapping message. If S-PE does determine that it is a suitable S-PE, it performs following steps in order to forward the MS-PW signal. o Record the Peer PW ID, PW label and senders IP address. Note that these values are unique for each MS-PW signaling message it receives, and in particular that the Peer PW ID is significant only within the context of the senderÆs IP address o Allocates the required QOS resources from the PSN tunnels in the reverse direction. o Determine the next hop T-LDP peer(s). If the TU-PE is a T-LDP peer, then this PE becomes the sole candidate. If not, then the criteria used to select the candidates are not specified in this document, but may be based on mechanisms specified in Section 6. The IP address of each of these is recorded. Shah et al Expires January 2006 [Page 16] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o Allocate a new Peer PW ID and a PW label. Note that this Peer PW ID uniquely represents this instance of MS-PW FEC. o Increment the hop count. o Decrement the TTL. o Adjust the Available QOS TLV, if present, based on the resources it is willing to commit for the PW in the reverse direction. o If a use count is maintained, set the use count to the number of T-LDP peers to which the MS-PW Label Mapping will be advertised. o Record the state of the PW. o If Path TLV is present, insert the S-PE's LSR Identifier. The IP address of the SU-PE, MS-PW ID and TU-PE tuple along with the newly created Peer PW ID can be used as the key to fetch the information recorded for MS-PW. 9.1.3. The Role of TU-PE The MS-PW signaling thus passes along the PW segments through one or more S-PEs to arrive at the TU-PE. It is possible that some MS-PW paths may perish mid-way for various reasons such as TTL becoming zero, no suitable next hop, could not satisfy the QOS requirement, etc. When an S-PE can not 'forward' the MS-PW signaling message, it triggers a tear-down in the reverse direction of the MS-PW path passing through it. It is possible that the TU-PE may receive more than one MS-PW signaling message. Each received MS-PW label mapping message represents a PW path that varies from the other. The TU-PE may use some heuristics and or policy to select one MS-PW as the primary PW path. It is also possible to select one or more MS-PW paths as backup PW paths. A TU-PE performs the following procedures for each MS-PW Label Mapping that a TU-PE receives: o Matches the MS-PW FEC with the configured PW-FEC. Shah et al Expires January 2006 [Page 17] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o It 'responds' to the selected S-PE from which the Label Mapping message was received with the MS-PW FEC TLV with the reverse direction bit set. o A label release is sent to those S-PEs that were not selected with reverse direction bit set. o The TU-PE becomes the PW path terminator. For the unsuccessful (i.e. un-selected) paths, reverse tear down is triggered by the TU-PE. o The TU-PE is also responsible for triggering the reverse path selection of its choice. This choice could be based on only the penultimate hop S-PE from which it receives the forward direction signaling message, or by comparing the available QOS TLV from various signaling messages. o When a disjoint backup path is desired, the TU-PE uses the Path TLV of the selected primary path as the exclude list to select the backup path (during reverse signaling propagation) that is disjoint. 9.2. MS-PW Signaling in the Reverse Direction 9.2.1. The Role of the TU-PE The TU-PE is responsible for generating the MS-PW Label Mapping message in the reverse direction for one or more MS-PWs if applicable. The following procedures are performed for each reverse MS-PW signaling message: o Set the direction flag to Reverse in the MS-PW TLV o Allocates a Label for the Label Mapping message o Use the Peer PW ID and MS-PW ID from the received Label Mapping message unchanged. o Set the "PW relative forwarding priority" field of this PW path to the desired value. A higher priority value indicates to the SU-PE that this path is selected over all other paths to transmit traffic in both directions. o Allocate the QOS resources from the PSN tunnel to the penultimate hop S-PE. Shah et al Expires January 2006 [Page 18] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o Issue a Label Release to the sender S-PE(s) for unselected MS-PW Label Mapping messages for the same MS-PW FEC as identified by SU- PE IP address, MS-PW ID and TU-PE IP address. It is possible that an S-PE may need to release Label Mapping message during the reverse path MS-PW establishment. The S-PE would initiate the path tear down in the preceding and the succeeding MS-PW segments. The tear down of the specific instance of MS-PW path propagates in both directions towards SU-PE and TU-PE as described in section 9.1. 9.2.2. The Role of the S-PE When an S-PE receives the MS-PW signaling message in the reverse direction, it fetches the MS-PW record using the Peer PW ID present in the MS-PW signal. It verifies the PW FEC using SU-PE IP address, MS-PW ID and TU-PE IP address triplet. Note that the sender of the MS-PW signaling message in the reverse direction is responsible for using the same Peer PW ID that was received when handling the corresponding MS-PW signal in the forwarding direction. The Peer PW ID uniquely represents a specific instance of MS-PW FEC. If the S-PE finds that a label was already installed for this MS-PW, i.e., this is an attempt for a backup PW path it performs following operations, o If Disjoint Backup Path is dictated as indicated by the flag in the signal or a local policy, it releases the reverse direction label back to the sending S-PE or TU-PE. o Otherwise, it selects the predecessor PE (and thus the reverse direction) based on the Peer PW ID it received in the signal that represent the specific instance of MS-PW path in forwarding direction. The S-PE performs a check of resources in the respective direction based on the requested or available QOS TLVs and the CAC behavior flag present in MS-PW Label Mapping message. If resources are not available, the S-PE initiates path teardown in both directions towards U-PEs for this instance of MS-PW path. Once the S-PE has selected the downstream T-LDP peer for the reverse path, it performs following steps for processing a MS-PW Label Mapping in the reverse direction, Shah et al Expires January 2006 [Page 19] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 o The S-PE has a record of the MS-PW created during forward processing of the same MS-PW signaling message. It fetches the predecessorÆs IP address and PW ID and inserts that in the Label Mapping message o Allocates a PW label for the forward data path for the Label Mapping message o Programs the bidirectional PW as follows, o Forward direction (SU-PE->TU-PE) using the label advertised to the downstream T-LDP peer in the reverse direction MS-PW signaling, and the label received from the upstream neighbor for the reverse direction of the MS-PW signaling. o Reverse direction (SU-PE<-TU-PE) using the label received from the upstream neighbor and the label advertised to the downstream neighbor during MS-PW signaling in the forward direction. o Allocates the required QOS resources from the PSN tunnels in the forward and reverse direction. o For all the predecessor's T-LDP peers that had advertised a MS-PW Label Mapping in the forwarding direction but were not selected for reverse path, the S-PE issues a Label Release message. An S-PE may also receive a Label Release message for the MS-PW signal that it had sent in the forwarding direction. As noted earlier, Peer PW ID in the Label Release message represents a specific instance of MS-PW path. However, when an S-PE is a fork for the MS-PW paths in the forwarding direction, more than one instance of MS-PW paths map to a single MS-PW path in reverse direction. In such case, a 'use count' variable may be maintained. When the use count becomes zero when decrementing for each reverse path Label Release message received, a Label Release message is generated in the reverse path towards the SU-PE. 9.2.3. The Role of SU-PE The SU-PE is expected to receive one, or more if backup PWs are supported, MS-PW signaling messages in the reverse direction. If more than one Label Mapping message was received, the SU-PE will start forwarding traffic using the label of the highest priority PW. It will also expect to receive traffic over the label of that same PW. In that case, a bi-directional, possibly multi-segmented, pseudo-wire Shah et al Expires January 2006 [Page 20] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 has been set up between SU-PE and TU-PE. As a last step, the SU-PE performs PW programming in its forwarding database to enable the dataflow between the Attachment Circuit and the pseudo wire. The SU-PE may also receive a set of Label Release messages, which denote unsuccessful attempts to establishing the multi-segment PWs through different paths. These messages are processed for clean-up purposes. It is also possible that none of the MS-PW signaling messages reached the TU-PE and resulted in Label Release messages returning back for the whole set. The SU-PE may choose to schedule a retry for such cases or wait for operator intervention. 9.3. Signaling role As per the discussion above the following is true. 1. SU-PE always o Generates Label Mapping message (MS-PW Signal) in forward direction. o Processes Label Mapping message (MS-PW Signal) in reverse direction. 2. TU-PE always a. Processes Label Mapping message (MS-PW Signal) in forwarding direction b. Generates a Label Mapping message (MS-PW Signal) in reverse direction in response to SU-PE MS-PW Signaling message (Label Mapping). 3. S-PEs processes and propagates MS-PW signal in both direction. 10. PW status processing A multi-segment PW includes the SU-PE, a set of one or more S-PEs and a TU-PE. All members are responsible for maintaining a consistent view of the PW status from end to end. If a defect occurs at any mid point, the S-PE detecting the failure is responsible for generating PW status to its preceding and succeeding T-LDP peers. Upon receipt Shah et al Expires January 2006 [Page 21] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 of such (PW Status) messages, an S-PE is responsible for processing and propagating along in the forwarding direction (i.e. in the opposite direction from where it received). In essence, a PW Status message generated at the midpoint should ripple through the rest of the PW segments in both the directions towards the endpoints. The S- PEs should only use forwarding/not-forwarding status and should leave the incoming/outgoing breakdown of the status bits to the U-PEs only. In addition, whenever an S-PE receives a PW status message, it must check the forwarding capabilities between the two PW segments. If one or both PSN tunnels fails, it should mark the PW status accordingly before propagating it in the forwarding direction. This is important for handling the simultaneous multiple midpoint failures at different PW segments for a given multi-segment PW. The PW Status TLV is OPTIONALLY included in the Label Mapping messages generated by the SU-PE, S-PEs and TU-PEs. 11. Peer PW ID Traditionally, the PW ID represents a handle that each PE uses as a key to fetch the Pseudo wire related information. For MS-PWs, we have introduced the MS-PW ID that resides in the MS-PW TLV. The MS-PW ID is relevant only to U-PEs. The PW ID present in the PW FEC of the Label Mapping message is re-defined in this proposal as Peer PW ID. The Peer PW ID is dynamic in nature for S-PEs such that the sender of the Label Mapping message 'allocates' a new PW ID for each received PW FEC used in MS-PW Signal. The receiver of the Label Mapping message is responsible for: o Recording the PW ID of the sender. o Using the PW ID of the sender a.k.a Peer PW ID, whenever it sends an LDP message for MS-PW. This includes Label Messages (mapping, withdraw and release) and Notification messages (PW status, PW QOS updates, etc). o Using its own PW ID when communicating with the downstream T-LDP peer since he was the sender of the MS-PW Signal. o There are no new PW IDs generated for the MS-PW Signal traversing in the reverse path. That is, PW IDs are generated only when signaling a MS-PW in forward direction. o On the return path, each PE (starting with TU-PE) would use its predecessor's PW ID in the PW ID FEC. Shah et al Expires January 2006 [Page 22] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 12. Mechanisms for using Generalized ID FEC The generalized ID FEC (GID FEC) consists of SAI, TAI and AGI information. The SAI holds IP address (as present in LDP-ID) and Attachment Identifier information for the SU-PE, while the TAI holds IP address (as present in LDP-ID) and Attachment Identifier information for the TU-PE. The AGI MAY represent the VPN identifier, for example. The GID FEC eliminates the need for some of the information present in MS-PW TLV. However, for consistency, it is recommended that MS-PW TLV should be included. It also eliminates the need for generating a PW ID at each hop in the forwarding path as is the case PW ID FEC. The signaling procedures for the SU-TE, S-PEs and TU-PE remain the same as described above. Each MS-PW signaling message needs to be processed within the context of the direction MS-PW signal is flowing. In single-sided signaling, TU-PE does not have to be configured with MS-PW specific information. We note an exception to the handling of the generalized ID FEC. As per [3], the receiver of GID FEC must respond 'immediately' either with a corresponding Label Mapping message or with a Label Release message. An exception is required when handling MS-PW Signaling, whereby the recipient of the MS-PW signal must wait for corresponding MS-PW Label Mapping, or a Label Release in the reverse direction. This is not a significant deviation from the common practice as there is no requirement that sender bind a Label Mapping message with a timer and issue a Label Withdraw if a response is not received with certain time. 13. Resiliency The multi-segment pseudo wire set up is an involved process and the nodal failures are not protected without having to initiate another MS-PW setup. Hence it is prudent to provide a mechanism whereby backup MS-PW(s) are setup during initial MS-PW establishment. The proposed scheme described in this document is well suited for this requirement as multi path PWs can be generated during initial Shah et al Expires January 2006 [Page 23] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 MS-PW setup. When TU-PE receives multiple MS-PW signals, it may select one or more Backup PW paths and set its priority in the MS-PW TLV. The S-PEs continue to process and forward the MS-PW signaling in the reverse direction in the same manner as the primary PW. It is possible that reverse path signaling may not succeed. For this reason, TU-PE should try to initiate multiple PW backup path setup through different penultimate hop S-PEs. The Backup PWE3(s) remain established and available to become the primary PW. The SU-PE and TU-PE let the data flow only on the primary PWE3. The following criteria or policies can be used by the SU-PE and TU-PE to switch the data flow to a higher priority backup PW. . Primary PW is torn down - e.g. in the case of a S-PE nodal failure . Primary PW is in the non-forwarding state for a long time e.g. due to one or more PSN tunnel failures at mid points In either case, switch over must be co-ordinated between SU-PE and TU-PE. The details of this or other schemes will be discussed in the future revisions. 14. Scalability In this scheme, the label resources are used efficiently. The scheme allows a high probability of finding the most suitable PW path without needing a crank back mechanism, creation of one or more disjoint backup pseudo wire paths during the initial setup, etc. Signaling overhead is minimized through the use of mechanisms described in Section 6. 15. Aspects for Further Study The following aspects will be addressed in a future revision: o Applicability of this solution is addressing the requirements of [5]. o How traffic is switched from primary to backup PWs on failure of the primary. o MS-PWs in the context of a carrier's carrier environment. Shah et al Expires January 2006 [Page 24] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 16. Security Considerations The security aspects of this solution will be discussed at a later time. 17. Acknowledgments The authors wish to acknowledge David Watkinson from Alcatel, Mark Libby from Ciena and Eric Gray from Marconi for their contribution to this proposal. 18. References 18.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [3] Martini et. Al., "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-16.txt, March 2005 (work in progress) [4] Martini et. Al., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-06.txt, September 2004 (work in progress) [5] Martini et al., "Requirements for inter domain Pseudo-Wires", draft-martini-pwe3-MS-pw-requirements-01.txt, February 2005 (work in progress) 18.2. Informative References [6] Martini et. Al., "Pseudo Wire Switching", draft-martini-pwe3- pw-switching-02.txt, February 2005 (work in progress) [7] Shah et al., "Qos Signaling for PW", draft-shah-pwe3-pw-qos- signaling-02.txt, February 2005 (work in progress) Shah et al Expires January 2006 [Page 25] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 Author's Addresses Himanshu Shah Ciena Corp 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Matthew Bocci Alcatel Voyager Place Maidenhead Berks, UK Email: matthew.bocci@alcatel.co.uk Mustapha Aissaoui Alcatel 600 March Road Kanata ON, Canada Email: mustapha.aissaoui@alcatel.com Jason Rusmisel Alcatel 600 March Road Kanata ON, Canada Email: Jason.rusmisel@alcatel.com Yetik Serbest SBC Labs 9505 Arboretum Blvd. Austin, TX 78759 Email: Yetik_serbest@labs.sbc.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Shah et al Expires January 2006 [Page 26] Internet-Draft Multi-segment Pseudo-Wire Signaling 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shah et al Expires January 2006 [Page 27]