Seamoby Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 20 July 2001 Communication Systems Laboratory Nokia Research Center Manish Tiwari Juniper Networks Context Relocation for Seamless Header Compression in IP Networks draft-koodli-seamoby-hc-relocate-01.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 options for the handover ICMP messages defined for IPv6 and suboptions for the destination options used by mobile nodes to request smooth handovers. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page i] Internet Draft Header Compression Context Relocation 20 July 2001 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 Router . . 9 4. Compression Context Transfer with Handover signaling 10 5. Header Compression ICMP Option Processing Rules at Routers 11 6. Message Formats 12 6.1. Header Compression Context Transfer Request ICMP Option . 12 6.2. Header Compression Context Transfer Reply ICMP Option . . 13 6.3. Header Compression Context Transfer Request SHIN Suboption 14 6.4. Header Compression Context Transfer SHAK Suboption . . . 14 7. Configurable Parameters 15 8. Security Considerations 15 9. IANA Considerations 15 A. Response Codes in the SHAK message 16 A.1. Compression Profile Unavailable Acknowledgment Code Format 16 A.2. Header Compression Context Transfer Error SHAK Suboption 16 A.3. Resource Unavailable Error Data Format . . . . . . . . . 17 A.4. Bad Format Error Data Format . . . . . . . . . . . . . . 17 A.5. Context Unavailable Error Data Format . . . . . . . . . . 18 B. Requesting Header Compression without Handover 19 Addresses 19 Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 1] Internet Draft Header Compression Context Relocation 20 July 2001 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 Router maintains a compression context for both the downlink and uplink packets. When handover takes place, for seamless operation, the New Router 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 New Router. 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 a Previous Router to a New Router in order to achieve seamless operation of header compression during handovers. For this purpose, we make use of the new seamless handover options defined in [4] 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 Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 2] Internet Draft Header Compression Context Relocation 20 July 2001 | +------------+ +-+ <.... | Previous | <==== < ====>: Uncompressed | | ---------- | Router | ------ > ----\ packet stream +-+ ....> | (Prtr) | ====> < \ ....>: Compressed MN | | \ packet stream | +------------+ +---------------+ | | IP | Correspondent | | | Network | Node(CN) | V | +---------------+ | / | +------------+ / +-+ <==== | New | <==== < / | | ---------- | Router | ------ > ----/ +-+ ....>. | (Nrtr) | < MN .+------------+ . . . . V discard Figure 1: Effect of Handover on Header Compression 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. While we make this distinction, we do explain how compression context instantiation and destruction can be carried out using our proposal in the appendix. 2. Terminology We define the following terms for use in this document. HAck Message The ICMP Handover Acknowledgment message, sent from the New Router to the Previous Router, and defined in [6]. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 3] Internet Draft Header Compression Context Relocation 20 July 2001 HI Message The ICMP Handover Initiate message, sent from the Previous Router to the New Router, and defined in [6]. New Router (Nrtr) The router to which the MN attaches after handover Previous Router (Prtr) 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 Previous Router 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). SHAK Message Any IPv6 message received by the mobile node containing the SHAK Destination Option defined in [4]. SHIN Message Any IPv6 message sent by the mobile node containing the SHIN Destination Option defined in [4]. SHREP Message The ICMP Smooth Handover Reply message, sent between access routers, and defined in [4]. SHREQ Message The ICMP Smooth Handover Request message, sent between access routers, and defined in [4]. 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 Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 4] Internet Draft Header Compression Context Relocation 20 July 2001 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 handover 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 New Router) 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. We also specify some extensions to convey the New IP address of the MN and to handle the possible tunneling of packets from the Previous Router to the MN. In the following, we provide the definitions for IPv6/UDP/RTP CPT. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 5] Internet Draft Header Compression Context Relocation 20 July 2001 3.1. Handover Uplink and Downlink CPT When the MN changes its default router, typically its IP address changes. The New Router needs to know the new IP address in order to correctly decompress the packets arriving from the MN. We propose that the MN supply this information once it definitively establishes its new IP address. This update is sent as an extension in any appropriate compressed packet similar to other extensions currently defined in [1]. The Previous Router includes an IR packet containing both the static chain and the dynamic chain as part of the Compression Profile. This IR packet is included as an option as shown in Figure 2. For details regarding the individual fields in the IR packet, 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 depnding 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 link layer in the compressed packets as in [1]. 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 Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 6] Internet Draft Header Compression Context Relocation 20 July 2001 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] Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 7] Internet Draft Header Compression Context Relocation 20 July 2001 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 Previous Router may tunnel packet to the MN. For example, in fast handovers, the Previous Router tunnels packets either directly to the MN's new IP address or to the New Router. 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 Previous Router then tunnels those packets to the MN's new IP address. In the following, we provide new tunneling extensions that the New Router uses when it receives packets from the Previous Router. 3.3.1. Extension for packets tunneled to MN's new IP Address Observe that the New Router 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 Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 8] Internet Draft Header Compression Context Relocation 20 July 2001 Figure 4 allows the New Router 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 Previous Router, the destination address is its own new IP address, the Next Header is IPv6, Vesrion 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 Router The Previous Router may tunnel packets destined for the MN's previous IP address to the MN's New Router, which in turn forwards the packet to the MN. In such a case, the New Router 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. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 9] Internet Draft Header Compression Context Relocation 20 July 2001 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 note that the compression contexts can be carried in other forms of messages as well, e.g., they could be carried in a Paging Message [3]. We use fast handover signaling for Mobile IPv6 for our illustration here. The Previous Router, in response to either the network-initiated handover or the mobile-initiated handover, sends a HI message to the New Router. In this HI message, it includes the Unsolicited Seamless Handover Reply (U-SHREP) option defined in [4], which carries the appropriate compression contexts. The actual contexts that are carried could depend on the knowledge that the Previous Router possesses regarding the compression capabilities of the New Router. We anticipate however, that some well-known CPTs would be supported by many different implementations. The Unsolicited SHREP option carries an authentication token for the New Router to verify prior to authorizing the feature contexts. This token uses the session key that gets established when the MN first connects to the Previous Router. Alternative to carrying the token, the Unsolicited SHREP message could instead carry the session key itself as one of the sub options. In any case, the network policy may require the New Router to authenticate the MN prior to granting network access as well as feature contexts. In such a case, the MN has to respond to an appropriate challenege from the New Router providing its own token that must match the one that the New Router possesses. See [3] for how this is performed for IP Paging. Once authorized (whenever enforced), the New Router makes the compression contexts available to the MN. The New Router SHOULD include a SHREP-Ack option in the HAck message to the Previous Router. 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. We provide the Seamless Handover Initiate (SHIN) option for the MN to request specific contexts, or all the contexts, which we assume to be the default case. This SHIN option can be embedded in the network authentication message, or it can also be sent along-with the Binding Update message. In response to the SHIN message, recognizing that the required state is not available, the New Router transmits a Seamless Handover Request (SHREQ) message with compression sub options. And, the Previous Router responds back with a Seamless Handover Reply (SHREP) message containing the actual QoS context information. See [4] for the details. It is worth noting that the New Router does not always possess the knowledge of MN's previous router and its previous IP address which are both needed in order to fetch the contexts. For instance, due to Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 10] Internet Draft Header Compression Context Relocation 20 July 2001 unfavorable terrain conditions, the MN may lose link connectivity with its current AR and establish a new link with a new AR. In such a case, the MN supplies the required information in the SHIN option, which in the default case contains the Previous Router address, MN's Previous IP Address and an optional authentication token. Since there is no established means for a MN to be certain in all the handover cases that the New Router has knowledge of its Previous Router and its Previous IP address, we propose including the SHIN option in all the handover scenarios. When the context is already present at the New Router, SHIN facilitates explicit authorization of feature contexts. When the context is not present, it triggers reactive context transfer. 5. Header Compression ICMP Option Processing Rules at Routers This section specifies certain detailed handling by the previous and new access routers (Prtr and Nrtr respectively) for header compression options. When Prtr receives a SHREQ message, it MUST verify the Authentication Data of the SHREQ according to its security association with the mobile node. Furthermore, Prtr MUST check the IPsec Authentication Header (AH) included in the SHREQ message by Nrtr, the originator of the SHREQ message. If the authentications are valid, Prtr MUST subsequently return the requested header compression state in options in a Seamless Handover Reply (SHREP) message sent to Nrtr. The new access router (Nrtr) obeys the following: 1. If the required header compression state for the MN is available, the New Router MUST make the contexts available to the MN as soon as the authorization (when present) is successful. It MAY indicate this to the MN through an appropriate sub option in the Seamless Handover Acknowledgment (SHAK) message. Instead, it can simply start sending the compressed packets. 2. If the compression state requested by a mobile node is not already available from a HI message received from the Previous Router, the New Router MUST formulate the corresponding options in an ICMP Seamless Handover Request (SHREQ) message to obtain the requested header compression state options from the Previous Router. After sending SHREP, Prtr MUST maintain the header compression contexts for HC_CONTEXT_SAVE_TIME in order to recover from lost SHREP messages. Prtr SHOULD also maintain the contexts until HC_CONTEXT_PURGE_TIME. After that time, Prtr MUST purge all context associated to the mobile node. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 11] Internet Draft Header Compression Context Relocation 20 July 2001 6. Message Formats Header compression options and suboptions are defined for use in several different protocol message types: - as an option or a sub option to a HI, HAck, SHREQ, or SHREP ICMPv6 messages. - as a suboption of an IPv6 destination option. - as an extension to a Mobile IPv4 registration request to be processed by a Foreign Agent. - as an extension to some other seamless handover message to be defined in the future for mobile nodes using IPv4. The general format for the options is the same in all cases, as shown in Figure 5. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCOpt Type | HCOpt Len | HCOpt Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Header Compression Options, Suboptions, and Extensions Format 6.1. Header Compression Context Transfer Request ICMP Option The HCReq suboption is sent by Nrtr to Previous Router in the SHREQ message to obtain header compression context on behalf of the mobile node. The New Router MAY request all of the relevant header compression context associated with the mobile node, by sending HCReq with suboption length equal to zero. Suboption Type: HCReq-ICMP Suboption Length: Variable The processing of this ICMP option at the Previous Router depends on the availability of required header compression state, and is done in accordance with requirements outlined in Section 5. The New Router MAY respond with the SHAK suboption defined in section 6.4. The New Router, Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 12] Internet Draft Header Compression Context Relocation 20 July 2001 possibly using the information sent by the Previous Router, MAY include suboption HCErr (defined below) in the SHAK message. 6.2. Header Compression Context Transfer Reply ICMP Option The Header Compression Context Transfer Reply suboption (HCRep) suboption is defined for Prtr to transfer state to Nrtr in the HI or SHREP ICMP messages. The HCRep suboption includes the necessary state for Nrtr 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 the HCRep ICMP option 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 Prtr cannot supply the required header compression state to Nrtr. In case of errors, Prtr SHOULD include the HCErr suboption defined in section A.2 in the SHREP message. When the value of CPT is zero in a tuple, it indicates that the Previous Router cannot supply state information for the associated context identified by the CID. In this case also, Prtr SHOULD include suboption HCErr (e.g., to indicate that suboption HCReq was incorrectly formatted) in the packet. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 13] Internet Draft Header Compression Context Relocation 20 July 2001 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. 6.3. Header Compression Context Transfer Request SHIN Suboption Note that the default operation of the SHIN message is to include request for all the contexts including the compression contexts. When the mobile node wishes to specifically continue header compression at Nrtr, it sends the Header Compression Context Transfer Request (HCReq) suboption in a message addressed to Nrtr containing a SHIN Destination Option. Suboption Type: HCReq-SHIN Suboption Length: Variable When the HCReq is present in a SHIN message and the suboption length is zero (the default value), this suboption indicates the MN's desire to continue with the same header compression features as prior to handover. 6.4. Header Compression Context Transfer SHAK Suboption The Header Compression Context Transfer Acknowledge suboption (HCAck) is defined for inclusion in the SHAK IPv6 Destination Option, and is used by Nrtr to respond to the mobile node. Suboption Type: HCAck-SHAK Suboption Length: Variable When the suboption length is zero (the default value), this suboption indicates that MN's request to continue with header compression was accepted at Nrtr without any modifications to the context parameters. When the suboption length is non-zero, the HCAck data has the format shown in Figure 7. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCAck Code | HCAck Len | HCAck Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Header Compression Context Transfer SHAK Suboption (HCAck) format Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 14] Internet Draft Header Compression Context Relocation 20 July 2001 Each acknowledgment code specifies the format of the HCAck data field, which contains the data associated with the acknowledgment. The currently defined acknowledgment code is specified in the appendix. 7. Configurable Parameters The nodes supporting mobility defined in this document SHOULD be able to configure the parameters outlined below as well those in [5]. Each table entry contains the name of the parameter and the default value. Parameter Name Default Value ------------------------------------------------- HC_CONTEXT_SAVE_TIME 2 * SHREQ_REXMIT_TIME HC_CONTEXT_PURGE_TIME 5 * SHREQ_REXMIT_TIME SHIN_WAIT_TIME 1000 milliseconds 8. Security Considerations All context transfer for header compression MUST be secured by use of the Authentication suboption [5], or the IPv6 Authentication Header [2]. 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] R. Koodli and Malinen J. Idle Mode Handover Support in IPv6 Networks(work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-idle-mode-ct-00.txt, November 2000. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 15] Internet Draft Header Compression Context Relocation 20 July 2001 [4] R. Koodli and C. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-00.txt, November 2000. [5] 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. [6] 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. Response Codes in the SHAK message A.1. Compression Profile Unavailable Acknowledgment Code Format The HC Acknowledgment Code block for CPT_UNAVAILABLE is as shown in figure 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCAck Code=2 | Length | [CID,New-CID] pairs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: CPT UNAVAILABLE Acknowledgment Data format Code: 02 (CPT_UNAVAILABLE) Length: Variable The data for the CPT_UNAVAILABLE acknowledgment code consists of [CID, New-CPT] tuple(s), one for each requested CPT that was unavailable. When the value of CPT is zero in a tuple, it indicates that the associated context identified by the CID was not activated. In this case, Nrtr MAY include suboption HCErr with an appropriate error code indicating the reason for failure to activate the context. A.2. Header Compression Context Transfer Error SHAK Suboption The Header Compression Context Transfer SHAK Error Suboption (HCErr) allows the access routers to supply error codes when activation fails for one or more header compression contexts. The HCErr data format is shown in Figure 9. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 16] Internet Draft Header Compression Context Relocation 20 July 2001 Suboption Type: HCErr-SHAK Suboption Length: Variable +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code | HCErr Length | HCErr Error Code Blocks... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Header Compression Context Transfer Error format Each error code specifies the format of the HCErr data field, which contains the data associated with the error condition. The currently defined error codes are specified in the following sections. A.3. Resource Unavailable Error Data Format The HC Error Code block for RESOURCE_UNAVAILABLE is as shown in figure 10 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code=1 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: RESOURCE UNAVAILABLE error format Code: 01 (RESOURCE_UNAVAILABLE) Length: 0 The RESOURCE_UNAVAILABLE error has no associated error data. This error is returned when no resources are available. This code indicates that Nrtr 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 Nrtr to activate a new compression profile. A.4. Bad Format Error Data Format The HC Error Code block for BAD_FORMAT is as shown in figure 11 Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 17] Internet Draft Header Compression Context Relocation 20 July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code=2 | Length | Offending Suboption ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: BAD FORMAT error format Code: 02 (BAD_FORMAT) Length: Variable This error indicates that the context transfer request was poorly formatted. If a router does not understand the format of a particular suboption, it sends HCErr with this code; and the data part contains the details of the suboption which caused this error. The Previous Router SHOULD send this suboption to Nrtr whenever appropriate, and Nrtr MAY send this suboption to the MN. A.5. Context Unavailable Error Data Format The HC Error Code block for CONTEXT_UNAVAILABLE is as shown in figure 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code=3 | Length | Unavailable CIDs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: CONTEXT UNAVAILABLE error format Code: 03 (CONTEXT_UNAVAILABLE) Length: Variable The HCErr data for this code contains the CIDs representing contexts which are not available for transfer. This might happen because the context has already been removed at both the routers in the fast handover case. Note that Nrtr MAY remove the state supplied by Prtr if Nrtr does not receive a SHIN message from the MN within HC_CONTEXT_SAVE_TIME. Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 18] Internet Draft Header Compression Context Relocation 20 July 2001 B. Requesting Header Compression without Handover In this section we provide a simple extension to the HCReq suboption for the MN to request header compression features independent of handover. The following extensions are destination suboptions that the MN can use when using explicit signaling to request header compression support. The following extensions can also be used along with well-defined compression messages, such as a Full Header packet, with appropriate modifications to those messages. Recall that the suboption length field in the HCReq message for handover purposes is zero. When this suboption length is non-zero, the MN supplies [CID, CPT] tuple(s) as parameters. Depending on the value of CPT, there are two cases. When CPT is non-zero in a tuple, it indicates that the MN wishes to make use of header compression for the context identified by CID using the specified CPT. The network node implementing header compression may then reply back using HCAck or HCErr suboptions. All of these suboptions can be sent piggy-backed to a well-defined compression message, or as destination option in explicit signaling messages. When the value of CPT is zero in a tuple, it indicates that the MN does not wish to continue header compression for the context identified by the associated CID. In this way, the MN can dynamically indicate its intention to tear down an existing compression context. When CPT is non-zero in a tuple, but its value is other than the existing value, it indicates that the MN wishes to continue header compression for the context identified by CID, but with a new CPT. In this way, the MN can dynamically indicate its intention to change the compression profile of an existing context. In both of these re-negotiation cases, the network node implementing header compression may then respond using HCAck or HCErr suboptions. Any of these suboptions can be sent piggy-backed to a well-defined compression message, or as a destination option in an explicit signaling message. The HCReq sub option itself may be sent in response to an application-driven event, such as a socket system call. Addresses Questions about this memo can be directed to the authors: Koodli, Tiwari, Perkins Expires 20 January 2002 [Page 19] Internet Draft Header Compression Context Relocation 20 July 2001 Rajeev Koodli Manish Tiwari Communications Systems Lab 1194 North Mathilda Avenue Nokia Research Center Sunnyvale, California 95089 313 Fairchild Drive USA Mountain View, California 94043 EMail: mtiwari@juniper.net USA Phone: +1-650 625-2359 EMail: rajeev.koodli@nokia.com 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 20 January 2002 [Page 20]