idnits 2.17.00 (12 Aug 2021) /tmp/idnits26964/draft-bocci-bryant-pwe3-ms-pw-arch-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 774), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 == Line 664 has weird spacing: '...eck the integ...' -- 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 14, 2005) is 6056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3985 (ref. '2') -- No information found for draft-ietf-pwe3-mh-pw-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 4 S.Bryant 5 Cisco Systems 7 Expires: April 2006 October 14, 2005 9 An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge 11 draft-bocci-bryant-pwe3-ms-pw-arch-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, orf 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 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on December 1, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This document describes an architecture for extending pseudo wire 48 emulation across multiple packet switched network segments. Scenarios 49 are discussed where each segment of a given edge-to-edge emulated 50 service spans a different provider's PSN, and where the emulated 51 service originates and terminates on the same providers PSN, but may 52 pass through several PSN tunnel segments in that PSN. It presents an 53 architectural framework for such multi-segment pseudo wires, defines 54 terminology, and specifies the various protocol elements and their 55 functions. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [1]. 63 Table of Contents 65 1. Introduction...................................................3 66 1.1. Motivation................................................3 67 1.2. Non-Goals of this Document................................6 68 1.3. Terminology...............................................6 69 2. Applicability..................................................7 70 3. Protocol Layering model........................................7 71 3.1. Domain of Multi-Segment PWE3..............................8 72 3.2. Payload Types.............................................8 73 4. Multi-Segment PWE3 Reference Model.............................8 74 4.1. Intra-Provider Architecture..............................10 75 4.1.1. Intra-Provider Switching Using ACs..................10 76 4.1.2. Intra-Provider Switching Using PWs..................10 77 4.2. Inter-Provider Architecture..............................10 78 4.2.1. Inter-Provider Switching Using ACs..................11 79 4.2.2. Inter-Provider Switching Using PWs..................11 80 5. PE Reference Model............................................12 81 5.1. PWE3 Pre-processing......................................12 82 5.1.1. Forwarding..........................................12 83 5.1.2. Native Service Processing...........................12 84 6. Protocol Stack reference Model................................12 85 7. Maintenance Reference Model...................................13 86 8. PW Demultiplexer Layer and PSN Requirements...................14 87 8.1. Multiplexing.............................................14 88 8.2. Fragmentation............................................15 89 9. Control Plane.................................................15 90 9.1. Setup or Teardown of Pseudo Wires........................15 91 9.2. Pseudo-Wire Up/Down Notification.........................15 92 9.3. Misconnection and Payload Type Mismatch..................16 93 10. Management and Monitoring....................................16 94 11. IANA Considerations..........................................16 95 12. Security Considerations......................................16 96 13. Acknowledgments..............................................17 97 14. References...................................................18 98 14.1. Normative References....................................18 99 Author's Addresses...............................................18 100 Intellectual Property Statement..................................18 101 Disclaimer of Validity...........................................19 102 Copyright Statement..............................................19 103 Acknowledgment...................................................19 105 1. Introduction 107 RFC 3985 [2] defines the architecture for pseudo wires, where a 108 pseudo wire (PW) both originates and terminates on the edge of the 109 same packet switched network (PSN). The PW passes through a maximum 110 of one PSN tunnel between the originating and terminating PEs. 112 This document extends the architecture in RFC 3985 to enable pseudo 113 wires to be extended through multiple PSN tunnels. Use cases for 114 multi-segment pseudo wires, and the consequent requirements, are 115 defined in [3]. 117 1.1. Motivation 119 PWE3 aims to provide point-to-point connectivity between two edges of 120 a provider network. Requirements for Multi-Segment Pseudo-Wires for 121 this are specified in [3]. These requirements address three main 122 problems: 124 o How to scale PWE3 when the number of PEs grows to many hundreds or 125 thousands, while minimizing the complexity of the PEs and P 126 routers. 128 o How to provide PWE3 across multiple PSN routing domains or areas 129 in the same provider. 131 o How to provide PWE3 across multiple provider domains, and 132 different PSN types. 134 Consider a single PWE3 domain, such as that shown in Figure 1. There 135 are 4 PEs, and PWE3 must be provided from any PE to any other PE. 136 Traditionally, this would be achieved by establishing a full mesh of 137 PSN tunnels between the PEs. This would also require a full mesh of 138 LDP signaling adjacencies between the PEs. Pseudo wires could then be 139 established between any PE and any other PE via a single, direct 140 tunnel. PEs must terminate all pseudo wires that are carried on PSN 141 tunnels that terminate on that PE according to the architecture of 142 RFC 3985. This solution is adequate for small numbers of PEs, but the 143 number of PEs and signaling adjacencies will grow in proportion to 144 the square of the number of PEs. 146 A more efficient solution for large numbers of PEs would be to 147 support a partial mesh of PSN tunnels between the PEs, as shown in 148 Figure 1. For example, consider a PWE3 service whose endpoints are 149 PE1 and PE4. Pseudo wires for this can take the path PE1->PE2->PE3, 150 and rather than terminating at PE2, be switched between ingress and 151 egress PSN tunnels on that PE. This requires a capability in PE2 that 152 can concatenate PW segments PE1-PE2 to PW segments PE2-PE3. The end- 153 to-end PW is known as a multi-segment PW. 155 ,,..--..,,_ 156 .-`` `'., 157 +-----+` '+-----+ 158 | PE1 |---------------------| PE2 | 159 | |---------------------| | 160 +-----+ PSN Tunnel +-----+ 161 / || || \ 162 / || || \ 163 | || || | 164 | || PSN || | 165 | || || | 166 \ || || / 167 \ || || / 168 \|| ||/ 169 +-----+ +-----+ 170 | PE3 |---------------------| PE4 | 171 | |---------------------| | 172 +-----+`'.,_ ,.'` +-----+ 173 `'''---''`` 174 Figure 1 Single PSN PWE3 Scaling 176 Figure 1 shows a simple flat PSN topology. However, large provider 177 networks are typically not flat, consisting of many domains that are 178 connected together to provide edge-to-edge services. The elements in 179 each domain are specialized for a particular role. 181 An example application is shown in Figure 2. Here, the providers 182 network is divided into three domains: Two access domains and the 183 core domain. The access domains represent the edge of the provider's 184 network at which services are delivered. In the access domain, 185 simplicity is required in order to minimize the cost of the network. 186 The core domain must support all of the aggregated services from the 187 access domains, and the design requirements here are for scalability, 188 performance, and information hiding (i.e. minimal state). The core 189 must not be exposed to the state associated with large numbers of 190 individual edge-to-edge flows. That is, the core must be simple and 191 fast. 193 In a traditional layer 2 network, the interconnection points between 194 the domains are where services in the access domains are aggregated 195 for transport across the core to other access domains. In an IP 196 network, the interconnection points would also represent interworking 197 points between different types of IP networks e.g. those with MPLS 198 and those without, and also points where network policies can be 199 applied. 201 <-------- Edge to Edge Emulated Services -------> 203 ,' . ,-` `', ,' . 204 / \ .` `, / \ 205 / \ / , / \ 206 AC +----+ +----+ +----+ +----+ AC 207 ---| PE |-----| PE |---------------| PE |-------| PE |--- 208 | 1 | | 2 | | 3 | | 4 | 209 +----+ +----+ +----+ +----+ 210 \ / \ / \ / 211 \ / \ Core ` \ / 212 `, ` . ,` `, ` 213 '-'` `., _.` '-'` 214 Access 1 `''-''` Access 2 216 Figure 2 Multi-Domain Network Model 218 This model can also be applied to inter-provider services, where they 219 also rely on a number of separate provider networks to be connected 220 together. 222 Consider the application of this model to PWE3. PWE3 uses tunneling 223 mechanisms such as MPLS to enable the underlying IP PSN to emulate 224 characteristics of the native service. One solution to the multi- 225 domain network model above is to extend PSN tunnels edge-to-edge 226 between all of the PEs in access domain 1 and all of the PEs in 227 access domain 2, but this runs into the scaling issues described 228 above, and also exposes access and the core of the network to 229 undesirable complexity. An alternative is to constrain the complexity 230 to the network domain interconnection points (PE2 and PE3 in the 231 example above). Pseudo-wires between PE1 and PE4 would then be 232 switched between PSN tunnels at the interconnection points, enabling 233 PWs from many PEs in the access domains to be aggregated across only 234 a few PSN tunnels in the core of the network. PEs in the access 235 domains would only need to maintain direct signaling sessions, and 236 PSN tunnels, with other PEs in their own domain, thus minimizing 237 complexity of the access domains. 239 1.2. Non-Goals of this Document 241 The following are non-goals for this document: 243 o The on-the-wire specification of PW encapsulations 245 o Requirements on multi-segment pseudo-wires. 247 o The detailed specification of mechanisms for establishing and 248 maintaining multi-segment pseudo-wires. 250 1.3. Terminology 252 The terminology specified in RFC 3985 applies. In addition, we define 253 the following terms: 255 o PW Terminating Provider Edge (T-PE). A PE where the customer- 256 facing attachment circuits (ACs) are bound to a PW forwarder. A 257 Terminating PE is present in the first and last segments of a MS- 258 PW. This incorporates the functionality of a PE as defined in RFC 259 3985. 261 o Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 262 two T-PE devices. Each PW in one direction of a SS-PW traverses 263 one PSN tunnel that connects the two T-PEs. 265 o Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 266 configured set of two or more contiguous PW segments that behave 267 and function as a single point-to-point PW. Each end of a MS-PW by 268 definition MUST terminate on a T-PE. 270 o PW Segment. A part of a single-segment or multi-segment PW, which 271 is set up between two PE devices, T-PEs and/or S-PEs. 273 o PW Switching Provider Edge (S-PE). A PE capable of switching the 274 control and data planes of the preceding and succeeding PW 275 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 276 preceding and succeeding segments of the MS-PW.It is therefore a 277 PW switching point for a MS-PW. A PW Switching Point is never the 278 S-PE and the T-PE for the same MS-PW. A PW switching point runs 279 necessary protocols to setup and manage PW segments with other PW 280 switching points and terminating PEs. 282 2. Applicability 284 A MS-PW is a single PW that for technical or administrative reasons 285 is segmented into a number of concatenated hops. From the 286 perspective of a T-PE, a MS-PW is indistinguishable from a SS-PW. 287 Thus, the following are equivalent from the perspective of the T-PE 289 +----+ +----+ 290 |TPE1+--------------------------------------------------+TPE2| 291 +----+ +----+ 293 |<---------------------------PW----------------------------->| 295 +----+ +---+ +---+ +----+ 296 |TPE1+--------------+SPE+-----------+SPE+---------------+TPE2| 297 +----+ +---+ +---+ +----+ 299 Figure 3 MS-PW Equivalence 301 Although a MS-PW may require services such as node discovery and path 302 signaling to construct the PW, it should not be confused with a L2VPN 303 system, which also requires these services. A VPWS connects its 304 endpoints via a set of PWs. MS-PW is a mechanism that abstracts the 305 construction of complex PWs from the construction of a L2VPN. Thus a 306 T-PE might be an edge device optimized for simplicity and an S-PE 307 might be an aggregation device designed to absorb the complexity of 308 continuing the PW across the core of one or more service provider 309 networks to another T-PE located at the edge of the network. 311 3. Protocol Layering model 313 The protocol-layering model specified in RFC 3985 applies to multi- 314 segment PWE3 with the following clarification: the pseudo-wires may 315 be considered to be a separate layer to the PSN tunnel. That is, they 316 are independent of the PSN tunnel routing, operations, signaling and 317 maintenance. The design of PW routing domains should not imply that 318 the underlying PSN routing domains are the same. However, MS-PW will 319 reuse the protocols of the PSN and may use information that is 320 extracted from the PSN e.g. reachability. 322 3.1. Domain of Multi-Segment PWE3 324 PWE3 defines the Encapsulation Layer, i.e. the method of carrying 325 various payload types, and the interface to the PW Demultiplexer 326 Layer. It is expected that other layers will provide the following: 328 . PSN tunnel setup, maintenance and routing 330 . T-PE discovery 332 It is assumed that any node that is reachable via a PSN tunnel from 333 an S-PE or T-PE is a PE, a subset of which may be capable of behaving 334 as an S-PE. The selection of which S-PEs to use to reach a T-PE is 335 considered to be in the domain of PWE3. 337 3.2. Payload Types 339 Multi-segment PWE3 is applicable to all PWE3 payload types. 340 Encapsulations defined for SS-PWs are also used for MH-PW without 341 change. If different segments run over different PSN types, the 342 encapsulation may change but the PW types must be the same. 343 Translations between segments must not require processing of the 344 underlying payload. 346 4. Multi-Segment PWE3 Reference Model 348 The PWE3 reference architecture for the single segment case is shown 349 in [2]. This architecture applies to the case where a PSN tunnel 350 extends between two edges of a single PSN domain to transport a PW 351 with endpoints at these edges. 353 Native |<-----------Pseudo Wire----------->| Native 354 Service | | Service 355 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 356 | V V V V V V | 357 | +----+ +-----+ +----+ 358 +----+ | |TPE1|=========|SPE1 |=========|TPE2| | +----+ 359 | |-------|.....PW.Seg't1.......PW.Seg't3.....|----------| | 360 | CE1| | | | | | | | | |CE2 | 361 | |-------|.....PW.Seg't2.......PW.Seg't4.....|----------| | 362 +----+ | | |=========| |=========| | | +----+ 363 ^ +----+ +-----+ +----+ ^ 364 | Provider Edge 1 ^ Provider Edge 2 | 365 | | | 366 | | | 367 | PW switching point | 368 | | 369 |<------------------- Emulated Service ------------------>| 371 Figure 4 PW switching Reference Model 373 Figure 4 extends this architecture to show a multi-segment case. The 374 PEs that provide PWE3 to CE1 and CE2 are Terminating-PE1 (T-PE1) and 375 Terminating-PE2 (T-PE2) respectively. A PSN tunnel extends from T-PE1 376 to switching-PE1 (S-PE1) across PSN1, and a second PSN tunnel extends 377 from S-PE1 to S-PE2 across PSN2. PWs are used to connect the 378 attachment circuits (ACs) attached to PE1 to the corresponding ACs 379 attached to PE3. Each PW segment on the tunnel across PSN1 is 380 switched to a PW segment in the tunnel across PSN2 at S-PE1 to 381 complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 382 is therefore the PW switching point. PW segment 1 and PW segment 3 383 are segments of the same MS-PW while PW segment 2 and PW segment 4 384 are segments of another MS-PW. PW segments of the same MS-PW (e.g., 385 PW1 and PW3) MAY be of the same PW type or different type, and PSN 386 tunnels (e.g., PSN1 and PSN2) can be the same or different 387 technology. This document requires support for MS-PWs with segments 388 of the same type. An S-PE switches an MS-PW from one segment to 389 another based on the PW identifiers (e.g., PW label in case of MPLS 390 PWs). 392 Note that although Figure 4 only shows a single S-PE, a PW may 393 transit more one S-PE along its path. This architecture is applicable 394 when the S-PEs are statically chosen, or when they are chosen using a 395 dynamic path selection mechanism. 397 4.1. Intra-Provider Architecture 399 There is a requirement to deploy PWs edge to edge in large service 400 provider networks [3]. Such networks typically encompass hundreds or 401 thousands of aggregation devices at the edge, each of which would be 402 a PE. These networks may be partitioned into separate metro and core 403 PWE3 domains, where the PEs are interconnected by a sparse mesh of 404 tunnels. 406 Whether or not the network is partitioned into separate PWE3 domains, 407 there is a also a requirement to support a partial mesh of traffic 408 engineered PSN tunnels. 410 The architecture shown in Figure 4 can be used to support such cases. 411 PSN1 and PSN2 may be in different administrative domains or access, 412 core or metro regions within the same providers network. 413 Alternatively, T-PE1, SPE1 and T-PE2 may reside at the edges of the 414 same PSN. 416 4.1.1. Intra-Provider Switching Using ACs 418 In this model, the PW reverts to the native service AC at the PE. 419 This AC is then connected to a separate PW on the same PE. In this 420 case, the reference models of RFC 3985 apply to each segment and to 421 the PEs. The remaining PE architectural considerations in this 422 document do not apply to this case. 424 4.1.2. Intra-Provider Switching Using PWs 426 In this model, PW segments are switched between PSN tunnels that span 427 portions of a provider's network, without reverting to the native 428 service at the boundary. For example, in Figure 4, PSN 1 and PSN 2 429 would be portions of the same provider's network. 431 4.2. Inter-Provider Architecture 433 Intra-provider PWs may need to be switched between PSN tunnels at the 434 provider boundary in order to minimize the number of tunnels required 435 to provide PWE3 services to CEs attached to each providers network. 436 In addition, AAA and security and mechanisms may need to be 437 implemented on a per-PW basis at the provider boundary. 439 4.2.1. Inter-Provider Switching Using ACs. 441 In this model, the PW reverts to the native service at the provider 442 boundary PE. This AC is then connected to a separate PW at the peer 443 provider boundary PE. In this case, the reference models of RFC 3985 444 apply to each segment and to the PEs. The remaining PE architectural 445 considerations in this document do not apply to this case. 447 4.2.2. Inter-Provider Switching Using PWs. 449 In this model, PW segments are switched between PSN tunnels in each 450 provider's network, without reverting to the native service at the 451 boundary. For example, in Figure 4, PSN 1 and PSN 2 would be 452 different provider's networks. However, this would require that S-PE1 453 be a member of both provider networks. 455 An alternative network architecture is shown in Figure 5. Here, S-PE1 456 and S-PE2 are provider border routers. PW segment 1 is switched to PW 457 segment 2 at S-PE1. PW segment 2 is then carried across an inter- 458 provider PSN tunnel to S-PE2, where it is switched to PW segment 3 in 459 PSN 2. 461 |<---------- MS-Pseudo Wire ---------->| 462 | Provider Provider | 463 AC | |<----1---->| |<----2--->| | AC 464 | V V V V V V | 465 | +----+ +-----+ +----+ +----+ | 466 +----+ | | |=====| |=====| |=====| | | +----+ 467 | |-------|......PW..........PW.........PW.......|-------| | 468 | CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2 | 469 +----+ | | |=====| |=====| |=====| | | +----+ 470 ^ +----+ +-----+ +----+ +----+ ^ 471 | T-PE1 S-PE1 S-PE2 T-PE2 | 472 | ^ ^ | 473 | | | | 474 | PW switching points | 475 | | 476 | | 477 |<------------------- Emulated Service --------------->| 479 Figure 5 Inter-Provider Reference Model 481 5. PE Reference Model 483 5.1. PWE3 Pre-processing 485 PWE3 preprocessing is applied in the T-PEs as specified in RFC 3985. 486 Processing at the S-PEs is specified in the following sections. 488 5.1.1. Forwarding 490 Each forwarder in the S-PE forwards packets from one PW segment on 491 the ingress PSN facing interface of the S-PE to one PW segment on the 492 egress PSN facing interface of the S-PE. 494 The forwarder selects the egress segment PW based on the ingress PW 495 label. The mapping of ingress to egress PW label may be statically or 496 dynamically configured. Figure 6 shows how a single forwarder is 497 associated with each PW segment at the S-PE. 499 +------------------------------------------+ 500 | S-PE Device | 501 +------------------------------------------+ 502 Ingress | | | | Egress 503 PW instance | Single | | Single | PW Instance 504 <==========>X PW Instance + Forwarder + PW Instance X<==========> 505 | | | | 506 +------------------------------------------+ 508 Figure 6 Point-to-Point Service 510 Other mappings of PW to forwarder are for further study. 512 5.1.2. Native Service Processing 514 There is no native service processing in the S-PEs. 516 6. Protocol Stack reference Model 518 Figure 7 illustrates the protocol stack reference model for multi- 519 segment PWs. 521 +----------------+ +----------------+ 522 |Emulated Service| |Emulated Service| 523 |(e.g., TDM, ATM)|<======= Emulated Service =======>|(e.g., TDM, ATM)| 524 +----------------+ +----------------+ 525 | Payload | | Payload | 526 | Encapsulation |<== Multi-segment Pseudo Wire ===>| Encapsulation | 527 +----------------+ +--------+ +----------------+ 528 |PW Demultiplexer||PW Demux||PW Demultiplexer| 529 +----------------+ +--------+ +----------------+ 530 | PSN Tunnel, || PSN || PSN Tunnel, | 531 | PSN & Physical | |Physical| | PSN & Physical | 532 | Layers | | Layers | | Layers | 533 +-------+--------+ +--------+ +----------------+ 534 | .......... | .......... | 535 | / \ | / \ | 536 +==========/ PSN \===/ PSN \==========+ 537 \ domain 1 / \ domain 2 / 538 \__________/ \__________/ 539 `````````` `````````` 541 Figure 7 Multi-Segment PW Protocol Stack 543 The MS-PW provides the CE with an emulated physical or virtual 544 connection to its peer at the far end. Native service PDUs from the 545 CE are passed through an Encapsulation Layer and a PW demultiplexer 546 is added at the sending T-PE. The PDU is sent over PSN domain 1. The 547 receiving S-PE removes the existing PW demultiplexer, adds a new 548 demultiplexer, and then sends the PDU over PSN2. Policies may also be 549 applied to the PW at this point. Examples of such policies include: 550 admission control, rate control, QoS mappings, and security. The 551 receiving T-PE removes the PW demultiplexer and restores the payload 552 to its native format for transmission to the destination CE. 554 Where the encapsulation format is different e.g. MPLS and L2TPv3, the 555 payload encapsulation may be transparently translated at the S-PE. 557 7. Maintenance Reference Model 559 Figure 8 shows the maintenance reference model for multi-segment 560 PWE3. 562 |<------------- CE (end-to-end) Signaling ------------>| 563 | | 564 | |<-------- MS-PW/T-PE Maintenance ----->| | 565 | | |<---PW Seg't-->| |<--PW Seg't--->| | | 566 | | | Maintenance | | Maintenance | | | 567 | | | | | | | | 568 | | | PSN | | PSN | | | 569 | | | |<-Tunnel1->| | | |<-Tunnel2->| | | | 570 | V V V Signaling V V V V Signaling V V V | 571 V +----+ +-----+ +----+ V 572 +----+ |TPE1|===========|SPE1 |===========|TPE2| +----+ 573 | |-------|......PW.Seg't1.........PW Seg't3......|------| | 574 | CE1| | | | | | | |CE2 | 575 | |-------|......PW.Seg't2.........PW Seg't4......|------| | 576 +----+ | |===========| |===========| | +----+ 577 ^ +----+ +-----+ +----+ ^ 578 | Terminating ^ Terminating | 579 | Provider Edge 1 | Provider Edge 2 | 580 | | | 581 | PW switching point | 582 | | 583 |<--------------------- Emulated Service ------------------->| 585 Figure 8 MS-PWE3 Maintenance Reference Model 587 RFC 3985 specifies the use of CE (end-to-end) and PSN tunnel 588 signaling, and PW/PE maintenance. CE and PSN tunnel signaling is as 589 specified in RFC 3985. However, in the case of MS-PWE3, signaling 590 between the PEs now has both an edge-to-edge and a hop-by-hop 591 context. That is, signaling and maintenance between T-PEs and S-PEs 592 and between adjacent S-PEs is used to set up, maintain, and tear down 593 the MS-PW segments, which including the coordination of parameters 594 related to each switching point, as well as the MS-PW end points. 596 8. PW Demultiplexer Layer and PSN Requirements 598 8.1. Multiplexing 600 The purpose of the PW demultiplexer layer at the S-PE is to 601 demultiplex PWs from ingress PSN tunnels and to multiplex them into 602 egress PSN tunnels. Although each PW may contain multiple native 603 service circuits, e.g. multiple ATM VCs, the S-PEs do not have 604 visibility of, and hence do not change, this level of multiplexing 605 because they contain no NSP. 607 8.2. Fragmentation 609 An S-PE is not required to make any attempt to reassemble a 610 fragmented PW payload. An S-PE may fragment a PW payload. 612 9. Control Plane 614 9.1. Setup or Teardown of Pseudo Wires 616 For multi-segment pseudo wires, the intermediate PW switching points 617 may be statically provisioned, or they may be dynamically signaled. 618 For the dynamic case, there are two options for selecting the path of 619 the PW: 621 o T-PEs determine the full path of the PW through intermediate 622 switching points. This may be either static or based on a dynamic 623 PW path selection mechanism. 625 o Each segment of the PW path is determined locally by each T-PE or 626 S-PE, either through static configuration or based on a dynamic PW 627 path selection mechanism. 629 Further details of the impact of these on the control plane 630 architecture will be provided in a future revision. 632 9.2. Pseudo-Wire Up/Down Notification 634 Since a multi-segment PW consists of a number of concatenated PW 635 segments, the emulated service can only be considered as being up 636 when all of the PW segments and PSN tunnels (if used) are functional 637 along the entire path of the MS-PW. 639 If a native service requires bi-directional connectivity, the 640 corresponding emulated service can only be signaled as being up when 641 the PW segments and PSN tunnels (if used), are functional in both 642 directions. 644 RFC 3985 describes the need for failure and other status notification 645 mechanisms for PWs. These considerations also apply to multi-segment. 646 In addition, the S-PE must be able to propagate such notifications 647 between concatenated segments of the same PW. 649 9.3. Misconnection and Payload Type Mismatch 651 With PWE3, misconnection and payload type mismatch can occur. 652 Misconnection can breach the integrity of the system. Payload 653 mismatch can disrupt the customer network. In both instances, there 654 are security and operational concerns. 656 The services of the underlying tunneling mechanism and its associated 657 control protocol can be used to ensure that the identity of the next 658 hop is as expected. As part of the PW setup, a PW-TYPE identifier is 659 exchanged. This is then used by the forwarder and the NSP of the T- 660 PEs to verify the compatibility of the ACs. This can also be used by 661 S-PEs to ensure that concatenated segments of a given MS-PW are 662 compatible, or that a MS-PW is not misconnected into a local AC. In 663 addition, it is advisable to do an end to end connection verification 664 to check the integrity of the PW and to verify the identity of the 665 T-PE. 667 10. Management and Monitoring 669 The management and monitoring as described in RFC 3985 apply here. 671 The need for an S-PE ping and PW trace route, and the mechanisms to 672 provide these, are for further study. 674 11. IANA Considerations 676 This document does not contain any IANA actions. 678 12. Security Considerations 680 The security considerations described in RFC-3985 apply here. 682 Additional consideration needs to be given to the security of the S- 683 PEs, particularly when these are dynamically selected and/or when the 684 MH-PW transits the networks of multiple operators. 686 When the MS-PW is dynamically created by the use of a signaling 687 protocol, an SPE SHOULD determine the authenticity of the request, 688 and its compliance with policy. 690 Particular consideration needs to be given to Quality of Service 691 requests because the inappropriate use of priority may impact other 692 service guarantees. 694 Where an S-PE provides interconnection between different providers, 695 similar considerations to those applied to ASBRs apply. In particular 696 peer entity authentication SHOULD be used. 698 Where an S-PE also supports T-PE functionality, mechanisms should be 699 provided to ensure that MS-PWs to switched correctly to the 700 appropriate outgoing PW segment, rather than a local AC. Other 701 mechanisms for PW end point verification may also be used to confirm 702 the correct PW connection prior to enabling the attachment circuits. 704 13. Acknowledgments 706 The authors gratefully acknowledge the input of Mustapha Aissaoui, 707 Dimitri Papadimitrou, and Luca Martini. 709 14. References 711 14.1. Normative References 713 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 714 Levels", BCP 14, RFC 2119, March 1997. 716 [2] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation Edge- 717 to-Edge (PWE3) Architecture", RFC 3985, March 2005 719 [3] Martini, S. Bitar, N. and Bocci, M (Editors), "Requirements for 720 inter domain Pseudo-Wires", draft-ietf-pwe3-mh-pw-requirements- 721 00.txt, internet Draft, July 2005 723 Author's Addresses 725 Matthew Bocci 726 Alcatel 727 Voyager Place, 728 Shoppenhangers Rd, 729 Maidenhead, Berks, UK Email: matthew.bocci@alcatel.co.uk 731 Stewart Bryant 732 Cisco Systems, 733 250, Longwater, 734 Green Park, 735 Reading, RG2 6GB, 736 United Kingdom. Email: stbryant@cisco.com 738 Intellectual Property Statement 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; nor does it represent that it has 745 made any independent effort to identify any such rights. Information 746 on the procedures with respect to rights in RFC documents can be 747 found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use of 752 such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at ietf 760 ipr@ietf.org 762 Disclaimer of Validity 764 This document and the information contained herein are provided on an 765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 767 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 768 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 769 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 772 Copyright Statement 774 Copyright (C) The Internet Society (2005). 776 This document is subject to the rights, licenses and restrictions 777 contained in BCP 78, and except as set forth therein, the authors 778 retain all their rights. 780 Acknowledgment 782 Funding for the RFC Editor function is currently provided by the 783 Internet Society.