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