idnits 2.17.1 draft-ietf-pwe3-ms-pw-requirements-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1002. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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. -- 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 (January 2007) is 6304 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3916 ** Downref: Normative reference to an Informational RFC: RFC 3985 -- 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: 5 errors (**), 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 Expiration Date: July 2007 6 Luca Martini (Editor) Matthew Bocci (Editor) 7 Cisco Systems Inc. Alcatel 9 January 2007 11 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) 13 draft-ietf-pwe3-ms-pw-requirements-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes the necessary requirements to allow a service 40 provider to extend the reach of pseudowires across multiple domains. 41 These domains can be autonomous systems under one provider 42 administrative control, IGP areas in one autonomous system, different 43 autonomous systems under the administrative control of two or more 44 service providers, or administratively established pseudowire 45 domains. 47 Table of Contents 49 1 Specification of Requirements ........................ 4 50 2 Acknowledgments ...................................... 4 51 3 Introduction ......................................... 4 52 3.1 Scope ................................................ 4 53 3.2 Architecture ......................................... 4 54 4 Terminology .......................................... 7 55 5 Use Cases ............................................ 8 56 5.1 Multi-Segment Pseudowire Placement Mechanisms ........ 11 57 6 Multi-Segment Pseudowire Requirements ................ 11 58 6.1 All Mechanisms ....................................... 11 59 6.1.1 Architecture ......................................... 11 60 6.1.2 Resiliency ........................................... 12 61 6.1.3 Quality Of Service ................................... 13 62 6.2 Generic Requirements for MS-PW Setup Mechanisms ...... 14 63 6.2.1 Routing .............................................. 15 64 6.3 Statically configured MS-PWs ......................... 16 65 6.3.1 Architecture ......................................... 16 66 6.3.2 MPLS-PWs ............................................. 16 67 6.3.3 Resiliency ........................................... 16 68 6.3.4 Quality of service ................................... 17 69 6.4 Signaled PW-segments ................................. 17 70 6.4.1 Architecture ......................................... 17 71 6.4.2 Resiliency ........................................... 17 72 6.4.3 Quality of Service ................................... 18 73 6.4.4 Routing .............................................. 18 74 6.5 Signaled PW / Dynamic Route .......................... 19 75 6.5.1 Architecture ......................................... 19 76 6.5.2 Resiliency ........................................... 19 77 6.5.3 Quality of Service ................................... 19 78 6.5.4 Routing .............................................. 20 79 7 Operations and Maintenance (OAM) ..................... 20 80 8 Security Considerations .............................. 21 81 8.1 Data-plane Security Requirements ..................... 22 82 8.2 Control-plane Security Requirements .................. 23 83 9 Full Copyright Statement ............................. 24 84 10 Intellectual Property Statement ...................... 24 85 11 IANA Considerations .................................. 25 86 12 Normative References ................................. 25 87 13 Informative References ............................... 25 88 14 Author Information ................................... 25 90 1. Specification of Requirements 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. 96 2. Acknowledgments 98 The editors gratefully acknowledge the following contributors: 99 Dimitri Papadimitriou (Alcatel), Peter Busschbach (Lucent), Sasha 100 Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord 101 (France Telecom), Deborah Brungard (AT&T), David McDyson, Rahul 102 Aggawal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE). 104 3. Introduction 106 3.1. Scope 108 This document specifies requirements for extending pseudowires across 109 more than one packet switched network (PSN) domain and/or more than 110 one PSN tunnel. These pseudowires are called multi-segment 111 pseudowires (MS-PW). Requirements for single-segment pseudowires 112 (SS-PW) that extend edge to edge across only one PSN domain are 113 specified in [RFC3916]. 115 This document specifies additional requirements that apply to MS-PWs. 116 These requirements do not apply to PSNs that only support SS-PWs. 118 3.2. Architecture 120 The following three figures describe the reference models which are 121 derived from [RFC3985] to support PW emulated services. 123 |<-------------- Emulated Service ---------------->| 124 | | 125 | |<------- Pseudowire ------->| | 126 | | | | 127 | | |<-- PSN Tunnel -->| | | 128 | PW End V V V V PW End | 129 V Service +----+ +----+ Service V 130 +-----+ | | PE1|==================| PE2| | +-----+ 131 | |----------|............PW1.............|----------| | 132 | CE1 | | | | | | | | CE2 | 133 | |----------|............PW2.............|----------| | 134 +-----+ ^ | | |==================| | | ^ +-----+ 135 ^ | +----+ +----+ | | ^ 136 | | Provider Edge 1 Provider Edge 2 | | 137 | | | | 138 Customer | | Customer 139 Edge 1 | | Edge 2 140 | | 141 | | 142 Attachment Circuit (AC) Attachment Circuit (AC) 143 Native service Native service 145 Figure 1: PWE3 Reference Configuration 147 Figure 1 shows the PWE3 reference architecture [RFC3985]. This 148 architecture applies to the case where a PSN tunnel extends between 149 two edges of a single PSN domain to transport a PW with endpoints at 150 these edges. 152 Native |<--------Multi-Segment Pseudowire----->| Native 153 Service | PSN PSN | Service 154 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 155 | V V 1 V V 2 V V | 156 | +-----+ +-----+ +---- + | 157 +---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+ 158 | |---------|........PW1.......... |...PW3..........|---|----| | 159 |CE1| | | | | | | | | |CE2| 160 | |---------|........PW2...........|...PW4..........|--------| | 161 +---+ | | |==========| |==========| | | +---+ 162 ^ +-----+ +-----+ +-----+ ^ 163 | Provider Edge 1 ^ Provider Edge 3 | 164 | | | 165 | | | 166 | PW switching point | 167 | | 168 | | 169 |<------------------- Emulated Service ------------------->| 171 Figure 2: PW switching Reference Model 173 Figure 2 extends this architecture to show a multi-segment case. 174 Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3 175 service to CE1 and CE2. These PEs terminate different PSN tunnels, 176 PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or 177 pseudowire domains. One PSN tunnel extends from T-PE1 to S-PE1 across 178 PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across 179 PSN2. 181 PWs are used to connect the Attachment circuits (ACs) attached to T- 182 PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel 183 1 is switched to a PW in the tunnel across PSN2 at S-PE2 to complete 184 the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is 185 therefore the PW switching point and will be referred to as the PW 186 switching provider edge (S-PE). PW1 and PW3 are segments of the same 187 MS-PW while PW2 and PW4 are segments of another pseudowire. PW 188 segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW 189 type or different type, and PSN tunnels (e.g., PSN Tunnel 1 and PSN 190 Tunnel 2) can be the same or different technology. This document 191 requires support for MS-PWs with segments of the same PW type. An S- 192 PE switches a MS-PW from one segment to another based on the PW 193 identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the 194 domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could beIGP areas 195 in the same IGP network, or simply PWE3 domains in a single flat IGP 196 network for instance. 198 |<------Multi-Segment Pseudowire------>| 199 | AS AS | 200 AC | |<----1---->| |<----2--->| | AC 201 | V V V V V V | 202 | +----+ +-----+ +----+ +----+ | 203 +----+ | | |=====| |=====| |=====| | | +----+ 204 | |-------|.....PW1..........PW2.........PW3.....|-------| | 205 | CE1| | | | | | | | | | | |CE2 | 206 +----+ | | |=====| |=====| |=====| | | +----+ 207 ^ +----+ +-----+ +----+ +----+ ^ 208 | T-PE1 S-PE2 S-PE3 T-PE4 | 209 | ^ ^ | 210 | | | | 211 | PW switching points | 212 | | 213 | | 214 |<------------------- Emulated Service --------------->| 216 Figure 3: PW switching inter provider Reference Model 218 Note that although Figure 2 only shows a single S-PE, a PW may 219 transit more than one S-PE along its path. For instance, in the 220 multi-AS case shown in Figure 3, there can be an S-PE (S-PE2), at the 221 border of one AS (AS1) and another S-PE (S-PE3) at the border of the 222 other AS (AS2). A MS-PW that extends from the edge of one AS (T-PE1) 223 to the edge of the other AS (T-PE4) is composed of three segments: 224 (1) PW1, a segment in AS1, (2) PW2, a segment between the two border 225 routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a 226 segment in AS2. AS1 and AS2 could be belong to the same provider 227 (e.g., AS1 could be an access network or metro transport network, and 228 AS2 could be an MPLS core network) or to two different providers 229 (e.g., AS1 for Provider 1 and AS2 for Provider2). 231 4. Terminology 233 RFC 3985 [RFC3985] provides terminology for PWE3. The following 234 additional terminology is defined for multi-segment pseudowires: 236 - PW Terminating Provider Edge (T-PE). A PE where the customer- 237 facing attachment circuits (ACs) are bound to a PW forwarder. A 238 Terminating PE is present in the first and last segments of a 239 MS-PW. This incorporates the functionality of a PE as defined in 240 RFC 3985. 242 - Single-Segment Pseudowire (SS-PW). A PW setup directly between 243 two T-PE devices. Each direction of a SS-PW traverses one PSN 244 tunnel that connects the two T-PEs. 246 - Multi-Segment Pseudowire (MS-PW). A static or dynamically 247 configured set of two or more contiguous PW segments that behave 248 and function as a single point-to-point PW. Each end of a MS-PW 249 by definition MUST terminate on a T-PE. 251 - PW Segment. A part of a single-segment or multi-segment PW, which 252 is set up between two PE devices, T-PEs and/or S-PEs. 254 - PW Switching Provider Edge (S-PE). A PE capable of switching the 255 control and data planes of the preceding and succeeding PW 256 segments in a MS-PW. The S-PE terminates the PSN tunnels 257 transporting the preceding and succeeding segments of the MS-PW. 258 It is therefore a PW switching point for a MS-PW. A PW Switching 259 Point is never the S-PE and the T-PE for the same MS-PW. A PW 260 switching point runs necessary protocols to setup and manage PW 261 segments with other PW switching points and terminating PEs. 263 5. Use Cases 265 PWE3 defines the signaling and encapsulation techniques for 266 establishing SS-PWs between a pair of terminating PEs (T-PEs) and in 267 the vast majority of cases this will be sufficient. MS-PWs may be 268 useful in the following situations: 270 -i. Inter-Provider PWs: An Inter-Provider PW is a PW that 271 extends from a T-PE in one provider domain to a T-PE in 272 another provider domain. 274 -ii. It may not be possible, desirable or feasible to establish a 275 direct PW control channel between the T-PEs, residing in 276 different provider networks, to setup and maintain PWs. At a 277 minimum, a direct PW control channel establishment (e.g., 278 targeted LDP session) requires knowledge of and reachability 279 to the remote T-PE IP address. The local T-PE may not have 280 access to this information due to operational or security 281 constraints. Moreover, a SS-PW would require the existence 282 of a PSN tunnel between the local T-PE and the remote T-PE. 283 It may not be feasible or desirable to extend single, 284 contiguous PSN tunnels between T-PEs in one domain and T-PEs 285 in another domain for security and/or scalability reasons or 286 because the two domains may be using different PSN 287 technologies. 289 -iii. MS-PW setup, maintenance and forwarding procedures must 290 satisfy requirements placed by the constraints of a multi- 291 provider environment. An example is the inter-AS L2VPN 292 scenario where the T-PEs reside in different provider 293 networks (ASs) and it is the current practice to MD5-key all 294 control traffic exchanged between two networks. A MS-PW 295 allows the providers to confine MD5 key administration for 296 the LDP session to just the PW switching points connecting 297 the two domains. 299 -iv. PSN Interworking: PWE3 signaling protocols and PSN types may 300 differ in different provider networks. The terminating PEs 301 may be connected to networks employing different PW 302 signaling and /or PSN protocols. In this case it is not 303 possible to use a SS-PW. A MS-PW with the appropriate 304 interworking performed at the PW switching points can enable 305 PW connectivity between the terminating PEs in this 306 scenario. 308 -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: 309 There is a requirement to deploy PWs edge to edge in large 310 service provider networks. Such networks typically encompass 311 hundreds or thousands of aggregation devices at the edge, 312 each of which would be a PE. Furthermore, there is a 313 requirement that these PWs have explicit bandwidth 314 guarantees. To satisfy these requirements, the PWs will be 315 tunneled over PSN TE-tunnels with bandwidth constraints. A 316 single segment pseudowire architecture would require that a 317 full mesh of PSN TE-tunnels be provisioned to allow PWs to 318 be established between all PEs. Inter-provider PWs riding 319 traffic engineered tunnels further add to the number of 320 tunnels that would have to be supported by the PEs and the 321 core network as the total number of PEs increases. 323 In this environment, there is a requirement either to 324 support a sparse mesh of PSN TE-tunnels and PW signaling 325 adjacencies, or to partition the network into a number of 326 smaller PWE3 domains. In either case, a PW would have to 327 pass through more than one PSN tunnel hop along its path. An 328 objective is to reduce the number of tunnels that must be 329 supported, and thus the complexity and scalability problem 330 that may arise. 332 -vi. Pseudowires in access/metro metworks: Service providers wish 333 to extend PW technology to access and metro networks in 334 order to reduce maintenance complexity and operational 335 costs. Today's access and metro networks are either legacy 336 (TDM, SONET/SDH, or Frame Relay/ATM), Ethernet or IP based. 338 Due to these architectures, circuits (e.g., Ethernet VCs, 339 ATM VCs, TDM circuits) in the access/metro are traditionally 340 handled as attachment circuits, in their native format, to 341 the edge of the IP-MPLS network where the PW starts. This 342 combination requires multiple separate access networks and 343 complicates end-to-end control, provisioning, and 344 maintenance. In addition, when a TDM or SONET/SDH access 345 network is replaced with a packet-based infrastructure, 346 expenses may be lowered due to moving statistical 347 multiplexing closer to the end-user and converging multiple 348 services onto a single access network. 350 Access networks have a number of properties that impact the 351 application of PWs. For example, there exist access 352 mechanisms where the PSN is not of an IETF specified type, 353 but uses mechanisms compatible with those of PWE3 at the PW 354 layer. Here, use case (iv) may apply. In addition, many 355 networks consist of hundreds or thousands of access devices. 356 There is therefore a desire to support a sparse mesh of PW 357 signaling adjacencies and PSN tunnels. Use case (v) may 358 therefore apply. Finally, Access networks also tend to 359 differ from core networks in that the access PW setup and 360 maintenance mechanism may only be a subset of that used in 361 the core. 363 Using the MS-PWs, access and metro network elements need 364 only maintain PW signaling adjacencies with the PEs to which 365 they directly connect. They do not need PW signaling 366 adjacencies with every other access and metro network 367 device. PEs in the PSN backbone in turn maintain PW 368 signaling adjacencies among each other. In addition, a PSN 369 tunnel is setup between an access element and the PE to 370 which it connects. Another PSN tunnel needs to be 371 established between every PE pair in the PSN backbone. A 372 MS-PW may be setup from one access network element to 373 another another access element with three segments: (1) 374 access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN- 375 PE to access element. In this MS-PW setup, access elements 376 are T-PEs while PSN-PEs are S-PEs. It should be noted that 377 the PSN backbone can be also segmented into PWE3 domains 378 resulting in more segments per PW. 380 5.1. Multi-Segment Pseudowire Placement Mechanisms 382 This requirements document assumes that the above use cases are 383 realized using one or more of the following mechanisms: 385 -i. Static Configuration: The switching points (S-PEs), in 386 addition to the T-PEs, are manually provisioned for each 387 segment. 389 -ii. Pre-determined Route: The PW is established along an 390 administratively determined route using an end-to-end 391 signaling protocol with automated stitching at the S-PEs. 393 -iii. Signaled Dynamic Route: The PW is established along a 394 dynamically determined route using an end-to-end signaling 395 protocol with automated stitching at the S-PEs. The route is 396 selected with the aid of one or more dynamic routing 397 protocols. 399 Note that we define the PW route to be the set of S-PEs through which 400 a MS-PW will pass between a given pair of T-PEs. PSN tunnels along 401 that route can be explicitly specified or locally selected at the S- 402 PEs and T-PEs. The routing of the PSN tunnels themselves is outside 403 the scope of the requirements specified in this document. 405 6. Multi-Segment Pseudowire Requirements 407 The following sections detail the requirements that the above use 408 cases put on the MS-PW setup mechanisms. 410 6.1. All Mechanisms 412 The following generic requirements apply to the three MS-PW setup 413 mechanisms defined in the previous section. 415 6.1.1. Architecture 417 -i. If MS-PWs are tunneled, across a PSN that only supports SS- 418 PWs, then only the requirements of [RFC3916] apply to that 419 PSN. The fact that the overlay is carrying MS-PWs MUST be 420 transparent to the routers in the PSN. 422 -ii. The PWs MUST remain transparent to the P-routers. A P-router 423 is not an S-PE or an T-PE from the MS-PW architecture 424 viewpoint. P-routers provide transparent PSN transport for 425 PWs and MUST not have any knowledge of the PWs traversing 426 them. 428 -iii. The MS-PWs MUST use the same encapsulation modes specified 429 for SS-PWs. 431 -iv. The MS-PWs MUST be composed of SS-PWs. 433 -v. A MS-PW MUST be able to pass across PSNs of all technologies 434 specified by PWE3 for SS-PWs. When crossing from one PSN 435 technology to another, an S-PE must provide the necessary 436 PSN interworking functions in that case. 438 -vi. Both directions of a PW segment MUST terminate on the same 439 S-PE/T-PE. 441 -vii. S-PEs MAY only support switching PWs of the same PW type. In 442 this case, the PW type is transparent to the S-PE in the 443 forwarding plane, except for functions needed to provide for 444 interworking between different PSN technologies. 446 -viii. Solutions MAY provide a way to prioritize the setup and 447 maintenance process among PWs. 449 6.1.2. Resiliency 451 Mechanisms to protect a MS-PW when an element on the existing path of 452 a MS-PW fails MUST be provided. These mechanisms will depend on the 453 MS-PW setup. Following are the generic resiliency requirements that 454 apply to all MS-PW setup mechanisms: 456 -i. Configuration and establishment of a backup PW to a primary 457 PW SHOULD be supported. Mechanisms to perform a switchover 458 from a primary PW to a backup PW upon failure detection 459 SHOULD be provided. 461 -ii. The ability to configure an end-to-end backup PW path for a 462 primary PW path SHOULD be supported. The primary and backup 463 paths may be statically configured, statically specified for 464 signaling or dynamically selected via dynamic routing 465 depending on the MS-PW establishment mechanism. Backup and 466 primary paths should have the ability to traverse separate 467 S-PEs. The backup path MAY be signaled at configuration time 468 or after failure. 470 -iii. The ability to configure a primary PW and a backup PW with a 471 different T-PE from the primary SHOULD be supported. 473 -iv. Automatic Mechanisms to perform a fast switchover from a 474 primary PW to a backup PW upon failure detection SHOULD be 475 provided. 477 -v. A mechanism to automatically revert to a primary PW from a 478 backup PW MAY be provided. When provided, it MUST be 479 configurable. 481 6.1.3. Quality Of Service 483 Pseudowires are intended to support emulated services (e.g., TDM and 484 ATM) which may have strict per-connection quality of service 485 requirements. This may include either absolute or relative guarantees 486 on packet loss, delay, and jitter. These guarantees are in part 487 delivered by reserving sufficient network resources (e.g. bandwidth), 488 and by providing appropriate per-packet treatment (e.g. scheduling 489 priority and drop precedence) throughout the network. 491 For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be 492 used to ensure that sufficient resources are reserved in the P- 493 routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST 494 have the ability to automatically manage PSN tunnel resources in the 495 traffic direction (e.g. admission control of PWs onto the PSN tunnel 496 and accounting for reserved bandwidth and available bandwidth on the 497 tunnel). In cases where the tunnel supports multiple classes of 498 service (CoS) (e.g., E-LSP), bandwidth management is required per 499 CoS. 501 For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions 502 Must enable S-PEs and T-PEs to automatically bind a PW segment to a 503 PSN-tunnel based on CoS and bandwidth requirements when these 504 attributes are specified for a PW. Solutions SHOULD also provide the 505 capability of binding a PW segment to a tunnel as a matter of policy 506 configuration. S-PEs and T-PEs must be capable of automatically 507 managing PSN-tunnel resources per CoS. 509 S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP 510 field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs 511 affects packet treatment. The CoS marking depends on the PSN 512 technology. Thus, solutions must enable the configuration of 513 necessary mapping for CoS marking when the MS-PW crosses from one PSN 514 technology to another. Similarly, different administrative domains 515 may use different CoS values to imply the same CoS treatment. 516 Solutions MUST provide the ability to define CoS marking maps on S- 517 PEs at administrative domain boundaries to translate from one CoS 518 value to another as a a PW PDU crosses from one domain to the next. 520 Solutions MUST enable S-PEs and T-PEs on the path of a MS-PW to 521 notify other S-PEs and T-PEs on that path of congestion when it 522 occurs. Congestion may be indicated by queue length, packet loss 523 rate, or bandwidth measurement (among others) crossing a respective 524 threshold. The action taken by a T-PE that receives a notification of 525 congestion along the path of one of its PWs could be to reroute the 526 MS-PW to an alternative path, including an alternative T-PE if 527 available. Some PW types, such as TDM PWs, are more sensitive to 528 congestion than others. The reaction to a congestion notification MAY 529 vary per PW type. 531 6.2. Generic Requirements for MS-PW Setup Mechanisms 533 The MS-PW setup mechanisms MUST accommodate Service Provider's 534 practices, especially in relation to security, confidentiality and 535 traffic engineering. Security and confidentiality are especially 536 important when the MS-PWs are setup across Autonomous Systems in 537 different administrative domains. Following are generic requirements 538 that apply to the three MS-PW setup mechanisms defined earlier: 540 -i. The ability to statically select S-PEs and PSN tunnels on a 541 PW path MUST be provided. Static selection of S-PEs is by 542 definition a requirement for the static configuration and 543 signaled/static route setup mechanisms. This requirement 544 satisfies the need for forcing a MS-PW to traverse specific 545 S-PEs to enforce service provider security and 546 administrative policies. 548 -ii. Solutions SHOULD minimize the amount of configuration needed 549 to setup a MS-PW. 551 -iii. Solutions should support different PW setup mechanisms on 552 the same T-PE, S-PE and PSN network. 554 -iv. Solutions MUST allow T-PEs to simultaneously support use of 555 SS-PW signaling mechanisms as specified in [RFC4447] as well 556 as MS-PW signaling mechanisms. 558 -v. Solutions MUST ensure that a MS-PW will be setup when a path 559 that satisfies the PW constraints for bandwidth, CoS and 560 other possible attributes does exist in the network. 562 -vi. Solutions must clearly define the setup procedures for each 563 mechanism so that a MS-PW setup on T-PEs can be interpreted 564 as successful only when all PW segments are successfully 565 setup. 567 -vii. Admission control to the PSN tunnel needs to be performed 568 against available resources, when applicable. This process 569 MUST be performed at each PW segment comprising the MS-PW. 570 PW admission control into a PSN tunnel MUST be configurable. 572 -viii. In case the PSN tunnel lacks the resources necessary to 573 accommodate the new PW, an attempt to signal a new PSN 574 tunnel, or increase the capacity of the existing PSN tunnel 575 MAY be made. If the expanded PSN tunnel fails to setup the 576 PW MUST fail to setup. 578 -ix. The setup mechanisms must allow the setup of a PW segment 579 between two directly connected S-PEs without the existence 580 of a PSN tunnel. This requirement allows a PW segment to be 581 setup between two (Autonomous System Border Routers (ASBRs) 582 when the MS-PW crosses AS boundaries without the need for 583 configuring and setting up a PSN tunnel. In this case, 584 admission control must be done, when enabled, on the link 585 between the S-PEs. 587 6.2.1. Routing 589 An objective of MS-PWs is to provide support for the following 590 connectivity: 592 -i. MS-PWs MUST be able to traverse multiple Service Provider 593 administrative domains. 595 -ii. MS-PWs MUST be able to traverse multiple Autonomous Systems 596 within the same administrative domain. 598 -iii. MS-PWs MUST be able to traverse multiple Autonomous Systems 599 belonging to different administrative domains. 601 -iv. MS-PWs MUST be able to support any hybrid combination of the 602 aforementioned connectivity scenarios, including both PW 603 transit, and termination in a domain. 605 6.3. Statically configured MS-PWs 607 When the MS-PW segments are statically configured the following 608 requirements apply in addition to the generic requirements previously 609 defined. 611 6.3.1. Architecture 613 There are no additional requirements on the architecture. 615 6.3.2. MPLS-PWs 617 Solutions should allow for the static configuration of MPLS labels 618 for MPLS-PW segments and the cross-connection of these labels to 619 preceding and succeeding segments. This is especially useful when a 620 MS-PW crosses provider boundaries and two providers do not want to 621 run any PW signaling protocol between them. A T-PE or S-PE that 622 allows the configuration of static labels for MS-PW segments should 623 also simultaneously allow for dynamic label assignments for other 624 MS-PW segments. It should be noted that when two interconnected S-PEs 625 do not have signaling peering for the purpose of setting up MS-PW 626 segments, they should have in-band PW OAM capabilities that relay PW 627 or attachment circuit defect notifications between the adjacent S- 628 PEs. 630 6.3.3. Resiliency 632 The solution should allow for the protection of a PW-segment, a 633 contiguous set of PW-segments, as well as the end-end path. The 634 primary and protection segments paths must share the same segments 635 endpoints. Solutions should allow for having the backup paths setup 636 prior to the failure or as a result of failure. The choice should be 637 made by configuration. When resources are limited and cannot satisfy 638 all PWs, the PWs with the higher setup priorities should be given 639 preference when compared with the setup priorities of other PWs being 640 setup or the holding priorities of existing PWs. 642 Solutions should strive to minimize traffic loss between T-PEs. 644 6.3.4. Quality of service 646 The CoS and bandwidth of the MS-PW must be configurable at T-PEs and 647 S-PEs. 649 6.4. Signaled PW-segments 651 When the MS-PW segments are dynamically signaled the following 652 requirements apply in addition to the generic requirements previously 653 defined. 655 These signaled MS-PW segments can be on the path of a statically 656 configured MS-PW, signaled/statically routed MS-PW or 657 signaled/dynamically routed MS-PW. 659 There are four different SS-PW signaling protocols that are defined 660 to signal PWs: 662 -i. Static setup of the SS-PW (MPLS or L2TPv3 forwarding). 664 -ii. LDP using PWid FEC 128 666 -iii. LDP using the generalized PW FEC 129 668 -iv. L2TPv3 670 The MS-PW setup mechanism MUST be able to support PW segments 671 signaled with any of the above protocols, however the specification 672 of which combinations of SS-PW signaling protocols is supported by a 673 specific implementation is outside the scope of this document. 675 For the signaled/statically routed and signaled/dynamically routed 676 MS-PW setup mechanisms the following requirements apply in addition 677 to the generic requirements previously defined. 679 6.4.1. Architecture 681 There are no additional requirements on the architecture. 683 6.4.2. Resiliency 685 Solutions should allow for the signaling of a protection path for a 686 PW segment, sequence of segments or end-to-end path. The protection 687 and primary paths for the protected segment(s) share the same 688 respective segments endpoints. When admission control is enabled, 689 systems must be careful not to double account for bandwidth 690 allocation at merged points (e.g., tunnels). Solutions should allow 691 for having the backup paths setup prior to the failure or as a result 692 of failure. The choice should be made by configuration at the 693 endpoints of the protected path. When resources are limited and 694 cannot satisfy all PWs, the PWs with the higher setup priorities 695 should be given preference when compared with the setup priorities of 696 other PWs being setup or the holding priorities of existing PWs. 697 Procedures must allow for the primary and backup paths to be 698 diversified 700 6.4.3. Quality of Service 702 When the T-PE attempts to signal a MS-PW the following capability is 703 required: 705 -i. Signaling must be able to identify the CoS associated with a 706 MS-PW 707 -ii. Signaling must be able to carry the traffic parameters for a 708 MS-PW per CoS. Traffic parameters should be based on 709 existing INTSERV definitions and must be used for admission 710 control when admission control is enabled. 712 -iii. The PW signaling MUST enable separate traffic parameter 713 values to be specified for the forward and reverse 714 directions of the PW. 716 -iv. PW traffic parameter representations MUST be the same for 717 all types of MS-PWs. 719 -v. The signaling protocol must be able to accommodate a method 720 to prioritize the PW setup and maintenance process among 721 PWs. 723 6.4.4. Routing 725 See the requirements for "Resiliency" above. 727 Following are further requirements on signaled MS-PW setup 728 mechanisms: 730 -i. The signaling procedures MUST be defined such that the setup 731 of a MS-PW is considered successful if all segments of the 732 MS-PW are successfully setup. 734 -ii. The MS-PW path MUST have the ability to be dynamically setup 735 between the T-PEs by provisioning only the T-PEs. 737 -iii. Dynamic MS-PW setup requires that a unique identifier be 738 associated with a PW and be carried in the signaling 739 message. That identifier must contain sufficient information 740 to determine the path to the remote T-PE through 741 intermediate S-PEs. 743 -iv. In a single-provider domain it is natural to have the T-PE 744 identified by one of its IP addresses. This may also apply 745 when a MS-PW is setup across multiple domains operated by 746 the same provider. However, some service providers have 747 security and confidentiality policies that prevent them from 748 advertising reachability to routers in their networks to 749 other providers (reachability to an ASBR is an exception). 750 Thus, procedures MUST be provided to allow dynamic setup of 751 MS-PWs under these conditions. 753 6.5. Signaled PW / Dynamic Route 755 The following requirements apply, in addition to those in Section 6.1 756 and Section 6.2, when both dynamic signaling and dynamic routing are 757 used. 759 6.5.1. Architecture 761 There are no additional architectural requirements. 763 6.5.2. Resiliency 765 The PW Routing function MUST support dynamic re-routing around 766 failure points when segments are setup using the dynamic setup 767 method. 769 6.5.3. Quality of Service 771 There are no additional QoS requirements. 773 6.5.4. Routing 775 Following are requirements associated with dynamic route selection 776 for a MS-PW: 778 -i. Routing must enable S-PEs and T-PEs to discover S-PEs on the 779 path to a destination T-PE. 781 -ii. The MS-PW routing function MUST have the ability to 782 automatically select the S-PEs along the MS-PW path. Some of 783 the S-PEs MAY be statically selected and carried in the 784 signaling to constrain the route selection process. 786 -iii. The PW Routing function MUST support re-routing around 787 failures that occur between the statically configured 788 segment endpoints. This may be done by choosing another PSN 789 tunnel between the two segment endpoints or setting up an 790 alternative tunnel. 792 -iv. Routing protocols must be able to advertise reachability 793 information to attachment circuit (AC) endpoints. This 794 reachability information must be consistent with the AC 795 identifiers carried in signaling. 797 7. Operations and Maintenance (OAM) 799 OAM mechanisms for the attachment circuits are defined in the 800 specifications for PW emulated specific technologies (e.g., ITU-T 801 I.610 for ATM). These mechanisms enable, among other things, defects 802 in the network to be detected, localized and diagnosed. They also 803 enable communication of PW defect states on the PW attachment 804 circuit. 806 The interworking of OAM mechanisms for SS-PWs between ACs and PWs is 807 defined in [PWE3-OAM]. These enable defect states to be propagated 808 across a PWE3 network following the failure and recovery from faults. 810 OAM mechanisms for MS-PWs MUST provide at least the same capabilities 811 as those for SS-PWs. 813 In addition, it should be possible to support both segment and end- 814 to-end OAM mechanisms for both defect notifications and connectivity 815 verification in order to allow defects to be localized in a multi- 816 segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE 817 to S-PE, or S-PE to S-PE. 819 The following requirements apply to OAM for MS-PWs: 821 -i. Mechanisms for PW segment failure detection and notification 822 to other segments of a MS-PW MUST be provided. 824 -ii. MS-PW OAM SHOULD be supported end-to-end across the network. 826 -iii. Single ended monitoring SHOULD be supported for both 827 directions of the MS-PW. 829 -iv. MS-PW OAM SHOULD support switch over between 1:1 protected 830 LSPs end-to-end. 832 -v. SS-PW OAM mechanisms (e.g., [VCCV]) SHOULD be extended to 833 support MS-PWs on both end-end basis and segment basis. 835 -vi. All PE routers along the MS-PW MUST agree on a common PW OAM 836 mechanism to use for the MS-PW. 838 -vii. At the S-PE, defects on an PSN tunnel MUST be propagated to 839 all PWs that utilize that particular PSN tunnel. 841 -viii. The directionality of defect notifications MUST be 842 maintained across the S-PE. 844 -ix. The S-PE SHOULD be able to behave as a segment endpoint for 845 PW OAM mechanisms. 847 -x. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages 848 transparently. 850 -xi. Performance OAM, is required for both MS-PWs and SS-PWs to 851 measure round-trip delay, one-way delay, jitter, and packet 852 loss ratio. 854 8. Security Considerations 856 This document specifies the requirements for MS-PWs that can be setup 857 across domain boundaries administered by one ore more service 858 providers. The security requirements for MS-PW setup across domains 859 administered by one service provider are the same as those described 860 under security considerations in [RFC4447]. These requirements also 861 apply to interprovider MS-PWs. In addition, [RFC4111] identifies user 862 and provider requirements for L2 VPNs that apply to MS-PWs described 863 in this document. In this section, the focus is on the additional 864 security requirements for interprovider operation of MS-PWs in both 865 the control plane and data plane,and some of these requirements may 866 overlap with those in [RFC4111]. 868 8.1. Data-plane Security Requirements 870 MS-PWs that cross SP domain boundaries may connect one T-PE in a SP 871 domain to a T-PE in another SP-domain. They may also transit other SP 872 domains even if the two T-PEs are under the control of one SP. Under 873 these scenarios, there is a chance that one or more PDUs could be 874 falsely inserted into a MS-PW at any of the originating, terminating 875 or transit domains. Such false injection can be the result of a 876 malicious attack or fault in the MS-PW cross-connects. Solutions MAY 877 provide mechanisms for ensuring the end-to-end authenticity of MS-PW 878 PDUs. 880 One of the crossed domains may decide to selectively mirror the PDUs 881 of a MS-PW for eavesdropping purposes. It may also decide to 882 selectively hijack the PDUs of a MS-PW by directing the PDUs away 883 from their destination. In either case, the privacy of a MS-PDU can 884 be violated. This document does not place any requirements on 885 protecting the privacy of a MS-PW PDU via encryption for instance. 886 Encryption may be performed at a higher layer in the protocol stack, 887 based on the application or network requirements. 889 The data plane of an S-PE at a domain boundary MUST be able to police 890 an incoming MS-PW traffic to the MS-PW traffic parameters or to an 891 administratively configured profile. The option to enable/disable 892 policing MUST be provided to the network administrator. This is to 893 ensure that a MS-PW or a group of MS-PWs do not grab more resources 894 than they are allocated. In addition, the data plane of an S-PE MUST 895 be able to police OAM messages to a pre-configured traffic profile or 896 to filter out these messages upon administrative configuration. 898 An ingress S-PE MUST ensure that a MS-PW receive the CoS treatment 899 configured or signaled for that MS-PW at the S-PE. Specifically, an 900 S-PE MUST guard against packets marked in the exp bits or IP-header 901 DS field (depending on the PSN) for a better CoS than they should 902 receive. 904 An ingress S-PE MUST be able to define per-interface or interface- 905 group (a group may correspond to interfaces to a peer-provider) label 906 space for MPLS-PWs. An S-PE MUST be configurable not to accept 907 labeled packets from another provider unless the bottom label is a 908 PW-label assigned by the S-PE on the interface on which the packet 909 arrived. 911 8.2. Control-plane Security Requirements 913 A MS-PW connects two attachment circuits. It is important to make 914 sure that PW connections are not arbitrarily accepted from anywhere, 915 or else a local attachment circuit might get connected to an 916 arbitrary remote attachment circuit. The fault in the connection can 917 start at a remote T-PE or an S-PE. 919 An incoming MS-PW request/reply MUST NOT be accepted unless its IP 920 source address is known to be the source of an "eligible" peer. If a 921 peering adjacency has to be established prior to exchanging setup 922 requests/responses, peering MUST only be done with eligible peers. 923 The set of eligible peers could be pre-configured (either as a list 924 of IP addresses, or as a list of address/mask combinations). 925 Furthermore, the restriction of peering sessions to specific 926 interfaces SHOULD also be provided. The S-PE and T-PE SHOULD drop the 927 unaccepted signaling messages in the data path to avoid a DoS attack 928 on the control plane. 930 Even if a connection request appears to come from an eligible peer, 931 its source address may have been spoofed. So some means of preventing 932 source address spoofing must be in place. For example, if eligible 933 peers are in the same network, source address filtering at the border 934 routers of that network could eliminate the possibility of source 935 address spoofing. 937 For a greater degree of security, an authentication mechanism that is 938 suitable to the associated protocol MUST be available. Furthermore 939 authentication using a signature for each individual MS-PW setup 940 messages MUST be available, in addition to an overall control 941 protocol session authentication , and message validation. 943 Peer authentication protects against IP address spoofing but does not 944 prevent one peer (S-PE or T-PE) from connecting to the wrong 945 attachment circuit. Under a single administrative authority, this may 946 be the result of a misconfiguration. When the MS-PW crosses multiple 947 provider domains, this may be the result of a malicious act by a 948 service provider or a security hole in that provider network. Static 949 manual configuration of MS-PWs at S-PEs and T-PEs provide a greater 950 degree of security. If an identification of both ends of a MS-PW is 951 configured and carried in the signaling message, an S-PE can verify 952 the signaling message against the configuration. To support dynamic 953 signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs 954 are dynamically discovered, mechanisms SHOULD be provided to 955 configure such information on a server and to use that information 956 during a connection attempt for validation. 958 S-PEs that connect one provider domain to another provider domain 959 MUST have the capability to rate-limit signaling traffic in order to 960 prevent DoS attacks on the control plane. Furthermore, detection and 961 disposition of malformed packets and defense against various forms of 962 attacks that can be protocol-specific MUST be provided. 964 9. Full Copyright Statement 966 Copyright (C) The Internet Society (2007). 968 This document is subject to the rights, licenses and restrictions 969 contained in BCP 78, and except as set forth therein, the authors 970 retain all their rights. 972 This document and the information contained herein are provided on an 973 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 974 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 975 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 976 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 977 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 978 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 980 10. Intellectual Property Statement 982 The IETF takes no position regarding the validity or scope of any 983 Intellectual Property Rights or other rights that might be claimed to 984 pertain to the implementation or use of the technology described in 985 this document or the extent to which any license under such rights 986 might or might not be available; nor does it represent that it has 987 made any independent effort to identify any such rights. Information 988 on the procedures with respect to rights in RFC documents can be 989 found in BCP 78 and BCP 79. 991 Copies of IPR disclosures made to the IETF Secretariat and any 992 assurances of licenses to be made available, or the result of an 993 attempt made to obtain a general license or permission for the use of 994 such proprietary rights by implementers or users of this 995 specification can be obtained from the IETF on-line IPR repository at 996 http://www.ietf.org/ipr. 998 The IETF invites any interested party to bring to its attention any 999 copyrights, patents or patent applications, or other proprietary 1000 rights that may cover technology that may be required to implement 1001 this standard. Please address the information to the IETF at ietf- 1002 ipr@ietf.org. 1004 11. IANA Considerations 1006 This document has no IANA Actions. 1008 12. Normative References 1010 [RFC3916] "Requirements for Pseudo-Wire Emulation Edge-to-Edge 1011 (PWE3)", X. Xiao, D. McPherson, P. Pate, September 2004 1013 [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. 1015 13. Informative References 1017 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1018 Verification (VCCV)", Internet Draft 1019 , October 2006. (work in progress) 1021 [RFC4447] L. Martini, Ed, et al., "Pseudowire Setup and 1022 Maintenance Using the Label Distribution Protocol (LDP)", 1023 RFC4447, April 2006 1025 [RFC4111] "Security Framework for 1026 Provider-Provisioned Virtual Private Networks (PPVPNs)," 1027 Fang. L., et al., RFC 4111, July 2005 1029 [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., 1030 draft-ietf-pwe3-oam-msg-map-02.txt (work in progress), 1031 February 2005 1033 14. Author Information 1035 Nabil Bitar 1036 Verizon 1037 40 Sylvan Road 1038 Waltham, MA 02145 1039 e-mail: nabil.bitar@verizon.com 1040 Matthew Bocci 1041 Alcatel Telecom Ltd, 1042 Voyager Place 1043 Shoppenhangers Road 1044 Maidenhead 1045 Berks, UK 1046 e-mail: matthew.bocci@alcatel.co.uk 1048 Luca Martini 1049 Cisco Systems, Inc. 1050 9155 East Nichols Avenue, Suite 400 1051 Englewood, CO, 80112 1052 e-mail: lmartini@cisco.com