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]