idnits 2.17.1 draft-ietf-pwe3-ms-pw-requirements-07.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 1172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1150. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1156. 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 (June 2007) is 6153 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: December 2007 7 Luca Martini (Editor) Matthew Bocci (Editor) 8 Cisco Systems Inc. Alcatel-Lucent 10 June 2007 12 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) 14 draft-ietf-pwe3-ms-pw-requirements-07.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 Inter-Provider MS-PWs ................................ 23 87 9.1.1 Data-plane Security Requirements ..................... 24 88 9.1.2 Control-plane Security Requirements .................. 25 89 9.2 Intra-Provider MS-PWs ................................ 27 90 10 Intellectual Property Statement ...................... 27 91 11 Full Copyright Statement ............................. 28 92 12 IANA Considerations .................................. 28 93 13 Normative References ................................. 28 94 14 Informative References ............................... 29 95 15 Author Information ................................... 29 97 1. Specification of Requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119. 103 2. Acknowledgments 105 The editors gratefully acknowledge the following contributors: 106 Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel- 107 Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British 108 Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), 109 David McDyson (Verizon), Rahul Aggawal (Juniper), Du Ke (ZTE), 110 Cagatay Buyukkoc (ZTE) and Stewart Bryant (Cisco). 112 3. Introduction 114 3.1. Scope 116 This document specifies requirements for extending pseudowires across 117 more than one packet switched network (PSN) domain and/or more than 118 one PSN tunnel. These pseudowires are called multi-segment 119 pseudowires (MS-PW). Requirements for single-segment pseudowires 120 (SS-PW) that extend edge to edge across only one PSN domain are 121 specified in [RFC3916]. This document is not intended to invalidate 122 any part of [RFC3985]. 124 This document specifies additional requirements that apply to MS-PWs. 125 These requirements do not apply to PSNs that only support SS-PWs. 127 3.2. Architecture 129 The following three figures describe the reference models which are 130 derived from [RFC3985] to support PW emulated services. 132 |<-------------- Emulated Service ---------------->| 133 | | 134 | |<------- Pseudowire ------->| | 135 | | | | 136 | | |<-- PSN Tunnel -->| | | 137 | PW End V V V V PW End | 138 V Service +----+ +----+ Service V 139 +-----+ | | PE1|==================| PE2| | +-----+ 140 | |----------|............PW1.............|----------| | 141 | CE1 | | | | | | | | CE2 | 142 | |----------|............PW2.............|----------| | 143 +-----+ ^ | | |==================| | | ^ +-----+ 144 ^ | +----+ +----+ | | ^ 145 | | Provider Edge 1 Provider Edge 2 | | 146 | | | | 147 Customer | | Customer 148 Edge 1 | | Edge 2 149 | | 150 | | 151 Attachment Circuit (AC) Attachment Circuit (AC) 152 Native service Native service 154 Figure 1: PWE3 Reference Configuration 156 Figure 1 shows the PWE3 reference architecture [RFC3985]. This 157 architecture applies to the case where a PSN tunnel extends between 158 two edges of a single PSN domain to transport a PW with endpoints at 159 these edges. 161 Native |<--------Multi-Segment Pseudowire----->| Native 162 Service | PSN PSN | Service 163 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 164 | V V 1 V V 2 V V | 165 | +-----+ +-----+ +---- + | 166 +---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+ 167 | |---------|........PW1.......... |...PW3..........|---|----| | 168 |CE1| | | | | | | | | |CE2| 169 | |---------|........PW2...........|...PW4..........|--------| | 170 +---+ | | |==========| |==========| | | +---+ 171 ^ +-----+ +-----+ +-----+ ^ 172 | Provider Edge 1 ^ Provider Edge 3 | 173 | | | 174 | | | 175 | PW switching point | 176 | | 177 | | 178 |<------------------- Emulated Service ------------------->| 180 Figure 2: PW switching Reference Model 182 Figure 2 extends this architecture to show a multi-segment case. 183 Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3 184 service to CE1 and CE2. These PEs terminate different PSN tunnels, 185 PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or 186 pseudowire domains. One PSN tunnel extends from T-PE1 to S-PE1 across 187 PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across 188 PSN2. 190 PWs are used to connect the Attachment circuits (ACs) attached to T- 191 PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel 192 1 is switched to a PW in the tunnel across PSN2 at S-PE2 to complete 193 the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is 194 therefore the PW switching point and will be referred to as the PW 195 switching provider edge (S-PE). PW1 and PW3 are segments of the same 196 MS-PW while PW2 and PW4 are segments of another pseudowire. PW 197 segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW 198 type or different types, and PSN tunnels (e.g., PSN Tunnel 1 and PSN 199 Tunnel 2) can be the same or different technology. This document 200 requires support for MS-PWs with segments of the same PW type only. 201 An S-PE switches a MS-PW from one segment to another based on the PW 202 identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the 203 domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could be IGP 204 areas in the same IGP network, or simply PWE3 domains in a single 205 flat IGP network for instance. 207 |<------Multi-Segment Pseudowire------>| 208 | AS AS | 209 AC | |<----1---->| |<----2--->| | AC 210 | V V V V V V | 211 | +----+ +-----+ +----+ +----+ | 212 +----+ | | |=====| |=====| |=====| | | +----+ 213 | |-------|.....PW1..........PW2.........PW3.....|-------| | 214 | CE1| | | | | | | | | | | |CE2 | 215 +----+ | | |=====| |=====| |=====| | | +----+ 216 ^ +----+ +-----+ +----+ +----+ ^ 217 | T-PE1 S-PE2 S-PE3 T-PE4 | 218 | ^ ^ | 219 | | | | 220 | PW switching points | 221 | | 222 | | 223 |<------------------- Emulated Service --------------->| 225 Figure 3: PW switching inter provider Reference Model 227 Note that although Figure 2 only shows a single S-PE, a PW may 228 transit more than one S-PE along its path. For instance, in the 229 multi-AS case shown in Figure 3, there can be an S-PE (S-PE2), at the 230 border of one AS (AS1) and another S-PE (S-PE3) at the border of the 231 other AS (AS2). A MS-PW that extends from the edge of one AS (T-PE1) 232 to the edge of the other AS (T-PE4) is composed of three segments: 233 (1) PW1, a segment in AS1, (2) PW2, a segment between the two border 234 routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a 235 segment in AS2. AS1 and AS2 could be belong to the same provider 236 (e.g., AS1 could be an access network or metro transport network, and 237 AS2 could be an MPLS core network) or to two different providers 238 (e.g., AS1 for Provider 1 and AS2 for Provider2). 240 4. Terminology 242 RFC 3985 [RFC3985] provides terminology for PWE3. The following 243 additional terminology is defined for multi-segment pseudowires: 245 - PW Terminating Provider Edge (T-PE). A PE where the customer- 246 facing attachment circuits (ACs) are bound to a PW forwarder. A 247 Terminating PE is present in the first and last segments of a 248 MS-PW. This incorporates the functionality of a PE as defined in 249 RFC 3985. 251 - Single-Segment Pseudowire (SS-PW). A PW setup directly between 252 two PE devices. Each direction of a SS-PW traverses one PSN 253 tunnel that connects the two PEs. 255 - Multi-Segment Pseudowire (MS-PW). A static or dynamically 256 configured set of two or more contiguous PW segments that behave 257 and function as a single point-to-point PW. Each end of a MS-PW 258 by definition MUST terminate on a T-PE. 260 - PW Segment. A part of a single-segment or multi-segment PW, which 261 is set up between two PE devices, T-PEs and/or S-PEs. 263 - PW Switching Provider Edge (S-PE). A PE capable of switching the 264 control and data planes of the preceding and succeeding PW 265 segments in a MS-PW. The S-PE terminates the PSN tunnels 266 transporting the preceding and succeeding segments of the MS-PW. 267 It is therefore a PW switching point for a MS-PW. A PW Switching 268 Point is never the S-PE and the T-PE for the same MS-PW. A PW 269 switching point runs necessary protocols to setup and manage PW 270 segments with other PW switching points and terminating PEs. 272 5. Use Cases 274 PWE3 defines the signaling and encapsulation techniques for 275 establishing SS-PWs between a pair of terminating PEs (T-PEs) and in 276 the vast majority of cases this will be sufficient. MS-PWs may be 277 useful in the following situations: 279 -i. Inter-Provider PWs: An Inter-Provider PW is a PW that 280 extends from a T-PE in one provider domain to a T-PE in 281 another provider domain. 283 -ii. It may not be possible, desirable or feasible to establish a 284 direct PW control channel between the T-PEs, residing in 285 different provider networks, to setup and maintain PWs. At a 286 minimum, a direct PW control channel establishment (e.g., 287 targeted LDP session) requires knowledge of and reachability 288 to the remote T-PE IP address. The local T-PE may not have 289 access to this information due to operational or security 290 constraints. Moreover, a SS-PW would require the existence 291 of a PSN tunnel between the local T-PE and the remote T-PE. 292 It may not be feasible or desirable to extend single, 293 contiguous PSN tunnels between T-PEs in one domain and T-PEs 294 in another domain for security and/or scalability reasons or 295 because the two domains may be using different PSN 296 technologies. 298 -iii. MS-PW setup, maintenance and forwarding procedures must 299 satisfy requirements placed by the constraints of a multi- 300 provider environment. An example is the inter-AS L2VPN 301 scenario where the T-PEs reside in different provider 302 networks (ASs) and it is the current practice to MD5-key all 303 control traffic exchanged between two networks. A MS-PW 304 allows the providers to confine MD5 key administration for 305 the LDP session to just the PW switching points connecting 306 the two domains. 308 -iv. PSN Interworking: PWE3 signaling protocols and PSN types may 309 differ in different provider networks. The terminating PEs 310 may be connected to networks employing different PW 311 signaling and /or PSN protocols. In this case it is not 312 possible to use a SS-PW. A MS-PW with the appropriate 313 interworking performed at the PW switching points can enable 314 PW connectivity between the terminating PEs in this 315 scenario. 317 -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: 318 There is a requirement to deploy PWs edge to edge in large 319 service provider networks. Such networks typically encompass 320 hundreds or thousands of aggregation devices at the edge, 321 each of which would be a PE. Furthermore, there is a 322 requirement that these PWs have explicit bandwidth 323 guarantees. To satisfy these requirements, the PWs will be 324 tunneled over PSN TE-tunnels with bandwidth constraints. A 325 single segment pseudowire architecture would require that a 326 full mesh of PSN TE-tunnels be provisioned to allow PWs to 327 be established between all PEs. Inter-provider PWs riding 328 traffic engineered tunnels further add to the number of 329 tunnels that would have to be supported by the PEs and the 330 core network as the total number of PEs increases. 332 In this environment, there is a requirement either to 333 support a sparse mesh of PSN TE-tunnels and PW signaling 334 adjacencies, or to partition the network into a number of 335 smaller PWE3 domains. In either case, a PW would have to 336 pass through more than one PSN tunnel hop along its path. An 337 objective is to reduce the number of tunnels that must be 338 supported, and thus the complexity and scalability problem 339 that may arise. 341 -vi. Pseudowires in access/metro metworks: Service providers wish 342 to extend PW technology to access and metro networks in 343 order to reduce maintenance complexity and operational 344 costs. Today's access and metro networks are either legacy 345 (TDM, SONET/SDH, or Frame Relay/ATM), Ethernet or IP based. 347 Due to these architectures, circuits (e.g., Ethernet VCs, 348 ATM VCs, TDM circuits) in the access/metro are traditionally 349 handled as attachment circuits, in their native format, to 350 the edge of the IP-MPLS network where the PW starts. This 351 combination requires multiple separate access networks and 352 complicates end-to-end control, provisioning, and 353 maintenance. In addition, when a TDM or SONET/SDH access 354 network is replaced with a packet-based infrastructure, 355 expenses may be lowered due to moving statistical 356 multiplexing closer to the end-user and converging multiple 357 services onto a single access network. 359 Access networks have a number of properties that impact the 360 application of PWs. For example, there exist access 361 mechanisms where the PSN is not of an IETF specified type, 362 but uses mechanisms compatible with those of PWE3 at the PW 363 layer. Here, use case (iv) may apply. In addition, many 364 networks consist of hundreds or thousands of access devices. 365 There is therefore a desire to support a sparse mesh of PW 366 signaling adjacencies and PSN tunnels. Use case (v) may 367 therefore apply. Finally, Access networks also tend to 368 differ from core networks in that the access PW setup and 369 maintenance mechanism may only be a subset of that used in 370 the core. 372 Using the MS-PWs, access and metro network elements need 373 only maintain PW signaling adjacencies with the PEs to which 374 they directly connect. They do not need PW signaling 375 adjacencies with every other access and metro network 376 device. PEs in the PSN backbone in turn maintain PW 377 signaling adjacencies among each other. In addition, a PSN 378 tunnel is setup between an access element and the PE to 379 which it connects. Another PSN tunnel needs to be 380 established between every PE pair in the PSN backbone. A 381 MS-PW may be setup from one access network element to 382 another another access element with three segments: (1) 383 access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN- 384 PE to access element. In this MS-PW setup, access elements 385 are T-PEs while PSN-PEs are S-PEs. It should be noted that 386 the PSN backbone can be also segmented into PWE3 domains 387 resulting in more segments per PW. 389 5.1. Multi-Segment Pseudowire Placement Mechanisms 391 This requirements document assumes that the above use cases are 392 realized using one or more of the following mechanisms: 394 -i. Static Configuration: The switching points (S-PEs), in 395 addition to the T-PEs, are manually provisioned for each 396 segment. 398 -ii. Pre-determined Route: The PW is established along an 399 administratively determined route using an end-to-end 400 signaling protocol with automated stitching at the S-PEs. 402 -iii. Signaled Dynamic Route: The PW is established along a 403 dynamically determined route using an end-to-end signaling 404 protocol with automated stitching at the S-PEs. The route is 405 selected with the aid of one or more dynamic routing 406 protocols. 408 Note that we define the PW route to be the set of S-PEs through which 409 a MS-PW will pass between a given pair of T-PEs. PSN tunnels along 410 that route can be explicitly specified or locally selected at the S- 411 PEs and T-PEs. The routing of the PSN tunnels themselves is outside 412 the scope of the requirements specified in this document. 414 6. Multi-Segment Pseudowire Requirements 416 The following sections detail the requirements that the above use 417 cases put on the MS-PW setup mechanisms. 419 6.1. All Mechanisms 421 The following generic requirements apply to the three MS-PW setup 422 mechanisms defined in the previous section. 424 6.1.1. Architecture 426 -i. If MS-PWs are tunneled, across a PSN that only supports SS- 427 PWs, then only the requirements of [RFC3916] apply to that 428 PSN. The fact that the overlay is carrying MS-PWs MUST be 429 transparent to the routers in the PSN. 431 -ii. The PWs MUST remain transparent to the P-routers. A P-router 432 is not an S-PE or an T-PE from the MS-PW architecture 433 viewpoint. P-routers provide transparent PSN transport for 434 PWs and MUST not have any knowledge of the PWs traversing 435 them. 437 -iii. The MS-PWs MUST use the same encapsulation modes specified 438 for SS-PWs. 440 -iv. The MS-PWs MUST be composed of SS-PWs. 442 -v. A MS-PW MUST be able to pass across PSNs of all technologies 443 supported by PWE3 for SS-PWs. When crossing from one PSN 444 technology to another, an S-PE must provide the necessary 445 PSN interworking functions in that case. 447 -vi. Both directions of a PW segment MUST terminate on the same 448 S-PE/T-PE. 450 -vii. S-PEs MAY only support switching PWs of the same PW type. In 451 this case, the PW type is transparent to the S-PE in the 452 forwarding plane, except for functions needed to provide for 453 interworking between different PSN technologies. 455 -viii. Solutions MAY provide a way to prioritize the setup and 456 maintenance process among PWs. 458 6.1.2. Resiliency 460 Mechanisms to protect a MS-PW when an element on the existing path of 461 a MS-PW fails MUST be provided. These mechanisms will depend on the 462 MS-PW setup. Following are the generic resiliency requirements that 463 apply to all MS-PW setup mechanisms: 465 -i. Configuration and establishment of a backup PW to a primary 466 PW SHOULD be supported. Mechanisms to perform a switchover 467 from a primary PW to a backup PW upon failure detection 468 SHOULD be provided. 470 -ii. The ability to configure an end-to-end backup PW path for a 471 primary PW path SHOULD be supported. The primary and backup 472 paths may be statically configured, statically specified for 473 signaling or dynamically selected via dynamic routing 474 depending on the MS-PW establishment mechanism. Backup and 475 primary paths should have the ability to traverse separate 476 S-PEs. The backup path MAY be signaled at configuration time 477 or after failure. 479 -iii. The ability to configure a primary PW and a backup PW with a 480 different T-PE from the primary SHOULD be supported. 482 -iv. Automatic Mechanisms to perform a fast switchover from a 483 primary PW to a backup PW upon failure detection SHOULD be 484 provided. 486 -v. A mechanism to automatically revert to a primary PW from a 487 backup PW MAY be provided. When provided, it MUST be 488 configurable. 490 6.1.3. Quality Of Service 492 Pseudowires are intended to support emulated services (e.g., TDM and 493 ATM) which may have strict per-connection quality of service 494 requirements. This may include either absolute or relative guarantees 495 on packet loss, delay, and jitter. These guarantees are in part 496 delivered by reserving sufficient network resources (e.g. bandwidth), 497 and by providing appropriate per-packet treatment (e.g. scheduling 498 priority and drop precedence) throughout the network. 500 For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be 501 used to ensure that sufficient resources are reserved in the P- 502 routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST 503 have the ability to automatically request the PSN tunnel resources in 504 the direction of traffic (e.g. admission control of PWs onto the PSN 505 tunnel and accounting for reserved bandwidth and available bandwidth 506 on the tunnel). In cases where the tunnel supports multiple classes 507 of service (CoS) (e.g., E-LSP), bandwidth management is required per 508 CoS. 510 For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions 511 Must enable S-PEs and T-PEs to automatically bind a PW segment to a 512 PSN-tunnel based on CoS and bandwidth requirements when these 513 attributes are specified for a PW. Solutions SHOULD also provide the 514 capability of binding a PW segment to a tunnel as a matter of policy 515 configuration. S-PEs and T-PEs must be capable of automatically 516 requesting PSN-tunnel resources per CoS. 518 S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP 519 field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs 520 affects packet treatment. The CoS marking depends on the PSN 521 technology. Thus, solutions must enable the configuration of 522 necessary mapping for CoS marking when the MS-PW crosses from one PSN 523 technology to another. Similarly, different administrative domains 524 may use different CoS values to imply the same CoS treatment. 525 Solutions MUST provide the ability to define CoS marking maps on S- 526 PEs at administrative domain boundaries to translate from one CoS 527 value to another as a a PW PDU crosses from one domain to the next. 529 [RFC3985] requires PWs to respond to path congestion by reducing 530 their transmission rate. Alternatively, RFC3985 permits PWs that do 531 not have a congestion control mechanism to transmit using explicitly 532 reserved capacity along a provisioned path. Because MS-PWs are a type 533 of PW, this requirement extends to them as well. RFC3985 applied to 534 MS-PWs consequently requires that MS-PWs employ a congestion control 535 mechanism that is effective across a MS path, or requires an explicit 536 provisioning action that reserves sufficient capacity in all domains 537 along the MS path before the MS-PW begins transmission. S-PEs are 538 therefore REQUIRED to reject attempts to establish MS-PW segments for 539 PW types that either do not utilize an appropriate congestion control 540 scheme or when resources that are sufficient to support the 541 transmission rate of the PW cannot be reserved along the path. 543 6.1.4. Congestion Control 545 [RFC3985] requires all PWs to respond to congestion, in order to 546 conform to [RFC2914]. In the absence of a well-defined congestion 547 control mechanism, [RFC3985] permits PWs to be carried across paths 548 that have been provisioned such that the traffic caused by PWs has no 549 harmful effect on concurrent traffic that shares the path, even under 550 congestion. These requirements extend to the MS-PWs defined in this 551 document. 553 Path provisioning is frequently performed through QoS reservation 554 protocols or network management protocols. In the case of SS-PWs, 555 which remain within a single administrative domain, a number of 556 existing protocols can provide this provisioning functionality. MS- 557 PWs, however, may transmit across network domains that are under the 558 control of multiple entities. QoS provisioning across such paths is 559 inherently more difficult, due to the required inter-domain 560 interactions. It is important to note that these difficulties do not 561 invalidate the requirement to provision path capacity for MS-PW use. 562 Each domain MUST individually implement a method to control 563 congestion. This can be by QoS reservation, or other congestion 564 control method. MS-PWs MUST NOT transmit across unprovisioned, best 565 effort, paths in the absence of other congestion control schemes, as 566 required by [RFC3985]. 568 Solutions MUST enable S-PEs and T-PEs on the path of a MS-PW to 569 notify other S-PEs and T-PEs on that path of congestion when it 570 occurs. Congestion may be indicated by queue length, packet loss 571 rate, or bandwidth measurement (among others) crossing a respective 572 threshold. The action taken by a T-PE that receives a notification of 573 congestion along the path of one of its PWs could be to reroute the 574 MS-PW to an alternative path, including an alternative T-PE if 575 available. If a PE, or an S-PE has knowledge that a particular link 576 or tunnel is experiencing congestion , it MUST not setup any new MS- 577 PW that utilize that link or tunnel. Some PW types, such as TDM PWs, 578 are more sensitive to congestion than others. The reaction to a 579 congestion notification MAY vary per PW type. 581 6.2. Generic Requirements for MS-PW Setup Mechanisms 583 The MS-PW setup mechanisms MUST accommodate Service Provider's 584 practices, especially in relation to security, confidentiality of SP 585 information and traffic engineering. Security and confidentiality are 586 especially important when the MS-PWs are setup across Autonomous 587 Systems in different administrative domains. Following are generic 588 requirements that apply to the three MS-PW setup mechanisms defined 589 earlier: 591 -i. The ability to statically select S-PEs and PSN tunnels on a 592 PW path MUST be provided. Static selection of S-PEs is by 593 definition a requirement for the static configuration and 594 signaled/static route setup mechanisms. This requirement 595 satisfies the need for forcing a MS-PW to traverse specific 596 S-PEs to enforce service provider security and 597 administrative policies. 599 -ii. Solutions SHOULD minimize the amount of configuration needed 600 to setup a MS-PW. 602 -iii. Solutions should support different PW setup mechanisms on 603 the same T-PE, S-PE and PSN network. 605 -iv. Solutions MUST allow T-PEs to simultaneously support use of 606 SS-PW signaling mechanisms as specified in [RFC4447] as well 607 as MS-PW signaling mechanisms. 609 -v. Solutions MUST ensure that a MS-PW will be setup when a path 610 that satisfies the PW constraints for bandwidth, CoS and 611 other possible attributes does exist in the network. 613 -vi. Solutions must clearly define the setup procedures for each 614 mechanism so that a MS-PW setup on T-PEs can be interpreted 615 as successful only when all PW segments are successfully 616 setup. 618 -vii. Admission control to the PSN tunnel needs to be performed 619 against available resources, when applicable. This process 620 MUST be performed at each PW segment comprising the MS-PW. 621 PW admission control into a PSN tunnel MUST be configurable. 623 -viii. In case the PSN tunnel lacks the resources necessary to 624 accommodate the new PW, an attempt to signal a new PSN 625 tunnel, or increase the capacity of the existing PSN tunnel 626 MAY be made. If the expanded PSN tunnel fails to setup the 627 PW MUST fail to setup. 629 -ix. The setup mechanisms must allow the setup of a PW segment 630 between two directly connected S-PEs without the existence 631 of a PSN tunnel. This requirement allows a PW segment to be 632 setup between two (Autonomous System Border Routers (ASBRs) 633 when the MS-PW crosses AS boundaries without the need for 634 configuring and setting up a PSN tunnel. In this case, 635 admission control must be done, when enabled, on the link 636 between the S-PEs. 638 6.2.1. Routing 640 An objective of MS-PWs is to provide support for the following 641 connectivity: 643 -i. MS-PWs MUST be able to traverse multiple Service Provider 644 administrative domains. 646 -ii. MS-PWs MUST be able to traverse multiple Autonomous Systems 647 within the same administrative domain. 649 -iii. MS-PWs MUST be able to traverse multiple Autonomous Systems 650 belonging to different administrative domains. 652 -iv. MS-PWs MUST be able to support any hybrid combination of the 653 aforementioned connectivity scenarios, including both PW 654 transit, and termination in a domain. 656 6.3. Statically configured MS-PWs 658 When the MS-PW segments are statically configured the following 659 requirements apply in addition to the generic requirements previously 660 defined. 662 6.3.1. Architecture 664 There are no additional requirements on the architecture. 666 6.3.2. MPLS-PWs 668 Solutions should allow for the static configuration of MPLS labels 669 for MPLS-PW segments and the cross-connection of these labels to 670 preceding and succeeding segments. This is especially useful when a 671 MS-PW crosses provider boundaries and two providers do not want to 672 run any PW signaling protocol between them. A T-PE or S-PE that 673 allows the configuration of static labels for MS-PW segments should 674 also simultaneously allow for dynamic label assignments for other 675 MS-PW segments. It should be noted that when two interconnected S-PEs 676 do not have signaling peering for the purpose of setting up MS-PW 677 segments, they should have in-band PW OAM capabilities that relay PW 678 or attachment circuit defect notifications between the adjacent S- 679 PEs. 681 6.3.3. Resiliency 683 The solution should allow for the protection of a PW-segment, a 684 contiguous set of PW-segments, as well as the end-end path. The 685 primary and protection segments paths must share the same segments 686 endpoints. Solutions should allow for having the backup paths setup 687 prior to the failure or as a result of failure. The choice should be 688 made by configuration. When resources are limited and cannot satisfy 689 all PWs, the PWs with the higher setup priorities should be given 690 preference when compared with the setup priorities of other PWs being 691 setup or the holding priorities of existing PWs. 693 Solutions should strive to minimize traffic loss between T-PEs. 695 6.3.4. Quality of service 697 The CoS and bandwidth of the MS-PW must be configurable at T-PEs and 698 S-PEs. 700 6.4. Signaled PW-segments 702 When the MS-PW segments are dynamically signaled the following 703 requirements apply in addition to the generic requirements previously 704 defined. 706 These signaled MS-PW segments can be on the path of a statically 707 configured MS-PW, signaled/statically routed MS-PW or 708 signaled/dynamically routed MS-PW. 710 There are four different SS-PW signaling protocols that are defined 711 to signal PWs: 713 -i. Static setup of the SS-PW (MPLS or L2TPv3 forwarding). 715 -ii. LDP using PWid FEC 128 717 -iii. LDP using the generalized PW FEC 129 719 -iv. L2TPv3 721 The MS-PW setup mechanism MUST be able to support PW segments 722 signaled with any of the above protocols, however the specification 723 of which combinations of SS-PW signaling protocols is supported by a 724 specific implementation is outside the scope of this document. 726 For the signaled/statically routed and signaled/dynamically routed 727 MS-PW setup mechanisms the following requirements apply in addition 728 to the generic requirements previously defined. 730 6.4.1. Architecture 732 There are no additional requirements on the architecture. 734 6.4.2. Resiliency 736 Solutions should allow for the signaling of a protection path for a 737 PW segment, sequence of segments or end-to-end path. The protection 738 and primary paths for the protected segment(s) share the same 739 respective segments endpoints. When admission control is enabled, 740 systems must be careful not to double account for bandwidth 741 allocation at merged points (e.g., tunnels). Solutions should allow 742 for having the backup paths setup prior to the failure or as a result 743 of failure. The choice should be made by configuration at the 744 endpoints of the protected path. When resources are limited and 745 cannot satisfy all PWs, the PWs with the higher setup priorities 746 should be given preference when compared with the setup priorities of 747 other PWs being setup or the holding priorities of existing PWs. 748 Procedures must allow for the primary and backup paths to be 749 diversified 751 6.4.3. Quality of Service 753 When the T-PE attempts to signal a MS-PW the following capability is 754 required: 756 -i. Signaling must be able to identify the CoS associated with a 757 MS-PW 758 -ii. Signaling must be able to carry the traffic parameters for a 759 MS-PW per CoS. Traffic parameters should be based on 760 existing INTSERV definitions and must be used for admission 761 control when admission control is enabled. 763 -iii. The PW signaling MUST enable separate traffic parameter 764 values to be specified for the forward and reverse 765 directions of the PW. 767 -iv. PW traffic parameter representations MUST be the same for 768 all types of MS-PWs. 770 -v. The signaling protocol must be able to accommodate a method 771 to prioritize the PW setup and maintenance operation among 772 PWs. 774 6.4.4. Routing 776 See the requirements for "Resiliency" above. 778 Following are further requirements on signaled MS-PW setup 779 mechanisms: 781 -i. The signaling procedures MUST be defined such that the setup 782 of a MS-PW is considered successful if all segments of the 783 MS-PW are successfully setup. 785 -ii. The MS-PW path MUST have the ability to be dynamically setup 786 between the T-PEs by provisioning only the T-PEs. 788 -iii. Dynamic MS-PW setup requires that a unique identifier be 789 associated with a PW and be carried in the signaling 790 message. That identifier must contain sufficient information 791 to determine the path to the remote T-PE through 792 intermediate S-PEs. 794 -iv. In a single-provider domain it is natural to have the T-PE 795 identified by one of its IP addresses. This may also apply 796 when a MS-PW is setup across multiple domains operated by 797 the same provider. However, some service providers have 798 security and confidentiality policies that prevent them from 799 advertising reachability to routers in their networks to 800 other providers (reachability to an ASBR is an exception). 801 Thus, procedures MUST be provided to allow dynamic setup of 802 MS-PWs under these conditions. 804 6.5. Signaled PW / Dynamic Route 806 The following requirements apply, in addition to those in Section 6.1 807 and Section 6.2, when both dynamic signaling and dynamic routing are 808 used. 810 6.5.1. Architecture 812 There are no additional architectural requirements. 814 6.5.2. Resiliency 816 The PW Routing function MUST support dynamic re-routing around 817 failure points when segments are setup using the dynamic setup 818 method. 820 6.5.3. Quality of Service 822 There are no additional QoS requirements. 824 6.5.4. Routing 826 Following are requirements associated with dynamic route selection 827 for a MS-PW: 829 -i. Routing must enable S-PEs and T-PEs to discover S-PEs on the 830 path to a destination T-PE. 832 -ii. The MS-PW routing function MUST have the ability to 833 automatically select the S-PEs along the MS-PW path. Some of 834 the S-PEs MAY be statically selected and carried in the 835 signaling to constrain the route selection process. 837 -iii. The PW Routing function MUST support re-routing around 838 failures that occur between the statically configured 839 segment endpoints. This may be done by choosing another PSN 840 tunnel between the two segment endpoints or setting up an 841 alternative tunnel. 843 -iv. Routing protocols must be able to advertise reachability 844 information of attachment circuit (AC) endpoints. This 845 reachability information must be consistent with the AC 846 identifiers carried in signaling. 848 7. Operations and Maintenance (OAM) 850 OAM mechanisms for the attachment circuits are defined in the 851 specifications for PW emulated specific technologies (e.g., ITU-T 852 I.610 [i610] for ATM). These mechanisms enable, among other things, 853 defects in the network to be detected, localized and diagnosed. They 854 also enable communication of PW defect states on the PW attachment 855 circuit. 857 Note that this document uses the term OAM as Operations and 858 Management as per ITU-T I.610. 860 The interworking of OAM mechanisms for SS-PWs between ACs and PWs is 861 defined in [PWE3-OAM]. These enable defect states to be propagated 862 across a PWE3 network following the failure and recovery from faults. 864 OAM mechanisms for MS-PWs MUST provide at least the same capabilities 865 as those for SS-PWs. 867 In addition, it should be possible to support both segment and end- 868 to-end OAM mechanisms for both defect notifications and connectivity 869 verification in order to allow defects to be localized in a multi- 870 segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE 871 to S-PE, or S-PE to S-PE. 873 The following requirements apply to OAM for MS-PWs: 875 -i. Mechanisms for PW segment failure detection and notification 876 to other segments of a MS-PW MUST be provided. 878 -ii. MS-PW OAM SHOULD be supported end-to-end across the network. 880 -iii. Single ended monitoring SHOULD be supported for both 881 directions of the MS-PW. 883 -iv. SS-PW OAM mechanisms (e.g., [VCCV]) SHOULD be extended to 884 support MS-PWs on both end-end basis and segment basis. 886 -v. All PE routers along the MS-PW MUST agree on a common PW OAM 887 mechanism to use for the MS-PW. 889 -vi. At the S-PE, defects on an PSN tunnel MUST be propagated to 890 all PWs that utilize that particular PSN tunnel. 892 -vii. The directionality of defect notifications MUST be 893 maintained across the S-PE. 895 -viii. The S-PE SHOULD be able to behave as a segment endpoint for 896 PW OAM mechanisms. 898 -ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages 899 transparently. 901 -x. Performance OAM, is required for both MS-PWs and SS-PWs to 902 measure round-trip delay, one-way delay, jitter, and packet 903 loss ratio. 905 8. Management of Multi-Segment Pseudowires 907 Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms 908 for network operators to manage the emulated service. Management 909 mechanisms for MS-PWs MUST provide at least the same capabilities as 910 those for SS-PWs, as defined in [RFC3916]. 912 It SHOULD also be possible to manage the additional attributes for 913 MS-PWs. Since the operator that initiates the establishment of an 914 MS-PW may reside in a different PSN domain from the S-PEs and one of 915 the T-PEs along the path of the MS-PW, mechanisms for the remote 916 management of the MS-PW SHOULD be provided. 918 The following additional requirements apply: 920 8.1. MIB Requirements 922 -i. MIB Tables MUST be designed to facilitate configuration and 923 provisioning of the MS-PW at the S-PEs and T-PEs. 925 -ii. The MIB(s) MUST facilitate inter-PSN configuration and 926 monitoring of the ACs. 928 8.2. Management Interface Requirements 930 -i. Mechanisms MUST be provided to enable remote management of a 931 MS-PW at an S-PE or T-PE. It SHOULD be possible for these 932 mechanisms to operate across PSN domains. An example of a 933 commonly available mechanism is the command line interface 934 (CLI) over a telnet session. 936 -ii. For security or other reasons, it SHOULD be possible to 937 disable the remote management of a MS-PW. 939 9. Security Considerations 941 This document specifies the requirements both for MS-PWs that can be 942 setup across domain boundaries administered by one or more service 943 providers (inter-provider MS-PWs), and for MS-PWs that are only setup 944 across one provider (intra-provider MS-PWs). 946 9.1. Inter-Provider MS-PWs 948 The security requirements for MS-PW setup across domains administered 949 by one service provider are the same as those described under 950 security considerations in [RFC4447] and [RFC3916]. These 951 requirements also apply to interprovider MS-PWs. 953 In addition, [RFC4111] identifies user and provider requirements for 954 L2 VPNs that apply to MS-PWs described in this document. In this 955 section, the focus is on the additional security requirements for 956 interprovider operation of MS-PWs in both the control plane and data 957 plane, and some of these requirements may overlap with those in 958 [RFC4111]. 960 9.1.1. Data-plane Security Requirements 962 By security in the "data plane", we mean protection against the 963 following possibilities: 965 -i. Packets from within an MS-PW traveling to a PE or an AC that 966 the PW is not intended to be connected to, other than in a 967 manner consistent with the policies of the MS-PW. 969 -ii. Packets from outside an MS-PW entering the MS-PW, other than 970 in a manner consistent with the policies of the MS-PW. 972 MS-PWs that cross service provider (SP) domain boundaries may connect 973 one T-PE in a SP domain to a T-PE in another provider domain. They 974 may also transit other provider domains even if the two T-PEs are 975 under the control of one SP. Under these scenarios, there is a chance 976 that one or more PDUs could be falsely inserted into a MS-PW at any 977 of the originating, terminating or transit domains. Such false 978 injection can be the result of a malicious attack or fault in the S- 979 PE. Solutions MAY provide mechanisms for ensuring the end-to-end 980 authenticity of MS-PW PDUs. 982 The data plane security requirements at a service provider border for 983 MS-PWs are similar to those for inter-provider BGP/MPLS IP Virtual 984 Private Networks [RFC4364]. In particular, an S-PE or T-PE SHOULD 985 discard a packet received from a particular neighbor over the service 986 provider border unless one of the following two conditions holds: 988 -iii. any MPLS label processed at the receiving S-PE or T-PE, such 989 the PSN tunnel label or the PW label, has a label value that 990 the receiving system has distributed to that neighbor, or 992 -iv. any MPLS label processed at the receiving S-PE or T-PE, such 993 as the PSN tunnel label or the PW label, has a label value 994 that the receiving S-PE or T-PE has previously distributed 995 to the peer S-PE or T-PE beyond that neighbor (i.e., when it 996 is known that the path from the system to which the label 997 was distributed to the receiving system is via that 998 neighbor). 1000 One of the domains crossed by a MS-PW may decide to selectively 1001 mirror the PDUs of a MS-PW for eavesdropping purposes. It may also 1002 decide to selectively hijack the PDUs of a MS-PW by directing the 1003 PDUs away from their destination. In either case, the privacy of a 1004 MS-PW can be violated. 1006 Some types of PWs make assumptions about the security of the 1007 underling PSN. The minimal security provided by an MPLS PSN might 1008 not be sufficient to meet the security requirements expected by the 1009 applications using the MS-PW. This document does not place any 1010 requirements on protecting the privacy of a MS-PW PDU via encryption. 1011 However, encryption may be required at a higher layer in the protocol 1012 stack, based on the application or network requirements. 1014 The data plane of an S-PE at a domain boundary MUST be able to police 1015 incoming MS-PW traffic to the MS-PW traffic parameters or to an 1016 administratively configured profile. The option to enable/disable 1017 policing MUST be provided to the network administrator. This is to 1018 ensure that a MS-PW or a group of MS-PWs do not grab more resources 1019 than they are allocated. In addition, the data plane of an S-PE MUST 1020 be able to police OAM messages to a pre-configured traffic profile or 1021 to filter out these messages upon administrative configuration. 1023 An ingress S-PE MUST ensure that a MS-PW receive the CoS treatment 1024 configured or signaled for that MS-PW at the S-PE. Specifically, an 1025 S-PE MUST guard against packets marked in the exp bits or IP-header 1026 DS field (depending on the PSN) for a better CoS than they should 1027 receive. 1029 An ingress S-PE MUST be able to define per-interface or interface- 1030 group (a group may correspond to interfaces to a peer-provider) label 1031 space for MPLS-PWs. An S-PE MUST be configurable not to accept 1032 labeled packets from another provider unless the bottom label is a 1033 PW-label assigned by the S-PE on the interface on which the packet 1034 arrived. 1036 Data plane security considerations for SS-PWs specified in [RFC3985] 1037 also apply to MS-PWs. 1039 9.1.2. Control-plane Security Requirements 1041 A MS-PW connects two attachment circuits. It is important to make 1042 sure that PW connections are not arbitrarily accepted from anywhere, 1043 or else a local attachment circuit might get connected to an 1044 arbitrary remote attachment circuit. The fault in the connection can 1045 start at a remote T-PE or an S-PE. 1047 Where a PW segment crosses a border between one provider and another 1048 provider, the PW segment endpoints (S-PEs) SHOULD be on ASBRs 1049 interconnecting the two providers. Directly interconnecting the S-PEs 1050 using a physically secure link, and enabling signaling and routing 1051 authentication between the S-PEs, eliminates the possibility of 1052 receiving a MS-PW signaling message or packet from an untrusted peer. 1053 Other configurations are possible, for example, P routers for the PSN 1054 tunnel between the adjacent S-PEs/T-PEs may reside on the ASBRs. In 1055 which case, the S-PEs/T-PEs MUST satisfy themselves of the security 1056 and privacy of the path. 1058 The configuration and maintenance protocol MUST provide a strong 1059 authentication and control protocol data protection mechanism. This 1060 option MUST be implemented, but it should be deployed according to 1061 the specific PSN environment requirements. Furthermore, 1062 authentication using a signature for each individual MS-PW setup 1063 messages MUST be available, in addition to an overall control 1064 protocol session authentication, and message validation. 1066 Since S-PEs in different provider networks SHOULD reside at each end 1067 of a physically secure link, or be interconnected by a limited number 1068 of trusted PSN tunnels, each S-PE will have a trust relationship with 1069 only a limited number of S-PEs in other ASs. Thus, it is expected 1070 that current security mechanisms based on manual key management will 1071 be sufficient. If deployment situations arise that require large 1072 scale connection of to S-PEs in other ASs, then a mechanism based on 1073 RFC 4107 [RFC4107] MUST be developed. 1075 Peer authentication protects against IP address spoofing but does not 1076 prevent one peer (S-PE or T-PE) from connecting to the wrong 1077 attachment circuit. Under a single administrative authority, this may 1078 be the result of a misconfiguration. When the MS-PW crosses multiple 1079 provider domains, this may be the result of a malicious act by a 1080 service provider or a security hole in that provider network. Static 1081 manual configuration of MS-PWs at S-PEs and T-PEs provides a greater 1082 degree of security. If an identification of both ends of a MS-PW is 1083 configured and carried in the signaling message, an S-PE can verify 1084 the signaling message against the configuration. To support dynamic 1085 signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs 1086 are dynamically discovered, mechanisms SHOULD be provided to 1087 configure such information on a server and to use that information 1088 during a connection attempt for validation. 1090 An incoming MS-PW request/reply MUST NOT be accepted unless its IP 1091 source address is known to be the source of an "eligible" peer. An 1092 eligible peer is an S-PE or a T-PE with which the originating S-PE or 1093 T-PE has a trust relationship. The number of such trusted T-PEs or 1094 S-PEs is bounded and not anticipated to create a scaling issue for 1095 the contol plane authentication mechanisms. 1097 If a peering adjacency has to be established prior to exchanging 1098 setup requests/responses, peering MUST only be done with eligible 1099 peers. The set of eligible peers could be pre-configured (either as a 1100 list of IP addresses, or as a list of address/mask combinations) or 1101 automatically generated from the local PW configuration information. 1103 Furthermore, the restriction of peering sessions to specific 1104 interfaces MUST also be provided. The S-PE and T-PE MUST drop the 1105 unaccepted signaling messages in the data path to avoid a DoS attack 1106 on the control plane. 1108 Even if a connection request appears to come from an eligible peer, 1109 its source address may have been spoofed. So some means of preventing 1110 source address spoofing must be in place. For example, if eligible 1111 peers are in the same network, source address filtering at the border 1112 routers of that network could eliminate the possibility of source 1113 address spoofing. 1115 S-PEs that connect one provider domain to another provider domain 1116 MUST have the capability to rate-limit signaling traffic in order to 1117 prevent DoS attacks on the control plane. Furthermore, detection and 1118 disposition of malformed packets and defense against various forms of 1119 attacks that can be protocol-specific MUST be provided. 1121 9.2. Intra-Provider MS-PWs 1123 Security requirements for pseudowires are provided in [RFC3916]. 1124 These requirements also apply to MS-PWs. 1126 MS-PWs are intended to enable many more PEs to provide PWE3 services 1127 in a given service providers network than traditional SS-PWs, 1128 particularly in access and metro environments where the PE may be 1129 situated closer to the ultimate endpoint of the service. In order to 1130 limit the impact of a compromise of one T-PE in a service providers 1131 network, the data path security requirements for inter-provider MS- 1132 PWs also apply to intra-provider MS-PWs in such cases. 1134 10. Intellectual Property Statement 1136 The IETF takes no position regarding the validity or scope of any 1137 Intellectual Property Rights or other rights that might be claimed to 1138 pertain to the implementation or use of the technology described in 1139 this document or the extent to which any license under such rights 1140 might or might not be available; nor does it represent that it has 1141 made any independent effort to identify any such rights. Information 1142 on the procedures with respect to rights in RFC documents can be 1143 found in BCP 78 and BCP 79. 1145 Copies of IPR disclosures made to the IETF Secretariat and any 1146 assurances of licenses to be made available, or the result of an 1147 attempt made to obtain a general license or permission for the use of 1148 such proprietary rights by implementers or users of this 1149 specification can be obtained from the IETF on-line IPR repository at 1150 http://www.ietf.org/ipr. 1152 The IETF invites any interested party to bring to its attention any 1153 copyrights, patents or patent applications, or other proprietary 1154 rights that may cover technology that may be required to implement 1155 this standard. Please address the information to the IETF at ietf- 1156 ipr@ietf.org. 1158 11. Full Copyright Statement 1160 Copyright (C) The IETF Trust (2008). 1162 This document is subject to the rights, licenses and restrictions 1163 contained in BCP 78, and except as set forth therein, the authors 1164 retain all their rights. 1166 This document and the information contained herein are provided on an 1167 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1168 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1169 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1170 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1171 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1172 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1174 12. IANA Considerations 1176 This document has no IANA Actions. 1178 13. Normative References 1180 [RFC3916] "Requirements for Pseudo-Wire Emulation Edge-to-Edge 1181 (PWE3)", X. Xiao, D. McPherson, P. Pate, September 2004 1183 [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. 1185 14. Informative References 1187 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1188 Verification (VCCV)", Internet Draft 1189 "draft-ietf-pwe3-vccv-15.txt", September 2007.(work in progress) 1191 [RFC4447] L. Martini, Ed, et al., "Pseudowire Setup and 1192 Maintenance Using the Label Distribution Protocol (LDP)", 1193 RFC4447, April 2006 1195 [RFC4111] "Security Framework for 1196 Provider-Provisioned Virtual Private Networks (PPVPNs)," 1197 Fang. L., et al., RFC 4111, July 2005 1199 [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., 1200 draft-ietf-pwe3-oam-msg-map-02.txt (work in progress), 1201 February 2005 1203 [RFC2914] "Congestion Control Principles", S. Floyd, 1204 September 2000 1206 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", 1207 E. Rosen et al, February 2006 1209 [RFC4107] "Guidelines for Cryptographic Key Management", 1210 S. Belloin et al, June 2005 1212 15. Author Information 1214 Nabil Bitar 1215 Verizon 1216 40 Sylvan Road 1217 Waltham, MA 02145 1218 e-mail: nabil.bitar@verizon.com 1220 Matthew Bocci 1221 Alcatel-Lucent Telecom Ltd, 1222 Voyager Place 1223 Shoppenhangers Road 1224 Maidenhead 1225 Berks, UK 1226 e-mail: matthew.bocci@alcatel-lucent.co.uk 1227 Luca Martini 1228 Cisco Systems, Inc. 1229 9155 East Nichols Avenue, Suite 400 1230 Englewood, CO, 80112 1231 e-mail: lmartini@cisco.com