[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-avt-hc-over-mpls-protocol

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

                                                            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 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 November 26, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


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


Internet Draft     Header Compression over MPLS Protocol       July 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 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. 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  . . . . . . . . . . . . . . . . . . . 9
      4.1 MPLS Pseudowire & Header Compression Scheme
          Setup/Negotiation/Signaling  . . . . . . . . . . . . . . . 9
      4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12
          4.2.1 FULL_HEADER Packet Format  . . . . . . . . . . . . . 13
          4.2.2 CONTEXT_STATE Packet Format  . . . . . . . . . . . . 13
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   9. Informative References . . . . . . . . . . . . . . . . . . . . 15
   10. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 16


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


Internet Draft     Header Compression over MPLS Protocol       July 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-ash--avt-hc-over-mpls-protocol-01.txt>     [Page 3]


Internet Draft     Header Compression over MPLS Protocol       July 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.

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

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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

   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.

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


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

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

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

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


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


Internet Draft     Header Compression over MPLS Protocol       July 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)

   Then we do compression on the IP/UDP/RTP headers before transmission,

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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.

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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, each PW had a logically separate HD instance, in this case,
   HD-a and HD-b, independent of all other PWs.  That is, 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 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:

   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.

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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], illustrated in Figure 4, 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.

    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

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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]

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
   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 5:


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

                       Figure 5 - 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: MUST NOT BE ASSIGNED

   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 proposed encoding of the PWE3 control

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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
   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 6, 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 6 - FULL_HEADER Packet

4.2.2 CONTEXT_STATE Packet Format

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


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


Internet Draft     Header Compression over MPLS Protocol       July 2005


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

                Figure 7 - CONTEXT_STATE Packet

   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.

   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, new PW type values are assigned in
   [IANA] for HC over MPLS LSP/PWs.  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

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


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


Internet Draft     Header Compression over MPLS Protocol       July 2005


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

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

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

   [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

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


Internet Draft     Header Compression over MPLS Protocol       July 2005


   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


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


Internet Draft     Header Compression over MPLS Protocol       July 2005


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.

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-01.txt>    [Page 17]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/