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]