idnits 2.17.1 draft-ietf-pwe3-ms-pw-arch-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (July 30, 2009) is 5376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-09 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M.Bocci 2 Internet Draft Alcatel-Lucent 4 S.Bryant 5 Cisco Systems 7 Intended Status: Informational 8 Expires: January 2010 July 30, 2009 10 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge 12 draft-ietf-pwe3-ms-pw-arch-07.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 30, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document describes an architecture for extending pseudowire 51 emulation across multiple packet switched network segments. Scenarios 52 are discussed where each segment of a given edge-to-edge emulated 53 service spans a different provider's PSN, and where the emulated 54 service originates and terminates on the same provider's PSN, but may 55 pass through several PSN tunnel segments in that PSN. It presents an 56 architectural framework for such multi-segment pseudowires, defines 57 terminology, and specifies the various protocol elements and their 58 functions. 60 Table of Contents 62 1. Introduction................................................3 63 1.1. Motivation and Context..................................3 64 1.2. Non-Goals of this Document..............................6 65 1.3. Terminology............................................7 66 2. Applicability...............................................8 67 3. Protocol Layering model......................................9 68 3.1. Domain of MS-PW Solutions...............................9 69 3.2. Payload Types..........................................9 70 4. Multi-Segment Pseudowire Reference Model....................10 71 4.1. Intra-Provider Connectivity Architecture...............11 72 4.1.1. Intra-Provider Switching Using ACs................11 73 4.1.2. Intra-Provider Switching Using PWs................12 74 4.2. Inter-Provider Connectivity Architecture...............12 75 4.2.1. Inter-Provider Switching Using ACs................12 76 4.2.2. Inter-Provider Switching Using PWs................12 77 5. PE Reference Model.........................................13 78 5.1. Pseudowire Pre-processing..............................13 79 5.1.1. Forwarding........................................13 80 5.1.2. Native Service Processing.........................14 81 6. Protocol Stack reference Model..............................14 82 7. Maintenance Reference Model.................................15 83 8. PW Demultiplexer Layer and PSN Requirements.................16 84 8.1. Multiplexing..........................................16 85 8.2. Fragmentation.........................................17 86 9. Control Plane..............................................17 87 9.1. Setup and Placement of MS-PWs..........................17 88 9.2. Pseudowire Up/Down Notification........................18 89 9.3. Misconnection and Payload Type Mismatch................18 90 10. Management and Monitoring..................................18 91 11. Congestion Considerations..................................19 92 12. IANA Considerations........................................20 93 13. Security Considerations....................................20 94 14. Acknowledgments...........................................23 95 15. References................................................24 96 15.1. Normative References..................................24 97 15.2. Informative References................................24 98 Author's Addresses............................................24 99 Acknowledgment................................................25 101 1. Introduction 103 RFC 3985 [1] defines the architecture for pseudowires, where a 104 pseudowire (PW) both originates and terminates on the edge of the 105 same packet switched network (PSN). The PW label is unchanged between 106 the originating and terminating PEs. This is now known as a single- 107 segment pseudowire (SS-PW). 109 This document extends the architecture in RFC 3985 to enable point to 110 point pseudowires to be extended through multiple PSN tunnels. These 111 are known as multi-segment pseudowires (MS-PWs). Use cases for multi- 112 segment pseudowires (MS-PWs), and the consequent requirements, are 113 defined in RFC 5254 [5]. 115 1.1. Motivation and Context 117 RFC 3985 addresses the case where a PW spans a single segment between 118 two PEs. Such PWs are termed single-segment pseudowires (SS-PWs) and 119 provide point-to-point connectivity between two edges of a provider 120 network. However, there is now a requirement to be able to construct 121 multi-segment pseudowires. These requirements are specified in RFC 122 5254 [5], and address three main problems: 124 i. How to constrain the density of the mesh of PSN tunnels when 125 the number of PEs grows to many hundreds or thousands, while 126 minimizing the complexity of the PEs and P routers. 128 ii. How to provide PWs across multiple PSN routing domains or areas 129 in the same provider. 131 iii. How to provide PWs across multiple provider domains, and 132 different PSN types. 134 Consider a single PW domain, such as that shown in Figure 1. There 135 are 4 PEs, and PWs must be provided from any PE to any other PE. PWs 136 can be supported by establishing a full mesh of PSN tunnels between 137 the PEs, requiring a full mesh of LDP signaling adjacencies between 138 the PEs. PWs can therefore be established between any PE and any 139 other PE via a single, direct PSN tunnel that is switched only by 140 intermediate P-routers (not shown in the figure). In this case, each 141 PW is a SS-PW. A PE must terminate all the pseudowires that are 142 carried on the PSN tunnels that terminate on that PE according to the 143 architecture of RFC 3985. This solution is adequate for small numbers 144 of PEs, but the number of PEs, PSN tunnels and signaling adjacencies 145 will grow in proportion to the square of the number of PEs. 147 For reasons of economy, the edge PEs that terminate the attachment 148 circuits (AC) are often small devices built to very low cost with 149 limited processing power. Consider an example where a particular PE, 150 residing at the edge of a provider network, terminates N PWs to/from 151 N different remote PEs. This needs N PW signaling adjacencies to be 152 set-up and maintained. If the edge PE attaches to a single 153 intermediate PE that is able to switch the PW, that edge PE only 154 needs a single adjacency to signal and maintain all N PWs. The 155 intermediate switching PE (which is a larger device) needs M 156 signaling adjacencies, but statistically this is less than tN where t 157 is the number of edge PEs that it is serving. Similarly, if the PWs 158 are running over TE PSN tunnels, there is a statistical reduction in 159 the number of TE PSN tunnels that need to be set up and maintained 160 between the various PEs. 162 One possible solution that is more efficient for large numbers of 163 PEs, in particular for the control plane, is therefore to support a 164 partial mesh of PSN tunnels between the PEs, as shown in Figure 1. 165 For example, consider a PW service whose endpoints are PE1 and PE4. 166 Pseudowires for this can take the path PE1->PE2->PE4, and rather than 167 terminating at PE2, be switched between ingress and egress PSN 168 tunnels on that PE. This requires a capability in PE2 that can 169 concatenate PW segments PE1-PE2 to PW segments PE2-PE4. The end-to- 170 end PW is known as a multi-segment PW. 172 ,,..--..,,_ 173 .-`` `'., 174 +-----+` '+-----+ 175 | PE1 |---------------------| PE2 | 176 | |---------------------| | 177 +-----+ PSN Tunnel +-----+ 178 / || || \ 179 / || || \ 180 | || || | 181 | || PSN || | 182 | || || | 183 \ || || / 184 \ || || / 185 \|| ||/ 186 +-----+ +-----+ 187 | PE3 |---------------------| PE4 | 188 | |---------------------| | 189 +-----+`'.,_ ,.'` +-----+ 190 `'''---''`` 191 Figure 1 PWs Spanning a Single PSN with Partial Mesh of PSN Tunnels 193 Figure 1 shows a simple flat PSN topology. However, large provider 194 networks are typically not flat, consisting of many domains that are 195 connected together to provide edge-to-edge services. The elements in 196 each domain are specialized for a particular role, for example 197 supporting different PSN types or using different routing protocols. 199 An example application is shown in Figure 2. Here, the provider's 200 network is divided into three domains: Two access domains and the 201 core domain. The access domains represent the edge of the provider's 202 network at which services are delivered. In the access domain, 203 simplicity is required in order to minimize the cost of the network. 204 The core domain must support all of the aggregated services from the 205 access domains, and the design requirements here are for scalability, 206 performance, and information hiding (i.e. minimal state). The core 207 must not be exposed to the state associated with large numbers of 208 individual edge-to-edge flows. That is, the core must be simple and 209 fast. 211 In a traditional layer 2 network, the interconnection points between 212 the domains are where services in the access domains are aggregated 213 for transport across the core to other access domains. In an IP 214 network, the interconnection points could also represent interworking 215 points between different types of IP networks e.g. those with MPLS 216 and those without, and also points where network policies can be 217 applied. 219 <-------- Edge to Edge Emulated Services -------> 221 ,' . ,-` `', ,' . 222 / \ .` `, / \ 223 / \ / , / \ 224 AC +----+ +----+ +----+ +----+ AC 225 ---| PE |-----| PE |---------------| PE |-------| PE |--- 226 | 1 | | 2 | | 3 | | 4 | 227 +----+ +----+ +----+ +----+ 228 \ / \ / \ / 229 \ / \ Core ` \ / 230 `, ` . ,` `, ` 231 '-'` `., _.` '-'` 232 Access 1 `''-''` Access 2 234 Figure 2 Multi-Domain Network Model 236 A similar model can also be applied to inter-provider services, where 237 a single PW spans a number of separate provider networks in order to 238 connect ACs residing on PEs in disparate provider networks. In this 239 case, each provider will typically maintain their own PE at the 240 border of their network in order to apply policies such as security 241 and QoS to PWs entering their network. Thus, the connection between 242 the domains will normally be a link between two PEs on the border of 243 each provider's network. 245 Consider the application of this model to PWs. PWs use tunneling 246 mechanisms such as MPLS to enable the underlying PSN to emulate 247 characteristics of the native service. One solution to the multi- 248 domain network model above is to extend PSN tunnels edge-to-edge 249 between all of the PEs in access domain 1 and all of the PEs in 250 access domain 2, but this requires a large number of PSN tunnels as 251 described above, and also exposes the access and the core of the 252 network to undesirable complexity. An alternative is to constrain the 253 complexity to the network domain interconnection points (PE2 and PE3 254 in the example above). Pseudowires between PE1 and PE4 would then be 255 switched between PSN tunnels at the interconnection points, enabling 256 PWs from many PEs in the access domains to be aggregated across only 257 a few PSN tunnels in the core of the network. PEs in the access 258 domains would only need to maintain direct signaling sessions, and 259 PSN tunnels, with other PEs in their own domain, thus minimizing 260 complexity of the access domains. 262 1.2. Non-Goals of this Document 264 The following are non-goals for this document: 266 o The on-the-wire specification of PW encapsulations 268 o The detailed specification of mechanisms for establishing and 269 maintaining multi-segment pseudo-wires. 271 1.3. Terminology 273 The terminology specified in RFC 3985 [1] and RFC 4026 [2] applies. 274 In addition, we define the following terms: 276 o PW Terminating Provider Edge (T-PE). A PE where the customer- 277 facing attachment circuits (ACs) are bound to a PW forwarder. A 278 Terminating PE is present in the first and last segments of a MS- 279 PW. This incorporates the functionality of a PE as defined in RFC 280 3985. 282 o Single-Segment Pseudowire (SS-PW). A PW setup directly between two 283 T-PE devices. The PW label is unchanged between the originating 284 and terminating T-PEs. 286 o Multi-Segment Pseudowire (MS-PW). A static or dynamically 287 configured set of two or more contiguous PW segments that behave 288 and function as a single point-to-point PW. Each end of a MS-PW by 289 definition terminates on a T-PE. 291 o PW Segment. A part of a single-segment or multi-segment PW, which 292 traverses one PSN tunnel in each direction between two PE devices, 293 T-PEs and/or S-PEs. 295 o PW Switching Provider Edge (S-PE). A PE capable of switching the 296 control and data planes of the preceding and succeeding PW 297 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 298 preceding and succeeding segments of the MS-PW. It therefore 299 includes a PW switching point for a MS-PW. A PW Switching Point is 300 never the S-PE and the T-PE for the same MS-PW. A PW switching 301 point runs necessary protocols to setup and manage PW segments 302 with other PW switching points and terminating PEs. A S-PE can 303 exist anywhere where a PW must be processed or policy applied. It 304 is therefore not limited to the edge of a provider network. 306 Note that it was originally anticipated that S-PEs would only be 307 deployed at the edge of a provider network where there would be 308 used to switch the PWs of different service providers. However as 309 the design of MS-PW progressed other applications for MS-PW were 310 recognized. By this time S-PE had become the accepted term for the 311 equipment even though they were no longer universally deployed at 312 the provider edge. 314 o PW Switching. The process of switching the control and data planes 315 of the preceding and succeeding PW segments in a MS-PW. 317 o PW Switching Point. The reference point in an S-PE where the 318 switching takes place, e.g. where PW label swap is executed. 320 o Eligible S-PE or T-PE. An Eligible S-PE or T-PE is a PE that meets 321 the security and privacy requirements of the MS-PW, according to 322 the network operator's policy. 324 o Trusted S-PE or T-PE. A trusted S-PE or T-PE is a PE that is 325 understood to be eligible by its next hop S-PE or T-PE, while a 326 trust relationship exists between two S-PEs or T-PEs if they 327 mutually consider each other to be eligible. 329 2. Applicability 331 A MS-PW is a single PW that for technical or administrative reasons 332 is segmented into a number of concatenated hops. From the perspective 333 of a L2VPN, a MS-PW is indistinguishable from a SS-PW. Thus, the 334 following are equivalent from the perspective of the T-PE 336 +----+ +----+ 337 |TPE1+--------------------------------------------------+TPE2| 338 +----+ +----+ 340 |<---------------------------PW----------------------------->| 342 +----+ +---+ +---+ +----+ 343 |TPE1+--------------+SPE+-----------+SPE+---------------+TPE2| 344 +----+ +---+ +---+ +----+ 346 Figure 3 MS-PW Equivalence 348 Although a MS-PW may require services such as node discovery and path 349 signaling to construct the PW, it should not be confused with a L2VPN 350 system, which also requires these services. A VPWS connects its 351 endpoints via a set of PWs. MS-PW is a mechanism that abstracts the 352 construction of complex PWs from the construction of a L2VPN. Thus a 353 T-PE might be an edge device optimized for simplicity and an S-PE 354 might be an aggregation device designed to absorb the complexity of 355 continuing the PW across the core of one or more service provider 356 networks to another T-PE located at the edge of the network. 358 As well as supporting traditional L2VPNs, an MS-PW is applicable to 359 providing connectivity across a transport network based on packet 360 switching technology e.g. MPLS Transport profile (MPLS-TP) [6], [8]. 361 Such a network uses pseudowires to support the transport and 362 aggregation of all services. This application requires deterministic 363 characteristics and behavior from the network. The operational 364 requirements of such networks may need pseudowire segments that can 365 be established and maintained in the absence of a control plane, and 366 the operational independence of PW maintenance from the underlying 367 PSN. 369 3. Protocol Layering model 371 The protocol-layering model specified in RFC 3985 applies to MS-PWs 372 with the following clarification: the pseudowires may be considered 373 to be a separate layer to the PSN tunnel. That is, although a PW 374 segment will follow the path of the PSN tunnel between S-PEs, the MS- 375 PW is independent of the PSN tunnel routing, operations, signaling 376 and maintenance. The design of PW routing domains should not imply 377 that the underlying PSN routing domains are the same. However, MS-PWs 378 will reuse the protocols of the PSN and may, if applicable, use 379 information that is extracted from the PSN e.g. reachability. 381 3.1. Domain of MS-PW Solutions 383 PWs provide the Encapsulation Layer, i.e. the method of carrying 384 various payload types, and the interface to the PW Demultiplexer 385 Layer. Other layers provide the following: 387 . PSN tunnel setup, maintenance and routing 389 . T-PE discovery 391 Not all PEs may be capable of providing S-PE functionality. 392 Connectivity to the next hop S-PE or T-PE must be provided by a PSN 393 tunnel, according to [1]. The selection of which set of S-PEs to use 394 to reach a given T-PE is considered to be within the scope of MS-PW 395 solutions. 397 3.2. Payload Types 399 MS-PWs are applicable to all PW payload types. Encapsulations defined 400 for SS-PWs are also used for MS-PW without change. Where the PSN 401 types for each segment of an MS-PW are identical, the PW types of 402 each segment must also be identical. However, if different segments 403 run over different PSN types, the encapsulation may change but the PW 404 segments must be of an equivalent PW type i.e. the S-PE must not need 405 to process the PW payload to provide translation. 407 4. Multi-Segment Pseudowire Reference Model 409 The PWE3 reference architecture for the single segment case is shown 410 in [1]. This architecture applies to the case where a PSN tunnel 411 extends between two edges of a single PSN domain to transport a PW 412 with endpoints at these edges. 414 Native |<------Multi-Segment Pseudowire------>| Native 415 Service | PSN PSN | Service 416 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 417 | V V 1 V V 2 V V | 418 | +----+ +-----+ +----+ | 419 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 420 | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| | 421 | CE1| | | | | | | | | |CE2 | 422 | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| | 423 +----+ | | |===========| |==========| | | +----+ 424 ^ +----+ +-----+ +----+ ^ 425 | Provider Edge 1 ^ Provider Edge 2 | 426 | | | 427 | | | 428 | PW switching point | 429 | | 430 |<------------------ Emulated Service --------------->| 432 Figure 4 MS-PW Reference Model 434 Figure 4 extends this architecture to show a multi-segment case. The 435 PEs that provide services to CE1 and CE2 are Terminating-PE1 (T-PE1) 436 and Terminating-PE2 (T-PE2) respectively. A PSN tunnel extends from 437 T-PE1 to switching-PE1 (S-PE1) across PSN1, and a second PSN tunnel 438 extends from S-PE1 to T-PE2 across PSN2. PWs are used to connect the 439 attachment circuits (ACs) attached to PE1 to the corresponding ACs 440 attached to T-PE2. 442 Each PW segment on the tunnel across PSN1 is switched to a PW segment 443 in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW 444 (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching 445 point. PW segment 1 and PW segment 3 are segments of the same MS-PW 446 while PW segment 2 and PW segment 4 are segments of another MS-PW. PW 447 segments of the same MS-PW (e.g., PW segment 1 and PW segment 3) must 448 be of equivalent PW types, as described in Section 3.2. above, while 449 PSN tunnels (e.g., PSN1 and PSN2) may be of the same or different PSN 450 types. An S-PE switches an MS-PW from one segment to another based on 451 the PW demultiplexer, i.e., PW label that may take one of the forms 452 defined in RFC3985 Section 5.4.1 [1]. 454 Note that although Figure 4 only shows a single S-PE, a PW may 455 transit more one S-PE along its path. This architecture is applicable 456 when the S-PEs are statically chosen, or when they are chosen using a 457 dynamic path selection mechanism. Both directions of an MS-PW must 458 traverse the same set of S-PEs on a reciprocal path. Note that 459 although the S-PE path is therefore reciprocal, the path taken by the 460 PSN tunnels between the T-PEs and S-PEs might not be reciprocal due 461 to choices made by the PSN routing protocol. 463 4.1. Intra-Provider Connectivity Architecture 465 There is a requirement to deploy PWs edge-to-edge in large service 466 provider networks (RFC 5254 [5]). Such networks typically encompass 467 hundreds or thousands of aggregation devices at the edge, each of 468 which would be a PE. These networks may be partitioned into separate 469 metro and core PW domains, where the PEs are interconnected by a 470 sparse mesh of tunnels. 472 Whether or not the network is partitioned into separate PW domains, 473 there is also a requirement to support a partial mesh of traffic 474 engineered PSN tunnels. 476 The architecture shown in Figure 4 can be used to support such cases. 477 PSN1 and PSN2 may be in different administrative domains or access, 478 core or metro regions within the same provider's network. PSN 1 and 479 PSN2 may also be of different types. For example, S-PEs may be used 480 to connect PW segments traversing metro networks of one technology 481 e.g. statically allocated labels, with segments traversing a MPLS 482 core network. 484 Alternatively, T-PE1, S-PE1 and T-PE2 may reside at the edges of the 485 same PSN. 487 4.1.1. Intra-Provider Switching Using ACs 489 In this model, the PW reverts to the native service AC at the domain 490 boundary PE. This AC is then connected to a separate PW on the same 491 PE. In this case, the reference models of RFC 3985 apply to each 492 segment and to the PEs. The remaining PE architectural considerations 493 in this document do not apply to this case. 495 4.1.2. Intra-Provider Switching Using PWs 497 In this model, PW segments are switched between PSN tunnels that span 498 portions of a provider's network, without reverting to the native 499 service at the boundary. For example, in Figure 4, PSN 1 and PSN 2 500 would be portions of the same provider's network. 502 4.2. Inter-Provider Connectivity Architecture 504 Inter-provider PWs may need to be switched between PSN tunnels at the 505 provider boundary in order to minimize the number of tunnels required 506 to provide PW-based services to CEs attached to each provider's 507 network. In addition, the following may need to be implemented on a 508 per-PW basis at the provider boundary: 510 . Operations and Management (OAM), 512 . Authentication, Authorization and Accounting (AAA), 514 . Security mechanisms. 516 Further security related architectural considerations are described 517 in Section 13. 519 4.2.1. Inter-Provider Switching Using ACs. 521 In this model, the PW reverts to the native service at the provider 522 boundary PE. This AC is then connected to a separate PW at the peer 523 provider boundary PE. In this case, the reference models of RFC 3985 524 apply to each segment and to the PEs. This is similar to the case in 525 Section 4.1.1. , except that additional security and policy 526 enforcement measures will be required. The remaining PE architectural 527 considerations in this document do not apply to this case. 529 4.2.2. Inter-Provider Switching Using PWs. 531 In this model, PW segments are switched between PSN tunnels in each 532 provider's network, without reverting to the native service at the 533 boundary. This architecture is shown in Figure 5. Here, S-PE1 and S- 534 PE2 are provider border routers. PW segment 1 is switched to PW 535 segment 2 at S-PE1. PW segment 2 is then carried across an inter- 536 provider PSN tunnel to S-PE2, where it is switched to PW segment 3 in 537 PSN 2. 539 |<------Multi-Segment Pseudowire------>| 540 | Provider Provider | 541 AC | |<----1---->| |<----2--->| | AC 542 | V V V V V V | 543 | +----+ +-----+ +----+ +----+ | 544 +----+ | | |=====| |=====| |=====| | | +----+ 545 | |-------|......PW.....X....PW.....X...PW.......|-------| | 546 | CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2 | 547 +----+ | | | | | | | | | | +----+ 548 ^ +----+ +-----+ +----+ +----+ ^ 549 | T-PE1 S-PE1 S-PE2 T-PE2 | 550 | ^ ^ | 551 | | | | 552 | PW switching points | 553 | | 554 | | 555 |<------------------- Emulated Service --------------->| 557 Figure 5 Inter-Provider Reference Model 559 5. PE Reference Model 561 5.1. Pseudowire Pre-processing 563 Pseudowire preprocessing is applied in the T-PEs as specified in RFC 564 3985. Processing at the S-PEs is specified in the following sections. 566 5.1.1. Forwarding 568 Each forwarder in the S-PE forwards packets from one PW segment on 569 the ingress PSN facing interface of the S-PE to one PW segment on the 570 egress PSN facing interface of the S-PE. 572 The forwarder selects the egress segment PW based on the ingress PW 573 label. The mapping of ingress to egress PW label may be statically or 574 dynamically configured. Figure 6 shows how a single forwarder is 575 associated with each PW segment at the S-PE. 577 +------------------------------------------+ 578 | S-PE Device | 579 +------------------------------------------+ 580 Ingress | | | | Egress 581 PW instance | Single | | Single | PW Instance 582 <==========>X PW Instance + Forwarder + PW Instance X<==========> 583 | | | | 584 +------------------------------------------+ 586 Figure 6 Point-to-Point Service 588 Other mappings of PW to forwarder are for further study. 590 5.1.2. Native Service Processing 592 There is no native service processing in the S-PEs. 594 6. Protocol Stack reference Model 596 Figure 7 illustrates the protocol stack reference model for multi- 597 segment PWs. 599 +----------------+ +----------------+ 600 |Emulated Service| |Emulated Service| 601 |(e.g., TDM, ATM)|<======= Emulated Service =======>|(e.g., TDM, ATM)| 602 +----------------+ +----------------+ 603 | Payload | | Payload | 604 | Encapsulation |<=== Multi-segment Pseudowire ===>| Encapsulation | 605 +----------------+ +--------+ +----------------+ 606 |PW Demultiplexer||PW Demux||PW Demultiplexer| 607 +----------------+ +--------+ +----------------+ 608 | PSN Tunnel, || PSN || PSN Tunnel, | 609 | PSN & Physical | |Physical| | PSN & Physical | 610 | Layers | | Layers | | Layers | 611 +-------+--------+ +--------+ +----------------+ 612 | .......... | .......... | 613 | / \ | / \ | 614 +==========/ PSN \===/ PSN \==========+ 615 \ domain 1 / \ domain 2 / 616 \__________/ \__________/ 617 `````````` `````````` 619 Figure 7 Multi-Segment PW Protocol Stack 621 The MS-PW provides the CE with an emulated physical or virtual 622 connection to its peer at the far end. Native service PDUs from the 623 CE are passed through an Encapsulation Layer and a PW demultiplexer 624 is added at the sending T-PE. The PDU is sent over PSN domain via the 625 PSN transport tunnel. The receiving S-PE swaps the existing PW 626 demultiplexer for the demultiplexer of the next segment, and then 627 sends the PDU over transport tunnel in PSN2. Where the ingress and 628 egress PSN domains of the S-PE are of the same type e.g. they are 629 both MPLS PSNs, a simple label swap operation is performed, as 630 described in RFC 3031 [3] Section 3.13. However, where the ingress 631 and egress PSNs are of different types, e.g. MPLS and L2TPv3, the 632 ingress PW demultiplexer is removed (or popped), a mapping to the 633 egress PW demultiplexer is performed, and then inserted (or pushed). 635 Policies may also be applied to the PW at this point. Examples of 636 such policies include: admission control, rate control, QoS mappings, 637 and security. The receiving T-PE removes the PW demultiplexer and 638 restores the payload to its native format for transmission to the 639 destination CE. 641 Where the encapsulation format is different e.g. MPLS and L2TPv3, the 642 payload encapsulation may be translated at the S-PE. 644 7. Maintenance Reference Model 646 Figure 8 shows the maintenance reference model for multi-segment 647 pseudowires. 649 |<------------- CE (end-to-end) Signaling ------------>| 650 | | 651 | |<-------- MS-PW/T-PE Maintenance ----->| | 652 | | |<---PW Seg't-->| |<--PW Seg't--->| | | 653 | | | Maintenance | | Maintenance | | | 654 | | | | | | | | 655 | | | PSN | | PSN | | | 656 | | | |<-Tunnel1->| | | |<-Tunnel2->| | | | 657 | V V V Signaling V V V V Signaling V V V | 658 V +----+ +-----+ +----+ V 659 +----+ |TPE1|===========|SPE1 |===========|TPE2| +----+ 660 | |-------|......PW.Seg't1....X....PW Seg't3......|------| | 661 | CE1| | | | | | | |CE2 | 662 | |-------|......PW.Seg't2....X....PW Seg't4......|------| | 663 +----+ | |===========| |===========| | +----+ 664 ^ +----+ +-----+ +----+ ^ 665 | Terminating ^ Terminating | 666 | Provider Edge 1 | Provider Edge 2 | 667 | | | 668 | PW switching point | 669 | | 670 |<--------------------- Emulated Service ------------------->| 672 Figure 8 MS-PW Maintenance Reference Model 674 RFC 3985 specifies the use of CE (end-to-end) and PSN tunnel 675 signaling, and PW/PE maintenance. CE and PSN tunnel signaling is as 676 specified in RFC 3985. However, in the case of MS-PWs, signaling 677 between the PEs now has both an edge-to-edge and a hop-by-hop 678 context. That is, signaling and maintenance between T-PEs and S-PEs 679 and between adjacent S-PEs is used to set up, maintain, and tear down 680 the MS-PW segments, which include the coordination of parameters 681 related to each switching point, as well as the MS-PW end points. 683 8. PW Demultiplexer Layer and PSN Requirements 685 8.1. Multiplexing 687 The purpose of the PW demultiplexer layer at the S-PE is to 688 demultiplex PWs from ingress PSN tunnels and to multiplex them into 689 egress PSN tunnels. Although each PW may contain multiple native 690 service circuits, e.g. multiple ATM VCs, the S-PEs do not have 691 visibility of, and hence do not change, this level of multiplexing 692 because they contain no Native Service Processor (NSP). 694 8.2. Fragmentation 696 If fragmentation is to be used in an MS-PW, T-PEs and S-PEs must 697 satisfy themselves that fragmented PW payloads can be correctly 698 reassembled for delivery to the destination attachment circuit. 700 An S-PE is not required to make any attempt to reassemble a 701 fragmented PW payload. However, it may choose to do so if, for 702 example, it knows that a downstream PW segment does not support 703 reassembly. 705 An S-PE may fragment a PW payload using [4]. 707 9. Control Plane 709 9.1. Setup and Placement of MS-PWs 711 For multi-segment pseudowires, the intermediate PW switching points 712 may be statically provisioned, or they may be chosen dynamically. 714 For the static case, there are two options for exchanging the PW 715 labels: 717 o By configuration at the T-PEs or S-PEs 719 o By signaling across each segment using a dynamic maintenance 720 protocol. 722 A multi-segment pseudowire may thus consist of segments where the 723 labels are statically configured and segments where the labels are 724 signaled. 726 For the case of dynamic choice of the PW switching points, there are 727 two options for selecting the path of the MS-PW: 729 o T-PEs determine the full path of the PW through intermediate 730 switching points. This may be either static or based on a dynamic 731 PW path selection mechanism. 733 o Each T-PE and S-PE makes a local decision as to which next-hop S- 734 PE to choose to reach the target T-PE. This choice is made either 735 using locally configured information, or by using a dynamic PW 736 path selection mechanism. 738 9.2. Pseudowire Up/Down Notification 740 Since a multi-segment PW consists of a number of concatenated PW 741 segments, the emulated service can only be considered as being up 742 when all of the constituting PW segments and PSN tunnels are 743 functional and operational along the entire path of the MS-PW. 745 If a native service requires bi-directional connectivity, the 746 corresponding emulated service can only be signaled as being 747 operational up when the PW segments and PSN tunnels (if used), are 748 functional and operational in both directions. 750 RFC 3985 describes the architecture of failure and other status 751 notification mechanisms for PWs. These mechanisms are also needed in 752 multi-segment pseudowires. In addition, if a failure notification 753 mechanism is provided for consecutive segments of the same PW, the S- 754 PE must propagate such notifications between the consecutive 755 concatenated segments. 757 9.3. Misconnection and Payload Type Mismatch 759 Misconnection and payload type mismatch can occur with PWs. 760 Misconnection can breach the integrity of the system. Payload 761 mismatch can disrupt the customer network. In both instances, there 762 are security and operational concerns. 764 The services of the underlying tunneling mechanism or the PW control 765 and OAM protocols can be used to ensure that the identity of the PW 766 next hop is as expected. As part of the PW setup, a PW-TYPE 767 identifier is exchanged. This is then used by the forwarder and the 768 NSP of the T-PEs to verify the compatibility of the ACs. This can 769 also be used by S-PEs to ensure that concatenated segments of a given 770 MS-PW are compatible, or that a MS-PW is not misconnected into a 771 local AC. In addition, it is possible to perform an end-to-end 772 connection verification to check the integrity of the PW, to verify 773 the identity of S-PEs and check the correct connectivity at S-PEs, 774 and to verify the identity of the T-PE. 776 10. Management and Monitoring 778 The management and monitoring as described in RFC 3985 applies here. 780 The MS-PW architecture introduces additional considerations related 781 to management and monitoring, which need to be reflected in the 782 design of maintenance tools and additional management objects for MS- 783 PWs. 785 The first is that each S-PE is a new point at which defects may occur 786 along the path of the PW. In order to troubleshoot MS-PWs, management 787 and monitoring should be able to operate on a subset of the segments 788 of an MS-PW, as well as edge-to-edge. That is, connectivity 789 verification mechanisms should be able to troubleshoot and 790 differentiate the connectivity between T-PEs and intermediate S-PEs, 791 as well as T-PE to T-PE. 793 The second is that the set of S-PEs and P-routers along the MS-PW 794 path may be less optimal than a path between the T-PEs chosen solely 795 by the underlying PSN routing protocols. This is because the S-PEs 796 are chosen by the MS-PW path selection mechanism and not by the PSN 797 routing protocols. Troubleshooting mechanisms should therefore be 798 provided to verify the set of S-PEs that are traversed by a MS-PW to 799 reach a T-PE. 801 Some of the S-PEs and the T-PEs for an MS-PW may reside in different 802 service provider's PSN domain from that of the operator who initiated 803 the establishment of the MS-PW. These situations may necessitate the 804 use of remote management of the MS-PW, which is able to securely 805 operate across provider boundaries. 807 11. Congestion Considerations 809 The following congestion considerations apply to MS-PWs. These are in 810 addition to the considerations for PWs described in RFC 3985 [1], [7] 811 and in the respective RFCs specifying each PW type. 813 The control plane and the data plane fate-share in traditional IP 814 networks. The implication of this is that congestion in the data 815 plane can cause degradation of the operation of the control plane. 816 Under quiescent operating conditions it is expected that the network 817 will be designed to avoid such problems. However, MS-PW mechanisms 818 should also consider what happens when congestion does occur, when 819 the network is stretched beyond its design limits, for example during 820 unexpected network failure conditions. 822 Although congestion within a single provider's network can be 823 mitigated by suitable engineering of the network so that the traffic 824 imposed by PWs can never cause congestion in the underlying PSN, a 825 significant number of MS-PWs are expected to be deployed for inter- 826 provider services. In this case, there may be no way of a provider 827 who initiates the establishment of a MS-PW at a T-PE guaranteeing 828 that it will not cause congestion in a downstream PSN. A specific PSN 829 may be able to protect itself from excess PW traffic by policing all 830 PWs at the S-PE at the provider border. However, this may not be 831 effective when the PSN tunnel across a provider utilizes the transit 832 services of another provider that cannot distinguish PW traffic from 833 ordinary, TCP-controlled, IP traffic. 835 Each segment of an MS-PW therefore needs to implement congestion 836 detection and congestion control mechanisms where it is not possible 837 to explicitly provision sufficient capacity to avoid congestion. 839 In many cases, only the T-PEs may have sufficient information about 840 each PW to fairly apply congestion control. Therefore, T-PEs need to 841 be aware which of their PWs are causing congestion in a downstream 842 PSN and their native service characteristics and to apply congestion 843 control accordingly. S-PEs therefore need to propagate PSN congestion 844 state information between their downstream and upstream directions. 845 If the MS-PW transits many S-PEs, it may take some time for 846 congestion state information to propagate from the congested PSN 847 segment to the source T-PE, thus delaying the application of 848 congestion control. Congestion control in the S-PE at the border of 849 the congested PSN can enable a more rapid response and thus 850 potentially reduce the duration of congestion. 852 In addition to protecting the operation of the underlying PSN, 853 consistent QoS and traffic engineering mechanisms should be used on 854 each segment of a MS-PW to support the requirements of the emulated 855 service. The QoS treatment given to a PW packet at an S-PE may be 856 derived from context information of the PW (e.g. traffic or QoS 857 parameters signaled to the S-PE by an MS-PW control protocol), or 858 from PSN-specific QoS flags in the PSN tunnel label or PW 859 demultiplexer e.g. TC bits in either the LSP or PW label for an MPLS 860 PSN or the DS field of the outer IP header for L2TPv3. 862 12. IANA Considerations 864 This document does not contain any IANA actions. 866 13. Security Considerations 868 The security considerations described in RFC 3985 [1] apply here. 870 Detailed security requirements for MS-PWs are specified in RFC 5254 871 [5]. This section describes the architectural implications of those 872 requirements. 874 The security implications for T-PEs are similar to those for PEs in 875 single segment pseudowires. However, S-PEs represent a point in the 876 network where the PW label is exposed to additional processing. An 877 S-PE or T-PE must trust that the context of the MS-PW is maintained 878 by a downstream S-PE. OAM tools must be able to verify the identity 879 of the far end T-PE to the satisfaction of the network operator. 880 Additional consideration needs to be given to the security of the S- 881 PEs, both at the data plane and the control plane, particularly when 882 these are dynamically selected and/or when the MS-PW transits the 883 networks of multiple operators. 885 An implicit trust relationship exists between the initiator of an MS- 886 PW, the T-PEs, and the S-PEs along the MS-PW's path. That is, the T- 887 PE trusts the S-PEs to process and switch PWs without compromising 888 the security or privacy of the PW service. An S-PE should not select 889 a next-hop S-PE or T-PE unless it knows it would be considered 890 eligible, as defined in Section 1.3. above, by the originator of the 891 MS-PW. For dynamically placed MS-PWs, this can be achieved by 892 allowing the T-PE to explicitly specify the path of the MS-PW. When 893 the MS-PW is dynamically created by the use of a signaling protocol, 894 an S-PE or T-PE should determine the authenticity of the peer entity 895 from which it receives the request, and its compliance with policy. 897 Where a MS-PW crosses a border between one provider and another 898 provider, the MS-PW segment endpoints (S-PEs or T-PEs), or P-routers 899 for the PSN tunnel, typically reside on the same nodes as the ASBRs 900 interconnecting the two providers. In either case, an S-PE in one 901 provider is connected to a limited number of trusted T-PEs or S-PEs 902 in the other provider. The number of such trusted T-PEs or S-PEs is 903 bounded and not anticipated to create a scaling issue for the control 904 plane authentication mechanisms. 906 Directly interconnecting the S-PEs/T-PEs using a physically secure 907 link, and enabling signaling and routing authentication between the 908 S-PEs/T-PEs, eliminates the possibility of receiving a MS-PW 909 signaling message or packet from an untrusted peer. The S-PEs/T-PEs 910 represent security policy enforcement points for the MS-PW, while the 911 ASBRs represent security policy enforcement points for the provider's 912 PSNs. This architecture is illustrated in Figure 9. 914 |<------------- MS-PW ---------------->| 915 | Provider Provider | 916 AC | |<----1---->| |<----2--->| | AC 917 | V V V V V V | 918 | +----+ +-----+ +----+ +----+ | 919 +---+ | | |=====| |=====| |=====| | | +---+ 920 | |-------|......PW.....X....PW.....X...PW.......|-------| | 921 |CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2| 922 +---+ | | | | | | | | | | +---+ 923 ^ +----+ +-----+ ^ +----+ +----+ ^ 924 | T-PE1 S-PE1 | S-PE2 T-PE2 | 925 | ASBR | ASBR | 926 | | | 927 | Physically secure link | 928 | | 929 | | 930 |<------------------- Emulated Service --------------->| 932 Figure 9 Directly Connected Inter-Provider Reference Model 934 Alternatively, the P-routers for the PSN tunnel may reside on the 935 ASBRs, while the S-PEs or T-PEs reside behind the ASBRs within each 936 provider's network. A limited number of trusted inter-provider PSN 937 tunnels interconnect the provider networks. This is illustrated in 938 Figure 10. 940 |<-------------- MS-PW -------------------->| 941 | Provider Provider | 942 AC | |<------1----->| |<-----2------->| | AC 943 | V V V V V V | 944 | +---+ +---+ +--+ +--+ +---+ +---+ | 945 +---+ | | |=====| |===============| |=====| | | +---+ 946 | |-----|.....PW....X.......PW..............PW....X.|------| | 947 |CE1| | | |Seg 1| | | Seg 2| | |Seg 3| | | |CE2| 948 +---+ | | | | | | | | | | | | | +---+ 949 ^ +---+ +---+ +--+ ^ +--+ +---+ +---+ ^ 950 | T-PE1 S-PE1 ASBR | ASBR S-PE2 T-PE2 | 951 | | | 952 | | | 953 | Trusted Inter-AS PSN Tunnel | 954 | | 955 | | 956 |<------------------- Emulated Service ----------------->| 958 Figure 10 Indirectly Connected Inter-Provider Reference Model 960 Particular consideration needs to be given to Quality of Service 961 requests because the inappropriate use of priority may impact any 962 service guarantees given to other PWs. Consideration also needs to be 963 given to the avoidance of spoofing the PW demultiplexer. 965 Where an S-PE provides interconnection between different providers, 966 similar considerations to those applied to ASBRs apply. In particular 967 peer entity authentication should be used. 969 Where an S-PE also supports T-PE functionality, mechanisms should be 970 provided to ensure that MS-PWs to switched correctly to the 971 appropriate outgoing PW segment, rather than a local AC. Other 972 mechanisms for PW end point verification may also be used to confirm 973 the correct PW connection prior to enabling the attachment circuits. 975 14. Acknowledgments 977 The authors gratefully acknowledge the input of Mustapha Aissaoui, 978 Dimitri Papadimitrou, Sasha Vainshtein, and Luca Martini. 980 15. References 982 15.1. Normative References 984 [1] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation Edge- 985 to-Edge (PWE3) Architecture", RFC 3985, March 2005 987 [2] Andersson, L. and Madsen, T., "Provider Provisioned Virtual 988 Private Network (VPN) Terminology", RFC 4026, March 2005 990 [3] Rosen, E. Viswanathan, A. and Callon, R., "Multiprotocol Label 991 Switching Architecture", RFC 3031, January 2001 993 [4] Malis, A. and Townsley, M., "Pseudowire Emulation Edge-to-Edge 994 (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006 996 15.2. Informative References 998 [5] Martini, L. Bitar, N. and Bocci, M (Editors), "Requirements for 999 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 1000 5254, October 2008 1002 [6] Niven-Jenkins, B. et al., "MPLS-TP Requirements", draft-ietf- 1003 mpls-tp-requirements-09.txt, June 2009, work in progress. 1005 [7] Bryant, S et al."Pseudowire Congestion Control Framework", 1006 draft-ietf-pwe3-congestion-frmwk-02.txt, June 2009, work in 1007 progress. 1009 [8] Bocci, M., Bryant, S., Levrau, L. (Editors), "A Framework for 1010 MPLS in Transport Networks", draft-ietf-mpls-tp-framework- 1011 02.txt, July 2009, work in progress. 1013 Author's Addresses 1015 Matthew Bocci 1016 Alcatel-Lucent 1017 Voyager Place, Shoppenhangers Road, 1018 Maidenhead, Berks, UK 1019 Phone: +44 1633 413600 1020 Email: matthew.bocci@alcatel-lucent.com 1021 Stewart Bryant 1022 Cisco 1023 250, Longwater, 1024 Green Park, 1025 Reading, RG2 6GB, 1026 United Kingdom. 1027 Email: stbryant@cisco.com 1029 Acknowledgment 1031 Funding for the RFC Editor function is currently provided by the 1032 Internet Society.