idnits 2.17.1 draft-ietf-pwe3-packet-pw-04.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 (May 12, 2012) is 4338 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: November 13, 2012 Cisco Systems 6 A. Malis 7 Verizon Communications 8 May 12, 2012 10 Packet Pseudowire Encapsulation over an MPLS PSN 11 draft-ietf-pwe3-packet-pw-04.txt 13 Abstract 15 This document describes a pseudowire mechanism that is used to 16 transport a packet service over an MPLS PSN in 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 November 13, 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 and IEEE 802.1 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 Appendix A provides information on alternative approaches to 127 providing a packet PW that were considered by PWE3 Working Group and 128 the reasons for using the method defined in this specification. 130 2. Network Reference Model 132 The network reference model for the packet pseudowire operating in an 133 MPLS network is shown in Figure 1. This is an extension of Figure 3 134 "Pre-processing within the PWE3 Network Reference Model" from 135 [RFC3985]. 137 PW PW 138 End Service End Service 139 | | 140 |<------- Pseudowire ------->| 141 | | 142 | Server | 143 | |<- PSN Tunnel ->| | 144 | V V | 145 ------- +-----+-----+ +-----+-----+ ------- 146 ) | | |================| | | ( 147 client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client 148 MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN 149 ) | | | | | | ( 150 ) | | |================| | | ( 151 ------- +-----+-----+ +-----+-----+ -------- 152 ^ ^ 153 | | 154 | | 155 |<---- Emulated Service----->| 156 | | 157 Virtual physical Virtual physical 158 termination termination 160 Figure 1: Packet PW Network Reference Model 162 In this model LSRs, LSR1 and LSR2, are part of the client MPLS PSN. 163 The PEs, PE1 and PE2 are part of the server PSN, that is to be used 164 to provide connectivity between the client LSRs. The attachment 165 circuit that is used to connect the MPLS LSRs to the PEs is a virtual 166 interface within the equipment. A packet pseudowire is used to 167 provide connectivity between these virtual interfaces. This packet 168 pseudowire is used to transport all of the required layer 2 and layer 169 3 between protocols between LSR1 and LSR2. 171 3. Client Network Layer Model 173 The packet PW appears as a single point-to-point link to the client 174 layer. Network Layer adjacency formation and maintenance between the 175 client equipments will the follow normal practice needed to support 176 the required relationship in the client layer. The assignment of 177 metrics for this point-to-point link is a matter for the client 178 layer. In a hop by hop routing network the metrics would normally be 179 assigned by appropriate configuration of the embedded client network 180 layer equipment (e.g. the embedded client LSR). Where the client was 181 using the packet PW as part of a traffic engineered path, it is up to 182 the operator of the client network to ensure that the server layer 183 operator provides the necessary service level agreement. 185 4. Forwarding Model 187 The packet PW forwarding model is illustrated in Figure 2. The 188 forwarding operation can be likened to a virtual private network 189 (VPN), in which a forwarding decision is first taken at the client 190 layer, an encapsulation is applied and then a second forwarding 191 decision is taken at the server layer. 193 +------------------------------------------------+ 194 | | 195 | +--------+ +--------+ | 196 | | | Pkt +-----+ | | | 197 ------+ +---------+ PW1 +--------+ +------ 198 | | Client | AC +-----+ | Server | | 199 Client | | LSR | | LSR | | Server 200 Network | | | Pkt +-----+ | | | Network 201 ------+ +---------+ PW2 +--------+ +------ 202 | | | AC +-----+ | | | 203 | +--------+ +--------+ | 204 | | 205 +------------------------------------------------+ 207 Figure 2: Packet PW Forwarding Model 209 A packet PW PE comprises three components, the client LSR, PW 210 processor and a server LSR. Note that [RFC3985] does not formally 211 indicate the presence of the server LSR because it does not concern 212 itself with the server layer. However it is useful in this document 213 to recognise that the server LSR exists. 215 It may be useful to first recall the operation of a layer 2 PW such 216 as an Ethernet PW [RFC4448] within this model. The client LSR is not 217 present and packets arrive directly on the attachment circuit (AC) 218 which is part of the client network. The PW function undertakes any 219 header processing, if configured to do so, it then optionally pushes 220 the PW control word (CW), and finally pushes the PW label. The PW 221 function then passes the packet to the LSR function which pushes the 222 label needed to reach the egress PE and forwards the packet to the 223 next hop in the server network. At the egress PE, the packet 224 typically arrives with the PW label at top of stack, the packet is 225 thus directed to the correct PW instance. The PW instance performs 226 any required reconstruction using, if necessary, the CW and the 227 packet is sent directly to the attachment circuit. 229 Now let us consider the case client layer MPLS traffic being carried 230 over a packet PW. An LSR belonging to the client layer is embedded 231 within the PE equipment. This is a type of native service processing 232 element [RFC3985]. The client LSR determines the next hop in the 233 client layer, and pushes the label needed by the next hop in the 234 client layer. It then encapsulates the packet in an Ethernet header 235 setting the Ethertype to MPLS. The client LSR then passes the packet 236 to the correct PW instance. The PW instance then proceeds as defined 237 for an Ethernet PW [RFC4448] by optionally pushing the control word, 238 then pushing the PW label, and finally handing the packet to the 239 server layer LSR for delivery to the egress PE in the server layer. 241 At the egress PE in the server layer, the packet is first processed 242 by the server LSR which uses the PW label to pass the packet to the 243 correct PW instance. This PW instance processed the packet as 244 described in RFC4448. The resultant Ethernet encapsulated client 245 packet is then passed to the egress client LSR which then processes 246 the packet in the normal manner. 248 Note that although the description above is written in terms of the 249 behaviour of an MPLS LSR, the processing model would be similar for 250 an IP packet, or indeed any other protocol type. 252 Note that the semantics of the PW between the client LSRs is a point- 253 to-point link. 255 5. Packet PW Encapsulation 257 The client network work layer packet encapsulation into a packet PW 258 is shown in Figure 3. 260 +-------------------------------+ 261 | Client | 262 | Network Layer | 263 | packet | n octets 264 | | 265 +-------------------------------+ 266 | | 267 | Ethernet | 14 octets 268 | Header | 269 | +---------------+ 270 | | 271 +---------------+---------------+ 272 | Optional Control Word | 4 octets 273 +-------------------------------+ 274 | PW label | 4 octets 275 +-------------------------------+ 276 | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) 277 +-------------------------------+ 279 Figure 3: Packet PW Encapsulation 281 This conforms to the PW protocols stack as defined in [RFC4448]. The 282 protocol stack is unremarkable except to note that the stack does not 283 retain 32 bit alignment between the virtual Ethernet header and the 284 PW optional control word (or the PW label when the optional 285 components are not present in the PW header). This loss of 32 bit of 286 alignment is necessary to preserve backwards compatibility with the 287 Ethernet PW design [RFC4448] 289 Ethernet Raw Mode (PW type 5) MUST be used for the packet PW. 291 The PEs MAY use a local Ethernet address for the Ethernet header used 292 to encapsulate the client network layer packet, or MAY use the 293 special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as 294 described below. 296 IANA is requested to allocate [ed note: RFC Editor will change to 297 "has allocated"] two unicast Ethernet addresses [RFC5342] for use 298 with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". 299 Where [RFC4447] signalling is used to set up the PW, the LDP peers 300 numerically compare their IP addresses. The LDP PE with the higher 301 value IP address will use PacketPWEthA, whilst the LDP peer with the 302 lower value IP address uses PacketPWEthB. 304 Where no signalling PW protocol is used, suitable Ethernet addresses 305 MUST be configured at each PE. 307 Although this PW represents a point-to-point connection, the use of a 308 multicast destination address in the Ethernet encapsulation is 309 REQUIRED by some client layer protocols. Peers MUST be prepared to 310 handle a multicast destination address in the Ethernet encapsulation. 312 6. Ethernet and IEEE 802.1 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, a server LSR is not 319 required to implement the Ethernet OAM. 321 The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q 322 tagging 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 A number of approaches to the design of a packet pseudowire (PW) were 408 investigated by the PWE3 Working Group and were discussed in IETF 409 meetings and on the PWE3 list. This section describes the approaches 410 that were analysed and the technical issues that the authors took 411 into consideration in arriving at the approach described in the main 412 body of this document. This appendix is provided so that engineers 413 considering alternative optimizations can have access to the rational 414 for the selection of the approach described above. 416 In a typical network there are usually no more that four network 417 layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS 418 although any solution needs to be scalable to a larger number of 419 protocols. The approaches considered in this document all satisfy 420 this minimum requirement, but vary in their ability to support larger 421 numbers of network layer protocols. 423 Additionally it is beneficial if the complete set of protocols 424 carried over the network between in support of a set of CE peers fate 425 share. It is additionally beneficial if a single OAM session can be 426 used to monitor the behaviour of this complete set. During the 427 investigation various views were expressed as to where on the scale 428 from absolutely required to "nice to have" these benefits lay, but in 429 the end they were not a factor in reaching our conclusion. 431 There are four candidate approaches that have been analysed: 433 1. A protocol identifier (PID) in the PW Control Word (CW) 435 2. A PID label 437 3. Parallel PWs - one per protocol. 439 4. Virtual Ethernet 441 A.1. A Protocol Identifier in the Control Word 443 This is the approach that we proposed in draft 0 of this document . 444 The proposal was that a Protocol Identifier (PID) would included in 445 the PW control word (CW), by appending it to the generic control word 446 [RFC5385] to make a 6 byte CW (the version 0 draft actually included 447 two reserved bytes to provide 32bit alignment, but let us assume that 448 was optimized out). A variant of this is just to use a 2 byte PID 449 without a control word. 451 This is a simple approach, and is basically a virtual PPP interface 452 without the PPP control protocol. This has a smaller MTU than for 453 example a virtual Ethernet would need, however in forwarding terms it 454 is not as simple as the PID label or multiple PW approaches described 455 next, and may not be deployable on a number of existing hardware 456 platforms. 458 A.2. PID Label 460 This is the approach that we described in Version 2 of this document. 461 The in this mechanism the PID is indicated by including a label after 462 the PW label that indicates the protocol type as shown in Figure 4. 464 +-------------------------------+ 465 | Client | 466 | Network Layer | 467 | packet | n octets 468 | | 469 +-------------------------------+ 470 | Optional Control Word | 4 octets 471 +-------------------------------+ 472 | PID Label (S=1) | 4 Octets 473 +-------------------------------+ 474 | PW label | 4 octets 475 +-------------------------------+ 476 | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) 477 +-------------------------------+ 479 Figure 4: Encapsulation of a pseudowire with a pseudowire load 480 balancing label 482 In the PID Label approach a new Label Distribution protocol (LDP) 483 Forwarding Equivalence Class (FEC) element is used to signal the 484 mapping between protocol type and the PID label. This approach 485 complies with RFC3031. 487 A similar approach to PID label is described in Section 3.4.5 of 488 [RFC5921]. In this case when the client is a network layer packet 489 service such as IP or MPLS, a service label and demultiplexer label 490 (which may be combined) is used to provide the necessary 491 identifications needed to carry this traffic over an LSP. 493 The authors surveyed the hardware designs produced by a number of 494 companies across the industry and concluded that whilst the approach 495 complies with the MPLS architecture, it may conflict with a number of 496 designer's interpretation of the existing MPLS architecture. This 497 led to concerns that the approach may result in unexpected 498 difficulties in the future. Specifically there is an assumption in 499 many designs that a forwarding decision should be made on the basis 500 of a single label. Whilst the approach is attractive, it cannot be 501 supported by many commodity chip sets and this would require new 502 hardware which would increase the cost of deployment and delay the 503 introduction of a packet PW service. 505 A.3. Parallel PWs 507 In this approach one PW is constructed for each protocol type that 508 must be carried between the PEs. Thus a complete packet PW would 509 therefore consist of a bundle of PWs . This model would be very 510 simple and efficient from a forwarding point of view. The number of 511 parallel PWs required would normally be relatively small. In a 512 typical network there are usually no more that four network layer 513 protocols that need to be supported: IPv4, IPv6, MPLS and CLNS 514 although any solution needs to be scalable to a larger number of 515 protocols. 517 The are a number of serious downsides with this approach: 519 1. From an operational point of view the lack of fate sharing 520 between the protocol types can lead to complex faults which are 521 difficult to diagnose. 523 2. There is an undesirable trade off in the OAM related to the first 524 point. Either we would have to run an OAM on each PW and bind 525 them together which lead to significant protocol and software 526 complexity and does not scale well. Alternatively we would need 527 to run a single OAM session on one of the PWs as a proxy for the 528 others and the diagnose any more complex failure on a case by 529 case basis. To some extent the issue of fate sharing between 530 protocol in the bundle (for example the assumed fate sharing 531 between CLNS and IP in IS-IS) can be mitigated through the use of 532 BFD. 534 3. The need to configure manage and synchronize the behaviour of a 535 group of PWs as if they were a single PW leads to an increase in 536 control plane complexity. 538 The Parallel PW mechanism is therefore an approach which simplifies 539 the forwarding plane, but only at a cost of a considerable increase 540 in other aspects of the design and in particular operation of the PW. 542 A.4. Virtual Ethernet 544 Using a virtual Ethernet to provide a packet PW would require PEs to 545 include a virtual (internal) Ethernet interface and then to use an 546 Ethernet PW [RFC4448] to carry the user traffic. This is 547 conceptually simple and can be implemented today without any further 548 standards action, although there are a number of applicability 549 considerations that it is useful to draw to the attention of the 550 community. 552 Conceptually this is a simple approach and some deployed equipments 553 can already do this. However the requirement to run a complete 554 Ethernet adjacency lead us to conclude that there was a need to 555 identify a simpler approach. The packets encapsulated in an Ethernet 556 header have a larger MTU than the other approaches, although this is 557 not considered to be an issue on the networks needing to carry packet 558 PWs. 560 The virtual Ethernet mechanism was the first approach that the 561 authors considered, before the merits of the other approaches 562 appeared to make them more attractive. As we shall see below 563 however, the other approaches were not without issues and it appears 564 that the virtual Ethernet is preferred approach to providing a packet 565 PW. 567 A.5. Recommended Encapsulation 569 The operational complexity and the breaking of fate sharing 570 assumptions associated with the parallel PW approach would suggest 571 that this is not an approach that should be further pursued. 573 The PID Label approach gives rise to the concerns that it will break 574 implicit behavioural and label stack size assumptions in many 575 implementations. Whilst those assumptions may be addressed with new 576 hardware this would delay the introduction of the technology to the 577 point where it was unlikely to gain acceptance in competition with an 578 approach that needed no new protocol design and is already 579 supportable on many existing hardware platforms. 581 The PID in the CW leads to the most compact protocol stack, is simple 582 and requires minimal protocol work. However it is a new forwarding 583 design, and apart from the issue of the larger packet header and the 584 simpler adjacency formation offers no advantage over the virtual 585 Ethernet. 587 The above considerations bring us back to the virtual Ethernet, which 588 is a well known protocol stack, with a well known (internal) client 589 interface. It is already implemented in many hardware platforms and 590 is therefore readily deployable. The authors conclude that having 591 considered a number of initially promising alternatives, the 592 simplicity and existing hardware make the virtual Ethernet approach 593 to the packet PW the most attractive solution. 595 Authors' Addresses 597 Stewart Bryant (editor) 598 Cisco Systems 599 250, Longwater, Green Park, 600 Reading, Berks RG2 6GB 601 UK 603 Email: stbryant@cisco.com 605 Luca Martini 606 Cisco Systems 607 9155 East Nichols Avenue, Suite 400 608 Englewood, CO 80112 609 USA 611 Email: lmartini@cisco.com 613 George Swallow 614 Cisco Systems 615 1414 Massachusetts Ave 616 Boxborough, MA 01719 617 USA 619 Email: swallow@cisco.com 620 URI: 622 Andy Malis 623 Verizon Communications 624 117 West St. 625 Waltham, MA 02451 626 USA 628 Email: andrew.g.malis@verizon.com