One document matched: draft-minaburo-rohc-nemo-00.txt

NEMO                                               A. Minaburo
Internet Draft                                     ENST-Bretagne
Document: draft-minaburo-rohc-nemo-00.txt          E.K. Paik
                                                   KT
                                                   L. Toutain
                                                   ENST-Bretagne
Expires: September 2005                            March 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 become aware will be disclosed, 
in accordance with RFC 3668.

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 August, 2005.


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 [9]. The idea is to use both 
NEMO and ROHC as they have been defined without any change. The 
tunneling in the NEMO Basic Support protocol will be done over 
different supports (Wireless LAN, 3G or PPP) links, where ROHC 
compression can work.



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 [ ].

Table of Contents

1. Introduction                         2
2. The use of ROHC in NEMO              2
3. ROHC configuration                   4
4. NEMO addresses                       4
4.1 Addresses for header compression    4
Security Considerations                 5
References                              5
Acknowledgments                         6
Author's Addresses                      6
Copyright Statement                     6

1. Introduction

Network mobility (NEMO) [1] is concerned with managing the mobility 
of an entire network through a mobile router (MR). The MR dynamically 
changes its point of attachment to the Internet. ROHCs header 
compression algorithms are able to reduce the header size and 
improve performance in low bandwidth links. This document defines the 
use of ROHC [2,3,4,5,6,7,8] mechanisms in a NEMO network [9] to 
improve the performance between the home agent and the mobile router.

Section 2 introduces where ROHC will be used in NEMO, section 3 will 
describe the ROHC configuration and section 4 will describe the use 
of NEMO addresses for header compression.



2. The use of ROHC in NEMO


A basic approach of using ROHC in mobile networks is to use 
bi-directional tunnel between the MR and HA to preserve session 
continuity while the MR moves. As ROHC has been defined to work 
between two peers, the header compression of ROHC will be done 
between the MR and the HA tunneling.

As tunneling in NEMO Basic Support [9] is bi-directional, ROHC will 
be able to perform the three operation modes and use the feedback to 
improve performance.

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.

ROHC has three operation modes: Unidirectional (U), bi-directional 
Optimistic (O) and bi-directional Reliable (R). 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.

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 change, it further achieves efficiency by using an 
encoding algorithm in which only the last significant bits are sent.
The ROHC compressor has three compression levels: 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 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.

The decompressor works at the receiving end of the link 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 when there is no context synchronization, and the second is 
Static Context (SC) that is reached only after the dynamic 
information in the context is lost. The third is Full Context (FC), 
reached when the decompressor has all the information about header 
fields. When 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 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.

ROHC for SIP [4] flows use the UDVM (Universal Decompression Virtual 
Machine) which accept any encoding code (Deflate, Huffman, Z77, EPIC, 
etc) and use the corresponding byte-code to decompress the packet. 
ROHC for TCP [7] use EPIC (Efficient Protocol Independent Compression) 
to generate encoding within the ROHC operation modes. EPIC is an 
improvement method of Huffman encoding to reduce a character set.

The ROHC Negotiation will be done while the tunneling is opened and 
it is not the objective of this draft.



3. ROHC configuration

ROHC entities formed by a compressor and a decompressor will be 
placed in both MR and HA, each flow will use a ROHC context 
identifier (CID), the use of ROHC will be based on the description 
made in [6] where channels of ROHC are given. The profiles used in 
the tunneling will depend on the profiles implemented in each peer 
negotiated initially.

The ROHC compression parameters need to be studied and are out of the 
scope of this document. The use of different IP addresses will not be 
a problem as it is explained in section 4. The ROHC classification 
has not change the address will be static all over the life of the
tunnel.

The MNN will not be affected by the use of header compression in the 
tunnel, the use of ROHC between the MR and the HA has to be 
transparent for them and for all the users in the mobile network.



4. Addresses to support NEMO

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.



4.1 Addresses for header compression

ROHC mechanisms classifies the header fields to make compression. 
This analysis is based on how the values in the header fields change 
during a stream. These fields are separated and assigned to the 
static and the dynamic chain of the compressed header packets.

The MR will acquire a care-of address (CoA) from its attachment 
point and it will use it to make header compression. While MR is in 
its home networking header compression will not be used.

As the addresses are classified as static, each time the MR changes 
its attachment point the ROHC context will be initialized.




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.


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 Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., 
  Rosenberg, J., "Signaling Compression (SigComp)", RFC 3320, 
  January 2003.

5 Jonsson, L-E., Pelletier, G., "Robust Header Compression (ROHC): 
  A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, 
  April 2002.

6 Liu, Z., Le, K., "Zero-byte for Bidirectional Reliable Mode 
  (R-mode) in Extended Link-layer Assisted Robust Header Compression 
  (ROHC) Profile", RFC 3408, December 2002.

7 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.

8 Pelletier, G., "RObust Header Compression (ROHC): Profiles for 
  UDP-Lite", <draft-ietf-rohc-udp-lite-04.txt>, June 2004.

9 Devarapalli, V., Wakikawa, R., Petrescu, A., Thubert, P., "Network 
  Mobility (NEMO) Basic Support Protocol", rfc3963, 2005.




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/




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."