Internet DRAFT - draft-haerri-manet-location

draft-haerri-manet-location






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]