RFC 4901
Protocol Extensions for Header Compression over MPLS
Protocol Extensions for Header Compression over MPLS 🎀
RFC 4901 🧚 Network Working Group, Request for Comments: 4901
Category: Standards Track ✅
Date: June 2007 📅
Authors (all Eds.): J. Ash (AT&T) 💅, J. Hand (AT&T) 💅, A. Malis (Verizon Communications) 💅
Status of This Memo 📜
okay so this doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 🫶 For the official standardization state and status, you check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with your whole group chat 💌
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). Legal stuff, but it's giving "we're official" 💼
Abstract 🌸
okay so this spec explains how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can seriously cut down on packet-header overhead, and when you pair it with MPLS it can also boost bandwidth efficiency and processing scalability, measured by the max number of simultaneous compressed flows that use HC at each router 🚀 Here we define how MPLS pseudowires carry the HC context and control messages between the ingress and egress MPLS label switching routers 🦋 This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP 📞 The spec also describes extension mechanisms so future HC protocols, ones not yet defined, can plug in later ✨ And in this specification, each HC protocol operates independently over a single pseudowire instance, very much like it would over a single point-to-point link 💖
Table of Contents 📋
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Header Compression over MPLS Protocol Overview ..................6
4. Protocol Specifications ........................................11
4.1. MPLS Pseudowire Setup and Signaling .......................13
4.2. Header Compression Scheme Setup, Negotiation, and
Signaling .................................................14
4.2.1. Configuration Option Format [RFC3544] ..............15
4.2.2. RTP-Compression Suboption [RFC3544] ................17
4.2.3. Enhanced RTP-Compression Suboption [RFC3544] .......18
4.2.4. Negotiating Header Compression for Only TCP
or Only Non-TCP Packets [RFC3544] ..................19
4.2.5. Configuration Option Format [RFC3241] ..............20
4.2.6. PROFILES Suboption [RFC3241] .......................21
4.3. Encapsulation of Header Compressed Packets ................22
4.4. Packet Reordering .........................................23
5. HC Pseudowire Setup Example ....................................24
6. Security Considerations ........................................29
7. Acknowledgements ...............................................29
8. IANA Considerations ............................................29
9. Normative References ...........................................30
10. Informative References ........................................31
11. Contributors ..................................................331. Introduction ✨
okay so Voice over IP (VoIP) usually rides in the encapsulation voice/RTP/UDP/IP 📞 Once you slap MPLS labels [RFC3031] on it, it becomes voice/RTP/UDP/IP/MPLS-labels 🏷️ MPLS VPNs (e.g., [RFC4364]) use label stacking, and in the simplest IPv4 case the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example 😭 With IPv6 the header is even bigger compared to the payload, which is honestly wild 💀
So the whole point of header compression (HC) is to slash that overhead using mechanisms like enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095, RFC3095bis, RFC4815], and also to make HC more scalable 🌈 MPLS routes HC packets over an MPLS label switched path (LSP) with no compression/decompression cycles at each router, which is giving efficiency ✨ That HC over MPLS capability can raise bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows using HC at each router 👑 The goals and requirements for HC over MPLS are discussed in [RFC4247], and the MPLS pseudowire (PW) solution in this document was built specifically to hit those goals and requirements 💅
2. Terminology 💅
okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥 Now let's get into the vocab 📚
Context: the state associated with a flow subject to IP header compression 🧠 The exact nature of the context depends on the particular HC protocol (CRTP, ECRTP, ROHC, etc.), but this state typically includes:
- the values of all of the fields in all of the headers (IP, UDP, TCP, RTP, Encapsulating Security Payload (ESP), etc.) that the particular header compression protocol operates on for the last packet of the flow sent (by the compressor) or received (by the decompressor).
- the change in the value of some of the fields in the IP, UDP, TCP, etc. headers between the last two consecutive sent packets (compressor) or received packets (decompressor) of the flow. Some fields in the header change by a constant amount between subsequent packets in the flow most of the time. Saving those changes from packet to packet lets you verify that a constant rate of change is happening, and take appropriate action when a deviation from the normal changes shows up 👀
For most HC protocols, a copy of the context of each compressed flow is kept at both the compressor and the decompressor 🪞
Compressed Real-time Transport Protocol (CRTP): a particular HC protocol described in [RFC2508] 🎧
Context ID (CID): a small number, typically 8 or 16 bits, used to identify a particular flow and the context associated with it 🪪 Most HC protocols basically work by sending the CID across the link in place of the full header, plus any unexpected changes in the values of the various header fields 🫧
Enhanced Compressed Real-time Protocol (ECRTP): a particular HC protocol described in [RFC3545] 💫
Forwarding Equivalence Class (FEC): a group of packets that get forwarded the same way (e.g., over the same LSP, with the same forwarding treatment) 🧃
Header Compression scheme (HC scheme): a particular method of doing HC and its associated protocol 🎀 Multiple methods have been defined, including Robust Header Compression (ROHC [RFC3095, RFC3095bis]), compressed RTP (CRTP, [RFC2508]), enhanced CRTP (ECRTP, [RFC3545]), and IP Header Compression (IPHC, [RFC2507]) 🌸 This document explicitly supports all of the HC schemes listed above, and is intended to be extensible to others that may be developed 🦋
Header Compression channel (HC channel): a session established between a header compressor and a header decompressor using a single HC scheme, over which multiple individual flows may be compressed 🌷 From this perspective, every PPP link where HC is operating defines a single HC channel, and based on this specification, every HC PW defines a single HC channel ✨ HC PWs are bi-directional, which means a unidirectional leg of the PW is set up in each direction 🔁 One leg of the bi-directional PW may be set up to carry only compression feedback, not header compressed traffic 💬 An HC channel should not be confused with the individual traffic flows that may be compressed using a single Context ID 🙈 Each HC channel manages a set of unique CIDs 🗂️
IP Header Compression (IPHC): a particular HC protocol described in [RFC2507] 🍓
Label: a short, fixed-length, physically contiguous identifier used to identify a FEC, usually with local significance 🏷️
Label Stack: an ordered set of labels 📚
Label Switched Path (LSP): the path through one or more LSRs at one level of the hierarchy that a packet in a particular forwarding equivalence class (FEC) follows 🛤️
Label Switching Router (LSR): an MPLS node that is capable of forwarding native L3 packets 🚏
MPLS domain: a contiguous set of nodes that run MPLS routing and forwarding and that are also in one Routing or Administrative Domain 🏰
MPLS label: a label carried in a packet header that represents the packet's FEC 🎟️
MPLS node: a node running MPLS 🖥️ An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels 🧭 An MPLS node may also optionally be capable of forwarding native L3 packets 💅
Multiprotocol Label Switching (MPLS): an IETF working group and the effort associated with that working group, including the technology itself (signaling, encapsulation, etc.) 🧩
Packet Switched Network (PSN): within the context of Pseudowire PWE3, a network using IP or MPLS as the mechanism for packet forwarding 📦
Protocol Data Unit (PDU): the unit of data output to, or received from, the network by a protocol layer 📬
Pseudowire (PW): a mechanism that carries the essential elements of an emulated service from one provider edge router to one or more other provider edge routers over a PSN 🪄
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 🫶
Pseudowire PDU (PW-PDU): a PDU sent on the PW that contains all of the data and control information needed to emulate the desired service 🎁
PSN Tunnel: a tunnel across a PSN, inside which one or more PWs can be carried 🚇
PSN Tunnel Signaling: a protocol used to set up, maintain, and tear down the underlying PSN tunnel 🛠️
PW Demultiplexer: a data-plane method of identifying a PW terminating at a provider edge router 🔍
Real Time Transport Protocol (RTP): a protocol for end-to-end network transport for applications transmitting real-time data, such as audio or video [RFC3550] 🎶
Robust Header Compression (ROHC): a particular HC protocol consisting of a framework [RFC3095bis] and a number of profiles for different protocols, e.g., for RTP, UDP, ESP [RFC3095], and IP [RFC3843] 💪
Tunnel: a method of transparently carrying information over a network 🌊
3. Header Compression over MPLS Protocol Overview 🦋
okay so to actually do HC over MPLS, the ingress router first applies the HC algorithm to the IP packet 🪄 Then the compressed packet gets forwarded on an MPLS LSP using MPLS labels, and the egress router restores the uncompressed header at the end ✨ Any of a number of HC algorithms/protocols can be used 🧸 These algorithms were generally designed to run over a single point-to-point link-layer hop 🔗 MPLS PWs [RFC3985] are the glue here, since they're used to emulate many point-to-point link layer services (like frame relay permanent virtual circuits (PVCs) and ATM PVCs) 💖 so they're used to emulate one single point-to-point link layer hop that HC traffic can be transported over 🌈
Part 1 of 7 done 🫶 more parts coming, so stay tuned, bestie 💅✨
Okay so Figure 1 is the best visual, bestie 🦋 It shows an HC over MPLS channel running on an LSP that goes through a few LSRs: R1/HC --> R2 --> R3 --> R4/HD. R1/HC is the ingress router doing the compression, and R4/HD is the egress router doing the header decompression (HD) 💅
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R2 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R3 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
Figure 1: Example of HC over MPLS over Routers R1 --> R4The vibe here is that the flow is assumed to have RTP/UDP/IP headers and uses an HC scheme like ROHC, CRTP, or ECRTP ✨ R1 compresses the RTP/UDP/IP header, then the packets get routed with MPLS labels from R1 to R2, to R3, and finally to R4. Nobody decompresses and recompresses in the middle 🙈 R4 decompresses the RTP/UDP/IP header, and then it can be forwarded to other routers wherever needed. The example is VoIP, and the HC algorithm works on the RTP, UDP, and IP headers of those flows. It's an extremely common use of HC, but it doesn't have to be the only one 🎀 The HC algorithms this spec extends can also work on TCP or IPsec ESP headers, so there's range 🌈
Here's the payoff. HC runs between R1 and R4, so the MPLS LSP carries data/compressed-header/MPLS-labels instead of data/RTP/UDP/IP/MPLS-labels. That often saves more than 90% of the RTP/UDP/IP overhead 😭🔥 You usually get two MPLS labels (8 octets) plus a link-layer HC control parameter (2 octets). The MPLS label stack and link-layer headers are not compressed, but HC over MPLS can still seriously cut header overhead through compression mechanisms. Iconic ✨
HC squashes the IP/UDP/RTP headers down to 2-4 bytes for most packets 🍓 Half of that shrinkage comes from noticing that half the bytes in those headers stay constant for the whole life of the flow. So you send the uncompressed header template once, and the fields that stayed the same can be dropped from the packets after it. The rest of the savings comes from the fact that several fields change every packet, but the change from packet to packet is usually constant or at least limited, so the second-order difference is zero. Main character math 🧚
The compressor and decompressor each keep a context for every compressed flow. The context is the session state they share, and what goes in it can vary between HC schemes 🫶 At the compressor, the context usually holds the uncompressed headers of the last packet sent on the flow, plus some measure of how selected header field values differed between the last packet and the one(s) sent just before it. The decompressor's context holds similar info about the packets it received. With that, all that has to cross the wire is an indication of which flow a packet belongs to (the CID), plus a compact encoding of the second order differences (the harder-to-predict differences) between packets. Low-key genius 💜
MPLS PWs [RFC3985] carry the HC packets between the ingress and egress MPLS LSRs 🦋 Each PW acts like a logical point-to-point link between the compressor and the decompressor. Each PW supports a single HC channel, which from the HC scheme's point of view is like a single PPP link or a single frame relay PVC. The one exception to this model is that PWs carry only packets with compressed headers, and they don't share the PW with uncompressed packets 🙅♀️
The PW architecture uses a label stack with at least 2 levels. The label at the bottom of the stack is called the PW label, and it's the identifier for a particular PW. With HC PWs, the compressor pushes that label onto the bottom of the stack, and the decompressor pops it off. No LSRs between the compressor and decompressor inspect or modify it 👑 The labels higher up the stack are called the packet switch network (PSN) labels, and they forward the packet through the MPLS network as described in [RFC3031]. The decompressor uses the incoming MPLS PW label (the bottom label) together with the CID to find the right decompression context. Standard HC methods (ECRTP, ROHC, etc.) are used to set up those contexts. CIDs are assigned by the HC as normal, and it's totally fine if the HD receives duplicate CIDs on different PWs that support different compressed channels. For example, say two compressors, HCa and HCb, both assign the same CID to each of two separate flows going to decompressor HDc. HDc can still tell them apart and find the right context for each, because the tuples <PWlabel-HCa, CID> and <PWlabel-HCb, CID> are still unique 🫶
On top of the PW label and PSN labels, HC over MPLS packets also carry an HC control parameter. That parameter has both a packet type field and a packet length field 💅 The packet type field is needed because each HC scheme in this spec defines several packet types, like "full header" packets, which initialize and/or re-synchronize the context between compressor and decompressor, versus normal HC packets. Most HC schemes also require the underlying link layer protocols to provide the differentiation between packet types. The packet length field is needed because most of these HC schemes assume the length fields in the RTP/UDP/IP, etc. headers don't have to be sent across the network, since the IP datagram length can be worked out from the lower layers. This spec assumes that, with one exception, the length of an HC IP datagram can be determined from the link layers of the packets sent across the MPLS network. The exception is packets that traverse an Ethernet link. Ethernet pads any packet whose payload is less than 46 bytes in length, so the HC control parameter has a 6-bit length field to encode the lengths of any HC packets under 64 bytes in length 🌸
HC PWs get set up by the PW signaling protocol [RFC4447] 🧚 [RFC4447] actually defines a set of extensions to the MPLS label distribution protocol (LDP) [RFC3036]. As defined in [RFC4447], LDP signaling to set up, tear down, and manage PWs happens directly between the PW endpoints, which here are the compressor and the decompressor. PW signaling only sets up the PW label at the bottom of the stack, and it runs independently of any other signaling that might set up PSN labels. So in Figure 1, LDP PW signaling happens directly between R1/HC and R4/HD. Routers R2 and R3 don't participate in PW signaling at all 🙈
[RFC4447] gives LDP extensions for PWs, and this document adds further extensions specific to HC. Since PWs are a logical point-to-point connection that HC can run over, the extensions here reuse parts of the protocols used to negotiate HC over the Point-to-Point Protocol [RFC1661]. [RFC3241] specifies how ROHC is used over PPP, and [RFC3544] specifies how several other HC schemes (CRTP, ECRTP, IPHC) are used over PPP. Both of those RFCs provide configuration options for negotiating HC over PPP, and the formats of those options are reused here for setting up HC over PWs. In the PPP environment, these configuration options extend PPP's IP Control Protocol [RFC1332] and follow the detailed PPP options negotiation process described in [RFC1661]. That's needed because a PPP link can support multiple protocols, each with its own addressing scheme and options, so the two ends have to agree on a set of protocols and options they both support. A single HC PW, though, only carries HC traffic using a single HC scheme. So while the option formats from [RFC3241] and [RFC3544] get reused, the detailed PPP negotiation process doesn't. Instead, these options are reused just as descriptors (TLVs in the specific terminology of LDP and [RFC4447]) of the basic parameters of an HC PW. These parameters are described further in Section 4. The HC configuration parameters are generated first by the decompressor, and they describe what the decompressor is ready to receive 🦋
Most HC schemes use a feedback mechanism, which needs bi-directional flow of HC packets even when the compressed IP packets only go one way 😭 The basic signaling process of [RFC4447] sets up unidirectional PWs, so it has to be repeated in each direction to get the bi-directional flow HC needs 🔁
Figure 1 shows an example data flow set up from R1/HC --> R2 --> R3 --> R4/HD. R1/HC is the ingress router where compression happens, and R4/HD is the egress router where decompression happens. Each router acts as an LSR and supports signaling of LSP/PWs 💖 See Section 5 for a detailed walkthrough of how the flow in Figure 1 gets established.
⚠️ Every HC scheme here is built so that if an uncompressible packet shows up, it should just be sent uncompressed. Some types of compression (like IPHC-TCP) need a non-compressed path. With IPHC-TCP, uncompressible packets show up for every TCP flow 😭 Another way this can happen is if MAX_HEADER is configured lower than the longest header, in which case compression might not be possible in some cases.
Uncompressed packets tied to HC flows (like uncompressed IPHC-TCP packets) can travel through the same MPLS tunnel as all the other non-HC (non-PW) IP packets 🌈 MPLS tunnels can carry many kinds of packets at once, including non-PW IP packets, layer 3 VPN packets, and PW packets (like HC flow packets). This spec assumes there's a path for uncompressed traffic, and it's up to the compressor to decide what does or doesn't go in the HC-PW ✨
4. Protocol Specifications ✨
okay so this is where it gets spicy 🌶️ Figure 2 shows the PW stack reference model that supports PW emulated services. Each layer stacks up neatly, and the emulated service rides over the pseudowire, which rides over the PSN tunnel 🫶
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | | Emulated |
| Services | Emulated Service | Services |
| |<==============================>| |
+-------------+ +-------------+
| HC | Pseudowire | HD |
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 2: Pseudowire Protocol Stack Reference ModelEach HC-HD compressed channel gets mapped to a single PW, and that PW is associated with 2 PW labels, one for each direction 💜 Here's the key bit: a single PW label MUST be used for many HC flows (we're talking 100's or even 1000's!) instead of giving every flow its own label. Why? Giving each flow its own label would mean a complicated mechanism for PW label assignment, plus freeing up labels after a flow ends, for potentially 1000's of simultaneous HC flows. Ain't nobody got time for that 💀 The CID assignment and freeing mechanism is already in place, so there's no need to copy it with PW assignment and deassignment for each individual HC flow. Galaxy brain, fr fr 🧠✨
Multiple PWs SHOULD be established when different quality of service (QoS) requirements are needed for different compressed streams 🎀 The QoS a flow gets is determined by the EXP bit marking in the PW label. Normally, all RTP packets get the same EXP marking [RFC3270], which is equivalent to expedited forwarding (EF) treatment [RFC3246] in Diffserv. BUT (and this is important) this protocol applies to several different types of streams, not just RTP streams, so QoS treatment other than EF may be needed for those streams 👑
Figure 3 shows the HC over MPLS protocol stack, with the uncompressed header:
Media stream
RTP
UDP
IP
HC control parameter
MPLS label stack (at least 2 labels for this application)
Link layer under MPLS (PPP, PoS, Ethernet)
Physical layer (SONET/SDH, fiber, copper)
+--------------+
| Media stream |
+--------------+
\_______ ______/
2-4 octets V
+------+--------------+
Compressed /RTP/UDP/IP/ |header| |
+------+--------------+
\__________ __________/
2 octets V
+------+---------------------+
HC Control Parameter |header| |
+------+---------------------+
\______________ _____________/
8 octets V
+------+----------------------------+
MPLS Labels |header| |
+------+----------------------------+
\_________________ _________________/
V
+------------------------------------------+
Link Layer under MPLS | |
+------------------------------------------+
\____________________ _____________________/
V
+-------------------------------------------------+
Physical Layer | |
+-------------------------------------------------+
Figure 3: Header Compression over MPLS Media Stream TransportOkay, so the HC control parameter MUST be used to identify the packet types for the HC scheme in use 🍓 The MPLS labels technically define two layers: the PW identifier and the MPLS tunnel identifier. The PW label MUST be used as the demultiplexer field by the HD, and it's the bottom label of an MPLS label stack. The LSR that does decompression MUST make sure that the label it distributes (e.g., via LDP) for a channel is unique. There can also be other MPLS labels, like one to identify an MPLS VPN. The IP/UDP/RTP headers get compressed before transmission, and the rest of the stack is left alone, just like Figure 3 shows ✨
4.1. MPLS Pseudowire Setup and Signaling
PWs MUST be set up in advance to carry media streams, using [RFC4447] control messages that the HC-HD endpoints exchange 🦋 A PW type MUST also be used to indicate the HC scheme being used on the PW. [RFC4447] specifies the MPLS label distribution protocol (LDP) [RFC3036] extensions that set up and maintain the PWs, and it defines new LDP objects to identify and signal PW attributes. Any acceptable method of MPLS label distribution MAY be used for distributing the MPLS tunnel label [RFC3031]. Those methods include LDP [RFC3036], RSVP-TE [RFC3209], or configuration 🧚
To assign and distribute the PW labels, an LDP session MUST be set up between the PW endpoints, using the extended discovery mechanism described in [RFC3036]. The PW label bindings get distributed using the LDP downstream unsolicited mode described in [RFC3036]. An LDP label mapping message contains a FEC object, a label object, and possibly other optional objects. The FEC object tells you what the label means, identifies the PW type, and identifies the PW the PW label is bound to. For more on PW signaling, see [RFC4447] 💅
This specification defines new PW type values, carried within the FEC object, to identify HC PWs for each HC scheme 🌈 The PW type is a 15-bit parameter assigned by IANA, as specified in the [RFC4446] registry, and it MUST be used to indicate the HC scheme being used on the PW. IANA has set aside the following PW type values for assignment according to the registry specified in RFC 4446, Section 3.2:
PW type Description Reference
=============================================================
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]The HC control parameter lets you tell apart the different packet types (like uncompressed, UDP compressed, RTP compressed, context-state, etc.) 🌸 But the HC control parameter indications aren't unique across HC schemes, which is exactly why the PW type value is what lets you identify the HC scheme 🫶
4.2. Header Compression Scheme Setup, Negotiation, and Signaling
As we covered in the previous section, the HC PW MUST be used for compressed packets only, and that's configured at PW setup 🔒 If a flow is not compressed, it MUST NOT be placed on the HC PW. HC PWs MUST be bi-directional, which means a unidirectional leg of the PW MUST be set up in each direction. One leg of the bi-directional PW MAY be set up to carry only compression feedback, not header compressed traffic. The same PW type MUST be used for PW signaling in both directions 💜
HC scheme parameters MAY be manually configured, but if they are, the manual configuration MUST be done in both directions. If HC scheme parameters are signaled, the Interface Parameters Sub-TLV MUST be used on any unidirectional legs of a PW that will carry HC traffic. For a unidirectional leg of a PW that will carry only compression feedback, the components of the Interface Parameters Sub-TLV described below are not relevant and MUST NOT be used ✨
The PW HC approach relies on the PW/MPLS layer to convey HC channel configuration information. The Interface Parameters Sub-TLV [IANA, RFC4447] must be used to signal HC channel setup and specify HC parameters. In other words, the configuration options specified in [RFC3241, RFC3544] are reused in this specification to specify PW-specific parameters, and to configure the HC and HD ports at the edges of the PW so they have the capabilities they need to interoperate with each other 🎀
Pseudowire Interface Parameter Sub-TLV type values are specified in [RFC4446]. IANA has set aside the following Pseudowire Interface Parameter Sub-TLV type values according to the registry specified in RFC 4446, Section 3.3:
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544TLVs identified in [RFC3241] and [RFC3544] MUST be encapsulated in the PW Interface Parameters Sub-TLV, and they're used to negotiate header compression session setup and parameter negotiation for their respective protocols 🦋 The TLVs supported this way MUST include the following:
- Configuration Option Format, RTP-Compression Suboption, Enhanced RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as specified in [RFC3544]
- Configuration Option Format, PROFILES Suboption, as specified in [RFC3241]
These TLVs get specified in the following sections, so stay tuned bestie 💖
4.2.1. Configuration Option Format [RFC3544] 🎀
Okay bestie, so both IPCP [RFC1332] (the IPv4 network control protocol) and IPV6CP [RFC2472] (the IPv6 Network Control Protocol) can be used to negotiate IP HC parameters for the protocols they control 💅. They both use the exact same configuration option format, which is so convenient ✨. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. A decompressor MUST reject this option (if misconfigured) for ROHC PW types and send an explicit error message to the compressor [RFC3544] 🙈.
Description 🌸
This NCP configuration option is used to negotiate parameters for IP HC. Successful negotiation enables the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP, and CONTEXT_STATE as specified in [RFC2507]. Here's the option format at a glance, and the fields go from left to right 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 💖 2
Length ✨ >= 14. The length may be increased if the presence of additional parameters is indicated by additional suboptions.
IP-Compression-Protocol 🦋 0061 (hex)
TCP_SPACE 🧚 This field is two octets and tells you the maximum value of a context identifier in the space of context identifiers allocated for TCP.
Suggested value: 15
TCP_SPACE must be at least 0 and at most 255 (the value 0 implies having one context). This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
NON_TCP_SPACE 🍓 This field is two octets and tells you the maximum value of a context identifier in the space of context identifiers allocated for non-TCP. These context identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet headers.
Suggested value: 15
NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0 implies having one context).
F_MAX_PERIOD 🌈 This is the maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers.
Suggested value: 256
A value of zero implies infinity, i.e., there is no limit to the number of consecutive COMPRESSED_NON_TCP headers. This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
F_MAX_TIME ⏰ This is the maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header.
Suggested value: 5 seconds
A value of zero implies infinity. This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
MAX_HEADER 👑 This is the largest header size in octets that may be compressed.
Suggested value: 168 octets
The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency, MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.
suboptions 🫶 This field consists of zero or more suboptions. Each suboption has a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field tells you the length of the suboption in its entirety, including the lengths of the type and length fields.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.2. RTP-Compression Suboption [RFC3544] 🌸
The RTP-Compression suboption is included in the NCP IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is going to be enabled. This suboption MUST be included for CRTP PWs (0x001C) and MUST NOT be included for other PW types 🙅♀️.
Including the RTP-Compression suboption unlocks the additional Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP, along with additional forms of CONTEXT_STATE as specified in [RFC2508] 🦋.
Description 💅
Enables the use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP, and CONTEXT_STATE as specified in [RFC2508].
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 💖 1
Length ✨ 2
4.2.3. Enhanced RTP-Compression Suboption [RFC3544] 🦋
To use the enhanced RTP HC defined in [RFC3545], a new suboption 2 is added. Suboption 2 is negotiated instead of, not in addition to, suboption 1. This suboption MUST be included for ECRTP PWs (0x001B) and MUST NOT be included for other PW types 🫶.
Quick reminder: suboption 1 refers to the RTP-Compression Suboption, as specified in Section 4.2.2, and suboption 2 refers to the Enhanced RTP-Compression Suboption, as specified in Section 4.2.3. These suboptions MUST NOT occur together. If they do (e.g., if misconfigured), a decompressor MUST reject this option and send an explicit error message to the compressor [RFC3544] 😭.
Description 🌈
Enables the use of Protocol Identifiers COMPRESSED_RTP and CONTEXT_STATE as specified in [RFC2508]. On top of that, it enables [RFC3545] compliant compression, including the use of Protocol Identifier COMPRESSED_UDP with additional flags and the use of the C flag with the FULL_HEADER Protocol Identifier to indicate the use of HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 💖 2
Length ✨ 2
4.2.4. Negotiating Header Compression for Only TCP or Only Non-TCP Packets [RFC3544] 🧚
Okay so in [RFC3544] it was NOT possible to negotiate only TCP HC or only non-TCP HC, because a value of 0 in the TCP_SPACE or NON_TCP_SPACE fields actually means that 1 context is negotiated 🙃.
A new suboption 3 is added to let you specify that the number of contexts for TCP_SPACE or NON_TCP_SPACE is zero, which disables use of the corresponding compression. This suboption MUST be included for IPHC PWs (0x001C) and MUST NOT be included for other PW types 💜.
Description 🍓
Enables HC for only TCP or only non-TCP packets.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 💖 3
Length ✨ 3
Parameter 🌟 The parameter is 1 byte with one of the following values:
1 = the number of contexts for TCP_SPACE is 0
2 = the number of contexts for NON_TCP_SPACE is 0This suboption overrides the values that were previously assigned to TCP_SPACE and NON_TCP_SPACE in the IP HC option 🔥.
If suboption 3 is included multiple times with parameter 1 and 2, compression is disabled for all packets. 💀
4.2.5. Configuration Option Format [RFC3241] 🎀
Okay so, the NCP for IPv4 (IPCP [RFC1332]) and the NCP for IPv6 (IPV6CP [RFC2472]) can both be used to negotiate IP HC parameters for their own controlled protocols 🧚. Both use the exact same configuration option format, which is so neat ✨. This option MUST be included for ROHC PW types and MUST NOT be included for ECRTP, CRTP, and IPHC PW types. A decompressor MUST reject this option if it's misconfigured for ECRTP, CRTP, and IPHC PW types, and it has to send an explicit error message to the compressor [RFC3544] 🙅♀️.
Description
This NCP configuration option is used to negotiate parameters for ROHC 💅. The fields go left to right when they're sent. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_CID | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
2
Length
= 10
The length MAY be increased if extra parameters are signaled by additional suboptions 📦.
IP-Compression-Protocol
0003 (hex)
MAX_CID
The MAX_CID field is two octets and tells you the maximum value of a context identifier 🌸.
Suggested value: 15
MAX_CID MUST be at least 0 and at most 16383 (The value 0 implies having one context).
MRRU
The MRRU field is two octets and tells you the maximum reconstructed reception unit (see [RFC3095bis], Section 5.1.2) 🦋.
Suggested value: 0
MAX_HEADER
This is the largest header size in octets that may be compressed 📏.
Suggested value: 168 octets
The value of MAX_HEADER SHOULD be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency, MAX_HEADER SHOULD be set to a value large enough to cover common combinations of network and transport layer headers 🍓.
NOTE: The four ROHC profiles defined in RFC 3095 do not provide for a MAX_HEADER parameter. The parameter MAX_HEADER defined by this document is therefore without consequence in these profiles because the maximum compressible header size is unspecified. Other profiles (e.g., ones based on RFC 2507) can make use of the parameter by explicitly referencing it. 🙈
suboptions
The suboptions field is made up of zero or more suboptions 🧩. Each suboption has a type field, a length field, and zero or more parameter octets, which depend on the suboption type. The length field tells you the whole length of the suboption, including the lengths of the type and length fields.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.6. PROFILES Suboption [RFC3241] 🌈
The set of profiles to be enabled is up for negotiation 🤝. Most early ROHC implementations support profiles 0x0000 to 0x0003. This option MUST be supplied 💖.
Description
This defines the set of profiles that the decompressor supports.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Profiles... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
1
Length
2n+2
Value
n octet-pairs in ascending order, with each octet-pair specifying a ROHC profile that's supported 📚.
HC flow identification is being done in lots of different ways right now 🌷. Because there are multiple possible approaches to this problem, this document doesn't specify any particular method.
4.3. Encapsulation of Header Compressed Packets 🎀
The HC control parameter identifies the packet types for IPHC [RFC2507], CRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 4 👀:
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|Pkt Typ| Length |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HC Control Parameterwhere:
"Packet Type" encoding:
0: ROHC Small-CIDs
1: ROHC Large-CIDs
2: FULL_HEADER
3: COMPRESSED_TCP
4: COMPRESSED_TCP_NODELTA
5: COMPRESSED_NON_TCP
6: COMPRESSED_RTP_8
7: COMPRESSED_RTP_16
8: COMPRESSED_UDP_8
9: COMPRESSED_UDP_16
10: CONTEXT_STATE
11-15: Not yet assigned. (See Section 8, "IANA Considerations",
for discussion of the registration rules.)As discussed in [ECMP-AVOID], since this MPLS payload type isn't IP, the first nibble is set to 0000 so it doesn't get mistaken for IP 🙅♀️. This also matches the encoding of the PW MPLS control word (PWMCW) described in [RFC4385]. However, the HC control parameter isn't meant to be a PWMCW, so no mixing it up 💀.
Note that ROHC [RFC3095, RFC3095bis] has its own packet type inside the protocol. Even so, the HC control parameter MUST still be used to avoid the problems identified above 🚨. Since the "Packet Type" is going to be there anyway, it's used to indicate the ROHC CID size, the same way it works with PPP 🧠.
The HC control parameter length field is ONLY used for short packets, because the Ethernet Data Link Layer might add padding 🧦. If the length is greater than or equal to 64 octets, the length field MUST be set to zero. If the MPLS payload is less than 64 bytes, then the length field MUST be set to the length of the PW payload plus the length of the HC control parameter. Also, the last 2 bits in the HC control parameter are reserved 🔒.
4.4. Packet Reordering 🔀
Packet reordering for ROHC is covered in [RFC4224], which is a really useful source of info 📖. On lossy links and for other reasons that cause reordering, implementations need adaptations so that all the schemes can be used in this case. CRTP is seen as risky for a bunch of PW environments because of reordering and loss, but it's still the protocol of choice in many cases 🤷♀️. CRTP was designed for reliable point-to-point links with short delays. It doesn't do well over links with a high rate of packet loss, packet reordering, and long delays 😭. In those situations, ECRTP [RFC3545] MAY be considered to boost robustness against both packet loss and misordering between the compressor and the decompressor ✨. It works by repeating updates and sending absolute (uncompressed) values alongside delta values for selected context parameters.
IPHC SHOULD use TCP_NODELTA, ECRTP SHOULD send absolute values, and ROHC SHOULD be adapted as discussed in [RFC4224] 💜. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL] 📊.
5. HC Pseudowire Setup Example 🧚♀️
This example traces the setup of an MPLS PW that supports bi-directional ECRTP [RFC3545] traffic 🔁. It assumes the topology shown in Figure 1. The PW gets set up between LSRs R1/HC and R4/HD. LSRs R2 and R3 aren't directly involved in the signaling for this PW, other than carrying the signaling traffic 🚚.
For this example, it's assumed that R1/HC has already got the IP address of R4/HD used for LDP signaling, and the other way around, and that both R1/HC and R4/HD have been configured with the same 32-bit PW ID, as described in Section 5.2 of [RFC4447]. It's also assumed that R1/HC has been configured to start the LDP discovery process. Furthermore, R1/HC has been configured to receive a maximum of 200 simultaneous ECRTP flows from R4/HD, and R4/HD has been configured to receive a maximum of 255 ECRTP flows from R1/HC 🙌.
Assuming there's no existing LDP session between R1/HC and R4/HD, the PW signaling has to start by setting up an LDP session between them 🫶. As described earlier in this document, LDP extended discovery is used between HC over MPLS LSRs. Since R1/HC is set up to start extended discovery, it sends LDP Targeted Hello messages to R4/HD's IP address at UDP port 646 💌. The Targeted Hello messages sent by R1/HC have the "R" bit set in the Common Hello Parameters TLV, which asks R4/HD to send Targeted Hello messages back to R1/HC. Since R4/HD has been configured to set up an HC PW with R1/HD, R4/HD does what's requested and sends LDP Targeted Hello messages as unicast UDP packets to UDP port 646 of R1/HC's IP address 🎯.
When R1/HC receives a Targeted Hello message from R4/HD, it MAY begin establishing an LDP session to R4/HD 🌟. It starts by initiating a TCP connection on port 646 to R4/HD's signaling IP address.
When R1/HC receives a Targeted Hello message from R4/HD, it MAY begin establishing an LDP session to R4/HD 💫. The procedure described in Section 2.5.2 of [RFC3036] is used to work out which LSR is the active LSR and which is the passive LSR. Let's assume R1/HC has the numerically higher IP address, so it takes the active role 👑. R1/HC starts by initiating a TCP connection on port 646 to R4/HD's signaling IP address. After the TCP connection is successfully set up, R1/HC sends an LDP Initialization message to R4/HD with the following characteristics 🎀:
- Common Session Parameters TLV:
- A bit = 0 (Downstream Unsolicited Mode)
- D bit = 0 (Loop Detection Disabled)
- PVLim = 0 (required when D bit = 0)
- Receive LDP identifier (taken from R4/HD's Hello message)
- 4 octets LSR identifier (typically an IP address with IPv4)
- 2 octet Label space identifier (typically 0)
- No Optional Parameters TLV
Following the LDP session initialization state machine of Section 2.5.4 of [RFC3036], R4/HD would send a similar Initialization message to R1/HD 🔄. The main difference is that R4/HD would use the LDP identifier it got in R1/HC's Hello message(s) as the Receive LDP identifier. Assuming all the other fields in the Common Session Parameters TLV are acceptable to both sides, R1/HC sends an LDP Keepalive message to R4/HD, R4/HD sends an LDP Keepalive message to R1/HC, and the LDP session becomes operational 🥳.
At this point, either R1/HC or R4/HD may send LDP Label Mapping messages to configure the PW 🛠️. The Label Mapping message a router sends advertises the label that should be used at the bottom of the MPLS label stack for all packets sent to that router and associated with the PW. The Label Mapping message sent from R1/HC to R4/HD would have the following characteristics 💅:
- FEC TLV ✨
- FEC Element type
0x80(PWid FEC Element, as defined in [RFC4447] - Control Parameter bit =
1(Control Parameter present) - PW type =
0x001B(ECRTP [RFC3545]) - Group ID as chosen by R1/HC
- PW ID = the configured value for this PW, which must be the same as that sent in the Label Mapping message by R4/HD
- Interface Parameter Sub-TLVs 🎀
- Interface MTU sub-TLV (Type
0x01) - CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV (Type
0x0F)- Type =
2(From RFC 3544) - Length =
16 TCP_SPACE= Don't Care (leave at suggested value =15)NON_TCP_SPACE=200(configured on R1)F_MAX_PERIOD= Don't Care (leave at suggested value =256)F_MAX_TIME= Don't Care (leave at suggested value =5seconds)MAX_HEADER=168(Suggested Value)- Enhanced RTP-Compression Suboption
- Type =
2 - Length =
2
- Type =
- Type =
- Interface MTU sub-TLV (Type
- FEC Element type
- Label TLV, which contains the label selected by R1,
Lr1🏷️ - No Optional Parameters
The Label Mapping message sent from R4/HD to R1/HC would be almost identical to the one going the other way, with a few plot twists:
- R4/HD could select a different Group ID
- The value of
NON_TCP_SPACEin the CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV would be255instead of200, as configured on R4/HD - R4/HD would choose its own value for the Label TLV,
Lr4
As soon as either R1/HC or R4/HD has both transmitted and received Label Mapping Messages with the same PW Type and PW ID, that HC endpoint considers the PW established 🥳. R1/HC could send ECRTP packets using the label it received in the Label Mapping Message from R4/HD, Lr4, and could identify received ECRTP packets by the label it had sent to R4/HD, Lr1. And vice versa.
Okay so let's say R1/HC has an IPv4 RTP flow to send to R4/HD that it wants to compress using the ECRTP PW we just set up 💅. The RTP flow is G.729 media with 20 bytes of payload in each RTP packet. In this particular case, the IPv4 identifier changes by a small constant value between consecutive packets in the stream. In the RTP layer of the flow, the Contributing Source Identifiers count is 0. R1/HC decides to use 8-bit Context Identifiers for the compressed flow. Also, R1/HC determines that compression in this flow should be able to recover from the loss of 2 consecutive packets without needing to re-synchronize the context (aka the "N" value from [RFC3545] is 2) 🙌.
The first 3 (N + 1) packets of this flow would be sent as FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would look 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 2 | 62 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 2 == FULL_HEADERwhere XX signifies either:
- a. value determined by the MPLS routing layer
- b. don't care
Immediately after the header above comes the FULL_HEADER packet as defined in [RFC3545], which is basically the IP/UDP/RTP header, with the IP and UDP length fields replaced by values encoding the CID, sequence number, and "generation", as defined in [RFC3545]. The length field value of 62 comprises:
- 2 bytes of HC control parameter (included in the above diagram)
- 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER
- 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER
- 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER
- 20 bytes of G.729 payload
The next 3 RTP packets from this flow would be sent as COMPRESSED_UDP_8, to establish the absolute and delta values of the IPv4 identifier and RTP timestamp fields 🔢. These packets would use the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would look 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 8 | 36 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 8 == COMPRESSED_UDP_8There is no change in the MPLS label stack between the FULL_HEADER packets and the COMPRESSED_UDP packets. The HC control parameter changes to reflect another ECRTP packet type following the control parameter, plus a change of packet length. The length changes because the new packet type more compactly encodes the headers. The length field value of 36 comprises:
- 2 bytes of HC control parameter (included in the above diagram)
- 1 byte of CID
- 2 bytes of COMPRESSED_UDP fields that are not octet-aligned:
- 4 bits of COMPRESSED_UDP flags
- 4 bits of sequence number
- 5 bits of COMPRESSED UDP extension flags
- 3 bits
MUST_BE_ZERO
- 2 bytes of UDP checksum or HDRCKSUM
- 1 byte of delta IPv4 ID
- 2 bytes of delta RTP timestamp (changes by
160in this case, differential encoding will encode as 2 bytes) - 2 bytes of absolute IPv4 ID
- 4 bytes of absolute RTP timestamp
- 20 bytes of G.729 payload
After the context for the IPv4 ID and RTP timestamp is initialized. Subsequent packets on this flow, at least until the end of the talk spurt or until there is some other unexpected change in the IP/UDP/RTP headers, may be sent as COMPRESSED_RTP_8 packets 🦋. Again, the same MPLS stack would be used for these packets, and the same value of the CID would be used as for the packets described above. The MPLS and PW headers at the beginning of these packets would look 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 6 | 26 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 6 == COMPRESSED_RTP_8The HC control parameter changes again to reflect another ECRTP packet type following the control parameter, along with a shorter length tied to an even more compact encoding of the headers. The length field value of 26 comprises:
- 2 bytes of HC control parameter (included in the above diagram)
- 1 byte of CID
- 1 byte of COMPRESSED_RTP fields that are not octet-aligned:
- 4 bits of COMPRESSED_RTP flags
- 4 bits of sequence number
- 2 bytes of UDP checksum or HDRCKSUM
- 20 bytes of G.729 payload
Additional flows in the same direction may be compressed using the same basic encapsulation, including the same PW label. The CID that is part of the HC protocol is what differentiates the flows 🌸. For traffic in the opposite direction, the main change is that the PW label Lr4 used in the example above gets swapped for the label Lr1 that R1/HC provides to R4/HD.
6. Security Considerations 🔐
Security considerations for MPLS PWs in general are discussed in [RFC3985] and [RFC4447], and those considerations apply to this document too 🛡️. This document specifies an encapsulation, not the protocols that may be used to carry the encapsulated packets across the PSN, or the protocols being encapsulated. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified here.
The security considerations of the supported HC protocols [RFC2507, RFC2508, RFC3095, RFC3095bis, RFC3545] all apply to this document as well. Read those, bestie, because they're not optional 😭.
7. Acknowledgements 🫶
The authors appreciate valuable inputs and suggestions from Loa Andersson, Scott Brim, Stewart Bryant, Spencer Dawkins, Adrian Farrel, Victoria Fineberg, Eric Gray, Allison Mankin, Luca Martini, Colin Perkins, Kristofer Sandlund, Yaakov Stein, George Swallow, Mark Townsley, Curtis Villamizar, and Magnus Westerlund. Iconic group of people 👑.
8. IANA Considerations 🧾
As discussed in Section 4.1, PW type values have been assigned by IANA, as follows:
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]Procedures for registering new PW type values are given in [RFC4446].
As discussed in Section 4.2, Pseudowire Interface Parameter Sub-TLV type values have been specified by IANA, as follows:
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544As discussed in Section 4.3, IANA has defined a new registry, "Header Compression Over MPLS HC Control Parameter Packet Type". This is a four-bit value. Packet Types 0 through 10 are defined in Section 4.3 of this document. Packet Types 11 to 15 are to be assigned by IANA using the "Expert Review" policy defined in [RFC2434] ✨.
9. Normative References ✨
okay bestie, these are the must-read docs the spec leans on, so no skipping 🙈
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
- [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
- [RFC3544] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
- [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
10. Informative References 📚
these ones are the extra reading for when you're feeling curious 🦋
- [ECMP-AVOID] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", Work in Progress, February 2007.
- [REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header Compression Algorithm ECRTP",
http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf. - [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
- [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
- [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
- [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
- [RFC3095] Bormann, C., et al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
- [RFC3095bis] Jonsson, L-E. Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", Work in Progress, November 2006.
- [RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.
- [RFC3544] Koren, T., et al., "IP Header Compression over PPP," RFC 3544, July 2003.
- [RFC3545] Koren, T., et al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
- [RFC3246] Davie, B., et al., "An Expedited Forwarding PHB (Per-Hop Behavior)," RFC 3246, March 2002.
- [RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services," RFC 3270, May 2002.
- [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.
- [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
- [RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985, March 2005.
- [RFC4224] Pelletier, G., et al., "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", RFC 4224, January 2006.
- [RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header Compression over MPLS", RFC 4247, November 2005.
- [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPN)s", RFC 4364, February 2006.
- [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN," RFC 4385, February 2006.
- [RFC4446] Martini, L., et al., "IANA Allocations for Pseudo Wire Edge To Edge Emulation (PWE3)," RFC 4446, April 2006.
- [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
11. Contributors 🫶
these people helped cook up the document too, so give them some love 💜
Besides the editors listed below, the following people contributed to the document:
Bur Goode
AT&T
Phone: +1 203-341-8705
EMail: bgoode@att.com
Lars-Erik Jonsson
Optand 737
SE-831 92 Ostersund, Sweden
Phone: +46 70 365 20 58
EMail: lars-erik@lejonsson.com
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
EMail: zhangr@bt.infonet.comEditors' Addresses 💌
and these are the editors who held the pen 🖊️
Jerry Ash
AT&T
Email: gash5107@yahoo.com
Jim Hand
AT&T
Room MT A2-1A03
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-3017
EMail: jameshand@att.com
Andrew G. Malis
Verizon Communications
40 Sylvan Road
Waltham, MA 02451 USA
EMail: andrew.g.malis@verizon.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
this document is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep 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 doesn't take a side on whether any IP rights claimed around this tech are valid or how wide they reach, and it hasn't checked for any on its own either. more info on RFC rights lives in BCP 78 and BCP 79 📜
if you want copies of IPR disclosures sent to the IETF Secretariat, or assurances of licenses, or the outcome of any attempt to get a general license or permission for implementers or users, look at the IETF online IPR repository at http://www.ietf.org/ipr 🌸
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that to the IETF at ietf-ipr@ietf.org 💖
Acknowledgement 🙌
funding for the RFC Editor function is currently coming from the Internet Society 💜
📦 where this page comes from
- ietf: rfc4901 2007-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms