idnits 2.17.1 draft-bocci-bryant-pwe3-ms-pw-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 621. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 641), 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 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 -- 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 9, 2005) is 6865 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') -- Possible downref: Normative reference to a draft: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: January 2006 July 9, 2005 9 An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge 11 draft-bocci-bryant-pwe3-ms-pw-arch-00.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, 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 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............................7 72 3.2. Payload Types..........................................8 73 4. Multi-Segment PWE3 Reference Model...........................8 74 4.1. Intra-Provider Architecture.............................9 75 4.2. Inter-Provider Architecture.............................9 76 4.3. PW Switching Models....................................10 77 4.3.1. Switching using ACs...............................10 78 4.3.2. Switching using PWs...............................10 79 5. PE Reference Model.........................................10 80 5.1. PWE3 Pre-processing....................................10 81 5.1.1. Forwarding........................................11 82 5.1.2. Native Service Processing.........................11 83 6. Protocol Stack reference Model..............................11 84 7. Maintenance Reference Model.................................12 85 8. PW Demultiplexer Layer and PSN Requirements.................12 86 9. Control Plane..............................................12 87 10. Fragmentation.............................................13 88 11. Management and Monitoring..................................13 89 12. IANA Considerations........................................13 90 13. Security Considerations....................................13 91 14. Acknowledgments...........................................13 92 15. References................................................14 93 15.1. Normative References..................................14 94 Author's Addresses............................................14 95 Intellectual Property Statement................................14 96 Disclaimer of Validity........................................15 97 Copyright Statement...........................................15 98 Acknowledgment................................................15 100 1. Introduction 102 RFC 3985 [2] defines the architecture for pseudo wires, where a 103 pseudo wire (PW) both originates and terminates on the edge of the 104 same packet switched network (PSN). The PW passes through a maximum 105 of one PSN tunnel between the originating and terminating PEs. 107 This document extends the architecture in RFC 3985 to enable pseudo 108 wires to be extended through multiple PSN tunnels. Use cases for 109 multi-segment pseudo wires, and the consequent requirements, are 110 defined in [3]. 112 1.1. Motivation 114 PWE3 aims to provide point-to-point connectivity between two edges of 115 a provider network. Requirements for Multi-Segment Pseudo-Wires for 116 this are specified in [3]. These requirements address three main 117 problems: 119 o How to scale PWE3 when the number of PEs grows to many hundreds or 120 thousands, while minimizing the complexity of the PEs and P 121 routers. 123 o How to provide PWE3 across multiple PSN routing domains or areas 124 in the same provider. 126 o How to provide PWE3 across multiple provider domains, and 127 different PSN types. 129 Consider a single PWE3 domain, such as that shown in Figure 1. There 130 are 4 PEs, and PWE3 must be provided from any PE to any other PE. 131 Traditionally, this would be achieved by establishing a full mesh of 132 PSN tunnels between the PEs. This would also require a full mesh of 133 LDP signaling adjacencies between the PEs. Pseudo wires could then be 134 established between any PE and any other PE via a single, direct 135 tunnel. PEs must terminate all pseudo wires that are carried on PSN 136 tunnels that terminate on that PE according to the architecture of 137 RFC 3985. This solution is adequate for small numbers of PEs, but the 138 number of PEs and signaling adjacencies will grow in proportion to 139 the square of the number of PEs. 141 A more efficient solution for large numbers of PEs would be to 142 support a partial mesh of PSN tunnels between the PEs, as shown in 143 Figure 1. For example, consider a PWE3 service whose endpoints are 144 PE1 and PE4. Pseudo wires for this can take the path PE1->PE2->PE3, 145 and rather than terminating at PE2, be switched between ingress and 146 egress PSN tunnels on that PE. This requires a capability in PE2 that 147 can concatenate PW segments PE1-PE2 to PW segments PE2-PE3. The end- 148 to-end PW is known as a multi-segment PW. 150 ,,..--..,,_ 151 .-`` `'., 152 +-----+` '+-----+ 153 | PE1 |---------------------| PE2 | 154 | |---------------------| | 155 +-----+ PSN Tunnel +-----+ 156 / || || \ 157 / || || \ 158 | || || | 159 | || PSN || | 160 | || || | 161 \ || || / 162 \ || || / 163 \|| ||/ 164 +-----+ +-----+ 165 | PE3 |---------------------| PE4 | 166 | |---------------------| | 167 +-----+`'.,_ ,.'` +-----+ 168 `'''---''`` 169 Figure 1 Single PSN PWE3 Scaling 171 Figure 1 shows a simple flat PSN topology. However, large provider 172 networks are typically not flat, consisting of many domains that are 173 connected together to provide edge-to-edge services. The elements in 174 each domain are specialized for a particular role. 176 An example application is shown in Figure 2. Here, the providers 177 network is divided into three domains: Two access domains and the 178 core domain. The access domains represent the edge of the provider's 179 network at which services are delivered. In the access domain, 180 simplicity is required in order to minimize the cost of the network. 182 The core domain must support all of the aggregated services from the 183 access domains, and the design requirements here are for scalability, 184 performance, and information hiding (i.e. minimal state). The core 185 must not be exposed to the state associated with large numbers of 186 individual edge-to-edge flows. That is, the core must be simple and 187 fast. 189 In a traditional layer 2 network, the interconnection points between 190 the domains are where services in the access domains are aggregated 191 for transport across the core to other access domains. In an IP 192 network, the interconnection points would also represent interworking 193 points between different types of IP networks e.g. those with MPLS 194 and those without, and also points where network policies can be 195 applied. 197 <----------------Edge to Edge Emulated Services---------> 199 .-., ,..-.., .-., 200 ,' . ,-` `', ,' . 201 / \ .` `, / \ 202 / \ / , / \ 203 AC +----+ +----+ +----+ +----+ AC 204 ---| PE |=====| PE |===============| PE |=======| PE |--- 205 | 1 | | 2 | | 3 | | 4 | 206 +----+ +----+ +----+ +----+ 207 \ / \ / \ / 208 \ / \ Core ` \ / 209 `, ` '. ,` `, ` 210 '-'` `., _.` '-'` 211 Access 1 `''-''` Access 2 213 Figure 2 Multi-Domain Network Model 215 This model can also be applied to inter-provider services, where they 216 also rely on a number of separate provider networks to be connected 217 together. 219 Consider the application of this model to PWE3. PWE3 uses tunneling 220 mechanisms such as MPLS to enable the underlying IP PSN to emulate 221 characteristics of the native service. One solution to the multi- 222 domain network model above is to extend PSN tunnels edge-to-edge 223 between all of the PEs in access domain 1 and all of the PEs in 224 access domain 2, but this runs into the scaling issues described 225 above, and also exposes access and the core of the network to 226 undesirable complexity. An alternative is to constrain the complexity 227 to the network domain interconnection points (PE2 and PE3 in the 228 example above). Pseudo-wires between PE1 and PE4 would then be 229 switched between PSN tunnels at the interconnection points, enabling 230 PWs from may PEs in the access domains to be aggregated across only a 231 few PSN tunnels in the core of the network. PEs in the access domains 232 would only need to maintain direct signaling sessions, and PSN 233 tunnels, with other PEs in their own domain, thus minimizing 234 complexity of the access domains. 236 1.2. Non-Goals of this Document 238 The following are non-goals for this document: 240 o The on-the-wire specification of PW encapsulations 242 o Requirements on multi-segment pseudo-wires. 244 o The detailed specification of mechanisms for establishing and 245 maintaining multi-segment pseudo-wires. 247 1.3. Terminology 249 The terminology specified in RFC 3985 applies. In addition, we define 250 the following terms: 252 o Ultimate PE (U-PE). A PE where the customer-facing attachment 253 circuits (ACs) are bound to a PW forwarder. An ultimate PE is 254 present in the first and last segments of a MS-PW. 256 o Single-Segment PW (SS-PW). A PW setup directly between two U-PE 257 devices. Each PW in one direction of a SS-PW traverses one PSN 258 tunnel that connects the two U-PEs. 260 o Multi-Segment PW (MS-PW). A static or dynamically configured set 261 of two or more contiguous PW segments that behave and function as 262 a single point-to-point PW. Each end of a MS-PW by definition MUST 263 terminate on a U-PE. 265 o PW Switching Provider Edge (S-PE). A PE capable of switching the 266 control and data planes of the preceding and succeeding PW 267 segments in a MS-PW. It is therefore a PW switching point for a 268 MS-PW. A PW Switching Point is never the S-PE and the U-PE for the 269 same MS-PW. A PW switching point runs necessary protocols to setup 270 and manage PW segments with other PW switching points and ultimate 271 PEs. 273 o PW Segment. A part of a single-segment or multi-segment PW, which 274 is set up between two PE devices, U-PEs and/or S-PEs. 276 2. Applicability 278 A MS-PW is a single PW that for technical or administrative reasons 279 is segmented into a number of concatenated hops. From the 280 perspective of a U-PE, a MS-PW is indistinguishable from a SS-PW. 281 Thus, the following are equivalent from the perspective of the UPE 283 +----+ +----+ 284 |UPE1+--------------------------------------------------+UPE2| 285 +----+ +----+ 287 |<----------------------PW------------------------>| 289 +----+ +---+ +---+ +----+ 290 |UPE1+--------------+SPE+-----------+SPE+---------------+UPE2| 291 +----+ +---+ +---+ +----+ 293 Figure 3 MS-PW Equivalence 295 Although a MS-PW may require services such as node discovery and path 296 signaling to construct the PW, it should not be confused with a L2VPN 297 system, which also requires these services. A VPWS connects its 298 endpoints via a set of PWs. MS-PW is a mechanism that abstracts the 299 construction of complex PWs from the construction of a L2VPN. Thus a 300 U-PE might be an edge device optimized for simplicity and an S-PE 301 might be an aggregation device designed to absorb the complexity of 302 continuing the PW across the core of one or more service provider 303 networks to another UPE located at the edge of the network. 305 3. Protocol Layering model 307 The protocol-layering model specified in RFC 3985 applies to multi- 308 segment PWE3 with the following clarification: the pseudo-wires may 309 be considered to be a separate layer to the PSN tunnel. That is, they 310 are independent of the PSN tunnel routing, operations, signaling and 311 maintenance. The design of PW routing domains should not imply that 312 the underlying PSN routing domains are the same. However, MS-PW will 313 reuse the protocols of the PSN. 315 3.1. Domain of Multi-Segment PWE3 317 PWE3 defines the Encapsulation Layer, the method of carrying various 318 payload types, and the interface to the PW Demultiplexer Layer. It 319 is expected that other layers will provide the following: 321 . PSN tunnel setup, maintenance and routing 322 . U-PE discovery 324 It is assumed that any node that is reachable via a PSN tunnel from 325 an S-PE or U-PE is a PE, a subset of which may be capable of behaving 326 as an S-PE. The selection of which S-PEs to use to reach a U-PE is 327 considered to be in the domain of PWE3. 329 3.2. Payload Types 331 Multi-segment PWE3 is applicable to all PWE3 payload types. The same 332 encapsulations are used in both SS-PW and MH-PW. 334 4. Multi-Segment PWE3 Reference Model 336 The PWE3 reference architecture for the single segment case is shown 337 in [2]. This architecture applies to the case where a PSN tunnel 338 extends between two edges of a single PSN domain to transport a PW 339 with endpoints at these edges. 341 Native |<-----------Pseudo Wire----------->| Native 342 Service | | Service 343 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 344 | V V V V V V | 345 | +----+ +-----+ +----+ 346 +----+ | |UPE1|=========|SPE1 |=========|UPE2| | +----+ 347 | |-------|....PW.Seg't1........PW Seg't3.....|----------| | 348 | CE1| | | | | | | | | |CE2 | 349 | |-------|....PW.Seg't2.......|PW Seg't4.....|----------| | 350 +----+ | | |=========| |=========| | | +----+ 351 ^ +----+ +-----+ +----+ ^ 352 | Provider Edge 1 ^ Provider Edge 2 | 353 | | | 354 | | | 355 | PW switching point | 356 | | 357 |<------------------- Emulated Service ------------------>| 359 Figure 4 PW switching Reference Model 361 Figure 4 extends this architecture to show a multi-segment case. The 362 PEs that provide PWE3 to CE1 and CE2 are Ultimate-PE1 (U-PE1) and 363 Ultimate-PE2 (U-PE2) respectively. A PSN tunnel extends from U-PE1 to 364 switching-PE1 (S-PE1) across PSN1, and a second PSN tunnel extends 365 from S-PE1 to S-PE2 across PSN2. PWs are used to connect the 366 attachment circuits (ACs) attached to PE1 to the corresponding ACs 367 attached to PE3. Each PW segment on the tunnel across PSN1 is 368 switched to a PW segment in the tunnel across PSN2 at S-PE1 to 369 complete the multi-segment PW (MS-PW) between U-PE1 and U-PE2. S-PE1 370 is therefore the PW switching point. PW segment 1 and PW segment 3 371 are segments of the same MS-PW while PW segment 2 and PW segment 4 372 are segments of another MS-PW. PW segments of the same MS-PW (e.g., 373 PW1 and PW3) MAY be of the same PW type or different type, and PSN 374 tunnels (e.g., PSN1 and PSN2) can be the same or different 375 technology. This document requires support for MS-PWs with segments 376 of the same type. An S-PE switches an MS-PW from one segment to 377 another based on the PW identifiers (e.g., PW label in case of MPLS 378 PWs). 380 Note that although Figure 4 only shows a single S-PE, a PW may 381 transit more one S-PE along its path. This architecture is applicable 382 when the S-PEs are statically chosen, or when they are chosen using a 383 dynamic path selection mechanism. 385 4.1. Intra-Provider Architecture 387 There is a requirement to deploy PWs edge to edge in large 388 service provider networks [3]. Such networks typically encompass 389 hundreds or thousands of aggregation devices at the edge, each of 390 which would be a PE. These networks may be partitioned into separate 391 metro and core PWE3 domains, where the PEs are interconnected by a 392 sparse mesh of tunnels. 394 Whether or not the network is partitioned in to separate PWE3 395 domains, there is a also a requirement to support a partial mesh of 396 traffic engineered PSN tunnels. 398 The architecture shown in Figure 4 can be used to support such cases. 399 PSN1 and PSN2 may be in different administrative domains or access, 400 core or metro regions within the same providers network. 401 Alternatively, U-PE1, SPE1 and U-PE2 may reside at the edges of the 402 same PSN. 404 4.2. Inter-Provider Architecture 406 Intra-provider PWs may need to be switched between PSN tunnels at the 407 provider boundary in order to minimize the number of tunnels required 408 to provide PWE3 services to CEs attached to each providers network. 409 In addition, AAA and security and mechanisms may need to be 410 implemented on a per-PW basis at the provider boundary. 412 4.3. PW Switching Models 414 4.3.1. Switching using ACs. 416 In this model, the PW reverts to the native service at the provider 417 boundary PE. This AC is then connected to a separate PW at the peer 418 provider boundary PE. In this case, the reference models of RFC 3965 419 apply to each segment and to the PEs. The remaining PE architectural 420 considerations in this document do not apply to this case. 422 4.3.2. Switching using PWs. 424 In this model, PW segments are switched between PSN tunnels in each 425 providers network, without reverting to the native service at the 426 boundary. For example, in Figure 4, PSN 1 and PSN 2 would be 427 different provider's networks. However, this would require that S-PE1 428 be a member of both provider networks. 430 An alternative architecture is shown in Figure 5. 432 |<--------------Pseudo Wire----------->| 433 | Provider Provider | 434 AC | |<----1---->| |<----2--->| | AC 435 | V V V V V V | 436 | +----+ +-----+ +----+ +----+ | 437 +----+ | | |=====| |=====| |=====| | | +----+ 438 | |-------|.....PW.1........PW.2.......PW.3......|-------| | 439 | CE1| | | | | | | | | | | |CE2 | 440 +----+ | | |=====| |=====| |=====| | | +----+ 441 ^ +----+ +-----+ +----+ +----+ ^ 442 | PE1 PE2 PE3 PE4 | 443 | ^ ^ | 444 | | | | 445 | PW switching points | 446 | | 447 | | 448 |<------------------- Emulated Service --------------->| 450 Figure 5 Inter-Provider Reference Model 452 5. PE Reference Model 454 5.1. PWE3 Pre-processing 456 PWE3 preprocessing is applied in the U-PEs as specified in RFC 3985. 457 Processing at the S-PEs is specified in the following sections. 459 5.1.1. Forwarding 461 The forwarders in the S-PE forward packets from one or more PW 462 segments on the ingress PSN facing interface of the S-PE to one or 463 more PW segments on the egress PSN facing interface of the S-PE. 465 The forwarder selects the egress segment PW based on the ingress PW 466 label. The mapping of ingress to egress PW label may be statically or 467 dynamically configured. Figure 5 shows how a single forwarder is 468 associated with each PW segment at the S-PE. 470 +------------------------------------------+ 471 | S-PE Device | 472 +------------------------------------------+ 473 Ingress | | | | Egress 474 PW instance | Single | | Single | PW Instance 475 <==========>X PW Instance + Forwarder + PW Instance X<==========> 476 | | | | 477 +------------------------------------------+ 479 Figure 6 Point-to-Point Service 481 Other mappings of PW to forwarder are for further study. 483 5.1.2. Native Service Processing 485 There is no native service processing in the S-PEs. 487 6. Protocol Stack reference Model 489 Figure 7 illustrates the protocol stack reference model for multi- 490 segment PWs. 492 +----------------+ +----------------+ 493 |Emulated Service| |Emulated Service| 494 |(e.g., TDM, ATM)|<======= Emulated Service =======>|(e.g., TDM, ATM)| 495 +----------------+ +----------------+ 496 | Payload | | Payload | 497 | Encapsulation |<== Multi-segment Pseudo Wire ===>| Encapsulation | 498 +----------------+ +--------+ +----------------+ 499 |PW Demultiplexer||PW Demux||PW Demultiplexer| 500 +----------------+ +--------+ +----------------+ 501 | PSN Tunnel, || PSN || PSN Tunnel, | 502 | PSN & Physical | |Physical| | PSN & Physical | 503 | Layers | | Layers | | Layers | 504 +-------+--------+ +--------+ +----------------+ 505 | .......... | .......... | 506 | / \ | / \ | 507 +==========/ PSN \===/ PSN \==========+ 508 \ domain 1 / \ domain 2 / 509 \__________/ \__________/ 510 `````````` `````````` 512 Figure 7 Multi-Segment PW Protocol Stack 514 The MS-PW provides the CE with an emulated physical or virtual 515 connection to its peer at the far end. Native service PDUs from the 516 CE are passed through an Encapsulation Layer and a PW demultiplexer 517 is added at the sending U-PE. The PDU is sent over PSN domain 1. The 518 receiving S-PE removes the existing PW demultiplexer, adds a new 519 demultiplexer, and then sends the PDU over PSN2. Policies may also be 520 applied to the PW at this point. The receiving U-PE removes the PW 521 demultiplexer and restores the payload to its native format for 522 transmission to the destination CE. 524 Where the encapsulation format is different e.g. MPLS and L2TPv3, the 525 payload encapsulation may be transparently translated at the S-PE. 527 7. Maintenance Reference Model 529 To be added in a future version. 531 8. PW Demultiplexer Layer and PSN Requirements 533 To be added in a future version. 535 9. Control Plane 537 For multi-segment pseudo wires, the intermediate PW switching points 538 may be statically provisioned, or they may be dynamically signaled. 540 For the dynamic case, there are two options for selecting the path of 541 the PW: 543 o U-PEs determine the full path of the PW through intermediate 544 switching points. This may be either static or based on a dynamic 545 PW path selection mechanism. 547 o The each segment of the PW path is determined locally by each U-PE 548 or S-PE, either through static configuration or based on a dynamic 549 PW path selection mechanism. 551 Further details of the impact of these on the control plane 552 architecture will be provided in a future revision. 554 10. Fragmentation 556 An SPE is not required to make any attempt to reassemble a fragmented PW 557 payload. An SPE may fragment a PW payload fragment. 559 11. Management and Monitoring 561 To be added in a later version. 563 12. IANA Considerations 565 To be added in a future version. 567 13. Security Considerations 569 To be added in a later version. 571 14. Acknowledgments 573 The authors gratefully acknowledge the input of Mustapha Aissaoui, 574 Dimitri Papadimitrou, and Luca Martini. 576 15. References 578 15.1. Normative References 580 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 581 Levels", BCP 14, RFC 2119, March 1997. 583 [2] Bryant, S. and Pate, P. (Editors), "Pseudo Wire Emulation Edge- 584 to-Edge (PWE3) Architecture", RFC 3985, March 2005 586 [3] Martini, S. Bitar, N. and Bocci, M (Editors), "Requirements for 587 inter domain Pseudo-Wires", draft-martini-pwe3-mh-pw- 588 requirements-01.txt, internet Draft, March 2005 590 Author's Addresses 592 Matthew Bocci 593 Alcatel 594 Voyager Place, 595 Shoppenhangers Rd, 596 Maidenhead, Berks, UK Email: matthew.bocci@alcatel.co.uk 598 Stewart Bryant 599 Cisco Systems, 600 250, Longwater, 601 Green Park, 602 Reading, RG2 6GB, 603 United Kingdom. Email: stbryant@cisco.com 605 Intellectual Property Statement 607 The IETF takes no position regarding the validity or scope of any 608 Intellectual Property Rights or other rights that might be claimed to 609 pertain to the implementation or use of the technology described in 610 this document or the extent to which any license under such rights 611 might or might not be available; nor does it represent that it has 612 made any independent effort to identify any such rights. Information 613 on the procedures with respect to rights in RFC documents can be 614 found in BCP 78 and BCP 79. 616 Copies of IPR disclosures made to the IETF Secretariat and any 617 assurances of licenses to be made available, or the result of an 618 attempt made to obtain a general license or permission for the use of 619 such proprietary rights by implementers or users of this 620 specification can be obtained from the IETF on-line IPR repository at 621 http://www.ietf.org/ipr. 623 The IETF invites any interested party to bring to its attention any 624 copyrights, patents or patent applications, or other proprietary 625 rights that may cover technology that may be required to implement 626 this standard. Please address the information to the IETF at ietf 627 ipr@ietf.org 629 Disclaimer of Validity 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 634 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 635 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 636 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Copyright Statement 641 Copyright (C) The Internet Society (2005). 643 This document is subject to the rights, licenses and restrictions 644 contained in BCP 78, and except as set forth therein, the authors 645 retain all their rights. 647 Acknowledgment 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.