Internet DRAFT - draft-minaburo-rohc-nemo
draft-minaburo-rohc-nemo
NEMO A. Minaburo,ENST-B.
Internet Draft E.K. Paik, KT
Document: draft-minaburo-rohc-nemo-01.txt L. Toutain, ENST-B.
J-M. Bonnin, ENST-B.
Expires: January 2006 July 2005
ROHC (Robust Header Compression) in NEMO network
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 3 of RFC 3667 [1]. By submitting this
Internet-Draft, each author represents that any applicable patent or
other IPR claims of which he or she is aware have been or will be
disclosed, and any of which he or she becomes aware will be
disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on January, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the use of ROHC header compression mechanisms
for the NEMO Basic Support protocol [7]. The idea is to use both NEMO
and ROHC as they have been defined. In the NEMO Basic Support
protocol, the tunneling between the Mobile Router (MR) and the Home
Agent (HA) of the MR is done over different access technologies. Some
of these technologies are wireless (e.g. Wireless LAN, 3G or PPP) and
have scarce resources by nature, the use of ROHC compression can be
useful to reduce the bandwidth consumption.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [1].
Table of Contents
1. Introduction 2
2. The use of ROHC in NEMO 3
2.1 Basics 3
2.2 ROHC operation modes 3
2.3 ROHC compressor 4
2.4 ROHC decompressor 4
2.5 ROHC work in progress 4
3. ROHC Configuration 5
3.1 Tunneling Encapsulation 5
3.2 ROHC packet Format 6
3.3 Negotiation Header Packets 7
3.4 ROHC Parameter Values 10
3.5 ROHC Profiles 10
4. Modifications to NEMO Basic Support 10
4.1 Home Agent Operation 11
4.2 Mobile Router Operation 11
4.3 Use of Addresses 11
IANA Considerations 11
Security Considerations 11
References 11
Author's Addresses 12
Change Log 13
1. Introduction
The Network mobility (NEMO) Basic support [7] has been designed to
manage the mobility of an entire network. A Mobile Router (MR) in
this network manages the connectivity between different access
networks and the mobile networks. It is responsible to change its
point of attachment each time it is needed and to maintain a tunnel
(IP/IP) to its Home Agent (HA). This tunnel allows correspondent
nodes and mobile nodes attached to the mobile network to act as if
the mobile network was physically connected to its home network
beside the HA.
Due to the IP tunneling a double header is needed between the MR and
the HA, including the low bandwidth link between the MR and the
access network.
ROHCs header compression algorithms are known to be able to reduce
the header size and to improve performance in low bandwidth links.
This document defines how to use ROHC [2,3,4,5] mechanisms in a NEMO
network [7] to reduce the overhead and therefore to improve the
performance between the HA and the MR.
The Handover produced when the MN moves does not affect the ROHC
compression performance, the only problem that can be found is the
disordering reception of packets, when the MN moves a new tunnel
between the MR and the HA will be created, packets of the old tunnel
can arrive later.
Section 2 explains where ROHC will be used in NEMO architecture,
section 3 describes the ROHC configuration in this context and
section 4 describes the use of NEMO encapsulation for header
compression.
2. The use of ROHC in NEMO
2.1 Basics
A basic approach of using ROHC in mobile networks context is to use
ROHC to compress the header of IP packet traveling inside the
bi-directional tunnel established between the MR and HA. This tunnel
has some useful properties: it preserves the session continuity while
the MR moves and headers of IP packets traveling inside the tunnel do
not depend on the mobility of the mobile network.
The MR has two different interfaces, the ingress interfaces are
connected to the mobile network and the egress interfaces are
connected to the access network. An IP tunnel (often with IPSec) is
established between the egress interface and the HA. The HA has to
route packets that belong to the mobile network prefix to the MR
through the IP tunnel. The MR, on its side, has to route the packet
issued by the mobile network to the HA through the tunnel.
ROHC header compression is applied to packets issued by the mobile
network just after the routing decision and before the IP
encapsulation. The same thing is done by the HA on the other way.
As tunneling in NEMO Basic Support [7] is bi-directional, ROHC will
be able to perform the three operation modes and use the feedback to
improve performance.
Figure 1. ROHC in NEMO
ingress +-----+egress +-----+
+----------+ | MR |-----------------------------------| HA |
| IP packet| ---|+----| IPv6/IPsec(ESP)/ROHC or IPv6/ROHC |----+|
+----------+ ||ROHC|-----------------------------------|ROHC||
+-----+ +-----+
ROHC mechanism for RTP, UDP, IP and UDP-Lite flows works by removing
the redundancy and transfers only changing fields. It classifies the
header fields into static and dynamic fields. Static fields are those
that remain constant during the lifetime of the packet and dynamic
fields are those that keep on changing but their change pattern may
be known.
2.2 ROHC Operation modes
ROHC has three operation modes: Unidirectional (U), bi-directional
Optimistic (O) and bi-directional Reliable (R)(See RFC 3095 section
4.4). The U-mode is used when the link is unidirectional or when
feedback is not possible. For bi-directional links we can use the
O-mode or the R-mode. The O-mode sends only negative feedbacks,
optionally it can also send positive feedbacks but the R-mode uses
both negative and positive feedbacks. ROHC always starts header
compression using U-mode even if it is used in a bi-directional link.
2.3 ROHC Compressor
The ROHC compressor removes the redundant header fields and the
redundant information in the packet flow. ROHC compression
communicates changing fields most of the time. While sending the
fields that have changed, it further achieves efficiency by using an
encoding algorithm (See RFC 3095 section 4.5) in which only the last
significant bits are sent.
The ROHC compressor has three compression levels (See sections RFC
3095 5.3, 5.4 and 5.5): Initialization and Refresh (IR), First Order
(FO) and Second Order (SO). In IR compression level it establishes
the static information and in FO compression level the change pattern
of dynamic fields. In the last compression level, SO, it sends
encoded values of Sequence Number (SN) and Timestamp (TS) forming the
minimal size packets. With the use of this header format packet (See
section 5.7 RFC 3095) all header fields can be generated at the other
end of the link using the previously established change pattern. When
some updates or errors are there, the compressor goes back to the
upper compression levels. It only returns to the SO compression level
after retransmitting the updated information and establishing again
the change pattern in the decompressor.
2.4 ROHc Decompressor
The decompressor works at the receiving end of the link (See RFC 3095
section 5.3.2) and decompresses the headers based on the header
fields' information of the context. Both the compressor and the
decompressor use a context to store all the information about the
header fields. To ensure correct decompression, the context should
be synchronized all the time. The decompressor has three states, the
first is No Context (NC) that is used when there is no context
synchronization, and the second is Static Context (SC) that is
reached if the dynamic information in the context has been lost. The
third is Full Context (FC), reached when the decompressor has all the
information about header fields. In FC state, the decompressor moves
to the initial states as soon as it detects context damage. It uses
the k out of n rule by looking at the last n packets, if CRC failures
have occurred for at least k packets then, it assumes context damage
and transits backward to an initial state. The decompressor also
sends feedback according to the operation modes.
The Decompressor manages the operation mode in which the system will
work through the use of mode transitions (See RFC 3095 section 5.6)
that allow it to change from one mode to another, based on the link
characteristics and the performance requirements. The decompressor
also uses some efficient schemes to correct the context when it gets
damaged or the synchronization gets lost. The compressor also employs
some schemes through which it ensures the correct transmission of the
information to the decompressor.
2.5 ROHC work in progress
ROHC for SIP [4] flows use the UDVM (Universal Decompression Virtual
Machine) which accept any encoding code (Deflate, Huffman, Z77, EPIC,
etc). It uses the corresponding byte-code to decompress the packet.
ROHC for TCP [5] uses an improved compression efficiency method to
compress TCP header fields including TCP options to generate the
compressed format packets within the ROHC operation modes.
3. ROHC Configuration
Each ROHC entity is formed by a compressor and a decompressor, ROHC
entity will be placed in both MR and HA, each flow will use a ROHC
context identifier (CID). The profiles used in the tunneling will
depend on the profiles implemented in each peer negotiated initially.
The MNN will not be affected by the use ROHC, and it has to be
transparent for the users in the mobile network. The MR will make
ROHC compression after taking the routing decision and before making
tunneling encapsulation.
3.1 Tunneling Encapsulation
Tunnels between the mobile router and the home agent can be protected
by ensuring proper use of source addresses, and optional
cryptographic protection. When protection is requested, Home agent
and mobile router may use IPsec ESP to protect payload against
attackers on the path of the tunnel [8,9]. The ROHC packets will be
encapsulated as shown in figure 2.
This document specifies a new protocol value for the IP and IPsec
next header value to identify ROHC in the tunneling encapsulation.
Figure 2. Tunneling Encapsulation for ROHC packets.
+----------------------------+ +----------------------------+
|IPv6 Header |Nxt. Hdr.= ROHC| |IPv6 Header |Nxt. Hdr.= 50 |
| +---------------| | +---------------|
|Src. Addr. : CoA of MR | |Src. Addr. : CoA of MR |
|Dst. Addr. : HA address | |Dst. Addr. : HA address |
+----------------------------| +----------------------------|
|ROHC Packet | |ESP Header |Nxt. Hdr.= ROHC|
| | | +---------------|
| | +----------------------------+
| | |ROHC Packet |
| | | |
+----------------------------+ +----------------------------+
3.2 ROHC packet Format
Both Negotiation and ROHC Compressed packets will be sent with two
extra bytes to identify the type of packet and the disorder in the
link. Figure 3 shows the general format packet of the ROHC packets.
The Transfer Sequence Number will be used in case of packet
disordering in the link.
Figure 3. General Format Packet.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D | Transfer Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Variable length
: ROHC Header : (For ROHC format packet see
: or : section 5.2 of RFC 3095, For
: Negotiation Header : Negotiation Header see section
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 )
: :
: Payload :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D
Description Type. Two bits will be used to identify the Negotiation
ROHC packets from ROHC compressed packets.
00 Reserved
01 Negotiation
10 ROHC Compressed Packets
11 Reserved
Transfer Sequence Number
ROHC was designed to work over an order delivery transmission between
the compressor and the decompressor. When sending ROHC packets in the
IP tunneling between the MR and the HA many hops will be crossed by
different ways, order delivery may not be guaranteed. The Transfer
Sequence Number will help the decompressor to identify if disordering
has been produced in the delivery, and before making decompression of
an early arriving packet, decompressor has to wait until the order
delivery packet arrived or a timer expires.
The timer value is out of the scope of this draft, will need to be
studied depending on the congestion in the network.
3.3 Negotiation Header Packets
There is no process of negotiation when packets are sent in a IP
tunnel. To achieve correct compression, ROHC needs to know some
parameters in order to be supported by both ends of the tunnel. Based
on the RFC 3241 [6] which describes the principal parameters to be
sent in a negotiation for the PPP link, we have created the
negotiation packets. Compressor will start sending Negotiation
packets (see Figure 4), when decompressor receives negotiation
packets it will response with a feedback packet (see figure 5) to
accept or modified the compressor parameters.
ROHC Negotiation packets are sent only once, the first time the MR
leave its home network.
Figure 4. ROHC Negotiation Packet Format from Compressor to
Decompressor
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: sub options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
>= 10
The length depends on the number of sub options in the negotiation
packet
CID Size
0003 (hex) when small CID is used
0005 (hex) when large CID is used
MRRU
It indicates the maximum reconstructed reception unit, (see RFC 3095,
section 5.1.1).
Suggested value = 0
Sub options
See RFC 3241 section 2.1, and 2.2 for suboptions description.
The Profile suboption MUST be supplied.
Figure 5. ROHC Negotiation Feedback Format from Decompressor to
Compressor
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
|Ack. Type | Mode | |
+-----+-----+-----+-----+ +
| Transfer Seq. Number |
+ +-----+-----+-----+-----+-----+-----+
| : Feedback Options :
+-----+-----+-----+-----+-----+-----+-----+-----+
In order to receive the acknowledge or the modification of compressed
parameters, the Decompressor will used a Feedback type 2 (see RFC
3095 section 5.7.6
Ack. Type
See RFC 3095 section 5.7.6.1
Mode
0 = Negotiation Response
This is a modification made to RFC 3095 will be the identification
for Negotiation Response. The other values are as RFC 3095 has
defined.
Feedback Options
A new feedback option is introduced, in order to modified the
negotiation configuration. When the configuration of compressor is
accepted there is no feedback options.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+
|Opt. Type = 9 |Option | (See RFC3095 section 5.7.6.2)
+---+---+---+---+---+---+---+---+
|Len.= 4|CIDSize|p00|p01|p02|p03| ROHC Profiles
+---+---+---+---+---+---+---+---+
|p04|p05|p06|p07|P08| reserved |
+---+---+---+---+---+---+---+---+
| |
+ MRRU +
| |
+---+---+---+---+---+---+---+---+
CID Size
00 Reserved
01 Small CID
10 Large CID
11 Reserved
Profiles
Each bit represent a supported profile, when the bit is 1 the
profile is supported when it is 0 the profile is not supported.
The p-value represents the Profile of ROHC. When any profile is
matching at both sizes profile 0 is used.
p00 Profile 0. Without Compression
p01 Profile 1. IP/UDP/RTP
p02 Profile 2. IP/UDP
p03 Profile 3. IP/ESP
p04 Profile 4. IP
p05 Profile 5. LLA for U/O-mode
p06 Profile 6. LLA for R mode
p07 Profile 7. IP/UDP-Lite/RTP
p08 Profile 8. IP/UDP-Lite
MRRU
The maximum reconstructed unit supported by decompressor.
3.4 ROHC Parameter Values
A number of ROHC parameters must be set correctly for good
compression over the IP tunnel. The compression approach, the timers
of unidirectional mode, the k1, n1, k2, n2 and the timer for
disordering waiting has to be studied and are out of scope of this
document.
3.5 ROHC Profiles
All the other ROHC profiles can be used, it depends on the
MNN traffic and the profile supported by MR and HA ROHC
compressor/decompressor.
4. Modifications to NEMO Basic Support
4.1 Home Agent Operation
When HA intercepts packets which are destined to mobile router, HA
should be able to apply ROHC header compression to packets just after
the routing decision and before the IP encapsulation.
HA should be able to execute ROHC compressor and decompressor.
4.2 Mobile Router Operation
When packets are issued by the mobile network, MR should be able to
apply ROHC header compression to packets just after the routing
decision and before the IP encapsulation.
MR should be able to execute ROHC compressor and decompressor.
4.3 Use of Addresses
To support NEMO, MR uses two types of addresses: the home addresses
which are static and they are used when MR is at its home networking
and the care-of addresses which are dynamic and they change with the
attachment point. The HA will keep a binding cache for MR.
While MR is in its home networking header compression will not be
used.
The addresses used for ROHC will be the MNN (Mobile Network Node) as
source address and the CN (Corresponding Node) as destination
address. The Address will not change while the MN moves around.
IANA Considerations
This document defines a new IPv6 protocol and IPsec protocol, the
ROHC Next Header, described in Section 3.1.
Security Considerations
This document by it self does not add any security risk to the use of
ROHC and NEMO as they have already been defined in [2] and [7].
References
1 Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
2 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):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
3 Jonsson, L-E., Pelletier, G., "RObust Header Compression (ROHC):
A Compression Profile for IP", RFC 3843, June 2004.
4 Pelletier, G., "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
5 Pelletier, G., Jonsson, L-E., West, M., Price, R., Sandlund, K.,
"Robust Header Compression (ROHC): A Profile for TCP/IP
(ROHC-TCP)", <draft-ietf-rohc-tcp-08.txt>, October 2004.
6 Bormann, C., "RObust Header Compression (ROHC) over PPP", RFC
3241, April 2002.
7 Devarapalli, V., Wakikawa, R., Petrescu, A., Thubert, P.,"Network
Mobility (NEMO) Basic Support Protocol", rfc3963, 2005.
8 Johnson, D., Perkins, C., Arkko, J., "Mobility Support In IPv6",
RFC 3775, 2004.
9 Arkko, J., Devarapalli, V., Dupont, F.,"Using IPSec to Protect
Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC3776, 2004.
Author's Addresses
Ana Minaburo
ENST-Bretagne
2 rue de la Chataigneraie - CS 17607
35576 Cesson Sevigne Cedex
Phone: (+33) 299 127054
Email: anacarolina.minaburo@enst-bretagne.fr
Eun Kyoung Paik
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Laurent Toutain
ENST-Bretagne
2 rue de la Chataigneraie - CS 17607
35576 Cesson Sevigne Cedex
Phone: (+33) 299 127026
Email: laurent.toutain@enst-bretagne.fr
URI: http://www.rennes.enst-bretagne.fr/~toutain/
Jean-Marie Bonnin
ENST-Bretagne
2 rue de la Chataigneraie - CS 17607
35576 Cesson Sevigne Cedex
Phone: (+33) 299 127026
Email: jm.bonnin@enst-bretagne.fr
Change Log
Changes from draft-minaburo-rohc-nemo-00 to 01:
* Restructuring of Section 2:
+ Divide in sections the ROHC description.
* Restructuring of Section 3:
+ Added section 3.1 Tunneling Encapsulation
+ Added section 3.2 ROHC Packet Format
+ Added section 3.3 Negotiation Header Format
+ Moved part of section 3 to section 3.4 ROHC parameters
+ Added ROHC Profiles
* Restructuring of Section 4:
+ Re-named section title 'NEMO addresses' to 'Modifications to NEMO Basic Support '
+ Added section 4.1 Home Agent Operation
+ Added section 4.2 Mobile Router Operation
+ Moved section '4.1 Addresses for header compression' to section '4.3 Use of Addresses'
Copyright Statement
"Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
