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