PWE3 Working Group Luca Martini (Ed.) Internet Draft Cisco Systems Inc. Expires: April 2007 Matthew Bocci (Ed.) Alcatel Florin Balus (Ed.) Alcatel October 2006 Dynamic Placement of Multi Segment Pseudo Wires draft-ietf-pwe3-dynamic-ms-pw-02.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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network 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. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. Martini, et al. [Page 1] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 Table of Contents 1 Specification of Requirements ........................ 3 2 Major Co-authors ..................................... 3 3 Acknowledgements ..................................... 3 4 Introduction ......................................... 3 4.1 Scope ................................................ 3 4.2 Terminology .......................................... 4 4.3 Architecture Overview ................................ 4 5 Applicability ........................................ 6 5.1 Requirements Addressed ............................... 6 5.2 Changes to Existing PW Signaling ..................... 6 6 PW layer 2 addressing ................................ 6 6.1 Attachment Circuit Addressing ........................ 7 6.2 S-PE addressing ...................................... 7 7 Dynamic placement of MS-PWs .......................... 8 7.1 Pseudo wire routing procedures ....................... 8 7.1.1 AII PW routing table Lookup aggregation rules ........ 9 7.1.2 PW Static Route ...................................... 9 7.1.3 Dynamic advertisement with BGP ....................... 9 7.2 LDP Signaling ........................................ 10 7.2.1 MS-PW Bandwidth Signaling ............................ 11 7.2.2 Active/Passive T-PE Election Procedure ............... 12 7.2.3 Detailed Signaling Procedures ........................ 13 7.2.4 Support for Explicit PW Path ......................... 14 8 Failure Handling Procedures .......................... 14 8.1 PSN Failures ......................................... 14 8.2 S-PE Failures ........................................ 14 9 Operations and Maintenance (OAM) ..................... 14 10 Security Considerations .............................. 15 11 IANA Considerations .................................. 15 11.1 LDP Status Codes ..................................... 15 11.2 BGP SAFI ............................................. 15 12 Full Copyright Statement ............................. 15 13 Intellectual Property Statement ...................... 16 14 Normative References ................................. 16 15 Informative References ............................... 17 16 Author Information ................................... 17 Martini, et al. [Page 2] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 1. Specification of Requirements 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. 2. Major Co-authors The editors gratefully acknowledge the following additional co- authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff Sugimoto. 3. Acknowledgements The editors also gratefully acknowledge the input of the following people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 4. Introduction 4.1. Scope [MS-REQ] describes the service provider requirements for extending the reach of pseudo-wires across multiple PSN domains. This is achieved using a Multi-segment Pseudo-Wire (MS-PW). 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. This architecture is described in [MS-ARCH]. The procedures for establishing PWs that extend across a single PWE3 domain are described in [RFC4447], while procedures for setting up PWs across multiple domains, or control planes are described in [PW- SEG]. The purpose of this draft is to specify extensions to the PWE3 control protocol [RFC4447], and [PW-SEG] procedures, to enable multi-segment PWs to be automatically placed. The proposed procedures follow the guidelines defined in [RFC3036bis] and enable the reuse of existing TLVs, and procedures defined for SS-PWs in [RFC4447]. Martini, et al. [Page 3] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 4.2. Terminology [MS-ARCH] provides terminology for multi-segment pseudo wires. This document defines the following additional terms: - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which assumes the active signaling role and initiates the signaling for multi-segment PW. - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that assumes the passive signaling role. It waits and responds to the multi-segment PW signaling message in the reverse direction. - Forward Direction: ST-PE to TT-PE. - Reverse Direction: TT-PE to ST-PE - Forwarding Direction: Direction of control plane, signaling flow - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs that compose an MS-PW, as well as the automatic selection of S- PEs. 4.3. Architecture Overview The following figure describes the reference models which are derived from [MS-ARCH] to support PW emulated services across multi-segment PWs. Martini, et al. [Page 4] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 Native |<-------------Pseudo Wire----------->| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ +-----+ +-----+ +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|.....PW.Seg't1........PW Seg't3......|----------| | | CE1| | | | | | | | | |CE2 | | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | +----+ | | |=========| |=========| | | +----+ ^ +-----+ +-----+ +-----+ ^ | Provider Edge 1 ^ Provider Edge 2 | | | | | | | | PW switching point | | | |<------------------- Emulated Service -------------------->| Figure 1: PW switching Reference Model Figure 1 shows the architecture for a simple multi-segment case. T- PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs are used to connect the attachment circuits (ACs) attached to T-PE1 to the corresponding AC attached to T-PE2. A PW on the tunnel across PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point and will be referred to as the PW switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are segments of the same MS-PW while PW Segment 2 and PW Segment 4 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, and PSN tunnels (e.g., PSN1 and PSN2) can be the same or different technology. An S-PE switches an MS-PW from one segment to another based on the PW identifiers. ( PWid , or AII ) How the Pw PDUs are switched at the S-PE depends on the PSN tunnel technology: in case of an MPLS PSN to another MPLS PSN PW switching the operation is a standard MPLs label switch operation. Note that although Figure 1 only shows a single S-PE, a PW may transit more one S-PE along its path. For instance, in the multi- provider case, there can be an S-PE at the border of one provider domain and another S-PE at the border of the other provider domain. Martini, et al. [Page 5] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 5. Applicability In this document we describe the case where the PSNs carrying the SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are left for further study. 5.1. Requirements Addressed Specifically the following requirements are addressed - see [MS-REQ]: - Dynamic End-to-end Signaling - Scalability and Inter-domain Signaling and Routing - Minimal number of provisioning touches (provisioning only at the T-PEs) - Same set of T-PEs/S-PEs for both directions of a MS-PWs - QoS Signaling, Call Admission Control - Resiliency - End-to-end negotiation of OAM Capability 5.2. Changes to Existing PW Signaling The procedures described in this document make use of existing LDP TLVs and related PW signaling procedures described in [RFC4447] and [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" section for details). 6. PW layer 2 addressing Single segment pseudo wires on an MPLS PSN use Attachment circuit identifiers for a PW using FEC 129. In the case of an automatically placed MS-PW, there is a requirement to have individual global addresses assigned to PW attachment circuits, for reachability , and manageability of the PW. Referencing figure 1 above, individual globally unique addresses MUST be allocated to all the ACs , and S- PEs composing an MS-PW. Martini, et al. [Page 6] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 6.1. Attachment Circuit Addressing The attachment circuit addressing is derived from [AII] AII type 2 shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Implementations of the following procedure MUST interpret the AII type to determine the meaning of the address format of the AII, irrespective of the number of segments in the MS-PW. A unique combination Global ID, Prefix, and AC ID parts of the AII type 2 will be assigned to each AC. In general the same global ID and prefix will be assigned for all ACs belonging to the same T-PE, however this is not a strict requirement. A particular T-PE might have more than one prefix assigned to it, and likewise a fully qualified AII with the same Global ID/Prefix but different AC IDs might belong to different T-PEs. For the purpose of MS-PW the AII MUST be globally unique across all interconnected PW domains. 6.2. S-PE addressing The T-PE may elect to select a known specific path along a set of S- PEs for a specific PW. This requires that each S-PE be uniquely addressable in terms of pseudo wires. For this purpose at least one AI address of the format similar to AII type 2 [AII] composed of the Global ID, and Prefix part only MUST be assigned to each S-PE. Martini, et al. [Page 7] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 7. Dynamic placement of MS-PWs [PW-SEG] describes a procedure for connecting multiple pseudo wires together. This procedure requires each S-PE to be manually configured with the information required to terminate and initiate the SS-PW part of the MS-PW. The procedures in the following sections describe an method to extend [PW-SEG] by allowing the automatic selection of pre-defined S-PEs, and automatically setting up a MS-PW between two T-PEs. In this document we consider the case where the PSNs carrying the SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are left for further study. 7.1. Pseudo wire routing procedures The AII type 2 described above contains a Global ID, Prefix, and AC ID. The TAII is used by S-PEs to determine the next SS-PW destination for LDP signaling. Once an S-PE receives a PW Setup message containing a TAII with an AII that is not locally present, the S-PE performs a lookup in a local Layer 2 AII PW routing table. If this lookup results in an IP address of the next PE that advertised reachability information for the AII in question, then the S-PE will initiate the necessary LDP messaging procedure for setting up the next PW segment. If the AII PW routing table lookup does not result in a IP address of the next PE, the destination AII has become unreachable, and the PW MUST fail to setup. In this case a label release MUST be returned to the T-PE with a status message of "AII Unreachable". T-PEs that receive a status message of "AII Unreachable" MAY attempt to establish the MS-PW at a later time or via an alternative next hop. Such alternate routing procedures are beyind the scope of this document. To allow for dynamic end-to-end signaling of MS-PWs, information must be present in S-PEs to support the determination of the next PW signaling hop. Such information can be provisioned (static route equivalent) on each S-PE system or disseminated via regular routing protocols (e.g. BGP). Martini, et al. [Page 8] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 7.1.1. AII PW routing table Lookup aggregation rules All PEs capable of dynamic multi segment pseudowire path selection, must build a PW routing table to be used for PW next hop selection. The PW addressing scheme (AII type 2 in [AII]) consists of a Global Id, a 32 bit prefix and a 32 bit Attachment Circuit ID. An aggregation scheme similar with the one used for classless IPv4 addresses can be employed. An (8 bits) length mask is specified as a number ranging from 0 to 96 that indicates which Least Significant Bits (LSB) are ignored in the address field when performing the PW address matching algorithm. 0 31 32 63 64 95 (bits) +-----------+--------+--------+ | Global ID | Prefix | AC ID | +-----------+--------+--------+ During the signaling phase, the content of the (fully qualified) TAII type 2 field from the FEC129 TLV is compared against routes from the PW Routing table. Similar with the IPv4 case, the route with the longest match is selected, determining the next signaling hop and implicitly the next PW Segment to be signaled. 7.1.2. PW Static Route For the purpose of determining the next signaling hop for a segment of the pseudo wire, the PEs MAY be provisioned with fixed route entries in the PW next hop routing table. The static PW entries will follow all the addressing rules and aggregation rules described in the previous sections. The most common use of PW static provisioned routes is this example of the "default" route entry as follows: Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling Hop = S-PE1 7.1.3. Dynamic advertisement with BGP Any suitable routing protocol capable of carrying external routing information may be used to propagate MS-PW path information among S- PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use [RFC2858] to propagate PW address information throughout the PSN. In the case of the MS-PW if the Source T-PE knows a priori the Martini, et al. [Page 9] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 address of the Terminating T-PE, there is no need to advertise a "fully qualified" address on a per PW Attachment Circuit. Only the T-PE Global ID, Prefix, and prefix length needs to be advertised as part of well known BGP procedures - see [RFC2858] and, [L2VPN-SIG]. As PW Endpoints are provisioned in the T-PEs, the ST-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 TT-PE. The PW dynamic path NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=TBD). The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as an IPv4 address, whenever the length of NextHop address is 4 octets, and as a IPv6 address, whenever the length of the NextHop address is 16 octets. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 96 bits encoded as defined in section 4 of [RFC2858]. This prefix is structured as follows: 0 31 32 63 64 95 (bits) +-----------+--------+--------+ | Global ID | Prefix | AC ID | +-----------+--------+--------+ Except for the default PW route, which is encoded as a 0 length prefix, the minimum prefix length is 32 bits. 7.2. LDP Signaling The LDP signaling procedures are described in [RFC4447] and expanded in [PW-SEG]. No new LDP Signaling components are required for setting up a basic automatically placed MS-PW. However some optional signaling extensions are described below. In additional, optional signalling extentions described in [PW-SEG] MAY be used, including the PW Switching Point TLV for recording the switching points through which a MS PW passes. Martini, et al. [Page 10] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 7.2.1. MS-PW Bandwidth Signaling In the SS-PW case the PW QoS requirements may easily be met by selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS requirements. However in the case of an automatically placed MS-PW the QoS requirements for a SS-PW not initiating on a T-PE MAY need to be indicated along with the MS-PW addressing. This is accomplished by including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is specified as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW BW TLV (0x096E) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forward SENDER_TSPEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse SENDER_TSPEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The complete definitions of the content of the SENDER_TSPEC objects are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to the datapath in the direction of ST-PE to TT-PE. The reverse SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. In the forward direction, after a next hop selection is determined, a T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine an appropriate PSN tunnel towards the next signaling hop. If such a tunnel exists, the MS-PW signaling procedures are invoked with the inclusion of the PW Bandwidth TLV. When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is selected, the S/T-PE MUST request the appropriate resources from the PSN. The resources described in the reverse SENDER_TSPEC are allocated from the PSN toward the originator of the message or previous hop. When resources are allocated from the PSN for a specific PW, then the PSN SHOULD account for the PW usage of the resources. In the case where PSN resources towards the previous hop are not available the following procedure MUST be followed: -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to the PSN tunnel. -ii. The S-PE MAY attempt to setup another PSN tunnel to accommodate the new PW QoS requirements. Martini, et al. [Page 11] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 -iii. If the S-PE cannot get enough resources to setup the segment in the MS-PW a label release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable" In the latter case, the T-PE receiving the status message MUST also withdraw the corresponding PW label mapping for the opposite direction if it has already been successfully setup. 7.2.2. Active/Passive T-PE Election Procedure When a MS-PW is signaled, Each T-PE might independently start signaling the MS-PW, this could result in a different path selected for each T-PE PW. To avoid this situation one of the T-PE MUST start the PW signaling ( active role ), while the other waits to receive the LDP label mapping before sending the respective PW LDP label mapping message. ( passive role ). The Active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be identified before signaling is initiated for a given MS-PW. The determination of which T-PE assume the active role SHOULD be done as follows: the SAII and TAII are compared as unsigned integers, if the SAII is bigger then the T-PE assumes the active role. The selection process to determine which T-PE assumes the active role MAY be superseded by manual provisioning. If an ST-PE receives a label mapping message the following procedure MUST be followed: If the ST-PE has already sent a label mapping message for this PW then the ST-PE must check that this label mapping message originated from the same LDP peer to which the corresponding label mapping message for this particular PW was sent. If it is the same peer, the the PW is established. If it is a different peer, then ST-PE MUST send a label release message, with a status code of "Duplicate AII" to the PE that originate the LDP label mapping message. If the PE has not yet sent a label mapping message for this particular PW , then it MUST send the label mapping message to this same LDP peer, regardless of what the PW TAII routing lookup result is. Martini, et al. [Page 12] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 7.2.3. Detailed Signaling Procedures On receiving a label mapping message, the S-PE MUST inspect the FEC TLV. If the receiving node has no local AII matching the TAII for that label mapping then the S-PE will check if the FEC is already installed for the forward direction: - If it is already installed, and the received mapping was received from the same LDP peer where the forward LDP label mapping was sent, then this label mapping represents signaling in the reverse direction for this MS-PW segment. - Otherwise this represents signaling in the forward direction. For the forward direction: -i. Determine the next hop S-PE or T-PE according to the procedures above. -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. If no tunnel exists to the next hop S-PE or T-PE the S-PE MAY attempt to setup a PSN tunnel. -iii. Check that a PSN tunnel exists to the previous hop. If no tunnel exists to the previous hop S-PE or T-PE the S-PE MAY attempt to setup a PSN tunnel. -iv. If the S-PE cannot get enough PSN resources to setup the segment to the next or previous S-PE or T-PE, a label release MUST be returned to the T-PE with a status message of "Resources Unavailable". -v. If the label mapping message contains a Bandwidth TLV, allocate the required resources on the PSN tunnels in the forward and reverse directions according to the procedures above. -vi. Allocate a new PW label for the forward direction. -vii. Install the FEC for the forward direction. -viii. Send the label mapping message with the new forward label and the FEC to the next hop S-PE/T-PE. For the reverse direction: -i. Install the received FEC for the reverse direction. -ii. Determine the next signaling hop by referencing the LDP sessions used to setup the LSP in the Forward direction. -iii. Allocate a new PW label for the reverse direction. -iv. Install the FEC for the reverse direction. -v. Send the label mapping message with a new label and the FEC to the next hop S-PE/ST-PE. Martini, et al. [Page 13] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 7.2.4. Support for Explicit PW Path The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be used to signal an explicit path for a MS-PW. An Explicit PW path may be required to provide a simple solution for 1:1 protection with diverse primary and backup path or to enable controlled signaling (strict or loose) for special PWs. Details of its usage to be provided in a future version. 8. Failure Handling Procedures 8.1. PSN Failures Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD follow the procedures defined in Section 8 of [PW-SEG]. 8.2. S-PE Failures For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be followed. However the ST-PE MAY re-signal the PW if an alternate path is available. 9. Operations and Maintenance (OAM) The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A PW switching point TLV is used [PW-SEG] to record the switching points that the PW traverses. In the case of a MS-PW where the PW Endpoints are identified though using a globally unique, FEC 129-based AII addresses, there is no PWID defined on a per segment basis. Each individual PW segment is identified by the address of adjacent S-PE(s) in conjunction with the SAII and TAII. In this case, the following type MUST be used in place of type 0x01 in the PW switching point TLV: Type Length Description 0x04 8 Global ID/Prefix of the S-PE The above field MUST be included together with type 0x02 in the TLV once per individual PW Switching Point following the same rules and procedures as described in [PW-SEG]. Martini, et al. [Page 14] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 10. Security Considerations This document specifies only extensions to the protocols already defined in [RFC4447], and [PW-SEG]. Each such protocol may have its own set of security issues, but those issues are not affected by the extensions specified herein. Note that the protocols for dynamically distributing PW Layer 2 reachability information may have their own security issues, however those protocols specifications are outside the scope of this document. 11. IANA Considerations This document uses several new LDP TLV types, IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The following value is suggested for assignment: TLV type Description 0x096E Bandwidth TLV 11.1. LDP Status Codes This document uses several new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The following value are suggested for assignment: Range/Value E Description Reference ------------- ----- ---------------------- --------- TBD 0 Bandwidth resources unavailable RFCxxxx TBD 0 Resources Unavailable RFCxxxx TBD 0 AII Unreachable RFCxxxx 11.2. BGP SAFI IANA needs to allocate a new BGP SAFI for "Pseudo Wire routing information" from the L2VPN SAFI registry. 12. Full Copyright Statement Copyright (C) The Internet Society (2006). 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 the information contained herein are provided on an Martini, et al. [Page 15] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 "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. 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. 14. Normative References [PW-SEG] Martini et.al. "Segmented Pseudo Wire", draft-ietf-pwe3-segmented-pw-00.txt, IETF Work in Progress, July 2005 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" draft-ietf-mpls-rfc3036bis-03.txt, IETF Work in Progress, October 2005 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini L.,et al draft-ietf-pwe3-control-protocol-17.txt, ( work in progress ), Martini, et al. [Page 16] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 June 2005. [AII] "Pseudowire Attachment Identifiers for Aggregation and VPN Autodiscovery", Chris M., et al draft-metz-aii-aggregate-01.txt, October 2006 (work in progress) February, 2006 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", RFC3212, January 2002. 15. Informative References [MS-REQ] Martini et al, "Requirements for Inter-domain Pseudo-Wires", draft-ietf-pwe3-ms-pw-requirements-02, Martini, et al., June 2006 [MS-ARCH] Bocci at al, "Architecture for Multi-Segment PWE3", draft-bocci-bryant-pwe3-ms-pw-arch-01.txt, September 2005. ( work in progress ) [L2VPN-SIG] E. Rosen, et Al. "Provisioning, Autodiscovery, and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06.txt, September 2005 ( work in progress ) [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 16. Author Information Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 e-mail: lmartini@cisco.com Matthew Bocci Alcatel, Voyager Place Shoppenhangers Road Maidenhead Berks, UK e-mail: matthew.bocci@alcatel.co.uk Martini, et al. [Page 17] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 Florin Balus Alcatel 701 E. Middlefield Rd. Mountain View, CA 94043 e-mail: florin.balus@alcatel.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 e-mail: nabil.bitar@verizon.com Himanshu Shah Ciena Corp 35 Nagog Park, Acton, MA 01720 e-mail: hshah@ciena.com Mustapha Aissaoui Alcatel 600 March Road Kanata ON, Canada e-mail: mustapha.aissaoui@alcatel.com Jason Rusmisel Alcatel 600 March Road Kanata ON, Canada e-mail: Jason.rusmisel@alcatel.com Yetik Serbest SBC Labs 9505 Arboretum Blvd. Austin, TX 78759 e-mail: Yetik_serbest@labs.sbc.com Martini, et al. [Page 18] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 Andrew G. Malis Tellabs, Inc. 2730 Orchard Parkway San Jose, CA, USA 95134 e-mail: Andy.Malis@tellabs.com Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 e-mail: chmetz@cisco.com David McDysan MCI 22001 Loudoun County Pkwy Ashburn, VA, USA 20147 e-mail: dave.mcdysan@mci.com Jeff Sugimoto Nortel 3500 Carling Ave. Ottawa, Ontario, CANADA e-mail: sugimoto@nortel.com Mike Duckett Bellsouth Lindbergh Center D481 575 Morosgo Dr Atlanta, GA 30324 e-mail: mduckett@bellsouth.net Mike Loomis Nortel 600, Technology Park Dr Billerica, MA, USA e-mail: mloomis@nortel.com Martini, et al. [Page 19] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-02.txt October 2006 Paul Doolan Mangrove Systems IO Fairfield Blvd Wallingford, CT, USA 06492 e-mail: 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 e-mail: prayson.pate@overturenetworks.com Vasile Radoaca radoaca@hotmail.com Yuichiro Wada NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuke-ku Tokyo 163-1421, Japan e-mail: yuichiro.wada@ntt.com Yeongil Seo Korea Telecom Corp. 463-1 Jeonmin-dong, Yusung-gu Daejeon, Korea e-mail: syi1@kt.co.kr Martini, et al. [Page 20]