RFC 4448
Encapsulation Methods for Transport of Ethernet over MPLS Networks
Encapsulation Methods for Transport of Ethernet over MPLS Networks 🎀
okay so this is RFC 4448 💖 It's a Standards Track doc from the Network Working Group, dated April 2006. The editor is L. Martini (Ed.), with co-authors E. Rosen (Cisco Systems, Inc.), N. El-Aawar (Level 3 Communications, LLC), and G. Heron (Tellabs). There's no Obsoletes or Updates line in the header, so it doesn't replace or amend anything 🧚
Status of This Memo ✨
this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share away 💅
Copyright Notice 💜
Copyright (C) The Internet Society (2006).
Abstract 🦋
okay so an Ethernet pseudowire (PW) lets service providers carry Ethernet/802.3 Protocol Data Units (PDUs) across an MPLS network. this is how they offer "emulated" Ethernet services on top of MPLS networks that already exist, and it's giving efficient 😭 this document defines how Ethernet/802.3 PDUs get encapsulated inside a pseudowire. it also lays out how to use a PW to deliver a "point-to-point Ethernet" service 🔥
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 ...........................................231. Introduction 🌈
okay so an Ethernet pseudowire (PW) lets Ethernet/802.3 [802.3] Protocol Data Units (PDUs) travel across a Multi-Protocol Label Switched [MPLS-ARCH] network. when you're figuring out how to carry an Ethernet PDU over a packet switched network (PSN), this doc assumes the PW is already set up using a control protocol like the one described in [PWE3-CTRL]. the Ethernet pseudowire design here follows the pseudowire architecture in [RFC3985], so the reader should be familiar with RFC 3985 🧠 it's giving homework but make it cute 🎀
The Pseudowire Emulation Edge-to-Edge (PWE3) Ethernet PDU is made up of the Destination Address, Source Address, Length/Type, MAC Client Data, and padding pulled out of a MAC frame, joined into one octet sequence in their original order [PDU] 💅
On top of the Ethernet PDU format used inside the pseudowire, this doc also covers:
- how to use a PW to give a pair of Customer Edge (CE) routers an emulated (point-to-point) Ethernet service, including how Provider Edge (PE)-bound and CE-bound Ethernet PDUs get processed [RFC3985]
- Ethernet-specific quality of service (QoS) and security considerations
- inter-domain transport considerations for Ethernet PW
the two figures below show the reference models derived from [RFC3985] to support Ethernet PW emulated services 👑
|<-------------- 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 Configurationthe "emulated service" in Figure 1 is, technically, a bridged LAN. the PEs have MAC interfaces, consume MAC control frames, and so on 🙈 but the procedures in this doc only cover the case where there are exactly two CEs on the "emulated LAN." that's why we call it "emulated point-to-point Ethernet." specifying how to use pseudowires to emulate LANs with more than two CEs is out of scope for this 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
for this doc, PE1 is the ingress router and PE2 is the egress router. a layer 2 PDU comes in at PE1, gets encapsulated there, gets transported, gets decapsulated at PE2, and goes out on PE2's attachment circuit 🚀
an Ethernet PW emulates a single Ethernet link between exactly two endpoints ✨ the mechanisms here don't care what's underneath the "Pseudowire" level in Figure 2. they only deal with the "Emulated Service" part of the stack 💖
this reference model shows where each end of the PW terminates inside 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 Diagramthe PW ends at a logical port inside the PE, which is defined at point B in the diagram above. this port gives you an Ethernet MAC service that delivers each Ethernet frame received at point A, unaltered, to point A in the matching PE at the other end of the PW 🧚♀️ bestie, "unaltered" is doing a lot of work there 💅
The Native Service Processing (NSP) function covers the frame processing needed for Ethernet frames that get forwarded to the PW termination point. that can include stripping, overwriting, or adding VLAN tags, physical port multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation, shaping, policing, and so on. these functions are specific to Ethernet technology and may not be required for the PW emulation service 🌸
everything 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, is outside the scope of PWE3 and is not defined here 🙅♀️
"PW Termination," between A and B, covers the operations for setting up and maintaining the PW, and for encapsulating and decapsulating Ethernet frames as needed to send them across the MPLS network 🫶
an Ethernet PW runs 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 means something to the NSPs at the two PW termination points. so 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 doesn't mean anything to the NSPs and passes through them transparently 🦋
more terminology for pseudowires and Layer 2 Virtual Private Networking can 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] 🌈
that's the end of part 1 🎀
3. Applicability Statement 💅
Okay so the Ethernet PW emulation lets a service provider offer a "port to port" Ethernet-based service across an MPLS packet switched network (PSN) 🌐, and the Ethernet VLAN PW emulation gives you an "Ethernet VLAN to VLAN" based service over that same kind of MPLS PSN ✨
An Ethernet or Ethernet VLAN PW has these characteristics compared to its native service, and bestie, you need to know all of them 🫶
- An Ethernet PW connects two Ethernet ACs, and an Ethernet VLAN PW connects two Ethernet VLAN ACs. Both support bidirectional transport of variable length Ethernet frames 🦋 The ingress Native Service Processing (NSP) function strips the preamble and frame check sequence (FCS) off the frame, then carries the whole frame across the PW, no matter whether there's an 802.1Q tag in there or not. On the other side, the egress NSP function gets the frame from the PW and regenerates the preamble or FCS before forwarding it to the attachment circuit. Since the FCS isn't carried across either kind of PW, payload integrity transparency may be lost 😭 If you want payload integrity transparency on Ethernet or Ethernet VLAN PWs, the OPTIONAL method described in [FCS] can get you there 🎀
- For an Ethernet VLAN PW, VLAN tag rewrite can be done by NSP at the egress PE. That's outside the scope of this document, so it's not our tea today 🍓
- An Ethernet or Ethernet VLAN PW only supports a 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 pass 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 so it can 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 gets 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 significant to you, the VLAN identifier MUST be selected in such a way that it matches on the attachment circuits at both ends of the PW.
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 their respective PWs, and it corresponds to PW type 0x0004 "Ethernet Tagged Mode" [IANA] 💖
4.2. Ethernet Raw Mode
The Ethernet frame gets 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, every Ethernet frame received on the attachment circuit of PE1 is 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 it applies, 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], and the IANA registry with initial values for interface parameter sub-TLV types is defined in [IANA]. 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.
4.4. Generic Procedures
When the NSP/Forwarder hands a frame to the PW termination function, here's the main flow 💅
- 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 the proper tunnel encapsulation and pseudowire demultiplexer get 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. It 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 get stripped off. If the control word is present, it is processed and stripped off too. 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 tell two cases apart 👀
- The tag is service-delimiting. This means the tag was placed on the frame by some piece of service provider-operated equipment, and the service provider uses the tag to tell the traffic apart. For example, LANs from different customers might be attached to the same service provider switch, which applies VLAN tags to tell one customer's traffic from another's, and then forwards the frames to the PE 🍰
- The tag is not service-delimiting. This means the tag was placed in the frame by a piece of customer equipment, and it isn't 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., they 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, 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 shows 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 |
+-----------------------------------------------------------+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 don't need 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
okay so in standard Ethernet, flow control is optional 🫶 and it's usually set up between the two nodes on a point-to-point link, like the CE and the PE. IEEE 802.3x PAUSE frames MUST NOT be carried across the PW 🚫. peep Appendix A for the tea on CE-PE flow control 📖
4.5. Management
the Ethernet PW management model follows the general PW management model from [RFC3985] and [PWE3-MIB] 💜. honestly most of the usual PW management stuff just works here, so there's no extra Ethernet drama needed ✨. the Ethernet-specific parameters live in their own MIB module, [PW-MIB] 🎀
4.6. The Control Word
the control word in this section is based on the Generic PW MPLS Control Word from [PWE3-CW] 🦋. it gives you the ability to sequence individual frames on the PW, avoid equal-cost multiple-path load-balancing (ECMP) [RFC2992] 🙅♀️, and run Operations and Management (OAM) mechanisms, including VCCV [VCCV] 🔥
[PWE3-CW] says, "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 matters bc ECMP boxes may peek at the first nibble after the MPLS label stack to figure out if the labelled packet is IP 👀. so if the source MAC address of an Ethernet frame sent over the PW without a control word starts with 0x4 or 0x6, it could get mistaken for an IPv4 or IPv6 packet 😭. depending on the config and topology of the MPLS network, that could mean not all packets for a given PW take the same path. that can bump up out-of-order frames on a PW, or make OAM packets take a different path than the actual traffic (see Section 4.4.3, "Frame Ordering") 💀
the features the control word gives you might not be needed for every Ethernet PW. ECMP might not even be around or active on a given MPLS network, strict frame sequencing might not be required, etc. if that's the vibe, the control word doesn't add much and is therefore optional 💅. some early Ethernet PW implementations got deployed without a control word, or without the ability to process one if it was there 🕰️. so for backwards compatibility, future implementations MUST be able to send and receive frames without the control word present 🫶
in every case, the egress PE MUST be aware of whether the ingress PE will send a control word over a specific PW 🧠. you can get that by configuring the PEs, or by signaling, as defined in [PWE3-CTRL] ✨
here's the control word layout 🎀:
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 diagram above, the first 4 bits MUST be set to 0 to say "this is 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 hold a sequence number that can be used to guarantee ordered frame delivery 🍓. processing 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 lives 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 it's picking the value for a QoS field in the encapsulating protocol (e.g., the EXP fields of the MPLS label stack) 💖. similarly, 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, no matter what QoS support the PSN has 🪄
if an 802.1Q VLAN field gets 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 mentioned above 💅
a PE may support extra QoS by using one or more of these 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.
examples of the cases above, plus the details of the service mapping considerations, are in Appendix B 📚
the PW guaranteed rate at the MPLS PSN level is a PW service provider policy, based on the agreement with the customer 🤝. it may be different from the Ethernet physical port rate 💫
5. Security Considerations 🔐
okay this section is SERIOUS bestie 😤. the Ethernet pseudowire type is subject to all of the general security considerations discussed in [RFC3985] and [PWE3-CTRL] 🚨
the Ethernet pseudowire rides on an MPLS PSN, so the security of the pseudowire itself is only ever as strong as the security of the MPLS PSN 💀. the MPLS PSN can be secured by various methods, as described in [MPLS-ARCH] 🛡️
security from access control of MAC addresses is out of scope for this document 🙅♀️. extra security requirements for using a PW in a switching (virtual bridging) environment aren't discussed here either, because they're not within this document's scope 😮💨
6. PSN MTU Requirements 📏
the MPLS PSN MUST be configured with an MTU big enough to carry a maximum-sized Ethernet frame that's been encapsulated with a control word, a pseudowire demultiplexer, and a tunnel encapsulation 🎁. with MPLS as the tunneling protocol, for example, that's likely to be 8 or more bytes bigger than the largest frame size 📦. the methodology in [FRAG] MAY be used to fragment encapsulated frames that go over the PSN MTU 🧩. however, if [FRAG] isn't used and the ingress router figures out that an encapsulated layer 2 PDU is bigger than the MTU of the PSN tunnel it has to go through, the PDU MUST be dropped 😭🗑️
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.
[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.9. Significant Contributors 🌸
okay bestie, these are the people who put SO much work into this one 🫶 no cap, the list is long and they all deserve a shoutout
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
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
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.seAppendix A. Interoperability Guidelines 💅
A.1. Configuration Options
this list is the menu of configuration options for a point-to-point Ethernet PW, based on the reference points in 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 OptionsAllowed combinations: raw and other services are not allowed on the same NSP virtual port (A). Everything else is 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.
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
so, flow control is the "hey, slow down" signal 🛑 if the receiving node gets congested, it can send a special frame called the PAUSE frame to the source node on the other 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 wants to pause data it receives on a local Ethernet port (maybe because its own buffers are filling up, or because it heard about congestion inside the PSN), then it MAY issue a PAUSE frame on the local Ethernet port, but it MUST clear this condition when it's willing to receive more data 🫶
Appendix B. QoS Details ✨
Section 4.7, "QoS Considerations", describes the different modes for supporting PW QoS over the PSN. Here are some examples for a point-to-point VLAN service 💜
- The classification to the PW is based on the 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 the VLAN field and the PRI bits, and frames with different PRI bits are mapped to different PWs. An example is mapping a PWES to different L-LSPs in an MPLS PSN, to support multiple CoS over an L-LSP-capable network, or mapping 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.
B.1. Adaptation of 802.1Q CoS to PSN CoS
it is not required that the PSN has the same CoS definition as [802.1Q]. 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 the 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 MappingB.2. Drop Precedence
the 802.1P standard doesn't support drop precedence, so from the PW PE-bound point of view there's no mapping required 🙈 it IS possible to mark different drop precedence for different PW frames based on operator policy and the network behavior you want. This isn't discussed any further here.
PSN QoS support and signaling of QoS are out of the scope of this document.
Authors' Addresses 🦋
these are the folks who wrote the actual doc 💖
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.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2006).
this is the legal part, so here it is in full 🙏 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 on whether any Intellectual Property Rights (or other rights) that might be claimed to apply to the technology in this document are valid or in scope, or whether anyone could get a license for them. It also doesn't say it has searched for any such rights. If you want to know how rights work for RFC documents, look at BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that 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).
📦 where this page comes from
- ietf: rfc4448 2006-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms