Subject: [rohc] Multipoint Robust Compression for MANET

From: [email-masked]
Date: Mon, 29 Mar 2004 22:06:29 +0000

I'm designing a MANET system suitable for handheld and automobile portable radios that can operate on the move with link rages greater than 1 km. We will be adding IPv6 to the system so header compression has become a necessity as the network generally achieves less than 100kbps on links. In order to maximize bandwidth efficiency we are using broadcast and multicast traffic (multipoint traffic) to our neighbor nodes. I propose that we either create an extension to ROHC for multipoint links or come up with a method to efficiently use the current version in multipoint MANETS. I have been in contact with representatives from Effnet and Procito who are interested in designing the compression scheme.  I have included a problem statement that defines the issues that I think need to be addressed and suggest that the ROHC group take this up as a new action item.

Please let me know what you think, and if the we can address this problem within the working group. 

Thank you,

   David Green
   SRI International
   EMail: [email-masked]
ROHC Working Group                               D. Green
                                                 SRI International
 		                                       March 29, 2004

Problem Statement for ROHC Compression Profile for Multipoint MANET Links

draft-green-rohc-manet-problem-statement.txt

Status of this Memo
   This document is a draft suggestion to the ROHC working group to establish the need for an efficient method for using ROHC over multipoint (point to multipoint and broadcast) links found in Mobile Ad Hoc Network (MANET) radio systems. 

Abstract
   In ad hoc radio networks containing or contained within larger IP networks, especially IPv6 networks, the capabilities of a header compression protocol such as ROHC are desirable. This document poses the issues that need to be addressed to make ROHC work well in a network containing both traditional point-to-point unicast messaging and point-to-multipoint broadcast and multicast messaging sent across radio network topologies.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . 2
   1.1  Network Design Requirements  . . . . . . . . . . . . . . 2
   1.2  Multipoint Network General Approach  . . . . . . . . . . 3
   1.3  MANET Network General Issues . . . . . . . . . . . . . . 3
   1.4  MANET Data-Link Layer Considerations . . . . . . . . . . 4
   1.5  MANET Network Layer Considerations . . . . . . . . . . . 5
   1.6  Unique IPv6 Considerations . . . . . . . . . . . . . . . 5
   2.0  Combining MANET and ROHC - Specific Challenges . . . . . 5
   3.   Security Considerations  . . . . . . . . . . . . . . . . 5
   4.   Acknowledgements . . . . . . . . . . . . . . . . . . . . 6
   5.   References . . . . . . . . . . . . . . . . . . . . . . . 6
   6.   Authors' Addresses . . . . . . . . . . . . . . . . . . . 7
   7.   Intellectual Property and Copyright Statements . . . . . 7

1. Introduction

RFC 3509 [1], entitled "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed" gives a good overview of the requirements for IPv4 and IPv6 header compression in wireless networks. It describes the various issues and requirements that need to be addressed in such a network, and has led to the development of a number of extensions to the base protocol [2] [3] [4] [5].

These protocols specifically address networks in which the only, or
the primary, communication vehicle is a point-to-point radio link with significant error rates, and long round-trip times. In ad hoc radio networks containing or contained within larger IP networks, many of the capabilities of ROHC are desirable and arguably necessary, but for maximum efficiency additional extensions need to be made for point-to-multipoint traffic such as broadcast and multicast traffic.

This document poses the issues that need to be addressed to make ROHC work well in a network containing both traditional point-to-point (cellular) and point to multipoint (MANET) radio network topologies. 

1.1 Network Design Requirements

In the portions of networks linked by MANET capable radios, the radio frequency (RF) physical medium is error prone (10^-3 error rates are common), data rate limited (288kbps or less for long range 1km+ mobile data radios), and high delay (10s to 100s of milliseconds per hop) medium when compared to wired networks. When networks are operating on the move, terrain masking, foliage scattering, and the changing propagation distances between nodes all exacerbate packet errors, network outages, router topology changes, and delays. 

Due to the ad-hoc nature of MANET architectures, the radio system is inherently a broadcast medium where all neighbor radios may receive the transmission of any transmitting radio if they are within the RF range of the transmitter. Given the inherent broadcast nature of the RF medium, MANET radios may transmit point-to-point style messages to single neighbors (and other neighbors discard the transmissions not meant for them), point-to-multipoint messages to groups of neighbors (neighbors in the multipoint group listen to the message while neighbors not in the group discard the message), or point-to-all messages which are received and processed by all neighbors. These capabilities enable radios to service Internet Protocol unicast, multicast, and broadcast style messages.  Since messaging applications attached to MANETs often need to send messages to multiple destinations within the MANET, multicast and broadcast messages are used heavily as they consume less data bandwidth t!
 han transmitting multiple point-to-point unicast messages.
 
MANET networks have the same RF medium characteristics of high error rates, severely limited data rates, and high delay that the ROHC base specification addresses via robust Window-based LSB encoding. MANET networks differ from the current extensions for ROHC since they must service, broadcast and multicast messages in addition to unicast point-to-point messages. Since the RF physical medium characteristics are well addressed by ROHC, and only the capability to efficiently support multicast and broadcast transmissions may not supported, we reason that ROHC may properly support multicast and broadcast links with little or no modification.

1.2 Multipoint Network General Approach. 
A node sending a broadcast or multicast message a message needs a method to check and see if the message recipients correspond to current layer 1-2 (single hop) neighbors, and a method to look into a compression context table to determine if a full header needs to be sent or what level of compression may be used. Current unidirectional-mode (u-mode) compression can support multipoint data dissemination, but higher levels of compression may be gained through feedback mechanisms if the mechanisms do not cause excessive overhead. 
Compression on point to multipoint links will probably have a lower average efficiency when compared to point to point links, but a properly designed scheme should significantly lower IP overhead for IPv4 and v6 and result in a net savings.

1.3 MANET General Issues 

RFC 2501 [2], in section 3, lists a number of important points about
MANET networks. They have dynamic topologies, which is to say that a system's list of neighboring hosts and routers changes from time to time. They are often bandwidth-constrained, both because the medium is shared with other nodes and because of limitations of the technology. They are also often power-constrained - a man portable MANET system carried by a person is running on its battery, and the simple act of transmission can be a major power drain. They also enjoy limited security: even if locked in a room, their radio transmissions can be a beacon identifying their location or giving away information about the frequency and RF waveform with which they transmit. 

>From the perspective of adapting an existing header compression protocol, these MANET characteristics have specific implications. If transmissions consume power & bandwidth while potentially compromising security, unnecessary transmission is something to be avoided. As a result, if there are several ways that a peer might establish compression context (using multicast and broadcast to exchange compression context information to multiple neighbors simultaneously, piggybacking compression on messages for neighbor discovery or routing information exchange, etc.), selecting the one that uses the least power and bandwidth will have the least impact - at least less impact than allowing duplicates. If the network is
bandwidth-constrained, limiting transmissions also preserves bandwidth for other uses, and compressing data in ways that maximize available bandwidth is extremely helpful. Security threats need to be actively addressed, and in regions of rapid network change, or during periods of rapid network change, the transmission and computation loads need to be minimized. These issues are often deemed unimportant in protocols designed for fixed usage.

1.4 MANET Data-Link Layer Considerations. 
 MANET capable radios may be based on common commercial technology such as 802.11, emergency or military radios, or other technologies. Despite the variations in radio technology, the radios are usually built using a small set of link-layer technologies. Link layer assisted schemes will vary between radios, or in the case of JTRS and other software defined radios, they will vary as the software defined waveform changes.

General similarities of most MANET Radios:
*Data Link (Logical Link Control sub layer) Protocols such as ARP, RARP, RDISC are common and may be leveraged by multipoint ROHC
 
General differences between most MANET Radios:
*Channel access protocols vary between CSMA, CDMA, TDMA, and hybrid schemes 
*MAC Frame Formats often vary

1.5 MANET Network Layer considerations
*MANETS operate on many different experimental routing protocols (AODV, OLSR, TBRPF, OSPF with MANET extensions, and others) since there is no IETF standards-track MANET protocol
*MANET protocols that maintain active neighbor lists may provide the neighbor state information needed to check against multipoint recipients to determine if a compression context is established.

1.6 Unique IPv6 considerations [6]
*Larger addresses make header compression a more urgent need
*Automatic address reassignment via autodiscovery and autoconfiguration could impact header compression
*IPv6 neighbor discovery (neighbor solicitation and advertisement)(RFC 2461) [7] could be an enabling mechanism to gather information on neighbors
 
2.0 Combining MANET and ROHC - Specific Challenges
*Determining if messages require broadcast or multicast support
*Determining/discovering neighbors to establish compression contexts 
*Method for crosschecking multicast message recipients against neighbor tables
*U-mode probably will work for a low level of compression
*To get higher efficiency, we might need to redesign the feedback logic for bi-directional modes to handle multipoint links without generating collisions or congestion in dense networks 
*Impairment considerations for multipoint links
*Method for context repair for multipoint links

3.0 Security Considerations

   As a problem statement, this note imposes no new security
   requirements on MANET networks that are not known from RFC
   2501 [2]. Those problems can, however, be extreme. RFC 2501's
   Security Considerations read:

        Mobile wireless networks are generally more prone to physical security threats than are fixed, hardwired networks. Existing link-level security techniques (e.g. encryption) are often applied within wireless networks to reduce these threats. Absent link-level encryption, at the network layer, the most pressing issue is one of inter-router authentication prior to the exchange of network control information.  Several levels of authentication ranging from no security (always an option) and       simple shared-key approaches, to full public key        infrastructure-based authentication mechanisms will be explored by the group.  As an adjunct to the working groups efforts, several optional authentication modes may be standardized for use in MANETs.

   Note, however, that the issues that routing in a wireless network are very vulnerable to attack, and appropriate security issues need to be taken seriously.

4. Acknowledgements
Initial comments were received from Tommy Lundemo, Jesus Arango, Fred Templin, and Pete Sholander to help define this problem.

5. References
[1] 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.

[2] Degermark, M., "Requirements for IP/UDP/RTP Header Compression", RFC 3096, July 2001.

[3] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression", RFC 3243, April 2002.

[4] C. Bormann, "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.

[5] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): A compression profile for IP", Internet draft (work in progress), October 2003, <draft-ietf-rohc-ip- only-05.txt>

[6] Deering, S. and R. Hinden, "Internet Protocol, Version (IPv6) Specification", RFC 2460, December 1998.

[7] Narten, T., Nordmark, E., Simpson, W., and Daydreamer, "Neighbor Discovery for Ipv6", RFC 2461, December 1998

Portions of this document in its current state have been taken directly from http://www.ietf.org/Draft-Statements/draft-baker-manet-ospf-problem-statement-00.txt  as this document relates to creating an OSPF-MANET routing protocol and many general considerations in Baker's problem statement overlap with considerations for developing a MANET compression protocol.

6. Authors' Address

   David Green
   SRI International
   333 Ravenswood Ave
   Menlo Park, California  94025
   USA

   Phone: +1-732-532-6715
   Fax:   +1-732-427-2065
   EMail: [email-masked]

7. Intellectual Property Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that this document is referenced and the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the authors, IETF, or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns.

The author invites any interested party to bring to their attention any implementation issues, copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard.