idnits 2.17.1 draft-ietf-pwe3-ms-pw-requirements-03.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 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1016. ** 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 (October 2006) is 6397 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) == Unused Reference: 'ITUQ' is defined on line 1031, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3916 ** Downref: Normative reference to an Informational RFC: RFC 3985 (ref. 'PWE3-ARCH') -- 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 (~~), 5 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: April 2007 6 Luca Martini (Editor) Matthew Bocci (Editor) 7 Cisco Systems Inc. Alcatel 9 October 2006 11 Requirements for inter domain Pseudo-Wires 13 draft-ietf-pwe3-ms-pw-requirements-03.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 ........................ 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 Pseudo Wire Placement Mechanisms ....... 11 57 6 Multi-Segment Pseudo-Wire Requirements ............... 11 58 6.1 All Mechanisms ....................................... 12 59 6.1.1 Architecture ......................................... 12 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 ......................................... 18 71 6.4.2 Resiliency ........................................... 18 72 6.4.3 Quality of Service ................................... 18 73 6.4.4 Routing .............................................. 19 74 6.5 Signaled PW / Dynamic Route .......................... 19 75 6.5.1 Architecture ......................................... 19 76 6.5.2 Resiliency ........................................... 20 77 6.5.3 Quality of Service ................................... 20 78 6.5.4 Routing .............................................. 20 79 7 Operations and Maintenance (OAM) ..................... 20 80 8 Security Considerations .............................. 22 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 ................................... 26 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 pseudo-wires 109 across more than one packet switched network (PSN) domain and more 110 than one PSN tunnel. These pseudo-wires are called multi-segment 111 pseudo-wires (MS-PW). Requirements for single-segment pseudo wires 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 [PWE3-ARCH] to support PW emulated services. 123 |<-------------- Emulated Service ---------------->| 124 | | 125 | |<------- Pseudo Wire ------>| | 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 [PWE3-ARCH]. 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 |<-----------Pseudo Wire------------->| Native 153 Service | | Service 154 (AC) | |<-PSN1-->| |<--PSN2->| | (AC) 155 | V V V V V V | 156 | +-----+ +-----+ +---- + | 157 +----+ | |T-PE1|=========|S-PE2|=========|T-PE3| | +----+ 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 reside in different PSN domains, 176 PSN1 and PSN2, respectively. One PSN tunnel extends from T-PE1 to 177 T-PE2 across PSN1, and a second PSN tunnel extends from PE2 to PE3 178 across PSN2. PWs are used to connect the Attachment circuits (ACs) 179 attached to T-PE1 to the corresponding ACs attached to T-PE3. Each PW 180 on the tunnel across PSN1 is stitched to a PW in the tunnel across 181 PSN2 at S-PE2 to complete the multi-segment PW (MS-PW) between T-PE1 182 and T-PE3. S-PE2 is therefore the PW switching point and will be 183 referred to as the PW switching provider edge (S-PE). PW1 and PW3 are 184 segments of the same MS-PW while PW2 and PW4 are segments of another 185 pseudo-wire. PW segments of the same MS-PW (e.g., PW1 and PW3) MAY be 186 of the same PW type or different type, and PSN tunnels (e.g., PSN1 187 and PSN2) can be the same or different technology. This document 188 requires support for MS-PWs with segments of the same PW type. An S- 189 PE switches a MS-PW from one segment to another based on the PW 190 identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, PSN1 191 and PSN2 domains could be IGP areas in the same IGP network, or 192 simply PWE3 domains in a single flat IGP network for instance. 194 |<--------------Pseudo Wire----------->| 195 | | AS | | AS | 196 AC | |<----1---->| |<----2--->| | AC 197 | V V V V V V | 198 | +----+ +-----+ +----+ +----+ | 199 +----+ | | |=====| |=====| |=====| | | +----+ 200 | |-------|.....PW1..........PW2.........PW3.....|-------| | 201 | CE1| | | | | | | | | | | |CE2 | 202 +----+ | | |=====| |=====| |=====| | | +----+ 203 ^ +----+ +-----+ +----+ +----+ ^ 204 | T-PE1 S-PE2 S-PE3 T-PE4 | 205 | ^ ^ | 206 | | | | 207 | PW switching points | 208 | | 209 | | 210 |<------------------- Emulated Service --------------->| 212 Figure 3: PW switching inter provider Reference Model 214 Note that although Figure 2 only shows a single S-PE, a PW may 215 transit more than one S-PE along its path. For instance, in the 216 multi-AS case shown in Figure 3, there can be an S-PE (S-PE2), at the 217 border of one AS (AS1) and another S-PE (S-PE3) at the border of the 218 other AS (AS2). A MS-PW that extends from the edge of one AS (T-PE1) 219 to the edge of the other AS (T-PE4) is composed of three segments: 220 (1) PW1, a segment in AS1, (2) PW2, a segment between the two border 221 routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a 222 segment in AS2. AS1 and AS2 could be belong to the same provider 223 (e.g., AS1 could be an access network or metro transport network, and 224 AS2 could be an MPLS core network) or to two different providers 225 (e.g., AS1 for Provider 1 and AS2 for Provider2). 227 4. Terminology 229 RFC 3985 [PWE3-ARCH] provides terminology for PWE3. The following 230 additional terminology is defined for multi-segment pseudo wires: 232 - PW Terminating Provider Edge (T-PE). A PE where the customer- 233 facing attachment circuits (ACs) are bound to a PW forwarder. A 234 Terminating PE is present in the first and last segments of a 235 MS-PW. This incorporates the functionality of a PE as defined in 236 RFC 3985. 238 - Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 239 two T-PE devices. Each direction of a SS-PW traverses one PSN 240 tunnel that connects the two T-PEs. 242 - Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 243 configured set of two or more contiguous PW segments that behave 244 and function as a single point-to-point PW. Each end of a MS-PW 245 by definition MUST terminate on a T-PE. 247 - PW Segment. A part of a single-segment or multi-segment PW, which 248 is set up between two PE devices, T-PEs and/or S-PEs. 250 - PW Switching Provider Edge (S-PE). A PE capable of switching the 251 control and data planes of the preceding and succeeding PW 252 segments in a MS-PW. The S-PE terminates the PSN tunnels 253 transporting the preceding and succeeding segments of the MS-PW. 254 It is therefore a PW switching point for a MS-PW. A PW Switching 255 Point is never the S-PE and the T-PE for the same MS-PW. A PW 256 switching point runs necessary protocols to setup and manage PW 257 segments with other PW switching points and terminating PEs. 259 5. Use Cases 261 PWE3 defines the signaling and encapsulation techniques for 262 establishing SS-PWs between a pair of terminating PEs (T-PEs) and in 263 the vast majority of cases this will be sufficient. MS-PWs may be 264 useful in the following situations: 266 -i. Inter-Provider PWs: An Inter-Provider PW is a PW that 267 extends from a T-PE in one provider domain to a T-PE in 268 another provider domain. 270 -ii. It may not be possible, desirable or feasible to establish a 271 direct PW control channel between the T-PEs, residing in 272 different provider networks, to setup and maintain PWs. At a 273 minimum, a direct PW control channel establishment (e.g., 274 targeted LDP session) requires knowledge of and reachability 275 to the remote T-PE IP address. The local T-PE may not have 276 access to this information due to operational or security 277 constraints. Moreover, a SS-PW would require the existence 278 of a PSN tunnel between the local T-PE and the remote T-PE. 279 It may not be feasible or desirable to extend single, 280 contiguous PSN tunnels between T-PEs in one domain and T-PEs 281 in another domain for security and/or scalability reasons or 282 for the fact that the two domains may be using different PSN 283 technologies. 285 -iii. MS-PW setup, maintenance and forwarding procedures must 286 satisfy requirements placed by the constraints of a multi- 287 provider environment. An example is the inter-AS L2VPN 288 scenario where the T-PEs reside in different provider 289 networks (ASs) and it is the current practice to MD5-key all 290 control traffic exchanged between two networks. A MS-PW 291 allows the providers to confine MD5 key administration for 292 the LDP session to just the PW switching points connecting 293 the two domains. 295 -iv. PSN Interworking: PWE3 signaling protocols and PSN types may 296 differ in different provider networks. The terminating PEs 297 may be connected to networks employing different PW 298 signaling and /or PSN protocols. In this case it is not 299 possible to use a SS-PW. A MS-PW with the appropriate 300 interworking performed at the PW switching points can enable 301 PW connectivity between the terminating PEs in this 302 scenario. 304 -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: 305 There is a requirement to deploy PWs edge to edge in large 306 service provider networks. Such networks typically encompass 307 hundreds or thousands of aggregation devices at the edge, 308 each of which would be a PE. Furthermore, there is a 309 requirement that these PWs have explicit bandwidth 310 guarantees. To satisfy these requirements, the PWs will be 311 tunneled over PSN TE-tunnels with bandwidth constraints. A 312 single segment pseudo-wire architecture would require that a 313 full mesh of PSN TE-tunnels be provisioned to allow PWs to 314 be established between all PEs. Inter-provider PWs riding 315 traffic engineered tunnels further add to the number of 316 tunnels that would have to be supported by the PEs and the 317 core network as the total number of PEs increases. 319 In this environment, there is a requirement either to 320 support a sparse mesh of PSN TE-tunnels and PW signaling 321 adjacencies, or to partition the network into a number of 322 smaller PWE3 domains. In either case, a PW would have to 323 pass through more than one PSN tunnel hop along its path. An 324 objective is to reduce the number of tunnels that must be 325 supported, and thus the complexity and scalability problem 326 that may arise. 328 -vi. Pseudo Wires in access/metro metworks: Service providers 329 wish to extend PW technology to access and metro networks in 330 order to reduce maintenance complexity and operational 331 costs. Today's access and metro networks are either legacy 332 (TDM, SONET/SDH, or Frame Relay/ATM), Ethernet or IP based. 334 Due to these architectures, circuits (e.g., Ethernet VCs, 335 ATM VCs, TDM circuits) in the access/metro are traditionally 336 handled as attachment circuits, in their native format, to 337 the edge of the IP-MPLS network where the PW starts. This 338 combination requires multiple separate access networks and 339 complicates end-to-end control, provisioning, and 340 maintenance. In addition, when a TDM or SONET/SDH access 341 network is replaced with a packet-based infrastructure, 342 expenses may be lowered due to moving statistical 343 multiplexing closer to the end-user and converging multiple 344 services onto a single access network. 346 In order to set up an end-to-end PW, one is required either 347 to extend MPLS from the core into the access sections, or to 348 leverage PW mechanisms over non-MPLS access infrastructures. 350 By setting up a PW in the access network and stitching it 351 with a PW in the core, one achieves end-to-end PW continuity 352 without expanding the IP-MPLS network to the access. The 353 resukting Pseudo Wire is refered to as MS-PW. The MS-PW 354 benefits from 355 improved performance due to traffic engineering, converged 356 or commmon setup procedures and a single OAM echanism. 358 Access networks tend to differ from core networks in aspects 359 that simplify the way a PW is set up and utilized. Although 360 access network typically have many more network elements 361 than core 363 //Service providers are looking to //extend PWs to access 364 and metro networks. The prime motive is cost reduction //in 365 capital and operation expenses. For instance, in metro 366 networks, //providers are looking into extending PWs to next 367 generation SONET ADMs using //MPLS mechanisms. The objective 368 is to achieve statistical multiplexing of //packets closer 369 to the edge of the network, reducing the recurring costs of 370 //SONET circuits or maximizing the utilization of existing 371 SONET //infrastructure. In access and metro Ethernet 372 networks, providers are looking //to take advantage of MPLS 373 mechanisms to setup point to point Ethernet //virtual 374 circuits with endpoints in the same or different 375 access/metro //networks. 377 Using the MS-PW solution, access and metro network elements 378 need only maintain PW signaling adjacencies with the PEs to 379 which they directly connect. They do not need PW signaling 380 adjacencies with every other access and metro network 381 device. PEs in the PSN backbone in turn maintain PW 382 signaling adjacencies among each other. In addition, a PSN 383 tunnel is setup between an access element and the PE to 384 which it connects. Another PSN tunnel needs to be 385 established between every PE pair in the PSN backbone. A 386 MS-PW may be setup from one access network element to 387 another another access element with three segments: (1) 388 access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN- 389 PE to access element. In this MS-PW setup, access elements 390 are T-PEs while PSN-PEs are S-PEs. It should be noted that 391 the PSN backbone can be also segmented into PWE3 domains 392 resulting in more segments per PW. 394 5.1. Multi-Segment Pseudo Wire Placement Mechanisms 396 This requirements document assumes that the above use cases are 397 realized using one or more of the following mechanisms: 399 -i. Static Configuration: The switching points (S-PEs), in 400 addition to the T-PEs, are manually provisioned for each 401 segment. 403 -ii. Pre-determined Route: The PW is established along an 404 administratively determined route using an end-to-end 405 signaling protocol with automated stitching at the S-PEs. 407 -iii. Signaled Dynamic Route: The PW is established along a 408 dynamically determined route using an end-to-end signaling 409 protocol with automated stitching at the S-PEs. The route is 410 selected with the aid of one or more dynamic routing 411 protocols. 413 Note that we define the PW route to be the set of S-PEs through which 414 a MS-PW will pass between a given pair of T-PEs. PSN tunnels along 415 that route can be explicitly specified or locally selected at the S- 416 PEs and T-PEs. The routing of the PSN tunnels themselves is outside 417 the scope of the requirements specified in this document. 419 6. Multi-Segment Pseudo-Wire Requirements 421 The following sections detail the requirements that the above use 422 cases put on the MS-PW setup mechanisms. 424 6.1. All Mechanisms 426 The following generic requirements apply to the three MS-PW setup 427 mechanisms defined in the previous section. 429 6.1.1. Architecture 431 -i. If MS-PWs are tunneled, across a PSN that only supports SS- 432 PWs, then only the requirements of [RFC3916] apply to that 433 PSN. The fact that the overlay is carrying MS-PWs MUST be 434 transparent to the routers in the PSN. 436 -ii. The PWs MUST remain transparent to the P-routers. A P-router 437 is not an S-PE or an T-PE from the MS-PW architecture 438 viewpoint. P-routers provide transparent PSN transport for 439 PWs and MUST not have any knowledge of the PWs traversing 440 them. 442 -iii. The MS-PWs MUST use the same encapsulation modes specified 443 for SS-PWs. 445 -iv. The MS-PWs MUST be composed of SS-PWs. 447 -v. A MS-PW MUST be able to pass across PSNs of all technologies 448 specified by PWE3 for SS-PWs. When crossing from one PSN 449 technology to another, an S-PE must provide the necessary 450 PSN interworking functions in that case. 452 -vi. Both directions of a PW segment MUST terminate on the same 453 S-PE/T-PE. 455 -vii. S-PEs MAY only support switching PWs of the same PW type. In 456 this case, the PW type is transparent to the S-PE in the 457 forwarding plane, except for functions needed to provide for 458 interworking between different PSN technologies. 460 -viii. Solutions MAY provide a way prioritize the setup and 461 maintenance process among PWs. 463 6.1.2. Resiliency 465 Mechanisms to protect a MS-PW when an element on the existing path of 466 a MS-PW fails MUST be provided. These mechanisms will depend on the 467 MS-PW setup. Following are the generic resiliency requirements that 468 apply to all MS-PW setup mechanisms: 470 -i. Configuration and establishment of a backup PW to a primary 471 PW SHOULD be supported. Mechanisms to perform a switchover 472 from a primary PW to a backup PW upon failure detection 473 SHOULD be provided. 475 -ii. The ability to configure an end-to-end backup PW path for a 476 primary PW path SHOULD be supported. The primary and backup 477 paths may be statically configured, statically specified for 478 signaling or dynamically selected via dynamic routing 479 depending on the MS-PW establishment mechanism. Backup and 480 primary paths should have the ability to traverse separate 481 S-PEs. The backup path MAY be signaled at configuration time 482 or after failure. 484 -iii. The ability to configure a primary PW and a backup PW with a 485 different T-PE from the primary SHOULD be supported. 487 -iv. Automatic Mechanisms to perform a fast switchover from a 488 primary PW to a backup PW upon failure detection SHOULD be 489 provided. 491 -v. A mechanism to automatically revert to a primary PW from a 492 backup PW MAY be provided. When provided, it MUST be 493 configurable. 495 6.1.3. Quality Of Service 497 Pseudo wires are intended to support emulated services (e.g., TDM and 498 ATM) which may have strict per-connection quality of service 499 requirements. This may include either absolute or relative guarantees 500 on packet loss, delay, and jitter. These guarantees are in part 501 delivered by reserving sufficient network resources (e.g. bandwidth), 502 and by providing appropriate per-packet treatment (e.g. scheduling 503 priority and drop precedence) throughout the network. 505 For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be 506 used to ensure that sufficient resources are reserved in the P- 507 routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST 508 have the ability to automatically manage PSN tunnel resources in the 509 traffic direction (e.g. admission control of PWs onto the PSN tunnel 510 and accounting for reserved bandwidth and available bandwidth on the 511 tunnel). In cases where the tunnel supports multiple classes of 512 service (CoS) (e.g., E-LSP), bandwidth management is required per 513 CoS. 515 For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions 516 Must enable S-PEs and T-PEs to automatically bind a PW segment to a 517 PSN-tunnel based on CoS and bandwidth requirements when these 518 attributes are specified for a PW. Solutions SHOULD also provide the 519 capability of binding a PW segment to a tunnel as a matter of policy 520 configuration. S-PEs and T-PEs must be capable of automatically 521 managing PSN-tunnel resources per CoS. 523 S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP 524 field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs 525 affects packet treatment. The CoS marking depends on the PSN 526 technology. Thus, solutions must enable the configuration of 527 necessary mapping for CoS marking when the MS-PW crosses from one PSN 528 technology to another. Similarly, different administrative domains 529 may use different CoS values to imply the same CoS treatment. 530 Solutions MUST provide the ability to define CoS marking maps on S- 531 PEs at administrative domain boundaries to translate from one CoS 532 value to another as a a PW PDU crosses from one domain to the next. 534 Solutions MUST enable S-PEs and T-PEs on the path of a MS-PW to 535 notify other S-PEs and T-PEs on that path of congestion when it 536 occurs. Congestion may be indicated by queuue length, packet loss 537 rate, or bandwidth measurement (among others) crossing a respective 538 threshold. The action taken by a T-PE that receives a notification of 539 congestion along the path of one of its PWs could be to reroute the 540 MS-PW to an alternative path, including an alternative T-PE if 541 available. Some PW types, such as TDM PWs, are more sensitive to 542 congestion than others. The raction to congestion notification MAY 543 vary per PW type. 545 6.2. Generic Requirements for MS-PW Setup Mechanisms 547 The MS-PW setup mechanisms MUST accommodate Service Provider's 548 practices, especially in relation to security, confidentiality and 549 traffic engineering. Security and confidentiality are especially 550 important when the MS-PWs are setup across Autonomous Systems in 551 different administrative domains. Following are generic requirements 552 that apply to the three MS-PW setup mechanisms defined earlier: 554 -i. The ability to statically select S-PEs and PSN tunnels on a 555 PW path MUST be provided. Static selection of S-PEs is by 556 definition a requirement for the static configuration and 557 signaled/static route setup mechanisms. This requirement 558 satisfies the need for forcing a MS-PW to traverse specific 559 S-PEs to enforce service provider security and 560 administrative policies. 562 -ii. Solutions SHOULD minimize the amount of configuration needed 563 to setup a MS-PW. 565 -iii. Solutions should support different PW setup mechanisms on 566 the same T-PE, S-PE and PSN network. 568 -iv. Solutions MUST allow T-PEs to simultaneously support use of 569 SS-PW signaling mechanisms as specified in [RFC4447] as well 570 as MS-PW signaling mechanisms. 572 -v. Solutions MUST ensure that a MS-PW will be setup when a path 573 that satisfies the PW constraints for bandwidth, CoS and 574 other possible attributes does exist in the network. 576 -vi. Solutions must clearly define the setup procedures for each 577 mechanism so that a MS-PW setup on T-PEs can be interpreted 578 as successful only when all PW segments are successfully 579 setup. 581 -vii. Admission control to the PSN tunnel needs to be performed 582 against available resources, when applicable. This process 583 MUST be performed at each PW segment comprising the MS-PW. 584 PW admission control into a PSN tunnel MUST be configurable. 586 -viii. In case the PSN tunnel lacks the resources necessary to 587 accommodate the new PW, an attempt to signal a new PSN 588 tunnel, or increase the capacity of the existing PSN tunnel 589 MAY be made. If the expanded PSN tunnel fails to setup the 590 PW MUST fail to setup. 592 -ix. The setup mechanisms must allow the setup of a PW segment 593 between two directly connected S-PEs without the existence 594 of a PSN tunnel. This requirement allows a PW segment to be 595 setup between two (Autonomous System Border Routers (ASBRs) 596 when the MS-PW crosses AS boundaries without the need for 597 configuring and setting up a PSN tunnel. In this case, 598 admission control must be done, when enabled, on the link 599 between the S-PEs. 601 6.2.1. Routing 603 An objective of MS-PWs is to provide support for the following 604 connectivity: 606 -i. MS-PWs MUST be able to traverse multiple Service Provider 607 administrative domains. 609 -ii. MS-PWs MUST be able to traverse multiple Autonomous Systems 610 within the same administrative domain. 612 -iii. MS-PWs MUST be able to traverse multiple Autonomous Systems 613 belonging to different administrative domains. 615 -iv. MS-PWs MUST be able to support any hybrid combination of the 616 aforementioned connectivity scenarios, including both PW 617 transit , and termination in a domain. 619 6.3. Statically configured MS-PWs 621 When the MS-PW segments are statically configured the following 622 requirements apply in addition to the generic requirements previously 623 defined. 625 6.3.1. Architecture 627 There are no additional requirements on the architecture. 629 6.3.2. MPLS-PWs 631 Solutions should allow for the static configuration of MPLS labels 632 for MPLS-PW segments and the cross-connection of these labels to 633 preceding and succeeding segments. This is especially useful when a 634 MS-PW crosses provider boundaries and two providers do not want to 635 run any PW signaling protocol between them. A T-PE or S-PE that 636 allows the configuration of static labels for MS-PW segments should 637 also simultaneously allow for dynamic label assignments for other 638 MS-PW segments. It should be noted that when two interconnected S-PEs 639 do not have signaling peering for the purpose of setting up MS-PW 640 segments, they should have in-band PW OAM capabilities that relay PW 641 or attachment circuit defect notifications between the adjacent S- 642 PEs. 644 6.3.3. Resiliency 646 The solution should allow for the protection of a PW-segment, a 647 contiguous set of PW-segments, as well as the end-end path. The 648 primary and protection segments paths must share the same segments 649 endpoints. Solutions should allow for having the backup paths setup 650 prior to the failure or as a result of failure. The choice should be 651 made by configuration. When resources are limited and cannot satisfy 652 all PWs, the PWs with the higher setup priorities should be given 653 preference when compared with the setup priorities of other PWs being 654 setup or the holding priorities of existing PWs. 656 Solutions should strive to minimize traffic loss between T-PEs. 658 6.3.4. Quality of service 660 The CoS and bandwidth of the MS-PW must be configurable at T-PEs and 661 S-PEs. 663 6.4. Signaled PW-segments 665 When the MS-PW segments are dynamically signaled the following 666 requirements apply in addition to the generic requirements previously 667 defined. 669 These signaled MS-PW segments can be on the path of a statically 670 configured MS-PW, signaled/statically routed MS-PW or 671 signaled/dynamically routed MS-PW. 673 There are four different SS-PW signaling protocols that are defined 674 to signal PWs: 676 -i. Static setup of the SS-PW (MPLS or L2TPv3 forwarding). 678 -ii. LDP using PWid FEC 128 680 -iii. LDP using the generalized PW FEC 129 682 -iv. L2TPv3 684 The MS-PW setup mechanism MUST be able to support PW segments 685 signaled with any of the above protocols, however the specification 686 of which combinations of SS-PW signaling protocols is supported by a 687 specific implementation is outside the scope of this document. 689 For the signaled/statically routed and signaled/dynamically routed 690 MS-PW setup mechanisms the following requirements apply in addition 691 to the generic requirements previously defined. 693 6.4.1. Architecture 695 There are no additional requirements on the architecture. 697 6.4.2. Resiliency 699 Solutions should allow for the signaling of a protection path for a 700 PW segment, sequence of segments or end-to-end path. The protection 701 and primary paths for the protected segment(s) share the same 702 respective segments endpoints. When admission control is enabled, 703 systems must be careful not to double account for bandwidth 704 allocation at merged points (e.g., tunnels). Solutions should allow 705 for having the backup paths setup prior to the failure or as a result 706 of failure. The choice should be made by configuration at the 707 endpoints of the protected path. When resources are limited and 708 cannot satisfy all PWs, the PWs with the higher setup priorities 709 should be given preference when compared with the setup priorities of 710 other PWs being setup or the holding priorities of existing PWs. 711 Procedures must allow for the primary and backup paths to be 712 diversified 714 6.4.3. Quality of Service 716 When the T-PE attempts to signal a MS-PW the following capability is 717 required: 719 -i. Signaling must be able to identify the CoS associated with a 720 MS-PW 721 -ii. Signaling must be able to carry the traffic parameters for a 722 MS-PW per CoS. Traffic parameters should be based on 723 existing INTSERV definitions and must be used for admission 724 control when admission control is enabled. 726 -iii. The PW signaling MUST enable separate traffic parameter 727 values to be specified for the forward and reverse 728 directions of the PW. 730 -iv. PW traffic parameter representations MUST be the same for 731 all types of MS-PWs. 733 -v. The signaling protocol must be able to accommodate a method 734 to prioritize the PW setup and maintenance process among 735 PWs. 737 6.4.4. Routing 739 See the requirements for "Resiliency" above. 741 Following are further requirements on signaled MS-PW setup 742 mechanisms: 744 -i. The signaling procedures MUST be defined such that the setup 745 of a MS-PW is considered successful if all segments of the 746 MS-PW are successfully setup. 748 -ii. The MS-PW path MUST have the ability to be dynamically setup 749 between the T-PEs by provisioning only the T-PEs. 751 -iii. Dynamic MS-PW setup requires that a unique identifier be 752 associated with a PW and be carried in the signaling 753 message. That identifier must contain sufficient information 754 to determine the path to the remote T-PE through 755 intermediate S-PEs. 757 -iv. In a single-provider domain it is natural to have the T-PE 758 identified by one of its IP addresses. This may also apply 759 when a MS-PW is setup across multiple domains operated by 760 the same provider. However, some service providers have 761 security and confidentiality policies that prevent them from 762 advertising reachability to routers in their networks to 763 other providers (reachability to an ASBR is an exception). 764 Thus, procedures MUST be provided to allow dynamic setup of 765 MS-PWs under these conditions. 767 6.5. Signaled PW / Dynamic Route 769 The following requirements apply, in addition to those in Section 6.1 770 and Section 6.2, when both dynamic signaling and dynamic routing are 771 used. 773 6.5.1. Architecture 775 There are no additional architectural requirements. 777 6.5.2. Resiliency 779 The PW Routing function MUST support dynamic re-routing around 780 failure points when segments are setup using the dynamic setup 781 method. 783 6.5.3. Quality of Service 785 There are no additional QoS requirements. 787 6.5.4. Routing 789 Following are requirements associated with dynamic route selection 790 for a MS-PW: 792 -i. Routing must enable S-PEs and T-PEs to discover S-PEs on the 793 path to a destination T-PE. 795 -ii. The MS-PW routing function MUST have the ability to 796 automatically select the S-PEs along the MS-PW path. Some of 797 the S-PEs MAY be statically selected and carried in the 798 signaling to constrain the route selection process. 800 -iii. The PW Routing function MUST support re-routing around 801 failures that occur between the statically configured 802 segment endpoints. This may be done by choosing another PSN 803 tunnel between the two segment endpoints or setting up an 804 alternative tunnel. 806 -iv. Routing protocols must be able to advertise reachability 807 information to attachment circuit (AC) endpoints. This 808 reachability information must be consistent with the AC 809 identifiers carried in signaling. 811 7. Operations and Maintenance (OAM) 813 OAM mechanisms for the attachment circuits are defined in the 814 specifications for PW emulated specific technologies (e.g., ITU-T 815 I.610 for ATM). These mechanisms enable, among other things, defects 816 in the network to be detected, localized and diagnosed. They also 817 enable communication of PW defect states on the PW attachment 818 circuit. 820 The interworking of OAM mechanisms for SS-PWs between ACs and PWs is 821 defined in [PWE3-OAM]. These enable defect states to be propagated 822 across a PWE3 network following the failure and recovery from faults. 824 OAM mechanisms for MS-PWs MUST provide at least the same capabilities 825 as those for SS-PWs. 827 In addition, it should be possible to support both segment and end- 828 to-end OAM mechanisms for both defect notifications and connectivity 829 verification in order to allow defects to be localized in a multi- 830 segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE 831 to S-PE, or S-PE to S-PE. 833 The following requirements apply to OAM for MS-PWs: 835 -i. Mechanisms for PW segment failure detection and notification 836 to other segments of a MS-PW MUST be provided. 838 -ii. MS-PW OAM SHOULD be supported end-to-end across the network. 840 -iii. Single ended monitoring SHOULD be supported for both 841 directions of the MS-PW. 843 -iv. MS-PW OAM SHOULD support switch over between 1:1 protected 844 LSPs end-to-end. 846 -v. SS-PW OAM mechanisms (e.g., [VCCV]) SHOULD be extended to 847 support MS-PWs on both end-end basis and segment basis. 849 -vi. All PE routers along the MS-PW MUST agree on a common PW OAM 850 mechanism to use for the MS-PW. 852 -vii. At the S-PE, defects on an PSN tunnel MUST be propagated to 853 all PWs that utilize that particular PSN tunnel. 855 -viii. The directionality of defect notifications MUST be 856 maintained across the S-PE. 858 -ix. The S-PE SHOULD be able to behave as a segment endpoint for 859 PW OAM mechanisms. 861 -x. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages 862 transparently. 864 -xi. Performance OAM, is required for both MS-PWs and SS-PWs to 865 measure round-trip delay, one-way delay, jitter, and packet 866 loss ratio. 868 8. Security Considerations 870 This document specifies the requirements for MS-PWs that can be setup 871 across domain boundaries administered by one ore more service 872 providers. The security requirements for MS-PW setup across domains 873 administered by one service provider are the same as those described 874 under security considerations in [RFC4447]. These requirements also 875 apply to interprovider MS-PWs. In addition, [RFC4111] identifies user 876 and provider requirements for L2 VPNs that apply to MS-PWs described 877 in this document. In this section, the focus is on the additional 878 security requirements for interprovider operation of MS-PWs in both 879 the control plane and data plane,and some of these requirements may 880 overlap with those in [RFC4111]. 882 8.1. Data-plane Security Requirements 884 MS-PWs that cross SP domain boundaries may connect one T-PE in a SP 885 domain to a T-PE in another SP-domain. They may also transit other SP 886 domains even if the two T-PEs are under the control of one SP. Under 887 these scenarios, there is a chance that one or more PDUs could be 888 falsely inserted into a MS-PW at any of the originating, terminating 889 or transit domains. Such false injection can be the result of a 890 malicious attack or fault in the MS-PW cross-connects. Solutions MAY 891 provide mechanisms for ensuring the end-to-end authenticity of MS-PW 892 PDUs. 894 One of the crossed domains may decide to selectively mirror the PDUs 895 of a MS-PW for eavesdropping purposes. It may also decide to 896 selectively hijack the PDUs of a MS-PW by directing the PDUs away 897 from their destination. In either case, the privacy of a MS-PDU can 898 be violated. This document does not place any requirements on 899 protecting the privacy of a MS-PW PDU via encryption for instance. 900 Encryption may be performed at a higher layer in the protocol stack, 901 based on the application or network requirements. 903 The data plane of an S-PE at a domain boundary MUST be able to police 904 an incoming MS-PW traffic to the MS-PW traffic parameters or to an 905 administratively configured profile. The option to enable/disable 906 policing MUST be provided to the network administrator. This is to 907 ensure that a MS-PW or a group of MS-PWs do not grab more resources 908 than they are allocated. In addition, the data plane of an S-PE MUST 909 be able to police OAM messages to a pre-configured traffic profile or 910 to filter out these messages upon administrative configuration. 912 An ingress S-PE MUST ensure that a MS-PW receive the CoS treatment 913 configured or signaled for that MS-PW at the S-PE. Specifically, an 914 S-PE MUST guard against packets marked in the exp bits or IP-header 915 DS field (depending on the PSN) for a better CoS than they should 916 receive. 918 An ingress S-PE MUST be able to define per-interface or interface- 919 group (a group may correspond to interfaces to a peer-provider) label 920 space for MPLS-PWs. An S-PE MUST be configurable not to accept 921 labeled packets from another provider unless the bottom label is a 922 PW-label assigned by the S-PE on the interface on which the packet 923 arrived. 925 8.2. Control-plane Security Requirements 927 A MS-PW connects two attachment circuits. It is important to make 928 sure that PW connections are not arbitrarily accepted from anywhere, 929 or else a local attachment circuit might get connected to an 930 arbitrary remote attachment circuit. The fault in the connection can 931 start at a remote T-PE or an S-PE. 933 An incoming MS-PW request/reply MUST NOT be accepted unless its IP 934 source address is known to be the source of an "eligible" peer. If a 935 peering adjacency has to be established prior to exchanging setup 936 requests/responses, peering MUST only be done with eligible peers. 937 The set of eligible peers could be pre-configured (either as a list 938 of IP addresses, or as a list of address/mask combinations). 939 Furthermore, the restriction of peering sessions to specific 940 interfaces SHOULD also be provided. The S-PE and T-PE SHOULD drop the 941 unaccepted signaling messages in the data path to avoid a DoS attack 942 on the control plane. 944 Even if a connection request appears to come from an eligible peer, 945 its source address may have been spoofed. So some means of preventing 946 source address spoofing must be in place. For example, if eligible 947 peers are in the same network, source address filtering at the border 948 routers of that network could eliminate the possibility of source 949 address spoofing. 951 For a greater degree of security, an authentication mechanism that is 952 suitable to the associated protocol MUST be available. Furthermore 953 authentication using a signature for each individual MS-PW setup 954 messages MUST be available, in addition to an overall control 955 protocol session authentication , and message validation. 957 Peer authentication protects against IP address spoofing but does not 958 prevent one peer (S-PE or T-PE) from connecting to the wrong 959 attachment circuit. Under a single administrative authority, this may 960 be the result of a misconfiguration. When the MS-PW crosses multiple 961 provider domains, this may be the result of a malicious act by a 962 service provider or a security hole in that provider network. Static 963 manual configuration of MS-PWs at S-PEs and T-PEs provide a greater 964 degree of security. If an identification of both ends of a MS-PW is 965 configured and carried in the signaling message, an S-PE can verify 966 the signaling message against the configuration. To support dynamic 967 signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs 968 are dynamically discovered, mechanisms SHOULD be provided to 969 configure such information on a server and to use that information 970 during a connection attempt for validation. 972 S-PEs that connect one provider domain to another provider domain 973 MUST have the capability to rate-limit signaling traffic in order to 974 prevent DoS attacks on the control plane. Furthermore, detection and 975 disposition of malformed packets and defense against various forms of 976 attacks that can be protocol-specific MUST be provided. 978 9. Full Copyright Statement 980 Copyright (C) The Internet Society (2006). 982 This document is subject to the rights, licenses and restrictions 983 contained in BCP 78, and except as set forth therein, the authors 984 retain all their rights. 986 This document and the information contained herein are provided on an 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 988 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 989 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 990 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 991 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 10. Intellectual Property Statement 996 The IETF takes no position regarding the validity or scope of any 997 Intellectual Property Rights or other rights that might be claimed to 998 pertain to the implementation or use of the technology described in 999 this document or the extent to which any license under such rights 1000 might or might not be available; nor does it represent that it has 1001 made any independent effort to identify any such rights. Information 1002 on the procedures with respect to rights in RFC documents can be 1003 found in BCP 78 and BCP 79. 1005 Copies of IPR disclosures made to the IETF Secretariat and any 1006 assurances of licenses to be made available, or the result of an 1007 attempt made to obtain a general license or permission for the use of 1008 such proprietary rights by implementers or users of this 1009 specification can be obtained from the IETF on-line IPR repository at 1010 http://www.ietf.org/ipr. 1012 The IETF invites any interested party to bring to its attention any 1013 copyrights, patents or patent applications, or other proprietary 1014 rights that may cover technology that may be required to implement 1015 this standard. Please address the information to the IETF at ietf- 1016 ipr@ietf.org. 1018 11. IANA Considerations 1020 This document has no IANA Actions. 1022 12. Normative References 1024 [RFC3916] "Requirements for Pseudo-Wire Emulation Edge-to-Edge 1025 (PWE3)", X. Xiao, D. McPherson, P. Pate, September 2004 1027 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., RFC3985. 1029 13. Informative References 1031 [ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for 1032 Frame Mode Basic call control, ITU Geneva 1995 1034 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1035 Verification (VCCV)", Internet Draft 1036 , October 2006. (work in progress) 1038 [RFC4447] L. Martini, Ed, et al., "Pseudowire Setup and 1039 Maintenance Using the Label Distribution Protocol (LDP)", 1040 RFC4447, April 2006 1042 [RFC4111] "Security Framework for 1043 Provider-Provisioned Virtual Private Networks (PPVPNs)," 1044 Fang. L., et al., RFC 4111, July 2005 1046 [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., 1047 draft-ietf-pwe3-oam-msg-map-02.txt (work in progress), 1048 February 2005 1050 14. Author Information 1052 Nabil Bitar 1053 Verizon 1054 40 Sylvan Road 1055 Waltham, MA 02145 1056 e-mail: nabil.bitar@verizon.com 1058 Matthew Bocci 1059 Alcatel Telecom Ltd, 1060 Voyager Place 1061 Shoppenhangers Road 1062 Maidenhead 1063 Berks, UK 1064 e-mail: matthew.bocci@alcatel.co.uk 1066 Luca Martini 1067 Cisco Systems, Inc. 1068 9155 East Nichols Avenue, Suite 400 1069 Englewood, CO, 80112 1070 e-mail: lmartini@cisco.com