Network Working Group Lars-Erik Jonsson INTERNET-DRAFT Krister Svanbro Expires: February 2001 Hans Hannu Ericsson, Sweden August 23, 2000 Profiles and Parameters in ROHC 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract The RObust Header Compression WG (ROHC) is developing compression schemes initially for IP/UDP/RTP header compression [ROHC]. The group is also chartered to develop compression for IP/TCP and after re- chartering it is possible (probable) that also compression of other protocols will follow. Compression and decompression must always follow well defined rules but there exist a number of variables that will affect details in the way compression should be carried out and how these rules are set. The purpose of this document is to identify such variables and outline a way to make ROHC both adaptable to various conditions and possible to extend for future needs. Jonsson, Svanbro, Hannu [Page 1] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 Table of contents 1. Introduction..................................................3 2. A profile concept.............................................3 3. Variables for scheme adaptation...............................4 3.1. Size of context identifier (CID).......................4 3.2. IP version, 4 or 6.....................................5 3.3. Transport protocol.....................................5 3.4. Checksum presence in UDP (IPv4 only)...................5 3.5. Use of timer-based timestamp compression...............6 3.6. Compression of application protocols...................6 3.7. Future needs...........................................6 4. Parameters to negotiate by link layer.........................7 5. Proposed FH structure.........................................7 6. List of possible profiles and additional parameters...........8 7. Other considerations..........................................8 8. Conclusions...................................................9 9. References...................................................10 10. Authors addresses............................................10 Jonsson, Svanbro, Hannu [Page 2] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 1. Introduction The RObust Header Compression WG (ROHC) is developing compression schemes initially for IP/UDP/RTP header compression [ROHC]. These first outcomes from the WG are expected during 2000 and is already chosen by cellular communities to be part of year 2000 standards. ROHC is further chartered to develop compression also for IP/TCP and after re-chartering it is probable that other protocols, mainly application protocols, will follow. Compression and decompression must always follow well defined and standardized rules. However, even if probably the general ROHC principles of today for how to do header compression will be applicable also in the future, there exist a number of variables that will affect details in the way compression should be carried out. The purpose of this document is to identify such variables, analyze them and propose how ROHC adaptation should be carried out for each of them. A profile concept is proposed to handle some of the variations, profile specific parameters are proposed to handle others and finally link layer negotiations are proposed for a few channel specific issues. In chapter 2, the profile concept is defined. Chapter 3 lists and analyses the various variables for scheme adaptation and concludes about how to treat each of them. In chapter 4, a full header base structure is proposed and in chapter 6 some possible profiles are listed to exemplify the concept. Finally, chapter 6 summarizes what is left for negotiation on the link layer and chapter 7 mentions some additional considerations. Conclusions may be found in chapter 8. 2. A profile concept This chapter proposes a definition of ROHC profiles to be used in the ROHC scheme. The profile concept proposed here is derived from the ROCCO [ROCCO] profiles with modifications due to experiences from that work and comments from various people involved in ROHC. A profile is a context specific parameter which explicitly defines the kind of packet stream compressed within the context, the packet formats used and the exact details of compression and decompression logic. For each context present on a channel, one profile is used to compress the packet stream corresponding to that context. The same profile may be used for all context but there may also be as many different profiles as the number of active contexts. Profiles are identified with a profile identifier which is proposed to be an 8-bit value where the first bit is set to 0. If the first bit is set to one, the profile number is extended to 2 octets. This Jonsson, Svanbro, Hannu [Page 3] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 would give 128 possible profiles identified with 1 octet and 32768 with 2 octets. 128 is expected to be sufficient but by allowing an extended range the solution is not limiting the possibilities for future needs. One of the most important property of a profile is the protocols that are compressed with that profile. There may be many different combinations, more or less specialized, and a few examples of possible profiles can be seen in chapter 5. Note that there may exist several profiles that compress the same set of headers in different ways. In addition to what is unambiguous defined for a profile, the profile itself may have additional parameters that are set as part of the compression logic using the packet formats defined for that profile. 3. Variables for scheme adaptation There are several variables that will affect both packet formats and compression/decompression logic. This chapter lists and analyses the parameters that have been identified during the ROCCO work and in the discussions following that work. The variables identified are: - Size of context identifier - IP version, 4 or 6 - Transport protocols - Checksum presence in UDP - Use of timer-based timestamp compression - Compression of application protocols - Future needs The analysis carried out below aims at deciding whether it makes sense to have a parameter included in what is defined by the profile identifier or if a parameter should be handled by other means. 3.1. Size of context identifier (CID) Header compression removes the per packet information used to identify and separate the packet streams, addresses, port numbers and, for RTP, the SSRC identifier. It is therefore necessary to add some other mechanism to get this functionality, which is normally a field in the beginning of all packets sent over the channel called the context identifier or CID. The CID and its size are thus channel parameters that must be well defined and CID must be present in all packets sent over the channel. Since the CID size should be variable from channel to channel it is easiest to have a CID size of whole octets, zero, one or several. Also, since the CID must be well defined for all packets, it is natural to put the CID in the beginning of each packet. The CID size must thus be known a priori Jonsson, Svanbro, Hannu [Page 4] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 and should therefore be either pre-configured for the link or negotiated (compressor->decompressor) when the channel is established. 3.2. IP version, 4 or 6 Since IP version 4 differs from IP version 6 in a number of ways, also header compression will differ. Even if IPv4 and IPv6 packets will probably not appear at the same place, it could happen and IP version would then be a context specific property. There exist thus at least two possible ways to handle this variation in header compression characteristic. Either the IP version field is included in the compressed full header as it appears in the original header or implicitly defined by different profiles. Both ways would work, but if it is explicitly indicated all profiles must have support for both IPv4 and IPv6 which would be a significant disadvantage especially in the future. The best flexibility would thus be provided if different profiles are defined for IPv4 and IPv6, i.e. IP version becomes part of what is defined by a profile. 3.3. Transport protocol The same ideas as for the IP version applies also to the transport protocol issue. However, the disadvantages of having it explicitly indicated in the compressed full headers are even more significant. First of all, the requirement to have all profiles support all existing transport protocols is even more undesirable since there are major differences between the transport protocols and standardization of the compression schemes is naturally separate issues (as in ROHC right now). New transport protocols will probably also appear in the future which makes it impossible for all profiles to support all transport protocols. This means that also the transport protocol support variable becomes a part of what is defined by a profile. 3.4. Checksum presence in UDP (IPv4 only) In IPv4, it is possible to disable the UDP checksum. If the checksum is disabled, it will probably be so for all packets belonging to the same packet stream. If it is disabled, header compression would benefit from that since the checksum does not have to be transmitted over the link. The compressed header formats will therefore differ based on whether the checksum is enabled or disabled. Presence of the UDP checksum will thus be a context specific parameter. However, since this parameter is specific to UDP for IPv4, it does not suite the purpose of the profile concept but should instead be a profile specific parameter for all profiles compressing UDP over IPv4. Jonsson, Svanbro, Hannu [Page 5] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 3.5. Use of timer-based timestamp compression For certain real-time specific header compression schemes, usage of timers or wall clocks could improve the compression performance significantly. However, a compression scheme should never be designed to require such functionality and the usage must therefore be an option for compression enhancements. That would thus be a profile specific parameter for profiles that make use of such mechanisms, e.g. profiles for compression of RTP headers. 3.6. Compression of application protocols Compression of application protocol headers is a difficult task since the presence of application protocols are not explicitly indicated in the original packet headers. The only things that are told explicitly are IP version and which transport protocol that is used. This makes it hard to decide whether a packet stream is IP/UDP/RTP or IP/UDP and choose the appropriate compression scheme. In RFC2508 [CRTP], RTP is always assumed for all UDP streams and if the compression ratio gets low the scheme falls back to compression of IP/UDP only. This method works if RTP is the only possible application protocol. However, the number of application protocols in use is increasing and the method used in RFC2508 can therefore not be applied for all possible application protocol combinations. As mentioned above, the task of deciding what protocols to compress if application protocols are present is difficult. It should therefore be treated as an issue separate from ROHC and ROHC should not make any assumptions about this. Instead, ROHC should define compression profiles for various protocol combinations and methods for how to switch profile for a context. 3.7. Future needs In the short term, ROHC will standardize IP/UDP/RTP header compression. The charter of ROHC also includes compression for IP/TCP and more schemes are expected to follow. It is therefore important that ROHC becomes flexible and general so that new variations of the scheme can be added, utilizing the common header compression parts. Especially since it should not only be possible to handle the protocols known today, but also those that will appear in the future. Future link layers may also look different and put new or different requirements on header compression, meaning that new profiles must be added to compress the same protocols in a different way to get a certain desired behavior. By having the profile identifier, ROHC will get flexibility to add new variations both for existing protocols, future new protocols and future new requirements on compression of today's protocols. Jonsson, Svanbro, Hannu [Page 6] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 4. Parameters to negotiate by link layer For the link layer, only two parameters must be negotiated between compressor and decompressor: - Size of context identifier (CID) The CID is 0, 8 or 16 bits and the desired size must either be pre-configured or communicated when channel is established between compressor and decompressor. CID size should normally be communicated from compressor to decompressor. - Profile capabilities The profile identifier is an 8-bit number (may be extended to 16 bits) that unambiguously defines how header compression is carried out. However, both compressor and decompressor must support a certain profile to be able to use it. Since the compressor will decide what profile to use, it must know which profiles are supported by the decompressor. As for the CID, profile support might be pre-configured but normally it should be communicated from decompressor to compressor when the channel is established. 5. Proposed full header (FH) structure Since the profile to use for a certain context is specified in the initial full headers of a new compressed packet stream, the beginning of the full header format must be common for all profiles. If multiple contexts are supported, the CID must be unambiguously defined for all packet formats in all profile. All profiles must also have a common packet type identifier and profile number field for the full header format. The figure below shows a schematic figure of the proposed full header format. +...+...+...+...+...+...+...+...+ : CID : 0-2 octets +---+---+---+---+---+---+---+---+ | Full Header Packet Type | 1 octet +---+---+---+---+---+---+---+---+ | Profile Number | 1 octet +---+---+---+---+---+---+---+---+ | Profile specific full header | Example: Profiles for UDP in : structure including profile : IPv4 will have a : specific parameters. The : checksum presence : structure may be affected : flag and if set the : by the values of the profile : checksum will also | specific parameters. | be in the structure. +---+---+---+---+---+---+---+---+ Jonsson, Svanbro, Hannu [Page 7] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 6. List of possible profiles and additional parameters This section exemplifies the profile concept by listing some possible profiles that will be defined with proposed profile numbers. Profile specific parameters, as described in previous sections of this document, are also listed. +---------+----------------------+----------------------------------+ | Profile | Compressed protocols | Additional parameters | +---------+----------------------+----------------------------------+ | 0* | All, uncompressed | - | | 1 | IPv4 only | - | | 2 | IPv6 only | ? | | 3* | IPv4/UDP | Checksum on/off | | 4* | IPv6/UDP | - | | 5** | IPv4/TCP | ? | | 6** | IPv6/TCP | ? | | 7* | IPv4/UDP/RTP | Checksum on/off, Timer-based TS | | 8* | IPv6/UDP/RTP | Timer-based TS | | .. | | | +---------+----------------------+----------------------------------+ * Will be defined by ROHC during 2000 ** Will be defined by ROHC during 2001 7. Other considerations The profile number space becomes very important for ROHC and must be controlled on good authority. Assignment of profile numbers should therefore be made by the IANA. Jonsson, Svanbro, Hannu [Page 8] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 8. Conclusions This document has discussed how to make ROHC adaptable to various variation needs regarding what to compress and how to compress. A solution based on a combination of link layer negotiations, ROHC profiles and profile specific parameters has been proposed. The main arguments in favor of the proposed solution are the ones listed below. # By defining context specific profiles in ROHC: - Standardization can be done step-wise but the original framework of ROHC can be reused. - ROHC will become expandable to future needs both for new solutions to handle today's protocols and also for new protocols. - It would be easy to switch from one profile to another for the same context, since profile type is established by in-band signaling in full headers. # There will be only two parameters to negotiate by link layer: - Size of context identifier (compressor -> decompressor) - Profile capabilities (decompressor -> compressor) # The number of profiles is reduced by having profile specific parameters for some profiles (e.g. presence of checksum in UDP) Jonsson, Svanbro, Hannu [Page 9] INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000 9. References [CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [ROHC] Carsten Bormann, et.al., "Robust Header Compression (ROHC)", Internet Draft (work in progress), July 2000. [ROCCO] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister Svanbro, "RObust Checksum-based header COmpression (ROCCO)", Internet Draft (work in progress), June 2000. 10. Authors addresses Lars-Erik Jonsson Tel: +46 920 20 21 07 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 EMail: lars-erik.jonsson@ericsson.com SE-971 28 Lulea, Sweden Krister Svanbro Tel: +46 920 20 20 77 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 EMail: krister.svanbro@ericsson.com SE-971 28 Lulea, Sweden Hans Hannu Tel: +46 920 20 21 84 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 EMail: hans.hannu@ericsson.com SE-971 28 Lulea, Sweden This Internet-Draft expires February 23, 2001. Jonsson, Svanbro, Hannu [Page 10]