Network Working Group Mikael Degermark /University of Arizona INTERNET-DRAFT USA Expires: Feb 2001 August 27, 2001 ROHC Initialization Headers 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." 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. Abstract This is an individual contribution to the IETF ROHC WG. The document proposes a format for the initialization headers that establish the static (and dynamic) part of ROHC context. The method is intended to be general and extensible, and to deal well with IPv6 extension headers, headers used by Mobile IP, and IPSEC headers. All these headers must be dealt with according to the ROHC requirements, but are not handled by existing proposals. Comments should be sent to the ROHC WG, rohc@cdt.luth.se Degermark [Page 1] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 TABLE OF CONTENTS 1. Introduction..............................................3 2. Header formats ...........................................4 2.1 Basic structure of initialization headers..............4 2.2 Initialization of IPv6 header..........................6 2.3 Initialization of IPv6 extension headers...............6 2.3.1 Options..............................................6 2.3.2 Hop-by-hop options header............................7 2.3.3 Initialization of Routing Header.....................8 2.3.4 Fragment Header......................................8 2.3.5 Initialization of Destination Options Header.........8 2.3.6 No Next Header.......................................8 2.4 Authentication Header..................................9 2.5 Encapsulating Security Payload Header..................9 2.6 Initialization of UDP Header..........................10 2.7 Initialization of IPv4 Header.........................11 2.8 Minimal Encapsulation header..........................12 2.9 Initialization of RTP header..........................13 3. Conclusions...............................................15 4. Author's Address..........................................15 5. References................................................15 Degermark [Page 2] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 1. Introduction The Robust header compression WG (ROHC WG) of the IETF is developing header compression schemes suitable for communication channels with high error rates and long roundtrip times. Before compression of a packet stream can start, the required context needs to be present at compressor and decompressor. Context can be established at the following conceptually distinct events: 0) Specification - when the compression scheme is specified. 1) Link establishment - when the link is established. The capabilities of the compressor and decompressor may not be known until this time. 2) Channel establishment - when the channel is established. The number of streams that can be compressed in the channel may not be known until this time. 3) Stream establishment - when a packet stream starts to flow. A number of properties of a packet stream may not be known until this time. ROHC can deal with logically distinct dynamic channels between compressor and decompressor. The decompressor is assumed to know over which channel each frame arrives, and thus the context indication information can be reduced or eliminated (if a single stream is compressed over the channel). In the case of a PPP link, 1) and 2) occurs simultaneously. This document assumes that for each kind of link (PPP, WCDMA, etc) there will be a document "ROHC over X" which details 0). Presumably this document will specify what capabilities compressor and decompressor can have. When the ROHC scheme is extended, this document will have to be updated. At link establishment time, 1), a negotiation will establish non- default capabilities of the decompressor and compressor. Examples of such capabilities can be "decompressor can do timer-based timestamps", "compressor can do timer-based timestamps", "decompressor can do TCP compression", "decompressor can deal with headers of size at most X", "compressor can do RTP compression". After channel extablishment, 2), parameters such as the size of the CID space must be known. This will have an impact on header formats. Degermark [Page 3] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 At stream establishment, 3), stream specific context such as the actual values of addresses, ports, etc, must be communicated to the decompressor. This proposal assumes that the static part of such information is passed in Initialization headers (INIT). These have earlier been known under the name Full Headers (e.g., in rfc2507) but this would be a mis-nomer as we here propose to send only static information that is not known a priori, and not the entire header. The core of this proposal is to use a notion of profiles, similar to that outlined in "Profiles and Parameters in ROHC" [draft-jonsson- rohc-profiles-00.txt], in INIT headers. The profiles are more restricted, however. Essentially a profile tells the decompressor which transport/application this stream carries, e.g., UDP/RTP with UDP checksum, UDP/RTP without checksum, TCP, etc. The profile does not say anything about IP version, whether there are extension headers present or whether there are tunneling headers present. All other header information is carried in the INIT header, which is a chain of subheaders. The scheme allows dynamic header fields to be sent either separately in a FO header or REFRESH header, or after the static fields in the initialization header. 2. Header formats 2.1 Basic structure of Initialization headers 2.1.1 INIT header - - - - - - - - | CID | 0-2 octets +-+-+-+-+-+-+-+-+ |1 1 1 1 0|V|Res| +-+-+-+-+-+-+-+-+ | Profile | 1 octet +-+-+-+-+-+-+-+-+ | STATIC | | | - - - - - - - - | DYNAMIC | | | - - - - - - - - V V=0: the outermost header is an IPv4 header V=1: the outermost header is an IPv6 header Res reserved. Must be 0. Degermark [Page 4] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 Profile Indicates transport/application of this stream STATIC A chain of Static parts DYNAMIC A chain of Dynamic parts, as defined by the STATIC chain. 2.1.2 REFRESH header - - - - - - - - | CID | 0-2 octets +-+-+-+-+-+-+-+-+ |1 1 1 1 1|V|Res| +-+-+-+-+-+-+-+-+ | Profile | 1 octet +-+-+-+-+-+-+-+-+ | DYNAMIC | | | - - - - - - - - V V=0: the outermost header is an IPv4 header V=1: the outermost header is an IPv6 header Res reserved. Must be 0. Profile Indicates transport/application of this stream DYNAMIC A chain of Dynamic parts Degermark [Page 5] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.2. Initialization of IPv6 Header STATIC Part: +-+-+-+-+-+-+-+-+ |Version| F.Lbl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 LSBs of Flow Label | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DYNAMIC Part: Traffic Class Eliminated: Payload Length 2.3. Initialization of IPv6 Extension Headers [IPv6, section 4] What extension headers are present and the relative order of them is not expected to change in a packet stream. Whenever there is a change, an INIT header must be sent. 2.3.1. Options [IPv6, section 4.2] The contents of Hop-by-hop Options and Destination Options extension headers are encoded with TLV "options" (see [IPv6]): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Degermark [Page 6] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 Option Type and Opt Data Len fields are assumed to be fixed for a given packet stream, so they are classified as STATIC. The Option data is DYNAMIC unless specified otherwise below. Padding Pad1 option +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ Entire option is STATIC. PadN option +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - All fields are STATIC. 2.3.2. Hop-by-Hop Options Header [IPv6, section 4.3] STATIC Part: Next Header, Hdr Ext Len, Option Type, Opt Data Len, Padding. DYNAMIC Part: Option Data Eliminated: Empty. Degermark [Page 7] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.3.3. Initialization of Routing Header [IPv6, section 4.4] STATIC Part: Entire routing header. DYNAMIC Part: Empty. 2.3.4. Fragment Header [IPv6, section 4.5] Fragment headers are not compressed by ROHC. Headers after a Fragment Header MUST NOT be compressed. 2.3.5. Initialization of Destination Options Header [IPv6, section 4.6] STATIC Part: Next Header, Hdr Ext Len, Option Type, Option Ext Len, Padding. DYNAMIC Part: Option Data. Eliminated: Nothing. 2.3.6. No Next Header [IPv6, section 4.7] Covered by rules for IPv6 Header Extensions (2.3). Degermark [Page 8] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.4. Authentication Header [RFC-1826, section 3.2] STATIC Part: 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED | +---------------+---------------+---------------+---------------+ | Security Parameters Index (SPI) | +---------------+---------------+---------------+---------------+ DYNAMIC Part: +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ Eliminated: Empty. 2.5. Encapsulating Security Payload Header [RFC-1827, section 3.1] STATIC Part: +---------------+---------------+---------------+---------------+ | Security Association Identifier (SPI), 32 bits | +===============+===============+===============+===============+ DYNAMIC Part: +===============+===============+===============+===============+ | Opaque Transform Data, variable length | +---------------+---------------+---------------+---------------+ Eliminated: Empty Degermark [Page 9] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.6. Initialization of UDP Header [RFC-768]. STATIC Part: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DYNAMIC Part: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | If Checksum != 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Profile determines if the Checksum is present. Eliminated: Length The Length field of the UDP header MUST match the Length field(s) of preceding subheaders, i.e, there must not be any padding after the UDP payload that is covered by the IP Length. Degermark [Page 10] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.7. Initialization of IPv4 header [RFC-791, section 3.1] STATIC Part: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|Flags | Time to Live | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version could be eliminated but is kept in order to maintain byte alignment. Some Flags can be predicted, but it is simpler to keep the entire Flag field. Note: bits 6 and 7 of the Type of Service field may change often. There should be an inexpensive way to pass at least bit 7 in the compressed TCP header. DYNAMIC Part: Type of Service, Identification Eliminated: IHL (must be 5) Total Length (inferred in decompressed packets)) Fragment Offset (must be 0) Header Checksum (inferred in decompressed packets) Options, Padding (must not be present) Degermark [Page 11] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.8. Minimal Encapsulation header [RFC-2004, section 3.1] STATIC Part: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol |S| reserved | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (if present) Original Source Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DYNAMIC Part: Empty. Eliminated: Nothing. This header is likely to be used by Mobile IP. Degermark [Page 12] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 2.9. Initialization of RTP Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ STATIC Part: P, X, CC, PT, SSRC, CSRC identifiers. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V=2|P|X| CC | +-+-+-+-+-+-+-+-+ |M| PT | +-+-+-+-+-+-+-+-+ | | + + | | + SSRC + | | + + | | +-+-+-+-+-+-+-+-+ : : : CSRC ids : : : +-+-+-+-+-+-+-+-+ Degermark [Page 13] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 DYNAMIC Part: M, sequence number, timestamp, timestamp delta. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | sequence | + + | number | +-+-+-+-+-+-+-+-+ | | + + | | + timestamp + | | + + | | +-+-+-+-+-+-+-+-+ |M| timestamp | +-+ + | delta | +-+-+-+-+-+-+-+-+ Eliminated: Nothing. Degermark [Page 14] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 3. Conclusions The main difference between this proposal and draft-jonsson-rohc- profiles-00, is that here we propose to maintain the header structure as a chain of subheaders for both the static and dynamic parts of the header. As the header structure is maintained in this chain, new header formats need not be invented for each possible combination of subheaders. This should make the scheme easier to extend, as new header formats need not be invented for each new profile. A problem here is that it is not possible to ensure that all data is naturally aligned for all subheader combinations. This proposal is made under the assumption that it is better to keep the specification size small than to strive for optimal implementation efficiency. I note that it is possible to limit what subheaders can be part of a header. If a decompressor cannot handle for example IPSEC headers or tunneling, that could be established at link or channel establishment time. This approach might be preferable to having such subheader limitations being communicated by profiles. No matter which way this is dealt with, the number of possible limitations should be kept small, as an abundance of options becomes difficult to test. INIT and REFRESH headers may also need to carry information regarding switching to the optimistic or reliable mode. It is not clear (to me) at this moment how much information is needed. However, two bits are available in the initial part of both headers. 4. Author's Address Mikael Degermark Tel: +1 520 621-3498 Department of Computer Science Fax: +1 520 621-4246 The University of Arizona PO Box 210077 EMail: micke@cs.arizona.edu Tucson, AZ 85721 USA 5. References [RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980. [RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC-793] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [RFC-1826] R. Atkinson, IP Authentication Header, RFC 1826, August 1995. Degermark [Page 15] INTERNET-DRAFT ROHC Initialization Headers Aug 27, 2000 [RFC-1827] R. Atkinson, IP Encapsulating Security Protocol (ESP), RFC 1827, August 1995. [RFC-1828] Metzger, W. Simpson, IP Authentication using Keyed MD5, RFC 1828, August 1995. [IPv6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 1883, December 1995. [ICMPv6] A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6), RFC 1885, December 1995. [RFC-2004] C. Perkins, Minimal Encapsulation within IP, RFC 2004, October 1996. This draft expires February 27, 2001. Degermark [Page 16]