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
<packet> = {<packet-header><pad-octet>*}?
{<message><pad-octet>*}*
where <message> in defined in Section Section 5.2, and <pad-octet>
conforming to [PacketBB]
The packet header is defined as
<packet-header> = <zero>
<packet-semantics>
<packet-seq-number>?
<tlv-block>?
with the elements of <packet-header> 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
<message> is defined by:
<message> = <message-header>
<tlv-block>
{<addr-block><tlv-block>}*
<message-header> = <msg-type>
<msg-semantics>
<msg-size>
<msg-header-info>
<msg-header-info> = <originator-address>?
<hop-limit>?
<hop-count>?
<msg-seq-number>
<tlv-block> = <tlv-length>
<tlv>*
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.
<address-block> is defined by:
<address-block> = <num-addr>
<head-octet>
<head>?
<tail-octet>?
<tail>?
<mid>*
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:
<tlv> = <tlv-type>
<tlv-semantic>
<index-start>?
<index-stop>?
<length>?
<value>?
where the elements are defined as:
<tlv-type> 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
<tlv-semantic> is an 8-bit field which specifies the semantics of the
TLV accoridng to Section 5.3.1 in [PacketBB].
<index-start> and <index-stop> are each an 8 bit field, interpreted
as specified in Section 5.3.1 in [PacketBB]
<length> is interpreted as specified in Section 5.3.1 in [PacketBB]
<value> if present (see Table 1), this is a field of length <length>
octets. In an address block TLV, <value> 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
<value> = {<loc>?<azi>?<velo>?<stab><time>}*
with the usual notion of "?" indicating "zero or one" occurence of
the preceding element, the notion of "*" indicating "zero or more"
occurence of the preceding element, and the element defined thus:
<loc> is a block containing the coordinates of a node following
the general layout
<loc> = <Longitude><Latitude><Elevation>
<velo> is a block containing the node's velocity in m/s
<azi> is a block containing the node's azimuth
<stab> is a block containing the node's stability , which
represents the node eagerness to keep the current mobility
parameters, and which MAY be used as a measure of the relative
confidence of the mobility parameters.
<time> is a block containing the time these mobility parameters
has been sampled last. In conjunction with <stab>, it MAY be able
to provide a confidence predictor of the mobility parameters.
Haerri, et al. Expires April 26, 2007 [Page 12]
Internet-Draft MANET Location Signaling October 2006
7.1. Constraints
o An address SHALL NOT appear more than once in the same message
with the same prefix length (an address without a PREFIX-LENGHT
TLV is considered to have a prefix length equal to the address
length).
o In any kind of mobility TLV, the <stab> and <time> MUST always be
present.
o If the bit <azi> is set ('1'), the bit <speed> MUST also be set
('1').
o For TLVs carying mobility information, the user bit and the
mobility bit MUST be set ('1') in the <type> field..
o For TLVs carying mobility information, each mobility parameter
applies to a single and unique address. Accordingly, if multiple
addresses are aggregated in a TLV address block, the multivalue
bit MUST be set ('1') and the noindex bit MUST be unset ('0').
o For TLVs carying mobility information, two or more TLVs of the
same type MUST NOT be included in the same TLV block or TLV
address block.
o Non-mobility specific constrains MAY be found in [PacketBB]
Haerri, et al. Expires April 26, 2007 [Page 13]
Internet-Draft MANET Location Signaling October 2006
8. IANA Considerations
8.1. TLV Types
This document specifies 5 new TLV types which must be allocated from
the "Assigned Message Types" repository of [PacketBB].
+--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+
| LOCATION | 161 | Mobility TLV with location only |
+--------------------+-------+--------------------------------------+
| SPEED | 162 | Mobility TLV with speed only |
+--------------------+-------+--------------------------------------+
| LOCATION_SPEED | 163 | Mobility TLV with speed and location |
+--------------------+-------+--------------------------------------+
| SPEED_AZIMUT | 166 | Mobility TLV with speed and azimuth |
+--------------------+-------+--------------------------------------+
| LOC_SPEED_AZIMUT | 167 | Mobility TLV with speed, azimuth |
| | | and location |
+--------------------+-------+--------------------------------------+
Figure 10
Haerri, et al. Expires April 26, 2007 [Page 14]
Internet-Draft MANET Location Signaling October 2006
9. Security Considerations
This document is subject to similar security issues as [PacketBB].
Accordingly, similar security considerations may be undertaken.
Haerri, et al. Expires April 26, 2007 [Page 15]
Internet-Draft MANET Location Signaling October 2006
10. References
10.1. Nominative References
[PacketBB]
Clausen, T., "Generalized MANET Packet/Message Format", <
www.ietf.org/internet-drafts/
draft-ietf-manet-packetbb-02.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[DYMO] Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing",
<www.ietf.org/internet-drafts/
draft-ietf-manet-dymo-06.txt>.
[NHDP] Clausen, T., "MANET Neighborhood Discovery Protocol
(NHDP)", <
www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-00.txt>.
[OLSRv2] Clausen, T., "The Optimized Link State Routing version 2",
<www.ietf.org/internet-drafts/
draft-ietf-manet-olsrv2-02.txt>.
[SMF] Macker, J., "Simplified Multicast Forwarding for MANET",
<www.ietf.org/internet-drafts/draft-ietf-manet-smf-03.txt>.
Haerri, et al. Expires April 26, 2007 [Page 16]
Internet-Draft MANET Location Signaling October 2006
Appendix A. Message Layout
This section specifies the translation from the abstract descriptions
of messages employed in the protocol specification, and the bit-
layout messages actually exchanged between nodes. The section only
focuses on Mobility TLVs as other parts are described in details in
[PacketBB]
A.1. Mobility TLVs
The basic layout of the <type> field in a Mobility TVL is as follows:
+----+----+----+----+----+----+----+----+-----------------------+
| Type | Value |
+----+----+----+----+----+----+----+----+ |
| 7 6 5 4 3 2 1 0 | |
|User|Prot|Mobi|Resv|Resv|Azim|Velo|Loc | |
+----+----+----+----+----+----+----+----+-----------------------+
| 0 | ... | Regular TLV |
+----+----+----+----+----+----+----+----+-----------------------+
| 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | Mobility TLV with |
| | speed only |
+----+----+----+----+----+----+----+----+-----------------------+
| 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | Mobility TLV with |
| | speed and location |
+----+----+----+----+----+----+----+----+-----------------------+
| 1 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | Mobility TLV with all|
| | mobility paramters |
+----+----+----+----+----+----+----+----+-----------------------+
Figure 11
where, according to the bits cleared or set in the <type> field and
the related constraints, any combinations are possible.
Haerri, et al. Expires April 26, 2007 [Page 17]
Internet-Draft MANET Location Signaling October 2006
The basic layout of a Message Mobility TVL is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1|0|0|1|1|1| Resv|M|0|1|0|0| Length | Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude | Elevation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elevation | Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Speed | Azimuth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Azimuth | Stability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stability | Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
Figure 12
where all mobility parameters have been displayed. According to the
bits cleared or set in the <type> field and the related constraints,
any combinations are possible, yet adding padding bits ('0') at the
end to ensure that the total length is a integer multiple of 4 bytes.
Haerri, et al. Expires April 26, 2007 [Page 18]
Internet-Draft MANET Location Signaling October 2006
The basic layout of a Address Blocks Mobility TVL is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1|0|1|1|1|1| Resv|0|0|0|0|1| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude | Elevation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elevation | Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Speed | Azimuth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Azimuth | Stability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stability | Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ... |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
Figure 13
with as many mobility structures as the number of addresses in the
address block, and where all mobility parameters have been displayed.
Accoring to the bits cleared or set in the <type> field and the
related constraints, any combinations are possible, yet adding
padding bits ('0') at the end to ensure that the total length is an
integer multiple of 4 bytes.
Haerri, et al. Expires April 26, 2007 [Page 19]
Internet-Draft MANET Location Signaling October 2006
Appendix B. Message Layout of MANET routing protocols using Mobility
TLVs
B.1. MANET Neighborhood Discovery Protocol (NHDP)
This section specifies the translation from the abstract descriptions
of Mobility TLVs in Section Section 7 to the application in the MANET
Neighborhood Discovery Protocol [NHDP].
NHDP is a neighborhood discovery protocol (NHDP) for a mobile ad hoc
network (MANET). The protocol provides each MANET node with local
topology up to two hops distant, describing a node's 1-hop neighbors
and symmetric 2-hop neighbors. NHDP employs HELLO messages for
neighborhood discovery and are locally scoped. For a detailed
description, the reader is referred to [NHDP].
HELLO messages are exchanged between neighbor nodes only, ie. they
MUST NOT be forwarded by any node. A HELLO message is conformed to
the following layout:
<hello> = <hello-msg-tlvs>*{<addr_block><addr_block_tlv>+}*
B.1.1. HELLO Message: Message TLVs
If Mobility information are convoyed by HELLO messages, a node MUST
generate a HELLO message with at least the message TLVs specified in
Figure 15.
+-------------+-------------------------------------+---------------+
| 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 | |
+-------------+-------------------------------------+---------------+
| MOBILITY | sender mobility information. | N/A |
+-------------+-------------------------------------+---------------+
Figure 15
Haerri, et al. Expires April 26, 2007 [Page 20]
Internet-Draft MANET Location Signaling October 2006
Assigned HELLO message TLV types and bit layout in NHDP:
+---------------+--------+--------------------------------------+
| Mnemonic | Type | Value |
+---------------+--------+--------------------------------------+
| Fragmentation |00000000| Specifies behavior in case of content|
| | | fragmentation. |
+---------------+--------+--------------------------------------+
| Content Seq. |00000001| A sequence number, associated with |
| Number | | the content of the message |
+---------------+--------+--------------------------------------+
| VALIDITY_TIME | TBD | The time (in seconds) from receipt |
| | | of the message during which the |
| | | information contained in the message |
| | | is to be considered valid |
+---------------+--------+--------------------------------------+
| INTERVAL_TIME | TBD | The maximum time (in seconds) |
| | | between two successive transmissions |
| | | of messages of the appropriate type |
+---------------+--------+--------------------------------------+
| MOBILITY |10100...| Specifies the mobility parameter |
| | | of the sender node |
+---------------+--------+--------------------------------------+
Figure 16
Haerri, et al. Expires April 26, 2007 [Page 21]
Internet-Draft MANET Location Signaling October 2006
Assigned HELLO address TLV types and bit layout in NHDP:
+---------------+--------+--------------------------------------+
| Mnemonic | Type | Value |
+---------------+--------+--------------------------------------+
| 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 |
+---------------+--------+--------------------------------------+
| Mobility |10100...| Specifies the mobility parameter |
| | | of the node with the given address |
+---------------+--------+--------------------------------------+
Figure 17
B.1.2. HELLO Message: Address Blocks and Address TLVs
If Mobility information are convoyed by HELLO messages, for each
transmitting interface, a node MUST generate a HELLO message with
address blocks and address TLVs accoridng to Figure 18.
Haerri, et al. Expires April 26, 2007 [Page 22]
Internet-Draft MANET Location Signaling October 2006
+--------------------------+----------------------------------------+
| Addresses: | TLVs (Type=Value) |
| | |
| The set of neighbor | |
| interfaces which are... | |
+--------------------------+----------------------------------------+
| HEARD over the interface | (Link Status=HEARD); |
| over which the HELLO is | (Interface=TransmittingInterface) |
| being transmitted | (Mobility=Neighbor Mobility) |
+--------------------------+----------------------------------------+
| SYMMETRIC over the | (Link Status=SYMMETRIC); |
| interface over which | (Interface=TransmittingInterface) |
| the HELLO is being | (Mobility=Neighbor Mobility) |
| transmitted | |
+--------------------------+----------------------------------------+
| LOST over the interface | (Link Status=LOST); |
| over which the HELLO is | (Interface=TransmittingInterface) |
| being transmitted | |
+--------------------------+----------------------------------------+
| SYMMETRIC over ANY | (Link Status=SYMMETRIC); |
| interface of the node | (Interface=TransmittingInterface) |
| other than the interface | (Mobility=2-hops Neighbor Mobility) |
| over which the HELLO is | |
| being transmitted | |
+--------------------------+----------------------------------------+
Figure 18
B.1.2.1. HELLO Message Example with Mobility Informations
A simple example HELLO message, sent by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without prefix TLVs, i.e. with all addresses having
maximum length prefixes. The message is sent with a full message
header (message semantics octet is 0) with a hop limit of 1 and a hop
count of 0. The overall message length is 168 octets (it does not
need padding).
The message has a message TLV block with content length 8 octets
containing three message TLVs, of types VALIDITY_TIME, INTERVAL_TIME,
and MOBILITY. Each uses a TLV with semantics value 4, indicating no
start and stop indexes are included, and the first two has a value
length of 1 octet. The MOBILITY TLV has a length of 28 octet. The
values included (0x68 and 0x50) represent the default values of 6
seconds and 2 seconds, respectively.
The first address block contains 1 local interface address, with head
Haerri, et al. Expires April 26, 2007 [Page 23]
Internet-Draft MANET Location Signaling October 2006
length 4 and no address tail or mid parts. This address block has no
TLVs (TLV block content length 0 octets).
The second, and last, address block contains 4 neighbor interface
addresses, with head length 3 octets, no address tail part and each
address mid part having length one octet. The following TLV block
(content length 7 octets) includes one TLV which reports the link
status of all neighbors in a single multivalue TLV: the first two
addresses are HEARD, the third address is SYMMETRIC and the fourth
address is LOST. The TLV semantics value of 12 indicates, in
addition to that this is a multivalue TLV, that no start and stop
indexes are included, since values for all addresses are included.
The TLV value length of 4 octets indicates one octet per value per
address.
In the Message TLV, we add the coordinate of the source node and in
the address block TLV we add a multivalue TLV which contains the
coordinates of each MID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1| VALIDITY_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0| MOBILITY |1|0|1|0|1|1|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0 0| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude | Elevation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elevation | Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Speed | Azimuth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Azimuth | Stability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stability | Time |
Haerri, et al. Expires April 26, 2007 [Page 24]
Internet-Draft MANET Location Signaling October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid |0 0 0 0 0 0 0 0|0 0 0 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS |0 0 0 0 1 1 0 0|0 0 0 0 0 1 0 0| HEARD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HEARD | SYMMETRIC | LOST |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| MOBILITY |1|0|1|0|1|1|1|1|0 0 0 1 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elevation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Azimuth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
B.2. OLSR version 2
This section specifies the translation from the abstract descriptions
of Mobility TLVs in Section Section 7 to the application in OLSR
version 2 routing protocol [OLSRv2].
OLSRv2 employs two different message types for exchanging protocol
information. Those are the HELLO message which are locally scoped
Haerri, et al. Expires April 26, 2007 [Page 25]
Internet-Draft MANET Location Signaling October 2006
and the TC messages, which are globally scoped. For a detailed
description, the reader is referred to [OLSRv2].
B.2.1. HELLO
Hello messages are exahnged between neighbor nodes only, ie. they
MUST NOT be forwarded by any node. A HELLO message is conformed to
the following layout:
<hello> = <hello-msg-tlvs>*{<addr_block><addr_block_tlv>+}*
B.2.1.1. HELLO Message: Message TLVs
If Mobility information are convoyed by HELLO messages, for each
OLSRv2 interface a node MUST generate a HELLO message with at least
the message TLVs specified in Figure 21.
+-------------+-------------------------------------+---------------+
| TLV Type | | Default Value |
+-------------+-------------------------------------+---------------+
| Willingness | willingness to be selected as MPR. | WILL_DEFAULT |
+-------------+-------------------------------------+---------------+
| Mobility | sender mobility information. | N/A |
+-------------+-------------------------------------+---------------+
Figure 21
Haerri, et al. Expires April 26, 2007 [Page 26]
Internet-Draft MANET Location Signaling October 2006
Assigned HELLO message TLV types and bit layout in OLSRv2:
+---------------+--------+--------------------------------------+
| Mnemonic | Type | Value |
+---------------+--------+--------------------------------------+
| Fragmentation |00000000| Specifies behavior in case of content|
| | | fragmentation. |
+---------------+--------+--------------------------------------+
| Content Seq. |00000001| A sequence number, associated with |
| Number | | the content of the message |
+---------------+--------+--------------------------------------+
| Willingness |00000011| Specifies a nodes willingness [0-7] |
| | | to act as a realy and take part in |
| | | the network formation |
+---------------+--------+--------------------------------------+
| Mobility |1010....| Specifies the mobility parameter |
| | | of the sender node |
+---------------+--------+--------------------------------------+
Figure 22
Assigned HELLO address TLV types and bit layout in OLSRv2:
+---------------+--------+--------------------------------------+
| Mnemonic | Type | Value |
+---------------+--------+--------------------------------------+
| Link Status |00000000| Specifies a given link's status |
| | | asymmetric, verified bidirectional, |
| | | lost) |
+---------------+--------+--------------------------------------+
| MPR |00000001| Specifies that a given address is |
| | | selected as MPR |
+---------------+--------+--------------------------------------+
| Mobility |10100...| Specifies the mobility parameter |
| | | of the node with the given address |
+---------------+--------+--------------------------------------+
Figure 23
B.2.1.2. HELLO Message: Address Blocks and Address TLVs
If Mobility information are convoyed by HELLO messages, for each
OLSRv2 interface a node MUST generate a HELLO message with address
blocks and address TLVs accoridng to Figure 24.
Haerri, et al. Expires April 26, 2007 [Page 27]
Internet-Draft MANET Location Signaling October 2006
+--------------------------+----------------------------------------+
| Addresses: | TLVs (Type=Value) |
| | |
| The set of neighbor | |
| interfaces which are... | |
+--------------------------+----------------------------------------+
| HEARD over the interface | (Link Status=HEARD); |
| over which the HELLO is | (Interface=TransmittingInterface) |
| being transmitted | (Mobility=Neighbor Mobility) |
+--------------------------+----------------------------------------+
| SYMMETRIC over the | (Link Status=SYMMETRIC); |
| interface over which | (Interface=TransmittingInterface) |
| the HELLO is being | (Mobility=Neighbor Mobility) |
| transmitted | |
+--------------------------+----------------------------------------+
| LOST over the interface | (Link Status=LOST); |
| over which the HELLO is | (Interface=TransmittingInterface) |
| being transmitted | |
+--------------------------+----------------------------------------+
| SYMMETRIC over ANY | (Link Status=SYMMETRIC); |
| interface of the node | (Interface=TransmittingInterface) |
| other than the interface | (Mobility=2-hops Neighbor Mobility) |
| over which the HELLO is | |
| being transmitted | |
+--------------------------+----------------------------------------+
| selected as MPR for the | (Link Status=MPR); |
| interface over which the | (Interface=TransmittingInterface) |
| HELLO is transmitted | (MPR Selection=True) |
| | (Mobility=2-hops Neighbor Mobility) |
+--------------------------+----------------------------------------+
Figure 24
B.2.2. TC Messages
TC messages are, in OLSRv2, transmitted to the entire network with
the purpose of populating a topology information base as described in
[OLSRv2]. A TC message is conformed to the following layout:
<tc> = <tc-msg-tlvs>*{<addr_block><addr_block_tlv>*}*
Haerri, et al. Expires April 26, 2007 [Page 28]
Internet-Draft MANET Location Signaling October 2006
B.2.2.1. TC Message: Message TLVs
If Mobility information are convoyed by TC messages, each node
selected as MPR MUST generate TC messages with message TLVs according
to the following table:
+-------------+-------------------------------------+---------------+
| TLV Type | | Default Value |
+-------------+-------------------------------------+---------------+
| Seq. no | The current value of the ASSN of | N/A |
| | the node | |
+-------------+-------------------------------------+---------------+
Figure 26
Assigned TC message TLV types and bit layout in OLSRv2:
+---------------+--------+--------------------------------------+
| Mnemonic | Type | Value |
+---------------+--------+--------------------------------------+
| Content Seq. |00000000| Specifies the current value of the |
| Number | | ASSN of the node |
+---------------+--------+--------------------------------------+
| Mobility |10100...| Specifies the mobility parameter |
| | | of the sender node |
+---------------+--------+--------------------------------------+
Figure 27
B.2.2.2. TC Message: Message TLVs
If Mobility information are convoyed by TC messages, each node
selected as MPR MUST generates TC messages with address block and
address TLVs according to the following table:
+---------------------------------+---------------------------------+
| Addresses: | TLVs (Type=Value) |
+---------------------------------+---------------------------------+
| The set of neighbor interfaces | (Mobility= Neighbors Mobility) |
| which have selected the node as | |
| MPR | |
+---------------------------------+---------------------------------+
Haerri, et al. Expires April 26, 2007 [Page 29]
Internet-Draft MANET Location Signaling October 2006
Figure 28
Assigned TC address TLV types and bit layout in OLSRv2:
+---------------+--------+--------------------------------------+
| Mnemonic | Type | Value |
+---------------+--------+--------------------------------------+
| MPR Selector |00000000| Specifies that a given address has |
| | | selected the sender node as MPR |
+---------------+--------+--------------------------------------+
| Mobility |10100...| Specifies the mobility parameter |
| | | of the nodes with the given address |
+---------------+--------+--------------------------------------+
Figure 29
B.3. SMF
In [SMF], due to similar use of Hello messages as in OLSRv2, mobility
TLVs MAY be applied as in Section Appendix B.2 and considering the
new TLVs defined in [NHDP].
B.4. AODV
The current specification of AODV is overridden by DYMO
B.5. DYMO
[DYMO] is planned to use the mesage structure defined in [PacketBB]
as well as the hello structure defined in [NHDP]. Accordingly,
mobility TLVs MAY be applied as in Section Section 6
Haerri, et al. Expires April 26, 2007 [Page 30]
Internet-Draft MANET Location Signaling October 2006
Authors' Addresses
Jerome Haerri
Institut Eurecom, France
Phone: +33 4 93 00 8176
Email: haerri@eurecom.fr
Christian Bonnet
Institut Eurecom, France
Phone: +33 4 93 00 8108
Email: bonnet@eurecom.fr
Fethi Filali
Institut Eurecom, France
Phone: +33 4 93 00 8134
Email: filali@eurecom.fr
Haerri, et al. Expires April 26, 2007 [Page 31]
Internet-Draft MANET Location Signaling October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Haerri, et al. Expires April 26, 2007 [Page 32]