Mobile Ad hoc Networking (MANET) J. Haerri Internet-Draft C. Bonnet Intended status: Experimental F. Filali Expires: April 26, 2007 Institut Eurecom, France October 23, 2006 MANET Generalized Location Signaling Format draft-haerri-manet-location-02 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 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Haerri, et al. Expires April 26, 2007 [Page 1] Internet-Draft MANET Location Signaling October 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. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8.1. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Nominative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Message Layout . . . . . . . . . . . . . . . . . . . 17 A.1. Mobility TLVs . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Message Layout of MANET routing protocols using Mobility TLVs . . . . . . . . . . . . . . . . . . . . 20 B.1. MANET Neighborhood Discovery Protocol (NHDP) . . . . . . . 20 B.1.1. HELLO Message: Message TLVs . . . . . . . . . . . . . 20 B.1.2. HELLO Message: Address Blocks and Address TLVs . . . . 22 B.2. OLSR version 2 . . . . . . . . . . . . . . . . . . . . . . 25 B.2.1. HELLO . . . . . . . . . . . . . . . . . . . . . . . . 26 B.2.2. TC Messages . . . . . . . . . . . . . . . . . . . . . 28 B.3. SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.4. AODV . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.5. DYMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Haerri, et al. Expires April 26, 2007 [Page 2] Internet-Draft MANET Location Signaling October 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. Indeed, by peeking into the recent litterature, we see that between 2004 and 2006, 3 IEEE transactions and 38 IEEE conference proceedings are related to mobility predictions, while ACM published 11 papers. 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 Intelligent Vehicule Community already understood the benefits safety provisionings could obtain from proactive visions as they started standardizing the informations cars should share. For example, the VII consortium (Vehicle Infrastructure Integration) is standardizing the information that should be transmitted between vehicles. As routing protocols and eventually internet will come on top of intervehicular communications, a similar and possiblity collaborative approach should be undergone within the IETF. However, we do not know yet what kind of information are required to be transmitted, and it is quite clear that the community might not even all agree on a common framework. 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 26, 2007 [Page 3] Internet-Draft MANET Location Signaling October 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 26, 2007 [Page 4] Internet-Draft MANET Location Signaling October 2006 3. Applicability Statement This specification describes an extension to message signaling based on TLV packets. This specification has been based on [PacketBB]. This specification is designed to provide MANET routing protocols with 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. Although the TLVs are generic and could possiblity be adapted to any kind of structure, no specific TLV type has been defined in [PacketBB] for mobility information. Therefore, in the case of interoperability, nodes would not be able to know they are dealing with localization data unless some common agreements are defined. The objective of this draft is primarily to define a common agreement on the type and structure of packets containing mobility informations. Then, we provide examples of the mobility information structure in MANET standardized protocols. Haerri, et al. Expires April 26, 2007 [Page 5] Internet-Draft MANET Location Signaling October 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 the common packet format to be used by MANET routing protocols. Haerri, et al. Expires April 26, 2007 [Page 6] Internet-Draft MANET Location Signaling October 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 [PacketBB] The packet header is defined as = ? ? with the elements of conformed to the definition in [PacketBB] 5.2. Message Format Information is carried through "messages". Messages may contain: o A message header. o A message TLV block that contains zero or more TLVs, associated with the whole message. o Zero or more address blocks, each containing one or more addresses. o A TLV block, containing zero or more TLVs, following each address block. Haerri, et al. Expires April 26, 2007 [Page 7] Internet-Draft MANET Location Signaling October 2006 is defined by: = {}* = = ? ? ? = * with the elements conformed to the definition in [PacketBB] 5.2.1. Address Blocks An address is specified as a sequence of octets of the form head:mid: tail. An address block is an ordered set of addresses sharing the same head and tail, and having individual mids. is defined by: = ? ? ? * with the elements defined as in [PacketBB] Haerri, et al. Expires April 26, 2007 [Page 8] Internet-Draft MANET Location Signaling October 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 26, 2007 [Page 9] Internet-Draft MANET Location Signaling October 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 26, 2007 [Page 10] Internet-Draft MANET Location Signaling October 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 (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 2 (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 5 (mobility bit): TLV with this bit set ('1') contains mobility information according to this specification. bit 6 (tlvprot): for TLV types with the tlv-user bit cleared ('0'), this bit specifies, if cleared ('0'), that the TLV type is protocol independent, i.e. is not specific to any one protocol, or, if set ('1'), that the TLV type is specific to the protocol for which it is defined. 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 26, 2007 [Page 11] Internet-Draft MANET Location Signaling October 2006 is an 8-bit field which specifies the semantics of the TLV accoridng to Section 5.3.1 in [PacketBB]. and are each an 8 bit field, interpreted as specified in Section 5.3.1 in [PacketBB] is interpreted as specified in Section 5.3.1 in [PacketBB] if present (see Table 1), this is a field of length octets. In an address block TLV, is associated with the addresses from index-start to index-stop, inclusive. If the multivalue bit is cleared ('0') then the whole of this field is associated with each of the indicated addresses. If the multivalue bit is set ('1') then this field is divided equally into number- values fields, each of length single-length octets and these are associated, in order, with the indicated addresses. If the mobility bit is set ('1'), the value field has the following general layout = {???