Internet Draft Robust Header Compression (rohc) WG Rajeev Koodli INTERNET DRAFT Manish Tiwari 13 July 2000 Charles E. Perkins Communication Systems Laboratory Nokia Research Center Header Compression State Relocation in IP Mobile Networks draft-koodli-rohc-hc-relocate-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. This document is an individual submission for the ROHC Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the rohc@cdt.luth.se mailing list. Distribution of this memo is unlimited. Abstract In networks with limited bandwidths, 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 handoffs 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 IPv6 and Mobile IPv6. Koodli, Tiwari, Perkins Expires 13 January 2001 [Page i] Internet Draft Header Compression State Relocation 13 July 2000 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Overview 4 4. Message Formats 5 5. Considerations 10 5.1. MN Considerations . . . . . . . . . . . . . . . . . . . . 10 5.2. New-Router Considerations . . . . . . . . . . . . . . . . 10 5.3. Previous Router Considerations . . . . . . . . . . . . . 11 6. Security Considerations 11 7. IANA Considerations 11 Addresses 11 Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 1] Internet Draft Header Compression State Relocation 13 July 2000 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 perhaps application layers (such as http) in the future. 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 point as well) due to mobility of the user. This device mobility then requires potential 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 hand-off, the MN maintains a compression context for both the downlink and uplink packets. When hand-off takes place, for seamless operation, the New-Router must have appropriate compression state. The failure to possess this state could result in discarding the uplink packets and transmission of uncompressed packets in the downlink as shown in Figure 1 | MN +-----------+ +-+ <~~~~ | Previous | <-### < ###->: Uncompressed | | ---------- | Router | ------ > ----\ packet stream +-+ ~~~~> | (R1) | ###-> < \ ~~~~>: Compressed | | \ packet stream | +-----------+ +--------+ | | IP | Corr. | | | Network |Node(CN)| V | +--------+ | / | MN +-----------+ / +-+ <-### | New | <-### < / | | ---------- | Router | ------ > ----/ +-+ ~~~~> *| (R2) | < *| | *+-----------+ * * * V discard Figure 1: Effect of Handoff on Header Compression Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 2] Internet Draft Header Compression State Relocation 13 July 2000 In this document, we provide a mechanism to relocate header compression state from Previous-Router to New-Router in order to achieve seamless operation of header compression during handoffs. For this purpose, we make use of the new smooth handoff messages defined in [2] and specific suboptions for header compression defined in this document. 2. Terminology We define the following terms in this document. New-Router The router to which the MN attaches to subsequent to handoff Previous-Router The MN's default router prior to handoff New-CoA The Care-of-Address of the Mobile Node (MN) when attached to New-Router Previous-CoA The Care-of-Address of the Mobile Node (MN) when attached to Previous-Router Context Identifier (CID) 8 or 16-bit unsigned integer that identifies a particular header compression context. In order to make compression context unique across handoffs, this field may be used in conjunction with an identifier such as link-layer address. Filter This field identifies the flow undergoing compression that matches the CID. This field is further sub-divided into Filter-Type and Filter-Value. Filter-Type is a field which identifies the particular Filter-Value that is used. The size of Filter-Value is understood from the Filter-Type field. Size of this field is TBD. Compression Profile Type (CPT) This is an object that indicates what type of header compression is desired. Possible types are: 1. IPv6 header compression 2. IP/UDP/RTP header compression Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 3] Internet Draft Header Compression State Relocation 13 July 2000 3. IP/TCP header compression Each CPT is allocated an IANA type number. Size of each of the CPTs is fixed. 3. Overview We follow the handoff classification outlined in [2] for our purposes. The framework there describes "Network-Controlled, Mobile-Assisted" (NCMA) and "Mobile-Controlled, Network-(un)Assisted" (MCNA) scenarios. We start with the MCNA case first. When the MN moves to a new point of IPv6 attachment, the IP layer in the MN sends a standard Router Solicitation message. The New-Router responds back with a Router Advertisement message. This Router Advertisement message is enhanced to include a `C' bit in the Reserved field that indicates header compression capability, including the ability to support header compression subsequent to handoff, at the New-Router. The MN uses the Router Advertisement message to form a New-CoA and parses the `C' bit to verify header compression support at the New-Router. Subsequently, following the framework in [2], the MN sends a combined Binding Update message (intended for its mobility agent) and a Smooth Handover Initiate (SHIN) message to the New-Router. In the SHIN message the MN includes sub-options for header compression state relocation for both the New-Router and the Previous-Router. In response to receiving the SHIN message with header compression sub-options destined to the New-Router, the New-Router MUST activate new header compression context if it already has the compression state available. This is possible in Network-Controlled-Mobile-Assisted (NCMA) handoffs, in which the Previous-Router pushes state information to the New-Router as discussed in [2]. The number and the type (i.e., the Compression Profile Type (CPT)) of such contexts activated depends on the semantics of the sub-option. The default behavior is to simply provide support as prior to handoff. If the New-Router can activate header compression context in response to the SHIN message, it SHOULD send a SHACK message back to the MN immediately, enabling header compression to be used at the MN as soon as possible. In addition, the New-Router MUST send a Smooth Handover Request (SHREQ) message to the Previous-Router (since this message creates a binding for the MN at the Previous-Router) and this SHREQ message MAY contain header compression sub-options. These header compression sub-options SHOULD be ignored by the Previous-Router if it has already supplied the context to the New-Router. If header compression state is not available, the New Router must then construct a Smooth Handover Request (SHREQ) with header compression sub-options for the Previous-Router. These sub-options must include Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 4] Internet Draft Header Compression State Relocation 13 July 2000 the sub-options supplied by the MN for both the New-Router and the Previous-Router, as well as those intended for the Previous-Router only. If the header compression sub-options intended for the New-Router alone cannot be processed due to the absence of compression state, as would be the case in MCNA, the New-Router MUST include those sub-options as well in the SHREQ message (as sub-options from New-Router to the Previous-Router only). This allows the Previous-Router to supply back these same sub-options along with the required context information so that compression context initialization can take place when the SHREP message arrives at the New-Router. In response to receiving the SHREQ message, the Previous-Router prepares to transfer the requested header compression state to the New-Router after proper authentication of the request by the MN, and optionally that of the originator of the SHREQ message itself. The Previous-Router constructs a Smooth Handover Reply (SHREP) message containing the appropriate sub-options for the New-Router that allow it to initialize each of the new header compression contexts. In the SHREP message, the Previous-Router MUST also copy the sub-options present in ``MN to New-Router and Previous-Router'' and those present in ``New-Router to Previous-Router'' in the SHREQ message when the New Router does not yet have a compression state for the MN. The header compression options meant for the Previous Router SHOULD be ignored if it has already transferred the state to the New Router. The Previous-Router must also keep the context active for CONTEXT_SAVE_TIME in order to recover from lost SHREP messages. When the New-Router receives a SHREP message with appropriate header compression sub-options, it MUST generate a Smooth Handover Acknowledgement (SHACK) message back to the MN with destination sub-options containing the response codes for the sub-options requested in the SHIN message. A successful header compression context activation at the New-Router allows the MN to resume transmission and reception of compressed packets with its correspondent nodes. 4. Message Formats The header compression sub-option is defined as a part of destination option used by mobile IPv6. The general format for the sub-option is as shown in Figure 2. The guidelines for the relative ordering of sub-options in the SHIN, SHREQ, SHREP and SHACK messages are presented in [2]. The MN, the New-Router and the Previous-Router MUST follow those guidelines for individual messages while constructing the header compression sub-options. As an example, in the SHIN message, the structure shown in Figure 3 is used for including the sub-options. Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 5] Internet Draft Header Compression State Relocation 13 July 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Sub-Option Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Sub-options Format 1. SHIN Destination Options hdr 2. Suboptions for New-Router 3. Suboptions for use by both New-Router and Previous-Router 4. Suboptions for Previous-Router Figure 3: Suboptions Structure for SHIN Destination Option For header compression state transfer purposes, the following common sub-options from the MN to the New-Router and the Previous-Router are currently defined. These sub-options are included for use by both New-Router and Previous-Router as shown in item 3 in Figure 3. The processing by each router is outlined below under each sub-option definition. Sub-option Type: 5 Sub-option Length: variable When this suboption type does not have suboption data, i.e., the suboption length is zero, it indicates to the Previous-Router MN's willingness to continue with header compression at the New-Router as prior to handoff. The Previous-Router then prepares to transfer all the [CID, CPT, Filter] tuples along with the header compression state appropriate for the CPT object. When the suboption length is non-zero, the MN supplies [CID, New-CPT] tuple, indicating that it wishes to use a new CPT for the context identified by the CID. The Previous-Router MUST ignore the New-CPT and simply supply the state indexed by the CID. Once the New-Router has the required state, it determines whether it can support the New-CPT or not. If it does support the New-CPT, the New-Router simply uses the appropriate state for the New-CPT. Sub-option Type: 6 Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 6] Internet Draft Header Compression State Relocation 13 July 2000 Sub-option Length: variable When suboption length is zero, this sub-option type indicates that the MN does not wish to continue compression at the New-Router. Thus, the Previous-Router MUST NOT send any state information to the New-Router. When the length is non-zero, the MN includes a list of CIDs for which it does not wish to have header compression. In response to this suboption, the New-Router MUST generate a SHACK message with suboption 8 defined below if it has the required compression context. If the New-Router does not possess the state, and there is valid compression context at the Previous-Router, the Previous-Router MUST include suboption 8 defined below in the SHREP message. For header compression state transfer purposes from the Previous-Router to the New-Router, the following sub-options are valid. Sub-option Type: 7 Sub-option Length: variable This sub-option type includes the necessary state for the New-Router to "carry-over" header compression, and is in response to sub-option type 5 in the BU message. The sub-option data field consists of the following tuple [CID, CPT, Filter, Header Compression State variables]. For a particular CPT, the size of header compression state variables field is fixed. There can be more than one such tuple as a part of this sub-option. In addition to this sub-option, the Previous-Router MAY include a sub- option specifically for the MN for acknowledging any applicable header compression sub-option request. The following sub-option may originate from either the New-Router or the Previous-Router, depending on the availability of the appropriate header compression context. Sub-option Type: 8 Sub-option Length: 0 This sub-option type indicates that the router understands that the MN does not wish to continue header compression at the New-Router. The router possessing the header compression state MAY perform garbage collection after CONTEXT_SAVE_TIME defined in [2]. Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 7] Internet Draft Header Compression State Relocation 13 July 2000 For header compression state transfer purposes from the New-Router to the MN, the following sub-options are valid. Sub-option Type: 9 Sub-option Length: variable When the suboption length is zero, this sub-option type indicates to the MN that its request to continue header compression at the New-Router was accepted, and that the MN may ensue sending compressed packets. When the suboption length is non-zero, then this suboption indicates to the MN that its request was accepted with the new CID(s) outlined as [Old-CID, New-CID] tuple(s) in the suboption data. Sub-option Type: 10 Sub-option Length: variable This sub-option indicates that the requested CPT is not supported and a matching [CID, New-CPT] tuple is included in the sub-option data field. The following sub-option (sub-option 11) can originate either at the New-Router or at the Previous-Router. Sub-option Type: 11 Sub-option Length: variable This sub-option indicates that there was an error in transferring state from the Previous-Router to the New-Router, and the error code, followed by error data is included in the sub-option data field. The following error codes are currently defined: Code: 00 Data: [CID, New-CPT] tuple(s) Meaning: Existing CPT in use. This code indicates that the requested CPT is in use and New-CPT(s) are outlined as [CID, New-CPT] tuple(s) in the Data field. Code: 01 Data: None Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 8] Internet Draft Header Compression State Relocation 13 July 2000 Meaning: No resources. The new router does not have the resources required to set up a header compression state for this MN. The MN MAY start sending full headers in this case, and relinquish compression, or it may re-negotiate with the New-Router. Code: 02 Data: Details Meaning: Wrong format of sub-option. If the New-Router or the Previous-Router do not understand the format of a particular sub-option, they SHOULD send the sub-option with this code, and the data part MAY contain the details of the sub-option which caused this error. Code: 03 Data: Details Meaning: Administratively prohibited. The new router or the previous router does not support a particular sub-option due to administrative reasons. The data part consists of the details of the sub-option which caused this error. Code: 04 Data: None Meaning: Timed Out. If a sub-option requires creation of a state at the new router, before a SHREQ message is sent to the previous router, the new router MUST time out and remove that state, so that lost SHREQ messages between the new router and the previous router do not lead to a zombie state at the new router. The new router MUST also send a SHACK message to the MN with this error code in this case. Code: 05 Data: Details Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 9] Internet Draft Header Compression State Relocation 13 July 2000 Meaning: Reason Unspecified. The data part MAY contain details of sub-options which led to this error. Code: 06 Data: Details Meaning: Context not available. This might happen because the context has already been removed at the previous router and the new router, in the MCNA case. The new router MUST remove the state pushed by the previous router after a timeout if the MN does not come up within that time. 5. Considerations 5.1. MN Considerations After sending the SHIN message, the MN MUST either wait for SHIN_WAIT_TIME for the SHACK message or send full headers until it receives a SHACK message from the New Router. When the required state is available at the New-Router, it may start sending compressed packets to the MN even before it receives a SHIN message from the MN. If this happens, then the MN may resume header compression without having to wait for the SHACK message to arrive from the New-Router. The MN MUST stop sending compressed packets over the previous link either after it receives a SHACK message or a compressed packet from the New-Router. 5.2. New-Router Considerations In response to the arrival of a SHIN message containing header compression sub-options to it only, the New-Router MUST include those sub-options in the SHREQ message to the Previous-Router when the header compression context is not present. When it receives a SHREP message with suitable sub-options and the header compression context, the New-Router MUST activate the header compression context. The New-Router MUST inform the MN about the availability of a compression state as soon as possible, either by sending an explicit SHACK message or by forwarding compressed packets to the mobile node. If the New-Router has a compression state for the MN when it receives a SHIN message, it SHOULD reply to the message immediately by sending a SHACK message. When the New-Router establishes the compression state for the MN, it can potentially recieve packets for the MN either from correspondent nodes, or from the Previous Router. The New Router SHOULD Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 10] Internet Draft Header Compression State Relocation 13 July 2000 maintain the context needed to compress the packets recieved from the Previous-Router, and MAY provide indication to the MN regarding the path (i.e., tunneled through the Previous-Router or directly received by the New-Router) traversed by a particular packet. 5.3. Previous Router Considerations The Previous-Router SHOULD attempt to forward the compression state corresponding to an MN undergoing handoff as soon as it can, to the New-Router. The packets destined to the MN, which reach the Previous-Router after the SHREP message has been sent, are encapsulated and forwarded to the New Router. The previous router should not apply any compression to these packets. The Previous-Router MUST replicate the sub-options supplied by the New-Router in the SHREQ message in its response message (SHREP). 6. Security Considerations All context transfer for header compression SHOULD be secured by use of the Authentication suboption [2], or for some circumstances IPv6 Authentication Header [1]. Thus, no additional vulnerability has been introduced. 7. IANA Considerations The Compression Profile Type (CPT) defined in this document requires IANA Type numbers. References [1] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [2] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-koodli-smoothv6-00.txt, July 2000. Addresses The working group can be contacted via the current chairs: Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 11] Internet Draft Header Compression State Relocation 13 July 2000 Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors: Rajeev Koodli Manish Tiwari Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2610 EMail: rajeev.koodli@nokia.com EMail: manisht@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 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 Koodli, Tiwari, Perkins Expires 13 January 2001 [Page 12]