RFC 3916
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
RFC 3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) 🎀
okay bestie, so this is RFC 3916 and it's giving requirements doc energy 💅. It's from the Network Working Group and was published in September 2004. Its category is Informational, which means it's giving info for the Internet community and is NOT a standard. The authors are X. Xiao (Ed.) from Riverstone Networks, D. McPherson (Ed.) from Arbor Networks, and P. Pate (Ed.) from Overture Networks. The header doesn't list anything it obsoletes or updates, so no drama there 🌸
Status of this Memo 🦋
this memo is just giving info to the Internet community. it does NOT specify an Internet standard of any kind, so don't treat it like one. distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice ✨
Copyright (C) The Internet Society (2004).
Abstract 🧚
this doc lays out the base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG) 🫶 it's basically a guideline for other WG docs that will define mechanisms for pseudo-wire emulation of Ethernet, ATM, and Frame Relay. requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") live in a different doc, so that's not this one 🙈
also, the PWE3 WG standardizes the mechanisms that can be used to provide PWE3 services, but NOT the services themselves. the mechanisms are the tea, the services are someone else's brand 🍓
Table of Contents 🌈
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What Are Pseudo Wires?. . . . . . . . . . . . . . . . . 2
1.2. Current Network Architecture. . . . . . . . . . . . . . 3
1.3. PWE3 as a Path to Convergence . . . . . . . . . . . . . 4
1.4. Suitable Applications for PWE3. . . . . . . . . . . . . 4
1.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Reference Model of PWE3 . . . . . . . . . . . . . . . . . . . 6
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . 7
4.2. Frame Ordering. . . . . . . . . . . . . . . . . . . . . 8
4.3. Frame Duplication . . . . . . . . . . . . . . . . . . . 8
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . 8
4.5. Consideration of Per-PSN Packet Overhead. . . . . . . . 9
5. Maintenance of Emulated Services. . . . . . . . . . . . . . . 9
5.1. Setup and Teardown of Pseudo-Wires. . . . . . . . . . . 9
5.2. Handling Maintenance Message of the Native Services . . 10
5.3. PE-initiated Maintenance Messages . . . . . . . . . . . 10
6. Management of Emulated Services . . . . . . . . . . . . . . . 12
6.1. MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. General MIB Requirements. . . . . . . . . . . . . . . . 12
6.3. Configuration and Provisioning. . . . . . . . . . . . . 13
6.4. Performance Monitoring. . . . . . . . . . . . . . . . . 13
6.5. Fault Management and Notifications. . . . . . . . . . . 13
6.6. Pseudo-Wire Connection Verification and Traceroute. . . 13
7. Faithfulness of Emulated Services . . . . . . . . . . . . . . 13
7.1. Characteristics of an Emulated Service. . . . . . . . . 14
7.2. Service Quality of Emulated Services. . . . . . . . . . 14
8. Non-Requirements. . . . . . . . . . . . . . . . . . . . . . . 14
9. Quality of Service (QoS) Considerations . . . . . . . . . . . 15
10. Inter-domain Issues . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References. . . . . . . . . . . . . . . . . . 17
13.2. Informative References. . . . . . . . . . . . . . . . . 17
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 191. Introduction ✨
1.1. What Are Pseudo Wires? 🧚♀️
okay so Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that emulates the essential attributes of a service like ATM, Frame Relay, or Ethernet over a Packet Switched Network (PSN). it's giving copycat service but make it packet-based 💅 the required functions of PWs include encapsulating service-specific PDUs that show up at an ingress port, carrying them across a path or tunnel, managing their timing and order, and any other operations needed to emulate the behavior and characteristics of the service as faithfully as possible. main character energy 👑
from the customer's point of view, the PW looks like an unshared link or circuit of the chosen service ✨ BUT, ngl, there may be deficiencies that stop some applications from riding a PW. those limitations should be fully described in the appropriate service-specific documents and Applicability Statements 🫶
1.2. Current Network Architecture 🌸
this section is the background tea on where networks are today and why they're changing. it also talks about why providers want converged networks while still supporting the services they already have. finally, it explains how PWs can solve this dilemma 🔥
1.2.1. Multiple Networks 🍓
so for any service provider delivering multiple services, the current setup usually looks like parallel or "overlay" networks. each network runs one specific service, like Frame Relay or Internet access. this is expensive, both in capital expense and operational costs, and having multiple networks makes planning messy 💀 providers end up asking themselves these questions:
- Which of my networks do I build out?
- How many fibers do I need for each network?
- How do I efficiently manage multiple networks?
a converged network helps providers answer these questions in a consistent and economical way 💖
1.2.2. Transition to a Packet-Optimized Converged Network 🦋
to maximize return on their assets and minimize operating costs, providers often want to consolidate the delivery of multiple service types onto a single networking technology ✨
as packet traffic takes up more and more of the available bandwidth, it gets increasingly useful to optimize public networks for the Internet Protocol. BUT (and this is a big but) many providers are dealing with several obstacles when engineering packet-optimized networks 😭 internet traffic is the fastest growing segment, yet it doesn't generate the highest revenue per bit. for example, Frame Relay traffic currently makes more revenue per bit than native IP services do. private line TDM services make even more revenue per bit than Frame Relay does 🤑 on top of that, there's a tremendous amount of legacy equipment in public networks that doesn't speak the Internet Protocol. providers keep using non-IP equipment to deliver a variety of services, and they need a way to interconnect this legacy gear over their IP-optimized core networks 🧚
1.3. PWE3 as a Path to Convergence 🌈
okay real question: how do providers get the capital and operational perks of a new packet-based infrastructure, while still using their existing equipment AND protecting the big revenue stream tied to that equipment? how do they move off mature Frame Relay or ATM networks while still offering these lucrative services? 🤔
one possibility is emulating circuits or services via PWs. circuit emulation over ATM and interworking of Frame Relay and ATM have already been standardized ✨ emulation lets existing services ride across the new infrastructure, which enables the interworking of disparate networks. it's giving bridge 🌉
implemented correctly, PWE3 can provide a means for supporting today's services over a new network 💖
1.4. Suitable Applications for PWE3 🎀
what makes an application suitable (or not) for PWE3 emulation? when you're considering PWs as a way to provide an application, these questions MUST be considered:
Wait, I'm reconsidering that wording, since the original does not use a key word there. Here's the correct version of this section:
1.4. Suitable Applications for PWE3 🎀
what makes an application suitable (or not) for PWE3 emulation? when considering PWs as a means of providing an application, the following questions must be considered:
- Is the application sufficiently deployed to warrant emulation?
- Is there interest on the part of service providers in providing an emulation for the given application?
- Is there interest on the part of equipment manufacturers in providing products for the emulation of a given application?
- Are the complexities and limitations of providing an emulation worth the savings in capital and operational expenses?
if the answer to all four questions is "yes", then the application is likely to be a good candidate for PWE3 🔥 otherwise, there may not be enough overlap between the customers, service providers, equipment manufacturers, and technology to warrant providing such an emulation 🙈
1.5. Summary 💜
to maximize return on their assets and minimize operational costs, many service providers are looking to consolidate the delivery of multiple service offerings and traffic types onto a single IP-optimized network ✨
to create this next-gen converged network, standard methods must be developed to emulate existing telecom formats like Ethernet, Frame Relay, and ATM over IP-optimized core networks. this document describes requirements for accomplishing this goal 🫶
2. Terminology 📚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. these are the capital-letter key words that carry real weight, so read them carefully 🫶
some terms used throughout this document are listed below:
Attachment Circuit (AC)
The physical or virtual circuit attaching a CE
to a PE. An AC can be a Frame Relay DLCI, an
ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC
link, a PPP connection on a physical interface,
a PPP session from an L2TP tunnel, an MPLS LSP,
etc.
Customer Edge (CE) A device where one end of a service originates
and/or terminates. The CE is not aware that it
is using an emulated service rather than a
native service.
Packet Switched Network (PSN)
Within the context of PWE3, this is a network
using IP or MPLS as the mechanism for packet
forwarding.
Provider Edge (PE) A device that provides PWE3 to a CE.
Pseudo Wire (PW) A mechanism that carries the essential elements
of an emulated circuit from one PE to another
PE 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 A Protocol Data Unit (PDU) sent on the PW that
contains all of the data and control
information necessary to emulate the desired
service.
PSN Tunnel A tunnel across a PSN inside which one or more
PWs can be carried.to be continued... 🦋💖
3. Reference Model of PWE3 🧚
okay bestie, so a pseudo-wire (PW) is basically a connection between two provider edge (PE) devices, and it connects two attachment circuits (ACs) 🎀. An AC can be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, an HDLC link, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, and more. the list goes on, it's giving "whatever you're plugged into" 🔌✨
Here's the picture, it's so cute 🦋
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | |==================| | +-----+
^ | +----+ +----+ ^
| | Provider Edge 1 Provider Edge 2 |
| | |
| Attachment Circuit |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 1: PWE3 Reference Modelso during PW setup, the two PEs either get configured or automatically swap info about the service being emulated 🤝. that way, later on, they already know how to handle packets coming from the other end 💅. once a PW is up between two PEs, frames that one PE gets from an AC get encapsulated and sent over the PW to the remote PE. then that remote PE rebuilds the native frames and forwards them to the other CE 🌸. for the full PWE3 architecture tea, go read the PWE3 architecture document [PWE3_ARCH] ✨
this document doesn't assume any particular type of PW (like [L2TPv3] sessions or [MPLS] LSPs) or PSN (like IP or MPLS) is being used 🙈. instead, it describes generic requirements that apply to all PWs and PSNs, for every service, including Ethernet, ATM, and Frame Relay, etc. very universal, very iconic 👑
4. Packet Processing 💖
this section covers the data plane requirements for PWE3 🔥
4.1. Encapsulation 🎁
every PE MUST provide an encapsulation mechanism for PDUs coming from an AC. heads up, the PDUs being encapsulated may or may not have L2 header info, and that depends on the service 🙃. every PWE3 service MUST specify what the PDU is.
a PW header is all the header fields in a PW PDU that the PW egress uses to figure out how to process the PDU 🧠. the PSN tunnel header does NOT count as part of the PW header, not me making rules 😤
here are the specific requirements on PDU encapsulation, bestie:
4.1.1. Conveyance of Necessary L2 Header Information 📦
the egress of a PW needs some info, like which native service the PW PDUs belong to, and maybe some L2 header info, so it knows how to process what it receives 🥺. a PWE3 encapsulation approach MUST provide some mechanism for conveying that info from the PW ingress to the egress. also, not all of that info has to ride in the PW header. some stuff (like the service type of a PW) can just be stored as state at the egress during PW setup 💜
4.1.2. Support of Variable Length PDUs 📏
a PWE3 approach MUST accommodate variable length PDUs, but only if the native service allows variable length PDUs 🌈. for example, a PWE3 approach for Frame Relay MUST accommodate variable length frames. main character energy 💅
4.1.3. Support of Multiplexing and Demultiplexing 🧵
if a service in its native form can group multiple circuits into a "trunk", like multiple ATM VCCs in a VPC or multiple Ethernet 802.1Q interfaces in a port, some mechanism SHOULD be provided so that a single PW can connect two end-trunks ✨. from the encapsulation perspective, sufficient info MUST be carried so the PW egress can demultiplex the individual circuits from the PW. it's giving organized 🗂️
4.1.4. Validation of PW-PDU 🔍
most L2 frames have a checksum field to make sure the frame is intact 🫶. every PWE3 service MUST specify whether the frame's checksum should be preserved across the PW, or removed at the ingress PE and then re-calculated and inserted at the egress PE. for protocols like ATM and FR, the checksum covers link-local info such as the circuit identifiers (for example, the FR DLCI or ATM VPI/VCI). so that checksum MUST be removed at the ingress PE and recalculated at the egress PE. this one is non-negotiable, bestie 💀
4.1.5. Conveyance of Payload Type Information 🏷️
sometimes it's really useful to tell PW traffic apart from other traffic, like IPv4, IPv6, or OAM 👀. for example, if Equal Cost Multi-Path (ECMP) is used in a PSN, that extra distinguishability can lower the chance that PW packets get misordered by the load balancing mechanism. some mechanism SHOULD provide this distinguishability if it's needed. that mechanism MAY be defined in the PWE3 WG or in other WGs 🦄
4.2. Frame Ordering 🔁
when packets carrying PW PDUs traverse a PW, they might arrive at the egress out of order 😭. for some services, the frames (either control frames only, or both control and data frames) have to be delivered in order. for those services, some mechanism MUST be provided to make sure delivery stays in order. one possible approach to spot out-of-order frames is putting a sequence number in the PW header of each packet 🔢. mechanisms for re-ordering frames may be provided by Native Service Processing (NSP) [PWE3_ARCH], but they're out of scope for PWE3, so not our problem, babe 🙅♀️
4.3. Frame Duplication 👯
in rare cases, packets traversing a PW may get duplicated 🙃. for some services, frame duplication is not allowed. for those services, some mechanism MUST be provided to make sure duplicated frames won't be delivered. that mechanism may or may not be the same one used to keep frames in order 🫠
4.4. Fragmentation ✂️
if the combined size of the L2 payload and its associated PWE3 and PSN headers goes over the PSN path MTU, the L2 payload may need to be fragmented (or the L2 frame may be dropped instead) 😬. for certain native services, fragmentation may also be needed to keep a control frame's position relative to the data frames (like an ATM PM cell's relative position). generally, fragmentation has a performance impact, so it's desirable to avoid it when possible. but different services can have different needs for fragmentation 🌷. when there's a potential need for fragmentation, each service-specific PWE3 document MUST specify whether to fragment the frame in question or drop it. if an emulated service chooses to drop the frame, the consequence MUST be specified in its applicability statement. be clear, be iconic ✨
4.5. Consideration of Per-PSN Packet Overhead 🍓
when the L2 PDU is small, multiple PDUs MAY be concatenated before a PSN tunnel header gets added, so the PSN tunnel header overhead goes down 🧁. each encapsulated PDU still carries its own PW header so the egress PE knows how to process it. but the header-efficiency benefit of concatenating PDUs should be weighed against the resulting increase in delay, jitter, and the bigger penalty from packet loss ⚖️. no free lunch, periodt 💅
5. Maintenance of Emulated Services 🛠️
this section covers the maintenance requirements for PWE3 🎀
5.1. Setup and Teardown of Pseudo-Wires 🌸
a PW must be set up before an emulated circuit can be established, and it must be torn down when the emulated circuit is no longer needed 🧹. setup and teardown of a PW can be triggered by a command from a PE's management plane, by Setup/Teardown of an AC (for example, an ATM SVC), or by an auto-discovery mechanism 🤖.
every PWE3 approach MUST define some setup mechanism for establishing the PWs. during setup, the PEs need to exchange some info (for example, to learn each other's capabilities) 🫶. the setup mechanism MUST enable the PEs to exchange all necessary info. for example, both endpoints must agree on methods for encapsulating PDUs and handling frame ordering 🤝. which signaling protocol to use and what info to exchange are service specific, and every PWE3 approach MUST specify them. manual configuration of PWs can be considered a special kind of signaling, and it's allowed 🙌
if a native circuit is bi-directional, the matching emulated circuit can only be signaled "Up" when the associated PW and PSN tunnels in both directions are functional 🟢
5.2. Handling Maintenance Message of the Native Services 📬
some native services have maintenance mechanisms, like ATM OAM and FR LMI 🧐. those maintenance messages can be in-band (mixed in with data messages on the same AC) or out-of-band (sent over a dedicated control circuit). for these services, all in-band maintenance messages related to a circuit SHOULD be transported in-band, just like data messages, through the corresponding PW to the remote CE 🚀. in other words, no translation is needed at the PEs for in-band maintenance messages. it MAY also be desirable to provide higher reliability for maintenance messages. the mechanisms for providing that high reliability don't have to be defined in the PWE3 WG 🫡
out-of-band maintenance messages between a CE and a PE may relate to multiple ACs between that CE and PE. they need to be processed at the local PE and possibly at the remote PE too 🔍. if a native service has out-of-band maintenance messages, the corresponding emulated service MUST specify how the PEs process those messages. in general, an out-of-band maintenance message is either translated into an in-band maintenance message of the native service, or turned into a PWE-specific maintenance message for every AC related to that out-of-band message 🔀. for example, say the ACs between a CE and a PE are some ATM VCCs inside a VPC. when the PE receives an F4 AIS [UNI3.0] from the CE, the PE should translate that F4 AIS into an F5 AIS and send it to the remote CE for every VCC 🦋. or, the PE should generate a PWE-specific maintenance message (for example, a label withdrawal) to the remote PE for every VCC instead. when the remote PE receives that PWE-specific maintenance message, it may need to generate a maintenance message of the native service and send it to the attached CE 💜
5.3. PE-initiated Maintenance Messages 🔔
Okay so sometimes a PE has to send its own maintenance messages without the CE asking for anything first 🙈 Usually this happens because something broke, like a PW failing across the PSN or a link dying between a CE and its PE.
Here's why this matters. Once a PW sits between two CEs, the CEs lose some of their maintenance powers, and that's the problem. Picture two CEs plugged straight into each other with a physical wire. If the wire breaks, a native service like ATM can hear about it from the physical layer below and react, so an ATM PVC can be signaled "Down" if the wire fails. Now put a PW in the middle:
+-----+ Phy-link +----+ +----+ Phy-link +-----+
| CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
+-----+ +----+ +----+ +-----+If the PW between PE1 and PE2 fails, CE1 and CE2 never get a physical link failure notification 😭 So they can't declare the emulated circuit down quickly, and that messes up the higher layer applications riding on top. So when the PW fails, PE1 and PE2 have to send some maintenance messages to tell the client layer on CE1 and CE2 (the one using the PW as its server layer, which here is the emulated service) what happened 💅 Same deal if the PE1-CE1 link dies: PE1 sends out maintenance message(s) so the client layer at CE2 finds out. PE2 might have to help with that too 🫶
Now the rare case: a physical wire between two CEs can get so many bit errors that the link gets declared "Down" and the client layer at the CEs gets notified. A PW can have its own version of this, with packet loss, corruption, and out-of-order delivery. We can lump all of that together as "generalized bit error" 🧠 If a PE detects excessive "generalized bit error", the PW can be declared "Down", and the detecting PE needs to send a maintenance message so the client layer at the CE gets the news.
Every emulated service MUST spell out three things:
- The circumstances under which PE-initiated maintenance messages are needed,
- The format of those maintenance messages, and
- How the remote PE processes them.
Some monitoring mechanisms are also needed to catch these situations, like a PW failure. Those mechanisms can be defined in the PWE3 WG or somewhere else 🌸
Here's a fun one: one network incident can affect a whole group of emulated circuits at once 🍓 If the physical link between a CE and a PE dies, every emulated circuit running over that link fails together. So it's really nice to use one maintenance message to report the failure for the whole group of circuits that connect to the same remote PE. A PWE3 approach MAY offer some mechanism for reporting status changes for a group of emulated circuits. One idea for doing that is to give each emulated circuit a group ID when its PW is being set up. Then a maintenance message can use that group ID to point at every circuit in the group ✨
If a PE needs to generate and send a maintenance message to a CE, the PE MUST use a maintenance message of the native service. This is essential for keeping the emulated service transparent to the CEs 👑
The requirements in this section line up with the ITU-T maintenance philosophy for telecommunications networks [G805], which uses the client layer/server layer concept 🧚
6. Management of Emulated Services 🎀
Each PWE3 approach SHOULD provide some mechanisms that let network operators manage the emulated service. Those mechanisms can take the forms described below 💖
6.1. MIBs 📚
SNMP MIBs [SMIV2] MUST be provided for managing each emulated circuit as well as pseudo-wire in general. These MIBs SHOULD be created with the following requirements.
6.2. General MIB Requirements 🧩
New MIBs MUST augment or extend, where appropriate, existing tables defined in other existing service-specific MIBs for existing services such as MPLS or L2TP. For example, the ifTable as defined in the Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-order packets. A second example is extending the MPLS-TE-MIB [TEMIB] when you're emulating circuit services over MPLS. Instead of redefining the tunnelTable so that PWE can use MPLS tunnels, entries in this table MUST be extended with additional PWE-specific objects 🙌 A final example would be extending the IP Tunnel MIB [IPTUNMIB] so it provides PWE3-specific semantics when tunnels other than MPLS are used as PSN transport. This is great because it makes extending the objects already defined in the existing MIBs feel natural for management, and it lets you reuse existing agent implementations 🫶
An AC MUST appear as an interface in the ifTable 🦋
6.3. Configuration and Provisioning ⚙️
MIB Tables MUST be designed to facilitate configuration and provisioning of the AC.
The MIB(s) MUST facilitate intra-PSN configuration and monitoring of ACs.
6.4. Performance Monitoring 📈
MIBs MUST collect statistics for performance and fault management.
MIBs MUST provide a description of how existing counters are used for PW emulation and SHOULD not replicate existing MIB counters 💅
6.5. Fault Management and Notifications 🚨
Notifications SHOULD be defined where appropriate to notify network operators of any interesting situations, including faults detected in the AC.
Objects that are defined to augment existing protocol-specific notifications in order to add PWE functionality MUST explain how those notifications are emitted 🔥
6.6. Pseudo-Wire Connection Verification and Traceroute 🔍
For network management purposes, a connection verification mechanism SHOULD be supported by PWs. Connection verification, along with other alarming mechanisms, can alert network operators that a PW has lost its remote connection. Sometimes it's really useful to know the exact functional path of a PW for troubleshooting, so a traceroute function that reports the path taken by data packets over the PW SHOULD be provided 🗺️
7. Faithfulness of Emulated Services 💕
An emulated service SHOULD be as similar to the native service as possible, but it is NOT REQUIRED to be identical. The applicability statement of a PWE3 service MUST report the limitations of the emulated service 🙃
Here are some basic requirements on how faithful an emulated service needs to be 👇
7.1. Characteristics of an Emulated Service 🪞
From the CE's point of view, an emulated circuit looks like an unshared link or circuit of the chosen service, even though the service quality might be different from the native one ✨ Specifically, the following requirements MUST be met:
- It MUST be possible to define the type (for example Ethernet, which is inherited from the native service), speed (for example 100Mbps), and MTU size for an emulated circuit, if it's possible to do that for a native circuit.
- If the two endpoints CE1 and CE2 of emulated circuit #1 are connected to PE1 and PE2 respectively, and CE3 and CE4 of emulated circuit #2 are also connected to PE1 and PE2, then the PWs of these two emulated circuits MAY share the same physical paths between PE1 and PE2. But from each CE's perspective, its emulated circuit MUST appear as unshared. For example, CE1/CE2 MUST NOT be aware of the existence of emulated circuit #2 or CE3/CE4 🙈
- If an emulated circuit fails (either at one of the ACs or in the middle of the PW), both CEs MUST be notified in a timely manner, if they would be notified in the native service (see Section 5.3 for more information). What "timeliness" means is service-dependent ⏰
- If a routing protocol (for example an IGP) adjacency can be established over a native circuit, it MUST be possible for it to be established over an emulated circuit as well 💜
7.2. Service Quality of Emulated Services 💅
It is NOT REQUIRED that an emulated service provide the same service quality as the native service. The PWE3 WG only defines mechanisms for providing PW emulation, not the services themselves. What quality to provide for a specific emulated service is a matter between a service provider (SP) and its customers, and it's outside the scope of the PWE3 WG 🌈
8. Non-Requirements 🙅♀️
Some non-requirements are mentioned in various sections of this document. Those work items are outside the scope of the PWE3 WG. Here they are, summarized 📝
- Service interworking;
In Service Interworking, the IWF (Interworking Function) between two dissimilar protocols (for example ATM & MPLS, Frame Relay & ATM, ATM & IP, ATM & L2TP, etc.) terminates the protocol used in one network and translates (i.e., maps) its Protocol Control Information (PCI) to the PCI of the protocol used in the other network, for User, Control and Management Plane functions to the extent possible 🔄
- Selection of a particular type of PWs;
- To make the emulated services perfectly match their native services;
- Defining mechanisms for signaling the PSN tunnels;
- Defining how to perform traffic management on packets that carry PW PDUs;
- Providing any multicast service that is not native to the emulated medium.
To illustrate this point, Ethernet transmission to a multicast IEEE-48 address is considered in scope, while multicast services like [MARS] that are implemented on top of the medium are out of scope 🫠
9. Quality of Service (QoS) Considerations 🌟
Some native services, such as ATM, can offer higher service quality than the best effort Internet service. So QoS is essential for making sure emulated services are compatible (but not necessarily identical) to their native forms 💫 It's up to network operators to decide how to provide QoS. They can choose to rely on over-provisioning and/or deploy some QoS mechanisms 🛠️
To take advantage of QoS mechanisms defined in other working groups, for example the traffic management schemes defined in the DiffServ WG, it's desirable that some mechanisms exist for differentiating the packets that result from PDU encapsulation. Those mechanisms don't have to be defined in the PWE3 approaches themselves. For example, if the resulting packets are MPLS or IP packets, their EXP or DSCP field can be used for marking and differentiating 🎯 A PWE3 approach MAY provide guidelines for marking and differentiating.
Whether PWE3 fits a particular service depends on how sensitive that service (or the CE implementation) is to delay, jitter, and so on, and on how well the application layer can mask them. PWE3 may not be applicable to services that have severe constraints in this respect 🥹
10. Inter-domain Issues 🌸
okay so PWE is basically a matter between the two PW end-points, and the network devices in the middle just vibe and don't care 🦋 which means inter-domain PWE is fundamentally similar to intra-domain PWE! as long as both end-points use the same PWE approach, they can communicate totally fine, even if they're in different domains 💖
security may get more important in the inter-domain case 🔐 so some security measure, like end-point authentication, MAY be applied.
QoS can get harder to deliver too 😭 because one service provider has no control over another provider's provisioning and traffic management policy. to fix the inter-domain QoS problem, the providers have to cooperate 🫶 once they agree at a contractual level to provide high quality of service to certain traffic (e.g., PWE traffic), the mechanisms defined in other working groups, e.g., the Diffserv WG, can be used ✨
inter-domain PSN tunnels are generally more difficult to set up, tear down and maintain than intra-domain ones. but that's an issue for PSN tunneling protocols such as MPLS and L2TPv3, and it's outside the scope of PWE3 💅
11. Security Considerations 💀
okay this section is serious, bestie 🙈 the PW end-point, the PW demultiplexing mechanism, and the payloads of the native service can all be vulnerable to attack. PWE3 should lean on security mechanisms provided by the PW Demultiplexer or PSN layers. those mechanisms SHOULD protect the PW end-point and PW Demultiplexer mechanism from denial-of-service (DoS) attacks and spoofing of the native data units. preventing unauthorized access to PW end-points and other network devices is generally effective against DoS attacks and spoofing, and it can be part of a protection mechanism 🛡️ protection mechanisms SHOULD also address the spoofing of tunneled PW data. validating traffic addressed to the PW Demultiplexer end-point is paramount for keeping the PW encapsulation intact 🔥 and security protocols such as IPsec [RFC2401] can be used.
12. Acknowledgments 🫶
the authors want to give a huge shoutout to M. Aissaoui, M. Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, and S. Vainshtein for their input ✨👑
13. References 📚
13.1. Normative References
- [IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. 🦋
- [SMIV2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 🌈
13.2. Informative References
- [G805] "Generic Functional Architecture of Transport Networks", ITU-T Recommendation G.805, 2000.
- [IPTUNMIB] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
- [L2TPv3] Lau, J., Townsley, M., and I. Goyret, et al., "Layer Two Tunneling Protocol (Version 3)", Work in Progress, June 2004.
- [MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
- [MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", Work in Progress, March 2004.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 🔐
- [TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
- [UNI3.0] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Sept. 1993.
14. Authors' Addresses 💌
XiPeng Xiao (Editor)
Riverstone Networks
5200 Great America Parkway
Santa Clara, CA 95054
EMail: xxiao@riverstonenet.com
Danny McPherson (Editor)
Arbor Networks
EMail: danny@arbor.net
Prayson Pate (Editor)
Overture Networks
507 Airport Boulevard, Suite 111
Morrisville, NC, USA 27560
EMail: prayson.pate@overturenetworks.com
Vijay Gill
AOL Time Warner
EMail: vijaygill9@aol.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaver Brook Drive
Boxborough, MA 01719
EMail: tnadeau@cisco.com
Craig White
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
EMail: Craig.White@Level3.com15. Full Copyright Statement ⭐
Copyright (C) The Internet Society (2004).
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 in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 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 IETF's procedures with respect to rights in IETF Documents can be found in 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 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: rfc3916 2004-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms