idnits 2.17.1 draft-ietf-pwe3-ms-pw-requirements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1080. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: -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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Solutions MUST enable S-PEs and T-PEs on the path of a MS-PW to notify other S-PEs and T-PEs on that path of congestion 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 to reroute 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 experiencing congestion , it MUST not setup any new MS-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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2007) is 6006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Nabil Bitar (Editor) 3 Internet Draft Verizon 4 Intended status: Informational 5 Expiration Date: May 2008 7 Luca Martini (Editor) Matthew Bocci (Editor) 8 Cisco Systems Inc. Alcatel-Lucent 10 November 2007 12 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) 14 draft-ietf-pwe3-ms-pw-requirements-06.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes the necessary requirements to allow a service 41 provider to extend the reach of pseudowires across multiple domains. 42 These domains can be autonomous systems under one provider 43 administrative control, IGP areas in one autonomous system, different 44 autonomous systems under the administrative control of two or more 45 service providers, or administratively established pseudowire 46 domains. 48 Table of Contents 50 1 Specification of Requirements ........................ 4 51 2 Acknowledgments ...................................... 4 52 3 Introduction ......................................... 4 53 3.1 Scope ................................................ 4 54 3.2 Architecture ......................................... 4 55 4 Terminology .......................................... 7 56 5 Use Cases ............................................ 8 57 5.1 Multi-Segment Pseudowire Placement Mechanisms ........ 11 58 6 Multi-Segment Pseudowire Requirements ................ 11 59 6.1 All Mechanisms ....................................... 11 60 6.1.1 Architecture ......................................... 11 61 6.1.2 Resiliency ........................................... 12 62 6.1.3 Quality Of Service ................................... 13 63 6.1.4 Congestion Control ................................... 14 64 6.2 Generic Requirements for MS-PW Setup Mechanisms ...... 15 65 6.2.1 Routing .............................................. 16 66 6.3 Statically configured MS-PWs ......................... 16 67 6.3.1 Architecture ......................................... 17 68 6.3.2 MPLS-PWs ............................................. 17 69 6.3.3 Resiliency ........................................... 17 70 6.3.4 Quality of service ................................... 17 71 6.4 Signaled PW-segments ................................. 18 72 6.4.1 Architecture ......................................... 18 73 6.4.2 Resiliency ........................................... 18 74 6.4.3 Quality of Service ................................... 19 75 6.4.4 Routing .............................................. 19 76 6.5 Signaled PW / Dynamic Route .......................... 20 77 6.5.1 Architecture ......................................... 20 78 6.5.2 Resiliency ........................................... 20 79 6.5.3 Quality of Service ................................... 20 80 6.5.4 Routing .............................................. 20 81 7 Operations and Maintenance (OAM) ..................... 21 82 8 Management of Multi-Segment Pseudowires .............. 22 83 8.1 MIB Requirements ..................................... 23 84 8.2 Management Interface Requirements .................... 23 85 9 Security Considerations .............................. 23 86 9.1 Data-plane Security Requirements ..................... 23 87 9.2 Control-plane Security Requirements .................. 24 88 10 Intellectual Property Statement ...................... 26 89 11 Full Copyright Statement ............................. 26 90 12 IANA Considerations .................................. 27 91 13 Normative References ................................. 27 92 14 Informative References ............................... 27 93 15 Author Information ................................... 27 95 1. Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119. 101 2. Acknowledgments 103 The editors gratefully acknowledge the following contributors: 104 Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel- 105 Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British 106 Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), 107 David McDyson, Rahul Aggawal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc 108 (ZTE). 110 3. Introduction 112 3.1. Scope 114 This document specifies requirements for extending pseudowires across 115 more than one packet switched network (PSN) domain and/or more than 116 one PSN tunnel. These pseudowires are called multi-segment 117 pseudowires (MS-PW). Requirements for single-segment pseudowires 118 (SS-PW) that extend edge to edge across only one PSN domain are 119 specified in [RFC3916]. This document is not intended to invalidate 120 any part of [RFC3985]. 122 This document specifies additional requirements that apply to MS-PWs. 123 These requirements do not apply to PSNs that only support SS-PWs. 125 3.2. Architecture 127 The following three figures describe the reference models which are 128 derived from [RFC3985] to support PW emulated services. 130 |<-------------- Emulated Service ---------------->| 131 | | 132 | |<------- Pseudowire ------->| | 133 | | | | 134 | | |<-- PSN Tunnel -->| | | 135 | PW End V V V V PW End | 136 V Service +----+ +----+ Service V 137 +-----+ | | PE1|==================| PE2| | +-----+ 138 | |----------|............PW1.............|----------| | 139 | CE1 | | | | | | | | CE2 | 140 | |----------|............PW2.............|----------| | 141 +-----+ ^ | | |==================| | | ^ +-----+ 142 ^ | +----+ +----+ | | ^ 143 | | Provider Edge 1 Provider Edge 2 | | 144 | | | | 145 Customer | | Customer 146 Edge 1 | | Edge 2 147 | | 148 | | 149 Attachment Circuit (AC) Attachment Circuit (AC) 150 Native service Native service 152 Figure 1: PWE3 Reference Configuration 154 Figure 1 shows the PWE3 reference architecture [RFC3985]. This 155 architecture applies to the case where a PSN tunnel extends between 156 two edges of a single PSN domain to transport a PW with endpoints at 157 these edges. 159 Native |<--------Multi-Segment Pseudowire----->| Native 160 Service | PSN PSN | Service 161 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 162 | V V 1 V V 2 V V | 163 | +-----+ +-----+ +---- + | 164 +---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+ 165 | |---------|........PW1.......... |...PW3..........|---|----| | 166 |CE1| | | | | | | | | |CE2| 167 | |---------|........PW2...........|...PW4..........|--------| | 168 +---+ | | |==========| |==========| | | +---+ 169 ^ +-----+ +-----+ +-----+ ^ 170 | Provider Edge 1 ^ Provider Edge 3 | 171 | | | 172 | | | 173 | PW switching point | 174 | | 175 | | 176 |<------------------- Emulated Service ------------------->| 178 Figure 2: PW switching Reference Model 180 Figure 2 extends this architecture to show a multi-segment case. 181 Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3 182 service to CE1 and CE2. These PEs terminate different PSN tunnels, 183 PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or 184 pseudowire domains. One PSN tunnel extends from T-PE1 to S-PE1 across 185 PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across 186 PSN2. 188 PWs are used to connect the Attachment circuits (ACs) attached to T- 189 PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel 190 1 is switched to a PW in the tunnel across PSN2 at S-PE2 to complete 191 the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is 192 therefore the PW switching point and will be referred to as the PW 193 switching provider edge (S-PE). PW1 and PW3 are segments of the same 194 MS-PW while PW2 and PW4 are segments of another pseudowire. PW 195 segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW 196 type or different types, and PSN tunnels (e.g., PSN Tunnel 1 and PSN 197 Tunnel 2) can be the same or different technology. This document 198 requires support for MS-PWs with segments of the same PW type only. 199 An S-PE switches a MS-PW from one segment to another based on the PW 200 identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the 201 domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could be IGP 202 areas in the same IGP network, or simply PWE3 domains in a single 203 flat IGP network for instance. 205 |<------Multi-Segment Pseudowire------>| 206 | AS AS | 207 AC | |<----1---->| |<----2--->| | AC 208 | V V V V V V | 209 | +----+ +-----+ +----+ +----+ | 210 +----+ | | |=====| |=====| |=====| | | +----+ 211 | |-------|.....PW1..........PW2.........PW3.....|-------| | 212 | CE1| | | | | | | | | | | |CE2 | 213 +----+ | | |=====| |=====| |=====| | | +----+ 214 ^ +----+ +-----+ +----+ +----+ ^ 215 | T-PE1 S-PE2 S-PE3 T-PE4 | 216 | ^ ^ | 217 | | | | 218 | PW switching points | 219 | | 220 | | 221 |<------------------- Emulated Service --------------->| 223 Figure 3: PW switching inter provider Reference Model 225 Note that although Figure 2 only shows a single S-PE, a PW may 226 transit more than one S-PE along its path. For instance, in the 227 multi-AS case shown in Figure 3, there can be an S-PE (S-PE2), at the 228 border of one AS (AS1) and another S-PE (S-PE3) at the border of the 229 other AS (AS2). A MS-PW that extends from the edge of one AS (T-PE1) 230 to the edge of the other AS (T-PE4) is composed of three segments: 231 (1) PW1, a segment in AS1, (2) PW2, a segment between the two border 232 routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a 233 segment in AS2. AS1 and AS2 could be belong to the same provider 234 (e.g., AS1 could be an access network or metro transport network, and 235 AS2 could be an MPLS core network) or to two different providers 236 (e.g., AS1 for Provider 1 and AS2 for Provider2). 238 4. Terminology 240 RFC 3985 [RFC3985] provides terminology for PWE3. The following 241 additional terminology is defined for multi-segment pseudowires: 243 - PW Terminating Provider Edge (T-PE). A PE where the customer- 244 facing attachment circuits (ACs) are bound to a PW forwarder. A 245 Terminating PE is present in the first and last segments of a 246 MS-PW. This incorporates the functionality of a PE as defined in 247 RFC 3985. 249 - Single-Segment Pseudowire (SS-PW). A PW setup directly between 250 two PE devices. Each direction of a SS-PW traverses one PSN 251 tunnel that connects the two PEs. 253 - Multi-Segment Pseudowire (MS-PW). A static or dynamically 254 configured set of two or more contiguous PW segments that behave 255 and function as a single point-to-point PW. Each end of a MS-PW 256 by definition MUST terminate on a T-PE. 258 - PW Segment. A part of a single-segment or multi-segment PW, which 259 is set up between two PE devices, T-PEs and/or S-PEs. 261 - PW Switching Provider Edge (S-PE). A PE capable of switching the 262 control and data planes of the preceding and succeeding PW 263 segments in a MS-PW. The S-PE terminates the PSN tunnels 264 transporting the preceding and succeeding segments of the MS-PW. 265 It is therefore a PW switching point for a MS-PW. A PW Switching 266 Point is never the S-PE and the T-PE for the same MS-PW. A PW 267 switching point runs necessary protocols to setup and manage PW 268 segments with other PW switching points and terminating PEs. 270 5. Use Cases 272 PWE3 defines the signaling and encapsulation techniques for 273 establishing SS-PWs between a pair of terminating PEs (T-PEs) and in 274 the vast majority of cases this will be sufficient. MS-PWs may be 275 useful in the following situations: 277 -i. Inter-Provider PWs: An Inter-Provider PW is a PW that 278 extends from a T-PE in one provider domain to a T-PE in 279 another provider domain. 281 -ii. It may not be possible, desirable or feasible to establish a 282 direct PW control channel between the T-PEs, residing in 283 different provider networks, to setup and maintain PWs. At a 284 minimum, a direct PW control channel establishment (e.g., 285 targeted LDP session) requires knowledge of and reachability 286 to the remote T-PE IP address. The local T-PE may not have 287 access to this information due to operational or security 288 constraints. Moreover, a SS-PW would require the existence 289 of a PSN tunnel between the local T-PE and the remote T-PE. 290 It may not be feasible or desirable to extend single, 291 contiguous PSN tunnels between T-PEs in one domain and T-PEs 292 in another domain for security and/or scalability reasons or 293 because the two domains may be using different PSN 294 technologies. 296 -iii. MS-PW setup, maintenance and forwarding procedures must 297 satisfy requirements placed by the constraints of a multi- 298 provider environment. An example is the inter-AS L2VPN 299 scenario where the T-PEs reside in different provider 300 networks (ASs) and it is the current practice to MD5-key all 301 control traffic exchanged between two networks. A MS-PW 302 allows the providers to confine MD5 key administration for 303 the LDP session to just the PW switching points connecting 304 the two domains. 306 -iv. PSN Interworking: PWE3 signaling protocols and PSN types may 307 differ in different provider networks. The terminating PEs 308 may be connected to networks employing different PW 309 signaling and /or PSN protocols. In this case it is not 310 possible to use a SS-PW. A MS-PW with the appropriate 311 interworking performed at the PW switching points can enable 312 PW connectivity between the terminating PEs in this 313 scenario. 315 -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: 316 There is a requirement to deploy PWs edge to edge in large 317 service provider networks. Such networks typically encompass 318 hundreds or thousands of aggregation devices at the edge, 319 each of which would be a PE. Furthermore, there is a 320 requirement that these PWs have explicit bandwidth 321 guarantees. To satisfy these requirements, the PWs will be 322 tunneled over PSN TE-tunnels with bandwidth constraints. A 323 single segment pseudowire architecture would require that a 324 full mesh of PSN TE-tunnels be provisioned to allow PWs to 325 be established between all PEs. Inter-provider PWs riding 326 traffic engineered tunnels further add to the number of 327 tunnels that would have to be supported by the PEs and the 328 core network as the total number of PEs increases. 330 In this environment, there is a requirement either to 331 support a sparse mesh of PSN TE-tunnels and PW signaling 332 adjacencies, or to partition the network into a number of 333 smaller PWE3 domains. In either case, a PW would have to 334 pass through more than one PSN tunnel hop along its path. An 335 objective is to reduce the number of tunnels that must be 336 supported, and thus the complexity and scalability problem 337 that may arise. 339 -vi. Pseudowires in access/metro metworks: Service providers wish 340 to extend PW technology to access and metro networks in 341 order to reduce maintenance complexity and operational 342 costs. Today's access and metro networks are either legacy 343 (TDM, SONET/SDH, or Frame Relay/ATM), Ethernet or IP based. 345 Due to these architectures, circuits (e.g., Ethernet VCs, 346 ATM VCs, TDM circuits) in the access/metro are traditionally 347 handled as attachment circuits, in their native format, to 348 the edge of the IP-MPLS network where the PW starts. This 349 combination requires multiple separate access networks and 350 complicates end-to-end control, provisioning, and 351 maintenance. In addition, when a TDM or SONET/SDH access 352 network is replaced with a packet-based infrastructure, 353 expenses may be lowered due to moving statistical 354 multiplexing closer to the end-user and converging multiple 355 services onto a single access network. 357 Access networks have a number of properties that impact the 358 application of PWs. For example, there exist access 359 mechanisms where the PSN is not of an IETF specified type, 360 but uses mechanisms compatible with those of PWE3 at the PW 361 layer. Here, use case (iv) may apply. In addition, many 362 networks consist of hundreds or thousands of access devices. 363 There is therefore a desire to support a sparse mesh of PW 364 signaling adjacencies and PSN tunnels. Use case (v) may 365 therefore apply. Finally, Access networks also tend to 366 differ from core networks in that the access PW setup and 367 maintenance mechanism may only be a subset of that used in 368 the core. 370 Using the MS-PWs, access and metro network elements need 371 only maintain PW signaling adjacencies with the PEs to which 372 they directly connect. They do not need PW signaling 373 adjacencies with every other access and metro network 374 device. PEs in the PSN backbone in turn maintain PW 375 signaling adjacencies among each other. In addition, a PSN 376 tunnel is setup between an access element and the PE to 377 which it connects. Another PSN tunnel needs to be 378 established between every PE pair in the PSN backbone. A 379 MS-PW may be setup from one access network element to 380 another another access element with three segments: (1) 381 access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN- 382 PE to access element. In this MS-PW setup, access elements 383 are T-PEs while PSN-PEs are S-PEs. It should be noted that 384 the PSN backbone can be also segmented into PWE3 domains 385 resulting in more segments per PW. 387 5.1. Multi-Segment Pseudowire Placement Mechanisms 389 This requirements document assumes that the above use cases are 390 realized using one or more of the following mechanisms: 392 -i. Static Configuration: The switching points (S-PEs), in 393 addition to the T-PEs, are manually provisioned for each 394 segment. 396 -ii. Pre-determined Route: The PW is established along an 397 administratively determined route using an end-to-end 398 signaling protocol with automated stitching at the S-PEs. 400 -iii. Signaled Dynamic Route: The PW is established along a 401 dynamically determined route using an end-to-end signaling 402 protocol with automated stitching at the S-PEs. The route is 403 selected with the aid of one or more dynamic routing 404 protocols. 406 Note that we define the PW route to be the set of S-PEs through which 407 a MS-PW will pass between a given pair of T-PEs. PSN tunnels along 408 that route can be explicitly specified or locally selected at the S- 409 PEs and T-PEs. The routing of the PSN tunnels themselves is outside 410 the scope of the requirements specified in this document. 412 6. Multi-Segment Pseudowire Requirements 414 The following sections detail the requirements that the above use 415 cases put on the MS-PW setup mechanisms. 417 6.1. All Mechanisms 419 The following generic requirements apply to the three MS-PW setup 420 mechanisms defined in the previous section. 422 6.1.1. Architecture 424 -i. If MS-PWs are tunneled, across a PSN that only supports SS- 425 PWs, then only the requirements of [RFC3916] apply to that 426 PSN. The fact that the overlay is carrying MS-PWs MUST be 427 transparent to the routers in the PSN. 429 -ii. The PWs MUST remain transparent to the P-routers. A P-router 430 is not an S-PE or an T-PE from the MS-PW architecture 431 viewpoint. P-routers provide transparent PSN transport for 432 PWs and MUST not have any knowledge of the PWs traversing 433 them. 435 -iii. The MS-PWs MUST use the same encapsulation modes specified 436 for SS-PWs. 438 -iv. The MS-PWs MUST be composed of SS-PWs. 440 -v. A MS-PW MUST be able to pass across PSNs of all technologies 441 supported by PWE3 for SS-PWs. When crossing from one PSN 442 technology to another, an S-PE must provide the necessary 443 PSN interworking functions in that case. 445 -vi. Both directions of a PW segment MUST terminate on the same 446 S-PE/T-PE. 448 -vii. S-PEs MAY only support switching PWs of the same PW type. In 449 this case, the PW type is transparent to the S-PE in the 450 forwarding plane, except for functions needed to provide for 451 interworking between different PSN technologies. 453 -viii. Solutions MAY provide a way to prioritize the setup and 454 maintenance process among PWs. 456 6.1.2. Resiliency 458 Mechanisms to protect a MS-PW when an element on the existing path of 459 a MS-PW fails MUST be provided. These mechanisms will depend on the 460 MS-PW setup. Following are the generic resiliency requirements that 461 apply to all MS-PW setup mechanisms: 463 -i. Configuration and establishment of a backup PW to a primary 464 PW SHOULD be supported. Mechanisms to perform a switchover 465 from a primary PW to a backup PW upon failure detection 466 SHOULD be provided. 468 -ii. The ability to configure an end-to-end backup PW path for a 469 primary PW path SHOULD be supported. The primary and backup 470 paths may be statically configured, statically specified for 471 signaling or dynamically selected via dynamic routing 472 depending on the MS-PW establishment mechanism. Backup and 473 primary paths should have the ability to traverse separate 474 S-PEs. The backup path MAY be signaled at configuration time 475 or after failure. 477 -iii. The ability to configure a primary PW and a backup PW with a 478 different T-PE from the primary SHOULD be supported. 480 -iv. Automatic Mechanisms to perform a fast switchover from a 481 primary PW to a backup PW upon failure detection SHOULD be 482 provided. 484 -v. A mechanism to automatically revert to a primary PW from a 485 backup PW MAY be provided. When provided, it MUST be 486 configurable. 488 6.1.3. Quality Of Service 490 Pseudowires are intended to support emulated services (e.g., TDM and 491 ATM) which may have strict per-connection quality of service 492 requirements. This may include either absolute or relative guarantees 493 on packet loss, delay, and jitter. These guarantees are in part 494 delivered by reserving sufficient network resources (e.g. bandwidth), 495 and by providing appropriate per-packet treatment (e.g. scheduling 496 priority and drop precedence) throughout the network. 498 For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be 499 used to ensure that sufficient resources are reserved in the P- 500 routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST 501 have the ability to automatically request the PSN tunnel resources in 502 the direction of traffic (e.g. admission control of PWs onto the PSN 503 tunnel and accounting for reserved bandwidth and available bandwidth 504 on the tunnel). In cases where the tunnel supports multiple classes 505 of service (CoS) (e.g., E-LSP), bandwidth management is required per 506 CoS. 508 For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions 509 Must enable S-PEs and T-PEs to automatically bind a PW segment to a 510 PSN-tunnel based on CoS and bandwidth requirements when these 511 attributes are specified for a PW. Solutions SHOULD also provide the 512 capability of binding a PW segment to a tunnel as a matter of policy 513 configuration. S-PEs and T-PEs must be capable of automatically 514 requesting PSN-tunnel resources per CoS. 516 S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP 517 field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs 518 affects packet treatment. The CoS marking depends on the PSN 519 technology. Thus, solutions must enable the configuration of 520 necessary mapping for CoS marking when the MS-PW crosses from one PSN 521 technology to another. Similarly, different administrative domains 522 may use different CoS values to imply the same CoS treatment. 523 Solutions MUST provide the ability to define CoS marking maps on S- 524 PEs at administrative domain boundaries to translate from one CoS 525 value to another as a a PW PDU crosses from one domain to the next. 527 [RFC3985] requires PWs to respond to path congestion by reducing 528 their transmission rate. Alternatively, RFC3985 permits PWs that do 529 not have a congestion control mechanism to transmit using explicitly 530 reserved capacity along a provisioned path. Because MS-PWs are a type 531 of PW, this requirement extends to them as well. RFC3985 applied to 532 MS-PWs consequently requires that MS-PWs employ a congestion control 533 mechanism that is effective across a MS path, or requires an explicit 534 provisioning action that reserves sufficient capacity in all domains 535 along the MS path before the MS-PW begins transmission. S-PEs are 536 therefore REQUIRED to reject attempts to establish MS-PW segments for 537 PW types that either do not utilize an appropriate congestion control 538 scheme or when resources that are sufficient to support the 539 transmission rate of the PW cannot be reserved along the path. 541 6.1.4. Congestion Control 543 [RFC3985] requires all PWs to respond to congestion, in order to 544 conform to [RFC2914]. In the absence of a well-defined congestion 545 control mechanism, [RFC3985] permits PWs to be carried across paths 546 that have been provisioned such that the traffic caused by PWs has no 547 harmful effect on concurrent traffic that shares the path, even under 548 congestion. These requirements extend to the MS-PWs defined in this 549 document. 551 Path provisioning is frequently performed through QoS reservation 552 protocols or network management protocols. In the case of SS-PWs, 553 which remain within a single administrative domain, a number of 554 existing protocols can provide this provisioning functionality. MS- 555 PWs, however, may transmit across network domains that are under the 556 control of multiple entities. QoS provisioning across such paths is 557 inherently more difficult, due to the required inter-domain 558 interactions. It is important to note that these difficulties do not 559 invalidate the requirement to provision path capacity for MS-PW use. 560 Each domain MUST individually implement a method to control 561 congestion. This can be by QoS reservation, or other congestion 562 control method. MS-PWs MUST NOT transmit across unprovisioned, best 563 effort, paths in the absence of other congestion control schemes, as 564 required by [RFC3985]. 566 Solutions MUST enable S-PEs and T-PEs on the path of a MS-PW to 567 notify other S-PEs and T-PEs on that path of congestion when it 568 occurs. Congestion may be indicated by queue length, packet loss 569 rate, or bandwidth measurement (among others) crossing a respective 570 threshold. The action taken by a T-PE that receives a notification of 571 congestion along the path of one of its PWs could be to reroute the 572 MS-PW to an alternative path, including an alternative T-PE if 573 available. If a PE, or an S-PE has knowledge that a particular link 574 or tunnel is experiencing congestion , it MUST not setup any new MS- 575 PW that utilize that link or tunnel. Some PW types, such as TDM PWs, 576 are more sensitive to congestion than others. The reaction to a 577 congestion notification MAY vary per PW type. 579 6.2. Generic Requirements for MS-PW Setup Mechanisms 581 The MS-PW setup mechanisms MUST accommodate Service Provider's 582 practices, especially in relation to security, confidentiality of SP 583 information and traffic engineering. Security and confidentiality are 584 especially important when the MS-PWs are setup across Autonomous 585 Systems in different administrative domains. Following are generic 586 requirements that apply to the three MS-PW setup mechanisms defined 587 earlier: 589 -i. The ability to statically select S-PEs and PSN tunnels on a 590 PW path MUST be provided. Static selection of S-PEs is by 591 definition a requirement for the static configuration and 592 signaled/static route setup mechanisms. This requirement 593 satisfies the need for forcing a MS-PW to traverse specific 594 S-PEs to enforce service provider security and 595 administrative policies. 597 -ii. Solutions SHOULD minimize the amount of configuration needed 598 to setup a MS-PW. 600 -iii. Solutions should support different PW setup mechanisms on 601 the same T-PE, S-PE and PSN network. 603 -iv. Solutions MUST allow T-PEs to simultaneously support use of 604 SS-PW signaling mechanisms as specified in [RFC4447] as well 605 as MS-PW signaling mechanisms. 607 -v. Solutions MUST ensure that a MS-PW will be setup when a path 608 that satisfies the PW constraints for bandwidth, CoS and 609 other possible attributes does exist in the network. 611 -vi. Solutions must clearly define the setup procedures for each 612 mechanism so that a MS-PW setup on T-PEs can be interpreted 613 as successful only when all PW segments are successfully 614 setup. 616 -vii. Admission control to the PSN tunnel needs to be performed 617 against available resources, when applicable. This process 618 MUST be performed at each PW segment comprising the MS-PW. 619 PW admission control into a PSN tunnel MUST be configurable. 621 -viii. In case the PSN tunnel lacks the resources necessary to 622 accommodate the new PW, an attempt to signal a new PSN 623 tunnel, or increase the capacity of the existing PSN tunnel 624 MAY be made. If the expanded PSN tunnel fails to setup the 625 PW MUST fail to setup. 627 -ix. The setup mechanisms must allow the setup of a PW segment 628 between two directly connected S-PEs without the existence 629 of a PSN tunnel. This requirement allows a PW segment to be 630 setup between two (Autonomous System Border Routers (ASBRs) 631 when the MS-PW crosses AS boundaries without the need for 632 configuring and setting up a PSN tunnel. In this case, 633 admission control must be done, when enabled, on the link 634 between the S-PEs. 636 6.2.1. Routing 638 An objective of MS-PWs is to provide support for the following 639 connectivity: 641 -i. MS-PWs MUST be able to traverse multiple Service Provider 642 administrative domains. 644 -ii. MS-PWs MUST be able to traverse multiple Autonomous Systems 645 within the same administrative domain. 647 -iii. MS-PWs MUST be able to traverse multiple Autonomous Systems 648 belonging to different administrative domains. 650 -iv. MS-PWs MUST be able to support any hybrid combination of the 651 aforementioned connectivity scenarios, including both PW 652 transit, and termination in a domain. 654 6.3. Statically configured MS-PWs 656 When the MS-PW segments are statically configured the following 657 requirements apply in addition to the generic requirements previously 658 defined. 660 6.3.1. Architecture 662 There are no additional requirements on the architecture. 664 6.3.2. MPLS-PWs 666 Solutions should allow for the static configuration of MPLS labels 667 for MPLS-PW segments and the cross-connection of these labels to 668 preceding and succeeding segments. This is especially useful when a 669 MS-PW crosses provider boundaries and two providers do not want to 670 run any PW signaling protocol between them. A T-PE or S-PE that 671 allows the configuration of static labels for MS-PW segments should 672 also simultaneously allow for dynamic label assignments for other 673 MS-PW segments. It should be noted that when two interconnected S-PEs 674 do not have signaling peering for the purpose of setting up MS-PW 675 segments, they should have in-band PW OAM capabilities that relay PW 676 or attachment circuit defect notifications between the adjacent S- 677 PEs. 679 6.3.3. Resiliency 681 The solution should allow for the protection of a PW-segment, a 682 contiguous set of PW-segments, as well as the end-end path. The 683 primary and protection segments paths must share the same segments 684 endpoints. Solutions should allow for having the backup paths setup 685 prior to the failure or as a result of failure. The choice should be 686 made by configuration. When resources are limited and cannot satisfy 687 all PWs, the PWs with the higher setup priorities should be given 688 preference when compared with the setup priorities of other PWs being 689 setup or the holding priorities of existing PWs. 691 Solutions should strive to minimize traffic loss between T-PEs. 693 6.3.4. Quality of service 695 The CoS and bandwidth of the MS-PW must be configurable at T-PEs and 696 S-PEs. 698 6.4. Signaled PW-segments 700 When the MS-PW segments are dynamically signaled the following 701 requirements apply in addition to the generic requirements previously 702 defined. 704 These signaled MS-PW segments can be on the path of a statically 705 configured MS-PW, signaled/statically routed MS-PW or 706 signaled/dynamically routed MS-PW. 708 There are four different SS-PW signaling protocols that are defined 709 to signal PWs: 711 -i. Static setup of the SS-PW (MPLS or L2TPv3 forwarding). 713 -ii. LDP using PWid FEC 128 715 -iii. LDP using the generalized PW FEC 129 717 -iv. L2TPv3 719 The MS-PW setup mechanism MUST be able to support PW segments 720 signaled with any of the above protocols, however the specification 721 of which combinations of SS-PW signaling protocols is supported by a 722 specific implementation is outside the scope of this document. 724 For the signaled/statically routed and signaled/dynamically routed 725 MS-PW setup mechanisms the following requirements apply in addition 726 to the generic requirements previously defined. 728 6.4.1. Architecture 730 There are no additional requirements on the architecture. 732 6.4.2. Resiliency 734 Solutions should allow for the signaling of a protection path for a 735 PW segment, sequence of segments or end-to-end path. The protection 736 and primary paths for the protected segment(s) share the same 737 respective segments endpoints. When admission control is enabled, 738 systems must be careful not to double account for bandwidth 739 allocation at merged points (e.g., tunnels). Solutions should allow 740 for having the backup paths setup prior to the failure or as a result 741 of failure. The choice should be made by configuration at the 742 endpoints of the protected path. When resources are limited and 743 cannot satisfy all PWs, the PWs with the higher setup priorities 744 should be given preference when compared with the setup priorities of 745 other PWs being setup or the holding priorities of existing PWs. 746 Procedures must allow for the primary and backup paths to be 747 diversified 749 6.4.3. Quality of Service 751 When the T-PE attempts to signal a MS-PW the following capability is 752 required: 754 -i. Signaling must be able to identify the CoS associated with a 755 MS-PW 756 -ii. Signaling must be able to carry the traffic parameters for a 757 MS-PW per CoS. Traffic parameters should be based on 758 existing INTSERV definitions and must be used for admission 759 control when admission control is enabled. 761 -iii. The PW signaling MUST enable separate traffic parameter 762 values to be specified for the forward and reverse 763 directions of the PW. 765 -iv. PW traffic parameter representations MUST be the same for 766 all types of MS-PWs. 768 -v. The signaling protocol must be able to accommodate a method 769 to prioritize the PW setup and maintenance operation among 770 PWs. 772 6.4.4. Routing 774 See the requirements for "Resiliency" above. 776 Following are further requirements on signaled MS-PW setup 777 mechanisms: 779 -i. The signaling procedures MUST be defined such that the setup 780 of a MS-PW is considered successful if all segments of the 781 MS-PW are successfully setup. 783 -ii. The MS-PW path MUST have the ability to be dynamically setup 784 between the T-PEs by provisioning only the T-PEs. 786 -iii. Dynamic MS-PW setup requires that a unique identifier be 787 associated with a PW and be carried in the signaling 788 message. That identifier must contain sufficient information 789 to determine the path to the remote T-PE through 790 intermediate S-PEs. 792 -iv. In a single-provider domain it is natural to have the T-PE 793 identified by one of its IP addresses. This may also apply 794 when a MS-PW is setup across multiple domains operated by 795 the same provider. However, some service providers have 796 security and confidentiality policies that prevent them from 797 advertising reachability to routers in their networks to 798 other providers (reachability to an ASBR is an exception). 799 Thus, procedures MUST be provided to allow dynamic setup of 800 MS-PWs under these conditions. 802 6.5. Signaled PW / Dynamic Route 804 The following requirements apply, in addition to those in Section 6.1 805 and Section 6.2, when both dynamic signaling and dynamic routing are 806 used. 808 6.5.1. Architecture 810 There are no additional architectural requirements. 812 6.5.2. Resiliency 814 The PW Routing function MUST support dynamic re-routing around 815 failure points when segments are setup using the dynamic setup 816 method. 818 6.5.3. Quality of Service 820 There are no additional QoS requirements. 822 6.5.4. Routing 824 Following are requirements associated with dynamic route selection 825 for a MS-PW: 827 -i. Routing must enable S-PEs and T-PEs to discover S-PEs on the 828 path to a destination T-PE. 830 -ii. The MS-PW routing function MUST have the ability to 831 automatically select the S-PEs along the MS-PW path. Some of 832 the S-PEs MAY be statically selected and carried in the 833 signaling to constrain the route selection process. 835 -iii. The PW Routing function MUST support re-routing around 836 failures that occur between the statically configured 837 segment endpoints. This may be done by choosing another PSN 838 tunnel between the two segment endpoints or setting up an 839 alternative tunnel. 841 -iv. Routing protocols must be able to advertise reachability 842 information of attachment circuit (AC) endpoints. This 843 reachability information must be consistent with the AC 844 identifiers carried in signaling. 846 7. Operations and Maintenance (OAM) 848 OAM mechanisms for the attachment circuits are defined in the 849 specifications for PW emulated specific technologies (e.g., ITU-T 850 I.610 [i610] for ATM). These mechanisms enable, among other things, 851 defects in the network to be detected, localized and diagnosed. They 852 also enable communication of PW defect states on the PW attachment 853 circuit. 855 Note that this document uses the term OAM as Operations and 856 Management as per ITU-T I.610. 858 The interworking of OAM mechanisms for SS-PWs between ACs and PWs is 859 defined in [PWE3-OAM]. These enable defect states to be propagated 860 across a PWE3 network following the failure and recovery from faults. 862 OAM mechanisms for MS-PWs MUST provide at least the same capabilities 863 as those for SS-PWs. 865 In addition, it should be possible to support both segment and end- 866 to-end OAM mechanisms for both defect notifications and connectivity 867 verification in order to allow defects to be localized in a multi- 868 segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE 869 to S-PE, or S-PE to S-PE. 871 The following requirements apply to OAM for MS-PWs: 873 -i. Mechanisms for PW segment failure detection and notification 874 to other segments of a MS-PW MUST be provided. 876 -ii. MS-PW OAM SHOULD be supported end-to-end across the network. 878 -iii. Single ended monitoring SHOULD be supported for both 879 directions of the MS-PW. 881 -iv. SS-PW OAM mechanisms (e.g., [VCCV]) SHOULD be extended to 882 support MS-PWs on both end-end basis and segment basis. 884 -v. All PE routers along the MS-PW MUST agree on a common PW OAM 885 mechanism to use for the MS-PW. 887 -vi. At the S-PE, defects on an PSN tunnel MUST be propagated to 888 all PWs that utilize that particular PSN tunnel. 890 -vii. The directionality of defect notifications MUST be 891 maintained across the S-PE. 893 -viii. The S-PE SHOULD be able to behave as a segment endpoint for 894 PW OAM mechanisms. 896 -ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages 897 transparently. 899 -x. Performance OAM, is required for both MS-PWs and SS-PWs to 900 measure round-trip delay, one-way delay, jitter, and packet 901 loss ratio. 903 8. Management of Multi-Segment Pseudowires 905 Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms 906 for network operators to manage the emulated service. Management 907 mechanisms for MS-PWs MUST provide at least the same capabilities as 908 those for SS-PWs, as defined in [RFC3916]. 910 It SHOULD also be possible to manage the additional attributes for 911 MS-PWs. Since the operator that initiates the establishment of an 912 MS-PW may reside in a different PSN domain from the S-PEs and one of 913 the T-PEs along the path of the MS-PW, mechanisms for the remote 914 management of the MS-PW SHOULD be provided. 916 The following additional requirements apply: 918 8.1. MIB Requirements 920 -i. MIB Tables MUST be designed to facilitate configuration and 921 provisioning of the MS-PW at the S-PEs and T-PEs. 923 -ii. The MIB(s) MUST facilitate inter-PSN configuration and 924 monitoring of the ACs. 926 8.2. Management Interface Requirements 928 -i. Mechanisms MUST be provided to enable remote management of a 929 MS-PW at an S-PE or T-PE. It SHOULD be possible for these 930 mechanisms to operate across PSN domains. An example of a 931 commonly available mechanism is the command line interface 932 (CLI) over a telnet session. 934 -ii. For security or other reasons, it SHOULD be possible to 935 disable the remote management of a MS-PW. 937 9. Security Considerations 939 This document specifies the requirements for MS-PWs that can be setup 940 across domain boundaries administered by one ore more service 941 providers. The security requirements for MS-PW setup across domains 942 administered by one service provider are the same as those described 943 under security considerations in [RFC4447]. These requirements also 944 apply to interprovider MS-PWs. In addition, [RFC4111] identifies user 945 and provider requirements for L2 VPNs that apply to MS-PWs described 946 in this document. In this section, the focus is on the additional 947 security requirements for interprovider operation of MS-PWs in both 948 the control plane and data plane, and some of these requirements may 949 overlap with those in [RFC4111]. 951 9.1. Data-plane Security Requirements 953 MS-PWs that cross SP domain boundaries may connect one T-PE in a SP 954 domain to a T-PE in another SP-domain. They may also transit other SP 955 domains even if the two T-PEs are under the control of one SP. Under 956 these scenarios, there is a chance that one or more PDUs could be 957 falsely inserted into a MS-PW at any of the originating, terminating 958 or transit domains. Such false injection can be the result of a 959 malicious attack or fault in the MS-PW cross-connects. Solutions MAY 960 provide mechanisms for ensuring the end-to-end authenticity of MS-PW 961 PDUs. 963 One of the crossed domains may decide to selectively mirror the PDUs 964 of a MS-PW for eavesdropping purposes. It may also decide to 965 selectively hijack the PDUs of a MS-PW by directing the PDUs away 966 from their destination. In either case, the privacy of a MS-PDU can 967 be violated. 969 Some types pf PWs make assumptions about the security of the 970 underling PSN. The minimal security provided by an MPLS PSN might 971 not be sufficient to meet the security requirements expected by the 972 applications using the MS-PW. This document does not place any 973 requirements on protecting the privacy of a MS-PW PDU via encryption. 974 However, encryption is required at a higher layer in the protocol 975 stack, based on the application or network requirements." 977 The data plane of an S-PE at a domain boundary MUST be able to police 978 an incoming MS-PW traffic to the MS-PW traffic parameters or to an 979 administratively configured profile. The option to enable/disable 980 policing MUST be provided to the network administrator. This is to 981 ensure that a MS-PW or a group of MS-PWs do not grab more resources 982 than they are allocated. In addition, the data plane of an S-PE MUST 983 be able to police OAM messages to a pre-configured traffic profile or 984 to filter out these messages upon administrative configuration. 986 An ingress S-PE MUST ensure that a MS-PW receive the CoS treatment 987 configured or signaled for that MS-PW at the S-PE. Specifically, an 988 S-PE MUST guard against packets marked in the exp bits or IP-header 989 DS field (depending on the PSN) for a better CoS than they should 990 receive. 992 An ingress S-PE MUST be able to define per-interface or interface- 993 group (a group may correspond to interfaces to a peer-provider) label 994 space for MPLS-PWs. An S-PE MUST be configurable not to accept 995 labeled packets from another provider unless the bottom label is a 996 PW-label assigned by the S-PE on the interface on which the packet 997 arrived. 999 Data plane security considerations for SS-PWs specified in [RFC3985] 1000 also apply to MS-PWs. 1002 9.2. Control-plane Security Requirements 1004 A MS-PW connects two attachment circuits. It is important to make 1005 sure that PW connections are not arbitrarily accepted from anywhere, 1006 or else a local attachment circuit might get connected to an 1007 arbitrary remote attachment circuit. The fault in the connection can 1008 start at a remote T-PE or an S-PE. 1010 An incoming MS-PW request/reply MUST NOT be accepted unless its IP 1011 source address is known to be the source of an "eligible" peer. If a 1012 peering adjacency has to be established prior to exchanging setup 1013 requests/responses, peering MUST only be done with eligible peers. 1014 The set of eligible peers could be pre-configured (either as a list 1015 of IP addresses, or as a list of address/mask combinations) or 1016 automatically generated from the local PW configuration information. 1017 Furthermore, the restriction of peering sessions to specific 1018 interfaces MUST also be provided. The S-PE and T-PE MUST drop the 1019 unaccepted signaling messages in the data path to avoid a DoS attack 1020 on the control plane. 1022 Even if a connection request appears to come from an eligible peer, 1023 its source address may have been spoofed. So some means of preventing 1024 source address spoofing must be in place. For example, if eligible 1025 peers are in the same network, source address filtering at the border 1026 routers of that network could eliminate the possibility of source 1027 address spoofing. 1029 The configuration and maintenance protocol MUST provide a strong 1030 authentication and control protocol data protection mechanism. This 1031 option MUST be implemented , but it should be deployed according to 1032 the specific PSN environment requirements. Furthermore authentication 1033 using a signature for each individual MS-PW setup messages MUST be 1034 available, in addition to an overall control protocol session 1035 authentication, and message validation. 1037 Peer authentication protects against IP address spoofing but does not 1038 prevent one peer (S-PE or T-PE) from connecting to the wrong 1039 attachment circuit. Under a single administrative authority, this may 1040 be the result of a misconfiguration. When the MS-PW crosses multiple 1041 provider domains, this may be the result of a malicious act by a 1042 service provider or a security hole in that provider network. Static 1043 manual configuration of MS-PWs at S-PEs and T-PEs provide a greater 1044 degree of security. If an identification of both ends of a MS-PW is 1045 configured and carried in the signaling message, an S-PE can verify 1046 the signaling message against the configuration. To support dynamic 1047 signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs 1048 are dynamically discovered, mechanisms SHOULD be provided to 1049 configure such information on a server and to use that information 1050 during a connection attempt for validation. 1052 S-PEs that connect one provider domain to another provider domain 1053 MUST have the capability to rate-limit signaling traffic in order to 1054 prevent DoS attacks on the control plane. Furthermore, detection and 1055 disposition of malformed packets and defense against various forms of 1056 attacks that can be protocol-specific MUST be provided. 1058 10. Intellectual Property Statement 1060 The IETF takes no position regarding the validity or scope of any 1061 Intellectual Property Rights or other rights that might be claimed to 1062 pertain to the implementation or use of the technology described in 1063 this document or the extent to which any license under such rights 1064 might or might not be available; nor does it represent that it has 1065 made any independent effort to identify any such rights. Information 1066 on the procedures with respect to rights in RFC documents can be 1067 found in BCP 78 and BCP 79. 1069 Copies of IPR disclosures made to the IETF Secretariat and any 1070 assurances of licenses to be made available, or the result of an 1071 attempt made to obtain a general license or permission for the use of 1072 such proprietary rights by implementers or users of this 1073 specification can be obtained from the IETF on-line IPR repository at 1074 http://www.ietf.org/ipr. 1076 The IETF invites any interested party to bring to its attention any 1077 copyrights, patents or patent applications, or other proprietary 1078 rights that may cover technology that may be required to implement 1079 this standard. Please address the information to the IETF at ietf- 1080 ipr@ietf.org. 1082 11. Full Copyright Statement 1084 Copyright (C) The IETF Trust (2007). 1086 This document is subject to the rights, licenses and restrictions 1087 contained in BCP 78, and except as set forth therein, the authors 1088 retain all their rights. 1090 This document and the information contained herein are provided on an 1091 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1092 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1093 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1094 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1095 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1096 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1098 12. IANA Considerations 1100 This document has no IANA Actions. 1102 13. Normative References 1104 [RFC3916] "Requirements for Pseudo-Wire Emulation Edge-to-Edge 1105 (PWE3)", X. Xiao, D. McPherson, P. Pate, September 2004 1107 [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. 1109 14. Informative References 1111 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1112 Verification (VCCV)", Internet Draft 1113 "draft-ietf-pwe3-vccv-15.txt", September 2007.(work in progress) 1115 [RFC4447] L. Martini, Ed, et al., "Pseudowire Setup and 1116 Maintenance Using the Label Distribution Protocol (LDP)", 1117 RFC4447, April 2006 1119 [RFC4111] "Security Framework for 1120 Provider-Provisioned Virtual Private Networks (PPVPNs)," 1121 Fang. L., et al., RFC 4111, July 2005 1123 [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., 1124 draft-ietf-pwe3-oam-msg-map-02.txt (work in progress), 1125 February 2005 1127 [RFC2914] "Congestion Control Principles", S. Floyd, 1128 September 2000 1130 15. Author Information 1132 Nabil Bitar 1133 Verizon 1134 40 Sylvan Road 1135 Waltham, MA 02145 1136 e-mail: nabil.bitar@verizon.com 1137 Matthew Bocci 1138 Alcatel-Lucent Telecom Ltd, 1139 Voyager Place 1140 Shoppenhangers Road 1141 Maidenhead 1142 Berks, UK 1143 e-mail: matthew.bocci@alcatel-lucent.co.uk 1145 Luca Martini 1146 Cisco Systems, Inc. 1147 9155 East Nichols Avenue, Suite 400 1148 Englewood, CO, 80112 1149 e-mail: lmartini@cisco.com