Context and Micro-mobility Routing (seamoby) WG Rajeev Koodli
INTERNET DRAFT Manish Tiwari
22 February 2001 Charles E. Perkins
Communication Systems Laboratory
Nokia Research Center
Context Relocation for Seamless Header Compression in IP Networks
draft-koodli-seamoby-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 seamoby Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the seamoby@cdma_2000.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 22 August 2001 [Page i]
Internet Draft Header Compression Context Relocation 22 February 2001
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 3
3. Overview 4
3.1. Compression Profiles and Compression Profile Type . . . . 5
3.2. Header Compression ICMP Option Processing Rules at Routers 6
3.3. Processing SHREP messages . . . . . . . . . . . . . . . . 6
4. Message Formats 7
4.1. Header Compression Context Transfer Request SHIN Suboption 8
4.2. Header Compression Context Transfer Request ICMP Option . 8
4.3. Header Compression Context Transfer Reply ICMP Option . . 9
4.4. Header Compression Context Transfer SHAK Suboption . . . 10
4.4.1. Compression Profile Unavailable Acknowledgment Code
Format . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Header Compression Context Transfer Error SHAK Suboption 11
4.5.1. Resource Unavailable Error Data Format . . . . . 11
4.5.2. Bad Format Error Data Format . . . . . . . . . . 12
4.5.3. Context Unavailable Error Data Format . . . . . . 12
5. Mobile Node Considerations 13
6. New Router Considerations 13
7. Previous Router Considerations 14
8. Configurable Parameters 14
9. Security Considerations 14
10. IANA Considerations 14
A. Requesting Header Compression without Handover 15
Addresses 16
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 1]
Internet Draft Header Compression Context Relocation 22 February 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 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 the
figure.
| +------------+
+-+ <.... | 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
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 2]
Internet Draft Header Compression Context Relocation 22 February 2001
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 [3]
and specific options for header compression defined in this document.
As defined here, header compression contexts are created or destroyed
always as a result of application events. In particular, a fresh
compression context is never created except by some event that can be
associated with a change in state related to some application. This
means that new header compression state is typically not created nor is
destroyed as part of a context transfer. We use this observation to
effect a substantial simplification for the control structures needed
during handovers, at the cost of the need for additional specification
for the creation and destruction of header compression contexts. The
specification for the latter protocol operations is outside the scope
of this document; they need to be closely aligned with results to be
obtained in the "Robust Header Compression" [rohc] working group.
Furthermore, such protocol specifications should be associated with
an appropriate programming interface in order to be effectively used
by applications. 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].
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
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 3]
Internet Draft Header Compression Context Relocation 22 February 2001
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.1).
SHAK Message
Any IPv6 message received by the mobile node containing
the SHAK Destination Option defined in [3].
SHIN Message
Any IPv6 message sent by the mobile node containing the
SHIN Destination Option defined in [3].
SHREP Message
The ICMP Smooth Handover Reply message, sent between
access routers, and defined in [3].
SHREQ Message
The ICMP Smooth Handover Request message, sent between
access routers, and defined in [3].
3. Overview
We follow the handover classification outlined in [3] for our
purposes. The framework there describes a ``basic handover'' scenario
as the one in which context transfer takes place as a reaction to
explicit signaling from the mobile node after it attaches to the New
Router. In the ``fast handover'' scenario, the Previous Router supplies
context information even before the mobile node attaches to the New
Router. We begin with the basic handover scenario.
When the MN moves to a new point of IPv6 attachment, it receives
a Router Advertisement message. This Router Advertisement message
includes a new `C' bit that indicates header compression capability,
including the ability to support header compression subsequent to
handover, at the New Router. The MN uses the Router Advertisement
message to configure a new access address (Naddr) [5, 1] and inspects
the `C' bit to verify header compression support at the New Router.
Subsequently, following [3], the MN sends a Seamless Handover Initiate
(SHIN) message to the New Router. In the SHIN message the MN includes
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 4]
Internet Draft Header Compression Context Relocation 22 February 2001
suboptions for header compression state relocation for both the New
Router and the Previous Router.
The New Router' response to header compression suboption(s) in the
SHIN message depends on the availability of required header compression
state. The rules in sections 3.2 summarize the behavior of the routers
in the two cases when the required header compression state is either
available or not at the New Router when the New Router receives a SHIN
message. In summary, if the required state is not available, the New
Router transmits a Seamless Handover Request (SHREQ) message with header
compression sub options. And, the Previous Router responds back with
a Seamless Handover Reply (SHREP) message containing the actual header
compression context information.
In the fast handover scenario, the Previous Router, perhaps in
response to a trigger from the mobile node (or some other network
entity), gratuitously supplies the context information in an unsolicited
SHREP option containing header compression contexts. In this case,
when the MN sends a SHIN message with header compression sub options to
the New Router, the required state would already be present at the New
Router, thus facilitating expedited context activation.
3.1. Compression Profiles and Compression Profile Type
A compression profile specifies the structure of the state variables
which are used for header compression. The Compression Profile Type
(CPT) provides a way to indicate which compression profile is in use
for a particular packet stream. For seamless header compression, the
compression engines located at separate network nodes must agree on the
structure of these state variables. When the target compression engine
receives the compression state from the appropriate handover message,
it will instantiate an instance of a compression state machine for the
packet stream in question. That new state machine will be created with
the values of the state variables taken from the header compression
option contained in the handover message, and interpreted according to
the data structure and format selected by the CPT.
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
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 5]
Internet Draft Header Compression Context Relocation 22 February 2001
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 4. Note that CPTs may be used in
options and suboptions specified as part of protocols outside the scope
of this document.
3.2. 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 process header compression suboption(s)
immediately, generate appropriate suboption(s) for a Seamless
Handover Acknowledgment (SHAK) message, and send the SHAK message
immediately. This action by the New Router expedites the process
of establishing header compression context(s) for the MN during
fast handovers.
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.
3.3. Processing SHREP messages
During fast handovers, Prtr supplies state information in the
ICMP Handover Initiate (HI) message. If Nrtr receives a HI message
containing header compression context records, it acknowledges receipt
by sending a HAck message to Prtr. The rest of this section applies to
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 6]
Internet Draft Header Compression Context Relocation 22 February 2001
the reception of a SHREP message after Nrtr has sent a SHREQ message
requesting the handover of compression context associated to the mobile
node.
The successful processing of header compression suboptions contained
in a message received by new access router leads to the creation of new
compression contexts. The type (i.e., the Compression Profile Type
(CPT)) and the number of such contexts activated depends on the contents
of the individual header compression options. The default behavior
is to simply provide the same support as prior to handover, or else a
default set of capabilities when context from Prtr is unavailable.
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.
When Nrtr receives a SHREP message with appropriate header
compression suboptions, it MUST generate a SHAK message back to the
MN with destination suboptions containing the response codes for
the suboptions 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 new
access router, and therefore maintain timely communication with its
correspondent nodes.
4. 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 2.
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 7]
Internet Draft Header Compression Context Relocation 22 February 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCOpt Type | HCOpt Len | HCOpt Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Header Compression Options, Suboptions,
and Extensions Format
4.1. Header Compression Context Transfer Request SHIN Suboption
When the mobile node wishes to 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.
4.2. 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 3.2. The New Router
MUST respond with the SHAK suboption defined in section 4.4. The New
Router, possibly using the information sent by the Previous Router, MAY
include suboption HCErr (defined below) in the SHAK message.
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 8]
Internet Draft Header Compression Context Relocation 22 February 2001
4.3. 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 3: 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 3.
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 4.5 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.
The processing of this suboption depends on the availability of
required header compression state, and is done in accordance with
requirements outlined in subsection 3.2.
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 9]
Internet Draft Header Compression Context Relocation 22 February 2001
4.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 4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCAck Code | HCAck Len | HCAck Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Header Compression Context Transfer SHAK
Suboption (HCAck) format
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 following
section.
4.4.1. Compression Profile Unavailable Acknowledgment Code Format
The HC Acknowledgment Code block for CPT_UNAVAILABLE is as shown in
figure 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCAck Code=2 | Length | [CID,New-CID] pairs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: CPT UNAVAILABLE Acknowledgment Data format
Code: 02 (CPT_UNAVAILABLE)
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 10]
Internet Draft Header Compression Context Relocation 22 February 2001
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.
4.5. 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 6.
Suboption Type: HCErr-SHAK
Suboption Length: Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCErr Code | HCErr Length | HCErr Error Code Blocks...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 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.
4.5.1. Resource Unavailable Error Data Format
The HC Error Code block for RESOURCE_UNAVAILABLE is as shown in
figure 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCErr Code=1 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RESOURCE UNAVAILABLE error format
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 11]
Internet Draft Header Compression Context Relocation 22 February 2001
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.
4.5.2. Bad Format Error Data Format
The HC Error Code block for BAD_FORMAT is as shown in figure 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCErr Code=2 | Length | Offending Suboption ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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.
4.5.3. Context Unavailable Error Data Format
The HC Error Code block for CONTEXT_UNAVAILABLE is as shown in
figure 9
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
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 12]
Internet Draft Header Compression Context Relocation 22 February 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCErr Code=3 | Length | Unavailable CIDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: CONTEXT UNAVAILABLE error format
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.
5. Mobile Node Considerations
After sending the SHIN message, the mobile node SHOULD NOT send
compressed headers until it receives a SHAK message from Nrtr.
Furthermore, the mobile node MUST maintain its previous header
compression context for SHIN_WAIT_TIME unless it first receives a SHAK
message from Nrtr. At any time after sending the SHIN message, the
mobile node MAY send full headers until it receives a SHAK message from
Nrtr. When the required state is available, Nrtr may start sending
compressed packets to the mobile node even before it receives a SHIN
message from the mobile node. If this happens, then the mobile node
MUST resume header compression without having to wait for the SHAK
message to arrive from Nrtr. The mobile node MUST NOT send compressed
packets over the previous link after it receives a either SHAK message
or a compressed packet from Nrtr.
6. New Router Considerations
In response to the arrival of a SHIN message containing header
compression suboptions, Nrtr MUST include those suboptions in the SHREQ
message to Prtr if the header compression context(s) is(are) not already
present. When it afterwards receives a SHREP message with suitable
header compression context(s), the New Router MUST attempt to activate
the header compression context(s).
The New Router MUST inform the mobile node about the availability of
a compression state as soon as possible, either by sending an explicit
SHAK message or by forwarding compressed packets to the mobile node. If
Nrtr has the compression state for the mobile node when it receives a
SHIN message, it MUST reply to the message immediately by sending a SHAK
message. When Nrtr establishes the compression state for the mobile
node, it can potentially receive packets for the mobile node either from
correspondent nodes, or from the Previous Router. The New Router SHOULD
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 13]
Internet Draft Header Compression Context Relocation 22 February 2001
maintain the compression context needed to compress the packets received
from Prtr.
7. Previous Router Considerations
The Previous Router SHOULD attempt to forward the compression state
for an MN undergoing handover as soon as it can, to Nrtr. The Previous
Router SHOULD NOT compress encapsulated packets.
8. Configurable Parameters
The nodes supporting mobility defined in this document SHOULD be able
to configure the parameters outlined below as well those in [4]. 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
9. Security Considerations
All context transfer for header compression MUST be secured by use of
the Authentication suboption [4], or the IPv6 Authentication Header [2].
Thus, no additional vulnerability has been introduced.
10. IANA Considerations
The Compression Profile Type (CPT) defined in this document requires
IANA Type numbers.
References
[1] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) (work in progress). Internet Draft, Internet
Engineering Task Force, May 2000.
[2] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 14]
Internet Draft Header Compression Context Relocation 22 February 2001
[3] 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.
[4] R. Koodli and C. Perkins. A Framework for Smooth Handovers
with Mobile IPv6 (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-koodli-mobileip-smoothv6-01.txt, November 2000.
[5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[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. 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
Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 15]
Internet Draft Header Compression Context Relocation 22 February 2001
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
The working group can be contacted via the current chairs:
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 22 August 2001 [Page 16]