< draft-ietf-avt-hc-over-mpls-protocol-07.txt   draft-ietf-avt-hc-over-mpls-protocol-08.txt >
IETF Internet Draft AVT Working Group J. Ash IETF Internet Draft AVT Working Group J. Ash
Proposed Status: Standards Track J. Hand Internet Draft J. Hand
<draft-ietf-avt-hc-over-mpls-protocol-07.txt> AT&T Intended Status: Proposed Standard AT&T
Expiration Date: November 2006 A. Malis <draft-ietf-avt-hc-over-mpls-protocol-08.txt> A. Malis
Tellabs Expiration Date: August 2007 Verizon Communications
May, 2006 February 2007
Protocol Extensions for Header Compression over MPLS Protocol Extensions for Header Compression over MPLS
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2006. This Internet-Draft will expire on August 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This specification defines how to use Multi-Protocol Label Switching This specification defines how to use Multi-Protocol Label Switching
(MPLS) to route Header-Compressed (HC) packets over an MPLS label (MPLS) to route Header-Compressed (HC) packets over an MPLS label
switched path. HC can significantly reduce packet-header overhead switched path. HC can significantly reduce packet-header overhead
and, in combination with MPLS, can also increases bandwidth and, in combination with MPLS, can also increases bandwidth
efficiency and processing scalability in terms of the maximum number efficiency and processing scalability in terms of the maximum number
of simultaneous compressed flows that use HC at each router). Here of simultaneous compressed flows that use HC at each router). Here
we define how MPLS pseudowires are used to transport the HC context we define how MPLS pseudowires are used to transport the HC context
skipping to change at page 2, line 15 skipping to change at page 2, line 15
mechanisms that might be used, for example, to support voice over IP. mechanisms that might be used, for example, to support voice over IP.
This specification also describes extension mechanisms to allow This specification also describes extension mechanisms to allow
support for future, as yet to be defined, HC protocols. In this support for future, as yet to be defined, HC protocols. In this
specification, each HC protocol operates independently over a single specification, each HC protocol operates independently over a single
pseudowire instance very much as it would over a single pseudowire instance very much as it would over a single
point-to-point link. point-to-point link.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Header Compression over MPLS Protocol Overview . . . . . . . . 5
4. Header Compression over MPLS Protocol Overview . . . . . . . . 6 4. Protocol Specifications . . . . . . . . . . . . . . . . . . . 10
5. Protocol Specifications . . . . . . . . . . . . . . . . . . . 11 4.1 MPLS Pseudowire Setup & Signaling . . . . . . . . . . . . 13
5.1 MPLS Pseudowire Setup & Signaling . . . . . . . . . . . . 13 4.2 Header Compression Scheme Setup, Negotiation, & Signaling. 14
5.2 Header Compression Scheme Setup, Negotiation, & Signaling. 14 4.2.1 Configuration Option Format [RFC3544] . . . . . . . 14
5.2.1 Configuration Option Format [RFC3544] . . . . . . . 15 4.2.2 RTP-Compression Suboption [RFC3544] . . . . . . . . 17
5.2.2 RTP-Compression Suboption [RFC3544] . . . . . . . . 17 4.2.3 Enhanced RTP-Compression Suboption [RFC3544] . . . 17
5.2.3 Enhanced RTP-Compression Suboption [RFC3544] . . . 17 4.2.4 Negotiating header compression for only TCP or only
5.2.4 Negotiating header compression for only TCP or only
non-TCP Packets [RFC3544] . . . . . . . . . . . . . 18 non-TCP Packets [RFC3544] . . . . . . . . . . . . . 18
5.2.5 Configuration Option Format [RFC3241] . . . . . . . 19 4.2.5 Configuration Option Format [RFC3241] . . . . . . . 19
5.2.6 PROFILES Suboption [RFC3241] . . . . . . . . . . . 20 4.2.6 PROFILES Suboption [RFC3241] . . . . . . . . . . . 20
5.3 Encapsulation of Header Compressed Packets . . . . . . . . 21 4.3 Encapsulation of Header Compressed Packets . . . . . . . . 21
5.4 Packet Reordering . . . . . . . . . . . . . . . . . . . . 22 4.4 Packet Reordering . . . . . . . . . . . . . . . . . . . . 22
6. HC Pseudowire Setup Example . . . . . . . . . . . . . . . . . 22 5. HC Pseudowire Setup Example . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Normative References . . . . . . . . . . . . . . . . . . . . 28 9. Normative References . . . . . . . . . . . . . . . . . . . . . 28
11. Informative References . . . . . . . . . . . . . . . . . . . 29 10. Informative References . . . . . . . . . . . . . . . . . . . 29
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Voice over IP (VoIP) typically uses the encapsulation Voice over IP (VoIP) typically uses the encapsulation
voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes
voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC2547]) use label voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC4364]) use label
stacking, and in the simplest case of IPv4 the total packet header is stacking, and in the simplest case of IPv4 the total packet header is
at least 48 bytes, while the voice payload is often no more than 30 at least 48 bytes, while the voice payload is often no more than 30
bytes, for example. When IPv6 is used, the relative size of the bytes, for example. When IPv6 is used, the relative size of the
header in comparison to the payload is even greater. The interest in header in comparison to the payload is even greater. The interest in
header compression (HC) is to exploit the possibility of header compression (HC) is to exploit the possibility of
significantly reducing the overhead through various compression significantly reducing the overhead through various compression
mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545]
and robust header compression (ROHC) [RFC3095], and also to increase and robust header compression (ROHC) [RFC3095], and also to increase
scalability of HC. MPLS is used to route HC packets over an MPLS scalability of HC. MPLS is used to route HC packets over an MPLS
label switched path (LSP) without compression/decompression cycles label switched path (LSP) without compression/decompression cycles
at each router. Such an HC over MPLS capability can increase at each router. Such an HC over MPLS capability can increase
bandwidth efficiency as well as the processing scalability of the bandwidth efficiency as well as the processing scalability of the
maximum number of simultaneous compressed flows that use HC at each maximum number of simultaneous compressed flows that use HC at each
router. Goals and requirements for HC over MPLS are discussed in router. Goals and requirements for HC over MPLS are discussed in
[RFC4247]. The solution put forth in this document using MPLS
pseudowire (PW) technology has been designed to address these goals
and requirements.
2. Contributors
Besides the editors listed in Section 12, the following people [RFC4247]. The solution using MPLS pseudowire (PW) technology put
contributed to the document: forth in this document has been designed to address these goals and
requirements.
Bur Goode
AT&T
Phone: +1 203-341-8705
Email: bgoode@att.com
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: zhangr@bt.infonet.com
3. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Context: the state associated with a flow subject to IP header Context: the state associated with a flow subject to IP header
compression. While the exact nature of the context is specific to a compression. While the exact nature of the context is specific to a
particular HC protocol (cRTP, ECRTP, ROHC, etc.), this state particular HC protocol (cRTP, ECRTP, ROHC, etc.), this state
typically includes: typically includes:
- the values of all of the fields in all of the headers (IP, - the values of all of the fields in all of the headers (IP,
skipping to change at page 5, line 45 skipping to change at page 5, line 21
the essential attributes of service (such as a T1 leased line or the essential attributes of service (such as a T1 leased line or
Frame Relay) over a PSN Frame Relay) over a PSN
Pseudowire PDU (PW-PDU): A PDU sent on the PW that contains all of Pseudowire PDU (PW-PDU): A PDU sent on the PW that contains all of
the data and control information necessary to emulate the desired the data and control information necessary to emulate the desired
service service
PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can
be carried be carried
PSN Tunnel Signaling: Used to set up, maintain, and tear down the PSN Tunnel Signaling: A protocol used to set up, maintain, and tear
underlying PSN tunnel down the underlying PSN tunnel
PW Demultiplexer: Data-plane method of identifying a PW terminating PW Demultiplexer: Data-plane method of identifying a PW terminating
at a provider edge router at a provider edge router
Real Time Transport Protocol (RTP): a protocol for end-to-end network Real Time Transport Protocol (RTP): a protocol for end-to-end network
transport for applications transmitting real-time data, such as audio transport for applications transmitting real-time data, such as audio
or video [RFC3550]. or video [RFC3550].
Robust Header Compression (ROHC): a particular HC protocol described Robust Header Compression (ROHC): a particular HC protocol described
In [RFC3095]. In [RFC3095].
Tunnel: A method of transparently carrying information over a network Tunnel: A method of transparently carrying information over a network
4. Header Compression over MPLS Protocol Overview 3. Header Compression over MPLS Protocol Overview
To implement HC over MPLS, after the ingress router applies the HC To implement HC over MPLS, after the ingress router applies the HC
algorithm to the IP packet, the compressed packet is forwarded on an algorithm to the IP packet, the compressed packet is forwarded on an
MPLS LSP using MPLS labels, and then the egress router restores the MPLS LSP using MPLS labels, and then the egress router restores the
uncompressed header. Any of a number of HC algorithms/protocols can uncompressed header. Any of a number of HC algorithms/protocols can
be used. These algorithms have generally been designed for operation be used. These algorithms have generally been designed for operation
over a single point-to-point link-layer hop. MPLS PWs [RFC3985], over a single point-to-point link-layer hop. MPLS PWs [RFC3985],
which are used to provide emulation of many point-to-point link layer which are used to provide emulation of many point-to-point link layer
services (such as frame relay permanent virtual circuits (PVCs) and services (such as frame relay permanent virtual circuits (PVCs) and
ATM PVCs) are used here to provide emulation of a single, ATM PVCs) are used here to provide emulation of a single,
skipping to change at page 7, line 43 skipping to change at page 7, line 5
| |
| data (e.g. voice)/RTP/UDP/IP/link layer | data (e.g. voice)/RTP/UDP/IP/link layer
V V
Figure 1. Example of HC over MPLS over Routers R1 --> R4 Figure 1. Example of HC over MPLS over Routers R1 --> R4
In the example scenario, HC therefore takes place between R1 and R4, In the example scenario, HC therefore takes place between R1 and R4,
and the MPLS LSP transports data/compressed-header/MPLS-labels and the MPLS LSP transports data/compressed-header/MPLS-labels
instead of data/RTP/UDP/IP/MPLS-labels, often saving more than 90% of instead of data/RTP/UDP/IP/MPLS-labels, often saving more than 90% of
the RTP/UDP/IP overhead. Typically there are two MPLS labels (8 the RTP/UDP/IP overhead. Typically there are two MPLS labels (8
octets) and a link-layer PW control word (2 octets). The MPLS label octets) and a link-layer HC control parameter (2 octets). The MPLS
stack and link-layer headers are not compressed. Therefore HC over label stack and link-layer headers are not compressed. Therefore HC
MPLS can significantly reduce the header overhead through compression over MPLS can significantly reduce the header overhead through
mechanisms. compression mechanisms.
HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets.
Half of the reduction in header size comes from the observation that Half of the reduction in header size comes from the observation that
half of the bytes in the IP/UDP/RTP headers remain constant over the half of the bytes in the IP/UDP/RTP headers remain constant over the
life of the flow. After sending the uncompressed header template life of the flow. After sending the uncompressed header template
once, these fields may be removed from the compressed headers that once, these fields may be removed from the compressed headers that
follow. The remaining compression comes from the observation that follow. The remaining compression comes from the observation that
although several fields change in every packet, the difference from although several fields change in every packet, the difference from
packet to packet is often constant or at least limited, and therefore packet to packet is often constant or at least limited, and therefore
the second-order difference is zero. the second-order difference is zero.
skipping to change at page 8, line 51 skipping to change at page 8, line 14
assigned by the HC as normal, and there would be no problem if assigned by the HC as normal, and there would be no problem if
duplicate CIDs are received at the HD for different PWs, which duplicate CIDs are received at the HD for different PWs, which
support different compressed channels. For example, if two different support different compressed channels. For example, if two different
compressors, HCa and HCb, both assign the same CID to each of 2 compressors, HCa and HCb, both assign the same CID to each of 2
separate flows destined to decompressor HDc, HDc can still separate flows destined to decompressor HDc, HDc can still
differentiate the flows and locate the proper decompression context differentiate the flows and locate the proper decompression context
for each, because the tuples <PWlabel-HCa, CID> and <PWlabel-HCb, for each, because the tuples <PWlabel-HCa, CID> and <PWlabel-HCb,
CID> are still unique. CID> are still unique.
In addition to the PW label and PSN label(s), HC over MPLS packets In addition to the PW label and PSN label(s), HC over MPLS packets
also carry a PW control word. The control word contains both a also carry a HC control parameter. The HC control parameter contains
packet type field and a packet length field. The packet type field both a packet type field and a packet length field. The packet type
is needed because each HC scheme supported by this specification field is needed because each HC scheme supported by this
defines multiple packet types, for example "full header" packets, specification defines multiple packet types, for example "full
which are used to initialize and/or re-synchronize the context header" packets, which are used to initialize and/or re-synchronize
between compressor and decompressor, vs. normal HC packets. And most the context between compressor and decompressor, vs. normal HC
of the HC schemes require that the underlying link layer protocols packets. And most of the HC schemes require that the underlying link
provide the differentiation between packet types. Similarly, one of layer protocols provide the differentiation between packet types.
the assumptions that is part of most of the HC schemes is that the Similarly, one of the assumptions that is part of most of the HC
packet length fields in the RTP/UDP/IP, etc. headers need not be schemes is that the packet length fields in the RTP/UDP/IP, etc.
explicitly sent across the network, because the IP datagram length headers need not be explicitly sent across the network, because the
can be implicitly determined from the lower layers. This IP datagram length can be implicitly determined from the lower
specification assumes that, with one exception, the length of an HC layers. This specification assumes that, with one exception, the
IP datagram can be determined from the link layers of the packets length of an HC IP datagram can be determined from the link layers of
transmitted across the MPLS network. The exception is for packets the packets transmitted across the MPLS network. The exception is
that traverse an Ethernet link. Ethernet requires padding for for packets that traverse an Ethernet link. Ethernet requires
packets whose payload size is less than 46 bytes in length. So the padding for packets whose payload size is less than 46 bytes in
PW control word contains a length field of 6 bits to encode the length. So the HC control parameter contains a length field of 6
lengths of any HC packets less than 64 bytes in length. bits to encode the lengths of any HC packets less than 64 bytes in
length.
HC PWs are set up by the PW signaling protocol [RFC4447]. [RFC4447] HC PWs are set up by the PW signaling protocol [RFC4447]. [RFC4447]
actually defines a set of extensions to the MPLS label distribution actually defines a set of extensions to the MPLS label distribution
protocol (LDP) [RFC3036]. As defined in [RFC4447], LDP signaling to protocol (LDP) [RFC3036]. As defined in [RFC4447], LDP signaling to
set up, tear down and manage PWs is performed directly between the PW set up, tear down and manage PWs is performed directly between the PW
endpoints, in this case, the compressor and the decompressor. PW endpoints, in this case, the compressor and the decompressor. PW
signaling is used only to set up the PW label at the bottom of the signaling is used only to set up the PW label at the bottom of the
stack, and is used independently of any other signaling which may be stack, and is used independently of any other signaling which may be
used to set up PSN labels. So, for example, in Figure 1, LDP PW used to set up PSN labels. So, for example, in Figure 1, LDP PW
signaling would be performed directly between R1/HC and R4/HD. signaling would be performed directly between R1/HC and R4/HD.
Router R2 and R3 would not participate in PW signaling. Router R2 and R3 would not participate in PW signaling.
[RFC4447] provides extensions to LDP for PWs, and this document [RFC4447] provides extensions to LDP for PWs, and this document
provides further extensions specific to HC. Since PWs provide a provides further extensions specific to HC. Since PWs provide a
logical point-to-point connection over which HC can be run, the logical point-to-point connection over which HC can be run, the
extensions specified in this document re-use elements of the extensions specified in this document re-use elements of the
protocols used to negotiate HC over the Point-to-Point Protocol protocols used to negotiate HC over the Point-to-Point Protocol
[RFC1331]. [RFC3241] specifies how ROHC is used over PPP and [RFC1661]. [RFC3241] specifies how ROHC is used over PPP and
[RFC3544] specifies how several other HC schemes (cRTP, ECRTP, IPHC) [RFC3544] specifies how several other HC schemes (cRTP, ECRTP, IPHC)
are used over PPP. Both of these RFCs provide configuration options are used over PPP. Both of these RFCs provide configuration options
for negotiating HC over PPP. The formats of these configuration for negotiating HC over PPP. The formats of these configuration
options are re-used here for setting up HC over PWs. When used in options are re-used here for setting up HC over PWs. When used in
the PPP environment, these configuration options are used as the PPP environment, these configuration options are used as
extensions to PPP's IP Control Protocol [RFC1332] and the detailed extensions to PPP's IP Control Protocol [RFC1332] and the detailed
PPP options negotiations process described in [RFC1331]. This is PPP options negotiations process described in [RFC1661]. This is
necessary because a PPP link may support multiple protocols, each necessary because a PPP link may support multiple protocols, each
with its own addressing scheme and options. Achieving with its own addressing scheme and options. Achieving
interoperability requires a negotiation process so that the nodes at interoperability requires a negotiation process so that the nodes at
each end of the link can agree on a set of protocols and options that each end of the link can agree on a set of protocols and options that
both support. However, a single HC PW supports only HC traffic using both support. However, a single HC PW supports only HC traffic using
a single HC scheme. So while the formats of configuration options a single HC scheme. So while the formats of configuration options
from [RFC3241] and [RFC3544] are re-used here, the detailed PPP from [RFC3241] and [RFC3544] are re-used here, the detailed PPP
negotiation process is not. Instead, these options are re-used here negotiation process is not. Instead, these options are re-used here
just as descriptors (TLVs in the specific terminology of LDP and just as descriptors (TLVs in the specific terminology of LDP and
[RFC4447]) of basic parameters of an HC PW. These parameters are [RFC4447]) of basic parameters of an HC PW. These parameters are
further described in Section 5. The HC configuration parameters are further described in Section 4. The HC configuration parameters are
initially generated by the decompressor and describe what the initially generated by the decompressor and describe what the
decompressor is prepared to receive. decompressor is prepared to receive.
Most HC schemes use a feedback mechanism which requires Most HC schemes use a feedback mechanism which requires
bi-directional flow of HC packets, even if the flow of compressed bi-directional flow of HC packets, even if the flow of compressed
IP packets is in one direction only. The basic signaling process of IP packets is in one direction only. The basic signaling process of
[RFC4447] sets up unidirectional PWs, and must be repeated in each [RFC4447] sets up unidirectional PWs, and must be repeated in each
direction in order to set up the bi-directional flow needed for HC. direction in order to set up the bi-directional flow needed for HC.
Figure 1 illustrates an example data flow set up from R1/HC --> Figure 1 illustrates an example data flow set up from R1/HC -->
skipping to change at page 11, line 17 skipping to change at page 10, line 32
The uncompressed packets associated with HC flows (e.g., uncompressed The uncompressed packets associated with HC flows (e.g., uncompressed
IPHC-TCP packets) can be sent through the same MPLS tunnel along with IPHC-TCP packets) can be sent through the same MPLS tunnel along with
all other non-HC (non-PW) IP packets. MPLS tunnels can transport all other non-HC (non-PW) IP packets. MPLS tunnels can transport
many types of packets simultaneously, including non-PW IP packets, many types of packets simultaneously, including non-PW IP packets,
layer 3 VPN packets, and PW (e.g., HC flow) packets. In the layer 3 VPN packets, and PW (e.g., HC flow) packets. In the
specification we assume that there is a path for uncompressed specification we assume that there is a path for uncompressed
traffic, and it is a compressor decision as to what would or would traffic, and it is a compressor decision as to what would or would
not go in the HC-PW. not go in the HC-PW.
5. Protocol Specifications 4. Protocol Specifications
Figure 2 illustrates the PW stack reference model to support PW Figure 2 illustrates the PW stack reference model to support PW
emulated services. emulated services.
+-------------+ +-------------+ +-------------+ +-------------+
| Layer2 | | Layer2 | | Layer2 | | Layer2 |
| Emulated | | Emulated | | Emulated | | Emulated |
| Services | Emulated Service | Services | | Services | Emulated Service | Services |
| |<==============================>| | | |<==============================>| |
+-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 12, line 16 skipping to change at page 12, line 9
to several different types of streams, not just RTP streams, and QoS to several different types of streams, not just RTP streams, and QoS
treatment other than EF may be required for those streams. treatment other than EF may be required for those streams.
Figure 3 shows the HC over MPLS protocol stack (with uncompressed Figure 3 shows the HC over MPLS protocol stack (with uncompressed
header): header):
Media stream Media stream
RTP RTP
UDP UDP
IP IP
PW control word HC control parameter
MPLS label stack (at least 2 labels for this application) MPLS label stack (at least 2 labels for this application)
Link layer under MPLS (PPP, PoS, Ethernet) Link layer under MPLS (PPP, PoS, Ethernet)
Physical layer (SONET/SDH, fiber, copper) Physical layer (SONET/SDH, fiber, copper)
+--------------+ +--------------+
| Media stream | | Media stream |
+--------------+ +--------------+
\_______ ______/ \_______ ______/
2-4 octets V 2-4 octets V
+------+--------------+ +------+--------------+
Compressed /RTP/UDP/IP/ |header| | Compressed /RTP/UDP/IP/ |header| |
+------+--------------+ +------+--------------+
\__________ __________/ \__________ __________/
2 octets V 2 octets V
+------+---------------------+ +------+---------------------+
PW Control Word |header| | HC Control Parameter |header| |
+------+---------------------+ +------+---------------------+
\______________ _____________/ \______________ _____________/
8 octets V 8 octets V
+------+----------------------------+ +------+----------------------------+
MPLS Labels |header| | MPLS Labels |header| |
+------+----------------------------+ +------+----------------------------+
\_________________ _________________/ \_________________ _________________/
V V
+------------------------------------------+ +------------------------------------------+
Link Layer under MPLS | | Link Layer under MPLS | |
+------------------------------------------+ +------------------------------------------+
\____________________ _____________________/ \____________________ _____________________/
V V
+-------------------------------------------------+ +-------------------------------------------------+
Physical Layer | | Physical Layer | |
+-------------------------------------------------+ +-------------------------------------------------+
Figure 3 - Header Compression over MPLS Media Stream Transport Figure 3 - Header Compression over MPLS Media Stream Transport
The PW control word MUST be to used to identify the packet types for The HC control parameter MUST be to used to identify the packet types
the HC scheme in use. The MPLS labels technically define two layers: for the HC scheme in use. The MPLS labels technically define two
layers: the PW identifier and the MPLS tunnel identifier. The PW
the PW identifier and the MPLS tunnel identifier. The PW label MUST label MUST be used as the demultiplexer field by the HD, where the PW
be used as the demultiplexer field by the HD, where the PW label label appears at the bottom label of an MPLS label stack. The LSR
appears at the bottom label of an MPLS label stack. The LSR that that will be performing decompression MUST ensure that the label it
will be performing decompression MUST ensure that the label it
distributes (e.g., via LDP) for a channel is unique. There can also distributes (e.g., via LDP) for a channel is unique. There can also
be other MPLS labels, for example, to identify an MPLS VPN. The be other MPLS labels, for example, to identify an MPLS VPN. The
IP/UDP/RTP headers are compressed before transmission, leaving the IP/UDP/RTP headers are compressed before transmission, leaving the
rest of the stack alone, as shown in Figure 3. rest of the stack alone, as shown in Figure 3.
5.1 MPLS Pseudowire Setup & Signaling 4.1 MPLS Pseudowire Setup & Signaling
PWs MUST be set up in advance for the transport of media streams PWs MUST be set up in advance for the transport of media streams
using [RFC4447] control messages exchanged by the HC-HD endpoints. using [RFC4447] control messages exchanged by the HC-HD endpoints.
Furthermore, a PW type MUST be used to indicate the HC scheme being Furthermore, a PW type MUST be used to indicate the HC scheme being
used on the PW. [RFC4447] specifies the MPLS label distribution used on the PW. [RFC4447] specifies the MPLS label distribution
protocol (LDP) [RFC3036] extensions to set up and maintain the PWs, protocol (LDP) [RFC3036] extensions to set up and maintain the PWs,
and defines new LDP objects to identify and signal attributes of PWs. and defines new LDP objects to identify and signal attributes of PWs.
Any acceptable method of MPLS label distribution MAY be used for Any acceptable method of MPLS label distribution MAY be used for
distributing the MPLS tunnel label [RFC3031, RFC3985]. These methods distributing the MPLS tunnel label [RFC3031]. These methods include
include LDP [RFC3036], RSVP-TE [RFC3209], or configuration. LDP [RFC3036], RSVP-TE [RFC3209], or configuration.
To assign and distribute the PW labels, an LDP session MUST be set up To assign and distribute the PW labels, an LDP session MUST be set up
between the PW endpoints using the extended discovery mechanism between the PW endpoints using the extended discovery mechanism
described in [RFC3036]. The PW label bindings are distributed using described in [RFC3036]. The PW label bindings are distributed using
the LDP downstream unsolicited mode described in [RFC3036]. An LDP the LDP downstream unsolicited mode described in [RFC3036]. An LDP
label mapping message contains a FEC object, a label object, and label mapping message contains a FEC object, a label object, and
possible other optional objects. The FEC object indicates the possible other optional objects. The FEC object indicates the
meaning of the label, identifies the PW type, and identifies the PW meaning of the label, identifies the PW type, and identifies the PW
that the PW label is bound to. See [RFC4447] for further explanation that the PW label is bound to. See [RFC4447] for further explanation
of PW signaling. of PW signaling.
This specification defines new PW type values to be carried within This specification defines new PW type values to be carried within
the FEC object to identify HC PWs for each HC scheme. The PW type is 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] a 15-bit parameter assigned by IANA, as specified in the [RFC4446]
registry, and MUST be used to indicate the HC scheme being used on registry, and MUST be used to indicate the HC scheme being used on
the PW. The following PW type values have been set aside for the PW. IANA has set aside the following PW type values for
assignment by IANA: assignment according to the registry specified in RFC 4446, Section
3.2:
PW type Description Reference
=============================================================
0x001A ROHC Transport Header-compressed Packets [RFC3095] 0x001A ROHC Transport Header-compressed Packets [RFC3095]
0x001B ECRTP Transport Header-compressed Packets [RFC3545] 0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507] 0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D cRTP Transport Header-compressed Packets [RFC2508] 0x001D cRTP Transport Header-compressed Packets [RFC2508]
The PW control word enables distinguishing between various packets The HC control parameter enables distinguishing between various
types (e.g., uncompressed, UDP compressed, RTP compressed, packets types (e.g., uncompressed, UDP compressed, RTP compressed,
context-state, etc.). However, the PW control word indications are context-state, etc.). However, the HC control parameter indications
not unique across HC schemes, and therefore the PW type value allows are not unique across HC schemes, and therefore the PW type value
the HC scheme to be identified. allows the HC scheme to be identified.
5.2 Header Compression Scheme Setup, Negotiation, & Signaling 4.2 Header Compression Scheme Setup, Negotiation, & Signaling
As described in the previous section, the HC PW MUST be used for As described in the previous section, the HC PW MUST be used for
compressed packets only, which is configured at PW setup. If a flow compressed packets only, which is configured at PW setup. If a flow
is not compressed, it MUST NOT be placed on the HC PW. HC PWs MUST is not compressed, it MUST NOT be placed on the HC PW. HC PWs MUST
be bi-directional, which means that a unidirectional leg of the PW be bi-directional, which means that a unidirectional leg of the PW
MUST be set up in each direction. One leg of the bi-directional 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 MAY be set up to carry only compression feedback, not header
compressed traffic. The same PW type MUST be used for PW signaling compressed traffic. The same PW type MUST be used for PW signaling
in both directions. in both directions.
skipping to change at page 14, line 34 skipping to change at page 14, line 26
The PW HC approach relies on the PW/MPLS layer to convey HC channel The PW HC approach relies on the PW/MPLS layer to convey HC channel
configuration information. The Interface Parameters Sub-TLV [IANA, configuration information. The Interface Parameters Sub-TLV [IANA,
RFC4447] must be used to signal HC channel setup and specify HC RFC4447] must be used to signal HC channel setup and specify HC
parameters. That is, the configuration options specified in parameters. That is, the configuration options specified in
[RFC3241, RFC3544] are reused in this specification to specify PW [RFC3241, RFC3544] are reused in this specification to specify PW
specific parameters, and to configure the HC and HD ports at the specific parameters, and to configure the HC and HD ports at the
edges of the PW, so that they have the necessary capabilities to edges of the PW, so that they have the necessary capabilities to
interoperate with each other. interoperate with each other.
Pseudowire Interface Parameter Sub-TLV type values are specified in Pseudowire Interface Parameter Sub-TLV type values are specified in
[RFC4446]. Two code-points have been reserved, as follows: [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 References Parameter ID Length Description References
=====================================================================
0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241 0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544 0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544
configuration configuration"
TLVs identified in [RFC3241] and [RFC3544] MUST be encapsulated in TLVs identified in [RFC3241] and [RFC3544] MUST be encapsulated in
the PW Interface Parameters Sub-TLV and used to negotiate header the PW Interface Parameters Sub-TLV and used to negotiate header
compression session setup and parameter negotiation for their compression session setup and parameter negotiation for their
respective protocols. The TLVs supported in this manner MUST include respective protocols. The TLVs supported in this manner MUST include
the following: the following:
o Configuration Option Format, RTP-Compression Suboption, Enhanced o Configuration Option Format, RTP-Compression Suboption, Enhanced
RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as
specified in [RFC3544] specified in [RFC3544]
o Configuration Option Format, PROFILES Suboption, as specified in o Configuration Option Format, PROFILES Suboption, as specified in
[RFC3241] [RFC3241]
These TLVs are now specified in the following sections. These TLVs are now specified in the following sections.
5.2.1 Configuration Option Format [RFC3544] 4.2.1 Configuration Option Format [RFC3544]
Both the network control protocol for IPv4, IPCP [RFC1332] and the Both the network control protocol for IPv4, IPCP [RFC1332] and the
IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters
for their respective protocols. The format of the configuration for their respective controlled protocols. The format of the
option is the same for both IPCP and IPV6CP. This configuration configuration option is the same for both IPCP and IPV6CP. This
option MUST be included for ECRTP, CRTP and IPHC PW types and MUST configuration option MUST be included for ECRTP, CRTP and IPHC PW
NOT be included for ROHC PW types. 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 Description
This NCP configuration option is used to negotiate parameters for This NCP configuration option is used to negotiate parameters for
IP HC. Successful negotiation of parameters enables the use of IP HC. Successful negotiation of parameters enables the use of
Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, Protocol Identifiers FULL_HEADER, COMPRESSED_TCP,
COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and CONTEXT_STATE as COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and CONTEXT_STATE as
specified in [RFC2507]. The option format is summarized below. specified in [RFC2507]. The option format is summarized below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
skipping to change at page 17, line 18 skipping to change at page 17, line 15
more parameter octets, as defined by the suboption type. The more parameter octets, as defined by the suboption type. The
value of the length field indicates the length of the suboption in value of the length field indicates the length of the suboption in
its entirety, including the lengths of the type and length fields. its entirety, including the lengths of the type and length fields.
0 1 2 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 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...| | Type | Length | Parameters...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2 RTP-Compression Suboption [RFC3544] 4.2.2 RTP-Compression Suboption [RFC3544]
The RTP-Compression suboption is included in the NCP IP-Compression- The RTP-Compression suboption is included in the NCP IP-Compression-
Protocol option for IPHC if IP/UDP/RTP compression is to be enabled. Protocol option for IPHC if IP/UDP/RTP compression is to be enabled.
This suboption MUST be included for cRTP PWs (0x001C) and MUST NOT be This suboption MUST be included for cRTP PWs (0x001C) and MUST NOT be
included for other PW types. included for other PW types.
Inclusion of the RTP-Compression suboption enables use of additional Inclusion of the RTP-Compression suboption enables use of additional
Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with
additional forms of CONTEXT_STATE as specified in [RFC2508]. additional forms of CONTEXT_STATE as specified in [RFC2508].
skipping to change at page 17, line 46 skipping to change at page 17, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
1 1
Length Length
2 2
5.2.3 Enhanced RTP-Compression Suboption [RFC3544] 4.2.3 Enhanced RTP-Compression Suboption [RFC3544]
To use the enhanced RTP HC defined in [RFC3545], a To use the enhanced RTP HC defined in [RFC3545], a
new sub-option 2 is added. Sub-option 2 is negotiated instead of, new sub-option 2 is added. Sub-option 2 is negotiated instead of,
not in addition to, sub-option 1. This suboption MUST be included not in addition to, sub-option 1. This suboption MUST be included
for ECRTP PWs (0x001B) and MUST NOT be included for other PW types. for ECRTP PWs (0x001B) and MUST NOT be included for other PW types.
Note that sub-option 1 refers to the RTP-Compression Sub-option, as
specified in Section 4.2.2, and sub-option 2 refers to the Enhanced
RTP-Compression Sub-option, as specified in Section 4.2.3. These
sub-options do not occur together.
Description Description
Enable use of Protocol Identifiers COMPRESSED_RTP and Enable use of Protocol Identifiers COMPRESSED_RTP and
CONTEXT_STATE as specified in [RFC2508]. In addition, enable use CONTEXT_STATE as specified in [RFC2508]. In addition, enable use
of [RFC3545] compliant compression including the use of Protocol of [RFC3545] compliant compression including the use of Protocol
Identifier COMPRESSED_UDP with additional flags and use of the C Identifier COMPRESSED_UDP with additional flags and use of the C
flag with the FULL_HEADER Protocol Identifier to indicate use of flag with the FULL_HEADER Protocol Identifier to indicate use of
HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets. HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
2 2
Length Length
2 2
5.2.4 Negotiating header compression for only TCP or only non-TCP 4.2.4 Negotiating header compression for only TCP or only non-TCP
Packets [RFC3544] Packets [RFC3544]
In [RFC2509] it was not possible to negotiate only TCP HC or only 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 the NON_TCP_SPACE non-TCP HC because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE
fields actually means that 1 context is negotiated. fields actually means that 1 context is negotiated.
A new suboption 3 is added to allow specifying that the number of A new suboption 3 is added to allow specifying that the number of
contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the
corresponding compression. This suboption MUST be included for IPHC corresponding compression. This suboption MUST be included for IPHC
PWs (0x001C) and MUST NOT be included for other PW types. PWs (0x001C) and MUST NOT be included for other PW types.
Description Description
skipping to change at page 18, line 52 skipping to change at page 19, line 4
| Type | Length | Parameter | | Type | Length | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
3 3
Length Length
3 3
Parameter Parameter
The parameter is 1 byte with one of the following values: The parameter is 1 byte with one of the following values:
1 = the number of contexts for TCP_SPACE is 0 1 = the number of contexts for TCP_SPACE is 0
2 = the number of contexts for NON_TCP_SPACE is 0 2 = the number of contexts for NON_TCP_SPACE is 0
This suboption overrides the values that were previously assigned to This suboption overrides the values that were previously assigned to
TCP_SPACE and NON_TCP_SPACE in the IP HC option. TCP_SPACE and NON_TCP_SPACE in the IP HC option.
If suboption 3 is included multiple times with parameter 1 and 2, If suboption 3 is included multiple times with parameter 1 and 2,
compression is disabled for all packets. compression is disabled for all packets.
5.2.5 Configuration Option Format [RFC3241] 4.2.5 Configuration Option Format [RFC3241]
Both the network control protocol for IPv4, IPCP [RFC1332] and the Both the network control protocol for IPv4, IPCP [RFC1332] and the
IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters
for their respective protocols. The format of the configuration for their respective controlled protocols. The format of the
option is the same for both IPCP and IPV6CP. This configuration configuration option is the same for both IPCP and IPV6CP. This
option MUST be included for ROHC PW types and MUST NOT be included configuration option MUST be included for ROHC PW types and MUST NOT
for ECRTP, CRTP and IPHC PW types. be included for ECRTP, CRTP and IPHC PW types. A decompressor
MUST reject this option (if misconfigured) for ECRTP, CRTP and IPHC
PW types and send an explicit error message to the compressor
[RFC3544].
Description Description
This NCP configuration option is used to negotiate parameters for This NCP configuration option is used to negotiate parameters for
ROHC. The option format is summarized below. ROHC. The option format is summarized below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 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 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 | | Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_CID | MRRU | | MAX_CID | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions... | MAX_HEADER | suboptions... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
2 2
Length Length
>= 10 >= 10
The length may be increased if the presence of additional The length may be increased if the presence of additional
parameters is indicated by additional suboptions. parameters is indicated by additional suboptions.
skipping to change at page 20, line 10 skipping to change at page 20, line 16
The MAX_CID field is two octets and indicates the maximum value of The MAX_CID field is two octets and indicates the maximum value of
a context identifier. a context identifier.
Suggested value: 15 Suggested value: 15
MAX_CID must be at least 0 and at most 16383 (The value 0 implies MAX_CID must be at least 0 and at most 16383 (The value 0 implies
having one context). having one context).
MRRU MRRU
The MRRU field is two octets and indicates the maximum The MRRU field is two octets and indicates the maximum
reconstructed reception unit (see [RFC3095], section 5.1.1). reconstructed reception unit (see [RFC3095], Section 5.1.1).
Suggested value: 0 Suggested value: 0
MAX_HEADER MAX_HEADER
The largest header size in octets that may be compressed. The largest header size in octets that may be compressed.
Suggested value: 168 octets Suggested value: 168 octets
The value of MAX_HEADER should be large enough so that at least The value of MAX_HEADER should be large enough so that at least
the outer network layer header can be compressed. To increase the outer network layer header can be compressed. To increase
compression efficiency MAX_HEADER should be set to a value large compression efficiency MAX_HEADER should be set to a value large
enough to cover common combinations of network and transport layer enough to cover common combinations of network and transport layer
headers. headers.
NOTE: The four ROHC profiles defined in RFC 3095 do not provide NOTE: The four ROHC profiles defined in RFC 3095 do not provide
for a MAX_HEADER parameter. The parameter MAX_HEADER defined by for a MAX_HEADER parameter. The parameter MAX_HEADER defined by
this document is therefore without consequence in these profiles. 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 Other profiles (e.g., ones based on RFC 2507) can make use of the
parameter by explicitly referencing it. parameter by explicitly referencing it.
suboptions suboptions
The suboptions field consists of zero or more suboptions. Each The suboptions field consists of zero or more suboptions. Each
suboption consists of a type field, a length field and zero or suboption consists of a type field, a length field and zero or
more parameter octets, as defined by the suboption type. The more parameter octets, as defined by the suboption type. The
value of the length field indicates the length of the suboption in value of the length field indicates the length of the suboption in
its entirety, including the lengths of the type and length fields. its entirety, including the lengths of the type and length fields.
0 1 2 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 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... | Type | Length | Parameters...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.6 PROFILES Suboption [RFC3241] 4.2.6 PROFILES Suboption [RFC3241]
The set of profiles to be enabled is subject to negotiation. Most The set of profiles to be enabled is subject to negotiation. Most
initial implementations of ROHC implement profiles 0x0000 to 0x0003. initial implementations of ROHC implement profiles 0x0000 to 0x0003.
This option MUST be supplied. This option MUST be supplied.
Description Description
Define the set of profiles supported by the decompressor. Define the set of profiles supported by the decompressor.
0 1 2 0 1 2
skipping to change at page 21, line 25 skipping to change at page 21, line 29
2n+2 2n+2
Value Value
n octet-pairs in ascending order, each octet-pair specifying a n octet-pairs in ascending order, each octet-pair specifying a
ROHC profile supported. ROHC profile supported.
HC flow identification is being done now in many ways. Since there HC flow identification is being done now in many ways. Since there
are multiple possible approaches to the problem, no specific method are multiple possible approaches to the problem, no specific method
is specified in this document. is specified in this document.
5.3 Encapsulation of Header Compressed Packets 4.3 Encapsulation of Header Compressed Packets
The PW control word is used to identify the packet types for IPHC The HC control parameter is used to identify the packet types for
[RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 4: IPHC [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown in
Figure 4:
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|Pkt Typ| Length |Res| |0 0 0 0|Pkt Typ| Length |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - PW Control Word Figure 4 - HC Control Parameter
where: where:
"Packet Type" encoding: "Packet Type" encoding:
0: ROHC Small-CIDs 0: ROHC Small-CIDs
1: ROHC Large-CIDs 1: ROHC Large-CIDs
2: FULL_HEADER 2: FULL_HEADER
3: COMPRESSED_TCP 3: COMPRESSED_TCP
4: COMPRESSED_TCP_NODELTA 4: COMPRESSED_TCP_NODELTA
5: COMPRESSED_NON_TCP 5: COMPRESSED_NON_TCP
6: COMPRESSED_RTP_8 6: COMPRESSED_RTP_8
7: COMPRESSED_RTP_16 7: COMPRESSED_RTP_16
8: COMPRESSED_UDP_8 8: COMPRESSED_UDP_8
9: COMPRESSED_UDP_16 9: COMPRESSED_UDP_16
10: CONTEXT_STATE 10: CONTEXT_STATE
11-15: TO BE ASSIGNED BY IANA (see Section 8, IANA considerations, 11-15: TO BE ASSIGNED BY IANA (see Section 7, IANA considerations,
for discussion of the Registry) for discussion of the Registry)
As discussed in [ECMP-AVOID], since this MPLS payload type is not IP, As discussed in [ECMP-AVOID], since this MPLS payload type is not IP,
the first nibble is set to 0000 to avoid being mistaken for IP. This the first nibble is set to 0000 to avoid being mistaken for IP. This
is also consistent with the encoding of the PWE3 control word is also consistent with the encoding of the PW MPLS control word
[PW-CNTL-WORD]. (PWMCW) described in [RFC4385]; however, the HC control parameter is
not intended to be a PWMCW.
Note that ROHC [RFC3095] provides its own packet type within the Note that ROHC [RFC3095] provides its own packet type within the
protocol, however the PW control word MUST still be used to avoid the protocol, however the HC control parameter MUST still be used to
problems identified above. Since the "Packet Type" will be there avoid the problems identified above. Since the "Packet Type" will be
anyway, it is used to indicate ROHC CID size, in the same way as with there anyway, it is used to indicate ROHC CID size, in the same way
PPP. as with PPP.
The PW control word length field is ONLY used for short packets The HC control parameter length field is ONLY used for short packets
because padding may be appended by the Ethernet Data Link Layer. If because padding may be appended by the Ethernet Data Link Layer. If
the length is >= than 64 octets, the length field MUST be set to zero the length is >= than 64 octets, the length field MUST be set to
[PW-CNTL-WORD]. If the MPLS payload is less than 64 bytes, the zero. If the MPLS payload is less than 64 bytes, the length field
length field MUST be set to the length of the PW payload plus the MUST be set to the length of the PW payload plus the length of the HC
length of the PW control word. Note that the last 2 bits in the PW control parameter. Note that the last 2 bits in the HC control
control word are reserved. parameter are reserved.
5.4 Packet Reordering 4.4 Packet Reordering
Packet reordering for ROHC is discussed in [RFC4224], which is a Packet reordering for ROHC is discussed in [RFC4224], which is a
useful source of information. In case of lossy links and other useful source of information. In case of lossy links and other
reasons for reordering, implementation adaptations are needed to reasons for reordering, implementation adaptations are needed to
allow all the schemes to be used in this case. Although CRTP is allow all the schemes to be used in this case. Although CRTP is
viewed as having risks for a number PW environments due to reordering viewed as having risks for a number of PW environments due to
and loss, it is still the protocol of choice in many cases. In these reordering and loss, it is still the protocol of choice in many
circumstances, it must be implemented and deployed with care. IPHC cases. CRTP was designed for reliable point to point links with
should use TCP_NODELTA, ECRTP should send absolute values, ROHC short delays. It does not perform well over links with high rate of
should be adapted as discussed in [RFC4224]. An evaluation and packet loss, packet reordering and long delays. In such cases ECRTP
simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL]. [RFC3545] may be considered to increase robustness to both packet
loss and misordering between the compressor and the decompressor.
This is achieved by repeating updates and sending of absolute
(uncompressed) values in addition to delta values for selected
context parameters. IPHC should use TCP_NODELTA, ECRTP should send
absolute values, ROHC should be adapted as discussed in [RFC4224].
An evaluation and simulation of ECRTP and ROHC reordering is given in
[REORDER-EVAL].
6. HC Pseudowire Setup Example 5. HC Pseudowire Setup Example
This example will trace the setup of an MPLS PW supporting This example will trace the setup of an MPLS PW supporting
bi-directional ECRTP [RFC3545] traffic. The example assumes the bi-directional ECRTP [RFC3545] traffic. The example assumes the
topology shown in Figure 1. The PW will be set up between LSRs R1/HC topology shown in Figure 1. The PW will be set up between LSRs R1/HC
and R4/HD. LSRs R2 and R3 have no direct involvement in the and R4/HD. LSRs R2 and R3 have no direct involvement in the
signaling for this PW, other than to transport the signaling traffic. signaling for this PW, other than to transport the signaling traffic.
For this example, it is assumed that R1/HC has already obtained the For this example, it is assumed that R1/HC has already obtained the
IP address of R4/HD used for LDP signaling, and vice versa, that both IP address of R4/HD used for LDP signaling, and vice versa, that both
R1/HC and R4/HD have been configured with the same 32 bit PW ID, as R1/HC and R4/HD have been configured with the same 32 bit PW ID, as
skipping to change at page 23, line 46 skipping to change at page 24, line 9
would become operational. would become operational.
At this point, either R1/HC or R4/HD may send LDP Label Mapping At this point, either R1/HC or R4/HD may send LDP Label Mapping
messages to configure the PW. The Label Mapping message sent by a messages to configure the PW. The Label Mapping message sent by a
particular router advertises the label that should be used at the particular router advertises the label that should be used at the
bottom of the MPLS label stack for all packets sent to that router bottom of the MPLS label stack for all packets sent to that router
and associated with the particular PW. The Label Mapping message and associated with the particular PW. The Label Mapping message
sent from R1/HC to R4/HD would have the following characteristics: sent from R1/HC to R4/HD would have the following characteristics:
o FEC TLV o FEC TLV
- FEC Element type 0x80 (Pwid FEC Element, as defined in [RFC4447] - FEC Element type 0x80 (PWid FEC Element, as defined in [RFC4447]
- Control Word bit = 1 (Control Word present) - Control Parameter bit = 1 (Control Parameter present)
- PW type = 0x001B (ECRTP [RFC 3545]) - PW type = 0x001B (ECRTP [RFC3545])
- Group ID as chosen by R1/HC - Group ID as chosen by R1/HC
- PW ID = the configured value for this PW, which must be the same - PW ID = the configured value for this PW, which must be the same
as that sent in the Label Mapping message by R4/HD as that sent in the Label Mapping message by R4/HD
- Interface Parameter Sub-TLVs - Interface Parameter Sub-TLVs
> Interface MTU sub-TLV (Type 0x01) > Interface MTU sub-TLV (Type 0x01)
> CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV (Type 0x0F) > CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV (Type 0x0F)
+ Type = 2 (From RFC 3544) + Type = 2 (From RFC 3544)
+ Length = 16 + Length = 16
+ TCP_SPACE = Don't Care (leave at suggested value = 15) + TCP_SPACE = Don't Care (leave at suggested value = 15)
+ NON_TCP_SPACE = 200 (configured on R1) + NON_TCP_SPACE = 200 (configured on R1)
skipping to change at page 24, line 20 skipping to change at page 24, line 34
seconds) seconds)
+ MAX_HEADER = 168 (Suggested Value) + MAX_HEADER = 168 (Suggested Value)
+ Enhanced RTP-Compression Suboption + Enhanced RTP-Compression Suboption
& Type = 2 & Type = 2
& Length = 2 & Length = 2
o Label TLV - contains label selected by R1, Lr1 o Label TLV - contains label selected by R1, Lr1
o No Optional Parameters o No Optional Parameters
The Label Mapping message sent from R4/HD to R1/HC would be almost The Label Mapping message sent from R4/HD to R1/HC would be almost
identical to the one sent in the opposite direction, with the identical to the one sent in the opposite direction, with the
following exceptions following exceptions:
o R4/HD could select a different Group ID o R4/HD could select a different Group ID
o The Value of NON_TCP_SPACE in the CRTP/ECRTP/IPHC HC over MPLS o The Value of NON_TCP_SPACE in the CRTP/ECRTP/IPHC HC over MPLS
configuration sub-TLV would be 255 instead of 200, as configured configuration sub-TLV would be 255 instead of 200, as configured
on R4/HD on R4/HD
o R4/HD would choose its own value for the Label TLV, Lr4 o R4/HD would choose its own value for the Label TLV, Lr4
As soon as either R1/HC or R4/HD had both transmitted and received As soon as either R1/HC or R4/HD had both transmitted and received
Label Mapping Messages with the same PW Type and PW ID, it could Label Mapping Messages with the same PW Type and PW ID, each HC
consider the PW established. R1/HC could send ECRTP packets using endpoint considers the PW established when it has seen both packets.
the label it received in the Label Mapping Message from R4/HD, Lr4, R1/HC could send ECRTP packets using the label it received in the
and could identify received ECRTP packets by the label it had sent to Label Mapping Message from R4/HD, Lr4, and could identify received
R4/HD, Lr1. And vice versa. ECRTP packets by the label it had sent to R4/HD, Lr1. And vice
versa.
In this case, assume that R1/HC has an IPv4 RTP flow to send to R4/HD In this case, assume that R1/HC has an IPv4 RTP flow to send to R4/HD
that it wishes to compress using the ECRTP PW just set up. The RTP that it wishes to compress using the ECRTP PW just set up. The RTP
flow is G.729 media with 20 bytes of payload in each RTP packet. In 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 this particular case, the IPv4 identifier changes by a small constant
value between consecutive packets in the stream. In the RTP layer of value between consecutive packets in the stream. In the RTP layer of
the flow, the Contributing Source Identifiers count is 0. R1/HC the flow, the Contributing Source Identifiers count is 0. R1/HC
decides to use 8-bit Context Identifiers for the compressed flow. decides to use 8-bit Context Identifiers for the compressed flow.
Also, R1/HC determines that compression in this particular flow Also, R1/HC determines that compression in this particular flow
should be able to recover from the loss of 2 consecutive packets should be able to recover from the loss of 2 consecutive packets
skipping to change at page 25, line 31 skipping to change at page 25, line 41
where XX signifies either where XX signifies either
a. value determined by the MPLS routing layer a. value determined by the MPLS routing layer
b. don't care b. don't care
Immediately following the above header would come the FULL_HEADER Immediately following the above header would come the FULL_HEADER
packet as defined in [RFC3545], which basically consists of the packet as defined in [RFC3545], which basically consists of the
IP/UDP/RTP header, with the IP and UDP length field replaced by IP/UDP/RTP header, with the IP and UDP length field replaced by
values encoding the CID, sequence number and "generation", as defined values encoding the CID, sequence number and "generation", as defined
in [RFC3545]. The length field value of 62 comprises: in [RFC3545]. The length field value of 62 comprises:
o 2 bytes of PW control word (included in the above diagram) o 2 bytes of HC control parameter (included in the above diagram)
o 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER o 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER
o 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER o 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER
o 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER o 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER
o 20 bytes of G.729 payload o 20 bytes of G.729 payload
The following 3 RTP packets from this flow would be sent as The next 3 RTP packets from this flow would be sent as
COMPRESSED_UDP_8, to establish the absolute and delta values of the COMPRESSED_UDP_8, to establish the absolute and delta values of the
IPv4 identifier and RTP timestamp fields. These packets would use IPv4 identifier and RTP timestamp fields. These packets would use
the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS
and PW headers at the beginning of these packets would be formatted and PW headers at the beginning of these packets would be formatted
as follows: as follows:
0 1 2 3 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 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 | | Label | Exp |S| TTL |
skipping to change at page 26, line 22 skipping to change at page 26, line 22
| Lr4 | XX |1| >0 | | Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res| | |Pkt Typ| Length |Res|
|0 0 0 0| 8 | 36 |0 0| |0 0 0 0| 8 | 36 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^
| |
-- 8 == COMPRESSED_UDP_8 -- 8 == COMPRESSED_UDP_8
There is no change in the MPLS label stack between the FULL_HEADER There is no change in the MPLS label stack between the FULL_HEADER
packets and the COMPRESSED_UDP packets. The PW control word changes packets and the COMPRESSED_UDP packets. The HC control parameter
to reflect another ECRTP packet type following the control word, and changes to reflect another ECRTP packet type following the control
a change of packet length. The length changes because the new packet parameter, and a change of packet length. The length changes because
type more compactly encodes the headers. The length field value of the new packet type more compactly encodes the headers. The length
36 comprises: field value of 36 comprises:
o 2 bytes of PW control word (included in the above diagram) o 2 bytes of HC control parameter (included in the above diagram)
o 1 byte of CID o 1 byte of CID
- 4 bits of COMPRESSED_UDP flags - 4 bits of COMPRESSED_UDP flags
- 4 bits of sequence number - 4 bits of sequence number
- 5 bits of COMPRESSED UDP extension flags - 5 bits of COMPRESSED UDP extension flags
- 3 bits MUST_BE_ZERO - 3 bits MUST_BE_ZERO
o 2 bytes of UDP checksum or HDRCKSUM o 2 bytes of UDP checksum or HDRCKSUM
o 1 byte of delta IPv4 ID o 1 byte of delta IPv4 ID
o 2 bytes of delta RTP timestamp (changes by 160 in this case, o 2 bytes of delta RTP timestamp (changes by 160 in this case,
differential encoding will encode as 2 bytes) differential encoding will encode as 2 bytes)
o 2 bytes of absolute IPv4 ID o 2 bytes of absolute IPv4 ID
skipping to change at page 27, line 21 skipping to change at page 27, line 21
| Label | Exp |S| TTL | | Label | Exp |S| TTL |
| Lr4 | XX |1| >0 | | Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res| | |Pkt Typ| Length |Res|
|0 0 0 0| 6 | 26 |0 0| |0 0 0 0| 6 | 26 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^
| |
-- 6 == COMPRESSED_RTP_8 -- 6 == COMPRESSED_RTP_8
The PW control word again changes to reflect another ECRTP packet The HC control parameter again changes to reflect another ECRTP
type following the control word, and shorter length associated with packet type following the control parameter, and shorter length
an even more compact encoding of headers. The length field value of associated with an even more compact encoding of headers. The length
26 comprises: field value of 26 comprises:
o 2 bytes of PW control word (included in the above diagram) o 2 bytes of HC control parameter (included in the above diagram)
o 1 byte of CID o 1 byte of CID
- 4 bits of COMPRESSED_RTP flags - 4 bits of COMPRESSED_RTP flags
- 4 bits of sequence number - 4 bits of sequence number
o 2 bytes of UDP checksum or HDRCKSUM o 2 bytes of UDP checksum or HDRCKSUM
o 20 bytes of G.729 payload o 20 bytes of G.729 payload
Additional flows in the same direction may be compressed using the Additional flows in the same direction may be compressed using the
same basic encapsulation, including the same PW label. The CID that same basic encapsulation, including the same PW label. The CID that
is part of the HC protocol is used to differentiate flows. For is part of the HC protocol is used to differentiate flows. For
traffic in the opposite direction, the primary change would be the PW traffic in the opposite direction, the primary change would be the PW
label, Lr4, used in the example above would be replaced by the label label, Lr4, used in the example above would be replaced by the label
Lr1 that R1/HC provides to R4/HD. Lr1 that R1/HC provides to R4/HD.
7. Security Considerations 6. Security Considerations
MPLS PW security considerations in general are discussed in MPLS PW security considerations in general are discussed in
[RFC3985] and [RFC4447], and those considerations also apply to this [RFC3985] and [RFC4447], and those considerations also apply to this
document. This document specifies an encapsulation and not the document. This document specifies an encapsulation and not the
protocols that may be used to carry the encapsulated packets across protocols that may be used to carry the encapsulated packets across
the PSN, or the protocols being encapsulated. Each such protocol may the PSN, or the protocols being encapsulated. Each such protocol may
have its own set of security issues, but those issues are not have its own set of security issues, but those issues are not
affected by the encapsulations specified herein. affected by the encapsulations specified herein.
The security considerations of the supported HC protocols [RFC2507, The security considerations of the supported HC protocols [RFC2507,
RFC2508, RFC3095, RFC3545] all apply to this document as well. RFC2508, RFC3095, RFC3545] all apply to this document as well.
8. Acknowledgements 7. Acknowledgements
The authors appreciate valuable inputs and suggestions from Loa The authors appreciate valuable inputs and suggestions from Loa
Andersson, Scott Brim, Stewart Bryant, Adrian Farrel, Victoria Andersson, Scott Brim, Stewart Bryant, Spencer Dawkins, Adrian
Fineberg, Eric Gray, Allison Mankin, Luca Martini, Colin Perkins, Farrel, Victoria Fineberg, Eric Gray, Allison Mankin, Luca Martini,
Kristofer Sandlund, Yaakov Stein, George Swallow, Curtis Villamizar, Colin Perkins, Kristofer Sandlund, Yaakov Stein, George Swallow,
and Magnus Westerlund. Mark Townsley, Curtis Villamizar, and Magnus Westerlund.
9. IANA Considerations 8. IANA Considerations
As discussed in Section 4.1, PW type values need to be assigned by As discussed in Section 3.1, PW type values need to be assigned by
IANA, as follows: IANA, as follows:
0x001A ROHC Transport Header-compressed Packets [RFC3095] 0x001A ROHC Transport Header-compressed Packets [RFC3095]
0x001B ECRTP Transport Header-compressed Packets [RFC3545] 0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507] 0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D cRTP Transport Header-compressed Packets [RFC2508] 0x001D cRTP Transport Header-compressed Packets [RFC2508]
Procedures for registering new PW type values are given in [RFC4446]. Procedures for registering new PW type values are given in [RFC4446].
As discussed in Section 4.2, Pseudowire Interface Parameter Sub-TLV As discussed in Section 3.2, Pseudowire Interface Parameter Sub-TLV
type values need to be specified by IANA, as follows: type values need to be specified by IANA, as follows:
Parameter ID Length Description References Parameter ID Length Description References
0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241 0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544 0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544
configuration configuration
As discussed in Section 4.3, IANA needs to define a new registry, As discussed in Section 3.3, IANA needs to define a new registry,
"Header Compression Over MPLS PW Control Word Packet Type". This is "Header Compression Over MPLS HC Control Parameter Packet Type".
a four bit value. Packet Types 0 through 10 are defined in Section This is a four bit value. Packet Types 0 through 10 are defined in
4.3 of this document. Packet Types 11 to 15 are to be assigned by Section 3.3 of this document. Packet Types 11 to 15 are to be
IANA using the "Expert Review" policy defined in [RFC2434]. assigned by IANA using the "Expert Review" policy defined in
[RFC2434].
10. Normative References
[PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over 9. Normative References
an MPLS PSN," work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2434] Narten, T. et al, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3036] Andersson, L., et. al., "LDP Specification," RFC 3036, [RFC3036] Andersson, L., et. al., "LDP Specification," RFC 3036,
January 2001. January 2001.
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP," [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP,"
RFC 3241, April 2002. RFC 3241, April 2002.
[RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression [RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression
over PPP", RFC 3544, July 2003. over PPP", RFC 3544, July 2003.
[RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture," RFC 3985, March 2005.
[RFC4447] Martini, L., et. al., "Pseudowire Setup and Maintenance [RFC4447] Martini, L., et. al., "Pseudowire Setup and Maintenance
Using LDP," RFC 4447, April 2006. Using LDP," RFC 4447, April 2006.
11. Informative References 10. Informative References
[ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath [ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath
Treatment in MPLS Networks," work in progress. Treatment in MPLS Networks," work in progress.
[REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header [REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header
Compression Algorithm ECRTP," Compression Algorithm ECRTP,"
http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf. http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf.
[RFC1331] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-Point Links,"
May 1992.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)," May 1992. (IPCP)," May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)," RFC 1661,
July 1994.
[RFC2434] Narten, T., et. al., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
[RFC2472] Haskin, D., Allen, E., "IP Version 6 over PPP," RFC 2472, [RFC2472] Haskin, D., Allen, E., "IP Version 6 over PPP," RFC 2472,
December 1998. December 1998.
[RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507, [RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507,
February 1999. February 1999.
[RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers [RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999. for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2509] Engan, M., et. al., "IP Header Compression over PPP,"
RFC 2509, February 1999.
[RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
1999.
[RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC): [RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC
3095, July 2001. 3095, July 2001.
[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001. 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 [RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on
Links with High Delay, Packet Loss, and Reordering," RFC 3545, July Links with High Delay, Packet Loss, and Reordering," RFC 3545, July
2003. 2003.
[RFC3246] Davie, B., et. al., "An Expedited Forwarding PHB (Per-Hop [RFC3246] Davie, B., et. al., "An Expedited Forwarding PHB (Per-Hop
Behavior)," RFC 3246, March 2002. Behavior)," RFC 3246, March 2002.
[RFC3270] Le Faucheur, F., et. al., "Multi-Protocol Label Switching [RFC3270] Le Faucheur, F., et. al., "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services," RFC 3270, May 2002. (MPLS) Support of Differentiated Services," RFC 3270, May 2002.
[RFC3550] Schulzrinne, H., et. al., "RTP: A Transport Protocol for [RFC3550] Schulzrinne, H., et. al., "RTP: A Transport Protocol for
Real-Time Applications," RFC 3550, July 2003. Real-Time Applications," RFC 3550, July 2003.
[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 [RFC4224] Pelletier, G., et. al., "RObust Header Compression
(ROHC): ROHC over Channels that can Reorder Packets," RFC 4224, (ROHC): ROHC over Channels that can Reorder Packets," RFC 4224,
January 2006. January 2006.
[RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header [RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header
Compression over MPLS", RFC 4247, November 2005. 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 [RFC4446] Martini, L., et. al., "IANA Allocations for Pseudo Wire
Edge To Edge Emulation (PWE3)," RFC 4446, April 2006. Edge To Edge Emulation (PWE3)," RFC 4446, April 2006.
[ROHC-IMPL-GUIDE] Jonsson, L-E., Kremer, P. "The RFC 3095 [ROHC-IMPL-GUIDE] Jonsson, L-E., et. al., RObust Header Compression
Implementer's Guide," work in progress. (ROHC): Corrections and Clarifications to RFC 3095," work in
progress.
12. Authors' Addresses Contributing Authors
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
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: zhangr@bt.infonet.com
Editors' Addresses
Jerry Ash (Editor) Jerry Ash (Editor)
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732-420-4578 Phone: +1 732-420-4578
Email: gash@att.com Email: gash@att.com
Jim Hand (Editor) Jim Hand (Editor)
AT&T AT&T
Room MT A2-1A03 Room MT A2-1A03
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732-420-3017 Phone: +1 732-420-3017
Email: jameshand@att.com Email: jameshand@att.com
Andrew G. Malis (Editor) Andrew G. Malis (Editor)
Tellabs Verizon Communications
90 Rio Robles Dr. 40 Sylvan Road
San Jose, CA 95134 Waltham, MA 02451 USA
Email: Andy.Malis@tellabs.com Email: andrew.g.malis@verizon.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 31, line 23 skipping to change at page 32, line 6
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (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.
 End of changes. 89 change blocks. 
220 lines changed or deleted 253 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/