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

                                                       September, 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/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 March 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 1]


Internet Draft    Header Compression over MPLS Protocol   September 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 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 one or more point-to-point
   instances corresponding to 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. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3. Header Compression over MPLS Protocol Overview . . . . . . . . 6
      3.1 PW Setup & HC Session Configuration  . . . . . . . . . . . 7
      3.2 HC over MPLS . . . . . . . . . . . . . . . . . . . . . . . 8
   4. Protocol Specifications  . . . . . . . . . . . . . . . . . . . 10
      4.1 MPLS Pseudowire & Header Compression Scheme
          Setup/Negotiation/Signaling  . . . . . . . . . . . . . . . 10
      4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12
          4.2.1 FULL_HEADER Packet Format  . . . . . . . . . . . . . 14
          4.2.2 CONTEXT_STATE Packet Format  . . . . . . . . . . . . 14
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8. Normative References . . . . . . . . . . . . . . . . . . . . . 16
   9. Informative References . . . . . . . . . . . . . . . . . . . . 16
   10. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 17


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 2]


Internet Draft    Header Compression over MPLS Protocol   September 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.  MPLS VPNs (e.g., [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 applies the HC
   algorithm to the IP packet, the compressed packet is forwarded on an
   MPLS LSP using MPLS labels, and then the egress router restores the
   uncompressed header.  Figure 1 illustrates an HC over MPLS session
   established on an LSP that traverses several label switch routers,
   from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router
   performing header compression (HC), and R4/HD is the egress router
   performing header decompression (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.


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 3]


Internet Draft    Header Compression over MPLS Protocol   September 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 in the
   /RTP/UDP/IP/ header.  Typically there are two MPLS labels (8 octets)
   and a link-layer (pseudowire) control octet.  The MPLS label stack
   and link-layer headers are not compressed.  Therefore HC over MPLS
   can significantly reduce the header overhead through compression
   mechanisms.

   MPLS is used to route HC packets over an MPLS LSP without
   compression/decompression cycles at each intermediate router.  MPLS
   pseudowires (PWs) [RFC3985] are used to transport the header
   compressed packets between the ingress and egress MPLS label switched
   router (LSR), and the PWs define one or more point-to-point instances
   corresponding to 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

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 4]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   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 data is routed on a separate MPLS 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 and the
   CID to locate the proper decompression context.

   Goals and requirements for header compression over MPLS are discussed
   In [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 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 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 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 packet's FEC


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 5]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   MPLS node: a node that is running MPLS.  An MPLS node will be aware
   of MPLS control protocols, will operate one or more L3 routing
   protocols, and will be capable of forwarding packets based on labels.
   An MPLS node may optionally be also capable of forwarding native L3
   packets.

   Multi Protocol Label Switching (MPLS): an IETF working group and the
   effort associated with the working group

   Packet Switched Network (PSN): Within the context of PWE3, this is a
   network using IP or MPLS as the mechanism for packet forwarding.

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

   Pseudo Wire (PW): A mechanism that carries the essential elements of
   an emulated service from one provider edge router to one or more
   other provider edge routers over a PSN

   Pseudo Wire Emulation Edge to Edge (PWE3): A mechanism that emulates
   the 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 contains all of
   the data and control information necessary to 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 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 header compressed packets
   between the ingress and egress MPLS label switched router (LSR), and
   the PWs define one or more point-to-point instances corresponding to
   each HC session at the header decompressor.  Standard HC methods
   (e.g., ECRTP, ROHC, etc.) are used to 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 over a PW.  That is, the

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 6]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   link-layer protocol could be emulated over the 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 be carried in a layer-2 PDU, which
   requires extra overhead.

   Alternatively, compressed packets 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 label.  In
   this approach, a PW control word is used to identify the type of
   packet, a unique PW Type is defined for each HC scheme, and, as
   normal, a context identification (CID) is used to identify each
   compressed packet context and payload.  Each HC scheme is applied
   directly over its own PW type, and the 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 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], 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 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.


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 7]


Internet Draft    Header Compression over MPLS Protocol   September 2005


                     |<------- 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)


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 8]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   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, the first nibble of
   the PW control octet is set to 0000 to avoid being mistaken for IP,
   as discussed in [ECMP-AVOID] and [PW-CNTL-WORD].  Note that ROHC
   [RFC3095] provides its own packet type within the protocol, and does
   not require use of the PW control octet.  Note also that the MPLS
   labels technically define two layers: the PW identifier and the MPLS
   tunnel identifier.  There can also be other MPLS labels, for example,
   to identify an MPLS VPN.

   We illustrate formats of the FULL_HEADER and CONTEXT_STATE packets in
   Section 4.2, Figures 5 and 6, 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.


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>         [Page 9]


Internet Draft    Header Compression over MPLS Protocol   September 2005


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 HCa and HCb assign the same CID to a
   flow, each PW had a logically separate HD instance, in this case,
   defined by the <PWlabel-HCa, CID> <PWlabel-HCb, CID> tuples,
   independent of all other PWs.  That is, HCa and HCb have a separate
   decompression context for the two flows based on the PW label and CID
   mapping.

   Note that a single PW label is used for many HC flows rather than
   assigning a different PW label to each flow.  The latter approach
   would involve a complex mechanism for PW label assignment, freeing
   up of labels after a flow terminates, etc., for potentially 1000's of
   simultaneous HC flows.  On the other hand, the mechanism for CID
   assignment, freeing up, etc. is well in place and there is no need to
   duplicate it with PW assignment/deassignment for individual HC flows.

   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.

   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 [IANA], as follows:

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 10]


