idnits 2.17.1 draft-ietf-pwe3-packet-pw-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (January 28, 2012) is 4472 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This RFC' is mentioned on line 352, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft L. Martini 4 Intended status: Standards Track G. Swallow 5 Expires: July 31, 2012 Cisco Systems 6 A. Malis 7 Verizon Communications 8 January 28, 2012 10 Packet Pseudowire Encapsulation over an MPLS PSN 11 draft-ietf-pwe3-packet-pw-03.txt 13 Abstract 15 This document describes a pseudowire mechanism that is used to 16 transport a packet service over an MPLS PSN is the case where the 17 client Label Switching Router (LSR) and the server Provider Edge 18 equipments are co-resident in the same equipment. This pseudowire 19 mechanism may be used to carry all of the required layer 2 and layer 20 3 protocols between the pair of client LSRs. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 31, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4 64 3. Client Network Layer Model . . . . . . . . . . . . . . . . . . 4 65 4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 6 67 6. Ethernet Functional Restrictions . . . . . . . . . . . . . . . 8 68 7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 11.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Encapsulation Approaches Considered . . . . . . . . . 10 76 A.1. A Protocol Identifier in the Control Word . . . . . . . . 11 77 A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 11 78 A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . 12 79 A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . 13 80 A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 There is a need to provide a method of carrying a packet service over 86 an MPLS PSN in a way that provides isolation between the two 87 networks. The server MPLS network may be an MPLS network or a 88 network conforming to the MPLS Transport Profile (MPLS-TP) [RFC5317]. 89 The client may also be either an MPLS network or a network conforming 90 to the MPLS-TP. Considerations regarding the use of an MPLS network 91 as a server for an MPLS-TP network are outside the scope of this 92 document. 94 Where the client equipment is connected to the server equipment via a 95 physical interface, the same data-link type MUST be used to attach 96 the clients to the Provider Edge equipments (PE)s, and a pseudowire 97 (PW) of the same type as the data-link MUST be used [RFC3985]. The 98 reason that inter-working between different physical and data-link 99 attachment types is specifically disallowed in the pseudowire 100 architecture is because this is a complex task and not a simple bit- 101 mapping exercise. The inter-working is not limited to the physical 102 and data-link interfaces and the state-machines. It also requires a 103 compatible approach to the formation of the adjacencies between 104 attached client network equipment. As an example the reader should 105 consider the differences between router adjacency formation on a 106 point-to-point link compared to a multipoint-to-multipoint interface 107 (e.g. Ethernet). 109 A further consideration is that two adjacent MPLS Label Switching 110 Routers (LSRs) do not simply exchange MPLS packets. They exchange IP 111 packets for adjacency formation, control, routing, label exchange, 112 management and monitoring purposes. In addition they may exchange 113 data-link packets as part of routing (e.g. IS-IS Hellos and IS-IS 114 Link State Packets) and for Operations, Administration, and 115 Maintenance (OAM) purposes such as Link Layer Discovery protocol 116 [IEEE standard 802.1AB-2009]. Thus the two clients require an 117 attachment mechanism that can be used to multiplex a number of 118 protocols. In addition it is essential to the correct operation of 119 the network layer that all of these protocols fate share. 121 Where the client LSR and server PE is co-located in the same 122 equipment, the data-link layer can be simplified to a point-to-point 123 Ethernet used to multiplex the various data-link types onto a 124 pseudowire. This is the method that described in this document. 126 Non-normative Appendix Appendix A provides information on alternative 127 approaches to providing a packet PW that were considered by PWE3 128 Working Group and the reasons for using the method defined in this 129 specification. 131 2. Network Reference Model 133 The network reference model for the packet pseudowire operating in an 134 MPLS network is shown in Figure 1. This is an extension of Figure 3 135 "Pre-processing within the PWE3 Network Reference Model" from 136 [RFC3985]. 138 PW PW 139 End Service End Service 140 | | 141 |<------- Pseudowire ------->| 142 | | 143 | Server | 144 | |<- PSN Tunnel ->| | 145 | V V | 146 ------- +-----+-----+ +-----+-----+ ------- 147 ) | | |================| | | ( 148 client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client 149 MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN 150 ) | | | | | | ( 151 ) | | |================| | | ( 152 ------- +-----+-----+ +-----+-----+ -------- 153 ^ ^ 154 | | 155 | | 156 |<---- Emulated Service----->| 157 | | 158 Virtual physical Virtual physical 159 termination termination 161 Figure 1: Packet PW Network Reference Model 163 In this model LSRs, LSR1 and LSR2, are part of the client MPLS PSN. 164 The PEs, PE1 and PE2 are part of the server PSN, that is to be used 165 to provide connectivity between the client LSRs. The attachment 166 circuit that is used to connect the MPLS LSRs to the PEs is a virtual 167 interface within the equipment. A packet pseudowire is used to 168 provide connectivity between these virtual interfaces. This packet 169 pseudowire is used to transport all of the required layer 2 and layer 170 3 between protocols between LSR1 and LSR2. 172 3. Client Network Layer Model 174 The packet PW appears as a single point-to-point link to the client 175 layer. Network Layer adjacency formation and maintenance between the 176 client equipments will the follow normal practice needed to support 177 the required relationship in the client layer. The assignment of 178 metrics for this point-to-point link is a matter for the client 179 layer. In a hop by hop routing network the metrics would normally be 180 assigned by appropriate configuration of the embedded client network 181 layer equipment (e.g. the embedded client LSR). Where the client was 182 using the packet PW as part of a traffic engineered path, it is up to 183 the operator of the client network to ensure that the server layer 184 operator provides the necessary service level agreement. 186 4. Forwarding Model 188 The packet PW forwarding model is illustrated in Figure 2. The 189 forwarding operation can be likened to a virtual private network 190 (VPN), in which a forwarding decision is first taken at the client 191 layer, an encapsulation is applied and then a second forwarding 192 decision is taken at the server layer. 194 +------------------------------------------------+ 195 | | 196 | +--------+ +--------+ | 197 | | | Pkt +-----+ | | | 198 ------+ +---------+ PW1 +--------+ +------ 199 | | Client | AC +-----+ | Server | | 200 Client | | LSR | | LSR | | Server 201 Network | | | Pkt +-----+ | | | Network 202 ------+ +---------+ PW2 +--------+ +------ 203 | | | AC +-----+ | | | 204 | +--------+ +--------+ | 205 | | 206 +------------------------------------------------+ 208 Figure 2: Packet PW Forwarding Model 210 A packet PW PE comprises three components, the client LSR, PW 211 processor and a server LSR. Note that [RFC3985] does not formally 212 indicate the presence of the server LSR because it does not concern 213 itself with the server layer. However it is useful in this document 214 to recognise that the server LSR exists. 216 It may be useful to first recall the operation of a layer 2 PW such 217 as an Ethernet PW [RFC4448] within this model. The client LSR is not 218 present and packets arrive directly on the attachment circuit (AC) 219 which is part of the client network. The PW function undertakes any 220 header processing, if configured to do so, it then optionally pushes 221 the PW control word (CW), and finally pushes the PW label. The PW 222 function then passes the packet to the LSR function which pushes the 223 label needed to reach the egress PE and forwards the packet to the 224 next hop in the server network. At the egress PE, the packet 225 typically arrives with the PW label at top of stack, the packet is 226 thus directed to the correct PW instance. The PW instance performs 227 any required reconstruction using, if necessary, the CW and the 228 packet is sent directly to the attachment circuit. 230 Now let us consider the case client layer MPLS traffic being carried 231 over a packet PW. An LSR belonging to the client layer is embedded 232 within the PE equipment. This is a type of native service processing 233 element [RFC3985]. The client LSR determines the next hop in the 234 client layer, and pushes the label needed by the next hop in the 235 client layer. It then encapsulates the packet in an Ethernet header 236 setting the Ethertype to MPLS. The client LSR then passes the packet 237 to the correct PW instance. The PW instance then proceeds as defined 238 for an Ethernet PW [RFC4448] by optionally pushing the control word, 239 then pushing the PW label, and finally handing the packet to the 240 server layer LSR for delivery to the egress PE in the server layer. 242 At the egress PE in the server layer, the packet is first processed 243 by the server LSR which uses the PW label to pass the packet to the 244 correct PW instance. This PW instance processed the packet as 245 described in RFC4448. The resultant Ethernet encapsulated client 246 packet is then passed to the egress client LSR which then processes 247 the packet in the normal manner. 249 Note that although the description above is written in terms of the 250 behaviour of an MPLS LSR, the processing model would be similar for 251 an IP packet, or indeed any other protocol type. 253 Note that the semantics of the PW between the client LSRs is a point- 254 to-point link. 256 5. Packet PW Encapsulation 258 The client network work layer packet encapsulation into a packet PW 259 is shown in Figure 3. 261 +-------------------------------+ 262 | Client | 263 | Network Layer | 264 | packet | n octets 265 | | 266 +-------------------------------+ 267 | | 268 | Ethernet | 14 octets 269 | Header | 270 | +---------------+ 271 | | 272 +---------------+---------------+ 273 | Optional Control Word | 4 octets 274 +-------------------------------+ 275 | PW label | 4 octets 276 +-------------------------------+ 277 | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) 278 +-------------------------------+ 280 Figure 3: Packet PW Encapsulation 282 This conforms to the PW protocols stack as defined in [RFC4448]. The 283 protocol stack is unremarkable except to note that the stack does not 284 retain 32 bit alignment between the virtual Ethernet header and the 285 PW optional control word (or the PW label when the optional 286 components are not present in the PW header). This loss of 32 bit of 287 alignment is necessary to preserve backwards compatibility with the 288 Ethernet PW design [RFC4448] 290 Ethernet Raw Mode (PW type 5) MUST be used for the packet PW. 292 The PEs MAY use a local Ethernet address for the Ethernet header used 293 to encapsulate the client network layer packet. Alternatively the 294 PEs may use the following procedure. 296 IANA are requested to allocate two unicast Ethernet addresses 297 [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB). 298 PacketPWEthA is the value lower Ethernet address and PacketPWEthB is 299 the higher value Ethernet address. Where [RFC4447] signalling is 300 used to set up the PW, the LDP peers compare IP addresses and with 301 the PE with the higher IP address uses PacketPWEthA, whilst the LDP 302 peer with the lower IP address uses PacketPWEthB. 304 Where no signalling PW protocol is used, suitable Ethernet addresses 305 MUST be configured at each PE. 307 Not withstanding the fact that this PW represents a point-to-point 308 connection, some client layer protocols require the use of a 309 destination multicast address in the Ethernet encapsulation. This 310 mode of operation MUST be supported. 312 6. Ethernet Functional Restrictions 314 The use of Ethernet as the encapsulation mechanism for traffic 315 between the server LSRs is a convenience based on the widespread 316 availability of existing hardware. In this application there is no 317 requirement for any Ethernet feature other than its protocol 318 multiplexing capability. Thus, for example, the Ethernet OAM is NOT 319 REQUIRED. 321 The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q 322 between PEs is not supported. 324 Point-to-multipoint and multipoint-to-multipoint operation of the 325 virtual Ethernet is not supported. 327 7. Congestion Considerations 329 A packet pseudowire is normally used to carry IP, MPLS and their 330 associated support protocols over an MPLS network. There are no 331 congestion considerations beyond those that ordinarily apply to an IP 332 or MPLS network. Where the packet protocol being carried is not IP 333 or MPLS and the traffic volumes are greater than that ordinarily 334 associated with the support protocols in an IP or MPLS network, the 335 congestion considerations developed for PWs apply [RFC3985], 336 [RFC5659]. 338 8. Security Considerations 340 The virtual Ethernet approach to packet PW introduces no new security 341 risks. A more detailed discussion of pseudowire security is given in 342 [RFC3985], [RFC4447] and [RFC3916]. 344 9. IANA Considerations 346 IANA are requested to allocate two Ethernet unicast addresses from 347 the IANA Ethernet Address Block - Unicast Use 348 Dotted Decimal Description Reference 349 ------------------- ---------------- --------- 351 000.00x.000 PacketPWEthA [This RFC] 352 000.00x.001 PacketPWEthB [This RFC] 354 The value of x is open for IANA to choose. A value of 3 is suggested. 356 10. Acknowledgements 358 The authors acknowledge the contribution make by Sami Boutros, Giles 359 Herron, Siva Sivabalan and David Ward to this document. 361 11. References 363 11.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 369 Heron, "Pseudowire Setup and Maintenance Using the Label 370 Distribution Protocol (LDP)", RFC 4447, April 2006. 372 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 373 "Encapsulation Methods for Transport of Ethernet over MPLS 374 Networks", RFC 4448, April 2006. 376 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 377 for IEEE 802 Parameters", BCP 141, RFC 5342, 378 September 2008. 380 11.2. Informative References 382 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 383 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 384 September 2004. 386 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 387 Edge (PWE3) Architecture", RFC 3985, March 2005. 389 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 390 Report on MPLS Architectural Considerations for a 391 Transport Profile", RFC 5317, February 2009. 393 [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for 394 Creating Internet Drafts and RFCs", RFC 5385, 395 February 2010. 397 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 398 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 399 October 2009. 401 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 402 Berger, "A Framework for MPLS in Transport Networks", 403 RFC 5921, July 2010. 405 Appendix A. Encapsulation Approaches Considered 407 This appendix is non-normative. 409 A number of approaches to the design of a packet pseudowire (PW) were 410 investigated by the PWE3 Working Group and were discussed in IETF 411 meetings and on the PWE3 list. This section describes the approaches 412 that were analysed and the technical issues that the authors took 413 into consideration in arriving at the approach described in the main 414 body of this document. This appendix is provided so that engineers 415 considering alternative optimizations can have access to the rational 416 for the selection of the approach described above. 418 In a typical network there are usually no more that four network 419 layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS 420 although any solution needs to be scalable to a larger number of 421 protocols. The approaches considered in this document all satisfy 422 this minimum requirement, but vary in their ability to support larger 423 numbers of network layer protocols. 425 Additionally it is beneficial if the complete set of protocols 426 carried over the network between in support of a set of CE peers fate 427 share. It is additionally beneficial if a single OAM session can be 428 used to monitor the behaviour of this complete set. During the 429 investigation various views were expressed as to where on the scale 430 from absolutely required to "nice to have" these benefits lay, but in 431 the end they were not a factor in reaching our conclusion. 433 There are four candidate approaches that have been analysed: 435 1. A protocol identifier (PID) in the PW Control Word (CW) 437 2. A PID label 438 3. Parallel PWs - one per protocol. 440 4. Virtual Ethernet 442 A.1. A Protocol Identifier in the Control Word 444 This is the approach that we proposed in draft 0 of this document . 445 The proposal was that a Protocol Identifier (PID) would included in 446 the PW control word (CW), by appending it to the generic control word 447 [RFC5385] to make a 6 byte CW (the version 0 draft actually included 448 two reserved bytes to provide 32bit alignment, but let us assume that 449 was optimized out). A variant of this is just to use a 2 byte PID 450 without a control word. 452 This is a simple approach, and is basically a virtual PPP interface 453 without the PPP control protocol. This has a smaller MTU than for 454 example a virtual Ethernet would need, however in forwarding terms it 455 is not as simple as the PID label or multiple PW approaches described 456 next, and may not be deployable on a number of existing hardware 457 platforms. 459 A.2. PID Label 461 This is the approach that we described in Version 2 of this document. 462 The in this mechanism the PID is indicated by including a label after 463 the PW label that indicates the protocol type as shown in Figure 4. 465 +-------------------------------+ 466 | Client | 467 | Network Layer | 468 | packet | n octets 469 | | 470 +-------------------------------+ 471 | Optional Control Word | 4 octets 472 +-------------------------------+ 473 | PID Label (S=1) | 4 Octets 474 +-------------------------------+ 475 | PW label | 4 octets 476 +-------------------------------+ 477 | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) 478 +-------------------------------+ 480 Figure 4: Encapsulation of a pseudowire with a pseudowire load 481 balancing label 483 In the PID Label approach a new Label Distribution protocol (LDP) 484 Forwarding Equivalence Class (FEC) element is used to signal the 485 mapping between protocol type and the PID label. This approach 486 complies with RFC3031. 488 A similar approach to PID label is described in Section 3.4.5 of 489 [RFC5921]. In this case when the client is a network layer packet 490 service such as IP or MPLS, a service label and demultiplexer label 491 (which may be combined) is used to provide the necessary 492 identifications needed to carry this traffic over an LSP. 494 The authors surveyed the hardware designs produced by a number of 495 companies across the industry and concluded that whilst the approach 496 complies with the MPLS architecture, it may conflict with a number of 497 designer's interpretation of the existing MPLS architecture. This 498 led to concerns that the approach may result in unexpected 499 difficulties in the future. Specifically there is an assumption in 500 many designs that a forwarding decision should be made on the basis 501 of a single label. Whilst the approach is attractive, it cannot be 502 supported by many commodity chip sets and this would require new 503 hardware which would increase the cost of deployment and delay the 504 introduction of a packet PW service. 506 A.3. Parallel PWs 508 In this approach one PW is constructed for each protocol type that 509 must be carried between the PEs. Thus a complete packet PW would 510 therefore consist of a bundle of PWs . This model would be very 511 simple and efficient from a forwarding point of view. The number of 512 parallel PWs required would normally be relatively small. In a 513 typical network there are usually no more that four network layer 514 protocols that need to be supported: IPv4, IPv6, MPLS and CLNS 515 although any solution needs to be scalable to a larger number of 516 protocols. 518 The are a number of serious downsides with this approach: 520 1. From an operational point of view the lack of fate sharing 521 between the protocol types can lead to complex faults which are 522 difficult to diagnose. 524 2. There is an undesirable trade off in the OAM related to the first 525 point. Either we would have to run an OAM on each PW and bind 526 them together which lead to significant protocol and software 527 complexity and does not scale well. Alternatively we would need 528 to run a single OAM session on one of the PWs as a proxy for the 529 others and the diagnose any more complex failure on a case by 530 case basis. To some extent the issue of fate sharing between 531 protocol in the bundle (for example the assumed fate sharing 532 between CLNS and IP in IS-IS) can be mitigated through the use of 533 BFD. 535 3. The need to configure manage and synchronize the behaviour of a 536 group of PWs as if they were a single PW leads to an increase in 537 control plane complexity. 539 The Parallel PW mechanism is therefore an approach which simplifies 540 the forwarding plane, but only at a cost of a considerable increase 541 in other aspects of the design and in particular operation of the PW. 543 A.4. Virtual Ethernet 545 Using a virtual Ethernet to provide a packet PW would require PEs to 546 include a virtual (internal) Ethernet interface and then to use an 547 Ethernet PW [RFC4448] to carry the user traffic. This is 548 conceptually simple and can be implemented today without any further 549 standards action, although there are a number of applicability 550 considerations that it is useful to draw to the attention of the 551 community. 553 Conceptually this is a simple approach and some deployed equipments 554 can already do this. However the requirement to run a complete 555 Ethernet adjacency lead us to conclude that there was a need to 556 identify a simpler approach. The packets encapsulated in an Ethernet 557 header have a larger MTU than the other approaches, although this is 558 not considered to be an issue on the networks needing to carry packet 559 PWs. 561 The virtual Ethernet mechanism was the first approach that the 562 authors considered, before the merits of the other approaches 563 appeared to make them more attractive. As we shall see below 564 however, the other approaches were not without issues and it appears 565 that the virtual Ethernet is preferred approach to providing a packet 566 PW. 568 A.5. Recommended Encapsulation 570 The operational complexity and the breaking of fate sharing 571 assumptions associated with the parallel PW approach would suggest 572 that this is not an approach that should be further pursued. 574 The PID Label approach gives rise to the concerns that it will break 575 implicit behavioural and label stack size assumptions in many 576 implementations. Whilst those assumptions may be addressed with new 577 hardware this would delay the introduction of the technology to the 578 point where it was unlikely to gain acceptance in competition with an 579 approach that needed no new protocol design and is already 580 supportable on many existing hardware platforms. 582 The PID in the CW leads to the most compact protocol stack, is simple 583 and requires minimal protocol work. However it is a new forwarding 584 design, and apart from the issue of the larger packet header and the 585 simpler adjacency formation offers no advantage over the virtual 586 Ethernet. 588 The above considerations bring us back to the virtual Ethernet, which 589 is a well known protocol stack, with a well known (internal) client 590 interface. It is already implemented in many hardware platforms and 591 is therefore readily deployable. The authors conclude that having 592 considered a number of initially promising alternatives, the 593 simplicity and existing hardware make the virtual Ethernet approach 594 to the packet PW the most attractive solution. 596 Authors' Addresses 598 Stewart Bryant (editor) 599 Cisco Systems 600 250, Longwater, Green Park, 601 Reading, Berks RG2 6GB 602 UK 604 Email: stbryant@cisco.com 606 Luca Martini 607 Cisco Systems 608 9155 East Nichols Avenue, Suite 400 609 Englewood, CO 80112 610 USA 612 Email: lmartini@cisco.com 614 George Swallow 615 Cisco Systems 616 1414 Massachusetts Ave 617 Boxborough, MA 01719 618 USA 620 Email: swallow@cisco.com 621 URI: 623 Andy Malis 624 Verizon Communications 625 117 West St. 626 Waltham, MA 02451 627 USA 629 Email: andrew.g.malis@verizon.com