Network Working Group Wang Hui
INTERNET-DRAFT Li Jinsheng
Expires: May 29 2003 Hong Peiling
Infonet Lab,USTC
Nov. 29, 2002
RObust Header Compression (ROHC):
A Compression Profile for Mobile IPv6
<draft-hwang-rohc-mipv6-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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract
The original RObust Header Compression (ROHC) RFC, RFC 3095, defines
a framework for header compression, along with compression protocols
(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed
packet streams. And another draft [IPPROFILE] posted by Jonsson
deals with the IP only profile. However, no profile was defined for
compression of IP extension headers. But in the coming wireless
applications, mobile IP will play an important role. In mobile IPv4,
there is no difference to the packet's IP header, so we don't have to
make a profile for mobile IPv4; while as to mobile IPv6[MIPV6], there
is difference, since some specific IPv6 extension headers will be
included in almost every packet in the mobile IPv6 packets. The
extension headers will also cost a lot of bandwidth, and we should do
compression over them. This document addresses this issue and
defines a ROHC compression profile for mobile IPv6, which may work as
a complementarity to the profiles defined by RFC3095.
Wang [Page 1]
INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................2
3. Changes to packets sent and received within a MN..............3
4. ROHC MIPv6 Compression (Profile 0x????).......................4
4.1 The HAO structure and its compression.....................4
4.2 The type 2 routing header structure and its compression...5
4.3 Initialization............................................5
4.4 Other considerations......................................5
5. Security Considerations.......................................6
6. IANA Considerations...........................................6
7. References....................................................6
8. Author's Address..............................................6
1. Introduction
The original RObust Header Compression (ROHC) RFC [RFC3095] defines
a framework for header compression, along with compression protocols
(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed
packet streams. The ROHC framework is designed to apply to wireless
environment, while in the experiment of deploying the wireless IP
network, we found mobile IP will play a more and more important role.
Mobile IP will bring some changes to the IP header. There is a need
for a ROHC profile to deal with these changes.
In mobile IPv4 [MIPv4], there is no difference to the packet's IP
header, so we don't have to make a profile for mobile IPv4; while as
to mobile IPv6[MIPV6], there is difference, for some specific IPv6
extension headers will be included in almost every packet in the
mobile IPv6 packets. These extension headers will also cost a lot of
bandwidth, and we should do compression over them.
In my experience of implementing mobile IPv6, I made a integration
with the ROHC to enhance the performance. In the integration, I
defined a special 'profile' to deal with the mobile IPv6 extension
headers. And in this document, I will introduce this special
profile, and I hope it would be included into the main ROHC profile
tree after some revisions.
This document addresses this issue and defines a ROHC compression
profile for mobile IPv6, which may work as a complementarity to the
profiles defined by RFC3095.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119].
The mobile IPv6 related terms are the same as defined in section 3.2
in [MIPv6]. Please refer to it.
Wang [Page 2]
INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002
3. Changes to packets sent and received within a MN
[MIPv6] has introduced some new IPv6 protocol, message Types, and
destination option. The detailed description of these changes can
be found in section 6 in [MIPv6]. Here we have a brief review of
these changes.
When the mobile node (MN) is in its home network, there is no
difference and the MN acts as normal Internet node. For packets
sent by a mobile node while it is at home, no special Mobile IPv6
processing is required.
While a mobile node is away from home, it continues to use its home
address, as well as also using one or more care-of addresses. For
packets sent by the mobile node sent while away from home using the
mobile node's home address as the source, special Mobile IPv6
processing of the packet is required. Usually the MN will directly
delivery the packets to its CN. In this case, the MN SHOULD arrange
to supply the home address in a Home Address option, and allowing
the IPv6 header's Source Address field to be set to one of the
mobile node's care-of addresses; the correspondent node will then
use the address supplied in the Home Address option to serve the
function traditionally done by the Source IP address in the IPv6
header. The mobile node's home address is then supplied to higher
protocol layer and applications. The Home Address Option(HAO) is
carried in the Destination Header.
Usually the CN will has a Binding Cache entry for the MN and so
packets sent by a correspondent node to the MN will be sent by the
correspondent node using a type 2 routing header. The packet will
be addressed to mobile node's care-of address, with the final hop in
the routing header directing the packet to the mobile node's home
address; the processing of this last hop of the routing header is
entirely internal to the mobile node, since the care-of address and
home address are both addresses within the mobile node.
Detailed operations on the packets in the above mobile IPv6 node can
be found in [MIPv6]. See from the above discussions, we could tell
that when the MN is away from its home network and plugs to the
foreign network access router, the packets sent and received by the
MN will be modified by the MIPv6 layer, according to [MIPv6], as to
gain the mobility. Here are a brief summarization :
While MN is away from home network, commonly
o packets sent from a MN will be modified to include a 'Home
Address Option'(HAO for short) in the Destination Header.
o packets received by a MN sent from the CN will contain a type 2
routing header.
Wang [Page 3]
INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002
Except the above tow kinds of packets, there are other packets
including the mobility header. The Mobility Header is an extension
header used by mobile nodes, correspondent nodes, and home agents in
all messaging related to the creation and management of bindings.
But as to the header compression considerations, these messages act
as signaling message and are only sent in a very low frequency so we
do not need to compress them.
So in the ROHC MIPv6 profile we only compress the HAO and the type 2
routing header.
4. ROHC MIPv6 Compression (Profile 0x????)
From the above analysis, we can see what the ROHC profile would deal
with are the destination header(HAO) and the type 2 routing header.
And the other headers, such as IPv6 basic header, UDP header and RTP
header etc. , will be treated the same as the normal IPv6 packets.
So what we should do is to define a special profile to cope with the
destination header and the type 2 routing header and this special
profile would work as a supplement to the profiles defined in
RFC3095. For example, the 'IPv6/MIPv6/UDP/RTP' will be considered as
'IPv6/UDP/RTP' profile(defined in RFC3095) plus 'MIPv6' profile.
The profile ID is TBD <To be assigned by IANA>.
4.1 The HAO structure and its compression
The Home Address option is carried by the Destination Option
extension header (Next Header value = 60). It is used in a packet
sent by a mobile node while away from home, to inform the recipient
of the mobile node's home address.
The Home Address option is encoded in type-length-value (TLV) format
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'Next Header', 8-bit selector, identifies the type of header
immediately following the routing header, which uses the same values
as the IPv6 Next Header field [IPv6]. 'Header Ext Len' is the length
of this Destination Header. 'Option Type' would be '0xC9', and
'Option Length' MUST be set to 16 [MIPv6]. So the four fields are
Wang [Page 4]
INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002
all static within a stream packets. The 'Home Address' indicates
the MN's home address, which in a specific UDP or TCP stream is
static too.
So the whole HAO header of one stream would all be static context.
We can compress this header to be 0-bit.
4.2 The type 2 routing header structure and its compression
Mobile IPv6 defines a new routing header variant, the type 2
routing header, to allow the packet to be routed directly from a
correspondent to the mobile node's care-of address. This routing
header type (type 2) is restricted to carry only one IPv6 address,
which is the MN's home address.
The type 2 routing header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'Next Header', 8-bit selector, identifies the type of header
immediately following the routing header, which uses the same values
as the IPv6 Next Header field [IPv6]. For a type 2 routing header,
the values of the 'Hdr Ext Len','Routing Type',and 'Segments Left'
are all fixed value as described in the figure.
So the whole type 2 routing header of one stream would all be static
context. We can compress this header to be 0-bit.
4.3 Initialization
The static context for ROHC MIPv6 compression can be initialized by
adding the mobile IPv6 static field to the static chain in the
existing IR packet of ROHC UDP/RTP profile, where the profile id
should be modified to be 0x????(TBD). In other word, the MIPv6
profile static field should be inserted into the static chain of
original static chain of ROHC IP/UDP/RTP profile. The other parts,
except the MIPv6 fields, should be treated as standard IP/UDP/RTP
profile as defined in RFC3095.
4.4 Other considerations
Since the signaling message will be sent a very low frequency, we
don't need to compress the Mobility Header. We only transfer it
directly.
Wang [Page 5]
INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002
5. Security Considerations
The security considerations of [RFC3095] apply equally to this
document, without exceptions or additions.
6. IANA Considerations
ROHC MIPv6 profile identifier 0x???? has been reserved by the IANA
for the profile defined in this document.
[TO BE REMOVED BEFORE PUBLICATION]
A ROHC profile identifier must be reserved by the IANA for the
profile defined in this document. Profile number 0x???? has
previously been saved for this purpose, and should thus be used.
As for previous ROHC profiles, profile numbers 0xnnXX must also be
reserved for future updates of this profile. A suggested
registration in the "RObust Header Compression (ROHC) Profile
Identifiers" name space would then be:
0x???? ROHC MIPv6 [RFCXXXX (this)]
0xnn?? Reserved
[END]
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust
Header Compression (ROHC)", RFC 3095, July 2001.
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[MIPv6] David B. Johnson, Charles E. Perkins and Jari Arkko,
"Mobility Support in IPv6", IETF draft:
draft-ietf-mobileip-ipv6-19.txt,Oct 2002,working in
progress
[IPPROFILE] L-E. Jonsson,"RObust Header Compression (ROHC):A
Compression Profile for IP",IETF draft: draft-ietf-rohc-
ip-only-00.txt, Oct. 2002, working in progress
8. Author's Address
Wang Hui Tel: +86 551 360 7041
Infonet Lab,EEIS Fax: +86 551 360 1334
University of Sci. & Tech. of China
P.O.Box 4
Hefei,Anhui http://mail.ustc.edu.cn/~whui
China,230027 EMail: whui@mail.ustc.edu.cn
Wang [Page 6]
INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002
9. Patents
Infonet Lab USTC is in the process of filing one or more patent
applications that may be relevant to this IETF draft.
Wang [Page 7]