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

                                                           April, 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 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.

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

Copyright Notice

Copyright (C) The Internet Society (2005). All Rights Reserved.


Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 1]


Internet Draft     Header Compression over MPLS Protocol      April 2005


Abstract

VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels
are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN,
the packet header is at least 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.1 MPLS Pseudowire Establishment & Processing  . . . . . . . . . . 6
   2.2 Link Layer Packet Type Field  . . . . . . . . . . . . . . . . . 7
3. HC over MPLS Procedures . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Normative References  . . . . . . . . . . . . . . . . . . . . . . . 9
8. Informative References  . . . . . . . . . . . . . . . . . . . . . . 9
9. Intellectual Property Considerations  . . . . . . . . . . . . . . .10
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].


Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 2]


Internet Draft     Header Compression over MPLS Protocol      April 2005


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 (e.g., [RFC2547], the
packet header is at least 48 bytes, while the voice payload is often no
more than 30 bytes, for example.  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, the ingress router would have to apply the HC
algorithm to the IP packet, the compressed packet routed on an MPLS LSP
using MPLS labels, and the compressed header would be decompressed at
the egress router where the HC session terminates.  Figure 1 illustrates
an HC over MPLS session established on an LSP that crosses several
routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress
router where header compression (HC) is performed, and R4/HD is the
egress router where header decompression (HD) is done.  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.


Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 3]


Internet Draft     Header Compression over MPLS Protocol      April 2005


                    _____
                   |     |
                   |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,

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 4]


Internet Draft     Header Compression over MPLS Protocol      April 2005


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 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 routed on a separate MPLS LSP/PW, where the PW is set up by MPLS PW
signaling [PW-SIG].  The decompressor uses the incoming MPLS PW label
and the CID to locate the proper decompression context.

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 of
LSP/PWs.  A summary of the flow setup is as follows (ECRTP is assumed in
this example):

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

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 5]


Internet Draft     Header Compression over MPLS Protocol      April 2005


2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows R4 -->
R3 --> R2 --> R1.
3. [RFC3544] and [RFC3409] are used to negotiate HC scheme parameters,
which is extended in this specification to negotiating over an MPLS
LSP/PW (as specified in Section 3).
4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to send
FULL_HEADER packets, compressed packets, and CONTEXT_STATE 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 uses the CID assigned by R1/HC and the R4 --> R1 LSP/PW to send
FULL_HEADER packets, compressed packets, and CONTEXT_STATE packets to
R1/HD, with LSP and PW labels.
7. if needed to resync, R4/HD sends a CONTEXT_STATE packet to R1/HC;
R1/HC resends the FULL_HEADER packet to R4/HD.
8. if needed to resync, R1/HD sends a CONTEXT_STATE packet to R4/HC;
R4/HC resends the FULL_HEADER packet to R1/HD.
9. R1/HC and R4/HD free up the CID when the flow terminates.

2.1 MPLS Pseudowire Establishment & Processing

An MPLS pseudowire (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].  Figure
2 illustrates header-compressed /RTP/UDP/IP carried over a PW through

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

      Figure 2: Pseudowire (PW) Reference Configuration

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

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 6]


Internet Draft     Header Compression over MPLS Protocol      April 2005


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 HD can distinguish these since it
knows the source by means of the PW label.  That is, HD has 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
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 the allocation of a new PW type to support the PW
signaling defined in Section 5.1 of [PW-SIG].  The PW type is a 15-bit
parameter assigned by IANA, as specified in the [IANA] registry.  The C
bit is set equal to 1 for this signaling.

2.2 Link Layer Packet Type Field

Since it is necessary to identify packet types for HC over MPLS (e.g.,
HC control packets, compressed packets, etc.), a 4-bit packet type field
is defined in the layer 2 header to encode the different packet types.
Each HC over MPLS packet MUST have prepended to it a packet type field,
which adds 1 octet to the layer-2 header, and is encoded as follows (see
[RFC3544], [RFC3545], [RFC3095], [IPCP]):

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

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

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 7]


Internet Draft     Header Compression over MPLS Protocol      April 2005


11: IPCP
12-15: RESERVED

As discussed in [ECMP-AVOID], since this MPLS payload type in 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 and HC control packets are routed
on LSP/PWs, which are set up as described in Section 2.1.

[RFC3544] and [RFC3409] are used to negotiate HC scheme parameters.
These RFCs are oriented toward negotiating over a single PPP link, which
is extended in this specification to negotiating over an MPLS LSP/PW.
[RFC3544] uses the IP control protocol (IPCP) [RFC1332] to
signal/negotiate HC parameters.  For HC over MPLS, objects MUST be sent
between the HC and HD over the MPLS LSP/PW, in which the IPCP packets
are identified, as specified in Section 2.2.  For example, to enable
ECRTP [RFC3545], sub-option 2 is negotiated, this object MUST be sent
between the HC and HD over 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 the procedures
in the HC protocol, as specified in [RFC2507] for IP header compression
(IPHC), [RFC2508] for compressed RTP (CRTP), [RFC3545] for ECRTP, and
[RFC3095] for ROHC.  The HC source node compresses the header by
removing the header and forming the compressed header, which is
prepended to the remainder of the packet.  The CID and the MPLS header
are then prepended and the packet is sent.  The HD destination node
removes the MPLS PW label and the compressed header.  The node prepends
the header template to the packet and then uses the operands to populate
the variable fields of the header with the values sent in the compressed
header.  The compressor and decompressor follow the procedures in the
applicable RFC, including the sending of control packets, compressed
packets, etc.

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].


Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 8]


Internet Draft     Header Compression over MPLS Protocol      April 2005


4. 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.

5. Acknowledgements

Thanks to Stewart Bryant, George Swallow, and Curtis Villamizar for
helpful suggestions.

6. IANA Considerations

As discussed in Section 2.1, a new PW types needs to be assigned for HC
over MPLS LSP/PWs.

7. Normative References

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

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

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

8. 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

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>     [Page 9]


Internet Draft     Header Compression over MPLS Protocol      April 2005



[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-REORDER] Pellitier, G., et. al., "RObust Header Compression
(ROHC): ROHC over Channels that can Reorder Packets," work in progress.

9. Intellectual Property Considerations

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.

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>    [Page 10]


Internet Draft     Header Compression over MPLS Protocol      April 2005



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.


Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>    [Page 11]


Internet Draft     Header Compression over MPLS Protocol      April 2005


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

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.

Ash, et. al.  <draft-ash--avt-hc-over-mpls-protocol-00.txt>    [Page 12]