Internet DRAFT - draft-degermark-rohc-initialization
draft-degermark-rohc-initialization
Network Working Group Mikael Degermark /University of Arizona
INTERNET-DRAFT USA
Expires: Feb 2001 August 27, 2001
ROHC Initialization Headers
<draft-degermark-rohc-initialization-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."
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]
