idnits 2.17.1 draft-ietf-pwe3-ms-pw-requirements-00.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 3667, Section 5.1 on line 787. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** Found boilerplate matching RFC 3978, Section 5.1 (on line 20), which is fine, but *also* found old RFC 3667, Section 5.1 text on line 787. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 168: '...g., PW1 and PW3) MAY be of the same PW...' RFC 2119 keyword, line 201: '...PW by definition MUST terminate on a U...' RFC 2119 keyword, line 339: '... -i. S-PEs MAY only support swit...' RFC 2119 keyword, line 347: '... carrying MS-PWs MUST be transparent t...' RFC 2119 keyword, line 350: '... -iii. The PWs MUST remain transpare...' (71 more instances...) 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: -iii. The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or an U-PE from the MS-PW architecture viewpoint. P-routers provide transparent PSN transport for PWs and MUST not have any knowledge of PW 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 (June 2005) is 6861 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) == Missing Reference: 'PWE3-REQ' is mentioned on line 346, but not defined == Unused Reference: 'ITUQ' is defined on line 803, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 (ref. 'PWE3-ARCH') == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-02 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini (Editor) 3 Internet Draft Cisco Systems Inc. 4 Expiration Date: December 2005 6 Matthew Bocci (Editor) Nabil Bitar (Editor) 7 Alcatel Verizon 9 June 2005 11 Requirements for inter domain Pseudo-Wires 13 draft-ietf-pwe3-ms-pw-requirements-00.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 pseudo-wires 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 pseudo-wire 45 domains. 47 Table of Contents 49 1 Specification of Requirements ........................ 2 50 2 Acknowledgments ...................................... 3 51 3 Introduction ......................................... 3 52 3.1 Scope ................................................ 3 53 3.2 Architecture ......................................... 3 54 4 Terminology .......................................... 6 55 5 Use Cases ............................................ 6 56 6 Multi-Segment Pseudo-Wire Requirements ............... 9 57 6.1 Architecture ......................................... 9 58 6.2 Resiliency ........................................... 10 59 6.3 Quality of Service and Class of Service .............. 11 60 6.3.1 Traffic Engineering .................................. 12 61 6.4 MS-PW Setup Mechanisms. .............................. 12 62 6.4.1 Routing .............................................. 14 63 7 Operations and Maintenance (OAM) ..................... 14 64 8 Security Considerations .............................. 16 65 8.1 Data-plane Security Requirements ..................... 16 66 8.2 Control-plane Security Requirements .................. 17 67 9 Full Copyright Statement ............................. 18 68 10 Intellectual Property Statement ...................... 18 69 11 IANA Considerations .................................. 19 70 12 Normative References ................................. 19 71 13 Informative References ............................... 19 72 14 Author Information ................................... 19 74 1. Specification of Requirements 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 80 2. Acknowledgments 82 The editors gratefully acknowledge the following contributors: 83 Dimitri Papadimitriou (Alcatel), Peter Busschbach (Lucent), Sasha 84 Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord 85 (France Telecom), Deborah Brungard (AT&T), Rahul Aggawal (Juniper), 86 Du Ke (ZTE), Cagatay Buyukkoc (ZTE). 88 3. Introduction 90 3.1. Scope 92 This document specifies requirements for extending pseudo-wires 93 across more than one packet switched network (PSN) domain and more 94 than one PSN tunnel. These pseudo-wires are called multi-segment 95 pseudo-wires (MS-PW). Requirements for single-segment pseudo wires 96 (SS-PW) that extend edge to edge across only one PSN domain are 97 specified in [PWE3-REQ]. 99 This document specifies additional requirements that apply to MS-PWs. 100 These requirements do not apply to PSNs that only support SS-PWs. 102 3.2. Architecture 104 The following three figures describe the reference models which are 105 derived from [PWE3-ARCH] to support PW emulated services. 107 |<-------------- Emulated Service ---------------->| 108 | | 109 | |<------- Pseudo Wire ------>| | 110 | | | | 111 | | |<-- PSN Tunnel -->| | | 112 | PW End V V V V PW End | 113 V Service +----+ +----+ Service V 114 +-----+ | | PE1|==================| PE2| | +-----+ 115 | |----------|............PW1.............|----------| | 116 | CE1 | | | | | | | | CE2 | 117 | |----------|............PW2.............|----------| | 118 +-----+ ^ | | |==================| | | ^ +-----+ 119 ^ | +----+ +----+ | | ^ 120 | | Provider Edge 1 Provider Edge 2 | | 121 | | | | 122 Customer | | Customer 123 Edge 1 | | Edge 2 124 | | 125 | | 126 Attachment Circuit (AC) Attachment Circuit (AC) 127 Native service Native service 129 Figure 1: PWE3 Reference Configuration 131 Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This 132 architecture applies to the case where a PSN tunnel extends between 133 two edges of a single PSN domain to transport a PW with endpoints at 134 these edges. 136 Native |<-----------Pseudo Wire----------->| Native 137 Service | | Service 138 (AC) | |<-PSN1-->| |<--PSN2->| | (AC) 139 | V V V V V V | 140 | +----+ +-----+ +----+ | 141 +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ 142 | |----------|........PW1.........|...PW3........|----------| | 143 | CE1| | | | | | | | | |CE2 | 144 | |----------|........PW2.........|...PW4........|----------| | 145 +----+ | | |=========| |=========| | | +----+ 146 ^ +----+ +-----+ +----+ | ^ 147 | Provider Edge 1 ^ Provider Edge 3 | 148 | | | 149 | | | 150 | PW switching point | 151 | | 152 | | 153 |<------------------- Emulated Service ------------------>| 155 Figure 2: PW switching Reference Model 157 Figure 2 extends this architecture to show a multi-segment case. PE1 158 and PE3 provide PWE3 to CE1 and CE2. These PEs reside in different 159 PSNs. A PSN tunnel extends from PE1 to PE2 across PSN1, and a second 160 PSN tunnel extends from PE2 to PE3 across PSN2. PWs are used to 161 connect the Attachment circuits (ACs) attached to PE1 to the 162 corresponding ACs attached to PE3. Each PW on the tunnel across PSN1 163 is stitched to a PW in the tunnel across PSN2 at PE2 to complete the 164 multi-segment PW (MS-PW) between PE1 and PE3. PE2 is therefore the PW 165 switching point and will be referred to as the PW switching provider 166 edge (S-PE). PW1 and PW3 are segments of the same MS-PW while PW2 and 167 PW4 are segments of another pseudo-wire. PW segments of the same MS- 168 PW (e.g., PW1 and PW3) MAY be of the same PW type or different type, 169 and PSN tunnels (e.g., PSN1 and PSN2) can be the same or different 170 technology. This document requires support for MS-PWs with segments 171 of the same type. An S-PE switches an MS-PW from one segment to 172 another based on the PW identifiers (e.g., PW label in case of MPLS 173 PWs). 175 Note that although Figure 2 only shows a single S-PE, a PW may 176 transit more one S-PE along its path. For instance, in the multi- 177 provider case shown in Figure 3, there can be an S-PE at the border 178 of one provider domain and another S-PE at the border of the other 179 provider domain. A MS-PW that extends from the edge of one provider 180 (PE1) to the edge of the other provider (PE4) is composed of three 181 segments: (1) PW1, a segment in provider1 network, (2) PW2, a segment 182 between the two borderrouters that are S-PEs, and (3) PWE3, a segment 183 in the provider2 network. 185 4. Terminology 187 [PWE3-REQ] provides terminology for PWE3. This document defines the 188 following additional terms: 190 - Ultimate PE (U-PE). A PE where the customer-facing ACs 191 (attachment circuits) are bound to a PW forwarder. An ultimate PE 192 is present in the first and last segments of a MS-PW. 194 - Single-Segment PW (SS-PW). A PW setup directly between two U-PE 195 devices. Each LSP in one direction of a SS-PW traverses one PSN 196 tunnel that connects the two U-PEs. 198 - Multi-Segment PW (MS-PW). A static or dynamically configured set 199 of two or more contiguous PW segments 200 that behave and function as a single point-to-point PW. Each end 201 of a MS-PW by definition MUST terminate on a U-PE. 203 - PW Switching Provider Edge (S-PE). A PE capable of switching the 204 control and data planes of the preceding and succeeding PW 205 segments in a MS-PW. It is therefore a PW switching point for a 206 MS-PW. A PW Switching Point is never the S-PE and the U-PE for 207 the same MS-PW. A PW switching point runs necessary protocols to 208 setup and manage PW segments with other PW switching points and 209 ultimate PEs. 211 - PW Segment. A part of a single-segment or multi-segment PW, which 212 is set up between two PE devices, U-PEs and/or S-PEs. 214 5. Use Cases 216 PWE3 defines the signaling and encapsulation techniques for 217 establishing SS-PWs between a pair of ultimate PEs and in the vast 218 majority of cases this will be sufficient. MS-PWs may be useful in 219 the following situations: 221 -i. Inter-Provider PWs: An Inter-Provider PW is a PW that 222 extends from a U-PE in one provider domain to a U-PE in 223 another provider domain. 225 -ii. It may not be possible, desirable or feasible to establish a 226 direct PW control channel between the ultimate source and 227 destination PEs to setup and maintain PWs. At minimum, a 228 direct PW control channel establishment (e.g., targeted LDP 229 session) requires knowledge of and reachability to the 230 remote U-PE IP address. The local U-PE may not have access 231 to this information due to operational or security 232 constraints. Moreover, a SS-PW would require the existence 233 of a PSN tunnel between the local U-PE and the remote U-PE. 234 It may not be feasible or desirable to extend single, 235 contiguous PSN tunnels between U-PEs in one domain and U-PEs 236 in another domain for security and/or scalability reasons or 237 for the fact that the two domains may be using different PSN 238 technologies. 240 -iii. MS-PW setup, maintenance and forwarding procedures must 241 satisfy requirements placed by the constraints of a multi- 242 provider environment. An example is the inter-AS L2VPN 243 scenario where the ultimate PEs reside in different provider 244 networks (ASs) and it is the practice to MD5-key all control 245 traffic exchanged between two networks. An MS-PW allows the 246 providers to confine MD5 key administration to just the PW 247 switching points connecting the two domains. 249 -iv. PSN Internetworking: PWE3 signaling protocols and PSN types 250 may differ in different provider networks. The ultimate PEs 251 may be connected to networks employing different PW 252 signaling and /or PSN protocols. In this case it is not 253 possible to use a SS-PW. A MS-PW with the appropriate 254 interworking performed at the PW switching points can enable 255 PW connectivity between the ultimate PEs in this scenario. 257 -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: 258 There is a requirement to deploy PWs edge to edge in large 259 service provider networks. Such networks typically encompass 260 hundreds or thousands of aggregation devices at the edge, 261 each of which would be a PE. Furthermore, there is a 262 requirement That these PWs have explicit bandwidth 263 guarantees. To satisfy these requirements, the PWs will be 264 tunneled over PSN TE-tunnels with bandwidth constraints. A 265 single segment pseudo-wire architecture would require that a 266 full mesh of PSN TE-tunnels be provisioned to allow PWs to 267 be established between all PEs. Inter provider PWs riding 268 traffic engineered tunnels further add to the number of 269 tunnels that would have to be supported by the PEs and the 270 core network as the total number of PEs increases. 272 In this environment, there is a requirement either to 273 support a sparse mesh of PSN TE-tunnels and PW signaling 274 adjacencies, or to partition the network into a number of 275 smaller PWE3 domains. In either case, a PW would have to 276 pass through more than one PSN tunnel hop along its path. An 277 objective is to reduce the number of tunnels that must be 278 supported, and thus the complexity and scalability problem 279 that may arise. The following use case would benefit from 280 this solution. 282 -vi. Pseudo-Wires in Access and Metro Networks: Service providers 283 are looking to extend PWs to access and metro networks. The 284 prime motive is cost reduction in capital and operation 285 expenses. For instance, in metro networks, providers are 286 looking into extending PWs to next generation SONET ADMs 287 using MPLS mechanisms. The objective is to achieve 288 statistical multiplexing of packets closer to the edge of 289 the network, reducing the recurring costs of SONET circuits 290 or maximizing the utilization of existing SONET 291 infrastructure. In access and metro Ethernet networks, 292 providers are looking to take advantage of MPLS mechanisms 293 to setup point to point Ethernet virtual circuits with 294 endpoints in the same or different access/metro networks. 296 Using the MS-PW solution, access and metro network elements 297 need only maintain PW signaling adjacencies with the PEs to 298 which they directly connect. They do not need PW signaling 299 adjacencies with every other access and metro network 300 device. PEs in the PSN backbone in turn maintain PW 301 signaling adjacencies among each other. In addition, a PSN 302 tunnel is setup between an access element and the PE to 303 which it connects. Another PSN tunnel needs to be 304 established between every PE pair in the PSN backbone. A 305 MS-PW may be setup from one access network element to 306 another another access element with three segments: (1) 307 access-element - PSN PE, (2) PSN-PE to PSN-PE, and (3) PSN- 308 PE to access element. In this MS-PW setup, access elements 309 are U-PEs while PSN-PEs are S-PEs. It should be noted that 310 the PSN backbone can be also segmented into PWE3 domains 311 resulting in more segments per PW. 313 6. Multi-Segment Pseudo-Wire Requirements 315 |<--------------Pseudo Wire----------->| 316 | Provider Provider | 317 AC | |<----1---->| |<----2--->| | AC 318 | V V V V V V | 319 | +----+ +-----+ +----+ +----+ | 320 +----+ | | |=====| |=====| |=====| | | +----+ 321 | |-------|.....PW1..........PW2.........PW3.....|-------| | 322 | CE1| | | | | | | | | | | |CE2 | 323 +----+ | | |=====| |=====| |=====| | | +----+ 324 ^ +----+ +-----+ +----+ +----+ ^ 325 | PE1 PE2 PE3 PE4 | 326 | ^ ^ | 327 | | | | 328 | PW switching points | 329 | | 330 | | 331 |<------------------- Emulated Service --------------->| 333 Figure 3: PW switching inter provider Reference Model 335 6.1. Architecture 337 The following requirements apply to the architecture for MS-PWs: 339 -i. S-PEs MAY only support switching PWs of the same PW type. In 340 this case, the PW type is transparent to the S-PE in the 341 forwarding plane, except for functions needed to provide for 342 interworking between different PSN technologies. 344 -ii. If MS-PWs are tunneled, using a PSN tunnel overlay, across a 345 PSN that only supports SS-PWs, then only the requirements of 346 [PWE3-REQ] apply to that PSN. The fact that the overlay is 347 carrying MS-PWs MUST be transparent to the routers in the 348 PSN. 350 -iii. The PWs MUST remain transparent to the P-routers. A P-router 351 is not an S-PE or an U-PE from the MS-PW architecture 352 viewpoint. P-routers provide transparent PSN transport for 353 PWs and MUST not have any knowledge of PW traversing them. 355 -iv. The MS-PWs MUST use the same encapsulation modes specified 356 for SS-PWs. 358 -v. S-PEs MAY change the type or encapsulation mode of a PW in 359 the NSP function. This enables the establishment of a MS-PW 360 between two PEs with different attachment circuit 361 encapsulation but with the same PW type. 363 -vi. A MS-PW SHOULD be able to pass across PSNs of all 364 technologies specified by PWE3 for SS-PWs. When crossing 365 from one PSN technology to another, an S-PE must provide the 366 necessary PSN interworking functions in that case. 368 -vii. MS-PWs are composed of SS-PW, and SS-PW are bi-directional, 369 therefore both directions of a PW segment MUST terminate on 370 the same S-PE/U-PE. 372 6.2. Resiliency 374 Mechanisms to protect an MS-PW when the existing path of a MS-PW 375 fails (including S-PE failure or any segment failure) MUST be 376 provided. These mechanisms will depend on the methods of a MS-PW 377 setup. The following are the resiliency requirements: 379 -i. The ability to configure an end-end backup PW path for a 380 primary PW path MUST be supported. The backup and primary 381 paths should have the ability to traverse separate S-PEs. 382 The backup path MAY be signaled at configuration time or 383 after failure detection. 385 -ii. The ability to configure a backup PW for a primary PW. The 386 backup and primary PWs should have the ability to traverse 387 separate S-PEs. 389 -iii. When a MS-PW segment is tunneled over PSN tunnels with fast 390 reroute capability fast re-route events SHOULD be 391 transparent to the MS-PW. 393 -iv. Automatic Mechanisms to perform a fast switchover from a 394 primary PW to a backup PW upon failure detection SHOULD be 395 provided to minimize packet loss. 397 -v. Configuration Mechanisms to perform a switchover from a 398 primary PW to a backup PW upon failure detection SHOULD be 399 provided. 401 -vi. A mechanism to automatically revert to a primary PW from a 402 backup PW MAY be provided. When provided, it SHOULD be 403 enabled/disabled by configuration. 405 -vii. Mechanisms for PW segment failure detection and notification 406 to other segments of a MS-PW MUST be provided. 408 6.3. Quality of Service and Class of Service 410 Pseudo-wires are intended to support emulated services (e.g., TDM and 411 ATM) which may have strict per-connection quality of service 412 requirements. This may include either absolute or relative guarantees 413 on packet loss, delay, and jitter. These guarantees are in part 414 delivered by reserving sufficient network resources (e.g. BW), and by 415 providing appropriate per-packet treatment (e.g. scheduling priority 416 and drop precedence) throughout the network. 418 In SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be 419 used to ensure that sufficient resources are reserved in the P- 420 routers to provide QoS to PWs on the tunnel. In this case, the 421 ability to automatically manage the PSN tunnel resources (e.g. 422 admission control of PWs onto the PSN tunnel) is a requirement at 423 each PW segment. The ability to associate the appropriate QoS class 424 with each PW PDU is a strict requirement at each router transited in 425 the network. 427 For MS-PWs, each S-PE maps a PW to a PSN tunnel. That is, an S-PE 428 decides what PW to bind to which PSN tunnel. Control over binding a 429 PW to a specific PSN tunnel SHOULD be provided as a matter of policy 430 configuration. 432 When the U-PE attempts to signal a PW the following capability is 433 required: 435 -i. Admission control to the PSN tunnel needs to be performed 436 against available resources. PW admission control into a PSN 437 tunnel MUST be configurable. 439 -ii. A method to select per PW/QoS class setup/holding priority 440 should be provided. 442 -iii. In case the PSN tunnel lacks the resources necessary to 443 accommodate the new PW, a PW setup failure message MUST be 444 returned and the PW MUST fail to setup. Alternatively: In 445 case the PSN tunnel lacks the resources necessary to 446 accommodate the new PW, an attempt to signal an new PSN 447 tunnel, or increase the capacity of the existing PSN tunnel 448 MUST be made. If the expanded PSN tunnels fails to setup the 449 PW MUST fail to setup. 451 -iv. PW traffic parameter representations MUST be the same for 452 all types of PW. 454 -v. The PW signaling MUST enable separate traffic parameter 455 values to be specified for the forward and reverse 456 directions of the PW. 458 6.3.1. Traffic Engineering 460 The following requirements apply to the traffic engineering of MS- 461 PWs: 463 -i. When setting up a MS-PW, S-PEs and U-PEs MUST be able to 464 select a tunnel across the PSN in such a way as to satisfy 465 the MS-PW QoS and bandwidth requirements. Restrictions may 466 apply depending on the method used for setting up a PW 467 segment and on PSN tunnel types. 469 -ii. Upon setting up a MS-PW for which QoS/bandwidth commitments 470 are made over the PSN, S-PEs and U-PEs SHOULD be able to 471 perform admission control for each PW segment over a PSN 472 tunnel to ensure that PW bandwidth and QoS requirements can 473 be satisfied. 475 6.4. MS-PW Setup Mechanisms. 477 The MS-PW setup mechanisms MUST accommodate Service Provider's 478 practices, especially in relation to security and confidentiality and 479 traffic engineering. Security and confidentiality are especially 480 important when the MS-PW's are setup across ASs in different 481 administrative domains. 483 There are four different SS-PW signaling protocols that are defined 484 to signal PWs: 486 -i. Static configuration of the SS-PW (MPLS or L2TPv3). 488 -ii. LDP using PWid FEC 128 490 -iii. LDP using the generalized PW FEC 129 492 -iv. L2TPv3 494 Any combination of these signaling protocols MUST be supported. 496 Following are further requirements on MS-PW setup mechanisms: 498 -i. Static S-PE selection and PSN tunnel selection MUST be 499 provided. 501 -ii. The MS-PW path MUST have the ability to be dynamically setup 502 between the U-PEs by provisioning only the U-PEs. 504 -iii. Dynamic MS-PW pseudowire setup requires that a unique 505 identifier be associated with a PW and be carried in the 506 signaling message. That identifier must contain sufficient 507 information to determine the path to the remote U-PE through 508 intermediate S-PEs. 510 -iv. It may be required for the PW to traverse a specific S-PE to 511 enforce security, or administrative policies. 513 -v. In a single-provider domain it is natural to have the U-PE 514 identified by one of its IP addresses. This may also apply 515 when a MS-PW is setup across multiple domains operated by 516 the same provider. However, some service providers have 517 security and confidentiality policies that prevent them from 518 advertising reachability to routers in their networks to 519 other providers (reachability to an ASBR is an exception). 520 Thus, procedures MUST be provided to allow dynamic setup of 521 MS-PWs under these conditions. 523 -vi. Addressing of MS-PW end point at the U-PE MUST be 524 independent of the IP address of the U-PEs themselves. 526 -vii. Solutions MUST strive to minimize the amount of 527 configuration needed to setup an MS-PW. 529 -viii. MS-PW signaling procedures MUST define clear rules for 530 triggering the setup of segments of a MS-PW. 532 -ix. The signaling procedures MUST be defined such that the setup 533 of a MS-PW is considered successful if and only if all 534 segments of the MS-PW are successfully setup. 536 -x. Mechanisms MUST be developed to propagate setup explicit 537 failure indications to the S-PEs and U-PEs associated with 538 the failed MS-PW. 540 6.4.1. Routing 542 An objective of MS-PWs is to provide support for the following 543 connectivity: 545 -i. MS-PW MUST be able to traverse multiple IGP domains. 546 -ii. MS-PW MUST be able to traverse multiple autonomous systems 547 within the same administrative domain. 548 -iii. MS-PW MUST be able to traverse multiple autonomous systems 549 belonging to different administrative domains. 550 -iv. MS-PW MUST be able to terminate, as well, in any of above 551 mentioned domains. 552 -v. MS-PWs MUST be able to support any hybrid combination of the 553 aforementioned connectivity scenarios. 555 The routing function MUST support the various MS-PW setup methods and 556 the various connectivity scenarios. Following are the consequent 557 requirements: 559 -i. MUST support the setup of a statically configured segment of 560 a MS-PW. ( static S-PE selection ) 561 -ii. The MS-PW MUST have the ability to automatically select the 562 S-PEs along the MS-PW path. Some of the S-PEs MAY be 563 statically selected. 564 -iii. The PW Routing function MUST support dynamic re-routing 565 around failure points when segments are setup using the 566 dynamic setup method. 567 -iv. The PW Routing function MUST support re-routing around 568 failures that occur between the statically configured 569 segment endpoints. This may be done by choosing another PSN 570 tunnel between the two segment endpoints or setting up an 571 alternative tunnel. 572 -v. Routing MUST support the operation of backup protection of 573 primary paths. 574 -vi. Manual routing SHOULD be supported to allow diversity for 575 1:1 protected PWs. 577 7. Operations and Maintenance (OAM) 579 OAM mechanisms for the attachment circuits are defined in the 580 specifications for PW emulated specific technologies (e.g., ITU-T 581 I.610 for ATM). These mechanisms enable, among other things, defects 582 in the network to be detected, localized and diagnosed. They also 583 enable communication of PW defect states on the PW attachment 584 circuit. 586 The interworking of OAM mechanisms for SS-PWs between ACs and PWs is 587 defined in [PWE3-OAM]. These enable defect states to be propagated 588 across a PWE3 network following the failure and recovery from faults. 590 OAM mechanisms for MS-PWs MUST provide at least the same capabilities 591 as those for SS-PWs. 593 In addition, it should be possible to support both segment and end- 594 to-end OAM mechanisms for both defect notifications and connectivity 595 verification in order to allow defects to be localized in a multi- 596 segment network. That is, PW OAM segments can be U-PE to U-PE, U-PE 597 to S-PE, or S-PE to S-PE. 599 It is desirable to use existing PW OAM mechanisms for MS-PWs or 600 extensions to them if needed. 602 The following requirements apply to OAM for MS-PWs: 604 -i. MS-PW OAM SHOULD be supported end-to-end across the network. 606 -ii. OAM activation/deactivation SHOULD be tied to MS-PW 607 setup/tear down. 609 -iii. The MS-PW SHOULD support a Forward Defect Indicator (FDI). 611 -iv. Single ended monitoring SHOULD be supported for both 612 directions of the MS-PW. 614 -v. MS-PW OAM SHOULD support switch over between 1:1 protected 615 LSPs end-to-end. 617 -vi. In-band monitoring SHOULD be provided both end-to-end across 618 the MS-PW, and on a segment (i.e. SS-PW) basis. 620 -vii. At the S-PE, defect notifications on the upstream segment of 621 PWs must be propagated to the downstream PW segment. 623 -viii. All PE routers along the MS-PW MUST agree on a common PW OAM 624 mechanism to use to the MS-PW. 626 -ix. At the S-PE, defects on an PSN tunnel must be propagated to 627 all PWs that utilize that particular PSN tunnel. 629 -x. The directionality of defect notifications must be 630 maintained across the S-PE. 632 -xi. The S-PE should be able to behave as a segment endpoint for 633 PW OAM mechanisms. 635 -xii. The S-PE MUST be able to pass U-PE to U-PE PW OAM messages 636 transparently. 638 8. Security Considerations 640 This document specifies the requirements for MS-PWs that can be setup 641 across domain boundaries administered by one ore more service 642 providers. The security requirements for MS-PWs setup across domains 643 administered by one service provider are the same as those described 644 under security considerations in [PWE3_control]. These requirements 645 also apply to interprovider MS-PWs. In this section, the focus is on 646 the additional security requirements for interprovider operation of 647 MS-PWs in both the control plane and data plane. 649 8.1. Data-plane Security Requirements 651 MS-PWs that cross SP domain boundaries may connect one U-PE in one SP 652 domain to a U-PE in another SP-domain. They may also transit other SP 653 domains even if the two U-PEs are under the control of one SP. Under 654 these scenarios, theere is a chance that one or more PDUs be falsely 655 inserted into a MS-PW at any of the orginating, terminating or 656 transit domains. Such false injection can be the result of a 657 malicious attack or fault in the MS-PW crossconnects. Solutions MAY 658 provide mechanisms for ensuring the end-end authenticity of MS-PW 659 PDUs. 661 One of the crossed domains may decide to selectively mirror the PDUs 662 of a MS-PW for eavesdropping purposes. It may also decide to 663 selectively hijack the PDUs of a MS-PW by directing the PDUs away 664 from their destination. In either case, the privacy of a MS-PDU can 665 be violated. This document does not place any requirements on 666 protecting the privacy of a MS-PW PDU via encryption for instance. 667 Encryption may be performed at a higher layer in the protocol stack, 668 based on the application or network requirements. 670 The data plane of an S-PE at a domain boundary MUST be able to police 671 an incoming MS-PW traffic to the MS-PW traffic parameters or to an 672 administratively configured profile. The option to enable/diable 673 policing MUST be provided to the network administor. This is to 674 ensure that a MS-PW or a group of MS-PWs do not grab more resources 675 then they are allocated. In addition, the data plane of an S-PE MUST 676 be able to police OAM messages to a preconfigured traffic profile or 677 to filter out these messages upon adminsitrative configuration. 679 An ingress S-PE MUST ensure that an MS-PW receive the CoS treatment 680 configured or signaled for that MS-PW at the S-PE. Specifically, an 681 S-PE MUST guard against packets marked in the exp bits or IP-header 682 DS field (depending on the PSN) for a better CoS than they should 683 receive. 685 An ingresss S-PE MUST be able to define per-interface or interface- 686 group (a group may correspond to interfaces to a peer-provider) label 687 space for MPLS-PWs. An S-PE MUST be configurable not to accept labled 688 packets from another provider unless the bottom label is a PW-label 689 assigned by the S-PE on the interface on which the packet arrived. 691 8.2. Control-plane Security Requirements 693 A MS-PW connects two attachment circuits. It is important to make 694 sure that PW connections are not arbitrarily accepted from anywhere, 695 or else a local attachment circuit might get connected to an 696 arbitrary remote attachment circuit. The fault in the connection can 697 start at a remote U-PE or an S-PE. 699 An incoming MS-PW request/reply MUST NOT be accepted unless its IP 700 source address is known to be the source of an "eligible" peer. If a 701 peering adjacency has to be established prior to exchaging setup 702 requests/responses, peering MUST only be done with eligible peers. 703 The set of eligible peers could be pre-configured (either as a list 704 of IP addresses, or as a list of address/mask combinations). 705 Furthermore, the restriction of peering sessions to specific 706 interfaces SHOULD also be provided. The S-PE and U-PE SHOULD drop the 707 unaccepted signaling messages in the data path to avoid a DoS attack 708 on the control plane. 710 Even if a connection request appears to come from an eligible peer, 711 its source address may have been spoofed. So some means of preventing 712 source address spoofing must be in place. For example, if eligible 713 peers are in the same network, source address filtering at the border 714 routers of that network could eliminate the possibility of source 715 address spoofing. 717 For a greater degree of security, an authentication mechanism that is 718 suitable to the associated protocol MUST be available. Furthermore 719 authentication using a signature for each indifidual MS-PW setup 720 messages MUST be available, in addition to an overall control 721 protocol session authentication , and message validation. 723 Peer authentication protects against IP address spoofing but does not 724 prevent one peer (S-PE or U-PE) from connecting to the wrong 725 attachment circuit. Under a single administrative authority, this may 726 be the result of a misconfiguration. When the MS-PW crosses multiple 727 provider domains, this may be the result of a malicious act by a 728 service provider or a security hole in that provider network. Static 729 manual configuration of MS-PWs at S-PEs and U-PEs provide a greater 730 degree of security. If an identfication of both ends of a MS-PW is 731 configured and carried in the signaling message, an S-PE can verify 732 the signaling message against the configuration. To support dynamic 733 signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs 734 are dynamically discovered, mechanisms SHOULD be provided to 735 configure such information on a server and to use that information 736 during a connection attempt for validation. 738 S-PEs that connect one provider domain to another provider domain 739 MUST have the capability to rate-limit signaling traffic in order to 740 prevent DoS attacks on the control plane. Furthermore, detection and 741 disposition of malformed packets and defense against various forms of 742 attacks that can be protocol-specific MUST be provided. 744 9. Full Copyright Statement 746 Copyright (C) The Internet Society (2005). 748 This document is subject to the rights, licenses and restrictions 749 contained in BCP 78, and except as set forth therein, the authors 750 retain all their rights. 752 This document and the information contained herein are provided on an 753 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 754 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 755 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 756 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 757 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 10. Intellectual Property Statement 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at ietf- 782 ipr@ietf.org. 784 By submitting this Internet-Draft, I certify that any applicable 785 patent or other IPR claims of which I am aware have been disclosed, 786 or will be disclosed, and any of which I become aware will be 787 disclosed, in accordance with RFC 3668. 789 11. IANA Considerations 791 This document has no IANA Actions. 793 12. Normative References 795 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., RFC3985. 797 [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., 798 draft-ietf-pwe3-oam-msg-map-02.txt (work in progress), 799 February 2005 801 13. Informative References 803 [ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for 804 Frame Mode Basic call control, ITU Geneva 1995 806 14. Author Information 808 Luca Martini 809 Cisco Systems, Inc. 810 9155 East Nichols Avenue, Suite 400 811 Englewood, CO, 80112 812 e-mail: lmartini@cisco.com 813 Matthew Bocci 814 Alcatel Telecom Ltd, 815 Voyager Place 816 Shoppenhangers Road 817 Maidenhead 818 Berks, UK 819 e-mail: matthew.bocci@alcatel.co.uk 821 Nabil Bitar 822 Verizon 823 40 Sylvan Road 824 Waltham, MA 02145 825 e-mail: nabil.bitar@verizon.com