RFC 4717
Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks
RFC 4717 📄✨
Okay bestie, this is RFC 4717, published in December 2006 as a Standards Track doc 💅. It's titled Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks. The authors are L. Martini, J. Jayakumar (from Cisco Systems, Inc.), M. Bocci (Alcatel), N. El-Aawar (Level 3 Communications, LLC), J. Brayley (ECI Telecom Inc.), and G. Koleyni (Nortel Networks). It's from the Network Working Group. The title block doesn't list anything it obsoletes or updates 🫶.
Status of This Memo 📌
This one specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🗣️. If you want the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.
Copyright Notice ©️
Copyright (C) The IETF Trust (2006) 💜.
Abstract 🦋
Okay so an Asynchronous Transfer Mode (ATM) Pseudowire (PW) carries ATM cells across an MPLS network 🚀. That's what lets service providers offer "emulated" ATM services over MPLS networks they already have, which is honestly iconic 👑. This document spells out how to encapsulate ATM cells inside a pseudowire, and it also covers the procedures for using a PW to deliver an ATM service 🎀.
Table of Contents 📚
1. Introduction ....................................................3
2. Specification of Requirements ...................................4
3. Applicability Statement .........................................4
4. Terminology .....................................................4
5. General Encapsulation Method ....................................6
5.1. The Control Word ...........................................6
5.1.1. The Generic Control Word ............................7
5.1.2. The Preferred Control Word ..........................8
5.1.3. Setting the Sequence Number Field in the
Control Word ........................................9
5.2. MTU Requirements ...........................................9
5.3. MPLS Shim S Bit Value .....................................10
5.4. MPLS Shim TTL Values ......................................10
6. Encapsulation Mode Applicability ...............................10
6.1. ATM N-to-One Cell Mode ....................................11
6.2. ATM One-to-One Cell Encapsulation .........................13
6.3. AAL5 SDU Frame Encapsulation ..............................13
6.4. AAL5 PDU Frame Encapsulation ..............................14
7. ATM OAM Cell Support ...........................................15
7.1. VCC Case ..................................................15
7.2. VPC Case ..................................................16
7.3. SDU/PDU OAM Cell Emulation Mode ...........................16
7.4. Defect Handling ...........................................17
8. ATM N-to-One Cell Mode .........................................18
8.1. ATM N-to-One Service Encapsulation ........................19
9. ATM One-to-One Cell Mode .......................................21
9.1. ATM One-to-One Service Encapsulation ......................21
9.2. Sequence Number ...........................................22
9.3. ATM VCC Cell Transport Service ............................22
9.4. ATM VPC Services ..........................................24
9.4.1. ATM VPC Cell Transport Services ....................25
10. ATM AAL5 CPCS-SDU Mode ........................................26
10.1. Transparent AAL5 SDU Frame Encapsulation .................27
11. AAL5 PDU Frame Mode ...........................................28
11.1. Transparent AAL5 PDU Frame Encapsulation .................28
11.2. Fragmentation ............................................30
11.2.1. Procedures in the ATM-to-PSN Direction ............30
11.2.2. Procedures in the PSN-to-ATM Direction ............31
12. Mapping of ATM and PSN Classes of Service .....................31
13. ILMI Support ..................................................32
14. ATM-Specific Interface Parameter Sub-TLVs .....................32
15. Congestion Control ............................................32
16. Security Considerations .......................................33
17. Normative References ..........................................34
18. Informative References ........................................34
19. Significant Contributors ......................................361. Introduction 🌈
Okay so Packet Switched Networks (PSNs) could seriously simplify a service provider's infrastructure, because pretty much any existing digital service can ride on one networking setup 🧚. The benefit for the provider is threefold, and it's giving efficiency 💅:
- i. Leveraging the existing systems and services to get more capacity out of a packet-switched core 🚀.
- ii. Keeping the existing network operational processes and procedures that maintain legacy services 🛠️.
- iii. Using one common packet-switched infrastructure for both the core capacity needs of existing services and the needs of new services that run natively over the packet-switched network ✨.
This document is about carrying ATM services over MPLS 🦋. It lists the ATM-specific requirements and gives the encapsulation formats and semantics for connecting ATM edge networks through a packet-switched network using MPLS 💖. This model is adapted from [RFC3985].
Figure 1 below shows the ATM services reference model 👀. It's literally the whole picture in one glance 🙈.
|<----- Pseudowire ----->|
| |
| |<-- PSN Tunnel -->| |
ATM Service V V V V ATM Service
| +----+ +----+ |
+----+| | PE1|==================| PE2| |+----+
| |----------|............PW1.............|----------| |
| CE1| | | | | | | |CE2 |
| |----------|............PW2.............|----------| |
+----+ | | |==================| | | +----+
^ +----+ +----+ | ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 1: ATM Service Reference Model2. Specification of Requirements 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🤓. Those are the capital-letter words that carry the weight, so pay attention when you see them 🔥.
3. Applicability Statement 🎯
Real talk: the ATM over PW service isn't meant to perfectly copy a traditional ATM service 💀. But it can totally work for apps that need an ATM transport service 🫶.
Here are the notable differences between traditional ATM service and the protocol in this document 👀:
- ATM cell ordering can be preserved using the OPTIONAL sequence field in the control word 🧠. However, implementations are not required to support this feature, and using it may impact other ATM quality of service (QoS) commitments ⚠️.
- The QoS model for traditional ATM can be emulated 💅. But the detailed specification of ATM QoS emulation is outside the scope of this document 🙃. The emulation must be able to provide the required ATM QoS commitments for the end-user application 🎀.
- The ATM flow control mechanisms are transparent to the MPLS network, so they can't reflect the status of the MPLS network 😶.
- Control plane support for ATM SVCs, SVPs, SPVCs, and SPVPs is outside the scope of this document 🚫.
Note that the encapsulations in this specification are identical to the ones described in [Y.1411] and [Y.1412] ✨.
4. Terminology 💜
Let's get the vocab down, bestie 📚.
One-to-one mode: an encapsulation method that maps one ATM Virtual Channel Connection (VCC) (or one ATM Virtual Path Connection (VPC)) to one pseudowire 🦋.
N-to-one mode (N >= 1): an encapsulation method that maps one or more ATM VCCs (or one or more ATM VPCs) to one pseudowire 🌸.
Packet-Switched Network (PSN): an IP or MPLS network 🌐.
Pseudowire 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 🧚.
Customer Edge (CE): a device where one end of a service originates and/or terminates 🏠. The CE isn't aware that it's using an emulated service instead of a native one 🙈.
Provider Edge (PE): a device that provides PWE3 to a CE 🏢.
Pseudowire (PW): a connection between two PEs carried over a PSN 🔗. The PE handles the adaptation between the CE and the PW 🎀.
Pseudowire PDU: a PDU sent on the PW that contains all the data and control information needed to provide the desired service 📦.
PSN Tunnel: a tunnel that multiple PWs can be nested inside, so they're transparent to core PSN devices 🚇.
PSN Bound: the traffic direction where information from a CE gets adapted to a PW, and PW-PDUs get sent into the PSN ⬆️.
CE Bound: the traffic direction where PW-PDUs are received on a PW from the PSN, converted back into the emulated service, and sent out to a CE ⬇️.
Ingress: the point where the ATM service is encapsulated into a pseudowire PDU (ATM to PSN direction) 🚪.
Egress: the point where the ATM service is decapsulated from a pseudowire PDU (PSN to ATM direction) 🚪.
CTD: Cell Transfer Delay ⏱️.
MTU: Maximum Transmission Unit 📏.
SDU: Service Data Unit 📦.
OAM: Operations And Maintenance 🛠️.
PVC: Permanent Virtual Connection. An ATM connection that's provisioned via a network management interface, and it isn't signaled 🗂️.
VCC: Virtual Circuit Connection. An ATM connection that's switched based on the cell header's VCI 🔀.
VPC: Virtual Path Connection. An ATM connection that's switched based on the cell header's VPI 🔀.
Additional terminology relevant to pseudowires and Layer 2 Virtual Private Networking (L2VPN) in general can be found in [RFC4026] 🌟. More to come in the next part, bestie 🫶✨.
5. General Encapsulation Method ✨
okay bestie, this section is the big picture 🦋 It walks through the general encapsulation format for ATM over PSN pseudowires, so it's basically the layer cake 🍰
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Control Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Service Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: General format for ATM encapsulation over PSNsThe PSN Transport Header is the part that changes depending on which tunneling tech you're using 🚇 Its whole job is to carry the encapsulated ATM info across the packet-switched core, so it's giving delivery driver 🚚
The Pseudowire Header is what picks out one specific ATM service on a tunnel 🎀 If you're on MPLS, this is one or more MPLS labels sitting at the bottom of the label stack 🧚
The ATM Control Word goes right before the ATM service payload 💜 It can hold a length and a sequence number, plus some control bits needed to carry the service. Very organised, very iconic 💅
5.1. The Control Word
okay the control words here are based on the Generic PW MPLS Control Word from [RFC4385] 🌸 They let you sequence individual frames on the PW, avoid equal-cost multiple-path load-balancing (ECMP) [RFC2992], and run OAM stuff, including VCCV [VCCV] 🔥
[RFC4385] says, "If a PW is sensitive to packet misordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism which prevents packet misordering." 😭 This matters because ECMP boxes may peek at the first nibble after the MPLS label stack to figure out whether the labelled packet is IP. So if the VPI of an ATM connection carried over an N-to-one cell mode PW doesn't have a control word, and it starts with 0x4 or 0x6, it could get mistaken for an IPv4 or IPv6 packet 🙈 Depending on the config and topology of the MPLS network, that could mean packets for one PW don't all take the same path. That may increase out-of-order frames on a given PW, or make OAM packets take a different route than the real traffic (see section 4.4.3 on Frame Ordering) 💀
The features the control word gives you might not be needed for every ATM PW. ECMP might not even be around on a given MPLS network, and strict frame sequencing might not be required, etc. ✨ If that's the case, and the control word isn't REQUIRED by the encapsulation mode for other stuff (like length or carrying ATM protocol specific info), then it doesn't add much value, so it's OPTIONAL 🫶 Some early ATM PW implementations got deployed without a control word or any way to process one if it was there. For backwards compatibility, future implementations MUST be able to send and receive frames without a control word present 🍓
Also, in every case, the egress PE MUST know whether the ingress PE is going to send a control word over a specific PW. You can get that by configuring the PEs, or through signaling, as defined in [RFC4447] 👑
If the pseudowire goes over a network link with a minimum frame size (Ethernet is the practical example), where the minimum is 64 octets, then those links will pad the pseudowire PDU up to that minimum 🧸 In that case the control word must include a length field set to the PDU length. And a mechanism is required for the egress PE to detect and remove that padding 🧹
5.1.1. The Generic Control Word
this control word is used in these encapsulation modes:
- ATM One-to-one Cell Mode
- AAL5 PDU Frame Mode
The PWE3 control word document [RFC4385] gives this structure for the generic control word 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Specified by PW Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The detailed structure for the ATM One-to-one Cell Mode and the AAL5 PDU Frame Mode looks like this 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Sequence Number | ATM Specific |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+in that diagram, the first 4 bits MUST be set to 0 to say "this is PW data" 💖 The receiving PE MUST ignore them 🙈
The next four bits are reserved, so they MUST be set to 0 when sending and ignored when receiving 🫧
The next 16 bits hold a sequence number that can guarantee ordered packet delivery ✨ Processing the sequence number field is OPTIONAL 🌈
The sequence number space is a 16-bit unsigned circular space. The value 0 means the sequence number check algorithm isn't used 🔁
The last 8 bits are for ATM-specific flags. Those are defined in the protocol-specific details below 🧚
There's no requirement for a length field in the One-to-one Cell and PDU Frame modes, because the PSN PDU is always greater than 64 bytes. That means no padding gets applied on Ethernet links in the PSN 🙌
5.1.2. The Preferred Control Word
this control word is used in these encapsulation modes:
- ATM N-to-one Cell Mode
- AAL5 SDU Frame Mode
It's defined like this 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |Res| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+In the above diagram, the first 4 bits MUST be set to 0 to indicate PW data. The receiving PE MUST ignore them 🫶
The next 4 bits give you room for protocol-specific flags 🍒 Those are defined in the protocol-specific details below.
The next 6 bits are a length field, and here's how it works 🧮 If the packet's length (that's the layer 2 payload length plus the control word length) is less than 64 bytes, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to zero. A non-zero length value can be used to strip padding. When the packet reaches the service provider's egress router, it may be desirable to remove the padding before forwarding ✂️ Also, the length field isn't used in N-to-one mode and MUST be set to 0 there 🙅♀️
The last 16 bits hold a sequence number that can guarantee ordered packet delivery. Processing the sequence number field is OPTIONAL 🌸
The sequence number space is a 16-bit unsigned circular space, and the value 0 means the sequence number check algorithm isn't used 🔁
5.1.3. Setting the Sequence Number Field in the Control Word
this section covers the sequence number field in both the Generic and Preferred Control Words 📝
For a given emulated VC and a pair of routers PE1 and PE2: if PE1 supports packet sequencing, then the sequencing procedures defined in [RFC4385] MUST be used 🚦
Packets that arrive out of order MAY be dropped or reordered, at the receiver's discretion 🤷♀️
A simple extension of the processing algorithm in [RFC4385] MAY be used to detect lost packets 🕵️♀️
If a PE router negotiated not to use receive sequence number processing, and then it gets a non-zero sequence number, it SHOULD send a PW status message indicating a receive fault and disable the PW 🚨
5.2. MTU Requirements
the network MUST be configured with an MTU big enough to carry the largest encapsulation frames 📏 If MPLS is your tunneling protocol, for example, that's likely to be 12 or more bytes bigger than the largest frame size. Other tunneling protocols may have longer headers and need bigger MTUs 🚛 If the ingress router figures out that an encapsulated layer 2 PDU is bigger than the MTU of the tunnel it has to go through, the PDU MUST be dropped 🗑️ And if an egress router gets an encapsulated layer 2 PDU whose payload length (aka the length of the PDU itself without any of the encapsulation headers) is bigger than the MTU of the destination layer 2 interface, the PDU MUST be dropped too 💀
5.3. MPLS Shim S Bit Value
the ingress label switching router (LSR), PE1, MUST set the S bit of the PW label to 1 to show that the VC label is at the bottom of the stack 👑 For more on setting the S bit, check [RFC3032] 📚
5.4. MPLS Shim TTL Values
how the TTL value in the PW label gets set is application dependent 🧠 But no matter what, the [RFC3032] TTL processing procedure, including how expired TTLs are handled, MUST be followed 🫡
6. Encapsulation Mode Applicability ✨
okay so this doc defines two ways to encapsulate ATM cells: One-to-one mode and N-to-one mode 🫶
N-to-one mode (N >= 1) is the one that maps one or more ATM VCCs (or one or more ATM VPCs) onto a single pseudowire. It is the only REQUIRED mode 👑 Both the VCC and VPC mappings use the same format, and the 4-octet ATM header stays exactly as it is, so the VPI/VCI is always there. Cells from one or more VCCs (or VPCs) can be concatenated 🧚
One-to-one mode maps one ATM VCC or one ATM VPC onto a single pseudowire. For VCCs the VPI/VCI is left out, and for VPCs the VPI is left out. Cells from one VCC or one VPC can be concatenated. This mode is OPTIONAL 🌸
There are also OPTIONAL encapsulations for ATM AAL5 transport, one for ATM AAL5 SDUs and another for ATM AAL5 PDUs 💜
Three deployment models are supported by the encapsulations in this doc 🦋
- i. Single ATM Connection: A PW carries the cells of only one ATM VCC or VPC. This supports both the transport of multiservice ATM and L2VPN service over a PSN for all AAL types.
- ii. Multiple ATM Connections: A PW carries the cells of multiple ATM VCCs and/or VPCs. This also supports both the transport of multiservice ATM and L2VPN service over a PSN for all AAL types.
- iii. AAL5: A PW carries the AAL5 frames of only one ATM VCC. A large proportion of the data carried on ATM networks is frame based and therefore uses AAL5. The AAL5 mapping takes advantage of the delineation of higher-layer frames in the ATM layer to provide increased bandwidth efficiency compared with the basic cell mapping. The nature of the service, as defined by the ATM service category [TM4.0] or the ATM transfer capability [I.371], should be preserved. 🍓
6.1. ATM N-to-One Cell Mode 💅
This encapsulation supports both the Single and Multiple ATM Connection deployment models. This encapsulation is REQUIRED 🔥
It lets multiple VCCs/VPCs ride inside one pseudowire. BUT a service provider might want to give a single VCC its own pseudowire, because that can help with QoS or restoration requirements 🎀
It also supports binding multiple VCCs/VPCs to one pseudowire. This is handy for using the PW demultiplexing header space more efficiently, and it makes the VCC/VPC services easier to provision ✨
In the simplest case, this encapsulation can send a single ATM cell per PSN PDU. For better PSN bandwidth efficiency, several ATM cells may optionally be packed into a single PSN PDU. This is called cell concatenation 🧚
The encapsulation has these attributes:
- i. Supports all ATM Adaptation Layer Types.
- ii. Non-terminating OAM/Admin cells are transported among the user cells in the same order as they are received. This requirement enables the use of various performance management and security applications. 💖
- iii. To gain transport efficiency on the PSN, multiple cells may be encapsulated in a single PW PDU. This is called cell concatenation. How many cells to insert, or how long to wait for cell arrival before sending a PW PDU, is an implementation decision. Cell concatenation adds latency and delay variation to a cell relay service. ⏳
- iv. The CLP bit from each cell may be mapped to a corresponding marking on the PW PDU. This lets the drop precedence be preserved across the PSN. 🌈
- v. If the Single ATM connection deployment model is used, then it is simpler to provide an ATM layer service. The nature of the service, as defined by the ATM service category [TM4.0] or ATM transfer capability [I.371], should be preserved. 👑
The limitations of the ATM N-to-one cell encapsulation are (ngl, read these, they matter 😭):
- vi. There is no currently defined method to translate the forward congestion indication (EFCI) to a corresponding function in the PSN. Nor is there a way to translate PSN congestion to the EFCI upon transmission by the egress PE.
- vii. The ATM cell header checksum can detect a 2-bit error or detect and correct a single-bit error in the cell header. Analogous functionality does not exist in most PSNs. A single bit error in a PW PDU will most likely cause the packet to be dropped due to an L2 Frame Check Sequence (FCS) failure. 💀
- viii. Cells can be concatenated from multiple VCCs or VPCs belonging to different service categories and QoS requirements. In this case, the PSN packet must receive treatment by the PSN to support the highest QoS of the ATM VCCs/VPCs carried. 🔥
- ix. Cell encapsulation only supports point-to-point Label Switched Paths (LSPs). Multipoint-to-point and point-to-multi-point are for further study (FFS). 🙈
- x. The number of concatenated ATM cells is limited by the MTU size and the cell transfer delay (CTD) and cell delay variation (CDV) objectives of multiple ATM connections that are multiplexed into a single PW. 🌸
6.2. ATM One-to-One Cell Encapsulation 🦋
This OPTIONAL encapsulation supports the Single ATM Connection deployment model.
Like N-to-one cell encapsulation, One-to-one mode supports cell concatenation. The perk here is that it uses less bandwidth than N-to-one for the same number of concatenated cells. Since only one ATM VCC or VPC rides on a PW, the VCI and/or VPI can be derived from the PW context using the PW label. So for a VCC these fields don't need to be encapsulated, and for a VPC only the VCI needs to be. This means service providers can get higher bandwidth efficiency on PSN links than with N-to-one, for the same number of concatenated cells 🧚
The limitations vi, vii, ix, and x of N-to-one mode apply 🫶
6.3. AAL5 SDU Frame Encapsulation 🎀
This OPTIONAL encapsulation supports the AAL5 model. It lets ATM AAL5 CSPS-SDUs traveling on a particular ATM PVC cross the network and come out on another ATM PVC. This encapsulation is used by a PW of type 0x0002 "ATM AAL5 SDU VCC transport" as allocated in [RFC4446] ✨
The AAL5 SDU encapsulation is more efficient for small AAL5 SDUs than the VCC cell encapsulations. It's also a more efficient option than cell relay when carrying [RFC2684]-encapsulated IP PDUs across a PSN 💖
The AAL5-SDU encapsulation requires Segmentation and Reassembly (SAR) on the PE-CE ATM interface. This SAR function is provided by common off-the-shelf hardware components. Once reassembled, the AAL5-SDU is carried via a pseudowire to the egress PE. And that's yet another perk of AAL5-SDU encapsulation 🌈
The limitations of the AAL5 SDU encapsulation are (okay this part is a little messy 🙈):
- i. If an ATM OAM cell is received at the ingress PE, it is sent before the cells of the surrounding AAL5 frame. Therefore, OAM cell reordering may occur, which may cause certain ATM OAM performance monitoring and ATM security applications to operate incorrectly.
- ii. If the ALL5 PDU is scrambled using ATM security standards, a PE will not be able to extract the ALL5 SDU, and therefore the whole PDU will be dropped. 😭
- iii. The AAL5 PDU CRC is not transported across the PSN. The CRC must therefore be regenerated at the egress PE since the CRC has end-to-end significance in ATM security. This means that the AAL5 CRC may not be used to accurately check for errors on the end-to-end ATM VCC.
- iv. The Length of AAL5 frame may exceed the MTU of the PSN. This requires fragmentation, which may not be available to all nodes at the PW endpoint. 💀
- v. This mode does not preserve the value of the CLP bit for every ATM cell within an AAL5 PDU. Therefore, transparency of the CLP setting may be violated. Additionally, tagging of some cells may occur when tagging is not allowed by the conformance definition [TM4.0]. 🍓
- vi. This mode does not preserve the EFCI state for every ATM cell within an AAL5 PDU. Therefore, transparency of the EFCI state may be violated. 🔥
6.4. AAL5 PDU Frame Encapsulation 👑
This OPTIONAL encapsulation supports the AAL5 model.
The main application for AAL5 PDU frame encapsulation over PSN is carrying ATM layer services that use AAL5 to carry higher-layer frames, transparently. The big win of this AAL5 mode is that it's transparent to ATM OAM and ATM security applications 🧚
One important consideration is letting OAM information be treated as it was in the original network. This encapsulation mode allows that transparency while doing AAL5 frame encapsulation. It supports fragmentation, which may be performed to keep the position of the OAM cells relative to the user cells 🦋
Fragmentation may also be performed to keep the size of the packet carrying the AAL5 PDU within the MTU of the link. It lets the PE set the size of the PW packet to a different value than the original AAL5 PDU. So the PE gets to control the delay and jitter applied to the ATM cells 💅
The whole AAL5-PDU is encapsulated. In this case, all necessary parameters, such as CPCS-UU (CPCS User-to-User indicator), CPI (Common Part Indicator), Length (Length of the CPCS-SDU) and CRC (Cyclic Redundancy Check), are transported as part of the payload. Carrying the full PDU also simplifies fragmentation, since it's done at cell boundaries and the CRC in the trailer of the AAL5 PDU can be used to check the integrity of the PDU 🌸
Reassembly is not required at the egress PE for the PSN-to-ATM direction 🫶
The limitations v and vi of the AAL5 SDU mode apply to this mode as well 🙈
7. ATM OAM Cell Support ✨
7.1. VCC Case 🦋
okay so, when a PE is set up for ATM VCC service, both PEs SHOULD act as a VC switch, following the OAM procedures in [I.610] 💅
The PEs SHOULD be able to pass these OAM cells through transparently 🫶
- F5 Alarm Indication Signal (AIS) (segment and end-to-end)
- F5 Remote Defect Indicator (RDI) (segment and end-to-end)
- F5 loopback (segment and end-to-end)
- Resource Management
- Performance Management
- Continuity Check
- Security
BUT if the PE is configured as an administrative segment boundary, the PE SHOULD terminate and process F5 segment OAM cells. that's a plot twist 😭
F4 OAM cells get inserted or extracted at the VP link termination. they never show up at the VC link termination, so they're not sent across the PSN 🌸
and this one is important, bestie: when the PE is running in AAL5 CPCS-SDU transport mode and it doesn't support transport of ATM cells, the PE MUST discard incoming MPLS frames on an ATM PW that have a PW label with the T bit set. no exceptions, periodt 💀
7.2. VPC Case 🌈
when a PE is set up for VPC cell relay service, both PEs SHOULD act as a VP cross-connect, following the OAM procedures in [I.610] ✨
The PEs SHOULD be able to process and pass these OAM cells through transparently, according to [I.610] 🧚
- F4 AIS (segment and end-to-end)
- F4 RDI (segment and end-to-end)
- F4 loopback (segment and end-to-end)
However, if the PE is configured as an administrative segment boundary, the PE SHOULD terminate and process F4 segment OAM cells. same energy as before, just with F4 this time 👑
F5 OAM are not inserted or extracted here. the PEs MUST be able to pass these OAM cells transparently, no drama 💖
- F5 AIS (segment and end-to-end)
- F5 RDI (segment and end-to-end)
- F5 loopback (segment and end-to-end)
- Resource Management
- Performance Management
- Continuity Check
- Security
The OAM cell MAY be encapsulated together with other user data cells if multiple cell encapsulation is used 🦋
7.3. SDU/PDU OAM Cell Emulation Mode 💜
A PE running in ATM SDU or PDU transport mode that doesn't support transport of OAM cells across a PW MAY provide OAM support on ATM PVCs using the procedures below. it's like a workaround arc and it's honestly so clever 🍓
- Loopback cells response
If an F5 end-to-end OAM cell is received from an ATM VC by either PE that's transporting this ATM VC, with a loopback indication value of 1, and the PE has a label mapping for the ATM VC, then the PE MUST decrement the loopback indication value and loop back the cell on the ATM VC. Otherwise, the loopback cell MUST be discarded by the PE 🙈
- AIS alarm
If an ingress PE, PE1, receives an AIS F4/F5 OAM cell, it MUST notify the remote PE of the failure. The remote PE, PE2, MUST in turn send F5 OAM AIS cells on the respective PVCs. Note that if the PE supports forwarding of OAM cells, then the received OAM AIS alarm cells MUST be forwarded along the PW as well 🔥
- Interface failure
If the PE detects a physical interface failure, or the interface is administratively disabled, the PE MUST notify the remote PE for all VCs associated with the failure ✨
- PSN/PW failure detection
If the PE detects a failure in the PW, by receiving a label withdraw for a specific PW ID, or the targeted Label Distribution Protocol (LDP) session fails, or a PW status TLV notification is received, then a proper AIS F5 OAM cell MUST be generated for all the affected ATM PVCs. The AIS OAM alarm will be generated on the ATM output port of the PE that detected the failure 😭
7.4. Defect Handling 🧚
Figure 3 shows four possible places where defects can happen on the PWE3 service:
- (a) On the ATM connection from CE to PE
- (b) On the ATM side of the PW
- (c) On the PSN side of the PE
- (d) In the PSN
+----+ +----+
+----+ | PE1|==================| PE2| +----+
| |---a------|b..c........PW1...d.........|----------| |
| CE1| | | | | |CE2 |
| |----------|............PW2.............|----------| |
+----+ | |==================| | +----+
^ +----+ +----+ ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 3: Defect LocationsFor failures at (a) or (b), in the VPC case, the ingress PE MUST be able to generate an F4 AIS when it receives a lower-layer defect (such as LOS). In the VCC case, the ingress PE SHOULD be able to generate an F5 AIS when it receives a corresponding F4 AIS or a lower-layer defect (such as LOS). These messages are sent across the PSN 💅
For failures at (c) or (d), in the VCC case, the egress PE SHOULD be able to generate an F5 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port). In the VPC case, the egress PE SHOULD be able to generate an F4 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port) 🌈
If the ingress PE can't support generating OAM cells, it MAY notify the egress PE using a pseudowire-specific maintenance mechanism, such as the PW status message defined in [RFC4447]. Alternatively, for example, the ingress PE MAY withdraw the pseudowire (PW label) label associated with the service. When the egress PE gets such a notification, it SHOULD generate the appropriate F4 AIS (for VPC) or F5 AIS (for VCC) 🫶
If the PW in one direction fails, then the whole bidirectional service is considered failed. that's a big deal, so keep it in mind 🔥
8. ATM N-to-One Cell Mode 👑
The N-to-one mode (N >= 1) described in this document lets a service provider offer an ATM PVC- or SVC-based service across a network 🦋 The encapsulation lets multiple ATM VCCs or VPCs be carried within a single PSN tunnel. A service provider can also use N-to-one mode to provision either one VCC or one VPC on a tunnel. This section defines the VCC and VPC cell relay services over a PSN and their applicability 💖
8.1. ATM N-to-One Service Encapsulation ✨
okay so this section is the general encapsulation format for ATM over PSN pseudowires 🦋 it's giving "here's the whole outfit" energy
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |Res| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Service Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: General format for ATM encapsulation over PSNs
The PSN Transport Header depends on the particular tunneling technology in use 🚇 it's the bit that carries the encapsulated ATM info through the packet-switched core.
The Pseudowire Header identifies a particular ATM service on a tunnel 🎀 non-ATM services can ride the same PSN tunnel too, so it's not a one-trick pony.
As you can see in Figure 4, the ATM Control Word goes in right before the ATM service payload. It can hold a length field and a sequence number field, plus some control bits that the service needs. 💅
The ATM Service Payload is specific to whichever service the pseudowire is offering. Those details come in the following sections. 🌸
In this encapsulation mode, ATM cells get sent individually 🍓 encapsulating a single ATM cell is the only REQUIRED encapsulation for ATM. Putting more than one ATM cell into a PSN frame is OPTIONAL, so it's a bonus, not a must.
The ATM cell encapsulation is an OPTIONAL control word plus one or more ATM cells. Each cell is a 4-byte ATM cell header followed by the 48-byte ATM cell payload. That header is defined the same way as in section 3.1.1 of [FBATM] (the FAST encapsulation), just without the trailer byte. The length of each frame, not counting the encapsulation headers, is a multiple of 52 bytes. How many cells fit in one frame is only limited by the network MTU and by how well the egress router can process them. ⚡ The ingress router MUST NOT send more cells than the egress router is willing to receive. The egress router's limit can be configured on the ingress router or signaled, for example using the methods described later in this document and in [RFC4447]. You can actually figure out how many cells are in a frame just from the frame length 🧮 The control word is OPTIONAL. If you do use it, the flag and length bits in the control word are not used, and they MUST be set to 0 when transmitting and MUST be ignored upon receipt. Hands off those bits, bestie 🙈
The EFCI and CLP bits travel across the network in the ATM cell header 🌈 Edge routers that implement this document MAY, when adding or removing this encapsulation, flip the EFCI bit from zero to one to show congestion the edge router knows about in the network. They can also flip the CLP bit from zero to one to show marking from edge policing of the ATM Sustained Cell Rate. The EFCI and CLP bits SHOULD NOT be changed from one to zero. Once they're flipped up, they stay up 🙅♀️
This diagram shows an encapsulation of two ATM cells 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control word ( Optional ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Payload ( 48 bytes ) |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Payload ( 48 bytes ) |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Multiple Cell ATM Encapsulation
Here's the rules for the header fields when you've got multiple cells 🎀
- When multiple VCCs or VPCs are carried in one pseudowire, the VPI/VCI values MUST be unique. If the VCCs or VPCs come from a different physical transmission path, you might need to give the ATM connections unique VPI/VCI values. If they come from the same physical transmission path, the VPI/VCI values are already unique. 🧐
- VPI
- The ingress router MUST copy the VPI field from the incoming cell into this field. For particular emulated VCs, the egress router MAY generate a new VPI and ignore the VPI contained in this field. 🦋
- VCI
- The ingress router MUST copy the VCI field from the incoming ATM cell header into this field. For particular emulated VCs, the egress router MAY generate a new VCI. 💜
- PTI & CLP (C bit)
- The PTI and CLP fields are the PTI and CLP fields of the incoming ATM cells. The cell headers of the cells within the packet are the ATM headers (without Header Error Check (HEC) field) of the incoming cell. 🫶
9. ATM One-to-One Cell Mode 🎀
okay the one-to-one mode is the main character here 👑 it lets a service provider offer an ATM PVC- or SVC-based service across a network. The encapsulation lets one ATM VCC or VPC ride inside a single pseudowire. Solo queen energy 💅
9.1. ATM One-to-One Service Encapsulation ✨
this section is the general encapsulation format for ATM over pseudowires on an MPLS PSN 🧚 Figure 6 shows the general format for putting ATM cells into packets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Optional Sequence Number | ATM Specific |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Service Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: General format for One-to-one mode encapsulation over PSNs
The MPLS PSN Transport Header depends on how the MPLS network is configured 🛤️ The Pseudowire Header picks out a particular ATM service inside the PSN tunnel that the PSN Transport Header created.
This header is what carries the encapsulated ATM info through the packet-switched core. 🚀
The generic control word goes in right after the Pseudowire Header. Its presence is REQUIRED, so no skipping it 🙅♀️
The ATM Specific Header goes in right before the ATM service payload. It holds the control bits the service needs, and those are defined in the ATM service descriptions below. The length of the ATM Specific Header may not always be one octet, since it depends on the service type. 🧩
The ATM payload octet group is the payload of the service being encapsulated 💖
9.2. Sequence Number 🦋
The sequence number is not required for all services. 🌸
Treatment of the sequence number is according to section 5.1.3. 💅
9.3. ATM VCC Cell Transport Service 💖
okay bestie, this one is all about mapping one whole ATM VCC (VPI/VCI) onto a single pseudowire 🦋 and it's fully transparent to the ATM Adaptation Layer, so the AAL just vibes in the background 💅. The single-cell VCC transport service is OPTIONAL 🌸, but if you do it, it MUST use this encapsulation format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ATM Cell Payload ( 48 bytes ) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Single ATM VCC Cell Encapsulation
- M (transport mode) bit
The M bit lives in the control byte and tells you whether the packet is carrying an ATM cell or a frame payload 🎀. If it's 0, the packet has an ATM cell. If it's 1, the PDU has an AAL5 payload.
- V (VCI present) bit
The V bit (also in the control byte) says whether the VCI field is in the packet ✨. If it's 1, the VCI field is there for the cell. If it's 0, no VCI field. For a VCC the VCI field isn't required. For a VPC though, the VCI field is required and gets sent with every cell 🧚.
- Reserved bits
The reserved bits should be set to 0 at the transmitter and ignored upon reception 🍓.
- PTI Bits
The 3-bit Payload Type Identifier (PTI) carries the ATM Layer PTI coding of the cell 💜. These bits get set to whatever the PTI of the encapsulated ATM cell is.
- C (CLP) Bit
The Cell Loss Priority (CLP) field shows the CLP value of the encapsulated cell 👑.
For better transport efficiency, the ingress PE SHOULD be able to pack multiple ATM cells into one pseudowire PDU 🔥. The ingress and egress PE MUST agree on a maximum number of cells in a single pseudowire PDU, and they can do that through a pseudowire-specific signaling mechanism or via static configuration 🫶.
When you stuff multiple cells into the same PSN packet, the ATM-specific byte MUST be repeated for each cell 😭. That means each 53-byte ATM cell gets encapsulated using 49 bytes. Here's the multi-cell version:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ATM Cell Payload ( 48 bytes ) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|V|Res| PTI |C| |
+-+-+-+-+-+-+-+-+ |
| ATM Cell Payload ( 48 bytes ) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 8: Multiple ATM VCC Cell Encapsulation9.4. ATM VPC Services 🌈
The VPC service is defined by mapping one VPC (VPI) onto a pseudowire 🦋. So basically it's emulating a Virtual Path cross-connect across the PSN, and every VCC that belongs to the VPC gets carried transparently by the VPC service ✨.
The egress PE may pick a different VPI than the one that came in at the ingress PE 💅. The egress PE MUST choose the outgoing VPI based solely upon the pseudowire header. And as a VPC service, the egress PE MUST NOT change the VCI field 🙈.
9.4.1. ATM VPC Cell Transport Services 💜
The ATM VPC cell transport service is OPTIONAL 🌸.
This service MUST use the following cell mode encapsulation:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ATM Cell Payload ( 48 bytes ) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Single Cell VPC EncapsulationThe ATM control byte holds the same info as in the VCC encapsulation, except for the VCI field 🧁.
- VCI Bits
The 16-bit Virtual Circuit Identifier (VCI) carries the ATM Layer VCI value of the cell 🎀.
For better transport efficiency, the ingress PE SHOULD be able to pack multiple ATM cells into one pseudowire PDU 🔥. The ingress and egress PE MUST agree on a maximum number of cells in a single pseudowire PDU, and that agreement can happen through a pseudowire-specific signaling mechanism or via static configuration 🫶.
If the Egress PE supports cell concatenation, the ingress PE MUST only concatenate cells up to the "Maximum Number of concatenated ATM cells in a frame" interface parameter sub-TLV, the one received as part of the control protocol [RFC4447] 📝.
When multiple ATM cells get encapsulated in the same PSN packet, the ATM-specific byte MUST be repeated for each cell 💀. So each 53-byte ATM cell uses 51 bytes. Here's how that looks:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Optional Sequence Number |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ATM Cell Payload (48 bytes) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |M|V|Res| PTI |C| VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | |
+-+-+-+-+-+-+-+-+ |
| ATM Cell Payload (48 bytes) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 10: Multiple Cell VPC Encapsulation10. ATM AAL5 CPCS-SDU Mode 🎀
The AAL5 payload VCC service maps the payload of an AAL5 VCC onto a single pseudowire 🦋. To make it work, the PE needs ATM segmentation and reassembly support 🔧.
The AAL5 payload CPCS-SDU service is OPTIONAL 🌸.
Okay, so even the tiniest TCP packet needs two ATM cells when it goes over AAL5 on a native ATM device 😩. Nobody wants that padding wasting space on the pseudowire, right? So once the ingress PE reassembles the AAL5 CPCS-PDU, it throws away the PAD and CPCS-PDU trailer, and then drops the leftover payload into a pseudowire PDU ✨.
The egress PE MUST regenerate the PAD and trailer before it transmits the AAL5 frame on the egress ATM port 🔥.
This service does allow OAM and RM cells to get transported 🧚, but it doesn't try to keep those cells in order relative to the cells that make up the AAL5 CPCS-PDU 🙃. Any OAM cell, no matter its type, that shows up while a single AAL5 CPCS-PDU is being reassembled gets sent right away on the pseudowire using N-to-one cell encapsulation, followed by the AAL5 payload 💌.
Heads up, bestie: because of that ordering thing, the AAL5 payload VCC service won't be suitable for ATM applications that need strict ordering of OAM cells (like performance monitoring and security applications) 🚨💀
10.1. Transparent AAL5 SDU Frame Encapsulation ✨
Okay bestie, so the AAL5 CPCS-SDU gets a header slapped on the front 🎀. It looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res |T|E|C|U|Res| Length | Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| ATM cell or AAL5 CPCS-SDU |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: AAL5 CPCS-SDU Encapsulation
The AAL5 payload service encapsulation requires the ATM control word 💅. The flag bits are explained right below, so keep reading.
- Res (Reserved) 🔒 These bits are reserved, so they MUST be set to 0 when you send and ignored when you receive. No drama, just zeros.
- T (transport type) bit 🛸 Bit (T) of the control word tells you whether the packet is carrying an ATM admin cell or an AAL5 payload. If T = 1, the packet contains an ATM admin cell, encapsulated according to the N-to-one cell relay encapsulation, Figure 4. If it's not set, the PDU contains an AAL5 payload. Being able to send an ATM cell in AAL5 SDU mode is meant to give you admin functionality over the AAL5 VCC, though it doesn't try to keep user-cell and admin-cell arrival/transport ordering. Not the vibe for strict ordering, just vibes for admin stuff 🙈.
- E (EFCI) Bit 🌸 The ingress router, PE1, SHOULD set this bit to 1 if the EFCI bit of the final cell of those that transported the AAL5 CPCS-SDU is set to 1, or if the EFCI bit of the single ATM cell to be transported in the packet is set to 1. Otherwise, this bit SHOULD be set to 0. The egress router, PE2, SHOULD set the EFCI bit of all cells that transport the AAL5 CPCS-SDU to the value contained in this field. Basically the EFCI state gets passed along both ways, bestie 🦋.
- C (CLP) Bit 💜 The ingress router, PE1, SHOULD set this bit to 1 if the CLP bit of any of the ATM cells that transported the AAL5 CPCS-SDU is set to 1, or if the CLP bit of the single ATM cell to be transported in the packet is set to 1. Otherwise this bit SHOULD be set to 0. The egress router, PE2, SHOULD set the CLP bit of all cells that transport the AAL5 CPCS-SDU to the value contained in this field. Same energy as the EFCI bit, just for CLP 💅.
- U (Command/Response Field) Bit 🍓 When FRF.8.1 Frame Relay/ATM PVC Service Interworking [RFC3916] traffic is being transported, the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. The ingress router, PE1, SHOULD copy this bit to the U bit of the control word. The egress router, PE2, SHOULD copy the U bit to the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU. This one is all about that Frame Relay interworking life 🌈.
11. AAL5 PDU Frame Mode 🎀
The AAL5 payload PDU service is OPTIONAL. Totally your call, no pressure ✨.
11.1. Transparent AAL5 PDU Frame Encapsulation
In this mode, the ingress PE encapsulates the entire CPCS-PDU, including the PAD and trailer. Everything comes along for the ride 🧚.
This mode MAY support fragmentation procedures described in the "Fragmentation" section below, in order to maintain OAM cell sequencing. So fragmentation is a maybe, and it's there to keep OAM cells in line 🫶.
Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC service is meant to be more efficient than the VCC cell transport service. However, the AAL5 transparent VCC service carries the entire AAL5 CPCS-PDU, including the PAD and trailer. Note that the AAL5 CPCS-PDU is not processed, i.e., an AAL5 frame with an invalid CRC or length field will be transported. One reason for this is that there may be a security agent that has scrambled the ATM cell payloads that form the AAL5 CPCS-PDU. Yes, it's giving "we don't check, we just deliver" 😭.
This service supports all OAM cell flows by using a fragmentation procedure that ensures that OAM cells are not repositioned in respect to AAL5 composite cells. OAM cells stay exactly where they belong, which is so iconic 👑.
The AAL5 transparent VCC service is OPTIONAL. Again, opt-in only 💖.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudowire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Resvd | Optional Sequence Number |M|V| Res |U|E|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| AAL5 CPCS-PDU |
| (n * 48 bytes) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: AAL5 transparent service encapsulation
The generic control word is inserted after the Pseudowire Header. The presence of the control word is MANDATORY. No skipping it, periodt 💅.
The M, V, Res, and C bits are as defined earlier for VCC One-to-one cell mode. Go back and peek at that section if you want the full tea 🍵.
- U Bit 🌙 This field indicates whether this frame contains the last cell of an AAL5 PDU, and represents the value of the ATM User-to-User bit for the last ATM cell of the PSN frame. Note: The ATM User-to-User bit is the least significant bit of the PTI field in the ATM header. This field is used to support the fragmentation functionality described later in this section. Fragmentation is the plot twist here 🔥.
- E (EFCI) bit 🌸 This field is used to convey the EFCI state of the ATM cells. The EFCI state is indicated in the middle bit of each ATM cell's PTI field.
- ATM-to-PSN direction (ingress): The EFCI field of the control byte is set to the EFCI state of the last cell of the AAL5 PDU or AAL5 fragment.
- PSN-to-ATM direction (egress): The EFCI state of all constituent cells of the AAL5 PDU or AAL5 fragment is set to the value of the EFCI field in the control byte.
- C (CLP) bit 💜 This field is used to convey the cell loss priority of the ATM cells.
- ATM-to-PSN direction (ingress): The CLP field of the control byte is set to 1 if any of the constituent cells of the AAL5 PDU or AAL5 fragment has its CLP bit set to 1; otherwise, this field is set to 0.
- PSN-to-ATM direction (egress): The CLP bit of all constituent cells for an AAL5 PDU or AAL5 fragment is set to the value of the CLP field in the control byte. The payload consists of the re-assembled AAL5 CPCS-PDU, including the AAL5 padding and trailer, or the AAL5 fragment.
11.2. Fragmentation ✂️
The ingress PE may not always be able to reassemble a full AAL5 frame. This may be because the AAL5 PDU exceeds the pseudowire MTU, or because OAM cells arrive during reassembly of the AAL5 PDU. In these cases, the AAL5 PDU shall be fragmented. In addition, fragmentation may be desirable to bound ATM cell delay. So sometimes you just gotta chop it up, lowkey iconic 💅.
When fragmentation occurs, the procedures described in the following subsections shall be followed.
11.2.1. Procedures in the ATM-to-PSN Direction
The following procedures shall apply while fragmenting AAL5 PDUs:
- Fragmentation shall always occur at cell boundaries within the AAL5 PDU.
- Set the UU bit to the value of the ATM User-to-User bit in the cell header of the most recently received ATM cell.
- The E and C bits of the fragment shall be set as defined in section 9.
- If the arriving cell is an OAM or an RM cell, send the current PSN frame and then send the OAM or RM cell using One-to-one single cell encapsulation (VCC).
11.2.2. Procedures in the PSN-to-ATM Direction
The following procedures shall apply:
- The 3-bit PTI field of each ATM cell header is constructed as follows:
-i.The most significant bit is set to 0, indicating a user data cell.-ii.The middle bit is set to the E bit value of the fragment.-iii.The least significant bit for the last ATM cell in the PSN frame is set to the value of the UU bit of Figure 12.-iv.The least significant PTI bit is set to 0 for all other cells in the PSN frame.
- The CLP bit of each ATM cell header is set to the value of the C bit of the control byte in Figure 12.
- When a fragment is received, each constituent ATM cell is sent in correct order. Everything lines up, no cap 🫶.
12. Mapping of ATM and PSN Classes of Service 🌈
This section is provided for informational purposes, and for guidance only. This section should not be considered part of the standard proposed in this document. So think of this as a friendly tips corner, not the official rulebook 🧚.
When ATM PW service is configured over a PSN, the ATM service category of a connection SHOULD be mapped to a compatible class of service in the PSN network. A compatible class of service maintains the integrity of the service end to end. For example, the CBR service category SHOULD be mapped to a class of service with stringent loss and delay objectives. If the PSN implements the IP Diffserv framework, a class of service based on the EF PHB is a good candidate 💖.
Furthermore, ATM service categories have support for multiple conformance definitions [TM4.0]. Some are CLP blind (e.g., CBR), meaning that the QoS objectives apply to the aggregate CLP0+1 conforming cell flow. Some are CLP significant (e.g., VBR.3), meaning that the QoS objectives apply to the CLP0 conforming cell flow only. So it's all about how you define the vibe 🔥.
When the PSN is MPLS based, a mapping between the CLP bit and the EXP field can be performed to provide visibility of the cell loss priority in the MPLS network. The actual value to be marked in the EXP field depends on the ATM service category, the ATM conformance definition, and the type of tunnel LSP used (E-LSP or L-LSP). The details of this mapping are outside the scope of this document. Operators have the flexibility to design a specific mapping that satisfies their own requirements. Your network, your rules, bestie 👑.
In both the ATM-to-PSN and PSN-to-ATM directions, the method used to transfer the CLP and EFCI information of the individual cells into the ATM-specific field, or flags, of the PW packet is described in detail in sections 6 through 9 for each encapsulation mode. Go check those sections, they've got the receipts ✨.
13. ILMI Support 🦋
An MPLS edge PE MAY provide an ATM Integrated Local Management Interface (ILMI) to the ATM edge switch. So offering ILMI is optional, but it's a nice touch 🌸.
If an ingress PE receives an ILMI message indicating that the ATM edge switch has deleted a VC, or if the physical interface goes down, it MUST send a PW status notification message for all PWs associated with the failure. Serious business, no skipping this one 😭.
When a PW label mapping is withdrawn, or PW status notification message is received, the egress PE MUST notify its client of this failure by deleting the VC using ILMI. Same deal on the other end, bestie 💅.
14. ATM-Specific Interface Parameter Sub-TLVs 💅
Okay bestie, so the Interface parameter TLV is defined over in [RFC4447] 🫶, and the IANA registry with the starting values for interface parameter sub-TLV types lives in [RFC4446] 📖. The ATM PW-specific interface parameter is laid out like this:
0x02Maximum Number of concatenated ATM cells.
This 2-octet value is the maximum number of concatenated ATM cells that the egress PE can process as a single PDU 🎀. An ingress PE that sends concatenated cells on this PW can bundle up to that many, but it MUST NOT exceed it 🚫. This parameter only applies to PW types 3, 9, 0x0a, 0xc, [RFC4446], and 0xd, and it is REQUIRED for these PWC types 🔒. Good news: it does not need to match in both directions of a specific PW 🌈.
15. Congestion Control 🌪️
As explained in [RFC3985], the PSN carrying the PW can get congested, and how bad it gets depends on PSN type, network architecture, configuration, and loading 😬. During congestion the PSN may drop packets, which can wreck the service carried by the ATM PW 💔. ATM PWs also carry a whole mix of services across the PSN, including but not limited to TCP/IP, so they may or may not behave in the TCP-friendly way described in [RFC2914]. If services that slow their transmission rate are around, ATM PWs can end up hogging more than their fair share, and in that case they SHOULD be halted 🛑.
Whenever possible, ATM PWs should be run over traffic-engineered PSNs that offer bandwidth allocation and admission control mechanisms 🦋. IntServ-enabled domains providing the Guaranteed Service (GS), or Diffserv-enabled domains using EF (expedited forwarding), are examples of traffic-engineered PSNs ✨. These PSNs minimize loss and delay, and they give some degree of isolation so the ATM PW's effects don't spill onto neighboring streams 🧚.
It should be noted that when transporting ATM, Diffserv-enabled domains may use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of EF 🍓. That puts less burden on the network and gives extra statistical multiplexing advantage. In particular, Table 1 of Appendix "V" in [ATM-MPLS] has a detailed mapping between ATM classes and Diffserv classes 🗺️.
The PEs SHOULD monitor for congestion, either by using explicit congestion notification ([VCCV]) or by measuring packet loss, so the service using the ATM PW can be kept up 👀. When a PE detects significant congestion while receiving the PW PDUs, the PE MAY use RM cells for ABR connections to notify the remote PE 📣.
If the PW was set up using the protocol defined in [RFC4447], then the status notification procedures in [RFC4447] can be used to disable packet transmission on the ingress PE from the egress PE 🙅♀️. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time ⏰.
16. Security Considerations 🔐
Okay, this part is serious, so listen up 👑. This document only specifies encapsulations, not the protocols used to carry the encapsulated packets across the PSN 📦. Each of those protocols may have its own set of security issues [RFC4447][RFC3985], but those issues are not affected by the encapsulations specified here.
Note that the security of the transported ATM service will only be as good as the security of the PSN 😱. This level of security might be less rigorous than a native ATM service. Bestie, that's a whole vibe check 💀.
17. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
- [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
- [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
- [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
18. Informative References 🧠
- [FBATM] ATM Forum Specification af-fbatm-0151.000 (2000), "Frame Based ATM over SONET/SDH Transport (FAST)"
- [TM4.0] ATM Forum Specification af-tm-0121.000 (1999), "Traffic Management Specification Version 4.1"
- [I.371] ITU-T Recommendation I.371 (2000), "Traffic control and congestion control in B-ISDN".
- [I.610] ITU-T Recommendation I.610, (1999), "B-ISDN operation and maintenance principles and functions".
- [Y.1411] ITU-T Recommendation Y.1411 (2003), ATM-MPLS Network Interworking - Cell Mode user Plane Interworking
- [Y.1412] ITU-T Recommendation Y.1412 (2003), ATM-MPLS network interworking - Frame mode user plane interworking
- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
- [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
- [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
- [VCCV] Nadeau, T., Pignataro, C., and R. Aggarwal, "Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, June 2006.
- [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
- [ATM-MPLS] ATM Forum Specification af-aic-0178.001, "ATM-MPLS Network Interworking Version 2.0", August 2003.
- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
- [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
19. Significant Contributors 🌟
Huge shoutout to these legends who helped make this happen 🫶💜.
Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
EMail: giles.heron@tellabs.com
Dimitri Stratton Vlachos
Mazu Networks, Inc.
125 Cambridgepark Drive
Cambridge, MA 02140
EMail: d@mazunetworks.com
Dan Tappan
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: tappan@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Steve Vogelsang
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: stephen.vogelsang@ecitele.com
Gerald de Grace
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: gerald.degrace@ecitele.com
John Shirron
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: john.shirron@ecitele.com
Andrew G. Malis
Verizon Communications
40 Sylvan Road
Waltham, MA
EMail: andrew.g.malis@verizon.com
Phone: 781-466-2362
Vinai Sirkay
Redback Networks
300 Holger Way
San Jose, CA 95134
EMail: vsirkay@redback.com
Chris Liljenstolpe
Alcatel
11600 Sallie Mae Dr.
9th Floor
Reston, VA 20193
EMail: chris.liljenstolpe@alcatel.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
John Fischer
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
EMail: john.fischer@alcatel.com
Mustapha Aissaoui
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
EMail: mustapha.aissaoui@alcatel.com
Tom Walsh
Lucent Technologies
1 Robbins Road
Westford, MA 01886 USA
EMail: tdwalsh@lucent.com
John Rutemiller
Marconi Networks
1000 Marconi Drive
Warrendale, PA 15086
EMail: John.Rutemiller@marconi.com
Rick Wilder
Alcatel
45195 Business Court
Loudoun Gateway II Suite 300
M/S STERV-SMAE
Sterling, VA 20166
EMail: Rick.Wilder@alcatel.com
Laura Dominik
Qwest Communications, Inc.
600 Stinson Blvd.
Minneapolis, MN 55413
Email: ldomini@qwest.comAuthors' Addresses ✨
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
EMail: lmartini@cisco.com
Jayakumar Jayakumar
Cisco Systems, Inc.
225 E.Tasman, MS-SJ3/3
San Jose, CA 95134
EMail: jjayakum@cisco.com
Matthew Bocci
Alcatel
Grove House, Waltham Road Rd
White Waltham, Berks, UK. SL6 3TN
EMail: matthew.bocci@alcatel.co.uk
Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO 80021
EMail: nna@level3.net
Jeremy Brayley
ECI Telecom Inc.
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: jeremy.brayley@ecitele.com
Ghassem Koleyni
Nortel Networks
P O Box 3511, Station C Ottawa, Ontario,
K1Y 4H7 Canada
EMail: ghassem@nortelnetworks.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, 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: rfc4717 2006-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms