wdiff draft-ash-avt-hc-over-mpls-protocol-00.txt draft-ash-avt-hc-over-mpls-protocol-01.txt

Network Working Group Jerry Ash
Internet Draft Bur Goode
<draft-ash-avt-hc-over-mpls-protocol-00.txt>
<draft-ash-avt-hc-over-mpls-protocol-01.txt> AT&T
Expiration Date: October 2005 January 2006 Jim Hand
Consultant
L-E. Jonsson
Ericsson
Andrew Malis
Tellabs
Raymond Zhang
Infonet

April,

July, 2005

Protocol Extensions for Header Compression over MPLS

Status of this Memo

By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 26, 2005.

Abstract

VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels
Labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an
MPLS VPN, the packet header is at least typically 48 bytes, while the voice
payload is often no more than 30 bytes, for example. Header
compression can significantly reduce the overhead through various
compression mechanisms. MPLS is used to route header-compressed (HC)
packets over an MPLS LSP without compression/decompression cycles at
each router. Such an HC over MPLS capability increases the bandwidth
efficiency as well as processing scalability of the maximum number of
simultaneous compressed flows that use HC at each router. MPLS
pseudowires are used to transport the HC context and other control
messages between the ingress and egress MPLS label switched router
(LSR), and the pseudowires define a point to point instance of each
HC session at the header decompressor. Standard HC methods (e.g.,
ECRTP, ROHC, etc.) are re-used to determine the context.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Extensions Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1
3. Header Compression over MPLS Pseudowire Establishment & Processing Protocol Overview . . . . . . . . 6
3.1 PW Setup & HC Session Configuration . . 6
2.2 Link Layer Packet Type Field . . . . . . . . . 7
3.2 HC over MPLS . . . . . . . . 7
3. HC over MPLS Procedures . . . . . . . . . . . . . . . 8
4. Protocol Specifications . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . 9
4.1 MPLS Pseudowire & Header Compression Scheme
Setup/Negotiation/Signaling . . . . . . . . . . . . . . . 9
5. Acknowledgments
4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12
4.2.1 FULL_HEADER Packet Format . . . . . . . . . . . . . 13
4.2.2 CONTEXT_STATE Packet Format . . . . . . . . 9
6. IANA . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . 9 . . . . . . . . . . . . . . . . 14
8. Informative Normative References . . . . . . . . . . . . . . . . . . . . . . 9 14
9. Intellectual Property Considerations Informative References . . . . . . . . . . . . . . . . . . . .10 . 15
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .11

Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 16

1. Introduction

Voice over IP (VoIP) typically uses the encapsulation
voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes
voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN VPNs (e.g., [RFC2547], [RFC2547]) use label
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
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 compression is to exploit the possibility of significantly
reducing the overhead through various compression mechanisms, such as
with enhanced compressed RTP (ECRTP) [RFC3545] and robust header
compression (ROHC) [RFC3095], and also to increase scalability of
header compression. MPLS is used to route header-compressed (HC)
packets over an MPLS label switched path (LSP) without
compression/decompression cycles at each router. Such an HC over
MPLS capability can increase bandwidth efficiency as well as the
processing scalability of the maximum number of simultaneous
compressed flows that use header compression at each router.

To implement HC over MPLS, after the ingress router would have to apply applies the HC
algorithm to the IP packet, the compressed packet routed is forwarded on an
MPLS LSP using MPLS labels, and the compressed header would be decompressed at then the egress router where restores the HC session terminates.
uncompressed header. Figure 1 illustrates an HC over MPLS session
established on an LSP that crosses traverses several label switch routers,
from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where
performing header compression (HC) is performed, (HC), and R4/HD is the egress router where
performing header decompression (HD) is done. (HD). Compression of the RTP/UDP/IP
header is performed at R1/HC, and the compressed packets are routed
using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD,
without further decompression/recompression cycles. The RTP/UDP/IP
header is decompressed at R4/HD and can be forwarded to other
routers, as needed.

_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| data (e.g. voice)/compressed-header/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| data (e.g. voice)/compressed-header/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| data (e.g. voice)/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|

Figure 1. Example of HC over MPLS over Routers R1 --> R4

In the example scenario, header compression therefore takes place
between R1 and R4, and the MPLS path transports
data/compressed-header/MPLS-labels instead of
data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS
label stack and link-layer headers are not compressed. Therefore HC
over MPLS can significantly reduce the header overhead through
compression mechanisms.

Goals and requirements for header compression over MPLS are discussed in
[MPLS-HC-REQ]. The solution put forth in this document meets these
requirements. In particular, the HC over MPLS solution:

a. uses existing protocols [e.g., ECRTP, ROHC] to compress RTP/UDP/IP
headers,
b. allows HC over an MPLS LSP, and thereby avoids hop-by-hop
compression/decompression cycles,
c. minimizes incremental performance degradation due to increased delay,
packet loss, and jitter, by leveraging a compression scheme [e.g.,
ECRTP] that is less sensitive to delay, packet loss, and jitter, as well
as by eliminating multiple compression/decompression cycles as a source
of performance degradation, over a range of network path
characteristics,
d. uses standard protocols to signal context identification and control
information,
e. packet reordering does not cause incorrectly decompressed packets
to be forwarded from the decompressor.

Section 2 presents the proposed protocol extensions, and Section 3
presents the procedures.

2. Protocol Extensions

MPLS is used to route HC packets over an MPLS LSP without
compression/decompression cycles at each intermediate router. MPLS
pseudowires (PWs) are used to transport the HC context and other control
messages header compressed packets
between the ingress and egress MPLS label switched router (LSR), and
the PWs define a point to point instance of each HC session at the
header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.)
are used to determine the context.

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 bytes in the IP/UDP/RTP headers remain constant over the
life of the connection. After sending the uncompressed header
template once, these fields may be removed from the compressed
headers that follow. The remaining compression comes from the
observation that although several fields change in every packet, the
difference from packet to packet is often constant and therefore the
second-order difference is zero.

By maintaining both the uncompressed header and the first-order
differences in the session state shared between the compressor and
decompressor, all that must be communicated is an indication that the
second-order difference was zero. In that case, the decompressor can
reconstruct the original header without any loss of information
simply by adding the first-order differences to the saved
uncompressed header as each compressed packet is received. The
compressed packet carries the context identification (CID), to
indicate in which session context that packet should be interpreted.
Compressed packets and HC control packets
are data is routed on a separate MPLS LSP/PW, LSP/PW from compressor
to decompressor, where the PW is set up by MPLS PW signaling
[PW-SIG]. The decompressor uses the incoming MPLS PW label Label and the
CID to locate the proper decompression context.

Goals and requirements for header compression over MPLS are discussed
In Figure 1 we assume an example data flow set up from R1/HC --> R2 -->
R3 --> R4/HD, where R1/HC [MPLS-HC-REQ]. The solution put forth in this document has been
Designed to address these goals and requirements.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

Forwarding Equivalence Class (FEC): a group of IP packets which are
forwarded in the same manner (e.g., over the same LSP, with the same
forwarding treatment)

Label: a short fixed length physically contiguous identifier which is
used to identify a FEC, usually of local significance

Label Switched Path (LSP): the ingress router where header compression path through one or more LSRs at one
level of the hierarchy followed by a packets in a particular
forwarding equivalence class (FEC)

Label Switching Router (LSR): an MPLS node which is performed, capable of
forwarding native L3 packets label stack an ordered set of labels

MPLS domain: a contiguous set of nodes which operate MPLS routing
and R4/HD forwarding and which are also in one Routing or Administrative
Domain

MPLS label: a label which is carried in a packet header, and which
represents the egress router where header decompression packet's FEC

MPLS node: a node that is done. Each router functions as an LSR running MPLS. An MPLS node will be aware
of MPLS control protocols, will operate one or more L3 routing
protocols, and supports signaling will be capable of
LSP/PWs. A summary forwarding packets based on labels.

