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/rfc4448.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc4448.txt (limited to 'doc/rfc/rfc4448.txt') diff --git a/doc/rfc/rfc4448.txt b/doc/rfc/rfc4448.txt new file mode 100644 index 0000000..e8202c4 --- /dev/null +++ b/doc/rfc/rfc4448.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group L. Martini, Ed. +Request for Comments: 4448 E. Rosen +Category: Standards Track Cisco Systems, Inc. + N. El-Aawar + Level 3 Communications, LLC + G. Heron + Tellabs + April 2006 + + + Encapsulation Methods for Transport of Ethernet over MPLS Networks + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol + Data Units (PDUs) over an MPLS network. This enables service + providers to offer "emulated" Ethernet services over existing MPLS + networks. This document specifies the encapsulation of + Ethernet/802.3 PDUs within a pseudowire. It also specifies the + procedures for using a PW to provide a "point-to-point Ethernet" + service. + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 1] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Specification of Requirements ...................................6 + 3. Applicability Statement .........................................6 + 4. Details Specific to Particular Emulated Services ................7 + 4.1. Ethernet Tagged Mode .......................................7 + 4.2. Ethernet Raw Mode ..........................................8 + 4.3. Ethernet-Specific Interface Parameter LDP Sub-TLV ..........8 + 4.4. Generic Procedures .........................................9 + 4.4.1. Raw Mode vs. Tagged Mode ............................9 + 4.4.2. MTU Management on the PE/CE Links ..................11 + 4.4.3. Frame Ordering .....................................11 + 4.4.4. Frame Error Processing .............................11 + 4.4.5. IEEE 802.3x Flow Control Interworking ..............11 + 4.5. Management ................................................12 + 4.6. The Control Word ..........................................12 + 4.7. QoS Considerations ........................................13 + 5. Security Considerations ........................................14 + 6. PSN MTU Requirements ...........................................14 + 7. Normative References ...........................................15 + 8. Informative References .........................................15 + 9. Significant Contributors .......................................17 + Appendix A. Interoperability Guidelines ...........................20 + A.1. Configuration Options .....................................20 + A.2. IEEE 802.3x Flow Control Considerations ...................21 + Appendix B. QoS Details ...........................................21 + B.1. Adaptation of 802.1Q CoS to PSN CoS .......................22 + B.2. Drop Precedence ...........................................23 + + + + + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 2] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +1. Introduction + + An Ethernet pseudowire (PW) allows Ethernet/802.3 [802.3] Protocol + Data Units (PDUs) to be carried over a Multi-Protocol Label Switched + [MPLS-ARCH] network. In addressing the issues associated with + carrying an Ethernet PDU over a packet switched network (PSN), this + document assumes that a pseudowire (PW) has been set up by using a + control protocol such as the one as described in [PWE3-CTRL]. The + design of Ethernet pseudowire described in this document conforms to + the pseudowire architecture described in [RFC3985]. It is also + assumed in the remainder of this document that the reader is familiar + with RFC 3985. + + The Pseudowire Emulation Edge-to-Edge (PWE3) Ethernet PDU consists of + the Destination Address, Source Address, Length/Type, MAC Client + Data, and padding extracted from a MAC frame as a concatenated octet + sequence in their original order [PDU]. + + In addition to the Ethernet PDU format used within the pseudowire, + this document discusses: + + - Procedures for using a PW in order to provide a pair of Customer + Edge (CE) routers with an emulated (point-to-point) Ethernet + service, including the procedures for the processing of Provider + Edge (PE)-bound and CE-bound Ethernet PDUs [RFC3985] + + - Ethernet-specific quality of service (QoS) and security + considerations + + - Inter-domain transport considerations for Ethernet PW + + The following two figures describe the reference models that are + derived from [RFC3985] to support the Ethernet PW emulated services. + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 3] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + |<-------------- Emulated Service ---------------->| + | | + | |<------- Pseudowire ------->| | + | | | | + | | |<-- PSN Tunnel -->| | | + | PW End V V V V PW End | + V Service +----+ +----+ Service V + +-----+ | | PE1|==================| PE2| | +-----+ + | |----------|............PW1.............|----------| | + | CE1 | | | | | | | | CE2 | + | |----------|............PW2.............|----------| | + +-----+ ^ | | |==================| | | ^ +-----+ + ^ | +----+ +----+ | | ^ + | | Provider Edge 1 Provider Edge 2 | | + | | | | + Customer | | Customer + Edge 1 | | Edge 2 + | | + | | + Attachment Circuit (AC) Attachment Circuit (AC) + native Ethernet service native Ethernet service + + Figure 1: PWE3 Ethernet/VLAN Interface Reference Configuration + + The "emulated service" shown in Figure 1 is, strictly speaking, a + bridged LAN; the PEs have MAC interfaces, consume MAC control frames, + etc. However, the procedures specified herein only support the case + in which there are two CEs on the "emulated LAN". Hence we refer to + this service as "emulated point-to-point Ethernet". Specification of + the procedures for using pseudowires to emulate LANs with more than + two CEs are out of the scope of the current document. + + +-------------+ +-------------+ + | Emulated | | Emulated | + | Ethernet | | Ethernet | + | (including | Emulated Service | (including | + | VLAN) |<==============================>| VLAN) | + | Services | | Services | + +-------------+ Pseudowire +-------------+ + |Demultiplexer|<==============================>|Demultiplexer| + +-------------+ +-------------+ + | PSN | PSN Tunnel | PSN | + | MPLS |<==============================>| MPLS | + +-------------+ +-------------+ + | Physical | | Physical | + +-----+-------+ +-----+-------+ + + Figure 2: Ethernet PWE3 Protocol Stack Reference Model + + + +Martini, et al. Standards Track [Page 4] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + For the purpose of this document, PE1 will be defined as the ingress + router, and PE2 as the egress router. A layer 2 PDU will be received + at PE1, encapsulated at PE1, transported, decapsulated at PE2, and + transmitted out on the attachment circuit of PE2. + + An Ethernet PW emulates a single Ethernet link between exactly two + endpoints. The mechanisms described in this document are agnostic to + that which is beneath the "Pseudowire" level in Figure 2, concerning + itself only with the "Emulated Service" portion of the stack. + + The following reference model describes the termination point of each + end of the PW within the PE: + + +-----------------------------------+ + | PE | + +---+ +-+ +-----+ +------+ +------+ +-+ + | | |P| | | |PW ter| | PSN | |P| + | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN + | | |y| | | |on | | | |y| + | C | +-+ +-----+ +------+ +------+ +-+ + | E | | | + | | +-+ +-----+ +------+ +------+ +-+ + | | |P| | | |PW ter| | PSN | |P| + | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN + | | |y| | | |on | | | |y| + +---+ +-+ +-----+ +------+ +------+ +-+ + | | + +-----------------------------------+ + ^ ^ ^ + | | | + A B C + + Figure 3: PW Reference Diagram + + The PW terminates at a logical port within the PE, defined at point B + in the above diagram. This port provides an Ethernet MAC service + that will deliver each Ethernet frame that is received at point A, + unaltered, to the point A in the corresponding PE at the other end of + the PW. + + The Native Service Processing (NSP) function includes frame + processing that is required for the Ethernet frames that are + forwarded to the PW termination point. Such functions may include + stripping, overwriting or adding VLAN tags, physical port + multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation, + shaping, policing, etc. These functions are specific to the Ethernet + technology, and may not be required for the PW emulation service. + + + + +Martini, et al. Standards Track [Page 5] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + The points to the left of A, including the physical layer between the + CE and PE, and any adaptation (NSP) functions between it and the PW + terminations, are outside of the scope of PWE3 and are not defined + here. + + "PW Termination", between A and B, represents the operations for + setting up and maintaining the PW, and for encapsulating and + decapsulating the Ethernet frames as necessary to transmit them + across the MPLS network. + + An Ethernet PW operates in one of two modes: "raw mode" or "tagged + mode". In tagged mode, each frame MUST contain at least one 802.1Q + [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the + two PW termination points. That is, the two PW termination points + must have some agreement (signaled or manually configured) on how to + process the tag. On a raw mode PW, a frame MAY contain an 802.1Q + VLAN tag, but if it does, the tag is not meaningful to the NSPs, and + passes transparently through them. + + Additional terminology relevant to pseudowires and Layer 2 Virtual + Private Networking may be found in [RFC4026]. + +2. Specification of Requirements + + 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]. + +3. Applicability Statement + + The Ethernet PW emulation allows a service provider to offer a "port + to port" Ethernet-based service across an MPLS packet switched + network (PSN) while the Ethernet VLAN PW emulation allows an + "Ethernet VLAN to VLAN" based service across an MPLS packet switched + network (PSN). + + The Ethernet or Ethernet VLAN PW has the following characteristics in + relationship to the respective native service: + + - An Ethernet PW connects two Ethernet ACs while an Ethernet VLAN + PW connects two Ethernet VLAN ACs, supporting bidirectional + transport of variable length Ethernet frames. The ingress + Native Service Processing (NSP) function strips the preamble and + frame check sequence (FCS) from the Ethernet frame and + transports the frame in its entirety across the PW. This is + done regardless of the presence of the 802.1Q tag in the frame. + The egress NSP function receives the Ethernet frame from the PW + and regenerates the preamble or FCS before forwarding the frame + + + +Martini, et al. Standards Track [Page 6] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + to the attachment circuit. Since the FCS is not transported + across either Ethernet or Ethernet VLAN PWs, payload integrity + transparency may be lost. The OPTIONAL method described in + [FCS] can be used to achieve payload integrity transparency on + Ethernet or Ethernet VLAN PWs. + + - For an Ethernet VLAN PW, VLAN tag rewrite can be achieved by NSP + at the egress PE, which is outside the scope of this document. + + - The Ethernet or Ethernet VLAN PW only supports homogeneous + Ethernet frame type across the PW; both ends of the PW must be + either tagged or untagged. Heterogeneous frame type support + achieved with NSP functionality is outside the scope of this + document. + + - Ethernet port or Ethernet VLAN status notification is provided + using the PW Status TLV in the Label Distribution Protocol (LDP) + status notification message. Loss of connectivity between PEs + can be detected by the LDP session closing, or by using [VCCV] + mechanisms. The PE can convey these indications back to its + attached Remote System. + + - The maximum frame size that can be supported is limited by the + PSN MTU minus the MPLS header size, unless fragmentation and + reassembly are used [FRAG]. + + - The packet switched network may reorder, duplicate, or silently + drop packets. Sequencing MAY be enabled in the Ethernet or + Ethernet VLAN PW to detect lost, duplicate, or out-of-order + packets on a per-PW basis. + + - The faithfulness of an Ethernet or Ethernet VLAN PW may be + increased by leveraging Quality of Service features of the PEs + and the underlying PSN. (See Section 4.7, "QoS + Considerations".) + +4. Details Specific to Particular Emulated Services + +4.1. Ethernet Tagged Mode + + The Ethernet frame will be encapsulated according to the procedures + defined later in this document for tagged mode. It should be noted + that if the VLAN identifier is modified by the egress PE, the + Ethernet spanning tree protocol might fail to work properly. If this + issue is of significance, the VLAN identifier MUST be selected in + such a way that it matches on the attachment circuits at both ends of + the PW. + + + + +Martini, et al. Standards Track [Page 7] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + If the PE detects a failure on the Ethernet physical port, or the + port is administratively disabled, it MUST send a PW status + notification message for all PWs associated with the port. + + This mode uses service-delimiting tags to map input Ethernet frames + to respective PWs and corresponds to PW type 0x0004 "Ethernet Tagged + Mode" [IANA]. + +4.2. Ethernet Raw Mode + + The Ethernet frame will be encapsulated according to the procedures + defined later in this document for raw mode. If the PE detects a + failure on the Ethernet input port, or the port is administratively + disabled, the PE MUST send an appropriate PW status notification + message to the corresponding remote PE. + + In this mode, all Ethernet frames received on the attachment circuit + of PE1 will be transmitted to PE2 on a single PW. This service + corresponds to PW type 0x0005 "Ethernet" [IANA]. + +4.3. Ethernet-Specific Interface Parameter LDP Sub-TLV + + This LDP sub-Type Length Value [LDP] specifies interface-specific + parameters. When applicable, it MUST be used to validate that the + PEs, and the ingress and egress ports at the edges of the circuit, + have the necessary capabilities to interoperate with each other. The + Interface parameter TLV is defined in [PWE3-CTRL], the IANA registry + with initial values for interface parameter sub-TLV types is defined + in [IANA], but the Ethernet-specific interface parameters are + specified as follows: + + - 0x06 Requested VLAN ID Sub-TLV + + An Optional 16-bit value indicating the requested VLAN ID. This + parameter MUST be used by a PE that is incapable of rewriting + the 802.1Q Ethernet VLAN tag on output. If the ingress PE + receives this request, it MUST rewrite the VLAN ID contained + inside the VLAN Tag at the input to match the requested VLAN ID. + If this is not possible, and the VLAN ID does not already match + the configured ingress VLAN ID, the PW MUST not be enabled. + This parameter is applicable only to PW type 0x0004. + + + + + + + + + + +Martini, et al. Standards Track [Page 8] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +4.4. Generic Procedures + + When the NSP/Forwarder hands a frame to the PW termination function: + + - The preamble (if any) and FCS are stripped off. + + - The control word as defined in Section 4.6, "The Control Word", + is, if necessary, prepended to the resulting frame. The + conditions under which the control word is or is not used are + specified below. + + - The proper pseudowire demultiplexer (PW Label) is prepended to + the resulting packet. + + - The proper tunnel encapsulation is prepended to the resulting + packet. + + - The packet is transmitted. + + The way in which the proper tunnel encapsulation and pseudowire + demultiplexer is chosen depends on the procedures that were used to + set up the pseudowire. + + The tunnel encapsulation depends on how the MPLS PSN is set up. This + can include no label, one label, or multiple labels. The proper + pseudowire demultiplexer is an MPLS label whose value is determined + by the PW setup and maintenance protocols. + + When a packet arrives over a PW, the tunnel encapsulation and PW + demultiplexer are stripped off. If the control word is present, it + is processed and stripped off. The resulting frame is then handed to + the Forwarder/NSP. Regeneration of the FCS is considered to be an + NSP responsibility. + +4.4.1. Raw Mode vs. Tagged Mode + + When the PE receives an Ethernet frame, and the frame has a VLAN tag, + we can distinguish two cases: + + 1. The tag is service-delimiting. This means that the tag was + placed on the frame by some piece of service provider-operated + equipment, and the tag is used by the service provider to + distinguish the traffic. For example, LANs from different + customers might be attached to the same service provider + switch, which applies VLAN tags to distinguish one customer's + traffic from another's, and then forwards the frames to the PE. + + + + + +Martini, et al. Standards Track [Page 9] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + 2. The tag is not service-delimiting. This means that the tag was + placed in the frame by a piece of customer equipment, and is + not meaningful to the PE. + + Whether or not the tag is service-delimiting is determined by local + configuration on the PE. + + If an Ethernet PW is operating in raw mode, service-delimiting tags + are NEVER sent over the PW. If a service-delimiting tag is present + when the frame is received from the attachment circuit by the PE, it + MUST be stripped (by the NSP) from the frame before the frame is sent + to the PW. + + If an Ethernet PW is operating in tagged mode, every frame sent on + the PW MUST have a service-delimiting VLAN tag. If the frame as + received by the PE from the attachment circuit does not have a + service-delimiting VLAN tag, the PE must prepend the frame with a + dummy VLAN tag before sending the frame on the PW. This is the + default operating mode. This is the only REQUIRED mode. + + In both modes, non-service-delimiting tags are passed transparently + across the PW as part of the payload. It should be noted that a + single Ethernet packet may contain more than one tag. At most, one + of these tags may be service-delimiting. In any case, the NSP + function may only inspect the outermost tag for the purpose of + adapting the Ethernet frame to the pseudowire. + + In both modes, the service-delimiting tag values have only local + significance, i.e., are meaningful only at a particular PE-CE + interface. When tagged mode is used, the PE that receives a frame + from the PW may rewrite the tag value, or may strip the tag entirely, + or may leave the tag unchanged, depending on its configuration. When + raw mode is used, the PE that receives a frame may or may not need to + add a service-delimiting tag before transmitting the frame on the + attachment circuit; however, it MUST not rewrite or remove any tags + that are already present. + + The following table illustrates the operations that might be + performed at input from the attachment circuit: + + +-----------------------------------------------------------+ + | Tag-> | service delimiting | non service delimiting| + |-------------+---------------------+-----------------------| + | Raw Mode | 1st VLAN Tag Removed| no operation performed| + |-------------+---------------------+-----------------------| + | Tagged Mode | NO OP or Tag Added | Tag Added | + +-----------------------------------------------------------+ + + + + +Martini, et al. Standards Track [Page 10] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +4.4.2. MTU Management on the PE/CE Links + + The Ethernet PW MUST NOT be enabled unless it is known that the MTUs + of the CE-PE links are the same at both ends of the PW. If an egress + router receives an encapsulated layer 2 PDU whose payload length + (i.e., the length of the PDU itself without any of the encapsulation + headers) exceeds the MTU of the destination layer 2 interface, the + PDU MUST be dropped. + +4.4.3. Frame Ordering + + In general, applications running over Ethernet do not require strict + frame ordering. However, the IEEE definition of 802.3 [802.3] + requires that frames from the same conversation in the context of + link aggregation (clause 43) are delivered in sequence. Moreover, + the PSN cannot (in the general case) be assumed to provide or to + guarantee frame ordering. An Ethernet PW can, through use of the + control word, provide strict frame ordering. If this option is + enabled, any frames that get misordered by the PSN will be dropped or + reordered by the receiving PW endpoint. If strict frame ordering is + a requirement for a particular PW, this option MUST be enabled. + +4.4.4. Frame Error Processing + + An encapsulated Ethernet frame traversing a pseudowire may be + dropped, corrupted, or delivered out-of-order. As described in + [PWE3-REQ], frame loss, corruption, and out-of-order delivery are + considered to be a "generalized bit error" of the pseudowire. PW + frames that are corrupted will be detected at the PSN layer and + dropped. + + At the ingress of the PW, the native Ethernet frame error processing + mechanisms MUST be enabled. Therefore, if a PE device receives an + Ethernet frame containing hardware-level Cyclic Redundancy Check + (CRC) errors, framing errors, or a runt condition, the frame MUST be + discarded on input. Note that defining this processing is part of + the NSP function and is outside the scope of this document. + +4.4.5. IEEE 802.3x Flow Control Interworking + + In a standard Ethernet network, the flow control mechanism is + optional and typically configured between the two nodes on a point- + to-point link (e.g., between the CE and the PE). IEEE 802.3x PAUSE + frames MUST NOT be carried across the PW. See Appendix A for notes + on CE-PE flow control. + + + + + + +Martini, et al. Standards Track [Page 11] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +4.5. Management + + The Ethernet PW management model follows the general PW management + model defined in [RFC3985] and [PWE3-MIB]. Many common PW management + facilities are provided here, with no additional Ethernet specifics + necessary. Ethernet-specific parameters are defined in an additional + MIB module, [PW-MIB]. + +4.6. The Control Word + + The control word defined in this section is based on the Generic PW + MPLS Control Word as defined in [PWE3-CW]. It provides the ability + to sequence individual frames on the PW, avoidance of equal-cost + multiple-path load-balancing (ECMP) [RFC2992], and Operations and + Management (OAM) mechanisms including VCCV [VCCV]. + + [PWE3-CW] states, "If a PW is sensitive to packet misordering and is + being carried over an MPLS PSN that uses the contents of the MPLS + payload to select the ECMP path, it MUST employ a mechanism which + prevents packet misordering." This is necessary because ECMP + implementations may examine the first nibble after the MPLS label + stack to determine whether the labelled packet is IP or not. Thus, + if the source MAC address of an Ethernet frame carried over the PW + without a control word present begins with 0x4 or 0x6, it could be + mistaken for an IPv4 or IPv6 packet. This could, depending on the + configuration and topology of the MPLS network, lead to a situation + where all packets for a given PW do not follow the same path. This + may increase out-of-order frames on a given PW, or cause OAM packets + to follow a different path than actual traffic (see Section 4.4.3, + "Frame Ordering"). + + The features that the control word provides may not be needed for a + given Ethernet PW. For example, ECMP may not be present or active on + a given MPLS network, strict frame sequencing may not be required, + etc. If this is the case, the control word provides little value and + is therefore optional. Early Ethernet PW implementations have been + deployed that do not include a control word or the ability to process + one if present. To aid in backwards compatibility, future + implementations MUST be able to send and receive frames without the + control word present. + + In all cases, the egress PE MUST be aware of whether the ingress PE + will send a control word over a specific PW. This may be achieved by + configuration of the PEs, or by signaling, as defined in [PWE3-CTRL]. + + + + + + + +Martini, et al. Standards Track [Page 12] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + The control word is defined as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0| Reserved | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + In the above diagram, the first 4 bits MUST be set to 0 to indicate + PW data. The rest of the first 16 bits are reserved for future use. + They MUST be set to 0 when transmitting, and MUST be ignored upon + receipt. + + The next 16 bits provide a sequence number that can be used to + guarantee ordered frame delivery. The processing of the sequence + number field is OPTIONAL. + + The sequence number space is a 16-bit, unsigned circular space. The + sequence number value 0 is used to indicate that the sequence number + check algorithm is not used. The sequence number processing + algorithm is found in [PWE3-CW]. + +4.7. QoS Considerations + + The ingress PE MAY consider the user priority (PRI) field [802.1Q] of + the VLAN tag header when determining the value to be placed in a QoS + field of the encapsulating protocol (e.g., the EXP fields of the MPLS + label stack). In a similar way, the egress PE MAY consider the QoS + field of the encapsulating protocol (e.g., the EXP fields of the MPLS + label stack) when queuing the frame for transmission towards the CE. + + A PE MUST support the ability to carry the Ethernet PW as a best- + effort service over the MPLS PSN. PRI bits are kept transparent + between PE devices, regardless of the QoS support of the PSN. + + If an 802.1Q VLAN field is added at the PE, a default PRI setting of + zero MUST be supported, a configured default value is recommended, or + the value may be mapped from the QoS field of the PSN, as referred to + above. + + A PE may support additional QoS support by means of one or more of + the following methods: + + i. One class of service (CoS) per PW End Service (PWES), mapped + to a single CoS PW at the PSN. + ii. Multiple CoS per PWES mapped to a single PW with multiple + CoS at the PSN. + iii. Multiple CoS per PWES mapped to multiple PWs at the PSN. + + + +Martini, et al. Standards Track [Page 13] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + Examples of the cases above and details of the service mapping + considerations are described in Appendix B. + + The PW guaranteed rate at the MPLS PSN level is PW service provider + policy based on agreement with the customer, and may be different + from the Ethernet physical port rate. + +5. Security Considerations + + The Ethernet pseudowire type is subject to all of the general + security considerations discussed in [RFC3985] and [PWE3-CTRL]. + + The Ethernet pseudowire is transported on an MPLS PSN; therefore, the + security of the pseudowire itself will only be as good as the + security of the MPLS PSN. The MPLS PSN can be secured by various + methods, as described in [MPLS-ARCH]. + + Security achieved by access control of MAC addresses is out of the + scope of this document. Additional security requirements related to + the use of PW in a switching (virtual bridging) environment are not + discussed here as they are not within the scope of this document. + +6. PSN MTU Requirements + + The MPLS PSN MUST be configured with an MTU that is large enough to + transport a maximum-sized Ethernet frame that has been encapsulated + with a control word, a pseudowire demultiplexer, and a tunnel + encapsulation. With MPLS used as the tunneling protocol, for + example, this is likely to be 8 or more bytes greater than the + largest frame size. The methodology described in [FRAG] MAY be used + to fragment encapsulated frames that exceed the PSN MTU. However, if + [FRAG] is not used and if the ingress router determines that an + encapsulated layer 2 PDU exceeds the MTU of the PSN tunnel through + which it must be sent, the PDU MUST be dropped. + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 14] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +7. Normative References + + [PWE3-CW] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire + Emulation Edge-to-Edge (PWE3) Control Word for Use over + an MPLS PSN", RFC 4385, February 2006. + + [IANA] Martini, L., "IANA Allocations for Pseudowire Edge to + Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + + [PWE3-CTRL] Martini, L., El-Aawar, N., Heron, G., Rosen, E., Tappan, + D., and T. Smith, "Pseudowire Setup and Maintenance + using the Label Distribution Protocol (LDP)", RFC 4447, + April 2006. + + [MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC 3031, + January 2001. + + [802.3] IEEE802.3-2005, ISO/IEC 8802-3: 2000 (E), "IEEE Standard + for Information technology -- Telecommunications and + information exchange between systems -- Local and + metropolitan + area networks -- Specific requirements -- Part 3: + Carrier Sense Multiple Access with Collision Detection + (CSMA/CD) Access Method and Physical Layer + Specifications", 2005. + + [802.1Q] ANSI/IEEE Standard 802.1Q-2005, "IEEE Standards for + Local and Metropolitan Area Networks: Virtual Bridged + Local Area Networks", 2005. + + [PDU] IEEE Std 802.3, 1998 Edition, "Part 3: Carrier sense + multiple access with collision detection (CSMA/CD) + access method and physical layer specifications" figure + 3.1, 1998 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +8. Informative References + + [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- + Edge (PWE3) Architecture", RFC 3985, March 2005. + + [PW-MIB] Zelig, D. and T. Nadeau, "Ethernet Pseudo Wire (PW) + Management Information Base", Work in Progress, February + 2006. + + + + +Martini, et al. Standards Track [Page 15] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + [PWE3-REQ] Xiao, X., McPherson, D., and P. Pate, "Requirements for + Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, + September 2004. + + [PWE3-MIB] Zelig, D., Ed. and T. Nadeau, Ed., "Pseudo Wire (PW) + Management Information Base", Work in Progress, February + 2006. + + [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., + and B. Thomas, "LDP Specification", RFC 3036, January + 2001. + + [FRAG] Malis, A. and W. Townsley, "PWE3 Fragmentation and + Reassembly", Work in Progress, February 2005. + + [FCS] Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame + Check Sequence Retention", Work in Progress, September + 2005. + + [VCCV] Nadeau, T., Ed. and R. Aggarwal, Ed., "Pseudo Wire + Virtual Circuit Connectivity Verification (VCCV)", Work + in Progress, August 2005. + + [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path + Algorithm", RFC 2992, November 2000. + + [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned + Virtual Private Network (VPN) Terminology", RFC 4026, + March 2005. + + [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two + Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, + March 2005. + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 16] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +9. Significant Contributors + + Andrew G. Malis + Tellabs + 90 Rio Robles Dr. + San Jose, CA 95134 + + EMail: Andy.Malis@tellabs.com + + + Dan Tappan + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA 01719 + + EMail: tappan@cisco.com + + + Steve Vogelsang + ECI Telecom + Omega Corporate Center + 1300 Omega Drive + Pittsburgh, PA 15205 + + EMail: stephen.vogelsang@ecitele.com + + + Vinai Sirkay + Reliance Infocomm + Dhirubai Ambani Knowledge City + Navi Mumbai 400 709 + India + + EMail: vinai@sirkay.com + + + Vasile Radoaca + Nortel Networks + 600 Technology Park + Billerica MA 01821 + + EMail: vasile@nortelnetworks.com + + + + + + + + + +Martini, et al. Standards Track [Page 17] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + Chris Liljenstolpe + Alcatel + 11600 Sallie Mae Dr. + 9th Floor + Reston, VA 20193 + + EMail: chris.liljenstolpe@alcatel.com + + + Kireeti Kompella + Juniper Networks + 1194 N. Mathilda Ave + Sunnyvale, CA 94089 + + EMail: kireeti@juniper.net + + + Tricci So + Nortel Networks 3500 Carling Ave., + Nepean, Ontario, + Canada, K2H 8E9. + + EMail: tso@nortelnetworks.com + + + XiPeng Xiao + Riverstone Networks + 5200 Great America Parkway + Santa Clara, CA 95054 + + EMail: xxiao@riverstonenet.com + + + Christopher O. Flores + T-Systems + 10700 Parkridge Boulevard + Reston, VA 20191 + USA + + EMail: christopher.flores@usa.telekom.de + + + David Zelig + Corrigent Systems + 126, Yigal Alon St. + Tel Aviv, ISRAEL + + EMail: davidz@corrigent.com + + + +Martini, et al. Standards Track [Page 18] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + Raj Sharma + Luminous Networks, Inc. + 10460 Bubb Road + Cupertino, CA 95014 + + EMail: raj@luminous.com + + + Nick Tingle + TiMetra Networks + 274 Ferguson Drive + Mountain View, CA 94043 + + EMail: nick@timetra.com + + + Sunil Khandekar + TiMetra Networks + 274 Ferguson Drive + Mountain View, CA 94043 + + EMail: sunil@timetra.com + + + Loa Andersson + TLA-group + + EMail: loa@pi.se + + + + + + + + + + + + + + + + + + + + + + + +Martini, et al. Standards Track [Page 19] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +Appendix A. Interoperability Guidelines + +A.1. Configuration Options + + The following is a list of the configuration options for a point-to- + point Ethernet PW based on the reference points of Figure 3: + + --------------|---------------|---------------|------------------ + Service and | Encap on C |Operation at B | Remarks + Encap on A | |ingress/egress | + --------------|---------------|---------------|------------------ + 1) Raw | Raw - Same as | | + | A | | + | | | + --------------|---------------|---------------|------------------ + 2) Tag1 | Tag2 |Optional change| VLAN can be + | |of VLAN value | 0-4095 + | | | Change allowed in + | | | both directions + --------------|---------------|---------------|------------------ + 3) No Tag | Tag |Add/remove Tag | Tag can be + | |field | 0-4095 + | | | (note i) + | | | + --------------|---------------|---------------|------------------ + 4) Tag | No Tag |Remove/add Tag | (note ii) + | |field | + | | | + | | | + --------------|---------------|---------------|------------------ + + Figure 4: Configuration Options + + Allowed combinations: + + Raw and other services are not allowed on the same NSP virtual port + (A). All other combinations are allowed, except that conflicting + VLANs on (A) are not allowed. Note that in most point-to-point PW + applications the NSP virtual port is the same entity as the physical + port. + + Notes: + + i. Mode #3 MAY be limited to adding VLAN NULL only, since + change of VLAN or association to specific VLAN can be done + at the PW CE-bound side. + + + + + +Martini, et al. Standards Track [Page 20] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + + ii. Mode #4 exists in layer 2 switches, but is not recommended + when operating with PW since it may not preserve the user's + PRI bits. If there is a need to remove the VLAN tag (for + TLS at the other end of the PW), it is recommended to use + mode #2 with tag2=0 (NULL VLAN) on the PW and use mode #3 at + the other end of the PW. + +A.2. IEEE 802.3x Flow Control Considerations + + If the receiving node becomes congested, it can send a special frame, + called the PAUSE frame, to the source node at the opposite end of the + connection. The implementation MUST provide a mechanism for + terminating PAUSE frames locally (i.e., at the local PE). It MUST + operate as follows: PAUSE frames received on a local Ethernet port + SHOULD cause the PE device to buffer, or to discard, further Ethernet + frames for that port until the PAUSE condition is cleared. + Optionally, the PE MAY simply discard PAUSE frames. + + If the PE device wishes to pause data received on a local Ethernet + port (perhaps because its own buffers are filling up or because it + has received notification of congestion within the PSN), then it MAY + issue a PAUSE frame on the local Ethernet port, but MUST clear this + condition when willing to receive more data. + +Appendix B. QoS Details + + Section 4.7, "QoS Considerations", describes various modes for + supporting PW QOS over the PSN. Examples of the above for a point- + to-point VLAN service are: + + - The classification to the PW is based on VLAN field, but the + user PRI bits are mapped to different CoS markings (and network + behavior) at the PW level. An example of this is a PW mapped to + an E-LSP in an MPLS network. + + - The classification to the PW is based on VLAN field and the PRI + bits, and frames with different PRI bits are mapped to different + PWs. An example is to map a PWES to different L-LSPs in MPLS + PSN in order to support multiple CoS over an L-LSP-capable + network, or to map a PWES to multiple L2TPv3 sessions [L2TPv3]. + + The specific value to be assigned at the PSN for various CoS is + out of the scope of this document. + + + + + + + + +Martini, et al. Standards Track [Page 21] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +B.1. Adaptation of 802.1Q CoS to PSN CoS + + It is not required that the PSN will have the same CoS definition of + CoS as defined in [802.1Q], and the mapping of 802.1Q CoS to PSN CoS + is application specific and depends on the agreement between the + customer and the PW provider. However, the following principles + adopted from 802.1Q, Table 8-2, MUST be met when applying the set of + PSN CoS based on user's PRI bits. + + ---------------------------------- + |#of available classes of service| + -------------||---+---+---+---+---+---+---+---| + User || 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | + Priority || | | | | | | | | + =============================================== + 0 Best Effort|| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | + (Default) || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 1 Background || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | + || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 2 Spare || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | + || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 3 Excellent || 0 | 0 | 0 | 1 | 1 | 2 | 2 | 3 | + Effort || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 4 Controlled || 0 | 1 | 1 | 2 | 2 | 3 | 3 | 4 | + Load || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 5 Interactive|| 0 | 1 | 1 | 2 | 3 | 4 | 4 | 5 | + Multimedia || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 6 Interactive|| 0 | 1 | 2 | 3 | 4 | 5 | 5 | 6 | + Voice || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + 7 Network || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | + Control || | | | | | | | | + ------------ ||---+---+---+---+---+---+---+---| + + Figure 5: IEEE 802.1Q CoS Mapping + + + + + + + + + + +Martini, et al. Standards Track [Page 22] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +B.2. Drop Precedence + + The 802.1P standard does not support drop precedence; therefore, from + the PW PE-bound point of view there is no mapping required. It is, + however, possible to mark different drop precedence for different PW + frames based on the operator policy and required network behavior. + This functionality is not discussed further here. + + PSN QoS support and signaling of QoS are out of the scope of this + document. + +Authors' Addresses + + Luca Martini, Editor + Cisco Systems, Inc. + 9155 East Nichols Avenue, Suite 400 + Englewood, CO, 80112 + + EMail: lmartini@cisco.com + + + Nasser El-Aawar + Level 3 Communications, LLC. + 1025 Eldorado Blvd. + Broomfield, CO, 80021 + + EMail: nna@level3.net + + + Giles Heron + Tellabs + Abbey Place + 24-28 Easton Street + High Wycombe + Bucks + HP11 1NT + UK + + EMail: giles.heron@tellabs.com + + + Eric C. Rosen + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA 01719 + + EMail: erosen@cisco.com + + + + +Martini, et al. Standards Track [Page 23] + +RFC 4448 Encapsulation of Ethernet over MPLS April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Martini, et al. Standards Track [Page 24] + -- cgit v1.2.3