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]