An MPLS node may optionally be also capable of forwarding native L3
packets.

MultiProtocol Label Switching (MPLS): an IETF working group and the flow setup is as follows (ECRTP is assumed in
effort associated with the working group

Packet Switched Network (PSN): Within the context of PWE3, this example):

1. [PW-SIG] is used to create a
network using IP or MPLS as the R1 --> R4 LSP/PW mechanism for packet forwarding.

Protocol Data Unit (PDU): The unit of data output to, or received
from, the network by a protocol layer.

Pseudo Wire (PW): A mechanism that follows R1 -->
R2 --> R3 --> R4.

2. [PW-SIG] is used carries the essential elements of
an emulated service from one provider edge router to create one or more
other provider edge routers over a PSN

Pseudo Wire Emulation Edge to Edge (PWE3): A mechanism that emulates
the R4 --> R1 LSP/PW essential attributes of service (such as a T1 leased line or
Frame Relay) over a PSN

Pseudo Wire PDU (PW-PDU): A PDU sent on the PW that follows R4 -->
R3 --> R2 --> R1.
3. [RFC3544] contains all of
the data and [RFC3409] are used control information necessary to negotiate HC scheme parameters, emulate the desired
service

PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can
be carried

PSN Tunnel Signaling: Used to set up, maintain, and tear down the
underlying PSN tunnel

PW Demultiplexer: Data-plane method of identifying a PW terminating
at a provider edge router

Tunnel: A method of transparently carrying information over a network

3. Header Compression over MPLS Protocol Overview

MPLS is extended in this specification used to negotiating route HC packets over an MPLS
LSP/PW (as specified in Section 3).
4. R1/HC assigns a CID LSP without
compression/decompression cycles at each intermediate router. MPLS
pseudowires (PWs) are used to transport the flow and uses the R1 --> R4 LSP/PW to send
FULL_HEADER packets, header compressed packets, and CONTEXT_STATE packets to
R4/HC, with LSP and PW labels.
5. R4/HD uses
between the incoming ingress and egress MPLS PW label switched router (LSR), and CID
the PWs define a point to locate point instance of each HC session at the proper
decompression context
header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.)
are used to decompress determine the context.

Traditionally, the use of HC over a particular link is a function of
the link-layer protocol, PPP, HDLC, FR, etc. Native procedures could
be used to carry compressed packets sent by
R1/HC.
6. R4/HC uses over a PW. That is, the CID assigned by R1/HC and
link-layer protocol could be emulated over the R4 --> R1 LSP/PW PW, which would then
behave like a serial link running encapsulated link-layer PDUs across
the MPLS network. The drawback of this approach is that the
compressed packet needs to send
FULL_HEADER packets, be carried in a layer-2 PDU, which
requires extra overhead.

Alternatively, compressed packets, and CONTEXT_STATE packets to
R1/HD, with LSP are directly encapsulated over a
PW, and are routed across the MPLS network using MPLS labels, which
include the packet switched network (PSN) label and PW labels.
7. if needed to resync, R4/HD sends label. In
this approach, a CONTEXT_STATE packet PW control word is used to R1/HC;
R1/HC resends identify the FULL_HEADER packet to R4/HD.
8. if needed to resync, R1/HD sends type of
packet, a CONTEXT_STATE packet unique PW Type is defined for each HC scheme, and, as
normal, a context identification (CID) is used to R4/HC;
R4/HC resends the FULL_HEADER identify each
compressed packet to R1/HD.
9. R1/HC context and payload. Each HC scheme is applied
directly over its own PW type, and R4/HD free up the CID when the flow terminates.

2.1 MPLS Pseudowire Establishment & Processing principles of HC-over-PPP
[RFC3241, RFC3544] are re-used. This more efficient approach is
taken in this document, and is now summarized.