Internet Draft    Header Compression over MPLS Protocol   September 2005



   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 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 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 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] 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.  This sub-TLV specifies interface specific parameters,
   and is used to configure the HC and HD ports at the edges of the PW,
   have the necessary capabilities to interoperate with each other.


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 11]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   Pseudowire Interface Parameter Sub-TLV type values are specified in
   [IANA].  Type values need to be specified for both the network
   control protocol (NCP) for IPv4, IPCP [RFC1332] and the IPv6 NCP,
   IPV6CP [RFC2472].  Therefore two code-points are requested, one for
   IPCP and one for IPV6CP, as follows:

   0x??        Length TBD       IPCP [RFC1332]
   0x??        Length TBD       IPV6CP [RFC2472]

   IPCP and IPV6CP TLVs identified in [RFC3251] and [RFC3544] may then
   be encapsulated in the PW Interface Parameters Sub-TLV and used to
   negotiate header compression session setup and parameter negotiation
   for their respective protocols.  The IPCP and IPV6CP TLVs supported
   in this 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]

   For example, in [RFC3544] the RTP sub-options (Section 2.2) and ECRTP
   sub-options (Section 2.3) are encoded within the NCP format specified
   in Section 2.1:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |    IP-Compression-Protocol    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           TCP_SPACE           |         NON_TCP_SPACE         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         F_MAX_PERIOD          |          F_MAX_TIME           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           MAX_HEADER          |          suboptions...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A fixed length (TBD) will be specified for each of the two Pseudowire
   Interface Parameter Sub-TLV type values using the maximum length
   across all the sub-options identified in [RFC3251] and [RFC3544].
   Blank bytes will be used in the encoding of each sub-option, as
   needed.

   HC flow identification is being done now in many ways.  Since there
   are multiple possible approaches to the problem, no specific method
   is specified in this document.

   4.2 Encapsulation of Header Compressed Packets

   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

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 12]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   PW-MPLS networks, for example, when transmitting 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 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 shown in Figure 4:


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

                       Figure 4 - PW Control Octet

   where:

   "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-15: TO BE ASSIGNED BY IANA (see Section 7, IANA considerations,
          for discussion of the Registry)

   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
   is also consistent with the encoding of the PWE3 control word
   [PW-CNTL-WORD].

   Note that ROHC [RFC3095] provides its own packet type within the
   protocol, and does not require use of the PW control octet.  We
   illustrate the exchange of packet formats for the case of [RFC2508],
   the other HC approaches are similar.

   FULL_HEADER - communicates a full IP/UDP/RTP header to establish or
   synchronize the state in the de-compressor for a call context.
   Similar to IP/UDP/RTP HC over PPP links [RFC2508], HC over MPLS PWs
   requires a CID.  Namely, the HC/HDs on both ends need to maintain
   context for many IP flows traversing the same link and the CIDs are

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 13]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   used to determine the context in which a packet has to be considered.

   CONTEXT_STATE - is a special packet sent from the HD to the HC
   indicating that the context associated with the flow may have been
   invalidated. The compressor is expected to send the next packet as a
   FULL_HEADER packet.

   We now illustrate the formats of the FULL_HEADER and CONTEXT_STATE
   packets.

4.2.1 FULL_HEADER Packet Format

   The format of a FULL_HEADER packet is illustrated in Figure 5, where
   the PW control octet is set to '00000001' indicating a FULL_HEADER
   packet format.

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

                  Figure 5 - FULL_HEADER Packet

4.2.2 CONTEXT_STATE Packet Format

   The format of a CONTEXT_STATE packet is illustrated in Figure 6,
   where the 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 6 - CONTEXT_STATE Packet

   The formats of other HC-control packets are similarly encapsulated,

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 14]


Internet Draft    Header Compression over MPLS Protocol   September 2005


   and the PW control octet is set to the appropriate value indicating
   the 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

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

7. IANA Considerations

   As discussed in Section 4.1, PW type values have been assigned in
   [IANA] for HC over MPLS LSP/PWs. No further action is required by
   IANA.

   As discussed in Section 4.1, Pseudowire Interface Parameter Sub-TLV
   type values need to be specified by IANA for both the network control
   protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472],
   as follows:

      0x??        Length TBD         IPCP [RFC1332]
      0x??        Length TBD         IPV6CP [RFC2472]

   A fixed length (TBD) will be specified for each of the two Pseudowire
   Interface Parameter Sub-TLV type values using the maximum length
   across all the sub-options identified in [RFC3251] and [RFC3544].
   Blank bytes will be used in the encoding of each sub-option, as
   needed.

   As discussed in Section 4.2, IANA needs to define a new registry,
   "Header Compression Over MPLS PW Control Octet Packet Type".  This is
   a four bit value.  Packet Types 0 through 9 are defined in Section
   4.2 of this document.  Packet Types 10 to 15 are to be assigned by
   IANA using the "Expert Review" policy defined in [RFC2434].


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 15]


Internet Draft    Header Compression over MPLS Protocol   September 2005


8. Normative References

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

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

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   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.

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

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

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.

   [REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header
   Compression Algorithm ECRTP,"
   http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf.

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

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


Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 16]


Internet Draft    Header Compression over MPLS Protocol   September 2005


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

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

   [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
   AT&T
   Room MT A2-4F36
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1 732-420-6179
   Email: jameshand@att.com

   Lars-Erik Jonsson
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

Ash, et. al.       <draft-ietf-avt-hc-over-mpls-01.txt>        [Page 17]


Internet Draft    Header Compression over MPLS Protocol   September 2005


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

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-ietf-avt-hc-over-mpls-01.txt>        [Page 18]


Internet Draft    Header Compression over MPLS Protocol   September 2005


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-ietf-avt-hc-over-mpls-01.txt>        [Page 19]