Mobile Ad hoc Networking (MANET) J. Haerri Internet-Draft C. Bonnet Expires: April 1, 2007 F. Filali Institut Eurecom, France September 28, 2006 MANET Generalized Location Signaling Format draft-haerri-manet-location-01 Status of this Memo 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 April 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document decribes a generalized format for transmitting mobility information, which MAY be used by mobile ad hoc network routing and other protocols. Haerri, et al. Expires April 1, 2007 [Page 1] Internet-Draft MANET Location Signaling September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 5. The Generalized MANET Message Format Signaling Framework . . . 7 5.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 8 6. MANET Neighborhood Discovery Protocol (NHDP) . . . . . . . . . 9 6.1. TLV types . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Mobility Specific TLVs . . . . . . . . . . . . . . . . . . . . 11 7.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Message Layout . . . . . . . . . . . . . . . . . . . 16 A.1. Mobility TLVs . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Message Layout of MANET routing protocols using Mobility TLVs . . . . . . . . . . . . . . . . . . . . 19 B.1. MANET Neighborhood Discovery Protocol (NHDP) . . . . . . . 19 B.1.1. HELLO Message: Message TLVs . . . . . . . . . . . . . 19 B.1.2. HELLO Message: Address Blocks and Address TLVs . . . . 21 B.2. OLSR version 2 . . . . . . . . . . . . . . . . . . . . . . 24 B.2.1. HELLO . . . . . . . . . . . . . . . . . . . . . . . . 25 B.2.2. TC Messages . . . . . . . . . . . . . . . . . . . . . 27 B.3. SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 B.4. AODV . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 B.5. DYMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Haerri, et al. Expires April 1, 2007 [Page 2] Internet-Draft MANET Location Signaling September 2006 1. Introduction In recent months, a growing interest has been observed in location information for improving routing in mobile ad hoc networks, by trying to improve links stability, periodic maintenance, power consumption or even security. The common point of all these new directions are the requirement of mobile nodes' mobility information. Some proposals needs nodes velocity, others moving directions, or nodes position. The most complex ones require nodes position and velocity in order to extract mobility prediction patterns. The aim of this document is to extend the recent internet drafts [PacketBB] and [NHDP] to include mobility information in TLV messages. Accordingly, this specification proposes a generalized mobility-based signaling framework, which may be employed by both mobile ad hoc networks routing protocols and other protocols with similar signaling requirements and which requires mobility information. Haerri, et al. Expires April 1, 2007 [Page 3] Internet-Draft MANET Location Signaling September 2006 2. Terminology 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 [RFC2119]. Additionally, this document uses the following terminology: Address - an address of the same type and length as the source IP address in the IP datagram carrying the packet. TLV - Type-Length-Value structure as described in [PacketBB] Mobility - mobility information related to a specific address, which consists of a set of coordinates followed by the velocity and the time this mobility information has been sampled. It will also be related to a TLV type that contains mobility information. Haerri, et al. Expires April 1, 2007 [Page 4] Internet-Draft MANET Location Signaling September 2006 3. Applicability Statement This specification describes an extension to message signaling based on TLV packets. This specification has been based on [PacketBB] and that used by OLSR [OLSRv2]. This specification is designed to provide MANET routing protocols a common framework for carrying mobility information. Extending the specification of MANET packet format [PacketBB], this specification keeps the same applicability and simply accomodates a new Mobility Type TLV attribute in message signaling. Haerri, et al. Expires April 1, 2007 [Page 5] Internet-Draft MANET Location Signaling September 2006 4. Protocol Overview and Functioning This specification does not describe a protocol. It describes an extension to MANET message signaling that MAY be used by protocols for mobile ad hoc networks to exchange mobility information. It is based on the Generalized MANET Packet/Message Format [PacketBB] specification which is currently used by OLSRv2 [OLSRv2] Haerri, et al. Expires April 1, 2007 [Page 6] Internet-Draft MANET Location Signaling September 2006 5. The Generalized MANET Message Format Signaling Framework This section provides a general description of message and packet format. A more precide description may be found in [PacketBB] 5.1. Packet Format Information in MANET are carried in a general packet format and MAY piggyback several independant messages in a single packet transmission The packet format conforms to the following specification = ?{*}+ where in defined in Section Section 5.2, and conforming to the following specification: is an 8-bit field with all bits cleared ('0'). As each message consists of an integral number of octet, the number of s required to achieve 32 bits alignment of a message is calculated as the smallest number which when added to produces a multiple of 4. The packet header is defined as = with the element of conformed to the definition in [PacketBB] 5.2. Message Format Information is carried through "messages". Messages may contain: o zero or more TLVs, associated with the whole message, or with the sender. o a set of addresses about which the originating node wishes to convey information. These addresses may be divided into one or more address blocks. Each address SHALL appear only once in a message with the same prefix length. Haerri, et al. Expires April 1, 2007 [Page 7] Internet-Draft MANET Location Signaling September 2006 o each address block is followed by zero or more TLVs, which convey information about the addresses in the address blocks. A message also contains a message header, which can be parsed without examining the remainder of the packet. > A message content MAY be fragmented due to size limitation. In that case, each fragment is transmitted such that it makes up a syntactically correct message. A message is constructed according to the following general layout: = {}* = = ? ? ? = * with the elements conformed to the definition in [PacketBB] 5.2.1. Address Blocks A naddress block represents a set of addresses in a compact and simple form. Assuming that an address can be specified as a sequence of bits of the form 'head:tail', then an address block is a set of addresses sharin the same 'head' and having different 'tails'. An address block conforms to the following layout: = + with the elements defined as in [PacketBB] Haerri, et al. Expires April 1, 2007 [Page 8] Internet-Draft MANET Location Signaling September 2006 6. MANET Neighborhood Discovery Protocol (NHDP) [NHDP] describes a general neighborhood discovery protocol that MAY be used by MANET protocols that require neighborhood knowledge without localization information. It uses the packet formats defined in [PacketBB] and introduced two new TLV types 'VALIDITY_TIME' and 'INTERVAL_TIME'. A TLV is a carrier of information, relative to a message or to addresses in an address block. When related to addresses in address blocks, a TLV MAY be associated with a single address or all address in the address block. 6.1. TLV types This specification defines two Message TLV types, which must be allocated from the "Assigned Message TLV Types" repository of [PacketBB] +-------------+-------------------------------------+---------------+ | TLV Type | | Default Value | +-------------+-------------------------------------+---------------+ |VALIDITY_TIME| The time (in seconds) from receipt | N/A | | | of the message during which the | | | | information contained in the message| | | | is to be considered valid | | +-------------+-------------------------------------+---------------+ |INTERVAL_TIME| The maximum time (in seconds) | N/A | | | between two successive transmissions| | | | of messages of the appropriate type | | +-------------+-------------------------------------+---------------+ Haerri, et al. Expires April 1, 2007 [Page 9] Internet-Draft MANET Location Signaling September 2006 This specification defines three Address Block TLV types, which must be allocated from the "Assigned Address Block TLV Types" repository of [PacketBB] +--------------------+-------+--------------------------------------+ | Mnemonic | Value | Description | +--------------------+-------+--------------------------------------+ | OTHER_IF | TBD | Specifies that the address, in the | | | | Local Interface Block of the | | | | message, is an address associated | | | | with a MANET interface other than | | | | the one on which the message is | | | | transmitted | | | | | | LINK_STATUS | TBD | Specifies a given link's status | | | | (LOST, SYMMETRIC or HEARD) | | | | | | OTHER_NEIGHB | TBD | Specifies that the address is, or | | | | was, of a MANET interface of a | | | | symmetric 1-hop neighbor of the node | | | | transmitting the HELLO message, but | | | | does not have a matching or better | | | | LINK_STATUS TLV | +--------------------+-------+--------------------------------------+ Haerri, et al. Expires April 1, 2007 [Page 10] Internet-Draft MANET Location Signaling September 2006 7. Mobility Specific TLVs A TLV is a carrier of information, relative to a message or to addresses in an address block. When related to addresses in address blocks, a TLV MAY be associated with a single address or all address in the address block. This specification extends the TLV definition in [PacketBB] to include Mobility TLVs. All TLVs are conformed to the following specification: = where the elements are defined as: is an 8 bit field which the type of TLV. bit 0 (location bit): TLV with this bit cleared ('0') does not contains the location of the address in the respective address block. TLVs with this bit set ('1') contains location information. bit 1 (azimuth bit): TLV with this bit cleared ('0') does not contains the azimuth of the address in the respective address block. TLVs with this bit set ('1') contains the azimuth. bit 2 (velocity bit): TLV with this bit cleared ('0') does not contains the velocity of the address in the respective address block. TLVs with this bit set ('1') contains the velocity. bit 3 (stability bit): TLV with this bit cleared ('0') does not contains confidence information of the information provided by the address in the respective address block. TLVs with this bit set ('1') contains the stability information. bits 4 and 5 are RESERVED and SHALL be cleared ('0). bit 6 (mobility bit): TLV with this bit set ('1') contains mobility information according to this specification. bit 7 (user bit): This bit is always set as this specification is introducing a new TLV type not covered in [PacketBB] Haerri, et al. Expires April 1, 2007 [Page 11] Internet-Draft MANET Location Signaling September 2006 is an 8-bit field which specifies the semantics of the TLV accoridng to the following: bit 0 (novalue): TLV with this bit cleared ('0') contains and elements. TLVs with this bit set ('1') contains no or elements - the TLV carries all the information needed. bit 1 (extended): In TLVs with this bit cleared ('0'), the size of the length field is 8 bits. In TLVs with this bit set ('1'), the size of the length field is 16 bits. This bit MUST be unset is the novalue is set. bit 2 (noindex): TLVs with this bit cleared ('0'), the and elements are included. TLVs with this bit set ('1'), no or elements are included. This bit MUST be set for message TLVs and for address block TLVs containing mobility information. If this bit is set for address block TLVs, the TLV applies to all addresses in the address block. bit 3 (multivalue): TLVs with this bit cleared ('0') includes a single value that applies to all addresses described by and . TLVs with this bit set ('1'), includes separate values for each of the addresses indicated by and . This bit MUST be unset for message TLVs or if the novalue is set. bits 4-7 are RESERVED and SHALL each be cleared ('0'). is omitted if the novalue bit is set, otherwise it is an 8-bit or 16 bit field, according to whether the extended bit is unset or set, respectively. If present, this field specifies the length, counted in octets, of the data contained in . If the multivalue bit is set, MUST be an integral multiple of (-+1). is omitted if the noindex bit is set. Otherwise, it is an 8 bit field. For a TLV associated with an address block, it specifies the index of the first address in the address block (starting at zero), for which this TLV applies, and is considered to be zero if omitted. is omitted if the noindex bit is set. Otherwise, it is an 8-bit field. For a TLV associated with an address block, it specifies the index of the last address in the address block (starting at zero) for which this TLV applies, and is considered to be one less than the number of addresses in the address block if omitted. Haerri, et al. Expires April 1, 2007 [Page 12] Internet-Draft MANET Location Signaling September 2006 is omitted if the novalue bit is set. Otherwise, it contains a payload, of the length specified in , which is to be processed according to the specification indexed by the field. If this is a TLV for an address block and the multivalue bit is set, this field is divided into (-+1) equal-sized fields which are applied, in order, to each address described by and . If the mobility bit is set ('1'), the value field has the following general layout = {????