Context and Micro-mobility Routing Working Group G. Kenward Internet Draft Nortel Networks draft-kenward-seamoby-ct-rohc-reqs-00.txt Category: Internet Draft Expires: January 2002 July 2001 Context Transfer Considerations for ROHC Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1 Abstract There is an interest in enhancing the performance of handover between access routers through the transfer of forwarding context [2]. To clearly understand the requirements for this transfer, it is useful to examine the requirements of specific feature contexts. This document reviews the requirements for transferring the context associated with RObust Header Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed. 2 Conventions used in this document The peer entities participating in a context transfer, shall, for the purpose of this document, be referred to as the sending access router (SAR) and the receiving access router (RAR), respectively. The SAR is expected to have the most up-to-date ROHC context, and the RAR is expected to be one of the candidates for handover of the IP flow. Kenward Internet Draft - Expires January 2002 1 Internet Draft July 2001 Context Transfer Considerations for ROHC This document will also make reference to the terms "proactive context transfer (PCT)" and "reactive context transfer (RCT)" as defined in [4]. ROHC [3] defines a unit of IP traffic described as a "packet stream" (section 1), being a "sequence of packets where the field values and change patterns of field values are such that the headers can be compressed using the same context". Context transfer operates on the microflow as being the smallest unit of IP traffic for which context can be transferred. Under the assumption that an ROHC "packet stream" is comprised of at least one, and perhaps two or more IP microflows, this document will use the terminology "packet stream" unless the more specific term "IP microflow" is warranted. No other assumptions concerning the access network architecture, the context transfer framework, nor the context transfer protocol(s) is assumed or implied. The general requirements for context transfer are described in [4]. 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 RFC 2119 [5]. 3 Overview ROHC Context ROHC is designed to provide header compression for IP packet transfers over links with significant error rates and long round-trip times ([3], section 1). The robustness of ROHC is provided through multi-modal state machines at the compressor and the decompressor. These state machines operate in response to the traffic flowing across the link. When IP packets are successfully being transferred from the compressor to the decompressor without any loss of information, ROHC operates in the mode that provides the most compression. When link impairments are high, and IP packets are being lost at a relatively high rate, ROCH transits into a mode where no compression is performed. The two sets of state machines at the compressor and decompressor operate quasi-synchronously: no explicit signalling takes place to coordinate transitions at the decompressor with those at the compressor. Instead, each state machine transits according to the relative success of the IP packet transfers across the link. The decompressor monitors the success of decompression of the IP packets, and acknowledges successful decompression to the compressor. The compressor attempts to compress the IP packets as much as possible, as long as the transmitted packets are acknowledged. Kenward Internet Draft - Expires January 2002 2 Internet Draft July 2001 Context Transfer Considerations for ROHC What makes ROHC robust is the intrinsic bias of the state machines to return to a basic mode of operation where no compression is performed. In this operational mode, any compromises introduced into the IP transfer protocol by compression are removed, and the protocol will perform as well as it was designed to perform. For a more complete description of how ROHC works, c.f. reference [3]. The ROHC draft defines "context" as "the state [the compressor / decompressor] uses to [compress / decompress] a header ([3], section 1). This context is comprised of "information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression" and "additional information describing the packet stream". The latter refers to parameters that describe how the various fields in the header will vary from packet to packet. ROHC also defines a specification for the compression methodology to be used for specific kinds of packet streams over specific kinds of links called the "header compression profile" ([3], section 1). ROHC [3] defines the two types of compression context as static and dynamic. Static compression context consists of the identifier for header compression profile, and any information fields in the packet headers that do not change between consecutive packets in the packet stream. The header compression profile is required to set-up the compressor and the decompressor in their respective initial states. The static header information can then be communicated once, and only once, to the decompressor for the lifetime of the packet stream. The opposite to completely static compression context are those header fields that change with nearly random behaviour with each consecutive packet in the stream. This type of header information usually cannot be compressed. In between the two extreme classifications of compression context, there is a continuum from slowly changing quasi-static information through to constantly changing but predictable information. Appendix A of ROHC [3] provides a general analysis of the dynamics of the header fields for IPv4 and IPv6, UDP and RTP. Context transfer to enhance mobile handover must be concerned with replicating the total context of an ROHC instantiation for a given IP microflow (or group of microflows) from the SAR to a RAR. 4 Context Transfer Alternatives Considering the robust nature, and modes of ROHC, there are four possible approaches to ROHC context transfer: 4.1. No Context Transfer Kenward Internet Draft - Expires January 2002 3 Internet Draft July 2001 Context Transfer Considerations for ROHC Simply because of the robust definition of ROHC, it is possible to handover the uncompressed packet stream from the SAR to the RAR without the integrity of the IP sessions being compromised. ROCH defines an uncompressed, or no-compression profile with an identifier value of 0x0000. Because of the semantics of the CID encoding, a regular, uncompressed IP packet, is interpreted as having a profile of 0x0000. The cons for this approach include: - if the MN was sending compressed packets (the compressor at the MN is in the FO or SO state), the RAR will not be able to decompress the transmitted ROHC frames. The MN compressor will recover, based upon the ROHC robust algorithm, but not without losing IP packets. - the RAR may not be able to re-establish compression for traffic destined for the MN. The RAR would have no direct method of determining that the stream was to be compressed. At best, precious bandwidth would be consumed by the larger then necessary packet headers. At worst, the network may be relying on header compression to lower the required bandwidth for the stream, and the RAR or the path between the RAR and the MN may not have sufficient resources to support the uncompressed stream. The net result would be degradation of the IP service. In addition, it is also possible (in some wireless situations), that the RAR would not have either the capacity or the authorization to admit an uncompressed packet stream resulting in the IP session being dropped. 4.2. Header Compression Profile Transfer The header compression profile is used to configure the ROHC compressor and decompressor to their initial states for the packet stream to be compressed. The information in the profile, along with the static components of the IP headers in the stream, is sufficient for the RAR to generate the equivalent of an Initiation and Refresh state (IR) packet ([3], section 5.2.3) to initialize each compressor state machine at the RAR. The SAR could also provide sufficient context to initiate the decompressor state machines at the RAR. However, the MNs will eventually generate IR messages that will also initiate the RARs decompressors, following the ROHC protocol. This is the simplest, yet most robust approach. A few compressed packets will be lost, and some initial packets in the stream will be exchanged without header compression, but full compression should be achieved relatively quickly, given successful packet transfers. Kenward Internet Draft - Expires January 2002 4 Internet Draft July 2001 Context Transfer Considerations for ROHC One issue with this approach is the reliance on the RAR having the same header compression profile. The IR packet conveys the profile ID and not the profile, and the RAR must match the received profile ID with one of the profiles in its local repository. Even if the RAR finds a matching ID, it is not clear that the profiles will match: e.g. for inter-technology handovers, say Bluetooth to 802.11, some of the link dependent aspects of the profile may change. The only apparently effective solution to this problem is to ensure that the header compression capabilities are compatible for each corresponding profile ID. This may require standardizing profiles beyond the four profiles specified in [3] and ensuring that the link specific characteristics of each networking technology are compatible with each profile. 4.3. Static Compression Context Transfer The IR packet provides all the static context required to initiate the compressor and decompressor state machines. The first level of actual header compression for ROHC compresses the static and quasi- static fields. The compression context is slowly varying, by definition, and thus transferring this context from SAR to RAR could be relatively straightforward. As the quasi-static compression does change over time, the context at the RAR could become stale (proactive ct). However, ROHC should recover from stale context in the same manner as it recovers from lost packets once the handover occurs. With timely updates, transferring of the static compression context would reduce some of the instances of lost packets after handover, and increase the continuity of the compression of the IP stream. 4.4. Dynamic Compression Context Transfer The last alternative is to attempt to capture the complete context for dynamic compression/decompress. Clearly, this is the most difficult approach. Dynamic context state will change with each packet transfer, and so the RAR context will quickly become stale (proactive ct) unless continuous updates are made. Dynamic compression context transfer will succeed for reactive context transfer only if the transfer can be completed between a packet arrival at the SAR and the first or second consecutive packet arrival at the RAR. Otherwise, ROHC will revert to more robust compression state. If the goal is to sustain header compression during and after handover, then the dynamic compression context should be transferred. Kenward Internet Draft - Expires January 2002 5 Internet Draft July 2001 Context Transfer Considerations for ROHC 5 ROHC Context Transfer Context transfer is performed not to ensure connectivity, but to sustain user service during a handover. The degree of degradation experienced for a mobile user will depend upon many factors such as the size and consistency of the wireless coverage areas, the velocity of the MN, the arrival rate of packets in the MNs traffic, as well as the performance of the handover and context transfer solutions. Option 4.2 is the simplest approach to ROHC context transfer that will sustain some level of header compression. It should work sufficiently well for relatively low rate IP microflows where some delay variance and packet losses can be tolerated - e.g. for compressed voice over IP. Option 4.3 is more complex then option 4.2, given that the associated context may change between two packet arrivals. By definition, the likelihood of a change in this context between two packet arrivals low, and the benefit provided by transferring the static and quasi-static information is that the first order (FO)compression may be able to continue effectively without interruption during and after the handover. Option 4.4 is significantly more complex then option 4.2, but may well be required for certain types of traffic, particularly for future services - e.g. two way conversational video, real-time control, etc. The remainder of this document will focus on options 4.2 and 4.3, as the context transfer issues are relatively straightforward, and these approaches represent significant first steps forward in ROHC context transfer development. 5.1 ROHC Context for Header Profile Transfer It is assumed that the RAR and the SAR use identical header compression algorithms and header compression profiles. Resolution of the problems that will arise when the two ARs do not share the same algorithms, profiles and/or profile identifiers is a subject for future research. The ROHC profile context for each IP microflow ([3], section 5.2.3) is comprised of: - Context IDentifier (Add-CID + optional large CID extension): 0, 1, 2, or 3 octets - Profile identifier: 1 octet - profile specific information, variable length. The profile specific information is comprised of static information from the packet headers, and the parameters, if any, required to perform compression on the dynamic fields of those headers. The profile specific information is entirely dependent upon the profile definition. Kenward Internet Draft - Expires January 2002 6 Internet Draft July 2001 Context Transfer Considerations for ROHC ROHC provides four defined profiles ([3], section 5.1.2). For the RTP/UDP/IPv4 profile (profile identifier 0x0001), the profile explicit information is comprised of ([3], section 5.7.7): - ROHC D bit: one bit - subheader Static chain: - IP protocol version number (4): 5 bits - IP protocol identifier (value of 17 for UDP): 1 octet - IP source address: 4 octets - IP destination address: 4 octets - UDP source port: 2 octets - UDP destination port: 2 octets - RTP Synchronization Source identifier: 4 octets. - subheader Dynamic chain: - IP ToS: 1 octet - IP TTL: 1 octet - IP identification: 2 octets - ROHC IP ID RND, NBO flags: 2 bits - IP Don't Fragment (DF) flag: 1 bit - UDP Checksum: 2 octet - RTP Version number (V=2): 2 bits - RTP Padding flag (P): 1 bit - RTP eXtension flag (X): 1 bit - RTP CSRC Count (CC): 4 bits - RTP Marker flag (M): 1 bit - RTP Payload Type (PT): 7 bits - RTP Sequence Number: 2 octets - RTP Timestamp: 4 octets - RTP Generic CSRC list: - ROHC Encoding Type (ET=0): bits - ROHC GP flag: 1 bit - ROHC Padding Size flag (PS): 1 bit - RTP CSRC Count (0