Internet Draft
Network Working Group                                     George Swallow
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: September 2000
                                                              Lou Berger
                                                         LabN Consulting

                                                              March 2000


                       Simple Header Compression


             draft-swallow-mpls-simple-hdr-compress-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

   To view the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
   Directory, see http://www.ietf.org/shadow.html.

Abstract

   MPLS allows packets to be forwarded based on a label lookup without
   inspection of the IP header at intermediate routers.  This enables
   headers to be compressed in some applications.

   Label Switched Paths may be established through the use of RSVP.
   This draft describes a simple technique for header compression.  It
   then proposes RSVP procedures for signaling header compression.











Swallow & Berger                                                [Page 1]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000




Contents

    1      Introduction   ..........................................   3
    2      Simple Header Compression  ..............................   4
    3      Header Compression Object Formats  ......................   5
    3.1    Simple Header Compression Object  .......................   5
    3.2    Simple Header Compression Reply Object  .................   7
    4      Control Plane Procedures  ...............................   8
    4.1    Source Node  ............................................   8
    4.2    Intermediate Node  ......................................   8
    4.3    Destination Node   ......................................   9
    5      Data Plane Procedures  ..................................   9
    5.1    Compressor  .............................................   9
    5.2    Decompressor  ...........................................   9
    6      Security Considerations  ................................  10
    7      Intellectual Property Considerations  ...................  10
    8      References  .............................................  10
    9      Authors' Addresses  .....................................  11































Swallow & Berger                                                [Page 2]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


1. Introduction

   MPLS allows packets to be forwarded based on a label lookup without
   inspection of the IP header at intermediate routers.  Further, the
   MPLS label can be used to serve as the context identifier, allowing
   the compressor and decompressor to associate the proper context with
   the stream of label-switched packets.  This enables headers to be
   compressed across a label-switched path.

   Header compression is usually associated with low or medium speed
   links.  However in an application such as voice over IP, the ratio of
   header to data is very high.  For such an application, compressing
   headers in the wide area can significantly reduce bandwidth
   requirements.

   Furthermore, benefits may obtain for low-speed links.  Suppose the
   end-to-end communication extends across low speed links at the edge
   of a network.  If the MPLS domain is extended across these links then
   header compression can be used end-to-end.  This not only gives the
   desirable compression on the low speed link, but also relieves the
   edge aggregation box of the burden of compression and decompression.

   Sophisticated header compression techniques rely on feedback to
   achieve resynchronization.  When packets are lost, the compressor and
   decompressor must resynchronize.  For an application such as voice
   over IP in the wide-area, the time necessary to achieve such
   resynchronization may be longer than the voice application can
   tolerate.

   Another consideration is the bandwidth verses processing trade-off.
   In many prospective environments it may be desirable to trade a small
   amount of compression efficiency for a less processing intense (and
   thus more scalable) compression technique.  For example, a voice
   gateway may be called upon to compress and decompress many flows.

   We propose a simple header compression technique which requires no
   resynchronization and a relatively light per packet processing load.

   Label Switched Paths may be established through the use of RSVP.
   This draft proposes RSVP procedures for signaling header compression.

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







Swallow & Berger                                                [Page 3]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


