summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4448.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4448.txt')
-rw-r--r--doc/rfc/rfc4448.txt1347
1 files changed, 1347 insertions, 0 deletions
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]
+