An MPLS pseudowire (PW) PW allows protocol data units for various link-layer
protocols to be encapsulated and carried over an MPLS network. The
PW is set up by a PW signaling protocol [PW-SIG]. [PW-SIG], and the Interface
Parameters Sub-TLV [IANA, PW-SIG] is used to convey HC configuration
information including HC session setup and HC parameter negotiation.
Mechanisms and principles for HC session setup and HC parameter
negotiation, as described for HC-over-PPP mechanisms [RFC3241,
RFC3544], are reused to enable HC session configuration.

MPLS PWs directly encapsulate compressed packets and HC control
packets, etc., for each HC scheme as identified by the PW type.
Mechanisms and principles described in each HC scheme: cTCP
[RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP
[RFC3545], are then directly reused to enable compressed packet
transport.

3.1 PW Setup & HC Session Configuration

From the signaling procedures from [PW-SIG], a PW is established
between the header compressor (HC) and header decompressor (HD) for
the transport of the media stream between the HC and HD endpoints.
Figure 2 illustrates header-compressed /RTP/UDP/IP packets carried over a PW
through an MPLS LSP tunnel. The 'PW label' is used as the
demultiplexer field by the HD, where the PW label appears at the
bottom of an MPLS label stack.

|<------- Pseudowire -------->|
| |
| |<-- MPLS Tunnel -->| |
V V V V
+----+ +----+
| HC |===================| HD |
|............PW...............|
| |===================| |
+----+ +----+

Figure 2: Pseudowire (PW) Reference Configuration

PWs are set up for the transport of media streams based on [PW-SIG]
control messages exchanged by the endpoints. PWs for media streams
are established at the edges of the MPLS network. Furthermore, a PW
type indicates the HC scheme being used on the PW, as specified in
[IANA].

The PW HC approach in this document relies on the PW/MPLS layer to
convey HC session configuration information. As detailed in Section
4.1, the Interface Parameters Sub-TLV [IANA, PW-SIG] is used to
signal HC session setup and HC parameter negotiation, such as
described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The
principles and IPCP messages described in [RFC3241, RFC3544] are
reused to enable PW/MPLS HC session configuration, as the PPP layer
does for each of the HC mechanisms.

3.2 HC over MPLS

Since a PW in an MPLS network looks similar to a point-to-point link,
the same HC approaches used on point-to-point links may be used in
PW-MPLS networks, for example, when shipping IP/UDP/RTP traffic over
MPLS PWs. Existing HC algorithms are re-used, as specified in cTCP
[RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP
[RFC3545], to maintain contexts as per each HC scheme and route each
stream over the appropriate PW. This section describes how to carry
HC packets in a PW-MPLS network for real-time media streams.

Figure 3 shows the HC over MPLS protocol stack. The uncompressed
stack would be:

Media stream
RTP
UDP
IP
PW control octet
MPLS label stack (at least 2 labels for this application)
Link layer under MPLS (PPP, PoS, Ethernet)
Physical layer (SONET/SDH, fiber, copper)

Then we do compression on the IP/UDP/RTP headers before transmission,
leaving the rest of the stack alone, as shown in Figure 3:

+--------------+
| Media stream |
+--------------+
\_______ ______/
2-4 octets V
+------+--------------+
Compressed /RTP/UDP/IP/ |header| |
+------+--------------+
\__________ __________/
1 octet V
+------+---------------------+
PW Control Octet |header| |
+------+---------------------+
\______________ _____________/
8 octets V
+------+----------------------------+
MPLS Labels |header| |
+------+----------------------------+
\_________________ _________________/
V
+------+-----------------------------------+
Link Layer under MPLS |header| |
+------+-----------------------------------+
\____________________ _____________________/
V
+------+------------------------------------------+
Physical Layer |header| |
+------+------------------------------------------+

Figure 3 - Header Compression over MPLS Media Stream Transport

The PW control octet is used to identify the packet types for certain
HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508],
and ECRTP [RFC3545], as detailed in Section 4.2. Note that ROHC
[RFC3095] provides its own packet type within the protocol, and does
not require use of the PW control octet. We illustrate formats of
the FULL_HEADER and CONTEXT_STATE packets in Section 4.2, Figures 6
and 7, respectively. The formats of other HC-control packets are
similarly encapsulated, and the PW control octet is set to the
appropriate value indicating the packet format.

4. Protocol Specifications

4.1 MPLS Pseudowire & Header Compression Scheme
Setup/Negotiation/Signaling

From the signaling procedures from [PW-SIG], a PW is established
between the header compressor (HC) and header decompressor (HD) for
the transport of the media stream between the HC and HD endpoints.

Figure 2 illustrates header-compressed packets carried over a PW
through an MPLS LSP tunnel. The 'PW label' is used as the
demultiplexer field by the HD, where the PW label appears at the
bottom label of an MPLS label stack. See [PW-SIG] for an explanation
of PW signaling, and [PW-HDLC-PPP] for a PW type that can be modeled
for the application in this document.

In Figure 2, many simultaneous compressed flows (could be 100's or
1000's) need to be established between HC and HD. These multiple
simultaneous compressed flows are carried on one HC-HD PW, and HD
uses the CID to identify the compressed flow-context and the PW
(inner) label to identify the HC source. That is, each HC-HD
compressed session would be identified by the PW label. The CIDs are
assigned by the HC as normal, and there would be no problem if
duplicate CIDs are received at the HD for different compressed
sessions. For example, if HC-a and HC-b assign the same CID to a
flow, the each PW had a logically separate HD can distinguish these since it
knows the source by means instance, in this case,
HD-a and HD-b, independent of the PW label. all other PWs. That is, HD has HD-a and HD-b
have a separate decompression context for the two flows based on the
PW label and CID mapping.

It is also possible for multiple PWs to be established in case different
Different QoS requirements are needed for different compressed
streams. The QoS received by the flow would be determined by the EXP
bit marking in the PW label. Normally, all the RTP packets would get
the same EXP marking, equivalent to EF treatment in DiffServ.
However, the protocol specified in this document applies to other
than RTP streams, and QoS treatment other than EF may be required for
those streams.

This document requires

PWs are set up for the transport of media streams based on [PW-SIG]
control messages exchanged by the endpoints. PWs for media streams
are established at the allocation edges of the MPLS network. Furthermore, a new PW
type to support indicates the HC scheme being used on the PW [IANA], as follows:

0x001B cTCP [RFC1144] Transport Header-compressed Packets
0x001C IPHC [RFC2507] Transport Header-compressed Packets
0x001D cRTP [RFC2508] Transport Header-compressed Packets
0x001E ROHC [RFC3095] Transport Header-compressed Packets
0x001F ECRTP [RFC3545] Transport Header-compressed Packets

In Figure 1 we assume an example data flow set up from R1/HC -->
R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header
Compression is performed, and R4/HD is the egress router where header
Decompression is done. Each router functions as an LSR and supports
signaling defined of LSP/PWs. A summary of the procedures is as follows:

1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows
R1 --> R2 --> R3 --> R4.
2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows
R4 --> R3 --> R2 --> R1.

3. [RFC3544] and [RFC3241] are used to negotiate HC scheme
parameters, which is extended in this specification to negotiating
during PW setup, as specified in Section 5.1 of [PW-SIG]. 4.1.
4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to
send HC scheme control packets and compressed packets to R4/HC, with
LSP and PW labels.
5. R4/HD uses the incoming MPLS PW label and CID to locate the proper
decompression context to decompress the compressed packets sent by
R1/HC.
6. R4/HC assigns a CID to the flow and uses the R4 --> R1 LSP/PW to
send HC scheme control packets and compressed packets to R1/HD, with
LSP and PW labels.
7. R1/HD uses the incoming MPLS PW label and CID to locate the proper
decompression context to decompress the compressed packets sent by
R4/HC.
8. if needed to resync, R4/HD sends an appropriate HC scheme control
packet to R1/HC; R1/HC resends the appropriate HC scheme control
packet to R4/HD.
9. if needed to resync, R1/HD sends an appropriate HC scheme control
packet to R4/HC; R4/HC resends the HC scheme control packet to R1/HD.
10. Existing HC scheme procedures are used to assign and free up the
CIDs; see, for example, Section 7 in [ROHC-IMPL-GUIDE].

The PW type HC approach in this document relies on the PW/MPLS layer to
convey HC session configuration information. The Interface
Parameters Sub-TLV [IANA, PW-SIG], illustrated in Figure 4, is a 15-bit used
to signal HC session setup and HC parameter assigned by IANA, negotiation, such as specified
described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The
principles and IPCP messages described in [RFC3241, RFC3544] are
reused to enable PW/MPLS HC session configuration, as the [IANA] registry. The C
bit PPP layer
does for each of the HC mechanisms. This sub-TLV specifies interface
specific parameters, and is set equal used to configure the HC and HD ports at
the edges of the PW, have the necessary capabilities to interoperate
with each other.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4 - PW Interface Parameters Sub-TLV

The interface parameter sub-TLV type values are specified in [IANA].
Type values are specified for both the network control protocol for
IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. IPCP and
IPV6CP TLVs may then be encapsulated in the PW Interface Parameters
Sub-TLV and used to negotiate HC parameters for their respective
protocols. The IPCP and IPV6CP TLVs supported in this signaling.

2.2 Link Layer Packet Type Field manner include
the following:

o Configuration Option Format, RTP-Compression Suboption, Enhanced
RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as
specified in [RFC3544]
o Configuration Option Format, PROFILES Suboption, as specified in
[RFC3241]

4.2 Encapsulation of Header Compressed Packets

Since it is necessary a PW in an MPLS network looks similar to identify packet types for a point-to-point link,
the same HC approaches used on point-to-point links may be used in
PW-MPLS networks, for example, when transmitting IP/UDP/RTP traffic
over MPLS (e.g., PWs. Existing HC control packets, compressed packets, etc.), a 4-bit packet type field
is defined algorithms are re-used, as specified in
cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and
ECRTP [RFC3545], to maintain contexts as per each HC scheme and route
each stream over the layer 2 header appropriate PW. This section describes how to encode
carry HC packets in a PW-MPLS network for real-time media streams.

Figure 3 shows the different packet types.
Each HC over MPLS packet MUST have prepended to it a packet type field,
which adds 1 protocol stack. The PW control octet
is used to identify the layer-2 header, packet types for certain HC schemes,
including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and is encoded as follows (see
[RFC3544], ECRTP
[RFC3545], [RFC3095], [IPCP]): as shown in Figure 5:

0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|0 0 0 0|Pkt Typ|
+-+-+-+-+-+-+-+-+

Figure 5 - PW Control Octet

where:

CID_Packet_Type designation:
0000 (first nibble)

"Packet Type" encoding:
0: Reserved
1: FULL_HEADER
2: COMPRESSED_TCP
3: COMPRESSED_TCP_NODELTA
4: COMPRESSED_NON_TCP
5: COMPRESSED_RTP_8
6: COMPRESSED_RTP_16
7: COMPRESSED_UDP_8
8: COMPRESSED_UDP_16
9: CONTEXT_STATE
10: ROHC
11: IPCP
12-15: RESERVED
10-15: MUST NOT BE ASSIGNED

As discussed in [ECMP-AVOID], since this MPLS payload type in is not IP,
the first nibble is set to 0000 to avoid being mistaken for IP. This
is also consistent with the proposed encoding of the PWE3 control
word
[PWE3-CNTL-WORD].

3. HC over MPLS Procedures

The MPLS control plane establishes LSPs, PWs, and label bindings between
each HC-HD pair. Compressed packets [PW-CNTL-WORD].

Note that ROHC [RFC3095] provides its own packet type within the
protocol, and HC does not require use of the PW control packets are routed
on LSP/PWs, which octet. We
illustrate the exchange of packet formats for the case of [RFC2508],
the other HC approaches are set up as described similar.

FULL_HEADER - communicates a full IP/UDP/RTP header to establish or
synchronize the state in Section 2.1.

[RFC3544] and [RFC3409] are used the de-compressor for a call context.
Similar to negotiate IP/UDP/RTP HC scheme parameters.
These RFCs are oriented toward negotiating over a single PPP link, which
is extended in this specification to negotiating links [RFC2508], HC over an MPLS LSP/PW.
[RFC3544] uses PWs
requires a CID. Namely, the IP control protocol (IPCP) [RFC1332] HC/HDs on both ends need to
signal/negotiate HC parameters. For HC over MPLS, objects MUST be sent
between maintain
context for many IP flows traversing the HC same link and HD over the MPLS LSP/PW, in which the IPCP packets CIDs are identified, as specified
used to determine the context in Section 2.2. For example, which a packet has to enable
ECRTP [RFC3545], sub-option 2 is negotiated, this object MUST be considered.

CONTEXT_STATE - is a special packet sent
between from the HC and HD over to the MPLS LSP/PW:

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=2 | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For HC over MPLS, the compressor and decompressor follow
indicating that the procedures
in context associated with the HC protocol, as specified in [RFC2507] for IP header compression
(IPHC), [RFC2508] for compressed RTP (CRTP), [RFC3545] for ECRTP, and
[RFC3095] for ROHC. flow may have been
invalidated. The HC source node compresses the header by
removing the header and forming the compressed header, which compressor is
prepended expected to send the remainder of the next packet as a
FULL_HEADER packet. The CID and

We now illustrate the MPLS header
are then prepended and formats of the FULL_HEADER and CONTEXT_STATE
packets.

4.2.1 FULL_HEADER Packet Format

The format of a FULL_HEADER packet is sent. The HD destination node
removes illustrated in Figure 6, where
the MPLS PW label and the compressed header. The node prepends
the header template control octet is set to the '00000001' indicating a FULL_HEADER
packet and then uses the operands to populate
the variable fields format.

PW Control Octet
\_____ ________/
V
+----------+--------------------+--------------+
| 00000001 | /RTP/UDP/IP Header | Data |
+----------+--------------------+--------------+
\______________________ _______________________/
V
+----------------+----------------------------------------------+
| MPLS/PW Labels | MPLS-PDU |
+----------------+----------------------------------------------+

Figure 6 - FULL_HEADER Packet

4.2.2 CONTEXT_STATE Packet Format

The format of the header with the values sent a CONTEXT_STATE packet is illustrated in Figure 7,
where the compressed
header. PW control octet is set to '00001001' indicating a
CONTEXT_STATE packet format.

PW Control Octet
\_____ ________/
V
+----------+--------------------+--------------+
| 00001001 | /RTP/UDP/IP Header | Data |
+----------+--------------------+--------------+
\______________________ _______________________/
V
+----------------+----------------------------------------------+
| MPLS/PW Labels | MPLS-PDU |
+----------------+----------------------------------------------+

Figure 7 - CONTEXT_STATE Packet

The compressor formats of other HC-control packets are similarly encapsulated,
and decompressor follow the procedures in PW control octet is set to the
applicable RFC, including appropriate value indicating
the sending of control packets, compressed
packets, etc. packet format.

Packet reordering for ROHC and ECRTP are discussed in [ROHC-REORDER]
and [ECRTP-REORDER], which are a useful source of information. An
evaluation and simulation of ECRTP and ROHC reordering is given in
[REORDER-EVAL].

5. Security Considerations

MPLS pseudowire security considerations in general are discussed in
[RFC3985] and [PW-SIG], and those considerations also apply to this
document. This document specifies an encapsulation and 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 herein.

6. Acknowledgements

Thanks to

The authors appreciate valuable inputs and suggestions from Loa
Andersson, Stewart Bryant, Adrian Farrel, Victoria Fineberg, Colin
Perkins, George Swallow, and Curtis Villamizar for
helpful suggestions.

6. Villamizar, and Magnus Westerlund.

7. IANA Considerations

As discussed in Section 2.1, a 4.1, new PW types needs to be type values are assigned in
[IANA] for HC over MPLS LSP/PWs.

7. As discussed in Section 4.1,
interface parameter sub-TLV type values are specified in [IANA] for
both the network control protocol for IPv4, IPCP [RFC1332] and the
IPv6 NCP, IPV6CP [RFC2472].

8. Normative References

[MPLS-HC-REQ]

[IANA] Martini, L., et. al., "IANA Allocations for Pseudo Wire Edge
To Edge Emulation (PWE3)," work in progress.

[MPLS-HC-REQS] Ash, G., Goode, B., Hand, J., "Requirements for Header
Compression over MPLS", work in progress.

[IANA]

[PW-PPP] Martini, L., et. al., "IANA Allocations "Encapsulation Methods for pseudo Wire Edge to
Edge Emulation (PWE3)," Transport
of PPP/HDLC Over IP and MPLS Networks," work in progress.

[PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance
Using LDP," work in progress.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP,"
RFC 3241, April 2002.

[RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression
over PPP", RFC 3544, July 2003.

9. Informative References

[ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath
Treatment in MPLS Networks," work in progress.

[ECRTP-REORDER] Koren, T., et. al., "Packet reordering in Extended
CRTP (ECRTP)," work in progress.

[PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over
an MPLS PSN," work in progress.

[PW-PPP] Martini, L., et. al., "Encapsulation Methods for Transport of
PPP/HDLC Over IP and MPLS Networks," work in progress.

[PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance using
LDP," work in progress.

[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
http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf.

[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)," May 1992.

[RFC1661] Simpson, W., et. al., "The Point-to-Point Protocol (PPP)," RFC
1661, July 1994.

[RFC2021] Rosen, E., et. al., "Multiprotocol Label Switching
Architecture," RFC 3031, January 2001.

[RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507,
February 1999.

[RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.

[RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
1999.

[RFC3032] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032,
January 2001.

[RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC
3095, July 2001.

[RFC3409] Svanbro, K., "Lower Layer Guidelines for Robust RTP/UDP/IP
Header Compression," December 2002.

[RFC3544] Engan, M., Casner, S., Bormann, C., "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.

[RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture," RFC 3985, March 2005.

[ROHC-IMPL-GUIDE] Jonsson, L-E., Kremer, P. "ROHC Implementer's
Guide," work in progress.

[ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression
(ROHC): ROHC over Channels that can Reorder Packets," work in
progress.

10. Authors' Addresses

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
Email: gash@att.com

Bur Goode
AT&T
Phone: +1 203-341-8705
Email: bgoode@att.com

Jim Hand
Consultant
Phone : +1 732-532-3020
Email: James.Hand@mail1.monmouth.army.mil

Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com

Andrew G. Malis
Tellabs
90 Rio Robles Dr.
San Jose, CA 95134
Email: Andy.Malis@tellabs.com

Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: zhangr@bt.infonet.com

Intellectual Property Considerations Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

10. Authors' Addresses

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
Email: gash@att.com

Bur Goode
AT&T
Phone: +1 203-341-8705
Email: bgoode@att.com

Jim Hand
Consultant
Phone : +1 732-532-3020
Email: James.Hand@mail1.monmouth.army.mil

Andrew G. Malis
Tellabs
90 Rio Robles Dr.
San Jose, CA 95134
Email: Andy.Malis@tellabs.com

Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: zhangr@sa.infonet.com

Full Copyright Statement

Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except as
set forth therein, the authors retain all their rights.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Disclaimer of Validity

Copyright (C) The Internet Society (2005). This document and is subject
to the information rights, licenses and restrictions contained herein are provided on an
"AS IS" basis in BCP 78, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
except as set forth therein, the authors retain all their rights.