RFC 3985
Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture 🦋
Part 1 of 9 💖
RFC number: 3985 Category: Informational 🌸 Date: March 2005 📅 Authors: S. Bryant, Ed. (Cisco Systems) and P. Pate, Ed. (Overture Networks, Inc.) 👑 Obsoletes / Updates: this title block doesn't list anything it obsoletes or updates 🙈
Status of This Memo ✨
okay so first things first, this memo is just information for the Internet community 💅 It does not specify an Internet standard of any kind, so nobody's getting graded on it lol. Distribution of this memo is unlimited, so share it with everyone you know 🫶
Copyright Notice 🎀
The copyright line says Copyright (C) The Internet Society (2005). That's the legal bit, bestie, so it stays exactly like that 💜
Abstract 🦋
okay so this document is an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) 🌈 The whole vibe is emulating services like Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) that run on IP or MPLS 🔥 It lays out the architectural framework for pseudo wires (PWs), defines the terminology, and specifies the different protocol elements and what they do ✨ Main character energy, honestly 👑
Table of Contents 🧚
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Pseudo Wire Definition. . . . . . . . . . . . . . . . . 2
1.2. PW Service Functionality. . . . . . . . . . . . . . . . 3
1.3. Non-Goals of This Document. . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
2. PWE3 Applicability. . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Layering Model . . . . . . . . . . . . . . . . . . . 6
3.1. Protocol Layers . . . . . . . . . . . . . . . . . . . . 7
3.2. Domain of PWE3. . . . . . . . . . . . . . . . . . . . . 8
3.3. Payload Types . . . . . . . . . . . . . . . . . . . . . 8
4. Architecture of Pseudo Wires. . . . . . . . . . . . . . . . . 11
4.1. Network Reference Model . . . . . . . . . . . . . . . . 12
4.2. PWE3 Pre-processing . . . . . . . . . . . . . . . . . . 12
4.3. Maintenance Reference Model . . . . . . . . . . . . . . 16
4.4. Protocol Stack Reference Model. . . . . . . . . . . . . 17
4.5. Pre-processing Extension to Protocol Stack Reference
Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. PW Encapsulation. . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Payload Convergence Layer . . . . . . . . . . . . . . . 19
5.2. Payload-independent PW Encapsulation Layers . . . . . . 21
5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . 24
5.4. Instantiation of the Protocol Layers. . . . . . . . . . 24
6. PW Demultiplexer Layer and PSN Requirements . . . . . . . . . 27
6.1. Multiplexing. . . . . . . . . . . . . . . . . . . . . . 27
6.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . 28
6.3. Length and Delivery . . . . . . . . . . . . . . . . . . 28
6.4. PW-PDU Validation . . . . . . . . . . . . . . . . . . . 28
6.5. Congestion Considerations . . . . . . . . . . . . . . . 28
7. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Set-up or Teardown of Pseudo Wires. . . . . . . . . . . 29
7.2. Status Monitoring . . . . . . . . . . . . . . . . . . . 30
7.3. Notification of Pseudo Wire Status Changes. . . . . . . 30
7.4. Keep-alive. . . . . . . . . . . . . . . . . . . . . . . 31
7.5. Handling Control Messages of the Native Services. . . . 32
8. Management and Monitoring . . . . . . . . . . . . . . . . . . 32
8.1. Status and Statistics . . . . . . . . . . . . . . . . . 32
8.2. PW SNMP MIB Architecture. . . . . . . . . . . . . . . . 33
8.3. Connection Verification and Traceroute. . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 38
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . 38
12.2. Informative References . . . . . . . . . . . . . . . . 39
13. Co-Authors. . . . . . . . . . . . . . . . . . . . . . . . . . 40
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 421. Introduction 🌸
okay so this doc describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) in support of [RFC3916] 🫶 It's about emulating services like Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS 💖 It gives you the architectural framework for pseudo wires (PWs), defines the terminology, and specifies the protocol elements and their functions ✨
1.1. Pseudo Wire Definition 🎀
ngl this is the core idea, so pay attention bestie 🧚 PWE3 is a mechanism that emulates the essential attributes of a telecommunications service (like a T1 leased line or Frame Relay) over a PSN 🌈 The goal is to provide only the minimum functionality needed to emulate the wire with the required degree of faithfulness for the given service definition 💅 Any switching that's required is the job of a forwarder function (FWRD) 🔥 Any translation or other operation that needs to know the payload semantics gets handled by native service processing (NSP) elements 💜 The functional definition of any FWRD or NSP elements is outside the scope of PWE3, so that's not on this doc 🙈
The required functions of PWs include encapsulating service-specific bit streams, cells, or PDUs that arrive at an ingress port, and carrying them across an IP path or MPLS tunnel 🦋 Sometimes it's also necessary to handle things like managing their timing and order, so the service acts like the original one at the required degree of faithfulness ✨
From the perspective of Customer Edge Equipment (CE), the PW looks like an unshared link or circuit of the chosen service 👑 Sometimes there might be deficiencies in the PW emulation that affect the traffic carried over a PW, and that can limit where this technology is applicable 😭 These limitations must be fully described in the appropriate service-specific documentation, no cap 📝
For each service type, there will be one default mode of operation that all PEs offering that service type must support 💅 Optional modes may also be defined to improve the faithfulness of the emulated service, but only if it's clearly demonstrated that the extra complexity is offset by the value it gives PW users 🌟
1.2. PW Service Functionality 🧚
PWs provide the following functions in order to emulate the behavior and characteristics of the native service 🦋
- Encapsulation of service-specific PDUs or circuit data arriving at the PE-bound port (logical or physical).
- Carriage of the encapsulated data across a PSN tunnel.
- Establishment of the PW, including the exchange and/or distribution of the PW identifiers used by the PSN tunnel endpoints.
- Managing the signaling, timing, order, or other aspects of the service at the boundaries of the PW.
- Service-specific status and alarm management.
1.3. Non-Goals of This Document 🙈
The following are non-goals for this document, so don't look for them here, periodt 💀
- The on-the-wire specification of PW encapsulations.
- The detailed definition of the protocols involved in PW setup and maintenance.
The following are outside the scope of PWE3 🌸
- Any multicast service not native to the emulated medium. Thus, Ethernet transmission to a "multicast" IEEE-48 address is in scope, but multicast services such as MARS [RFC2022] that are implemented on top of the medium are not. 💖
- Methods to signal or control the underlying PSN. 🫧
Part 1 done, more parts incoming! 🌈✨
1.4. Terminology ✨
okay bestie, this section is the glossary 📖💖 The original says these terms are "illustrated in context in Figure 2," so keep that in mind as we go.
- Attachment Circuit (AC) 🔌: the physical or virtual circuit that attaches a CE to a PE. An attachment circuit could be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, or an MPLS LSP. If the physical and virtual ACs are the same technology (both ATM, both Ethernet, both Frame Relay, etc.), the PW is said to provide "homogeneous transport." Otherwise it provides "heterogeneous transport" 🦋
- CE-bound 📥: the traffic direction where PW-PDUs arrive on a PW over the PSN, get processed, and then get sent on to the destination CE.
- CE Signaling 📣: messages sent and received by the CE's control plane. It may be desirable, or even necessary, for the PE to join in on or keep an eye on this signaling so it can emulate the service well 👀
- Control Word (CW) 🧩: a four-octet header used in some encapsulations to carry per-packet information when the PSN is MPLS.
- Customer Edge (CE) 🏠: a device where one end of a service starts and/or ends. The CE has no idea it's using an emulated service instead of a native one, which is honestly iconic 💅
- Forwarder (FWRD) 🧭: a PE subsystem that picks which PW to use to send a payload it received on an AC.
- Fragmentation ✂️: splitting one PDU into multiple PDUs before sending, with the plan that the original gets reassembled somewhere else in the network. Packets might get fragmented if they're bigger than the MTU of the network they're going to cross.
- Maximum Transmission Unit (MTU) 📏: the packet size (not counting the data link header) that an interface can transmit without having to fragment.
- Native Service Processing (NSP) 🛠️: processing the data a PE gets from the CE before it's handed to the PW for transit across the core, or processing the data a PE gets from a PW before it goes out on the AC. NSP functionality is defined by standards bodies other than the IETF, such as ITU-T,ANSI, or ATMF.)
- Packet Switched Network (PSN) 🌐: within the context of PWE3, a network that uses IP or MPLS as its packet forwarding mechanism.
- PE-Bound 📤: the traffic direction where information from a CE is adapted to a PW, and PW-PDUs get sent into the PSN.
- PE/PW Maintenance 🔧: used by the PEs to set up, maintain, and tear down the PW. It may be paired with CE Signaling so the PW can be managed well.
- Protocol Data Unit (PDU) 📦: the unit of data that a protocol layer outputs to the network, or receives from it.
- Provider Edge (PE) 🏢: a device that provides PWE3 to a CE.
- Pseudo Wire (PW) 🪄: a mechanism that carries the essential elements of an emulated service from one PE to one or more other PEs over a PSN.
- Pseudo Wire Emulation Edge to Edge (PWE3) 👑: a mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN.
- Pseudo Wire PDU (PW-PDU) 💌: a PDU sent on the PW that contains all the data and control information needed to emulate the desired service.
- PSN Tunnel 🚇: a tunnel across a PSN, inside which one or more PWs can be carried.
- PSN Tunnel Signaling 🛎️: used to set up, maintain, and tear down the underlying PSN tunnel.
- PW Demultiplexer 🔀: a data-plane method for identifying a PW that terminates at a PE.
- Time Domain Multiplexing (TDM) ⏱️: frequently used to refer to the synchronous bit streams at the rates defined by G.702.
- Tunnel 🦄: a method of carrying information transparently over a network.
2. PWE3 Applicability 🌷
okay so the PSN carrying a PW is going to subject payload packets to loss, delay, delay variation, and re-ordering 😭 During a network transient, service might be impaired for a sustained period. Whether PWE3 is a good fit for a given service depends on how sensitive that service (or the CE implementation) is to these effects, and on whether the adaptation layer can mask them 🧠
Some services are super resilient. IP over FR over PWE3 might handle IP and MPLS PSN characteristics quite well 💪 Other services need much more careful thought about the PSN and adaptation layer characteristics. Interconnecting PBX systems via PWE3 is a good example of that 📞 Sometimes the underlying PSN will need traffic engineering, and in some cases the constraints make the required service guarantees impossible to provide 💀
3. Protocol Layering Model 🍰
the PWE3 protocol-layering model is designed to minimize the differences between PWs running over different PSN types, which is so smart 🧠✨ It has two main goals: making each PW definition independent of the underlying PSN, and maximizing the reuse of IETF protocol definitions and their implementations 🫶
3.1. Protocol Layers 🥞
the logical protocol-layering model needed to support a PW is shown in Figure 1 👇
+---------------------------+
| Payload |
+---------------------------+
| Encapsulation | <==== may be empty
+---------------------------+
| PW Demultiplexer |
+---------------------------+
| PSN Convergence | <==== may be empty
+---------------------------+
| PSN |
+---------------------------+
| Data-Link |
+---------------------------+
| Physical |
+---------------------------+
Figure 1. Logical Protocol Layering ModelThe payload gets transported over the Encapsulation Layer 📦 This layer carries any information that isn't already in the payload itself but is needed by the PW CE-bound PE interface to send the payload to the CE over the physical interface. If the payload itself doesn't need any more information, this layer is empty 🫧
The Encapsulation Layer also supports real-time processing and, if needed, sequencing ⏰
The PW Demultiplexer layer lets you deliver multiple PWs over a single PSN tunnel 🚇 The PW demultiplexer value used to identify the PW in the data plane may be unique per PE, but that's not a PWE3 requirement. It must, however, be unique per tunnel endpoint. And if you need to identify a particular tunnel, that's the PSN layer's job 🙌
The PSN Convergence layer adds the enhancements needed to make the PSN conform to the PSN service requirement that's assumed. So this layer gives the PW a consistent interface, which makes the PW independent of the PSN type 💜 If the PSN already meets the service requirements, this layer is empty ✨
The PSN header, MAC/Data-Link, and Physical Layer definitions are outside the scope of this document. The PSN can be IPv4, IPv6, or MPLS 🌈
3.2. Domain of PWE3 🗺️
PWE3 defines the Encapsulation Layer, the method for carrying various payload types, and the interface to the PW Demultiplexer Layer. The other layers are expected to be provided by tunneling methods such as L2TP or MPLS over the PSN 🎀
3.3. Payload Types 🧁
the payload gets classified into these generic types of native data units:
- Packet 📦
- Cell 🔲
- Bit stream 🌊
- Structured bit stream 🧱
Within these generic types there are specific service types 👀
Generic Payload Type PW Service
-------------------- ----------
Packet Ethernet (all types), HDLC framing,
Frame Relay, ATM AAL5 PDU.
Cell ATM.
Bit stream Unstructured E1, T1, E3, T3.
Structured bit stream SONET/SDH (e.g., SPE, VT, NxDS0).3.3.1. Packet Payload 💌
a packet payload is a variable-size data unit delivered to the PE over the AC 📬 It can be large compared to the PSN MTU. How packet boundaries are delineated depends on the encapsulation. HDLC or Ethernet PDUs are examples of packet payloads. Usually a packet gets stripped of transmission overhead, such as HDLC flags and stuffing bits, before it's sent over the PW 🧼
A packet payload would normally be relayed across the PW as a single unit. But there are cases where the combined size of the packet payload and its associated PWE3 and PSN headers goes over the PSN path MTU 😳 In those cases, some fragmentation methodology has to be applied. That might happen when a user provides the service and attaches to the service provider via Ethernet, or when nested pseudo-wires are involved. Fragmentation gets covered in more detail in section 5.3 🔍
A packet payload may need sequencing and real-time support ⏱️
Sometimes the packet payload gets selected from the packets presented on the emulated wire based on some sub-multiplexing technique. For example, one or more Frame Relay PDUs may be selected for transport over a particular pseudo wire based on the Frame Relay Data-Link Connection Identifier (DLCI), or, for Ethernet payloads, by using a suitable MAC bridge filter 🪞 This is a forwarder function, so that selection happens before the packet is presented to the PW Encapsulation Layer 🧭
3.3.2. Cell Payload ✨
okay bestie, cell payloads 🦋 A cell payload gets made by grabbing groups of octets off the wire in a fixed-size format, carrying them across, and replaying them on the other side. How the group of bits is chopped up depends on the encapsulation type. Two classic examples are the ATM 53-octet cells and the chunkier 188-octet MPEG Transport Stream packets [DVB] 💅
to cut down on per-PSN packet overhead, you can cram multiple cells into a single payload 🍓 The Encapsulation Layer may consider the payload complete when a timer expires, after a fixed number of cells have come in, or when a significant cell (e.g., an ATM OAM cell) shows up. just remember the benefit of bundling PDUs should be weighed against a possible increase in packet delay variation and the bigger penalty when packets get lost 😭 In some cases, it may be appropriate for the Encapsulation Layer to do some kind of compression, like silence suppression or voice compression 🎀
the generic cell payload service will normally need sequence number support and may also need real-time support 🌸 It would not normally require fragmentation, so no chopping up needed bestie ✨
The Encapsulation Layer may apply some form of compression to some of these sub-types (e.g., idle cells may be suppressed). main character compression energy 👑
sometimes the cells get picked out by filtering them from the stream on the wire 🧚 For example, an ATM PWE3 service may select cells based on their VCI or VPI fields. This is a forwarder function, so the selection happens before the packet gets presented to the PW Encapsulation Layer. the forwarder is doing the sorting, periodt 💅
3.3.3. Bit Stream ✨
okay this one is giving pure raw vibes 🌈 A bit stream payload is made by capturing, transporting, and replaying the bit pattern on the emulated wire, without taking advantage of any structure that might be visible in the relayed traffic when you look at it. (i.e., the internal structure has no effect on the fragmentation into packets) 🙈
In some instances it's possible to apply suppression to bit streams 💜 For example, E1 and T1 send "all-ones" to indicate failure. This condition can be detected without knowing anything about the structure of the bit stream, and transmission of packetized data can be suppressed. no structure needed, just vibes 🫶
This service will require sequencing and real-time support ⭐
3.3.4. Structured Bit Stream ✨
a structured bit stream payload is the more organised sibling 🎀 It uses some knowledge of the underlying structure of the bit stream to capture, transport, and replay the bit pattern on the emulated wire.
Two important points set structured and unstructured bit streams apart 💖
- Some parts of the original bit stream may be stripped in the PSN-bound direction by an NSP block. For example, in Structured SONET the section and line overhead (and possibly more) may be stripped. A framer is required to enable such stripping. It is also required for frame/payload alignment for fractional T1/E1 applications. 🦋
- The PW must preserve the structure across the PSN so that the CE-bound NSP block can insert it correctly into the reconstructed unstructured bit stream. The stripped information (such as SONET pointer justifications) may appear in the encapsulation layer to facilitate this reconstitution. this part is so important, don't skip it 😭🔥
As an option, the Encapsulation Layer may also perform silence/idle suppression or similar compression on a structured bit stream 🌸
Structured bit streams are distinguished from cells in that the structures may be too long to be carried in a single packet. Note that "short" structures are indistinguishable from cells and may benefit from the use of methods described in section 3.3.2. (see, it all connects 🧚)
This service requires sequencing and real-time support 💅
3.3.5. Principle of Minimum Intervention ✨
okay so the vibe here is "don't touch the payload unless you have to" 🙈 To minimize the scope of information, and to improve the efficiency of data flow through the Encapsulation Layer, the payload should be transported as received, with as few modifications as possible [RFC1958]. minimal intervention, maximal slay 👑
This minimum intervention approach decouples payload development from PW development and requires fewer translations at the NSP in a system with similar CE interfaces at each end. It also prevents unwanted side effects caused by subtle misrepresentation of the payload in the intermediate format 🫶
An approach that does intervene can be more wire efficient in some cases, and may result in fewer translations at the NSP when the CE interfaces are of different types. ngl, though, any intermediate format effectively becomes a new framing type, which needs documentation and assured interoperability. That adds work for handling the protocol the intermediate format carries, and it is undesirable 💀
4. Architecture of Pseudo Wires ✨
this section is the PWE3 architectural model, so let's get into the blueprint 🌈
4.1. Network Reference Model ✨
Figure 2 illustrates the network reference model for point-to-point PWs 🦋
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 2. PWE3 Network Reference ModelThe two PEs (PE1 and PE2) have to provide one or more PWs on behalf of their client CEs (CE1 and CE2) so the client CEs can talk to each other over the PSN 🫶 A PSN tunnel gets set up to provide a data path for the PW. The PW traffic is invisible to the core network, and the core network is transparent to the CEs 🔮 Native data units (bits, cells, or packets) arrive via the AC, get encapsulated in a PW-PDU, and are carried across the underlying network via the PSN tunnel. The PEs do the encapsulation and decapsulation of PW-PDUs and handle any other functions the PW service requires, like sequencing or timing ⏰✨
4.2. PWE3 Pre-processing ✨
some applications have to do operations on the native data units received from the CE (both payload and signaling traffic) before the PE sends them across the PW 🧚 Examples include Ethernet bridging, SONET cross-connect, translation of locally-significant identifiers such as VCI/VPI, or translation to another service type. These operations could be carried out in external equipment, and the processed data could be sent to the PE over one or more physical interfaces. In most cases, undertaking these operations within the PE provides cost and operational benefits 💖 Processed data is then presented to the PW via a virtual interface within the PE. These pre-processing operations are included in the PWE3 reference model to provide a common reference point, but the detailed description of them is outside the scope of the PW definition given here 🌸
PW
End Service
|
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V PW
+-----+----+ +----+ End Service
+-----+ |PREP | PE1|==================| PE2| | +-----+
| | | |............PW1.............|----------| |
| CE1 |----| | | | | | | CE2 |
| | ^ | |............PW2.............|----------| |
+-----+ | | | |==================| | | ^ +-----+
| +-----+----+ +----+ | |
| ^ | |
| | | |
| |<------- Emulated Service ------->| |
| | |
| Virtual physical |
| termination |
| ^ |
CE1 native | CE2 native
service | service
|
CE2 native
service
Figure 3. Pre-processing within the PWE3 Network Reference ModelFigure 3 shows one PE with pre-processing (PREP) interworking with a second PE that doesn't have this functionality 🦋 This reference point emphasizes that the functional interface between PREP and the PW is the one represented by a physical interface carrying the service. That effectively defines the necessary inter-working specification 💅
The operation of a system where both PEs include PREP functionality is also supported 🌈
The required pre-processing can be divided into two components:
- Forwarder (FWRD) 🧚
- Native Service Processing (NSP) 👑
4.2.1. Forwarders ✨
okay so some apps need to forward payload elements selectively 🎀 from one or more ACs over to one or more PWs. 💅 When that happens, the PE also has to do the reverse on the PWE3-PDUs it gets from the PSN. 🦋 That whole job is the forwarder, and it's giving main character energy 👑
the forwarder picks the PW based on, for example, the incoming AC, the contents of the payload, or some statically and/or dynamically configured forwarding information. 🧚
+----------------------------------------+
| PE Device |
+----------------------------------------+
Single | | |
AC | | Single | PW Instance
<------>o Forwarder + PW Instance X<===========>
| | |
+----------------------------------------+
Figure 4a. Simple Point-to-Point Service
+----------------------------------------+
| PE Device |
+----------------------------------------+
Multiple| | Single | PW Instance
AC | + PW Instance X<===========>
<------>o | |
| |----------------------|
<------>o | Single | PW Instance
| Forwarder + PW Instance X<===========>
<------>o | |
| |----------------------|
<------>o | Single | PW Instance
| + PW Instance X<===========>
<------>o | |
+----------------------------------------+
Figure 4b. Multiple AC to Multiple PW ForwardingFigure 4a is the simple one 🌸 The forwarder has one input and one output, so filtering is the only kind of forwarding that applies. 🙈 Figure 4b is the bigger vibe, where payloads come out of one or more ACs and get sent to one or more PWs. 🔥 In that case, filtering, direction, and combination operations may all be performed on the payloads. 💖 For example, if the AC were Frame Relay, the forwarder might do Frame Relay switching, and the PW instances might be the inter-switch links. 🧚
4.2.2. Native Service Processing 💜
some applications required some form of data or address translation, or some other operation that needs to understand the semantics of the payload. 🤓 That's the job of the Native Service Processor (NSP). 🫶
using the NSP approach makes the PW simpler to design, because it keeps a PW limited to homogeneous operation. ✨ The NSP is in the reference model so there's a defined interface for this functionality. 🌈 The specification of the various types of NSP is outside the scope of PWE3. 🙅♀️
+----------------------------------------+
| PE Device |
Multiple+----------------------------------------+
AC | | | Single | PW Instance
<------>o NSP # + PW Instance X<===========>
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP #Forwarder + PW Instance X<===========>
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP # + PW Instance X<===========>
| | | |
+----------------------------------------+
Figure 5. NSP in a Multiple AC to Multiple PW Forwarding PEFigure 5 shows how the NSP, the forwarder, and the PWs all fit together inside a PE 🦋 The NSP can apply any transformation operation (modification, injection, etc.) to the payloads as they travel between the physical interface to the CE and the virtual interface to the forwarder. 💅 These transformation operations are, of course, limited to the ones that have been implemented in the data path and that are enabled by the PE configuration. 🔥 A PE device may contain more than one forwarder. ✨
this model also supports a system where the NSP functionality includes terminating the data-link, and applying Network Layer processing to the payload. 👑
4.3. Maintenance Reference Model 🎀
Figure 6 shows the maintenance reference model for PWs. 🌸
|<------- CE (end-to-end) Signaling ------>|
| |<---- PW/PE Maintenance ----->| |
| | |<-- PSN Tunnel -->| | |
| | | Signaling | | |
| V V (out of scope) V V |
v +-----+ +-----+ v
+-----+ | PE1 |==================| PE2 | +-----+
| |-----|.............PW1..............|-----| |
| CE1 | | | | | | CE2 |
| |-----|.............PW2..............|-----| |
+-----+ | |==================| | +-----+
+-----+ +-----+
Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2
Figure 6. PWE3 Maintenance Reference Modelthese signaling mechanisms are required 📋
- The CE (end-to-end) signaling is between the CEs. This signaling could be Frame Relay PVC status signaling, ATM SVC signaling, TDM CAS signaling, etc. 💌
- The PW/PE Maintenance is used between the PEs (or NSPs) to set up, maintain, and tear down PWs, including any required coordination of parameters. 🛠️
- The PSN Tunnel signaling controls the PW multiplexing and some elements of the underlying PSN. Examples are L2TP control protocol, MPLS LDP, and RSVP-TE. The definition of the information that PWE3 needs signaled is within the scope of PWE3, but the signaling protocol itself is not. 🧚
4.4. Protocol Stack Reference Model 💖
Figure 7 shows the protocol stack reference model for PWs. 🦋
+-----------------+ +-----------------+
|Emulated Service | |Emulated Service |
|(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+-----------------+ +-----------------+
| Payload | | Payload |
| Encapsulation |<====== Pseudo Wire ======>| Encapsulation |
+-----------------+ +-----------------+
|PW Demultiplexer | |PW Demultiplexer |
| PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, |
| PSN & Physical | | PSN & Physical |
| Layers | | Layers |
+-------+---------+ ___________ +---------+-------+
| / \ |
+===============/ PSN \===============+
\ /
\_____________/
Figure 7. PWE3 Protocol Stack Reference Modelthe PW gives the CE an emulated physical or virtual connection to its peer at the far end. 🌈 Native service PDUs from the CE go through an Encapsulation Layer at the sending PE, and then get sent over the PSN. 📦 The receiving PE takes off the encapsulation and restores the payload to its native format so it can go to the destination CE. 💅
4.5. Pre-processing Extension to Protocol Stack Reference Model ✨
Figure 8 shows how the protocol stack reference model gets extended to include pre-processing (forwarding and NSP). 🔥 It also shows where the physical interface sits relative to the CE. 🧚
/======================================\
H Forwarder H<----Pre-processing
H----------------======================/
H Native Service H | |
H Processing H | |
\================/ | |
| | | Emulated |
| Service | | Service |
| Interface | | (TDM, ATM, |
| (TDM, ATM, | | Ethernet, |<== Emulated Service ==
| Ethernet, | | Frame Relay, |
| Frame Relay, | | etc.) |
| etc.) | +-----------------+
| | | Payload |
| | | Encapsulation |<=== Pseudo Wire ======
| | +-----------------+
| | |PW Demultiplexer |
| | | PSN Tunnel, |
| | | PSN & Physical |<=== PSN Tunnel =======
| | | Headers |
+----------------+ +-----------------+
| Physical | | Physical |
+-------+--------+ +-------+---------+
| |
| |
| |
| |
| |
| |
To CE <---+ +---> To PSN
Figure 8. Protocol Stack Reference Model with Pre-processing5. PW Encapsulation ✨
okay so the PW Encapsulation Layer is basically the adapter 🔌. It takes whatever payload type is riding over the PW and gets it ready for the PW Demultiplexer Layer, which is the part that actually carries the PW across the PSN. main character energy, honestly 💅
The layer has three sub-layers, bestie:
- Payload Convergence
- Timing
- Sequencing
Figure 9 shows how the sub-layering fits into the whole stack 🦋
+---------------------------+
| Payload |
/===========================\ <------ Encapsulation
H Payload Convergence H Layer
H---------------------------H
H Timing H
H---------------------------H
H Sequencing H
\===========================/
| PW Demultiplexer |
+---------------------------+
| PSN Convergence |
+---------------------------+
| PSN |
+---------------------------+
| Data-Link |
+---------------------------+
| Physical |
+---------------------------+
Figure 9. PWE3 Encapsulation Layer in ContextThe Payload Convergence sub-layer is super tailored to each specific payload type 🎀. BUT, and this is the lowkey genius part, if you group a bunch of payload types into one generic class and give that whole group a single convergence sub-layer type, you end up with way fewer convergence sub-layer types overall. That means way less implementation complexity 🧠. This layer is also where per-packet signaling and other out-of-band information gets handled (anything other than sequencing or timing).
The Timing and Sequencing Layers are the generic services that give the Payload Convergence Layer a hand for every payload type that needs them 🫶.
5.1. Payload Convergence Layer
5.1.1. Encapsulation
The big job of the Payload Convergence Layer is wrapping the payload up in PW-PDUs 🎁. The native data units being encapsulated might come with an L2 header or L1 overhead, and that part depends on the service. The Payload Convergence header holds the extra info needed to replay those native data units out the CE-bound physical interface. The PW Demultiplexer header does NOT count as part of the PW header, so don't mix them up 🙈.
Not all of that replay info has to ride in the PW header of every PW PDU, though 💜. Some of it (like the service type of a PW, for example) can just be stored as state at the destination PE during PW set up. so efficient, I'm obsessed 😭
5.1.2. PWE3 Channel Types
The PW Encapsulation Layer and its signaling need one or more of the following channel types from the PW Demultiplexer and PSN Layers underneath (channel type 1 plus one or more of channel types 2 through 4) 🌈:
- A reliable control channel for signaling line events, status indications, and, in exceptional cases, CE-CE events that have to be translated and sent reliably between PEs. PWE3 may need this kind of control channel to faithfully emulate complex data-link protocols 🔥.
- A high-priority, unreliable, sequenced channel. A typical use is CE-to-CE signaling 📣. "High priority" can just be indicated with the DSCP bits for IP or the EXP bits for MPLS, which gives the packet priority while it's in transit. This channel type could also use a bit in the tunnel header itself to tell the PE that packets it receives should get higher-priority processing [RFC2474].
- A sequenced channel for data traffic that's sensitive to packet reordering (one classification you could use is any non-IP traffic) 🍓.
- An unsequenced channel for data traffic that doesn't care about packet order 🧚.
The data channels (2, 3, and 4 above) should be carried "in band" with one another as much as is reasonably possible on a PSN ✨.
Where end-to-end connectivity might get disrupted by address translation [RFC3022], access-control lists, firewalls, etc., the control channel may be able to get traffic through and set up the PW, while the PW data traffic is blocked by one or more of those things 🚧. In those cases, unless the control channel is also carried "in band", the signaling to set up the PW will NOT confirm that an end-to-end data path actually exists 💀. Sometimes you also need to sync CE events with the data carried over a PW. This is especially true for TDM circuits (like on-hook/off-hook events in PSTN switches, which might go over a reliable control channel while the matching bit stream rides a sequenced data channel) 📞.
PWE3 channel types that the supported PWs don't need don't have to be included in an implementation 🫧.
5.1.3. Quality of Service Considerations
Where it's possible, it's desirable to use mechanisms that give PW Quality of Service (QoS) support over PSNs 💖.
5.2. Payload-Independent PW Encapsulation Layers
Two PWE3 Encapsulation sub-layers give common services to ALL payload types: Sequencing and Timing 🌸. These services are optional and only get used if a particular PW instance actually needs them. If a service isn't needed, its header can be left out to save processing and network resources 🙌.
Sometimes a specific payload type needs to be transported with or without sequence and/or real-time support. For example, preserving packet order is an invariant of Frame Relay transport 🎀. Some Frame Relay applications expect in-order delivery and might not cope with frames getting reordered. BUT, if the Frame Relay service is only being used to carry IP, it may be worth relaxing that constraint to cut down on per-packet processing cost 💅.
The guiding principle is this: when possible, an existing IETF protocol should be used to provide these services 👑. When there isn't a suitable protocol, the existing one should be extended or modified to meet the PWE3 requirements, which also makes that protocol available for other IETF uses 🌈. For timing specifically, more than one general method might be needed to cover the full range of payload timing requirements ⭐.
5.2.1. Sequencing
The sequencing function gives three services: frame ordering, frame duplication detection, and frame loss detection 🔍. Together these let the emulation keep the invariant properties of a physical wire 🧵. Support for sequencing depends on the payload type, and it can be left out if it isn't needed.
The size of the sequence-number space depends on the speed of the emulated service and on how long the transient conditions in the PSN can last at most 📏. A sequence number space greater than 2^16 may therefore be needed so the sequence number space doesn't wrap during the transient 🌀.
5.2.1.1. Frame Ordering
When packets carrying the PW-PDUs travel across a PSN, they may arrive out of order at the destination PE 😵💫. For some services, the frames (control frames, data frames, or both) MUST be delivered in order, so some mechanism has to exist for keeping them in order. One option is putting a sequence number in the sequence sub-layer header of each packet. Another option: sequencing is a subset of the problem of delivering timed packets, so a single combined mechanism like [RFC3550] could be used instead 🧩.
There are two possible misordering strategies:
- Drop misordered PW PDUs.
- Try to sort PW PDUs into the correct order.
Which one you pick depends on:
- how critical losing packets is to the operation of the PW (for example, the acceptable bit error rate),
- the speeds of the PW and the PSN,
- the acceptable delay (because you have to add delay in order to reorder), and
- the expected incidence of misordering.
5.2.1.2. Frame Duplication Detection
Every once in a while, packets traversing a PW may get duplicated by the underlying PSN 👯. For some services, duplicated frames are a big no-no 🙅♀️. For those services, some mechanism has to make sure duplicated frames never get delivered to the destination CE. That mechanism can be the same one used to keep frames in order 💜.
5.2.1.3. Frame Loss Detection
A destination PE can figure out whether a frame got lost by tracking the sequence numbers of the PW PDUs it receives 🕵️♀️.
Sometimes, if a PW PDU doesn't arrive within a certain amount of time, the destination PE has to presume it's lost ⏳. If a PW-PDU that's already been processed as lost shows up later, the destination PE must discard it 🗑️. not me being like "wait, you're late?? sorry, gone" 💀
5.2.2. Timing
A bunch of native services have timing expectations based on the characteristics of the networks they were originally designed to travel over ⏰. The emulated service may have to copy those network characteristics as closely as possible. For example, it might need to deliver native traffic with bitrate, jitter, wander, and delay characteristics similar to what the sending PE received 🎶.
In those cases, the receiving PE has to play out the native traffic the same way it was received at the sending PE 🎬. To pull that off, it relies on timing information either sent between the two PEs or, in some cases, received from an external reference 🛰️.
So the Timing Sub-layer MUST support two timing functions: clock recovery and timed payload delivery 🔥. A particular payload type may need either or both of these services.
5.2.2.1. Clock Recovery
Clock recovery is pulling output transmission bit timing information out of the delivered packet stream, and it needs a suitable mechanism for that ⚙️. A physical wire carries timing natively, but getting timing out of a highly jittered source (like a packet stream) is a pretty complex task 😩. So it's desirable to use an existing real-time protocol like [RFC3550] for this, unless it can be shown that doing so is unsuitable or unnecessary for a particular payload type 🫶.
5.2.2.2. Timed Delivery
Timed delivery means handing non-contiguous PW PDUs to the PW output interface with a constant phase relative to the input interface ⏱️. The timing of that delivery may be relative to a clock derived from the packet stream received over the PSN (via clock recovery), or relative to an external clock 🦋.
5.3. Fragmentation 🧩
Okay so ideally, a payload gets relayed across the PW as one single unit, no drama 💅. But sometimes the payload plus its PWE3 and PSN headers adds up to more than the PSN path MTU 😬. When a packet is too big for a network, fragmentation and reassembly have to happen so it can still get delivered. Honestly, that stuff eats up a lot of network resources compared to just switching a whole packet through, so the need for it SHOULD be reduced or eliminated throughout the network to the extent possible ✨. It matters most at aggregation points where tons of PWs get processed, like at the PE.
Ideally, the equipment sending the PW traffic has adaptive measures in place (like [RFC1191] and [RFC1981]) so that packets needing fragmentation never get sent 🦋. When that fails, the point closest to the sending host that can do fragmentation and reassembly SHOULD attempt to shrink packets so they fit the PSN MTU. So in the reference model for PWE3 (Figure 3), fragmentation SHOULD first be performed at the CE if possible. Only if the CE can't hit an acceptable MTU size for the PW SHOULD the PE try its own fragmentation method 🫶.
If MTU management can't squeeze the payload down to a size that works for the PW, the PE MAY fall back to a generic PW fragmentation method or, if there is one, the fragmentation service of the underlying PSN 🌸.
It's totally acceptable for a PE implementation to skip fragmentation support 🤷♀️. A PE that does skip it will drop packets that go over the PSN MTU, and the management plane of the encapsulating PE MAY be notified.
If the length of a L2/L1 frame, restored from a PW PDU, is bigger than the MTU of the destination AC, it MUST be dropped 🚫. In this case, the management plane of the destination PE MAY be notified.
5.4. Instantiation of the Protocol Layers 🎀
This document doesn't get into the detailed mapping of the Protocol Layering model to existing or future IETF standards 📚. The instantiation of the logical Protocol Layering model is shown in Figure 9.
5.4.1. PWE3 over an IP PSN 🌐
The protocol definition of PWE3 over an IP PSN SHOULD employ existing IETF protocols wherever possible 💖.
+---------------------+ +-------------------------+
| Payload |------------->| Raw payload if possible |
/=====================\ +-------------------------+
H Payload Convergence H-----------+->| Flags, seq #, etc. |
H---------------------H / +-------------------------+
H Timing H---------/--->| RTP |
H---------------------H / +-------------+ |
H Sequencing H----one of | |
\=====================/ \ | +-----------+
| PW Demultiplexer |---------+--->| L2TP, MPLS, etc. |
+---------------------+ +-------------------------+
| PSN Convergence |------------->| Not needed |
+---------------------+ +-------------------------+
| PSN |------------->| IP |
+---------------------+ +-------------------------+
| Data-Link |------------->| Data-link |
+---------------------+ +-------------------------+
| Physical |------------->| Physical |
+---------------------+ +-------------------------+
Figure 10. PWE3 over an IP PSNFigure 10 shows the protocol layering for PWE3 over an IP PSN ✨. As a rule, the payload SHOULD be carried exactly as it was received from the NSP, with the Payload Convergence Layer added when needed. That said, in certain circumstances it may be justifiable to send the payload in some processed form 🧐. The reasons for that MUST be documented in the Encapsulation Layer definition for that payload type.
Where it makes sense, explicit timing is provided by RTP [RFC3550], which also provides a sequencing service when it's used 🕰️. When the PSN is UDP/IP, the RTP header follows the UDP header and comes before the PW control field. For all other cases, the RTP header follows the PW control header.
The encapsulation layer MAY also carry a sequence number 🔢. Sequencing is to be provided either by RTP or by the PW encapsulation layer, but not by both, so pick one bestie 😌.
PW Demultiplexing is handled by the PW label, which MAY take whatever form is specified in a bunch of IETF protocols 🏷️. For example, that could be an MPLS label [MPLSIP], an L2TP session ID [RFC3931], or a UDP port number [RFC768]. When PWs are carried over IP, the PSN Convergence Layer will not be needed 🙌.
As a special case, if the PW Demultiplexer is an MPLS label, you can use the protocol architecture of section 5.4.2 instead of the one in this section 💜.
5.4.2. PWE3 over an MPLS PSN 🍓
The MPLS ethos really cares about wire efficiency 🧚. By using a control word, some pieces of the PWE3 protocol layers can be compressed, which makes everything more efficient.
+---------------------+
| Payload |
/=====================\
H Payload Convergence H--+
H---------------------H | +--------------------------------+
H Timing H--------->| RTP |
H---------------------H | +--------------------------------+
H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc |
\=====================/ | +--------------------------------+
| PW Demultiplexer |--------->| PW Label |
+---------------------+ | +--------------------------------+
| PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap|
+---------------------+ | +--------------------------------+
| PSN |-----+
+---------------------+
| Data-Link |
+---------------------+
| Physical |
+---------------------+
Figure 11. PWE3 over an MPLS PSN Using a Control WordFigure 11 shows the protocol layering for PWE3 over an MPLS PSN 💫. An inner MPLS label handles the PW demultiplexing job 🏷️. The control word carries most of the info the PWE3 Encapsulation Layer and the PSN Convergence Layer need, all packed into a compact format 📦. The flags in the control word give you the payload convergence you need 🚩. A sequence field supports both in-order payload delivery and a PSN fragmentation service inside the PSN Convergence Layer (that one needs a fragmentation control method to work) 🧩.
Here's the annoying part: Ethernet pads every frame to a minimum size of 64 bytes 😤. The MPLS header doesn't include a length indicator, so if you want PWE3 carried in MPLS to pass cleanly over an Ethernet data-link, you need a length correction field in the control word 🔧. Same as with an IP PSN, timing is provided by RTP [RFC3550] where it makes sense ⏱️.
In some networks, you might need to carry PWE3 over MPLS over IP 🌈. In that case, the PW gets encapsulated for carriage over MPLS as described in this section, and then a method of carrying MPLS over an IP PSN (like GRE [RFC2784], [RFC2890]) is applied to the resulting PW-PDU 🎁.
5.4.3. PW-IP Packet Discrimination 🕵️♀️
For MPLS PSNs, there's an extra rule on the PW packet format 📜. Some label switched routers detect IP packets based on the first four bits of the packet content. To keep everything working properly, those bits in PW packets MUST NOT match an IP version number in current use 🙅♀️.
6. PW Demultiplexer Layer and PSN Requirements 👑
PWE3 puts three service requirements on the protocol layers that carry it across the PSN 💅:
- Multiplexing
- Fragmentation
- Length and Delivery
6.1. Multiplexing 🦋
The whole point of the PW Demultiplexer Layer is to let multiple PWs ride in a single tunnel. This keeps complexity down and saves resources 🫶.
Some native services can group multiple circuits into a "trunk" 🪢. Examples are multiple ATM VCs in a VP, multiple Ethernet VLANs on a physical media, or multiple DS0 services within a T1 or E1. A PW may interconnect two end-trunks, and that trunk would have a single multiplexing identifier ✨.
When an MPLS label is used as a PW Demultiplexer, setting the TTL value [RFC3032] in the PW label is application specific 🎀.
6.2. Fragmentation 🧩
If the PSN offers a fragmentation and reassembly service with adequate performance, it MAY be used to get an effective MTU that's big enough to transport the PW PDUs 💖. See section 5.3 for the full scoop on PW fragmentation issues.
6.3. Length and Delivery 📦
PDU delivery to the egress PE is the job of the PSN Layer 🚚.
If the underlying PSN doesn't give you all the info needed to figure out the length of a PW-PDU, the Encapsulation Layer MUST provide it 📏.
6.4. PW-PDU Validation 🔍
It's a super common practice to use an error detection mechanism like a CRC or something similar to make sure frames stay intact end-to-end 🛡️. The PW service-specific mechanisms MUST define whether the packet's checksum SHALL be preserved across the PW, or whether it gets removed from PE-bound PDUs and then recalculated for insertion in CE-bound data 🧠.
The first approach saves work, while the second saves bandwidth 💸. For a given implementation, the choice may be dictated by hardware restrictions, which may not allow the checksum to be preserved 🔧.
For protocols like ATM and FR, the checksum's scope is limited to a single link 🔗. That's because the circuit identifiers (like FR DLCI or ATM VPI/VCI) only have local significance and change on every hop or span. If the circuit identifier (and thus the checksum) were going to change as part of the PW emulation, it would be more efficient to strip and recalculate the checksum 😌.
The service-specific document for each protocol MUST describe the validation scheme to be used 📝.
6.5. Congestion Considerations 🌧️
Okay bestie, congestion is the vibe check on the PSN 💀 The PSN carrying the PW may get congested, and how bad it gets depends on the PSN type, the network architecture and configuration, and how loaded the PSN is 🚦
If the traffic carried over the PW is known to be TCP friendly (for example, by packet inspection), then packet discard in the PSN will trigger the reduction in offered load that's needed, and no additional congestion avoidance action is necessary 🫶
If the PW is operating over a PSN that provides enhanced delivery, the PEs should monitor packet loss to make sure the requested service is actually being delivered 👀 If it isn't, then the PE should assume that the PSN is providing a best-effort service and should use the best-effort service congestion avoidance measures described below 💅
If best-effort service is being used and the traffic is not known to be TCP friendly, the PEs should monitor packet loss to make sure the loss rate is within acceptable parameters 🌸 Packet loss is considered acceptable if a TCP flow across the same network path, experiencing the same network conditions, would achieve an average throughput (measured on a reasonable timescale) not less than what the PW flow is achieving. This condition can be satisfied by implementing a rate-limiting measure in the NSP, or by shutting down one or more PWs. The choice between those depends on the type of traffic being carried. Where congestion is avoided by shutting down a PW, a suitable mechanism must be provided to prevent it from immediately returning to service and causing a series of congestion pulses 🙅♀️
The comparison to TCP can't be specified exactly, but it's meant as an "order-of-magnitude" comparison in timescale and throughput 📏 The timescale on which TCP throughput is measured is the round-trip time of the connection. Basically, this requirement says it is not acceptable to deploy an application (using PWE3 or any other transport protocol) on the best-effort Internet that consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. Rude 😤 One method of determining an acceptable PW bandwidth is described in [RFC3448] ✨
7. Control Plane 🎀
This section describes PWE3 control plane services 💜
7.1. Setup or Teardown of Pseudo Wires
A PW must be set up before an emulated service can be established, and it must be torn down when an emulated service is no longer needed 🧚
Setup or teardown of a PW can be triggered by an operator command from the management plane of a PE, by signaling setup or teardown of an AC (e.g., an ATM SVC), or by an auto-discovery mechanism 🔥
During the setup process, the PEs have to exchange information (e.g., learn each other's capabilities). The tunnel signaling protocol may be extended to provide mechanisms that enable the PEs to exchange all necessary information on behalf of the PW 🤝
Manual configuration of PWs can be considered a special kind of signaling and is allowed 🍓
7.2. Status Monitoring
Some native services have mechanisms for status monitoring. For example, ATM supports OAM for this purpose 🔍 For these services, the corresponding emulated services must specify how to perform status monitoring 📋
7.3. Notification of Pseudo Wire Status Changes
7.3.1. Pseudo Wire Up/Down Notification
If a native service requires bi-directional connectivity, the corresponding emulated service can only be signaled as being up when the PW and PSN tunnels (if used) are functional in both directions 🔄
Because the two CEs of an emulated service are not adjacent, a failure may occur at a place so that one or both physical links between the CEs and PEs remain up. For example, in Figure 2, if the physical link between CE1 and PE1 fails, the physical link between CE2 and PE2 will not be affected and will remain up. Unless CE2 is notified about the remote failure, it will continue to send traffic over the emulated service to CE1. Such traffic will be discarded at PE1 😬 Some native services have failure notification, so that when the services fail, both CEs will be notified. For these native services, the corresponding PWE3 service must provide a failure notification mechanism 🚨
Similarly, if a native service has notification mechanisms so that all the affected services will change status from "Down" to "Up" when a network failure is fixed, the corresponding emulated service must provide a similar mechanism for doing so 🌈
These mechanisms may already be built into the tunneling protocol. For example, the L2TP control protocol [RFC2661] [RFC3931] has this capability, and LDP has the ability to withdraw the corresponding MPLS label 🏷️
7.3.2. Misconnection and Payload Type Mismatch
With PWE3, misconnection and payload type mismatch can occur. Misconnection can breach the integrity of the system. Payload mismatch can disrupt the customer network. In both instances, there are security and operational concerns 🚨🔒
The services of the underlying tunneling mechanism and its associated control protocol can be used to mitigate this. As part of the PW setup, a PW-TYPE identifier is exchanged. This is then used by the forwarder and the NSP to verify the compatibility of the ACs 🛡️
7.3.3. Packet Loss, Corruption, and Out-of-Order Delivery
A PW can incur packet loss, corruption, and out-of-order delivery on the PSN path between the PEs. This can affect the working condition of an emulated service 😵💫 For some payload types, packet loss, corruption, and out-of-order delivery can be mapped either to a bit error burst or to loss of carrier on the PW. If a native service has some mechanism to deal with bit errors, the corresponding PWE3 service should provide a similar mechanism 🧩
7.3.4. Other Status Notification
A PWE3 approach may provide a mechanism for other status notifications, if any are needed 📬
7.3.5. Collective Status Notification
The status of a group of emulated services may be affected identically by a single network incident. For example, when the physical link (or sub-network) between a CE and a PE fails, all the emulated services that go through that link (or sub-network) will fail. It is likely that a group of emulated services all terminate at a remote CE. There may also be multiple such CEs affected by the failure. Therefore, it is desirable that a single notification message be used to notify failure of the whole group of emulated services 🫧
A PWE3 approach may provide a mechanism for notifying status changes of a group of emulated circuits. One possible method is to associate each emulated service with a group ID when the PW for that emulated service is set up. Multiple emulated services can then be grouped by associating them with the same group ID. In status notification, this group ID can be used to refer to all the emulated services in that group. The group ID mechanism should be a mechanism provided by the underlying tunnel signaling protocol 👯
7.4. Keep-Alive
If a native service has a keep-alive mechanism, the corresponding emulated service must provide a mechanism to propagate it across the PW. Transparently transporting keep-alive messages over the PW would follow the principle of minimum intervention. However, to reproduce the semantics of the native mechanism accurately, some PWs may require an alternative approach, such as piggy-backing on the PW signaling mechanism 💓
7.5. Handling Control Messages of the Native Services
Some native services use control messages for circuit maintenance. These control messages may be in-band (e.g., Ethernet flow control, ATM performance management, or TDM tone signaling) or out-of-band (e.g., the signaling VC of an ATM VP, or TDM CCS signaling) 📡
Given the principle of minimum intervention, it is desirable that the PEs participate as little as possible in the signaling and maintenance of the native services. This principle should not, however, override the need to emulate the native service satisfactorily 🤏
If control messages are passed through, it may be desirable to send them by using either a higher priority or a reliable channel provided by the PW Demultiplexer layer. See Section 5.1.2, PWE3 Channel Types 🚀
8. Management and Monitoring 📊
This section describes the management and monitoring architecture for PWE3 💖
8.1. Status and Statistics
The PE should report the status of the interface and tabulate statistics that help monitor the state of the network and help measure service-level agreements (SLAs). Typical counters include the following 🧮
- Counts of PW-PDUs sent and received, with and without errors.
- Counts of sequenced PW-PDUs lost.
- Counts of service PDUs sent and received over the PSN, with and without errors (non-TDM).
- Service-specific interface counts.
- One-way delay and delay variation.
These counters would be contained in a PW-specific MIB, and they should not replicate existing MIB counters 🗂️
8.2. PW SNMP MIB Architecture
This section describes the general architecture for SNMP MIBs used to manage PW services and the underlying PSN. The intent here is to provide a clear picture of how all the pertinent MIBs fit together to form a cohesive management framework for deploying PWE3 services 🧩 Note that the names of MIB modules used below are suggestions and do not necessarily require that the actual modules used to realize the components in the architecture be named exactly so 🌷
8.2.1. MIB Layering ✨
okay so the SNMP MIBs made for PWE3 should fit the architecture in Figure 12 🦋 it's a layered, modular setup, which means any supported emulated service can plug into any supported PSN type 💅 the whole point is reuse, bestie 🫶 the emulated service layer MIB modules don't redefine the existing emulated service MIB module. they just link it to the pseudo wires that carry the service over the configured PSN ✨ so the PWE3 MIB architecture follows the overall PWE3 architecture. it's giving consistency 💖
the architecture also lets you join unsupported emulated service or PSN types. you just define extra MIB modules that connect new types to existing ones 🌸 those new modules can later be standardized. there's a separate MIB module for each emulated service, and one for each underlying PSN, and they can be mixed together in different combos as needed 🧚
Native
Service MIBs ... ... ...
| | |
+-----------+ +-----------+ +-----------+
Service | CEP | | Ethernet | | ATM |
Layer |Service MIB| |Service MIB| ... |Service MIB|
+-----------+ +-----------+ +-----------+
\ | /
\ | /
- - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
\ | /
+-------------------------------------------+
Generic PW | Generic PW MIBs |
Layer +-------------------------------------------+
/ \
- - - - - - - - - - - - / - - - - - - - - \ - - - - - - -
/ \
/ \
+--------------+ +----------------+
PSN VC |L2TP VC MIB(s)| | MPLS VC MIB(s) |
Layer +--------------+ +----------------+
| |
Native +-----------+ +-----------+
PSN |L2TP MIB(s)| |MPLS MIB(s)|
MIBs +-----------+ +-----------+
Figure 12. MIB Module Layering RelationshipFigure 13 shows a real example 🎀 a SONET PW carried over an MPLS Traffic Engineering Tunnel and an LDP-signaled LSP 😭
+-----------------+
| SONET MIB | RFC3592
+-----------------+
|
+------------------------------+
Service | Circuit Emulation Service MIB|
Layer +------------------------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
Generic PW | Generic PW MIB |
Layer +-----------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
PSN VC | MPLS VC MIBs |
Layer +-----------------+
| |
+-----------------+ +------------------+
| MPLS-TE-STD-MIB | | MPLS-LSR-STD-MIB |
+-----------------+ +------------------+
Figure 13. SONET PW over MPLS PSN Service-Specific Example8.2.2. Service Layer MIB Modules 🌷
this is the conceptual layer that holds MIB modules representing the relationship between emulated PWE3 services, like Ethernet, ATM, or Frame Relay, and the pseudo-wire carrying that service across the PSN 💫 it also holds the matching MIB modules that mate or adapt those emulated services to the generic pseudo-wire representation, which shows up as the "Generic PW MIB" functional block in Figure 13 above 🦋
now the important bit 👀 this working group should not produce any MIB modules for managing the general service. it should only make the modules that interface or adapt the emulated service onto the PWE3 management framework, as shown above 🙅♀️ for example, the standard SONET-MIB [RFC3592] is designed and maintained by another working group. it manages the native service without PW emulation 💅 but PWE3 is chartered to show how to emulate existing technologies like SONET/SDH over pseudo-wires, instead of reinventing those modules from scratch 🔥
8.2.3. Generic PW MIB Modules 💜
the middle layer is called the Generic PW Layer 🧁 MIBs here are responsible for pseudo-wire specific counters and service models, used for monitoring and configuring PWE3 services over any supported PSN service ✨ basically this layer gives you a general model of PWE3 abstraction for management purposes. it's the connector that links the MIB modules in the Service Layer to the PSN VC Layer MIBs (see section 8.2.4) 🔗
8.2.4. PSN VC Layer MIB Modules 🌈
the third layer in the PWE3 management architecture is the PSN VC Layer 🛤️ it's made of MIBs designed to associate pseudo-wires with the underlying PSN transport technologies that carry the pseudo-wire payloads across the PSN 🚀 in general, the MIB module maps the emulated service (mapped to the pseudo-wire through the Service Layer and the Generic PW MIB Layer) onto the native PSN service 💖
for example, with MPLS, it is required that the general VC service be mapped into MPLS LSPs through the MPLS-LSR-STD-MIB [RFC3813], or into Traffic-Engineered (TE) Tunnels through the MPLS-TE-STD-MIB [RFC3812] 💅 the MPLS-LDP-STD-MIB [RFC3815] may also be used to reveal the MPLS labels that get distributed over the MPLS PSN to keep the PW service alive 🦋 same deal as the native service MIBs from earlier: the MIB modules for managing the native PSN services are produced by other working groups that design and specify those services 🫶 these MIBs should contain the right mechanisms for monitoring and configuring the PSN service, so the emulated PWE3 service can keep working correctly ✨
8.3. Connection Verification and Traceroute 🔍
okay this one is lowkey important 😭 a PW should support a connection verification mechanism. connection verification and other alarm mechanisms can alert the operator that a PW has lost its remote connection 🚨 because a PW is opaque, you can't specify a generic connection verification or traceroute mechanism that passes that status along to the CEs over the PW 🙈 if the CE needs connection verification status of the PW, it must be mapped to the native connection status method 💀
for troubleshooting, it's sometimes useful to know the exact functional path a PW takes between PEs 🗺️ the traceroute service of the underlying PSN provides this. but since the PW is opaque, that traceroute info is only available inside the provider network, for example at the PEs 🏢
9. IANA Considerations 🌸
IANA considerations will be identified in the PWE3 documents that define the PWE3 encapsulation, control, and management protocols 📝
10. Security Considerations 🚨
PWE3 provides no means of protecting the integrity, confidentiality, or delivery of the native data units. this is a big deal, so please hear me out 😱 using PWE3 can therefore expose an environment to extra security threats. assumptions that are fine when every system is connected by a point-to-point or circuit-switched network may stop holding once they're connected over an emulated wire carried by some types of PSN 💀 analyzing and reviewing all the risks of PWE3 is outside the scope of this specification, especially since those risks depend on the PSN 🙏
here's an example that makes the concern clear. a number of IETF standards use fairly weak security mechanisms when the communicating nodes are expected to sit on the same local area network. the Virtual Router Redundancy Protocol [RFC3768] is one instance 🫠 those weak mechanisms are an even bigger vulnerability in an emulated Ethernet connected via a PW 🚩
exploitation of vulnerabilities from within the PSN may be aimed at the PW Tunnel end point, so that PW Demultiplexer and PSN tunnel services are disrupted 😤 one way to protect against this is to control PSN access to the PW Tunnel end point. by restricting PW Tunnel end point access to legitimate remote PE sources of traffic, the PE may reject traffic that would interfere with PW Demultiplexing and PSN tunnel services 🛡️
protection mechanisms must also address spoofing of tunneled PW data. validating traffic addressed to the PW Demultiplexer end-point is paramount for keeping the PW encapsulation intact 👑 security protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer Layer to provide authentication and data integrity between the PW Demultiplexer End-points 🔐
IPSec may provide authentication, integrity, and confidentiality for data transferred between two PEs. it cannot provide the equivalent services to the native service 🥺
depending on the type of data being transferred, the PW may indicate to the PW Demultiplexer Layer that enhanced security services are required. the PW Demultiplexer Layer may define multiple protection profiles based on the requirements of the PW emulated service 💅 CE-to-CE signaling and control events emulated by the PW, plus some data types, may need additional protection mechanisms. alternatively, the PW Demultiplexer Layer may use peer authentication for every PSN packet, which stops spoofed native data units from reaching the destination CE 🧱
the unlimited transformation capability of the NSP may be seen as a security risk. in practice, the operations the NSP can perform are limited to those implemented in the data path 🎯 a PE designed and managed to best current practice will have controls in place that protect and validate its configuration, and those controls will be sufficient to ensure the NSP behaves as expected 🌟
11. Acknowledgements 🫶
we thank Sasha Vainshtein for his work on Native Service Processing and advice on bit stream over PW services, and Thomas K. Johnson for his work on the background and motivation for PWs 💜
we also thank Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John Rutemiller, Scott Wainner, and David Zelig for their comments and contributions 🌈
12. References 📚
12.1. Normative References
Okay bestie, this is the list of the stuff the spec needs you to have read first 📚✨ Every reference is listed with all its details:
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, March
2005.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC3592] Tesink, K., "Definitions of Managed Objects for the
Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Interface Type", RFC 3592, September 2003.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.12.2. Informative References
Now the "good to know" pile 🦋 These ones aren't strictly required reading, but they're the backstage pass:
[DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T), European
Telecommunications Standards Institute (ETSI).
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani,
"Definitions of Managed Objects for the Multiprotocol
Label Switching (MPLS), Label Distribution Protocol
(LDP)", RFC 3815, June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)", RFC
3813, June 2004.
[MPLSIP] Rosen et al, "Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", Work in Progress, March 2004.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1
based ATM Networks", RFC 2022, November 1996.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, Eds, "Requirements
for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.13. Co-Authors
The squad behind this doc 🫶 Here's everyone who co-authored it:
Thomas K. Johnson
Litchfield Communications
Kireeti Kompella
Juniper Networks, Inc.
Andrew G. Malis
Tellabs
Thomas D. Nadeau
Cisco Systems
Tricci So
Caspian Networks
W. Mark Townsley
Cisco Systems
Craig White
Level 3 Communications, LLC.
Lloyd Wood
Cisco Systems14. Editors' Addresses
And the editors, who kept everything together 💅 Here's how to reach them:
Stewart Bryant
Cisco Systems
250, Longwater
Green Park
Reading, RG2 6GB,
United Kingdom
EMail: stbryant@cisco.com
Prayson Pate
Overture Networks, Inc.
507 Airport Boulevard
Morrisville, NC, USA 27560
EMail: prayson.pate@overturenetworks.comFull Copyright Statement
Copyright (C) The Internet Society (2005). 🌈
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 currently provided by the Internet Society. 🫶✨
📦 where this page comes from
- ietf: rfc3985 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms