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

Versions: (draft-berger-mpls-hdr-comp) 00

Network Working Group                                         Lou Berger
Internet Draft                                      LabN Consulting, LLC
Expiration Date: January 2001
                                                          Jason Jeffords
                                                    Integral Access Inc.

                                                               July 2000


                       MPLS/IP Header Compression


                    draft-ietf-mpls-hdr-comp-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

   This document describes a method for compressing the headers of IP
   datagrams that are being transported over MPLS.  This work extends
   the existing IP and IP/UDP/RTP header compression techniques, as
   defined in [RFC2507] and [RFC2508], to operate over and to compress
   MPLS label stack entries.













Berger & Jeffords                                               [Page 1]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   Changes from previous version:

   o  Changed name to draft-ietf-mpls-hdr-comp-00.txt.
   o  Changed name of 'N-bit' to 'P-bit' to avoid naming collision.


1. Introduction

   IP and IP/UDP/RTP header compression, which is defined in [RFC2507]
   and [RFC2508], reduces header overhead and is particularly useful on
   lower speed links.  The current header compression definition relies
   on IP datagrams being carried directly over a link layer protocol,
   such as PPP [STD51].  With the introduction of MPLS [LABELS], one or
   more MPLS headers, which are called label stack entries, may be
   present between the IP and link layer headers.  Since the header
   following the link layer header is no longer IP, the existing
   compression techniques will not operate.  Clearly delivering header
   compression when using MPLS on lower speed links is desirable.

   This document presents one method for providing header compression
   while running over MPLS.  The presented method incrementally builds
   on the header compression techniques defined in [RFC2507] and
   [RFC2508].  It makes use of the same basic mechanisms and continues
   to provide compression on a link-by-link basis.  It preserves the
   ability to compress all headers, including multiple MPLS label stack
   entries, into the same space when MPLS EXP bits remain constant.
   This is 2-4 bytes for MPLS/IP/UDP/RTP header compression.  It also
   co-exists with standard IP, IP/TCP and IP/UDP/RTP header compression
   running on the same link.

   Familiarity with [RFC2507], [RFC2508] and [RFC1144] is encouraged as
   the material presented in those documents is not repeated in this
   document and their principals and techniques are leveraged.

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


2. Compression Method Overview

   The defined compression method reuses the compression techniques and
   formats defined for IP and IP/UDP/RTP compression.  IP and IP/UDP/RTP
   compression relies on many header fields not changing per packet over
   the life of the session, or some fields differing from packet to
   packet by only a constant value.  By maintaining both the
   uncompressed header and the first-order differences in the session
   state shared between the compressor and decompressor, all that must



Berger & Jeffords                                               [Page 2]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   be communicated is an indication that the second-order difference was
   zero.  The decompressor can then reconstruct the original header
   without any loss of information simply by using the packet length
   indicated by the link-level protocol and by adding the first-order
   differences to the saved uncompressed header as each compressed
   packet is received.

   The same compression techniques can be used on MPLS label stack
   entries.  All fields within a stack entry other than the EXP field
   will typically remain constant over the life of a session.  When a
   label stack is used, i.e., there is more than one stack entry, the
   number of stack entries and the label values of each will also remain
   constant.  To support MPLS header compression, the number of stack
   entries and each entry's label is added to the session context.

   As with the previous techniques, the compressor and decompressor must
   maintain state per session context.  Likewise, multiple session
   contexts should be maintained.  In addition to the new MPLS related
   information, the session context contains the combination of the IP
   source and destination addresses, the TCP or UDP source and
   destination ports, and for RTP the SSRC field.  As with IP/UDP/RTP
   compression, a compressor implementation might use a hash function on
   these fields to index a table of stored session contexts.  The
   compressed packet continues to carry a small integer, called the
   session context identifier or CID, to indicate in which session
   context that packet should be interpreted.  Packets containing full
   headers and a CID are transmitted to initiate compression and to keep
   the decompressor synchronized.  The decompressor can use the CID to
   index its table of stored session contexts directly.  The CID
   together with any header fields that differ by a non-constant value
   are all that must be conveyed in order for the decompressor to
   reconstruct the full original MPLS, IP, TCP, UDP and RTP headers.
   Note that the existing TCP and non-TCP CID spaces are reused for MPLS
   encapsulated traffic.

   If not explicitly mentioned, all the conditions and restrictions
   documented in [RFC2507] and [RFC2508] apply to this document.  For
   example, this includes the restrictions on handling of fragmented IP
   packets, and the need for most compressor implementations to maintain
   a "negative cache" of packet streams that have failed to compress as
   RTP packets.

   Other methods for supporting IP and IP/UDP/RTP header compression
   over MPLS are possible and some where considered.  One alternative
   worth noting is adapting the existing header compression techniques
   to operate directly over MPLS without any MPLS header compression.
   This method was discounted for a couple of reasons.  The first was
   that MPLS headers do not typically carry a packet type code.  Such



Berger & Jeffords                                               [Page 3]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   codes could be carried by assigning special meaning to the EXP field
   or even the label field.  It was decided that such assignment was
   undesirable due to possible collision with Diff-Serv usage of the EXP
   field and not wanting to subdivide the label field.  The second and
   more important reason for not adapting compression to operate over
   MPLS was simply to gain extra efficiency by enabling the compression
   of the MPLS label stack.


3. MPLS/IP Header Compression

   MPLS headers, i.e., label stack entries, are carried between the IP
   header and the link layer header.  The number of stack entries and
   the label values of each will remain constant through the life of a
   session.  Data flows that have different number of stack entries or
   different label values are always considered to be different
   sessions.  The only part of a stack entry that may change during a
   session is the EXP field, and this is only the case for some
   sessions.

   To support a session that uses MPLS headers, the compressor and
   decompressor must synchronize, on a per MPLS session basis, on the
   number of stack entries and on the contents of each entry.  Once a
   compressor and decompressor are synchronized on the MPLS headers, the
   headers need not be resent.  For the cases where the EXP field my
   regularly change, the changed EXP fields must be conveyed per packet.
   When multiple stack entries are present, more than one EXP field may
   change in a label stack.

   Other than the initial synchronization of MPLS information and
   possible EXP field support, the previously defined header compression
   techniques can be reused with little or no modification.  The primary
   modifications required are to session context information, and the
   communication of uncompressed MPLS headers.

   As with IP and IP/UDP/RTP compression, there is a separate session
   context for each MPLS/IP packet stream.  The number of session
   contexts to be maintained MAY continue to be negotiated between the
   compressor and decompressor.  The support of MPLS/IP compression MUST
   be negotiated or configured.  The following information is added to
   the shared information in each context, as defined in [RFC2507] and
   [RFC2508]:

     o The number of stack entries.

     o The full MPLS stack.

     o Whether EXP changes are being supported.  This may change over



Berger & Jeffords                                               [Page 4]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


       the life of a session.

   To communicate this new shared information, a new packet format is
   defined:

     o FULL_MPLS_HEADER - communicates the uncompressed MPLS stack
       plus any following headers and data to establish the
       uncompressed header state in the decompressor for a particular
       context.  The FULL_MPLS_HEADER packet also carries the 8- or
       16-bit session context identifier and other previously defined
       fields to establish synchronization between the compressor and
       decompressor.

   Also to eliminate the possibility of interpreting an MPLS session as
   non-MPLS sessions in the face of certain loss conditions, the
   following packet format is defined:

     o COMPRESSED_MPLS - indicates a packet with a compressed MPLS
       header.  This packet contains a full IP header.  It is used in
       place of the FULL_HEADER packet.

   Assignments of numeric codes for these packet formats for PPP [STD51]
   are to be made by the Internet Assigned Numbers Authority.


3.1. FULL_MPLS_HEADER Packet Format

   The FULL_MPLS_HEADER packet is used to associate a compression
   context ID with full MPLS, IP, TCP or UDP and RTP headers, or to
   update the contents of some of those headers.  It is only used when
   one or more MPLS stack entries are preset.

   As with the existing IP and IP/UDP/RTP compression, the format of the
   FULL_MPLS_HEADER packet is the same as that of the original packet.
   The FULL_MPLS_HEADER packet differs from the corresponding normal
   MPLS/IPv4 or MPLS/IPv6 packet in that it must also carry the
   compression context ID and other previously defined compression
   related fields.  The compression related information in a
   FULL_MPLS_HEADER packet differs from the information defined in
   Section 5.3.2 of [RFC2507] and Section 3.3.1 of [RFC2508] in that it
   also contains an MPLS related flag.  The flag, called the NoEXP or
   "P" bit, indicates when the EXP bits will NOT be conveyed in every
   compressed packet.  The position of the compression related
   information is unchanged and is specified in Section 5.3.2 of
   [RFC2507].






Berger & Jeffords                                               [Page 5]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   The definition of the compression related information carried in a
   FULL_MPLS_HEADER packet is:

       For MPLS/IP/UDP sessions [RFC 2508, Section 3.3.1]

          For 8-bit context ID:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |0|1| Generation|      CID      |  First length field
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |P|          0          |  seq  |  Second length field
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          For 16-bit context ID:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |1|1| Generation|P|  0  |  seq  |  First length field
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |              CID              |  Second length field
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      For MPLS/IP/TCP sessions [RFC 2507, Section 5.3.1]

          Use of first length field:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Length field   | LSB of pkt nr |      CID      |
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Use of second length field if available:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Second length field  | MSB of pkt nr |P|      0      |
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+













Berger & Jeffords                                               [Page 6]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


      For MPLS/non-TCP sessions [RFC 2507, Section 5.3.1]

          For non-TCP headers with 8-bit CID:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 First length field   |0|D| Generation|      CID      |
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Use of second length field if available:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Second length field   |P|      0      | Data (if D=1) |
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Full non-TCP headers with 16-bit CID:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 First length field   |1|D| Generation|P|Data (if D=1)|
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Second length field  |              CID              |
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The only new field introduced in the above formats is the P-bit.  The
   P-bit, when set, indicates that the EXP fields in all present MPLS
   label stack entries will remain constant.  When not set, i.e., is
   zero (0), one or more EXP fields may change on a packet-by-packet
   basis.  In this case, a new EXP Compression field is included in all
   compressor to decompressor packets defined in [RFC2507] and
   [RFC2508].  See Section 3.5 for more details.  Note that in the 8-bit
   CID cases the P-bit is carried in the second length field.  When the
   second length field is not available, the P-bit is not carried and
   and the use of the EXP Compression field is implied.

   With the exception of the P-bit all fields have the same meaning and
   use as with existing IP and IP/UDP/RTP compression.  Processing of a
   MPLS_FULL_HEADER parallels the processing of a FULL_HEADER packet.
   As with the FULL_HEADER packet, a receiver of a MPLS_FULL_HEADER
   packet stores the complete set of headers into the context selected
   by the context ID.  The other compression related information is also
   stored in the context, thereby resynchronizing the decompressor to
   the compressor.

   MPLS_FULL_HEADER packets are sent for new sessions, after the receipt
   of a CONTEXT_STATE message indicating that synchronization has been
   lost for the associated CID, and periodically as called for in
   [RFC2507] and [RFC2508].  MPLS_FULL_HEADER packets are also sent to



Berger & Jeffords                                               [Page 7]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   indicate a change in EXP field handling.

   The compressor and decompressor need to agree on the number of MPLS
   label stack entries that may be present before an IP header.  The
   compressor and decompressor SHOULD negotiate the maximum number
   allowed.  If no maximum number of MPLS headers is negotiated or
   configured, a default of one (1) SHALL be used.  Packets containing
   more than the maximum number of MPLS headers MUST not be compressed.


3.2. COMPRESSED_MPLS Packet Format

   The COMPRESSED_MPLS packet carries a compressed MPLS label stack and
   all other headers uncompressed.  It is used to cover the cases where
   a full IP and TCP or UDP header must be sent.

   The format of a COMPRESSED_MPLS packet is:

                0   1   2   3   4   5   6   7
              +...............................+
              :   msb of session context ID   :  (if 16-bit CID)
              +-------------------------------+
              |   lsb of session context ID   |
              +-------------------------------+
              :    EXP Compression Fields     :  (see Section 3.5)
              +-------------------------------+
              |    Uncompressed IP packet     |
              :                               :


3.3. Baseline Operation

   Under normal conditions the number of MPLS label stack entries and
   the contents of each entry is expected to remain constant over the
   life of a session.  (Section 3.5 covers the case where the EXP field
   is expected to change on a per packet basis.)  Operation in this mode
   is selected by the P-bit, for more details see section 3.4.  In this
   mode, all MPLS headers will be transmitted in MPLS_FULL_HEADER
   packets and stored by the decompressor.  Once the MPLS headers are
   transmitted and stored by the decompressor, they no longer need to be
   transmitted.  This means that after a MPLS_FULL_HEADER packet is sent
   for a particular session, the standard IP and IP/UDP/RTP compression
   packet formats and associated processing may be used without any
   modifications.

   While the standard packet formats are used, the decompressor must of
   course be extended to reconstructs the original MPLS headers for all
   MPLS session.  When reconstructing the headers of an MPLS/IP packet



Berger & Jeffords                                               [Page 8]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   received in any compressed packet type, the decompressor MUST perform
   the same context validation checks as described in Section 10.2 of
   [RFC2507] and Section 3.3.5 of [RFC2508].  If the checks fail, a
   corresponding CONTEXT_STATE packet MUST be sent.  If the checks pass
   the decompressor adds the MPLS headers associated with the CID.

   There is one standard packet type that must be handled differently.
   For sessions not associated with MPLS, the FULL_HEADER packet is used
   to identify and reset the session context.  When a session is
   identified as using MPLS headers, via a MPLS_FULL_HEADER packet, the
   FULL_HEADER packet must be handled differently.  For MPLS sessions,
   the FULL_HEADER packet is not used.  If a FULL_HEADER packet is
   received with a CID matching an MPLS session, the receiver must
   assume that the CID is being reused for a new non-MPLS session and it
   MUST reset all session context based on the received FULL_HEADER
   packet.

   When a CONTEXT_STATE packet is received for an MPLS session, a
   MPLS_FULL_HEADER packet MUST be sent rather than a FULL_HEADER
   packet.  Note that per [RFC2508] and [RFC2507] generating a packet is
   not always required in response to a received a CONTEXT_STATE packet.


3.4. Setting the P-bit

   The P-bit is carried in MPLS_FULL_HEADER packets and controls whether
   EXP bits are carried in compressed packets.  When the EXP fields in
   all present MPLS label stack entries are expected to remain constant
   on a packet-by-packet basis, the P-bit SHOULD be set.  Values used in
   the MPLS EXP field typically depend on whether Differentiated
   Services [DIFFSERV] is being supported.  When Diff-Serv is not being
   used, the EXP field will typically remain constant.  When Diff-Serv
   is being supported, the EXP field may change packet-by-packet for
   some applications and remain constant for others.  Because of these
   different cases, it will generally be difficult to identify which
   MPLS sessions will be regularly changing EXP fields and which will
   not.

   To support these cases, all new sessions SHOULD be initiated with the
   P-bit set when possible.  (As previously noted, the P-bit is not
   carried in some exception cases.)  When the first change in an EXP
   field is seen by the compressor, it MUST send a new MPLS_FULL_HEADER
   packet.  At this point it may choose to not set the P-bit, or it may
   choose to wait to see if EXP changes are frequent.  If EXP changes
   are observed to be frequent, the compressor SHOULD NOT set the P-bit.
   Operation when the P-bit is not set is described in Section 3.5.  A
   compressor MAY be configured to never set the P-bit.




Berger & Jeffords                                               [Page 9]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


3.5. The EXP Compression Field

   When the P-bit is not present, or is not set in the session's most
   recent associated MPLS_FULL_HEADER packet, the session is said to be
   in "EXP mode".  In this mode one or more EXP fields are expected to
   change on as much as a per packet-by-packet basis.  To support this
   mode a new field, called the EXP Compression field, is defined.  When
   operating in EXP mode, at least one EXP Compression field is included
   in all compressed packet types.  Compressed packet types are the
   types defined in [RFC2507], [RFC2508] and earlier in this document
   and begin with "COMPRESSED_."

   Each EXP Compression field references a single MPLS label stack entry
   and provides the 3 bit EXP field to be used with that entry.
   Multiple EXP Compression fields may be included when more than stack
   entry is present.  At most changes to 16 stack entries can be
   supported.

   Only changes in EXP fields are carried, and the receiver MUST store
   the most recently received value.  If no changes in EXP fields are
   observed, one EXP Compression field MUST be included in the
   compressed packet.  In this case, the EXP Compression field SHOULD
   carry the EXP bits from the topmost stack entry.  Per [LABELS], the
   top of the label stack appears earliest in the packet, and the bottom
   appears latest.

   The format of the EXP Compression field is:

                0   1   2   3   4   5   6   7
              +---+---+---+---+---+---+---+---+
              |    offset     | L |    EXP    |
              +---+---+---+---+---+---+---+---+

       Offset indicates the count from the top of the stack to the
       corresponding label stack entry.  To reference a particular stack
       entry, offset is incremented for each stack entry between the
       link layer header and the desired stack entry, e.g., zero
       indicates the top of the stack and two would indicate the third
       stack entry.

       The L-bit is set in the last EXP Compression field present in the
       packet.  A zero indicates that there is another EXP Compression
       field immediately following this field.

       EXP is copied from the corresponding label stack entry.

   EXP Compression fields are carried as indicated in Section 3.2 and
   prior to the "RANDOM" fields defined in [RFC2507] and [RFC2508] in



Berger & Jeffords                                              [Page 10]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   other compressed packets.  Two example modified packet formats are:

       COMPRESSED_TCP format [RFC2507] for MPLS EXP mode session

               +-+-+-+-+-+-+-+-+
               |      CID      |
               +-+-+-+-+-+-+-+-+
               |R O I P S A W U|
               +-+-+-+-+-+-+-+-+
               |               |
               +  TCP Checksum +
               |               |
               +-+-+-+-+-+-+-+-+
                - - - - - - - -
               | EXP Compression fields                  (implied)
                - - - - - - - -
               | RANDOM fields, if any (see section 7)   (implied)
                - - - - - - - -
               | R-octet       |                         (if R=1)
                - - - - - - - -
               | Urgent Pointer Value                    (if U=1)
                - - - - - - - -
               | Window Delta                            (if W=1)
                - - - - - - - -
               | Acknowledgment Number Delta             (if A=1)
                - - - - - - - -
               | Sequence Number Delta                   (if S=1)
                - - - - - - - -
               | IPv4 Identification Delta               (if I=1)
                - - - - - - - -
               |  Options                                (if O=1)
                - - - - - - - -



















Berger & Jeffords                                              [Page 11]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


       COMPRESSED_UDP packet format [RFC2508] for MPLS EXP mode session

                0   1   2   3   4   5   6   7
              +...............................+
              :   msb of session context ID   :  (if 16-bit CID)
              +-------------------------------+
              |   lsb of session context ID   |
              +---+---+---+---+---+---+---+---+
              | 0 | 0 | 0 | I | link sequence |
              +---+---+---+---+---+---+---+---+
              :                               :
              +         UDP checksum          +  (if nonzero in context)
              :                               :
              +---+---+---+---+---+---+---+---+
              |    offset     | L |    EXP    |  EXP Compression fields
              +---+---+---+---+---+---+---+---+
              :                               :
              +        "RANDOM" fields        +  (if encapsulated)
              :                               :
              +...............................+
              :         delta IPv4 ID         :  (if I = 1)
              +-------------------------------+
              |           UDP data            |
              :   (uncompressed RTP header)   :

   Note that there may be more than one EXP Compression field per
   packet.


3.6. Compatibility

   MPLS and standard IP and IP/UDP/RTP compression can be performed on
   the same link.  MPLS and IP sessions are distinguished via the use of
   MPLS_FULL_HEADER or FULL_HEADER packets.  Once a session context is
   initialized, the CID implies whether MPLS headers are compressed.  It
   is important to note that there is no separate MPLS session CID
   space.  MPLS sessions share the TCP and non-TCP CID spaces.
   MPLS/IP/TCP sessions share the TCP CID space.  Other sessions,
   including MPLS/IP/UDP/RTP sessions, share the non-TCP space.

   It is also necessary for a compressor to know when a decompressor
   supports MPLS/IP compression.  This information can be configured or
   negotiated.  The default behavior is to assume that the decompressor
   does not support MPLS/IP compression.

   Finally, the compressor needs to know the maximum number of MPLS
   stack entries the decompressor can process.  This too can be
   configured or negotiated.  The previously mentioned default is to



Berger & Jeffords                                              [Page 12]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   assume only one entry, i.e., one MPLS header, is supported.


4. Negotiating MPLS/IP Compression

   The use of MPLS/IP compression over a particular link is a function
   of the link-layer protocol.  As in [RFC2508], it is expected that
   such negotiation will be defined separately for PPP, for example.
   The following additional items SHOULD be negotiated:

     o If MPLS/IP compression is supported

     o The maximum stack depth supported


5. Security Considerations

   No new security issues are raised by this document.  Please see
   [RFC2507] and [RFC2508] for a detailed discussion of existing
   considerations associated with header compression.


6. Open/Potential Issues

   This document doesn't support the CRTP enhancements proposed in
   draft-koren-avt-crtp-enhance-01.txt.  It's not clear if this is an
   issue.  The progress of the enhancements in the AVT working group
   should be tracked to see if it becomes an issue.


7. References

   [DIFFSERV] Faucheur, Wu, Davie, Davari, Vaananen, Krishnan,
              Cheval, "MPLS Support of Differentiated Services",
              draft-ietf-mpls-diff-ext-05.txt, June, 2000.

   [LABELS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, Conta,
            "MPLS Label Stack Encoding",
            draft-ietf-mpls-label-encaps-07.txt, September 1999.

   [RFC1144] Jacobson, V., "TCP/IP Compression for Low-Speed Serial
             Links", RFC 1144, February 1990.

   [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
             Compression", RFC 2507, February 1999.

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



Berger & Jeffords                                              [Page 13]


Internet Draft       draft-ietf-mpls-hdr-comp-00.txt           July 2000


   [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
           RFC 1661, July 1994.


8. Authors' Address

   Lou Berger                       Jason Jeffords
   LabN Consulting, LLC             Integral Access Inc.
   Voice:  +1 301 468 9228          6 Omni Way
   Email:  lberger@labn.net         Chelmsford, MA 01824
                                    Voice:  +1 978 256 8833
                                    Email:  jjeffords@integralaccess.com







































Berger & Jeffords                                              [Page 14]


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