2. Simple Header Compression

   In order to avoid the need for resynchronization and to minimize
   processing, the proposed technique relies on transmitting all first
   order differences in packets.  Any byte which varies in any bit will
   be explicitly transmitted as part of the compressed header.

   The compressor communicates the uncompressed header template via an
   RSVP Path message.  Also included in the message are a set of
   operands for reconstructing the header from the transmitted
   compressed header and the stored header template.

   The header template and the set of operands is encoded in a
   SIMPLE_HEADER_COMPRESSION (SHC)object.  The compressor sends one or
   more SHC objects via an RSVP Path message.  To allow multiplexing
   across an LSP the objects also carry a one byte sub-context ID
   (SCID).

   The template consists of the first n bytes of a packet.  All of the
   fixed fields are set to their appropriate values.  The variable
   fields SHOULD be set to zero.  Fields are always delimited on byte
   boundaries.  Each operand is simply an offset and a length.  They
   serve to delimit the variable fields within the template.

   Several additional operations are signaled via flags.  The concern
   the updating of TTL, the IP checksum, and the IP length field.  The
   'T' flag allows the IP TTL to be updated using the MPLS TTL.  The 'L'
   flag indicates that the IP length field should be inferred from the
   received packet length.  The 'C' flag indicates that the checksum
   should be recomputed from the reconstructed header.

   The compressor removes the header from the packet.  The term header
   is used loosely here.  It refers to the first n bytes of the packet
   where n is the length of the header template.  The compressor uses
   the operands to extract the variable fields from the header.  These
   are concatenated together as a compressed header.  The SCID is then
   prepended to the compressed header and the packet is sent.

   The decompressor uses the incoming MPLS label and the SCID to locate
   the proper decompression context.  The decompressor then uses the
   header template to reconstruct the original header.  It uses the
   operands to populate the variable fields of the header with the
   contents of the compressed header.








Swallow & Berger                                                [Page 4]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


3. Header Compression Object Formats

   The Class for Header Compression Objects is of the form 10bbbbbb.
   (Need an official number from IANA).  The form 10bbbbbb allows
   intermediate nodes which do not understand header compression to
   silently drop the compression object.  This ensures that a label
   switched path either exists between the source and the destination or
   that header compression is disabled.


3.1. Simple Header Compression Object

      Class = Header Compression Object, Type = 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Header Length         |   Compressed Header Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     SCID    |   RESVD   |T|L|C|      Number of Operands       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Header Operands                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Header Template                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Header Length

         The length of the header template in bytes


      Compressed Header Length

         The length of the compressed header in bytes













Swallow & Berger                                                [Page 5]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


      Flags

          T  Propagate MPLS TTL

             Indicates that the MPLS TTL field should be used to fill in
             the TTL field of the IPv4 header

          L  Reconstruct IP Length Field

             Indicates that the IP length field should be inferred from
             the received packet size.

          C  Reconstruct IP Header Checksum

             Indicates that the IP Header Checksum should be recomputed


      Number of Operands

         The number of operands which follow this field


      Header Operands

         A variable number of operands.  Each operand occupies 2  bytes.
         The operand format is shown below.


      Header Template

         The template for  reconstruction  of  the  header.   All  fixed
         fields  MUST  be  filled out with their respective values.  All
         variable fields SHOULD be set to zero.  The template is  padded
         with zeros to the next four byte boundary.

















Swallow & Berger                                                [Page %]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000



   Each header operand consists of an offset and a length in bytes.  The
   format is as follows.

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

      Header Offset

         The displacement from the  beginning  of  the  header  template
         where replacement begins.


      Replacement Length

         The number of compressed header bytes to  be  copied  into  the
         header template.



3.2. Simple Header Compression Reply Object

   Class = Header Compression Object, Type = 2

   The presence of this object in a Resv message indicates that the
   receiver is will act as a decompressor for packets sent on this LSP
   which contain one of the listed SCIDs.  Over the life of an RSVP
   session SCIDs may be added and deleted simply by refreshing the Path
   state with the updated set of SHC objects  This object provides
   synchronization between the sender and receiver as to which SCIDs may
   be used.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Num SCIDs   |                   SCIDs                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              SCIDs Continued                  |       PAD     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+









Swallow & Berger                                                [Page 7]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


4. Control Plane Procedures

   The following procedures apply only to unicast sessions.  Use of is
   limited to unicast sessions.  Extending simple header compression
   multicast is for further study.  The following sections discuss
   processing at source, intermediate and destination nodes.


4.1. Source Node

   Simple MPLS header compression is always initiated by the originator
   of the Path message, which we refer to as the source.  Note that the
   initiator of the RSVP session may or may not be the ultimate source
   of the compressed flow.  For instance a Cable Modem Termination
   System (CMTS) in a packet cable environment might serve as the
   compressor for a voice over IP flow across an MPLS backbone.

   The source creates a header template and a list of operands which
   identify the location and length of non-fixed fields within the
   template.  The variable fields of the header template SHOULD be set
   to zero.  An SCID is selected.  These are encoded into the SHC
   object.

   The TTL field is handled in one of two ways depending on the choice
   of the setting of the propagate MPLS TTL bit and the value sent in
   the header template.  If the bit is set, the TTL field is to be
   updated based upon the MPLS TTL.  If the bit is not set then the TTL
   is set to the lower of the TTL of the Path message and the value
   contained in the header template.

   The SHC object is included in an RSVP Path message.  The SHC object
   MUST not be included if a LABEL_REQUEST object is not also included
   in the Path message.

   Multiple SHC Objects may be included in a Path Message.  The set of
   objects may be updated over the life of the session.  If multiple SHC
   Objects are included then each SHC Object MUST have a unique SCID.


4.2. Intermediate Node

   Intermediate nodes must act to ensure that an LSP exists from source
   to destination.  Thus if an intermediate node forwards a Path message
   without a label request, the node MUST drop the SHC object from the
   Path message.

   As noted above, the SHC object class is set to a value which
   indicates to nodes in the Path which do not understand the object



Swallow & Berger                                                [Page 8]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


   that they are to silently drop the object.  This has the effect of
   allowing the RSVP session while disabling header compression.  This
   ensures that an SHC unaware node will not inadvertently allow a
   discontinuity in the LSP.


4.3. Destination Node

   If the destination node receives a Path message with SHC objects and
   is willing to act as a decompressor for this session and these SCIDs,
   it includes the SCIDs in a SHC_REPLY object in the corresponding Resv
   message.  If multiple SHC objects contain the same SCID, the first
   such object is used and the other objects with that value are
   ignored.

   If the propagate TTL bit is not set, the decompressor compares the
   TTL of the Path message with the TTL of the header template and
   updates the template with the lower value.



5. Data Plane Procedures

5.1. Compressor

   The source node compresses the header by removing the header (i.e.
   the first n bytes where n is the value sent in the header length
   field of the SHC object).  The node then uses the operands to extract
   the variable fields.  These are concatenated and prepended to the
   remainder of the packet.  The SCID and the MPLS header are then
   prepended and the packet is sent.

   Note that the compressor MUST not use a SCID until it has received a
   Resv message with contains a SHC_REPLY with the SCID listed.


5.2. Decompressor

   The destination node removes the MPLS header and the compressed
   header (i.e. the next n bytes where n is the value sent in the
   Compressed Header Length field of the SHC object).  The node prepends
   the header template to the packet.  The node then uses the operands
   to populate the variable fields of the header with the values sent in
   the compressed header.

   If the 'T' flag is set, the received MPLS TTL is copied into the IP
   TTL field in the decompressed header. The decompressed TTL is
   considered to be the incoming (yet-to-be-decremented) TTL.



Swallow & Berger                                                [Page 9]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000


   If the 'L' flag is set the packet length is recomputed based on the
   received packet length.  If the 'C' bit is set the IP checksum is
   generated afresh.  Note that in practice an end-system may bypass
   these steps and directly deliver the contents of the IP packet to the
   next higher layer.  In this case the 'L' and 'C' flags serve only to
   indicate that differences between the received length and checksum
   and those in the header template are of no concern.



6. Security Considerations

   These procedures do not change the trust model of RSVP (RFC2205[1])
   and draft-ietf-mpls-rsvp-tunnel-04.txt[2].  As such no additional
   security risks are posed.



7. Intellectual Property Considerations

   Cisco Systems may have intellectual property rights claimed in regard
   to some or all of the specification contained in this document.



8. References

[1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
    Version 1, Functional Specification", RFC 2205, September 1997.

[2] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels",
    draft-ietf-mpls-rsvp-tunnel-05.txt, Internet Draft, February 2000.

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
















Swallow & Berger                                               [Page 10]

Internet Draft draft-swallow-mpls-simple-hdr-compress-00.txt  March 2000



9. Authors' Addresses

   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Voice:  +1 978 244 8143
   Email:  swallow@cisco.com

   Lou Berger
   LabN Consulting
   Voice:  +1 301 468 9228
   Email:  lberger@labn.net





































Swallow & Berger                                               [Page 11]