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