Seamoby Working Group Manish Tiwari (Editor) INTERNET DRAFT Trapeze Networks 23 Jun 2003 Rajeev Koodli Charles E. Perkins Communication Systems Laboratory Nokia Research Center Context Relocation for Seamless Header Compression in IP Networks draft-koodli-seamoby-hc-relocate-02.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. This document is an individual submission for the seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the seamoby@cdma2000:org mailing list. Distribution of this memo is unlimited. Abstract In networks with bandwidth constraints, such as wireless cellular networks, compression of IP and transport headers may be employed to obtain better utilization of the available spectrum capacity. When header compression is used along with handovers in such networks, the header compression context needs to be relocated from one IP access point (i.e., a router) to another in order to achieve seamless operation. In this document, we propose a mechanism to achieve this compression context relocation using the framework defined in [3] for enabling authorized context transfers during node based mobility. Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Compression Profiles and Compression Profile Types 4 3.1. Handover Uplink and Downlink CPT . . . . . . . . . . . . 6 3.2. New-IP-Address-Uplink Extension . . . . . . . . . . . . . 6 3.3. Tunneling Extension for Downlink . . . . . . . . . . . . 8 3.3.1. Extension for packets tunneled to MN's new IP Address . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Handling packets tunneled to MN's New Access Router 9 4. Compression Context Transfer with Handover signaling 10 5. Header Compression Option Processing Rules at Routers 11 6. Message Formats 12 6.1. Header Compression Context Transfer Reply Option . . . . 13 7. Configurable Parameters 15 8. Security Considerations 15 9. IANA Considerations 15 A. Context Transfer Data Reply Message Status codes 16 A.1. Compression Profile Unavailable Acknowledgment Code 16 A.2. Resource Unavailable Error Code . . . . . . . . . . . . . 17 A.3. Bad Format Error Code . . . . . . . . . . . . . . . . . . 17 Addresses 19 1. Introduction In IP networks, header compression may be employed to obtain better utilization of the link layer for delivering useful payload to applications. Such header compression may include the IP layer and the transport layers such as UDP/RTP and TCP, and in the future, perhaps application layers (such as http). A good example of a network that may employ header compression is a cellular network where the limited link bandwidth makes the use of header compression quite compelling. In such a network, a Mobile Node (MN), which is attached to the cellular network through an air interface, could change its point of attachment (and hence potentially the IP access router as well) due to mobility of the user. This device mobility then requires transfer of header compression state from one network element to another in order to seamlessly continue existing compression contexts. Consider the scenario shown in Figure 1. Prior to handover, the Previous Access Router(pAR) maintains a compression context for both the downlink and uplink packets. When handover takes place, for seamless operation, the New Access Router(nAR) must have appropriate compression state. When it does not possess this state, some uplink packets can get discarded while downlink packets are sent uncompressed until context is re-established at the nAR. | +------------+ +-+ <.... | Previous | <==== < ====>: Uncompressed | | ---------- | Access | ------ > ----\ packet stream +-+ ....> | Router | ====> < \ ....>: Compressed MN | (pAR) | \ packet stream | +------------+ +---------------+ | | IP | Correspondent | | | Network | Node(CN) | V | +---------------+ | / | +------------+ / +-+ <==== | New | <==== < / | | ---------- | Access | ------ > ----/ +-+ ....> | Router | < MN | (nAR) | .+------------+ . . . . V discard Figure 1: Effect of Handover on Header Compression As an example of the difference that context transfer can make, consider the following example. In IPv6, the traffic for real time, voice over IP flows with no header compression consist of a 60 byte IPv6 header, an 8 byte UDP header, a 12 byte RTP header, and a (approximately) 20 byte payload [1]. With header compression, the traffic consists of a single byte header followed by the 20 byte payload. Voice over IP packets are typically sent once every 20 to 60 ms. Figuring on a 40 ms. packet transmission rate and no header compression, a host performing voice over IP requires about 16 kbps just for IP headers alone, without even considering the data payload. Cellular channels for ATM-based voice today average about 9.6 kbps, so it would require about 1.6 sec. to transmit just the header. Since establishing a new header context requires up to 4 packets, a host performing a voice over IP call interrupted by handover would require approximately 6.6 seconds until the performance of the channel with header compression was re-established. During this time, the user will notice gaps and other artifacts in the conversation. With header compression, transmitting the data payload would require approximately 8 kbps on a 9.6 kbps channel, well within the channel limitations. If context transfer can re-establish header compression without requiring the host to perform a full context re-establishment, the difference in the quality of the perceived voice signal to the user can be quite dramatic. Observe that context re-establishment is always an alternative to context relocation. The crucial distinction is that of performance benefits that context relocation, if engineered well, could offer to transport layers. At the same time, it is extremely important to note that the ability to establish packet forwarding through route establishment is the basic necessity without which ``treating packets with feature contexts'' is not feasible. When contexts are not present, a transport layer can always re-establish them. It, however, cannot establish basic network layer connectivity, which is handled by the IP layer mobility process. Hence, any context transfer must not inhibit the (mobility) process from expeditiously establishing the connectivity. It should however, be capable of making use of the mobility process to effect ``fast context transfers''. This document specifies a mechanism to relocate header compression state from the pAR to the nAR in order to achieve seamless operation of header compression during handovers. For this purpose, we make use of the context transfer framework defined in [3] and specific options for header compression defined in this document. As defined here, header compression contexts are created or destroyed always as a result of application events. In particular, a fresh compression context is never created except by some event that can be associated with a change in state related to some application. This means that new header compression state is typically not created nor is destroyed as part of a context transfer. We use this observation to effect a substantial simplification for the control structures needed during handovers, at the cost of the need for additional specification for the creation and destruction of header compression contexts. The specification for the latter protocol operations is outside the scope of this document; they need to be closely aligned with results to be obtained in the ``Robust Header Compression'' [rohc] working group. Furthermore, such protocol specifications should be associated with an appropriate programming interface in order to be effectively used by applications. 2. Terminology We define the following terms for use in this document. New Access Router (nAR) The router to which the MN attaches after handover Previous Access Router (pAR) The MN's default router prior to handover New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the pAR Context Identifier (CID) A 16-bit unsigned integer that identifies a particular header compression context. Compression Profile Type (CPT) A 16-bit unsigned integer that indicates the type of header compression (see section 3). 3. Compression Profiles and Compression Profile Types A compression profile specifies the structure of the state variables which are used for header compression. The Compression Profile Type (CPT) provides a way to indicate which compression profile is in use for a particular packet stream. For seamless header compression, the compression engines located at separate network nodes must agree on the structure of these state variables. When the target compression engine receives the compression state from the appropriate handover message, it will instantiate an instance of a compression state machine for the packet stream in question. That new state machine will be created with the values of the state variables taken from the header compression option contained in the context transfer message, and interpreted according to the data structure and format selected by the CPT. The CPT defined here maps, one-to-one, to the ``Profile'' defined in [1]. However, a Profile in [1] is embedded within a packet type, e.g., an IR packet. A CPT on the other hand, is visible to the context transfer code for demultiplexing the contexts. Possible types for the CPT are: 0: reserved 1: IPv4 header compression 2: IPv6 header compression 3: IPv4/UDP/RTP header compression 4: IPv6/UDP/RTP header compression 5: IPv4/TCP header compression 6: IPv6/TCP header compression Each CPT value is allocated by IANA. The size of each of compression profile is fixed. A value of zero has special meaning in suboption processing as outlined in Section 6. Note that CPTs may be used in options and suboptions specified as part of protocols outside the scope of this document. We specify the Compression Profiles for uplink (from the MN towards the nAR) packet streams as well as for downlink (packets destined towards the MN) during handover. These Compression Profiles, as we mentioned at the begining of this section, specify the compression context for the particular CPT. In the following, we provide the definitions for IPv6/UDP/RTP CPT. 3.1. Handover Uplink and Downlink CPT The pAR sends the Context Transfer Data(CTD) message containing both the static chain and the dynamic chain as part of the compression context. This compression context block is shown in Figure 2. For details regarding the individual fields in the compression context block, see [1], section 5.7.7. The CPT type is set to CPT-v6-RTP. Two new [rohc] Profiles, IR-CT-U and IR-CT-D, are defined to distinguish these contexts from those normally sent by a mobile node. The `D' bit MUST be set to one to include the dynamic chain, which needs to be padded appropriately depending on the entries in the Generic Extension Header list. Note that the payload only carries the UDP and RTP static and dynamic header chains. The payload length field is inferred from the length field of the corresponding CTP message. When the MN undergoes handover and acquires a new IP address, it MUST send a new extension specified below. This packet contains the new IP address of the MN, and other possible extensions defined in Section 5.7.5 in [1]. 3.2. New-IP-Address-Uplink Extension When the compressor module in the MN determines that only its source address is different for an existing packet stream, it sends this extension in any appropriate packet. This particular extension is currently not defined in [1]. We show the existing format in Figure 3 and identify our extension. TC The IPv6 Traffic Class bit. If set, the extension includes the new absolute value HL The IPv6 Hop Limit bit. If set, the extension includes the new absolute value DF Don't Fragment bit. Recast to New IP address extension. If set, the extension includes the new absolute value NH The IPv6 Next Header bit. If set, the extension includes the new absolute value 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type (TBD) ! Length ! CPT-v6-RTP ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Add-CID Octet |1 1 1 1 1 1 0 1| 0-2 octets of CID info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Profile=IR-CT-U| CRC | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ``Static Chain'' | | [version field, flow label, next header, | ~ previous IP address of the MN, ~ | IP address of the correspondent node] | Uplink +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ context | ``Dynamic Chain'' | | [Traffic Class, Hop Limit, | ~ Generic Extension Header List ~ | (e.g., Home Address Destination option) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ``Paload'' | | UDP static chain | | UDP dynamic chain | ~ RTP static chain ~ | RTP dynamic chain | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Add-CID Octet |1 1 1 1 1 1 0 1| 0-2 octets of CID info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Profile=IR-CT-D| CRC | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ``Downlink Context'' | | [Same fields as in Uplink Context | ~ Generic Extension Header List contains routing header ~ | for MIPv6 packets] | Downlink +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ context Figure 2: Composition of Uplink and Downlink Contexts IPX The IPv6 Extension Header bit. If set, the extension includes the new absolute values of extension headers. NBO See [1] RND See [1] 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | 1 | S |R-TS | Tsc | I |ip=1 | rtp | +-----+-----+-----+-----+-----+-----+-----+-----+ | TC | HL | DF=1| NH | IPX | NBO | RND | ip2 | (Inner IP header flags) +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Other fields conditionally present ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ New IP address ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 3: New IP Address Extension The first byte contains fields defined in [1] as-is. The Don't Fragment (DF) bit is not applicable to IPv6. We recast this bit to indicate ``New IP address'', which is included following other information that may be present. Note that the MN may also send other updates including Hop Limit, Traffic Class etc. 3.3. Tunneling Extension for Downlink Sometimes, the pAR may tunnel packet to the MN. For example, in fast handovers, the pAR tunnels packets either directly to the MN's new IP address or to the nAR. In basic mobile ip handovers, the MN may send a binding update to the Previous Router requesting forwarding packets sent to its previous IP address. The pAR then tunnels those packets to the MN's new IP address. In the following, we provide new tunneling extensions that the nAR uses when it receives packets from the pAR. 3.3.1. Extension for packets tunneled to MN's new IP Address Observe that the nAR possesses (or should possess) the context state necessary for compressing packets destined to the MN's previous IP address. When it receives a packet tunneled to the MN's new IP address, it must send the information pertaining to the outer IP header to the MN since the latter does not possess the context for it. The extension in Figure 4 allows the nAR to send only a subset of the outer header fields (Traffic Class and Hop Limit fields), thus substantially reducing the overhead. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | 1 | S |R-TS | Tsc | I |ip=1 | rtp | +-----+-----+-----+-----+-----+-----+-----+-----+ | TC | HL |DF=0 | NH | IPX | NBO | RND|ip2=1| (Inner IP header flags) +-----+-----+-----+-----+-----+-----+-----+-----+ |TC=1 |HL=1 |DF=0 | NH | IPX | NBO | RND | 0 | (Outer IP header flags) +-----+-----+-----+-----+-----+-----+-----+-----+ | Other fields that may be present | ~ (Seq Num, Timestamp, Inner IP header fields) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | Traffic Class field for the outer IP header | +-----+-----+-----+-----+-----+-----+-----+-----+ | Hop Limit field for the outer IP header | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 4: Tunneling to New IP Address Extension When the MN receives the above extension, it recognizes the presence of a tunneling extension for a packet stream that did not include encapsulation before. The compression module infers the rest of the fields. The source IP address is that of its pAR, the destination address is its own new IP address, the Next Header is IPv6, Version field is 6 and the flow label is assumed to be zero. Using the inferred values as well as the received values, the compression module constructs the outer IP header. The inner IP header is constructed based on the context present and optionally the values received in the extension header. 3.3.2. Handling packets tunneled to MN's New Access Router The pAR may tunnel packets destined for the MN's previous IP address to the MN's nAR, which in turn forwards the packet to the MN. In such a case, the nAR processes the inner packet using the context present and sends the compressed packet alone (without any encapsulation extensions) to the MN (perhaps with some extensions). Thus, there is no separate extension necessary for this case. 4. Compression Context Transfer with Handover signaling In this section, we provide an illustration of how the compression context defined in the previous section can be carried along-with handover signaling. We use context transfer protocol for mobile nodes for our illustration here. The pAR transfers header compression contexts either upon receiving a Context Transfer Request (CT Request) from the nAR, or upon receiving an internally generated trigger (e.g., a link layer trigger). In the first case, the pAR receives a Context Transfer Request(CT Request) from the nAR. In the CT-Request message, nAR suplies the MN's previous IP address, the context type for header-compression, and a token authorizing context transfer as mentioned in [3]. In response to the CT Request message, pAR transmits a Context Transfer Data (CTD) message that includes the MN's previous IP address and the header compression contexts. In the second case, if the pAR receives an internally generated trigger, it may predictively transmit the CTD message to the potential nAR. Sometimes the transfer of compression contexts prior to the MN's arrival at the New Router may not be possible. In such a case, the MN may request the New Router to fetch the contexts from the Previous Router using the Context Transfer Start Request (CTSR) Message. The nAR in turn, can then send the CT Request message to the pAR to trigger the transfer of compression state. The context transfer protocol [3] provides more details on the various scenarios. 5. Header Compression Option Processing Rules at Routers When pAR receives a CT Request message, it MUST verify the authentication token of the CT Request according to its security association with the mobile node. If the authentication token is valid, pAR MUST subsequently return the requested header compression state as a context block in Context Transfer Data (CTD) message. The new access router (nAR) obeys the following: 1. If the required header compression state for the MN is available, the nAR MUST make the contexts available to the MN as soon as the authorization (when present) is successful. It MAY simply start sending the compressed packets. 2. If the compression state requested by a mobile node is not already available from a CTD message received from the Previous Router, the nAR MUST formulate the corresponding CT Request message to obtain the requested header compression state from the Previous Router either in response to the corresponding Context Transfer Start Request (CTSR) message from the MN, or in response to an internally generated trigger. After sending CT Data message for header compression, pAR MUST maintain the header compression contexts for HC_CONTEXT_SAVE_TIME in order to recover from lost CT Data messages. pAR SHOULD also maintain the contexts until HC_CONTEXT_PURGE_TIME. After that time, pAR MUST purge all context associated to the mobile node. 6. Message Formats Header compression options and suboptions are defined below for use in CT data messages. The general format for the options is shown in Figure 5. We assume that the 'V' bit specified in the definition of Context data block in [3] is always set to 0. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCOpt Type | HCOpt Len | HCOpt Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Header Compression Options, Suboptions, and Extensions Format 6.1. Header Compression Context Transfer Reply suboption The Header Compression Context Transfer Reply (HCRep) suboption is defined for pAR to transfer state to nAR in the CT data message. The HCRep suboption includes the necessary state for nAR to ``carry-over'' header compression. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID | CPT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Compression State Variables ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Header Compression Reply Data Elements The Option Type and Option Length fields of HCRep are followed by blocks consisting of [CID, CPT, Header Compression State variables] tuple(s). Each block has the format illustrated in figure 6. CID Compression Context Identifier CPT Compression Profile Type Header Compression State Variables Values for header compression state variables, in the format defined by the CPT The CID and CPT are 16-bit fields. For a particular CPT, the size of header compression state variables field is fixed; this allows inclusion of multiple tuples without requiring a length indicator. If the suboption length is zero, it indicates that pAR cannot supply the required header compression state to nAR. When the value of CPT is zero in a tuple, it indicates that the pAR cannot supply state information for the associated compression context identified by the CID. The processing of this suboption depends on the availability of required header compression state, and is done in accordance with requirements outlined in subsection 5. 7. Configurable Parameters The nodes supporting mobility defined in this document SHOULD be able to configure the parameters outlined below as well as those in [4]. Each table entry contains the name of the parameter and the default value. Parameter Name Default Value ------------------------------------------------- HC_CONTEXT_SAVE_TIME 2000 milliseconda HC_CONTEXT_PURGE_TIME 5000 milliseconds 8. Security Considerations All context transfer for header compression MUST be secured by use of the Authentication token specified in all CTP packets [3]. Thus, no additional vulnerability has been introduced. 9. IANA Considerations The Compression Profile Type (CPT) defined in this document requires IANA Type numbers. References [1] C. Bormann and et al. RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed (work in progress). Technical report, Internet Engineering Task Force. draft-ietf-rohc-rtp-09.txt, 2001. [2] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [3] J. Loughney and et al. Context Transfer Protocol. Internet Draft, Internet Engineering Task Force. draft-ietf-seamoby-ctp-01.txt, March 2003. [4] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. [5] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in progress). Internet Draft, Internet Engineering Task Force. draft-designteam-fast-mipv6-01.txt, February 2001. A. Context Transfer Data Reply Message Status codes A.1. Compression Profile Unavailable Acknowledgment Code Code: 02 (CPT_UNAVAILABLE) The above code is returned as part of the CTDR message if atleast one of the CPTs specified in the CT data message are not supported by the nAR. A.2. Resource Unavailable Error Code Code: 01 (RESOURCE_UNAVAILABLE) The RESOURCE_UNAVAILABLE error is returned when no resources are available. This code indicates that nAR does not have the resources required to set up header compression context(s) for this MN. The MN MUST deactivate the previous compression state. It MAY either start sending full headers in this case, or it may re-negotiate with nAR to activate a new compression profile. A.3. Bad Format Error Code Code: 03 (BAD_FORMAT) This error indicates that the context transfer data message was poorly formatted. If a router does not understand the format of a particular suboption, it sends a CTDR message with this code. Acknowledgements The authors would like to thank James Kempf, DoCoMo USA Labs, for the numerical example in Section 1. Addresses Questions about this memo can be directed to the authors: Rajeev Koodli Communications Systems Lab Nokia Research Center Manish Tiwari 313 Fairchild Drive Trapeze Networks Mountain View, California 94043 5753 W. Las Positas Blvd. USA Pleasanton, California 94588 Phone: +1-650 625-2359 USA EMail: rajeev.koodli@nokia.com Phone: +1-925 474-2278 Fax: +1 650 625-2502 EMail: manish@trapezenetworks.com Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502