From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6658.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc6658.txt (limited to 'doc/rfc/rfc6658.txt') diff --git a/doc/rfc/rfc6658.txt b/doc/rfc/rfc6658.txt new file mode 100644 index 0000000..5cf9423 --- /dev/null +++ b/doc/rfc/rfc6658.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Bryant, Ed. +Request for Comments: 6658 L. Martini +Category: Standards Track G. Swallow +ISSN: 2070-1721 Cisco Systems + A. Malis + Verizon Communications + July 2012 + + + Packet Pseudowire Encapsulation over an MPLS PSN + +Abstract + + This document describes a pseudowire mechanism that is used to + transport a packet service over an MPLS PSN in the case where the + client Label Switching Router (LSR) and the server Provider Edge + equipments are co-resident in the same equipment. This pseudowire + mechanism may be used to carry all of the required layer 2 and layer + 3 protocols between the pair of client LSRs. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6658. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Bryant, et al. Standards Track [Page 1] + +RFC 6658 Packet PW July 2012 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4 + 3. Client Network-Layer Model . . . . . . . . . . . . . . . . . . 5 + 4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 7 + 6. Ethernet and IEEE 802.1 Functional Restrictions . . . . . . . 8 + 7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 + Appendix A. Encapsulation Approaches Considered . . . . . . . . . 11 + A.1. A Protocol Identifier in the Control Word . . . . . . . . 11 + A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 12 + A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 13 + A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 13 + A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 2] + +RFC 6658 Packet PW July 2012 + + +1. Introduction + + There is a need to provide a method of carrying a packet service over + an MPLS PSN in a way that provides isolation between the two + networks. The server MPLS network may be an MPLS network or a + network conforming to the MPLS Transport Profile (MPLS-TP) [RFC5317]. + The client may also be either an MPLS network or a network conforming + to the MPLS-TP. Considerations regarding the use of an MPLS network + as a server for an MPLS-TP network are outside the scope of this + document. + + Where the client equipment is connected to the server equipment via a + physical interface, the same data-link type must be used to attach + the clients to the Provider Edge (PE) equipments, and a pseudowire + (PW) of the same type as the data-link must be used [RFC3985]. The + reason that interworking between different physical and data-link + attachment types is specifically disallowed in the pseudowire + architecture is because this is a complex task and not a simple bit- + mapping exercise. The interworking is not limited to the physical + and data-link interfaces and the state-machines. It also requires a + compatible approach to the formation of the adjacencies between + attached client network equipment. As an example, the reader should + consider the differences between router adjacency formation on a + point-to-point link compared to a multipoint-to-multipoint interface + (e.g., Ethernet). + + A further consideration is that two adjacent MPLS Label Switching + Routers (LSRs) do not simply exchange MPLS packets. They exchange IP + packets for adjacency formation, control, routing, label exchange, + management, and monitoring purposes. In addition, they may exchange + data-link packets as part of routing (e.g., IS-IS Hellos and IS-IS + Link State Packets) and for Operations, Administration, and + Maintenance (OAM) purposes such as the Link-Layer Discovery Protocol + [IEEE.802.1AB.2009]. Thus, the two clients require an attachment + mechanism that can be used to multiplex a number of protocols. In + addition, it is essential to the correct operation of the network + layer that all of these protocols fate share. + + Where the client LSR and server PE are co-located in the same + equipment, the data-link layer can be simplified to a point-to-point + Ethernet used to multiplex the various data-link types onto a + pseudowire. This is the method described in this document. + + Appendix A provides information on alternative approaches to + providing a packet PW that were considered by the PWE3 Working Group + and the reasons for using the method defined in this specification. + + + + + +Bryant, et al. Standards Track [Page 3] + +RFC 6658 Packet PW July 2012 + + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Network Reference Model + + The network reference model for the packet pseudowire operating in an + MPLS network is shown in Figure 1. This is an extension of Figure 3 + "Pre-processing within the PWE3 Network Reference Model" from + [RFC3985]. + + PW PW + End Service End Service + | | + |<------- Pseudowire ------->| + | | + | Server | + | |<- PSN Tunnel ->| | + | V V | + ------- +-----+-----+ +-----+-----+ ------- + ) | | |================| | | ( + Client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client + MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN + ) | | | | | | ( + ) | | |================| | | ( + ------- +-----+-----+ +-----+-----+ -------- + ^ ^ + | | + | | + |<---- Emulated Service----->| + | | + Virtual physical Virtual physical + termination termination + + Figure 1: Packet PW Network Reference Model + + In this model, the LSRs (LSR1 and LSR2) are part of the client MPLS + PSN. The PEs (PE1 and PE2) are part of the server PSN that is to be + used to provide connectivity between the client LSRs. The attachment + circuit that is used to connect the MPLS LSRs to the PEs is a virtual + interface within the equipment. A packet pseudowire is used to + provide connectivity between these virtual interfaces. This packet + pseudowire is used to transport all of the required layer 2 and layer + 3 protocols between LSR1 and LSR2. + + + + + +Bryant, et al. Standards Track [Page 4] + +RFC 6658 Packet PW July 2012 + + +3. Client Network-Layer Model + + The packet PW appears as a single point-to-point link to the client + layer. Network-layer adjacency formation and maintenance between the + client equipments will follow the normal practice needed to support + the required relationship in the client layer. The assignment of + metrics for this point-to-point link is a matter for the client + layer. In a hop-by-hop routing network, the metrics would normally + be assigned by appropriate configuration of the embedded client + network-layer equipment (e.g., the embedded client LSR). Where the + client was using the packet PW as part of a traffic-engineered path, + it is up to the operator of the client network to ensure that the + server-layer operator provides the necessary service-level agreement. + +4. Forwarding Model + + The packet PW forwarding model is illustrated in Figure 2. The + forwarding operation can be likened to a virtual private network + (VPN), in which a forwarding decision is first taken at the client + layer, an encapsulation is applied, and then a second forwarding + decision is taken at the server layer. + + +------------------------------------------------+ + | | + | +--------+ +--------+ | + | | | Pkt +-----+ | | | + ------+ +---------+ PW1 +--------+ +------ + | | Client | AC +-----+ | Server | | + Client | | LSR | | LSR | | Server + Network | | | Pkt +-----+ | | | Network + ------+ +---------+ PW2 +--------+ +------ + | | | AC +-----+ | | | + | +--------+ +--------+ | + | | + +------------------------------------------------+ + + Figure 2: Packet PW Forwarding Model + + A packet PW PE comprises three components: the client LSR, a PW + processor, and a server LSR. Note that [RFC3985] does not formally + indicate the presence of the server LSR because it does not concern + itself with the server layer. However it is useful in this document + to recognize that the server LSR exists. + + It may be useful to first recall the operation of a layer 2 PW such + as an Ethernet PW [RFC4448] within this model. The client LSR is not + present, and packets arrive directly on the attachment circuit (AC) + that is part of the client network. The PW function undertakes any + + + +Bryant, et al. Standards Track [Page 5] + +RFC 6658 Packet PW July 2012 + + + header processing, if configured to do so; it then optionally pushes + the PW control word (CW) and finally pushes the PW label. The PW + function then passes the packet to the LSR function, which pushes the + label needed to reach the egress PE and forwards the packet to the + next hop in the server network. At the egress PE, the packet + typically arrives with the PW label at the top of the stack; the + packet is thus directed to the correct PW instance. The PW instance + performs any required reconstruction using, if necessary, the CW, and + the packet is sent directly to the attachment circuit. + + Now let us consider the case of client-layer MPLS traffic being + carried over a packet PW. An LSR belonging to the client layer is + embedded within the PE equipment. This is a type of native service + processing element [RFC3985]. The client LSR determines the next hop + in the client layer, and pushes the label needed by the next hop in + the client layer. It then encapsulates the packet in an Ethernet + header setting the Ethertype to MPLS, and the client LSR passes the + packet to the correct PW instance. The PW instance then proceeds as + defined for an Ethernet PW [RFC4448] by optionally pushing the + control word, then pushing the PW label, and finally handing the + packet to the server-layer LSR for delivery to the egress PE in the + server layer. + + At the egress PE in the server layer, the packet is first processed + by the server LSR, which uses the PW label to pass the packet to the + correct PW instance. This PW instance processes the packet as + described in [RFC4448]. The resultant Ethernet encapsulated client + packet is then passed to the egress client LSR, which then processes + the packet in the normal manner. + + Note that although the description above is written in terms of the + behavior of an MPLS LSR, the processing model would be similar for an + IP packet or any other protocol type. + + Note that the semantics of the PW between the client LSRs is a point- + to-point link. + + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 6] + +RFC 6658 Packet PW July 2012 + + +5. Packet PW Encapsulation + + The client network-layer packet encapsulation into a packet PW is + shown in Figure 3. + + +-------------------------------+ + | Client | + | Network-Layer | + | Packet | n octets + | | + +-------------------------------+ + | | + | Ethernet | 14 octets + | Header | + | +---------------+ + | | + +---------------+---------------+ + | Optional Control Word | 4 octets + +-------------------------------+ + | PW Label | 4 octets + +-------------------------------+ + | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) + +-------------------------------+ + + Figure 3: Packet PW Encapsulation + + This conforms to the PW protocols stack as defined in [RFC4448]. The + protocol stack is unremarkable except to note that the stack does not + retain 32-bit alignment between the virtual Ethernet header and the + PW optional control word (or the PW label when the optional + components are not present in the PW header). This loss of 32 bits + of alignment is necessary to preserve backwards compatibility with + the Ethernet PW design [RFC4448] + + Ethernet Raw Mode (PW type 5) MUST be used for the packet PW. + + The PEs MAY use a local Ethernet address for the Ethernet header used + to encapsulate the client network-layer packet or MAY use the special + Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described + below. + + IANA has allocated two unicast Ethernet addresses [RFC5342] for use + with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". + Where [RFC4447] signaling is used to set up the PW, the LDP peers + numerically compare their IP addresses. The LDP PE with the higher- + value IP address will use PacketPWEthA, whilst the LDP peer with the + lower-value IP address uses PacketPWEthB. + + + + +Bryant, et al. Standards Track [Page 7] + +RFC 6658 Packet PW July 2012 + + + Where no signaling PW protocol is used, suitable Ethernet addresses + MUST be configured at each PE. + + Although this PW represents a point-to-point connection, the use of a + multicast destination address in the Ethernet encapsulation is + REQUIRED by some client-layer protocols. Peers MUST be prepared to + handle a multicast destination address in the Ethernet encapsulation. + +6. Ethernet and IEEE 802.1 Functional Restrictions + + The use of Ethernet as the encapsulation mechanism for traffic + between the server LSRs is a convenience based on the widespread + availability of existing hardware. In this application, there is no + requirement for any Ethernet feature other than its protocol + multiplexing capability. Thus, for example, a server LSR is not + required to implement the Ethernet OAM. + + The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q + tagging between PEs is not supported. + + Point-to-multipoint and multipoint-to-multipoint operation of the + virtual Ethernet is not supported. + +7. Congestion Considerations + + A packet pseudowire is normally used to carry IP, MPLS and their + associated support protocols over an MPLS network. There are no + congestion considerations beyond those that ordinarily apply to an IP + or MPLS network. Where the packet protocol being carried is not IP + or MPLS and the traffic volumes are greater than that ordinarily + associated with the support protocols in an IP or MPLS network, the + congestion considerations developed for PWs apply [RFC3985] + [RFC5659]. + +8. Security Considerations + + The virtual Ethernet approach to packet PW introduces no new security + risks. A more detailed discussion of pseudowire security is given in + [RFC3985], [RFC4447], and [RFC3916]. + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 8] + +RFC 6658 Packet PW July 2012 + + +9. IANA Considerations + + IANA has allocated two Ethernet unicast addresses from "IANA Unicast + 48-bit MAC Addresses". + + Address Usage Reference + ------------------- ---------------- --------- + 00-00-5E-00-52-00 PacketPWEthA [RFC6658] + 00-00-5E-00-52-01 PacketPWEthB [RFC6658] + +10. Acknowledgements + + The authors acknowledge the contributions made to this document by + Sami Boutros, Giles Herron, Siva Sivabalan, and David Ward. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. + Heron, "Pseudowire Setup and Maintenance Using the Label + Distribution Protocol (LDP)", RFC 4447, April 2006. + + [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, + "Encapsulation Methods for Transport of Ethernet over MPLS + Networks", RFC 4448, April 2006. + + [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage + for IEEE 802 Parameters", BCP 141, RFC 5342, + September 2008. + +11.2. Informative References + + [IEEE.802.1AB.2009] + Institute of Electrical and Electronics Engineers, "IEEE + Standard for Local and Metropolitan Area Networks -- + Station and Media Access Control Connectivity Discovery", + IEEE Standard 802.1AB, 2009. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for + Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, + September 2004. + + + +Bryant, et al. Standards Track [Page 9] + +RFC 6658 Packet PW July 2012 + + + [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- + Edge (PWE3) Architecture", RFC 3985, March 2005. + + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for + Use over an MPLS PSN", RFC 4385, February 2006. + + [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) + Report on MPLS Architectural Considerations for a + Transport Profile", RFC 5317, February 2009. + + [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- + Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, + October 2009. + + [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. + Berger, "A Framework for MPLS in Transport Networks", + RFC 5921, July 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 10] + +RFC 6658 Packet PW July 2012 + + +Appendix A. Encapsulation Approaches Considered + + A number of approaches to the design of a packet pseudowire (PW) were + investigated by the PWE3 Working Group and were discussed in IETF + meetings and on the PWE3 list. This section describes the approaches + that were analyzed and the technical issues that the authors took + into consideration in arriving at the approach described in the main + body of this document. This appendix is provided so that engineers + considering alternative optimizations can have access to the + rationale for the selection of the approach described in this + document. + + In a typical network, there are usually no more that four network- + layer protocols that need to be supported: IPv4, IPv6, MPLS, and + Connectionless Network Service (CLNS). However, any solution needs + to be scalable to a larger number of protocols. The approaches + considered in this appendix all satisfy this minimum requirement but + vary in their ability to support larger numbers of network-layer + protocols. + + Additionally, it is beneficial if the complete set of protocols + carried over the network in support of a set of CE peers fate share. + It is additionally beneficial if a single OAM session can be used to + monitor the behavior of this complete set. During the investigation, + various views were expressed as to where these benefits lay on the + scale from absolutely required to "nice to have", but in the end, + they were not a factor in reaching our conclusion. + + Four candidate approaches were analyzed: + + 1. A protocol identifier (PID) in the PW control word (CW) + + 2. A PID label + + 3. Parallel PWs - one per protocol + + 4. Virtual Ethernet + +A.1. A Protocol Identifier in the Control Word + + In this approach, a Protocol Identifier (PID) is included in the PW + control word (CW) by appending it to the generic control word + [RFC4385] to make a 6-byte CW (it was thought that this approach + would include 2 reserved bytes to provide 32-bit alignment, but then + this was optimized out). A variant of this is just to use a 2-byte + PID without a control word. + + + + + +Bryant, et al. Standards Track [Page 11] + +RFC 6658 Packet PW July 2012 + + + This is a simple approach and is basically a virtual PPP interface + without the PPP control protocol. This has a smaller MTU than, for + example, a virtual Ethernet would need; however, in forwarding terms, + it is not as simple as the PID label or multiple PW approaches + described next and may not be deployable on a number of existing + hardware platforms. + +A.2. PID Label + + In this approach, the PID is indicated by including a label after the + PW label that indicates the protocol type, as shown in Figure 4. + + +-------------------------------+ + | Client | + | Network-Layer | + | Packet | n octets + | | + +-------------------------------+ + | Optional Control Word | 4 octets + +-------------------------------+ + | PID Label (S=1) | 4 octets + +-------------------------------+ + | PW Label | 4 octets + +-------------------------------+ + | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) + +-------------------------------+ + + Figure 4: Encapsulation of a Pseudowire with + a Pseudowire Load-Balancing Label + + In the PID label approach, a new Label Distribution Protocol (LDP) + Forwarding Equivalence Class (FEC) element is used to signal the + mapping between protocol type and the PID label. This approach + complies with [RFC3031]. + + A similar approach to PID label is described in Section 3.4.5 of + [RFC5921]. In this case, when the client is a network-layer packet + service such as IP or MPLS, a service label and demultiplexer label + (which may be combined) are used to provide the necessary + identifications needed to carry this traffic over an LSP. + + The authors surveyed the hardware designs produced by a number of + companies across the industry and concluded that whilst the approach + complies with the MPLS architecture, it may conflict with a number of + designers' interpretations of the existing MPLS architecture. This + led to concerns that the approach may result in unexpected + difficulties in the future. Specifically, there was an assumption in + many designs that a forwarding decision should be made on the basis + + + +Bryant, et al. Standards Track [Page 12] + +RFC 6658 Packet PW July 2012 + + + of a single label. Whilst the approach is attractive, it cannot be + supported by many commodity chip sets, and this would require new + hardware, which would increase the cost of deployment and delay the + introduction of a packet PW service. + +A.3. Parallel PWs + + In this approach, one PW is constructed for each protocol type that + must be carried between the PEs. Thus, a complete packet PW would + consist of a bundle of PWs. This model would be very simple and + efficient from a forwarding point of view. The number of parallel + PWs required would normally be relatively small. In a typical + network, there are usually no more that four network-layer protocols + that need to be supported: IPv4, IPv6, MPLS, and CLNS. However, any + solution needs to be scalable to a larger number of protocols. + + There are a number of serious downsides with this approach: + + 1. From an operational point of view, the lack of fate sharing + between the protocol types can lead to complex faults that are + difficult to diagnose. + + 2. There is an undesirable trade-off in the OAM related to the first + point. We would have to run an OAM on each PW and bind them + together, which leads to significant protocol and software + complexity and does not scale well. Alternatively, we would need + to run a single OAM session on one of the PWs as a proxy for the + others and then diagnose any more complex failures on a case-by- + case basis. To some extent, the issue of fate sharing between + protocols in the bundle (for example, the assumed fate sharing + between CLNS and IP in IS-IS) can be mitigated through the use of + Bidirectional Forwarding Detection (BFD). + + 3. The need to configure, manage, and synchronize the behavior of a + group of PWs as if they were a single PW leads to an increase in + control-plane complexity. + + The Parallel PW mechanism is therefore an approach that simplifies + the forwarding plane, but only at a cost of a considerable increase + in other aspects of the design, in particular, operation of the PW. + +A.4. Virtual Ethernet + + Using a virtual Ethernet to provide a packet PW would require PEs to + include a virtual (internal) Ethernet interface and then to use an + Ethernet PW [RFC4448] to carry the user traffic. This is + conceptually simple and can be implemented today without any further + standards action, although there are a number of applicability + + + +Bryant, et al. Standards Track [Page 13] + +RFC 6658 Packet PW July 2012 + + + considerations that it are useful to bring to the attention of the + community. + + Conceptually, this is a simple approach, and some deployed equipments + can already do this. However, the requirement to run a complete + Ethernet adjacency led us to conclude that there was a need to + identify a simpler approach. The packets encapsulated in an Ethernet + header have a larger MTU than the other approaches, although this is + not considered to be an issue on the networks needing to carry packet + PWs. + + The virtual Ethernet mechanism was the first approach that the + authors considered, before the merits of the other approaches + appeared to make them more attractive. As we shall see below, + however, the other approaches were not without issues, and it appears + that the virtual Ethernet is the preferred approach to providing a + packet PW. + +A.5. Recommended Encapsulation + + The operational complexity and the breaking of fate-sharing + assumptions associated with the parallel PW approach would suggest + that this is not an approach that should be further pursued. + + The PID label approach gives rise to the concerns that it will break + implicit behavioral and label-stack size assumptions in many + implementations. Whilst those assumptions may be addressed with new + hardware, this would delay the introduction of the technology to the + point where it is unlikely to gain acceptance in competition with an + approach that needs no new protocol design and is already supportable + on many existing hardware platforms. + + The PID in the CW leads to the most compact protocol stack, is + simple, and requires minimal protocol work. However, it is a new + forwarding design and, apart from the issue of the larger packet + header and the simpler adjacency formation, offers no advantage over + the virtual Ethernet. + + The above considerations bring us back to the virtual Ethernet, which + is a well-known protocol stack with a well-known (internal) client + interface. It is already implemented in many hardware platforms and + is therefore readily deployable. After considering a number of + initially promising alternatives, the authors conclude that the + simplicity and existing hardware make the virtual Ethernet approach + to the packet PW the most attractive solution. + + + + + + +Bryant, et al. Standards Track [Page 14] + +RFC 6658 Packet PW July 2012 + + +Authors' Addresses + + Stewart Bryant (editor) + Cisco Systems + 250, Longwater, Green Park, + Reading, Berks RG2 6GB + UK + + EMail: stbryant@cisco.com + + + Luca Martini + Cisco Systems + 9155 East Nichols Avenue, Suite 400 + Englewood, CO 80112 + USA + + EMail: lmartini@cisco.com + + + George Swallow + Cisco Systems + 1414 Massachusetts Ave + Boxborough, MA 01719 + USA + + EMail: swallow@cisco.com + + + Andrew G. Malis + Verizon Communications + 60 Sylvan Rd. + Waltham, MA 02451 + USA + + EMail: andrew.g.malis@verizon.com + + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 15] + -- cgit v1.2.3