Network Working GroupNabil Bitar (Editor) Internet DraftN. Bitar, Ed. Request for Comments: 5254 VerizonIntended status:Category: InformationalExpiration Date: December 2007 Luca Martini (Editor) Matthew Bocci (Editor)M. Bocci, Ed. Alcatel-Lucent L. Martini, Ed. CiscoSystemsSystems, Inc.Alcatel-Lucent June 2007July 2008 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)draft-ietf-pwe3-ms-pw-requirements-07.txtStatus ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.this memo is unlimited. Abstract This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. Table of Contents1 Specification of Requirements ........................ 4 2 Acknowledgments ...................................... 4 31. Introduction......................................... 4 3.1....................................................3 1.1. Scope................................................ 4 3.2......................................................3 1.2. Architecture......................................... 4 4...............................................3 2. Terminology.......................................... 7 5.....................................................6 2.1. Specification of Requirements ..............................6 3. Use Cases............................................ 8 5.1.......................................................7 3.1. Multi-Segment Pseudowire Placement Mechanisms........ 11 6..............9 4. Multi-Segment Pseudowire Requirements................ 11 6.1..........................10 4.1. All Mechanisms....................................... 11 6.1.1............................................10 4.1.1. Architecture......................................... 11 6.1.2.......................................10 4.1.2. Resiliency........................................... 12 6.1.3.........................................11 4.1.3. QualityOfof Service................................... 13 6.1.4.................................11 4.1.4. Congestion Control................................... 14 6.2.................................12 4.2. Generic Requirements for MS-PW Setup Mechanisms...... 15 6.2.1...........13 4.2.1. Routing.............................................. 16 6.3............................................14 4.3. StaticallyconfiguredConfigured MS-PWs......................... 16 6.3.1..............................15 4.3.1. Architecture......................................... 17 6.3.2.......................................15 4.3.2. MPLS-PWs............................................. 17 6.3.3...........................................15 4.3.3. Resiliency........................................... 17 6.3.4.........................................15 4.3.4. Quality ofservice ................................... 17 6.4Service .................................16 4.4. SignaledPW-segments ................................. 18 6.4.1PW Segments ......................................16 4.4.1. Architecture......................................... 18 6.4.2.......................................16 4.4.2. Resiliency........................................... 18 6.4.3.........................................16 4.4.3. Quality of Service................................... 19 6.4.4.................................17 4.4.4. Routing.............................................. 19 6.5............................................17 4.5. Signaled PW / Dynamic Route.......................... 20 6.5.1...............................18 4.5.1. Architecture......................................... 20 6.5.2.......................................18 4.5.2. Resiliency........................................... 20 6.5.3.........................................18 4.5.3. Quality of Service................................... 20 6.5.4.................................18 4.5.4. Routing.............................................. 20 7............................................18 5. Operations and Maintenance (OAM)..................... 21 8...............................19 6. Management of Multi-Segment Pseudowires.............. 22 8.1........................20 6.1. MIB Requirements..................................... 23 8.2..........................................20 6.2. Management Interface Requirements.................... 23 9.........................21 7. Security Considerations.............................. 23 9.1........................................21 7.1. Inter-Provider MS-PWs................................ 23 9.1.1 Data-plane.....................................21 7.1.1. Data-Plane Security Requirements..................... 24 9.1.2 Control-plane...................21 7.1.2. Control-Plane Security Requirements.................. 25 9.2................23 7.2. Intra-Provider MS-PWs................................ 27 10 Intellectual Property Statement ...................... 27 11 Full Copyright Statement ............................. 28 12 IANA Considerations .................................. 28 13.....................................25 8. Acknowledgments ................................................25 9. References .....................................................25 9.1. Normative References................................. 28 14......................................25 9.2. Informative References............................... 29 15 Author Information ................................... 29....................................25 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. Acknowledgments The editors gratefully acknowledge the following contributors: Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel- Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), David McDyson (Verizon), Rahul Aggawal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE) and Stewart Bryant (Cisco). 3.Introduction3.1.1.1. Scope This document specifies requirements for extending pseudowires across more than one packet switched network (PSN) domain and/or more than one PSN tunnel. These pseudowires are called multi-segment pseudowires(MS-PW).(MS-PWs). Requirements for single-segment pseudowires(SS-PW)(SS-PWs) that extend edge to edge across only one PSN domain are specified in [RFC3916]. This document is not intended to invalidate any part of [RFC3985]. This document specifies additional requirements that apply to MS-PWs. These requirements do not apply to PSNs that only support SS-PWs.3.2.1.2. Architecture The following three figures describe the reference modelswhichthat are derived from [RFC3985] to support PW emulated services. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudowire ------->| | | | | | | | |<-- 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 Figure 1 shows the PWE3 reference architecture [RFC3985]. 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 |<--------Multi-Segment Pseudowire----->| Native Service | PSN PSN | Service (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) | V V 1 V V 2 V V | | +-----+ +-----+ +---- + | +---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+ | |---------|........PW1.......... |...PW3..........|---|----| | |CE1| | | | | | | | | |CE2| | |---------|........PW2...........|...PW4..........|--------| | +---+ | | |==========| |==========| | | +---+ ^ +-----+ +-----+ +-----+ ^ | Provider Edge 1 ^ Provider Edge 3 | | | | | | | | PW switching point | | | | | |<------------------- Emulated Service ------------------->| Figure 2: PWswitchingSwitching Reference Model Figure 2 extends this architecture to show a multi-segment case. Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3 service to CE1 and CE2. These PEs terminate different PSN tunnels, PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or pseudowire domains. One 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 toT- PE1T-PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel 1 is switched to a PW in the tunnel across PSN2 at S-PE2 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). PW1 and PW3 are segments of the same MS-PW while PW2 and PW4 are segments of another pseudowire. PW segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW type or different types, and PSN tunnels (e.g., PSN Tunnel 1 and PSN Tunnel 2) can be the same or different technology. This document requires support for MS-PWs with segments of the same PW type only. An S-PE switchesaan MS-PW from one segment to another based on the PW identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could be IGP areas in the same IGPnetwork,network or simply PWE3 domains in a single flat IGPnetworknetwork, for instance. |<------Multi-Segment Pseudowire------>| | AS AS | AC | |<----1---->| |<----2--->| | AC | V V V V V V | | +----+ +-----+ +----+ +----+ | +----+ | | |=====| |=====| |=====| | | +----+ | |-------|.....PW1..........PW2.........PW3.....|-------| | | CE1| | | | | | | | | | | |CE2 | +----+ | | |=====| |=====| |=====| | | +----+ ^ +----+ +-----+ +----+ +----+ ^ | T-PE1 S-PE2 S-PE3 T-PE4 | | ^ ^ | | | | | | PW switching points | | | | | |<------------------- Emulated Service --------------->| Figure 3: PWswitching inter providerSwitching Inter-Provider Reference Model Note that although Figure 2 only shows a single S-PE, a PW may transit more than oneS-PES-PEs along its path. For instance, in the multi-AS case shown in Figure 3, there can be an S-PE(S-PE2),(S-PE2) at the border of one AS (AS1) and another S-PE (S-PE3) at the border of the other AS (AS2).AAn MS-PW that extends from the edge of one AS(T-PE1)(T- PE1) to the edge of the other AS (T-PE4) is composed of three segments: (1) PW1, a segment in AS1, (2) PW2, a segment between the two border routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a segment in AS2. AS1 and AS2 could be belong to the same provider (e.g., AS1 could be an access network or metro transport network, and AS2 could be an MPLS core network) or to two different providers (e.g., AS1 for Provider 1 and AS2 forProvider2). 4.Provider 2). 2. Terminology RFC 3985 [RFC3985] provides terminology for PWE3. The following additional terminology is defined for multi-segment pseudowires: - PW Terminating Provider Edge (T-PE). A PE where thecustomer- facingcustomer-facing attachment circuits (ACs) are bound to a PW forwarder. A Terminating PE is present in the first and last segments ofaan MS-PW. This incorporates the functionality of a PE as defined in RFC 3985. - Single-Segment Pseudowire (SS-PW). A PW setup directly between two PE devices. Each direction ofaan SS-PW traverses one PSN tunnel that connects the two PEs. - Multi-Segment Pseudowire (MS-PW). A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end ofaan MS-PW by definition MUST terminate on a T-PE. - PW Segment. A part of a single-segment or multi-segment PW, which is set up between two PE devices, T-PEs and/or S-PEs. - PW Switching Provider Edge (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments inaan MS-PW. The S-PE terminates the PSN tunnels transporting the preceding and succeeding segments of theMS-PW.MS- PW. It is therefore a PW switching point foraan MS-PW. A PWSwitching Pointswitching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols tosetupset up and manage PW segments with other PW switching points and terminating PEs.5.2.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 [RFC2119]. 3. Use Cases PWE3 defines the signaling and encapsulation techniques for establishing SS-PWs between a pair of terminating PEs(T-PEs)(T-PEs), and in the vast majority ofcasescases, this will be sufficient. MS-PWs may be useful in the following situations: -i. Inter-Provider PWs: An Inter-Provider PW is a PW that extends from a T-PE in one provider domain to a T-PE in another provider domain. -ii. It may not be possible,desirabledesirable, or feasible to establish a direct PW control channel between the T-PEs, residing in different provider networks, tosetupset up and maintain PWs. At a minimum, a direct PW control channel establishment (e.g., targeted LDP session) requires knowledge of and reachability to the remote T-PE IP address. The local T-PE may not have access to this information due to operational or security constraints. Moreover,aan SS-PW would require the existence of a PSN tunnel between the local T-PE and the remote T-PE. It may not be feasible or desirable to extend single, contiguous PSN tunnels between T-PEs in one domain and T-PEs in another domain for security and/or scalability reasons or because the two domains may be using different PSN technologies. -iii. MS-PW setup,maintenancemaintenance, and forwarding procedures must satisfy requirements placed by the constraints of amulti- providermulti-provider environment. An example is the inter-AS L2VPN scenario where the T-PEs reside in different provider networks (ASs) and it is the current practice to MD5-key all control traffic exchanged between two networks.AAn MS-PW allows the providers to confine MD5 key administration for the LDP session to just the PW switching points connecting the two domains. -iv. PSN Interworking: PWE3 signaling protocols and PSN types may differ in different provider networks. The terminating PEs may be connected to networks employing different PW signalingand /orand/or PSN protocols. In thiscasecase, it is not possible to useaan SS-PW.AAn MS-PW with the appropriate interworking performed at the PW switching points can enable PW connectivity between the terminating PEs in this scenario. -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: There is a requirement to deploy PWs edge to edge in large service provider networks. Such networks typically encompass hundreds or thousands of aggregation devices at the edge, each of which would be a PE. Furthermore, there is a requirement that these PWs have explicit bandwidth guarantees. To satisfy these requirements, the PWs will be tunneled over PSN TE-tunnels with bandwidth constraints. Asingle segmentsingle-segment pseudowire architecture would require that a full mesh of PSN TE-tunnels be provisioned to allow PWs to be established between all PEs. Inter-provider PWs riding traffic engineered tunnels further add to the number of tunnels that would have to be supported by the PEs and the core network as the total number of PEs increases. In this environment, there is a requirement either to support a sparse mesh of PSN TE-tunnels and PW signaling adjacencies, or to partition the network into a number of smaller PWE3 domains. In either case, a PW would have to pass through more than one PSN tunnel hop along its path. An objective is to reduce the number of tunnels that must be supported, and thus the complexity and scalability problem that may arise. -vi. Pseudowires in access/metrometworks:networks: Service providers wish to extend PW technology to access and metro networks in order to reduce maintenance complexity and operational costs. Today's access and metro networks are either legacy(TDM, SONET/SDH,(Time Division Multiplexer (TDM), Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), or FrameRelay/ATM), EthernetRelay/Asynchronous Transfer Mode (ATM)), Ethernet, or IP based. Due to these architectures, circuits (e.g., EthernetVCs,Virtual Circuits (VCs), ATM VCs, TDM circuits) in the access/metro are traditionally handled as attachment circuits, in their native format, to the edge of the IP-MPLS network where the PW starts. This combination requires multiple separate access networks and complicates end-to-end control, provisioning, and maintenance. In addition, when a TDM or SONET/SDH access network is replaced with a packet-based infrastructure, expenses may be lowered due to moving statistical multiplexing closer to the end-user and converging multiple services onto a single access network. Access networks have a number of properties that impact the application of PWs. For example, there exist access mechanisms where the PSN is not of an IETF specified type, but uses mechanisms compatible with those of PWE3 at the PW layer. Here, use case (iv) may apply. In addition, many networks consist of hundreds or thousands of access devices. There is therefore a desire to support a sparse mesh of PW signaling adjacencies and PSN tunnels. Use case (v) may therefore apply. Finally,Accessaccess networks also tend to differ from core networks in that the access PW setup and maintenance mechanism may only be a subset of that used in the core. Using the MS-PWs, access and metro network elements need only maintain PW signaling adjacencies with the PEs to which they directly connect. They do not need PW signaling adjacencies with every other access and metro network device. PEs in the PSNbackbonebackbone, inturnturn, maintain PW signaling adjacencies among each other. In addition, a PSN tunnel issetupset up between an access element and the PE to which it connects. Another PSN tunnel needs to be established between every PE pair in the PSN backbone.AAn MS-PW may besetupset up from one access network element to anotheranotheraccess element with three segments: (1) access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN- PE to access element. In this MS-PW setup, access elements are T-PEs while PSN-PEs are S-PEs. It should be noted that the PSN backbone can be also segmented into PWE3 domains resulting in more segments per PW.5.1.3.1. Multi-Segment Pseudowire Placement Mechanisms This requirements document assumes that the above use cases are realized using one or more of the following mechanisms: -i. Static Configuration: The switching points (S-PEs), in addition to the T-PEs, are manually provisioned for each segment. -ii.Pre-determinedPre-Determined Route: The PW is established along an administratively determined route using an end-to-end signaling protocol with automated stitching at the S-PEs. -iii. Signaled Dynamic Route: The PW is established along a dynamically determined route using an end-to-end signaling protocol with automated stitching at the S-PEs. The route is selected with the aid of one or more dynamic routing protocols. Note that we define the PW route to be the set of S-PEs through whichaan MS-PW will pass between a given pair of T-PEs. PSN tunnels along that route can be explicitly specified or locally selected at theS- PEsS-PEs and T-PEs. The routing of the PSN tunnels themselves is outside the scope of the requirements specified in this document.6.4. Multi-Segment Pseudowire Requirements The following sections detail the requirements that the above use cases put on the MS-PW setup mechanisms.6.1.4.1. All Mechanisms The following generic requirements apply to the three MS-PW setup mechanisms defined in the previous section.6.1.1.4.1.1. Architecture -i. If MS-PWs aretunneled,tunneled across a PSN that only supportsSS- PWs,SS-PWs, then only the requirements of [RFC3916] apply to that PSN. The fact that the overlay is carrying MS-PWs MUST be transparent to the routers in the PSN. -ii. The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or an T-PE from the MS-PW architecture viewpoint. P-routers provide transparent PSN transport for PWs and MUST not have any knowledge of the PWs traversing them. -iii. The MS-PWs MUST use the same encapsulation modes specified for SS-PWs. -iv. The MS-PWs MUST be composed of SS-PWs. -v.AAn MS-PW MUST be able to pass across PSNs of all technologies supported by PWE3 for SS-PWs. When crossing from one PSN technology to another, an S-PE must provide the necessary PSN interworking functions in that case. -vi. Both directions of a PW segment MUST terminate on the same S-PE/T-PE. -vii. S-PEs MAY only support switching PWs of the same PW type. In this case, the PW type is transparent to the S-PE in the forwarding plane, except for functions needed to provide for interworking between different PSN technologies. -viii. Solutions MAY provide a way to prioritize the setup and maintenance process among PWs.6.1.2.4.1.2. Resiliency Mechanisms to protectaan MS-PW when an element on the existing path ofaan MS-PW fails MUST be provided. These mechanisms will depend on the MS-PW setup.FollowingThe following are the generic resiliency requirements that apply to all MS-PW setup mechanisms: -i. Configuration and establishment of a backup PW to a primary PW SHOULD be supported. Mechanisms to perform a switchover from a primary PW to a backup PW upon failure detection SHOULD be provided. -ii. The ability to configure an end-to-end backup PW path for a primary PW path SHOULD be supported. The primary and backup paths may be statically configured, statically specified forsignalingsignaling, or dynamically selected via dynamic routing depending on the MS-PW establishment mechanism. Backup and primary paths should have the ability to traverse separate S-PEs. The backup path MAY be signaled at configuration time or after failure. -iii. The ability to configure a primary PW and a backup PW with a different T-PE from the primary SHOULD be supported. -iv. Automatic Mechanisms to perform a fast switchover from a primary PW to a backup PW upon failure detection SHOULD be provided. -v. A mechanism to automatically revert to a primary PW from a backup PW MAY be provided. When provided, it MUST be configurable.6.1.3.4.1.3. QualityOfof Service Pseudowires are intended to support emulated services (e.g., TDM and ATM)whichthat may have strict per-connectionquality of servicequality-of-service (QoS) requirements. This may include either absolute or relative guarantees on packet loss, delay, and jitter. These guaranteesareare, inpartpart, delivered by reserving sufficient network resources(e.g.(e.g., bandwidth), and by providing appropriate per-packet treatment(e.g.(e.g., scheduling priority and drop precedence) throughout the network. For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be used to ensure that sufficient resources are reserved in theP- routersP-routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST have the ability to automatically request the PSN tunnel resources in the direction of traffic(e.g.(e.g., admission control of PWs onto the PSN tunnel and accounting for reserved bandwidth and available bandwidth on the tunnel). In cases where the tunnel supports multiple classes of service (CoS) (e.g., E-LSP), bandwidth management is required per CoS. For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. SolutionsMustMUST enable S-PEs and T-PEs to automatically bind a PW segment to aPSN-tunnelPSN tunnel based on CoS and bandwidth requirements when these attributes are specified for a PW. Solutions SHOULD also provide the capability of binding a PW segment to a tunnel as a matter of policy configuration. S-PEs and T-PEs must be capable of automatically requestingPSN-tunnelPSN tunnel resources per CoS. S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs affects packet treatment. The CoS marking depends on the PSN technology. Thus, solutions must enable the configuration of necessary mapping for CoS marking when the MS-PW crosses from one PSN technology to another. Similarly, different administrative domains may use different CoS values to imply the same CoS treatment. Solutions MUST provide the ability to define CoS marking maps onS- PEsS-PEs at administrative domain boundaries to translate from one CoS value to another as aaPW PDU crosses from one domain to the next. [RFC3985] requires PWs to respond to path congestion by reducing their transmission rate. Alternatively,RFC3985RFC 3985 permits PWs that do not have a congestion control mechanism to transmit using explicitly reserved capacity along a provisioned path. Because MS-PWs are a type of PW, this requirement extends to them as well.RFC3985RFC 3985 applied to MS-PWs consequently requires that MS-PWs employ a congestion control mechanism that is effective acrossaan MS path, or requires an explicit provisioning action that reserves sufficient capacity in all domains along the MS path before the MS-PW begins transmission. S-PEs are therefore REQUIRED to reject attempts to establish MS-PW segments for PW types that either do not utilize an appropriate congestion control scheme or when resources that are sufficient to support the transmission rate of the PW cannot be reserved along the path.6.1.4.4.1.4. Congestion Control [RFC3985] requires all PWs to respond to congestion, in order to conform to [RFC2914]. In the absence of a well-defined congestion control mechanism, [RFC3985] permits PWs to be carried across paths that have been provisioned such that the traffic caused by PWs has no harmful effect on concurrent traffic that shares the path, even under congestion. These requirements extend to the MS-PWs defined in this document. Path provisioning is frequently performed through QoS reservation protocols or network management protocols. In the case of SS-PWs, which remain within a single administrative domain, a number of existing protocols can provide this provisioning functionality. MS- PWs, however, may transmit across network domains that are under the control of multiple entities. QoS provisioning across such paths is inherently more difficult, due to the required inter-domain interactions. It is important to note that these difficulties do not invalidate the requirement to provision path capacity for MS-PW use. Each domain MUST individually implement a method to control congestion. This can be by QoS reservation, or other congestion control method. MS-PWs MUST NOT transmit across unprovisioned, best effort, paths in the absence of other congestion control schemes, as required by [RFC3985]. Solutions MUST enable S-PEs and T-PEs on the path ofaan MS-PW to notify other S-PEs and T-PEs on that path ofcongestioncongestion, when it occurs. Congestion may be indicated by queue length, packet loss rate, or bandwidth measurement (among others) crossing a respective threshold. The action taken by a T-PE that receives a notification of congestion along the path of one of its PWs could be toreroutere-route the MS-PW to an alternative path, including an alternative T-PE if available. If a PE, or an S-PE has knowledge that a particular link or tunnel is experiencingcongestion ,congestion, it MUST notsetupset up any newMS- PWMS-PW that utilize that link or tunnel. Some PW types, such as TDM PWs, are more sensitive to congestion than others. The reaction to a congestion notification MAY vary per PW type.6.2.4.2. Generic Requirements for MS-PW Setup Mechanisms The MS-PW setup mechanisms MUST accommodateService Provider'sthe service provider's practices, especially in relation to security, confidentiality of SPinformationinformation, and traffic engineering. Security and confidentiality are especially important when the MS-PWs aresetupset up acrossAutonomous Systemsautonomous systems in different administrative domains.FollowingThe following are generic requirements that apply to the three MS-PW setup mechanisms defined earlier: -i. The ability to statically select S-PEs and PSN tunnels on a PW path MUST be provided. Static selection of S-PEs is by definition a requirement for the static configuration and signaled/static route setup mechanisms. This requirement satisfies the need for forcingaan MS-PW to traverse specific S-PEs to enforce service provider security and administrative policies. -ii. Solutions SHOULD minimize the amount of configuration needed tosetup aset up an MS-PW. -iii. Solutions should support different PW setup mechanisms on the same T-PE,S-PES-PE, and PSN network. -iv. Solutions MUST allow T-PEs to simultaneously support use of SS-PW signaling mechanisms as specified in[RFC4447][RFC4447], as well as MS-PW signaling mechanisms. -v. Solutions MUST ensure thataan MS-PW will besetupset up when a path that satisfies the PW constraints for bandwidth,CoSCoS, and other possible attributes does exist in the network. -vi. Solutions must clearly define the setup procedures for each mechanism so thataan MS-PW setup on T-PEs can be interpreted as successful only when all PW segments are successfullysetup.set up. -vii. Admission control to the PSN tunnel needs to be performed against available resources, when applicable. This process MUST be performed at each PW segment comprising the MS-PW. PW admission control into a PSN tunnel MUST be configurable. -viii. In case the PSN tunnel lacks the resources necessary to accommodate the new PW, an attempt to signal a new PSN tunnel, or increase the capacity of the existing PSN tunnel MAY be made. If the expanded PSN tunnel fails tosetupset up, the PW MUST fail tosetup.set up. -ix. The setup mechanisms must allow the setup of a PW segment between two directly connected S-PEs without the existence of a PSN tunnel. This requirement allows a PW segment to besetupset up between two (Autonomous System Border Routers (ASBRs) when the MS-PW crosses AS boundaries without the need for configuring and setting up a PSN tunnel. In this case, admission control must be done, when enabled, on the link between the S-PEs.6.2.1.4.2.1. Routing An objective of MS-PWs is to provide support for the following connectivity: -i. MS-PWs MUST be able to traverse multipleService Providerservice provider administrative domains. -ii. MS-PWs MUST be able to traverse multipleAutonomous Systemsautonomous systems within the same administrative domain. -iii. MS-PWs MUST be able to traverse multipleAutonomous Systemsautonomous systems belonging to different administrative domains. -iv. MS-PWs MUST be able to support any hybrid combination of the aforementioned connectivity scenarios, including both PWtransit,transit and termination in a domain.6.3.4.3. StaticallyconfiguredConfigured MS-PWs When the MS-PW segments are staticallyconfiguredconfigured, the following requirements apply in addition to the generic requirements previously defined.6.3.1.4.3.1. Architecture There are no additional requirements on the architecture.6.3.2.4.3.2. MPLS-PWs Solutions should allow for the static configuration of MPLS labels for MPLS-PW segments and the cross-connection of these labels to preceding and succeeding segments. This is especially useful whenaan MS-PW crosses provider boundaries and two providers do not want to run any PW signaling protocol between them. A T-PE or S-PE that allows the configuration of static labels for MS-PW segments should also simultaneously allow for dynamic label assignments for other MS-PW segments. It should be noted that when two interconnected S-PEs do not have signaling peering for the purpose of setting up MS-PW segments, they should have in-band PWOAMOperations and Maintenance (OAM) capabilities that relay PW or attachment circuit defect notifications between the adjacent S- PEs.6.3.3.4.3.3. Resiliency The solution should allow for the protection of aPW-segment,PW segment, a contiguous set ofPW-segments,PW segments, as well as theend-endend-to-end path. The primary and protection segmentspathsmust share the samesegmentssegment endpoints. Solutions should allow for having the backup pathssetupset up prior to the failure or as a result of failure. The choice should be made by configuration. When resources are limited and cannot satisfy all PWs, the PWs with the higher setup priorities should be given preference when compared with the setup priorities of other PWs beingsetupset up or the holding priorities of existing PWs. Solutions should strive to minimize traffic loss between T-PEs.6.3.4.4.3.4. Quality ofserviceService The CoS and bandwidth of the MS-PW must be configurable at T-PEs and S-PEs.6.4.4.4. SignaledPW-segmentsPW Segments When the MS-PW segments are dynamicallysignaledsignaled, the following requirements apply in addition to the generic requirements previously defined. These signaled MS-PW segments can be on the path of a statically configured MS-PW, signaled/statically routedMS-PWMS-PW, or signaled/dynamically routed MS-PW. There are four different SS-PW signaling protocols that are defined to signal PWs: -i. Staticsetupset up of the SS-PW (MPLS or L2TPv3 forwarding). -ii. LDP using PWidFECForward Error Correction (FEC) 128 -iii. LDP using the generalized PW FEC 129 -iv. L2TPv3 The MS-PW setup mechanism MUST be able to support PW segments signaled with any of the aboveprotocols, howeverprotocols; however, the specification of which combinations of SS-PW signaling protocolsisare supported by a specific implementation is outside the scope of this document. For the signaled/statically routed and signaled/dynamically routed MS-PW setupmechanismsmechanisms, the following requirements apply in addition to the generic requirements previously defined.6.4.1.4.4.1. Architecture There are no additional requirements on the architecture.6.4.2.4.4.2. Resiliency Solutions should allow for the signaling of a protection path for a PW segment, sequence ofsegmentssegments, or end-to-end path. The protection and primary paths for the protected segment(s) share the same respective segments endpoints. When admission control is enabled, systems must be careful not to double account for bandwidth allocation at merged points (e.g., tunnels). Solutions should allow for having the backup pathssetupset up prior to the failure or as a result of failure. The choice should be made by configuration at the endpoints of the protected path. When resources are limited and cannot satisfy all PWs, the PWs with the higher setup priorities should be given preference when compared with the setup priorities of other PWs beingsetupset up or the holding priorities of existing PWs. Procedures must allow for the primary and backup paths to be diversified6.4.3.4.4.3. Quality of Service When the T-PE attempts to signala MS-PWan MS-PW, the following capability is required: -i. Signaling must be able to identify the CoS associated witha MS-PWan MS-PW. -ii. Signaling must be able to carry the traffic parameters foraan MS-PW per CoS. Traffic parameters should be based on existing INTSERV definitions and must be used for admission control when admission control is enabled. -iii. The PW signaling MUST enable separate traffic parameter values to be specified for the forward and reverse directions of the PW. -iv. PW traffic parameter representations MUST be the same for all types of MS-PWs. -v. The signaling protocol must be able to accommodate a method to prioritize the PW setup and maintenance operation among PWs.6.4.4.4.4.4. Routing See the requirements for "Resiliency" above.FollowingThe following are further requirements on signaled MS-PW setup mechanisms: -i. The signaling procedures MUST be defined such that the setup ofaan MS-PW is considered successful if all segments of the MS-PW are successfullysetup.set up. -ii. The MS-PW path MUST have the ability to be dynamicallysetupset up between the T-PEs by provisioning only the T-PEs. -iii. Dynamic MS-PW setup requires that a unique identifier be associated with a PW and be carried in the signaling message. That identifier must contain sufficient information to determine the path to the remote T-PE through intermediate S-PEs. -iv. In a single-providerdomaindomain, it is natural to have the T-PE identified by one of its IP addresses. This may also apply whenaan MS-PW issetupset up across multiple domains operated by the same provider. However, some service providers have security and confidentiality policies that prevent them from advertising reachability to routers in their networks to other providers (reachability to an ASBR is an exception). Thus, procedures MUST be provided to allow dynamicsetupset up of MS-PWs under these conditions.6.5.4.5. Signaled PW / Dynamic Route The following requirements apply, in addition to those inSectionSections 6.1 andSection6.2, when both dynamic signaling and dynamic routing are used.6.5.1.4.5.1. Architecture There are no additional architectural requirements.6.5.2.4.5.2. Resiliency The PWRoutingrouting function MUST support dynamic re-routing around failure points when segments aresetupset up using the dynamic setup method.6.5.3.4.5.3. Quality of Service There are no additional QoS requirements.6.5.4.4.5.4. RoutingFollowingThe following are requirements associated with dynamic route selection foraan MS-PW: -i. Routing must enable S-PEs and T-PEs to discover S-PEs on the path to a destination T-PE. -ii. The MS-PW routing function MUST have the ability to automatically select the S-PEs along the MS-PW path. Some of the S-PEs MAY be statically selected and carried in the signaling to constrain the route selection process. -iii. The PWRoutingrouting function MUST support re-routing around failures that occur between the statically configured segment endpoints. This may be done by choosing another PSN tunnel between the two segment endpoints or setting up an alternative tunnel. -iv. Routing protocols must be able to advertise reachability information of attachment circuit (AC) endpoints. This reachability information must be consistent with the AC identifiers carried in signaling.7.5. Operations and Maintenance (OAM) OAM mechanisms for the attachment circuits are defined in the specifications for PW emulated specific technologies (e.g., ITU-T I.610 [i610] for ATM). These mechanisms enable, among other things, defects in the network to be detected,localizedlocalized, and diagnosed. They also enable communication of PW defect states on the PW attachment circuit. Note that this document uses the term OAM as Operations and Management as per ITU-T I.610. The interworking of OAM mechanisms for SS-PWs between ACs and PWs is defined in [PWE3-OAM]. These enable defect states to be propagated across a PWE3 network following the failure and recovery from faults. OAM mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs. In addition, it should be possible to support both segment andend- to-endend-to-end OAM mechanisms for both defect notifications and connectivity verification in order to allow defects to be localized in amulti- segmentmulti-segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE to S-PE, or S-PE to S-PE. The following requirements apply to OAM for MS-PWs: -i. Mechanisms for PW segment failure detection and notification to other segments ofaan MS-PW MUST be provided. -ii. MS-PW OAM SHOULD be supported end-to-end across the network. -iii. Single ended monitoring SHOULD be supported for both directions of the MS-PW. -iv. SS-PW OAM mechanisms (e.g.,[VCCV])[RFC5085]) SHOULD be extended to support MS-PWs on bothend-endan end-to-end basis and segment basis. -v. All PE routers along the MS-PW MUST agree on a common PW OAM mechanism to use for the MS-PW. -vi. At the S-PE, defects on an PSN tunnel MUST be propagated to all PWs that utilize that particular PSN tunnel. -vii. The directionality of defect notifications MUST be maintained across the S-PE. -viii. The S-PE SHOULD be able to behave as a segment endpoint for PW OAM mechanisms. -ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages transparently. -x. PerformanceOAM,OAM is required for both MS-PWs and SS-PWs to measure round-trip delay, one-way delay, jitter, and packet loss ratio.8.6. Management of Multi-Segment Pseudowires Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms for network operators to manage the emulated service. Management mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs, as defined in [RFC3916]. It SHOULD also be possible to manage the additional attributes for MS-PWs. Since the operator that initiates the establishment of an MS-PW may reside in a different PSN domain from the S-PEs and one of the T-PEs along the path of the MS-PW, mechanisms for the remote management of the MS-PW SHOULD be provided. The following additional requirements apply:8.1.6.1. MIB Requirements -i. MIB Tables MUST be designed to facilitate configuration and provisioning of the MS-PW at the S-PEs and T-PEs. -ii. The MIB(s) MUST facilitate inter-PSN configuration and monitoring of the ACs.8.2.6.2. Management Interface Requirements -i. Mechanisms MUST be provided to enable remote management ofaan MS-PW at an S-PE or T-PE. It SHOULD be possible for these mechanisms to operate across PSN domains. An example of a commonly available mechanism is the command line interface (CLI) over a telnet session. -ii. For security or other reasons, it SHOULD be possible to disable the remote management ofaan MS-PW.9.7. Security Considerations This document specifies the requirements both for MS-PWs that can besetupset up across domain boundaries administered by one or more service providers (inter-provider MS-PWs), and for MS-PWs that are onlysetupset up across one provider (intra-provider MS-PWs).9.1.7.1. Inter-Provider MS-PWs The security requirements for MS-PW setup across domains administered by one service provider are the same as those described under security considerations in [RFC4447] and [RFC3916]. These requirements also apply tointerproviderinter-provider MS-PWs. In addition, [RFC4111] identifies user and provider requirements for L2 VPNs that apply to MS-PWs described in this document. In this section, the focus is on the additional security requirements forinterproviderinter-provider operation of MS-PWs in both the control plane and data plane, and some of these requirements may overlap with those in [RFC4111].9.1.1. Data-plane7.1.1. Data-Plane Security Requirements By security in the "data plane", we mean protection against the following possibilities: -i. Packets from within an MS-PW traveling to a PE or an ACthatto which the PW is not intended to beconnected to,connected, other than in a manner consistent with the policies of the MS-PW. -ii. Packets from outside an MS-PW entering the MS-PW, other than in a manner consistent with the policies of the MS-PW. MS-PWs that cross service provider (SP) domain boundaries may connect one T-PE in a SP domain to a T-PE in another provider domain. They may also transit other provider domains even if the two T-PEs are under the control of one SP. Under these scenarios, there is a chance that one or more PDUs could be falsely inserted intoaan MS-PW at any of the originating,terminatingterminating, or transit domains. Such false injection can be the result of a malicious attack or fault in theS- PE.S-PE. Solutions MAY provide mechanisms for ensuring the end-to-end authenticity of MS-PW PDUs. The data plane security requirements at a service provider border for MS-PWs are similar to those for inter-provider BGP/MPLS IP Virtual Private Networks [RFC4364]. In particular, an S-PE or T-PE SHOULD discard a packet received from a particular neighbor over the service provider border unless one of the following two conditions holds: -iii.anyAny MPLS label processed at the receiving S-PE or T-PE, such the PSN tunnel label or the PWlabel,label has a label value that the receiving system has distributed to that neighbor, or -iv.anyAny MPLS label processed at the receiving S-PE or T-PE, such as the PSN tunnel label or the PWlabel,label has a label value that the receiving S-PE or T-PE has previously distributed to the peer S-PE or T-PE beyond that neighbor (i.e., when it is known that the path from the system to which the label was distributed to the receiving system is via that neighbor). One of the domains crossed byaan MS-PW may decide to selectively mirror the PDUs ofaan MS-PW for eavesdropping purposes. It may also decide to selectively hijack the PDUs ofaan MS-PW by directing the PDUs away from their destination. In either case, the privacy ofaan MS-PW can be violated. Some types of PWs make assumptions about the security of theunderlingunderlying PSN. The minimal security provided by an MPLS PSN might not be sufficient to meet the security requirements expected by the applications using the MS-PW. This document does not place any requirements on protecting the privacy ofaan MS-PW PDU via encryption. However, encryption may be required at a higher layer in the protocol stack, based on the application or network requirements. The data plane of an S-PE at a domain boundary MUST be able to police incoming MS-PW traffic to the MS-PW traffic parameters or to an administratively configured profile. The option to enable/disable policing MUST be provided to the network administrator. This is to ensure thataan MS-PW or a group of MS-PWs do not grab more resources than they are allocated. In addition, the data plane of an S-PE MUST be able to police OAM messages to a pre-configured traffic profile or to filter out these messages upon administrative configuration. An ingress S-PE MUST ensure thataan MS-PWreceivereceives the CoS treatment configured or signaled for that MS-PW at the S-PE. Specifically, an S-PE MUST guard against packets marked in the exp bits or IP-headerDSDifferentiated Services (DS) field (depending on the PSN) for a better CoS than they should receive. An ingress S-PE MUST be able to define per-interface orinterface- groupinterface-group (a group may correspond to interfaces to apeer-provider)peer- provider) label space for MPLS-PWs. An S-PE MUST be configurable not to accept labeled packets from another provider unless the bottom label is a PW-label assigned by the S-PE on the interface on which the packet arrived. Data plane security considerations for SS-PWs specified in [RFC3985] also apply to MS-PWs.9.1.2. Control-plane7.1.2. Control-Plane Security RequirementsAAn MS-PW connects two attachment circuits. It is important to make sure that PW connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit. The fault in the connection can start at a remote T-PE or an S-PE. Where a PW segment crosses a border between one provider and another provider, the PW segment endpoints (S-PEs) SHOULD be on ASBRs interconnecting the two providers. Directly interconnecting the S-PEs using a physically secure link, and enabling signaling and routing authentication between the S-PEs, eliminates the possibility of receivingaan MS-PW signaling message or packet from an untrusted peer. Other configurations are possible, for example, P routers for the PSN tunnel between the adjacent S-PEs/T-PEs may reside on the ASBRs. In which case, the S-PEs/T-PEs MUST satisfy themselves of the security and privacy of the path. The configuration and maintenance protocol MUST provide a strong authentication and control protocol data protection mechanism. This option MUST be implemented, but it should be deployed according to the specific PSN environment requirements. Furthermore, authentication using a signature for each individual MS-PW setupmessagesmessage MUST be available, in addition to an overall control protocol sessionauthentication,authentication and message validation. Since S-PEs in different provider networks SHOULD reside at each end of a physically secure link, or be interconnected by a limited number of trusted PSN tunnels, each S-PE will have a trust relationship with only a limited number of S-PEs in other ASs. Thus, it is expected that current security mechanisms based on manual key management will be sufficient. If deployment situations arise that require large scale connection of to S-PEs in other ASs, then a mechanism based on RFC 4107 [RFC4107] MUST be developed. Peer authentication protects against IP address spoofing but does not prevent one peer (S-PE or T-PE) from connecting to the wrong attachment circuit. Under a single administrative authority, this may be the result of a misconfiguration. When the MS-PW crosses multiple provider domains, this may be the result of a malicious act by a service provider or a security hole in that provider network. Static manual configuration of MS-PWs at S-PEs and T-PEs provides a greater degree of security. If an identification of both ends ofaan MS-PW is configured and carried in the signaling message, an S-PE can verify the signaling message against the configuration. To support dynamic signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs are dynamically discovered, mechanisms SHOULD be provided to configure such information on a server and to use that information during a connection attempt for validation. An incoming MS-PW request/reply MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer. An eligible peer is an S-PE or a T-PE with which the originating S-PE or T-PE has a trust relationship. The number of such trusted T-PEs or S-PEs is bounded and not anticipated to create a scaling issue for the contol plane authentication mechanisms. If a peering adjacency has to be established prior to exchanging setup requests/responses, peering MUST only be done with eligible peers. The set of eligible peers could be pre-configured (either as a list of IP addresses, or as a list of address/mask combinations) or automatically generated from the local PW configuration information. Furthermore, the restriction of peering sessions to specific interfaces MUST also be provided. The S-PE and T-PE MUST drop the unaccepted signaling messages in the data path to avoid aDoSDenial-of-Service (DoS) attack on the control plane. Even if a connection request appears to come from an eligible peer, its source address may have been spoofed. So some means of preventing source address spoofing must be in place. For example, if eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing. S-PEs that connect one provider domain to another provider domain MUST have the capability to rate-limit signaling traffic in order to prevent DoS attacks on the control plane. Furthermore, detection and disposition of malformed packets and defense against various forms of attacks that can be protocol-specific MUST be provided.9.2.7.2. Intra-Provider MS-PWs Security requirements for pseudowires are provided in [RFC3916]. These requirements also apply to MS-PWs. MS-PWs are intended to enable many more PEs to provide PWE3 services in a given service providers network than traditional SS-PWs, particularly in access and metro environments where the PE may be situated closer to the ultimate endpoint of the service. In order to limit the impact of a compromise of one T-PE in a service providers network, the data path security requirements for inter-providerMS- PWsMS-PWs also apply to intra-provider MS-PWs in such cases.10. Intellectual Property Statement8. Acknowledgments TheIETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain toeditors gratefully acknowledge theimplementation orfollowing contributors: Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel-Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), David McDyson (Verizon), Rahul Aggawal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE), and Stewart Bryant (Cisco). 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for useof the technology describedinthis 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 respectRFCs torights in RFC documents can be found inIndicate Requirement Levels", BCP7814, RFC 2119, March 1997. [RFC3916] Xiao, X., Ed., McPherson, D., Ed., andBCP 79. Copies of IPR disclosures made to the IETF SecretariatP. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [RFC3985] Bryant, S., Ed., andany assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permissionP. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 9.2. Informative References [i610] Recommendation I.610 "B-ISDN operation and maintenance principles and functions", February 1999. [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using theuse 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. 11.Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4111] Fang, L., Ed., "Security Framework for Provider- Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. [PWE3-OAM] Nadeau, T., Ed., Morrow, M., Ed., Busschbach, P., Ed., Alissaoui, M.,Ed., D. Allen, Ed., "Pseudo Wire (PW) OAM Message Mapping", Work in Progress, March 2005. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. Authors' Addresses Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.bitar@verizon.com Matthew Bocci Alcatel-Lucent Telecom Ltd, Voyager Place Shoppenhangers Road Maidenhead Berks, UK EMail: matthew.bocci@alcatel-lucent.co.uk Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 EMail: lmartini@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.12. IANA Considerations This document hasIntellectual Property The IETF takes noIANA Actions. 13. Normative References [RFC3916] "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", X. Xiao, D. McPherson, P. Pate, September 2004 [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. 14. Informative References [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection Verification (VCCV)", Internet Draft "draft-ietf-pwe3-vccv-15.txt", September 2007.(work in progress) [RFC4447] L. Martini, Ed, et al., "Pseudowire Setup and Maintenance Usingposition regarding theLabel Distribution Protocol (LDP)", RFC4447, April 2006 [RFC4111] "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)," Fang. L., et al.,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 RFC4111, July 2005 [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., draft-ietf-pwe3-oam-msg-map-02.txt (workdocuments can be found inprogress), February 2005 [RFC2914] "Congestion Control Principles", S. Floyd, September 2000 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", E. Rosen et al, February 2006 [RFC4107] "GuidelinesBCP 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 forCryptographic Key Management", S. Belloin et al, June 2005 15. Author Information Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 e-mail: nabil.bitar@verizon.com Matthew Bocci Alcatel-Lucent Telecom Ltd, Voyager Place Shoppenhangers Road Maidenhead Berks, UK e-mail: matthew.bocci@alcatel-lucent.co.uk Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 e-mail: lmartini@cisco.comthe 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.