Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                          LIX, Ecole Polytechnique, France
Expires: December 21, 2006
Intended status: Standards Track                             C. Dearlove
Expires: August 13, 2007                 BAE Systems Advanced Technology
                                                                  Centre
                                                                 J. Dean
                                               Naval Research Laboratory
                                                  The OLSRv2 Design Team
                                                     MANET Working Group
                                                           June 19, 2006
                                                        February 9, 2007

              MANET Neighborhood Discovery Protocol (NHDP)
                        draft-ietf-manet-nhdp-00
                     draft-ietf-manet-nhdp-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 21, 2006. August 13, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   This document describes a 1-hop and symmetric 2-hop 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.  This is achieved
   through periodic message exchange.  This neighborhood discovery
   protocol may be used by any MANET protocols which need neighborhood
   information.

   The protocol imposes minimum requirements to the network by not
   requiring sequenced or reliable transmission of control traffic. networks (MANETs).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2. . .  5
   3.  Applicability Statement  . . . . . . . . . . . . . . . . .  5
   2. . .  6
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  7
   3.
     4.1.  HELLO Message Generation . . . . . . . . . . . . . . . . .  7
     4.2.  HELLO message content  . . . . . . . . . . . . . . . . . .  8
     4.3.  Node Behavior  . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Neighborhood Information Base  . . . . . . . . . . . . . . . .  9
     3.1. 10
     5.1.  Link Set . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2. 10
     5.2.  Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 10
     3.3. 11
     5.3.  Neighborhood Address Association Set . . . . . . . . . . . 11
     3.4. 12
     5.4.  2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 11
   4. 12
   6.  Packets and Messages . . . . . . . . . . . . . . . . . . . . . 13
     4.1.
     6.1.  HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.1.
       6.1.1.  Local Interface Block  . . . . . . . . . . . . . . . . 14
       4.1.2.  Message
       6.1.2.  Address Block TLVs . . . . . . . . . . . . . . . . . . . . . 14
       4.1.3.  Address Block TLVs . . .
   7.  HELLO Message Generation . . . . . . . . . . . . . . . 16
   5.  HELLO Message Generation . . . . 15
     7.1.  HELLO Message: Transmission  . . . . . . . . . . . . . . . 17
     5.1. 16
       7.1.1.  HELLO Message: Transmission Jitter  . . . . . . . . . . . . . . . 18
   6. . 17
   8.  HELLO Message Processing . . . . . . . . . . . . . . . . . . . 19
     6.1. 18
     8.1.  Populating the Link Set  . . . . . . . . . . . . . . . . . 19
     6.2. 18
     8.2.  Populating the Symmetric Neighbor Set  . . . . . . . . . . 20
     6.3. 19
     8.3.  Populating the Neighborhood Address Association Set  . . . 21
     6.4. 20
     8.4.  Populating the 2-Hop Neighbor Set  . . . . . . . . . . . . 22
     6.5. 20
     8.5.  Neighborhood Changes . . . . . . . . . . . . . . . . . . . 23
   7. 22
   9.  Proposed Values for Constants  . . . . . . . . . . . . . . . . 24
     7.1. 23
     9.1.  Message Intervals  . . . . . . . . . . . . . . . . . . . . 24
     7.2. 23
     9.2.  Holding Times  . . . . . . . . . . . . . . . . . . . . . . 24
     7.3.  Time . 23
     9.3.  Jitter Times . . . . . . . . . . . . . . . . . . . . . . . 23
     9.4.  Time . . . 24
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
     8.1.  Multicast Addresses . . . 23
   10. IANA Considerations  . . . . . . . . . . . . . . . . 25
     8.2.  Message Types . . . . . 24
     10.1. Multicast Addresses  . . . . . . . . . . . . . . . . . 25
     8.3.  TLV Types . . 24
     10.2. Message Types  . . . . . . . . . . . . . . . . . . . . . . 25
     8.4. 24
     10.3. TLV Types  . . . . . . . . . . . . . . . . . . . . . . . . 24
     10.4. LINK_STATUS and OTHER_NEIGHB Values  . . . . . . . . . . . 26
   9. 25
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     9.1. 26
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     9.2. 26
     11.2. Informative References . . . . . . . . . . . . . . . . . . 27 26
   Appendix A.  Heuristics for Generating HELLO Messages   Address Block TLV Combinations . . . . . . 28 . . . . . 27
   Appendix B.   HELLO Message Example  . . . . . . . . . . . . . . . . 31 28
   Appendix C.  Security Considerations   Time TLVs  . . . . . . . . . . . . . . . 33 . . . . . . 30
     C.1.  Representing Time  . . . . . . . . . . . . . . . . . . . . 30
     C.2.  General Time TLV Structure . . . . . . . . . . . . . . . . 30
     C.3.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 32
       C.3.1.  VALIDITY_TIME TLV  . . . . . . . . . . . . . . . . . . 32
       C.3.2.  INTERVAL_TIME TLV  . . . . . . . . . . . . . . . . . . 32
   Appendix D.  Flow and Congestion Control   Message Jitter . . . . . . . . . . . . . 35
   Appendix E.  Contributors . . . . . . 33
     D.1.  Jitter . . . . . . . . . . . . . . 36
   Appendix F.  Acknowledgements . . . . . . . . . . . . 33
       D.1.1.  Periodic message generation  . . . . . . . . . 37
   Authors' Addresses . . . . 33
       D.1.2.  Externally triggered message generation  . . . . . . . 34
       D.1.3.  Message forwarding . . . . . . . . . . . . . . . . . . 34
   Appendix E.   Utilizing Link Layer Information . . . . . . . . . . 36
   Appendix F.   Security Considerations  . . . . . . . . . . . . . . 38
   Intellectual Property and Copyright Statements
   Appendix F.1. Invalid HELLO messages . . . . . . . . . . 39

1.  Introduction

   This document describes a neighborhood discovery protocol (NHDP) for
   a mobile ad hoc . . . . . 38
   Appendix G.   Flow and Congestion Control  . . . . . . . . . . . . 40
   Appendix H.   Contributors . . . . . . . . . . . . . . . . . . . . 41
   Appendix I.   Acknowledgements . . . . . . . . . . . . . . . . . . 42
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
   Intellectual Property and Copyright Statements . . . . . . . . . . 44

1.  Introduction

   This document describes a neighborhood discovery protocol (NHDP) for
   a mobile ad hoc network (MANET).  It was originally developed for the
   Optimized Link State Routing Protocol version 2 (OLSRv2) [3], based
   on that used in the Optimized Link State Routing Protocol version 1
   [4].  It  The protocol uses an exchange of
   HELLO messages in order that each node can determine its neighborhood up to two hops distant.  This protocol
   is used by OLSRv2 to determine a node's 1-hop neighbors for routing,
   and to allow the selection of MultiPoint Relays (MPRs) for optimized
   flooding and topology reporting.
   symmetric 2-hop neighborhoods.

   This specification however only describes the both this HELLO message exchange exchange, the
   messages being defined as instances of the specification [1], and the
   information storage required for
   1-hop and symmetric 2-hop neighborhood discovery.  It may be used by
   any MANET protocols which need neighborhood information, and which
   may add an MPR mechanism, or an alternative to it, using appropriate
   TLVs (type-length-value objects) as specified in [1], using which
   this protocol's HELLO message format is defined.

   This protocol makes no assumptions about the underlying link layer,
   other than support of link local multicast.  Link layer information
   and notifications may be used if available and applicable to qualify applicable.

   This protocol is based on the neighborhood information.

1.1. discovery process
   contained in the Optimized Link State Routing Protocol (OLSR) [3].

2.  Terminology

   The keywords "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 [2].

   Additionally,

   The terms "packet", "message", "address block", "TLV", and "TLV
   block" in this document uses the following terminology:

   node are to be interpreted as described in [1].

   Additionally, this document uses the following terminology:

   Node  - A MANET router which implements this neighborhood discovery
      protocol.

   MANET interface  - A network device participating in a MANET and
      using this neighborhood discovery protocol.  A node may have
      several MANET interfaces, each interface being assigned one or more IP
      addresses.

   link

   Link  - A link is a pair of MANET interfaces from two different nodes, where at
      least one interface is able to hear (i.e. receive traffic
      from) from the other.

   symmetric

   Symmetric link  - A link where both MANET interfaces are able to hear
      (i.e.
      receive traffic from) from the other.

   asymmetric link - A link which is not symmetric.

   1-hop neighbor  - A node X is a 1-hop neighbor of a node Y if node Y
      can hear node X (i.e. a link exists from a MANET interface on node
      X to a MANET interface on node Y).

   symmetric

   Symmetric 1-hop neighbor  - A node X is a symmetric 1-hop neighbor of
      a node Y if a symmetric link exists from a MANET interface on node
      X to a MANET interface on node Y.

   symmetric

   Symmetric 2-hop neighbor  - A node X is a symmetric 2-hop neighbor of
      a node Y if node X is a symmetric 1-hop neighbor of a symmetric
      1-hop neighbor of node Y, but is not node Y itself.

   1-hop neighborhood  - The 1-hop neighborhood of a node X is the set
      of the 1-hop neighbors of node X.

   symmetric

   Symmetric 1-hop neighborhood  - The symmetric 1-hop neighborhood of a
      node X is the set of the symmetric 1-hop neighbors of node X.

   symmetric

   Symmetric 2-hop neighborhood  - The symmetric 2-hop neighborhood of a
      node X is the set of the symmetric 2-hop neighbors of node X.
      (This may include nodes in the 1-hop neighborhood, or even in the
      symmetric 1-hop neighborhood, of node X.)

1.2.

3.  Applicability Statement

   This neighborhood discovery protocol supports nodes which have one or
   more interfaces which participate participating in the MANET.  It provides each node
   with local topology information up to two hops away.  This
   information is made available to other protocols through a collection
   of sets describing the node's 1-hop neighborhood and symmetric 2-hop
   neighborhood, collectively known as the neighborhood information
   base.
   Neighborhood Information Base, described in Section 5.

   The specification protocol is designed specifically with IP (IPv4/IPv6) in
   mind.  All addresses within a control message are assumed to be of
   the same size, deduced from IP.  In the case of mixed IPv6 and IPv4
   addresses, IPv4 addresses are carried work in IPv6 networks where messages may be
   lost, such as specified due to collisions in [5].

   The packets defined wireless networks.  If relevant
   link layer information is available then it may be used by this specification may use any transport
   protocol.

   This protocol appropriate to works in a completely distributed manner and does
   not depend on any central entity.  It does not require any changes to
   the protocol using this specification.  When
   the diffusion mechanism enabled by this specification is employed,
   UDP may format of IP packets, thus any existing IP stack can be most appropriate. used as
   is.

   This protocol uses the packet and message exchange format formats specified in [1].
   This implies that the
   HELLO messages specified by this protocol may be extended using the
   TLV mechanisms described in [1], e.g. [1].  For example, if multipoint relays
   (MPRs) are to be calculated similarly to signal
   MPR selection as required by OLSRv2 [3].  This also implies that
   neighborhood discovery protocol in OLSR [3] and signaled
   to neighbors, then this information may be added to HELLO messages
   using an address block TLV.  HELLO messages can also be transmitted
   in packets with messages from other protocols, so long as these protocols that also use [1].

2.

4.  Protocol Overview and Functioning

   This protocol consists of a specification of specifies local signaling, which
   serves to: (one hop) signaling that:

   o  advertise  advertises the presence of a node and its MANET interfaces to
      adjacent nodes (1-hop neighbors); interfaces;

   o  discover  discovers links to adjacent nodes;

   o  perform  performs bidirectionality (symmetry) checks on the discovered links;

   o  advertise  advertises discovered links and whether each is symmetric to its
      1-hop neighbors and hence discover symmetric 2-hop neighbors;

   o  maintain  maintains an information base consisting of describing discovered links and
      their status, 1-hop neighbors and their MANET interfaces,
      symmetric 1-hop neighbors and symmetric 2-hop neighbors.

   Signaling consists of a single type of periodically transmitted
   message message, known as a HELLO
   message.  A HELLO message identifies its originator node and that
   node's MANET interfaces and addresses.  As a node receives HELLO
   messages and populates its information base, a list of 1-hop
   neighbors' MANET interface addresses and their link status (lost,
   symmetric or heard) is included in subsequent HELLO message content. messages.  Thus,
   the periodic transmission allows nodes to continuously track changes
   in their 1-hop and symmetric 2-hop neighborhoods.

   Because each node sends  If information
   about link quality is available from the link layer, then this may
   also be used, see Appendix E.

4.1.  HELLO Message Generation

   HELLO messages periodically, the protocol can
   tolerate reasonable message loss without requiring reliable
   transmission.  Such losses can occur frequently may be sent:

   o  Proactively, at a regular interval, known as HELLO_INTERVAL.
      HELLO_INTERVAL may be fixed, as suggested in radio networks Section 9, or may be
      dynamic.  For example HELLO_INTERVAL may be backed off due to collisions
      congestion or other transmission problems.

   The nominal time network stability.  Note that if HELLO_INTERVAL is
      dynamic, it is interpreted as the interval of within which the next
      HELLO message will be sent on the same MANET interface.

   o  As a node's periodic response to a change in the node itself, or its neighborhood,
      for example on first becoming active or in response to a new,
      broken or changed status link.

   o  In a combination of these proactive and responsive mechanisms.

   Jittering of HELLO transmission is
   known as HELLO_INTERVAL message generation and MAY be included transmission, as described
   in Section 7.1, may be appropriate.

   HELLO messages are sent independently on each MANET interface.

4.2.  HELLO message content

   Each HELLO message sent over a MANET interface need not contain all
   of the information appropriate to that MANET interface, however:

   o  A HELLO message.
   The message MUST contain all of its own local interface
      information.

   o  Within every time interval of length REFRESH_INTERVAL, HELLO
      messages sent over a MANET interface MUST include all of the
      information appropriate to that interface in at least one HELLO
      message sent on that interface.  This applies to otherwise purely
      responsive nodes as well as proactive nodes.

   o  A HELLO message MUST include a validity time value VALIDITY_TIME message TLV that
      indicates the length of time for which the message content is to
      be considered valid and included in the receiving node's information base.  In some
   uses
      Neighborhood Information Base.

   o  A HELLO message SHOULD include an INTERVAL_TIME message TLV that
      indicates the validity time may be a multiple of HELLO_INTERVAL to allow
   for lossy exchange current value of HELLO messages.

   HELLO messages MAY, in addition to periodic transmissions, also be
   generated as a response to some event (e.g. a change in the
   advertised neighborhood indicated by a received HELLO message or by a
   layer 2 notification, if available, indicating a change in a link to
   a neighbor).  However a HELLO_INTERVAL.

4.3.  Node Behavior

   A node MUST respect MUST:

   o  Respect a minimum interval, HELLO_MIN_INTERVAL, between successive
      HELLO message transmissions in
   order to maintain an upper bound on signaling traffic.

   This protocol over a given interface.  If jitter is designed to work in
      used then this interval may be reduced, but only by a completely distributed manner
   and does not depend on any central entity.  This protocol does random value
      not
   require any exceeding HP_MAXJITTER.

   o  Ensure that if HELLO_INTERVAL and other parameters are maintained
      dynamically, changes to do not invalidate the format guarantees of IP packets, thus any existing IP
   stack can be used as is.

   Each MANET node will form
      Section 7.1.

   o  Maintain, based on received HELLO messages, estimates of its 1-hop
      and symmetric 2-hop neighborhoods as this protocol operates.  These estimates can be
   maintained in an information base comprised of the data sets listed
   below.  These are
      Formally defined formally in Section 3 and 5, this can be summarized as follows:
      consisting of the following sets:

      Link Set  - This set records Records the status of all links from and, if
      symmetric, and to current
         and former 1-hop neighbors.  It also records as lost links
      which used to be symmetric but have since failed.  A node MUST
      record the Link Set in order to correctly send HELLO messages.

      Symmetric Neighbor Set  - This set records the addresses of Records the MANET
      interfaces status of current and former
         symmetric 1-hop neighbors, or, as lost, those which
      used to be.  Note that if neighbors.  If any of these nodes have more
         than one MANET interface then this set may record addresses
         that are not in the Link Set. A node MUST record the Symmetric Neighbor Set in
      order to correctly send HELLO messages.

      Neighborhood Address Association Set  - This set allows Allows the addresses of
         the MANET interfaces of each 1-hop neighbor to be associated
         with each other.  It is required for processes such as MPR
      selection as in [3].

      2-Hop Neighbor Set  - This set records Records the addresses of the MANET
         interfaces of symmetric 2-hop neighbors.  It is required for
      processes such as MPR selection as

      The information in [3].

3. the Link Set and Symmetric Neighbor Set MUST be
      maintained in order for a node to correctly generate HELLO
      messages.

5.  Neighborhood Information Base

   The neighborhood information base stores

   A node maintains a Neighborhood Information Base that records
   information about the its 1-hop
   neighborhood and the symmetric 2-hop neighborhood of a node.

   Note that it is possible for a neighborhoods.  The
   Neighborhood Information Base includes the Link Set, the Symmetric
   Neighbor Set, the Neighborhood Address Association Set and the 2-Hop
   Neighbor Set.

   A node, X, to can be present in both the 1-hop and symmetric 2-hop
   neighborhoods of another node, Y, concurrently.  If the link between node X and node Y breaks, this  This allows node X
   to be taken into consideration immediately considered as a symmetric 2-hop neighbor by node Y immediately, rather than waiting for a HELLO
   message exchange cycle.

   This specification assumes that all
   if the link between them fails.

   All addresses MUST have an associated prefix length.  The prefix length of an address is, length, which is
   included in HELLO
   messages, all addresses in the Neighborhood Information Base.
   Prefix lengths are indicated in HELLO messages using the
   PREFIX_LENGTH TLV specified in [1].  If [1]; if an address has no PREFIX_LENGTH TLV is present for a given address, it is assumed
   that the such TLV,
   then its prefix length for that address is equal to the length of the
   address. address length.  Two addresses
   are identical considered equal if and only if both the
   addresses and their associated prefix lengths
   are identical.

   Addresses recorded in the neighborhood information base
   (L_local_iface_addr, L_neighbor_iface_addr, N_local_iface_addr,
   N_neighbor_iface_addr, N2_local_iface_addr, N2_neighbor_iface_addr,
   N2_2hop_iface_addr and those listed in NA_neighbor_iface_addr_list)
   MUST all be recorded with prefix lengths, in order to allow
   comparison with addresses received in HELLO messages.

3.1. also equal.

5.1.  Link Set

   A node node's Link Set records a set of "Link Tuples", recording information about its 1-hop neighborhood: neighborhood.  It consists of
   Link Tuples:

     (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time,
      L_ASYM_time, L_time)

   each describing a link between a MANET interface of this node and a
   MANET interface of one of its 1-hop neighbors,

   where:

   L_local_iface_addr  is the address of the local MANET interface of the local
      node on
      which the 1-hop neighbor is or was heard;

   L_neighbor_iface_addr  is the address of the MANET interface of the
      1-hop neighbor;

   L_SYM_time  is the time until which the link to the 1-hop neighbor is
      considered symmetric;

   L_ASYM_time  is the time until which the MANET interface of the 1-hop
      neighbor is considered heard;

   L_time  specifies when this Link Tuple expires and MUST be removed.

   The status of the link, denoted L_STATUS, can be derived based on the
   fields L_SYM_time and L_ASYM_time as defined in Table 1.

                 +-------------+-------------+-----------+
                 | L_SYM_time  | L_ASYM_time | L_STATUS  |
                 +-------------+-------------+-----------+
                 | Expired     | Expired     | LOST      |
                 |             |             |           |
                 | Not Expired | Expired     | SYMMETRIC |
                 |             |             |           |
                 | Not Expired | Not Expired | SYMMETRIC |
                 |             |             |           |
                 | Expired     | Not Expired | HEARD     |
                 +-------------+-------------+-----------+

                                  Table 1

   In a node, the set of Link Tuples is denoted the "Link Set".

3.2.

5.2.  Symmetric Neighbor Set

   A node records a set of "Symmetric node's Symmetric Neighbor Tuples", recording
   information about Set records its symmetric 1-hop neighborhood:
   neighborhood.  It consists of Symmetric Neighbor Tuples:

     (N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time)

   each describing an address of a MANET interface of this node and an
   address of a MANET interface of one of its symmetric 1-hop neighbors,

   where:

   N_local_iface_addr  is the address of the local MANET interface of the local
      node to
      which the 1-hop neighbor has or had a symmetric link;

   N_neighbor_iface_addr  is an address of a MANET interface of a 1-hop
      neighbor which is or was in this node's a symmetric 1-hop
      neighborhood; neighbor of this node;

   N_SYM_time  is the time until which the 1-hop neighbor is considered
      to be in this node's a symmetric 1-hop neighborhood; neighbor;

   N_time  specifies when this Symmetric Neighborhood Tuple expires and MUST be removed.

   The status of the 1-hop neighbor, denoted N_STATUS, can be derived
   based on the field L_SYM_time as defined in Table 2.

                        +-------------+-----------+
                        | N_SYM_time  | N_STATUS  |
                        +-------------+-----------+
                        | Expired     | LOST      |
                        |             |           |
                        | Not Expired | SYMMETRIC |
                        +-------------+-----------+

                                  Table 2

   In a node, the set of Symmetric Neighbor Tuples is denoted the
   "Symmetric Neighbor Set".

3.3.

5.3.  Neighborhood Address Association Set

   A node records a set of "Neighborhood node's Neighborhood Address Association Tuples",
   recording information about Set records the MANET
   interface configuration of its 1-hop neighbors: neighbors.  It consists of
   Neighborhood Address Association Tuples:

     (NA_neighbor_iface_addr_list, NA_time)

   where:

   NA_neighbor_iface_addr_list  is a list of interface addresses of a
      single 1-hop neighbor;

   NA_time  specifies when this Neighborhood Address Association Tuple expires and MUST be removed.

   In a node, the set of Neighborhood Address Association Tuples is
   denoted the "Neighborhood Address Association Set".

3.4.

5.4.  2-Hop Neighbor Set

   A node records a set of "2-Hop node's 2-Hop Neighbor Tuples", recording
   information about a Set records its symmetric 2-hop neighborhood: neighborhood.
   It consists of 2-Hop Neighbor Tuples:

     (N2_local_iface_addr, N2_neighbor_iface_addr, N2_2hop_iface_addr,
      N2_time)

   each describing a symmetric link between an address of a MANET
   interface of one of this node's symmetric 1-hop neighbors and an
   address of a MANET interface of a node in this node's symmetric 2-hop
   neighborhood.

   where:

   N2_local_iface_addr  is the address of the local MANET interface over on
      which the information defining this 2-Hop Neighbor Tuple information was received;

   N2_neighbor_iface_addr  is the address of the MANET interface address of a
      symmetric 1-hop neighbor;

   N2_2hop_iface_addr  is the address of a MANET interface of a
      symmetric 2-hop neighbor which has a symmetric link (not necessarily using
      this address) (using any
      MANET interface) to the node with MANET interface address
      N2_neighbor_iface_addr; indicated symmetric 1-hop neighbor;

   N2_time  specifies the time at which this 2-Hop Neighbor Tuple expires and MUST be
      removed.

   In a node, the set of 2-Hop Neighbor Tuples is denoted the "2-Hop
   Neighbor Set".

4.

6.  Packets and Messages

   The packet and message format used by this neighborhood discovery
   protocol is defined in [1], which is used with the following
   considerations:

   o  this protocol specifies one message type, the HELLO message, in
      Section 4.1; message;

   o  HELLO message header options may be used as specified by the
      protocol which uses this neighborhood discovery protocol;

   o  HELLO messages are transmitted only one hop, i.e. MUST NOT be forwarded;

   o  HELLO messages may be included in multi-message packets as
      specified in [1];

   o  packet header options may be created using other messages as
      specified by the protocol which uses this neighborhood discovery
      protocol;

   o  packet header options may be used used as specified by the protocol
      which uses this neighborhood discovery protocol.

4.1.

6.1.  HELLO Messages

   A HELLO message MUST contain:

   o  a  A VALIDITY_TIME message TLV with Type == VALIDITY_TIME and Value == H_HOLD_TIME, as specified in Section 4.1.2.1 Appendix C,
      representing time value (at distance one hop) H_HOLD_TIME, which
      MUST NOT be less than REFRESH_INTERVAL.  If HELLO messages may be
      lost then H_HOLD_TIME SHOULD be a multiple of REFRESH_INTERVAL.

   o  an  An address block block, and associated TLV block, known as the Local
      Interface Block, as specified in Section 4.1.1; other addresses MUST NOT be added to this
      address block. 6.1.1.

   A HELLO message which is transmitted at a regular interval SHOULD
   contain, and otherwise MAY contain:

   o  a  An INTERVAL_TIME message TLV with Type == INTERVAL_TIME and Value ==
      HELLO_INTERVAL, as specified in Section 4.1.2.2;

   o Appendix C,
      representing time value (at distance one hop) HELLO_INTERVAL.

   A HELLO message MAY contain:

   o  One or more address blocks blocks, with associated address block TLVs as
      specified in Section 4.1.3; these address blocks contain TLVs,
      containing current or former 1-hop neighbors' MANET interface addresses with
      associated TLVs.
      addresses.  Other addresses (i.e. addresses of non-neighbor nodes)
      MAY be added to included in these address blocks, however if they are
      then these addresses but MUST NOT have be
      associated TLVs from with any of the
      address block TLVs specified in Section 4.1.3.

   This protocol specifies two 6.1.2.

   o  Other message TLVs and three address block TLVs
   used in HELLO messages in Section 4.1.2 and Section 4.1.3; other TLVs
   MAY be included as specified by the protocol which uses this
   neighborhood discovery protocol.

4.1.1. TLVs.

6.1.1.  Local Interface Block

   The first address block, plus following TLV block, in a HELLO message
   is known as the Local Interface Block.  The Local Interface Block is
   not distinguished in any way other than by being the first address
   block in the message.

   The first address of the Local Interface Block MUST contain be the used
   address of the MANET interface over which the HELLO message is
   transmitted.
   If that interface has an associated prefix different from the length
   of the address, a PREFIX_LENGTH TLV MUST be associated with this
   address.  This first address, with associated prefix length, of the
   Local Interface Block is henceforth denoted the "Source Address".

   The Local Interface Block MUST contain all of the addresses of all of
   the MANET interfaces of the originating node, using the standard
   <address-block> syntax specified in [1]. and no other addresses.
   Those addresses, if any, which correspond to MANET interfaces other
   than that on which the HELLO message is transmitted MUST have a
   corresponding OTHER_IF TLV as specified in Section 4.1.3, 6.1.2, other
   addresses (i.e. those of the MANET interface on which the HELLO
   message is transmitted) MUST NOT use this TLV.

   Note that a Local Interface Block MAY include more than one address
   for each MANET interface, and hence a HELLO message MAY contain more
   than one address without an OTHER_IF TLV.  A Local Interface

6.1.2.  Address Block
   MUST NOT contain any addresses which are not of MANET interfaces of
   the originating node.

4.1.2.  Message TLVs

   This section specifies two message TLVs: VALIDITY_TIME and
   INTERVAL_TIME.

4.1.2.1.  VALIDITY_TIME TLV

   All HELLO messages MUST include a VALIDITY_TIME TLV, specifying for
   how long a node may, upon receiving a message, consider the message
   content to be valid.

   The VALIDITY_TIME TLV, described three address block TLVs used in this
   document, contains a single value since HELLO messages are
   transmitted only one hop.  Note that [1] specifies an extended
   version of this VALIDITY_TIME TLV, which is compatible with the
   format of the VALIDITY_TIME TLV in this specification.

   The VALIDITY_TIME message TLV specification is given specified in
   Table 3.

   +----------------+------+-------------------+----------------------+

   +----------------+------+-------------------+-----------------------+
   |      Name      | Type |       Length      | Value                 |
   +----------------+------+-------------------+----------------------+
   +----------------+------+-------------------+-----------------------+
   |  VALIDITY_TIME    OTHER_IF    |  TBD |       8       0 bits      | <t_default> Not Applicable        |
   +----------------+------+-------------------+----------------------+

                                  Table 3

   where <t_default> is the period for which the information is valid,
   represented as specified in Section 4.1.2.3.

4.1.2.2.  INTERVAL_TIME TLV

   HELLO messages MAY include an INTERVAL_TIME message TLV, specifying
   the interval at which HELLO messages are being generated by the
   originator node.  Note that HELLO messages which are not part
   |                |      |                   |                       |
   |   LINK_STATUS  |  TBD |       8 bits      | One of a
   regular schedule SHALL be ignored in defining the interval.  If, for
   whatever reason, HELLO messages are sent in an irregular pattern,
   then this SHALL be the longest interval in that pattern.

   The INTERVAL_TIME message TLV specification is given in Table 4.

   +----------------+------+-------------------+----------------------+ LOST,          |
   |                |      |                   | SYMMETRIC or HEARD    |      Name
   | Type                |       Length      | Value                   |
   +----------------+------+-------------------+----------------------+                       |  INTERVAL_TIME
   |  OTHER_NEIGHB  |  TBD |       8 bits      | <time> One of LOST or        |
   |
   +----------------+------+-------------------+----------------------+                |      |                   | SYMMETRIC             |
   +----------------+------+-------------------+-----------------------+

                                  Table 4

   where <time> is the scheduled maximum time until 3

7.  HELLO Message Generation

   HELLO messages MUST be generated and transmitted independently on
   each MANET interface.  If using the next
   transmission of a HELLO message by the originator node interval
   HELLO_INTERVAL then, following a HELLO message transmission on a
   MANET interface, another HELLO message MUST be sent on the same
   interface, represented
   interface after an interval not greater than HELLO_INTERVAL.  Two
   successive HELLO message transmissions on the same MANET interface
   MUST be separated by at least HELLO_MIN_INTERVAL, except as specified noted in
   Section 4.1.2.3.

4.1.2.3.  Representing Time

   Section 4.1.2.1 and Section 4.1.2.2 specify TLVs where time is
   represented as 7.1.1.

   A HELLO message MUST include a single octet.  This is defined by the lowest four
   bits of the octet representing the mantissa (a) and the highest four
   bits of the octet representing the exponent (b) of the time Local Interface Block as a
   multiple of a fixed constant C, yielding that: specified in
   Section 6.1.1 as its first address block.

   Other addresses which MUST be included in HELLO messages are:

   o  time = C * (1 + a/16) * 2^b

   where a is the integer represented by the four lowest bits  addresses of 1-hop neighbors from the
   time field and b the integer represented by the four highest bits Link Set;

   o  addresses of 1-hop neighbors from the time field.  All nodes in the network Symmetric Neighbor Set.

   These addresses MUST use the same value of
   C, which will NOT be specified included in seconds, hence so will be all times
   (see Section 7).  Note that ascending values of the octet represent
   ascending values of time, times may thus Local Interface Block.
   These addresses MAY be compared by comparison of
   octets.

   An algorithm for computing included in any HELLO messages sent on the representation of time t
   appropriate MANET interface.  These addresses, and their associated
   TLVs, are:

   1.  For each address which appears as an L_neighbor_iface_addr in one
       or more Link Tuples whose L_local_iface_addr is an address of the
   following:

   1.  find
       MANET interface over which the largest integer b such HELLO message is to be sent,
       include that t/C >= 2^b;

   2.  set a = 16 L_neighbor_iface_addr with an associated TLV with:

       * (t / (C  Type = LINK_STATUS; AND

       * 2^b) - 1), rounded up to the nearest
       integer;

   3.  Value = L_STATUS.

   2.  For each address which appears as an N_neighbor_iface_addr in one
       or more Symmetric Neighbor Tuples:

       1.  if a this address has already been included with an associated
           TLV with Type == 16 LINK_STATUS and Value == SYMMETRIC, do not
           add an associated TLV with Type == OTHER_NEIGHB;

       2.  otherwise if, for one or more of these Symmetric Neighbor
           Tuples, N_STATUS == SYMMETRIC, then set b include this
           N_neighbor_iface_addr with an associated TLV with:

           +  Type = b OTHER_NEIGHB; AND
           + 1 and set a  Value = 0;

   4.  if a SYMMETRIC.

       3.  otherwise if, for all of these Symmetric Neighbor Tuples,
           N_STATUS == LOST, and b are in the range 0 this address has not already been
           included with an associated TLV with Type == LINK_STATUS and 15
           Value == LOST, then t can be represented by include this N_neighbor_iface_addr with
           an octet holding the value 16*b associated TLV with:

           + a, otherwise it can not.

   As examples, the values  Type = OTHER_NEIGHB; AND

           +  Value = LOST.

   On each of 2 seconds and 6 seconds are represented by
   (a=0, b=5) its MANET interfaces, for each specified 1-hop neighbor
   address and (a=8, b=6), respectively, i.e., by associated TLV, the octets 80 and
   104 (hexadecimal 50 and 68).

4.1.3.  Address Block TLVs

   The three address block TLVs used and associated TLV MUST be
   included in at least one HELLO messages are specified message in
   Table 5.

   +----------------+------+-------------------+-----------------------+
   |      Name      | Type |       Length      | Value                 |
   +----------------+------+-------------------+-----------------------+
   |    OTHER_IF    |  TBD |       0 bits      | Not Applicable        |
   |                |      |                   |                       |
   |   LINK_STATUS  |  TBD |       8 bits      | One of LOST,          |
   |                |      |                   | SYMMETRIC or HEARD.   |
   |                |      |                   |                       |
   |  OTHER_NEIGHB  |  TBD |       8 bits      | One of LOST or        |
   |                |      |                   | SYMMETRIC             |
   +----------------+------+-------------------+-----------------------+

                                  Table 5

5.  HELLO Message Generation

   HELLO messages MUST be generated and transmitted independently on
   each MANET interface.  The maximum every interval between HELLO
   transmissions on the same MANET interface MUST NOT exceed
   HELLO_MIN_INTERVAL.  Two successive HELLO message transmissions on
   the same MANET interface MUST be separated by at least
   HELLO_MIN_INTERVAL.

   Each HELLO message MUST include a Local Interface Block as specified
   in Section 4.1.1 as its first address block.

   On its MANET interface with of length
   REFRESH_INTERVAL.

   If an address Sending Address, a node MUST
   report appropriate addresses is specified with more than one associated TLV, then
   these TLVs from the Link Set
   and Symmetric Neighbor Set. These addresses, with their associated
   TLVs, MAY be reported in any independently included or excluded from each HELLO
   messages transmitted on that MANET
   interface.  All as long as each such addresses, with their TLV is included associated TLVs, MUST be
   reported with that
   address in at least one a HELLO message transmitted sent on that MANET interface within in every
   interval of length REFRESH_INTERVAL.  These
   addresses MUST NOT be included in

   TLVs associated with the Local Interface Block, they MAY
   be included in any other same address block.

   The addresses, with their associated TLVs, which MUST be included in the same HELLO messages over the local MANET interface with address Sending
   Address, are computed thus:

   1.  For each Link Tuple with L_local_iface_addr == Sending Address,
       include:

       *  L_neighbor_iface_addr with an associated TLV with:

          +  Type = LINK_STATUS; AND

          +  Value = L_STATUS.

   2.  For each address which appears as an N_neighbor_iface_addr in one
       or more Symmetric Neighbor Tuples:

       1.  if this address has already been included with an associated
           TLV with Type == LINK_STATUS and Value == SYMMETRIC, do not
           add an associated TLV with Type == OTHER_NEIGHB;

       2.  otherwise if, for one or more of these Symmetric Neighbor
           Tuples, N_STATUS == SYMMETRIC, then include this address with
           associated TLV with:

           +  Type = OTHER_NEIGHB; AND
           +  Value = SYMMETRIC;

       3.  otherwise if, for all of these Symmetric Neighbor Tuples,
           N_STATUS == LOST, and this address has not already been
           included with an associated TLV with Type == LINK_STATUS and
           Value == LOST, then include this address with associated TLV
           with:

           +  Type = OTHER_NEIGHB; AND

           +  Value = LOST.

   If an address is specified as included with more than one associated
   TLV, then these TLVs MAY be independently included or excluded from
   HELLO messages as long as all are included with any interval of
   length REFRESH_INTERVAL.  TLVs applying to the same address MAY be
   applied to
   message MAY be applied to the same or different copies of the address in a given
   HELLO message.

5.1. that
   address.

7.1.  HELLO Message: Transmission

   Messages are transmitted in the packet/message format specified by
   [1] using the ALL-MANET-NEIGHBORS multicast address as destination IP
   address
   address, and with the HELLO message Hop Limit hop limit = 1.

6.  HELLO Message Processing

   On receiving a HELLO message, a node will update its neighborhood
   information base according to

   If the specification parameters of the protocol are changed, then guarantees given in this
   section.

   For
   for the purpose old values of this section, the parameters MUST still be respected.  In
   particular:

   o  If HELLO_INTERVAL is increased, then a HELLO message MUST be sent
      within the old HELLO_INTERVAL of the previous HELLO message sent
      on each MANET interface.

   o  If REFRESH_INTERVAL is increased, then all information (addresses
      and associated TLVs) must be sent again on each MANET interface
      within the old REFRESH_INTERVAL of the previous HELLO message that
      included that information.

7.1.1.  HELLO Message: Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If using data link and
   physical layers which are subject to packet loss due to collisions,
   HELLO messages SHOULD be jittered as described in Appendix D.

   Internally triggered message generation MAY be treated as if
   externally generated message generation, or MAY be not jittered.

   HELLO messages MUST NOT be forwarded, and thus message forwarding
   jitter does not apply to HELLO messages.

   Each form of jitter described in Appendix D requires a parameter
   MAXJITTER.  These parameters may be dynamic, and are specified by:

   o  For periodic message generation: HP_MAXJITTER, which MUST be
      significantly less than HELLO_INTERVAL.

   o  For externally triggered message generation: HT_MAXJITTER.  If
      HELLO messages are also periodically generated then HT_MAXJITTER
      also MUST be significantly less than HELLO_INTERVAL.

   When HELLO message generation is delayed in order that a HELLO
   message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
   message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
   be reduced by jitter, with maximum reduction HP_MAXJITTER.  In this
   case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.

8.  HELLO Message Processing

   On receiving a HELLO message, a node MUST update its neighborhood
   information base.

   For the purpose of this section, note the following definitions:

   o  the "validity time" of a message is calculated from the
      VALIDITY_TIME TLV of the message as specified in Section 4.1.2.1; Appendix C;

   o  the "Source Address" is the first address, including prefix
      length, of the Local Interface Block in the HELLO message;

   o  the "Receiving Address" is the address, including prefix length,
      of the MANET interface on which the HELLO message was received;

   o  the word EXPIRED indicates that a timer is set to a value clearly
      preceding the current time (e.g. current time - 1).

6.1.

8.1.  Populating the Link Set

   On receiving a HELLO message, a node SHOULD update its Link Set:

   1.  If there is no Link Tuple with:

       *  L_local_iface_addr == Receiving Address; AND

       *  L_neighbor_iface_addr == Source Address,

       then create a new Link Tuple with

       *  L_local_iface_addr = Receiving Address;

       *  L_neighbor_iface_addr = Source Address;

       *  L_SYM_time = EXPIRED;

       *  L_time = current time + validity time.

   2.  This Link Tuple (existing or new) is then modified as follows:

       1.  If the node finds the Receiving Address in one of the address
           blocks included in the HELLO message, other than the Local
           Interface Block, then the Link Tuple is modified as follows:

           1.  If the Receiving Address in that address block is
               associated with a TLV with Type == LINK_STATUS and Value
               == LOST then:

               1.  if L_STATUS == SYMMETRIC:

                   o  L_time = current time + max(validity time,
                      L_HOLD_TIME),

                   o  L_SYM_time = EXPIRED.

           2.  Otherwise if the Receiving Address in that address block
               is associated with a TLV with Type == LINK_STATUS and
               (Value == HEARD or Value == SYMMETRIC) then:

               -  L_SYM_time = current time + validity time;

               -  L_time = L_SYM_time + L_HOLD_TIME.

       2.  L_ASYM_time = current time + validity time;

       3.  L_time = max(L_time, L_ASYM_time).

6.2.

8.2.  Populating the Symmetric Neighbor Set

   On receiving a HELLO message, a node SHOULD update its Symmetric
   Neighbor Set:

   1.  If the Receiving Address is in an address block of the HELLO
       message, other than the Local Interface Block, with an associated
       TLV with Type == LINK_STATUS and (Value == HEARD or Value ==
       SYMMETRIC) then:

       1.  For each address (henceforth neighbor address) in the HELLO
           message's Local Interface Block:

           1.  If there is a Symmetric Neighbor Tuple with:

               -  N_local_iface_addr == Receiving Address; AND

               -  N_neighbor_iface_addr == neighbor address,

               then update this Symmetric Neighbor Tuple to have:

               -  N_SYM_time = current time + validity time;

               -  N_time = N_SYM_time + N_HOLD_TIME.

           2.  Otherwise create a new Symmetric Neighbor Tuple with:

               -  N_local_iface_addr = Receiving Address;
               -  N_neighbor_iface_addr = neighbor address;

               -  N_SYM_time = current time + validity time;

               -  N_time = N_SYM_time + N_HOLD_TIME.

   2.  Otherwise if the Receiving Address is in an address block of the
       HELLO message, other than the Local Interface Block, with an
       associated TLV with Type == LINK_STATUS and Value == LOST, then:

       1.  For each address (henceforth neighbor address) in the HELLO
           message Local Interface Block, if there exists a Symmetric
           Neighbor Tuple with:

           +  N_local_iface_addr == Receiving Address; AND

           +  N_neighbor_iface_addr == neighbor address,

           update this Symmetric Neighbor Tuple to have:

           +  N_SYM_time = EXPIRED;

           +  N_time = min(N_time, current time + N_HOLD_TIME).

6.3.

8.3.  Populating the Neighborhood Address Association Set

   On receiving a HELLO message, the node SHOULD update its Neighborhood
   Address Association Set:

   1.  Remove all Neighborhood Address Association Tuples where:

       *  NA_neighbor_iface_addr_list contains at least one address
          which is contained in the Local Interface Block of the
          received HELLO message,

       and create a new Neighborhood Address Association Tuple with:

       *  NA_neighbor_iface_addr_list = list of all addresses contained
          in the Local Interface Block of the received HELLO message;

       *  NA_time = current time + validity time.

6.4.

8.4.  Populating the 2-Hop Neighbor Set

   On receiving a HELLO message the node SHOULD update its 2-Hop
   Neighbor Set:

   1.  If there exists a Link Tuple with L_local_iface_addr == Source
       Address and L_STATUS == SYMMETRIC then:

       1.  For each address (henceforth 2-hop neighbor address) in an
           address block of the HELLO message, other than the Local
           Interface Block, which is not an interface address of the
           receiving node:

           1.  If the 2-hop neighbor address has an associated TLV with:

               -  Type == LINK_STATUS and Value == SYMMETRIC; OR

               -  Type == OTHER_NEIGHB and Value == SYMMETRIC,

               then, if there is no 2-Hop Neighbor Tuple with:

               -  N2_local_iface_addr == Receiving Address;

               -  N2_neighbor_iface_addr == Source Address;

               -  N2_2hop_iface_addr == 2-hop neighbor address;

               create a 2-Hop Neighbor Tuple with:

               -  N2_local_iface_addr = Receiving Address; AND

               -  N2_neighbor_iface_addr = Source Address; AND

               -  N2_2hop_iface_addr = 2-hop neighbor address.

               This 2-Hop Neighbor Tuple (existing or new) is then
               modified as follows:

               -  N2_time = current time + validity time.

           2.  Otherwise if the 2-hop neighbor address has a TLV with:

               -  Type == LINK_STATUS and (Value == LOST or Value ==
                  HEARD); OR

               -  Type == OTHER_NEIGHB and Value == LOST;

               then remove all 2-Hop Neighbor Tuples with:

               -  N2_local_iface_addr == Receiving Address; AND

               -  N2_neighbor_iface_addr == Source Address; AND
               -  N2_2hop_iface_addr == 2-hop neighbor address.

6.5.

8.5.  Neighborhood Changes

   If the L_SYM_time field of a Link Tuple expires (either due to timing
   out, or as a result of processing a TLV with Type == LINK_STATUS and
   Value == LOST) then all 2-Hop Neighbor Tuples with:

   o  N2_local_iface_addr == L_local_iface_addr from the Link Tuple,
      AND;

   o  N2_neighbor_iface_addr == L_neighbor_iface_addr from the Link
      Tuple,

   MUST be deleted.

   In this, or any other case of neighborhood change, a node MAY send a
   HELLO message reporting updated information.  If a node does send
   such a HELLO message information, subject to the node MUST ensure that any two successive
   HELLO messages are separated by at least HELLO_MIN_INTERVAL.
   constraints in Section 7.

9.  Proposed Values for Constants

   This section list the lists proposed values for the constants used in the
   description
   specification of the protocol.

7.1.

9.1.  Message Intervals

   o  HELLO_INTERVAL = 2 seconds

   o  REFRESH_INTERVAL = HELLO_INTERVAL

   o  HELLO_MIN_INTERVAL = HELLO_INTERVAL/4

7.2.

9.2.  Holding Times

   o  H_HOLD_TIME = 3 x REFRESH_INTERVAL

   o  L_HOLD_TIME = H_HOLD_TIME

   o  N_HOLD_TIME = H_HOLD_TIME

7.3.

9.3.  Jitter Times

   o  HP_MAXJITTER = HELLO_INTERVAL/4

   o  HT_MAXJITTER = HELLO_INTERVAL/4

9.4.  Time

   o  C = 0.0625 seconds second (1/16 second)

   In order to achieve interoperability, C MUST be the same on all
   nodes.

8.

10.  IANA Considerations

8.1.

10.1.  Multicast Addresses

   A well-known link-local multicast address, ALL-MANET-NEIGHBORS, must
   be registered and defined for both IPv6 and IPv4.  The addressing scope
   is link-local, i.e. this address is similar to the all nodes/routers
   multicast address of IPv6 in that it targets all MANET nodes adjacent
   to the originator of an IP datagram.

8.2.

10.2.  Message Types

   This specification defines one message type, which must be allocated
   from the "Assigned Message Types" repository of [1] [1].

   +--------------------+-------+--------------------------------------+
   |      Mnemonic      | Value | Description                          |
   +--------------------+-------+--------------------------------------+
   |        HELLO       |  TBD  | Local Signaling signaling                      |
   +--------------------+-------+--------------------------------------+

                                  Table 6

8.3. 4

10.3.  TLV Types

   This specification defines two Message TLV types, which must be
   allocated from the "Assigned Message TLV Types" repository of [1] [1].

   +--------------------+-------+--------------------------------------+
   |      Mnemonic      | Value | Description                          |
   +--------------------+-------+--------------------------------------+
   |    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  |
   +--------------------+-------+--------------------------------------+

                                  Table 7 5

   This specification defines three Address Block TLV types, which must
   be allocated from the "Assigned Address Block TLV Types" repository
   of [1] [1].

   +--------------------+-------+--------------------------------------+
   |      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 the status of the link to  |
   |                    |       | the indicated address (LOST,         |
   |                    |       | SYMMETRIC or HEARD)                  |
   |                    |       |                                      |
   |    OTHER_NEIGHB    |  TBD  | Specifies that the address is, or is        |
   |                    |       | was, (SYMMETRIC) or was (LOST) of a MANET |
   |                    |       | interface of a symmetric 1-hop       |
   |                    |       | symmetric 1-hop neighbor of the node transmitting    |
   |                    |       | transmitting the HELLO message, but does not have |
   |                    |       | does not have a matching or better   |
   |                    |       | LINK_STATUS TLV |
   +--------------------+-------+--------------------------------------+

                                  Table 8

8.4. 6

10.4.  LINK_STATUS and OTHER_NEIGHB Values

   The values which the LINK_STATUS TLV can use are the following:

   o  LOST = 0

   o  SYMMETRIC = 1

   o  HEARD = 2

   The values which the OTHER_NEIGHB TLV can use are the following:

   o  LOST = 0

   o  SYMMETRIC = 1

9.

11.  References

9.1.

11.1.  Normative References

   [1]  Clausen, T., Dean, J., Dearlove, C., Dean, J., and C. Adjih, "Generalized
        MANET Packet/Message Format", Work In
        Progress draft-ietf-manet-packetbb-01.txt, June 2006. draft-ietf-manet-packetbb-03.txt, January 2007.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

9.2.

11.2.  Informative References

   [3]  Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized Link
        State Routing Protocol version 2", Work In
        Progress draft-ietf-manet-olsrv2-02.txt, June 2006.

   [4]  Clausen, T. and P. Jacquet, "The Optimized Link State Routing
        Protocol", RFC 3626, October 2003.

   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

Appendix A.  Heuristics for Generating HELLO Messages  Address Block TLV Combinations

   The algorithm for generating HELLO messages in Section 5 7 specifies
   which addresses MAY be included in the address blocks after the Local
   Interface Block, and with which associated TLVs.  These TLVs may have
   Type == LINK_STATUS or Type == OTHER_NEIGHB, or both.  TLVs with Type
   == LINK_STATUS may have three possible values (Value == HEARD, Value
   == SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may
   have two possible values (Value == SYMMETRIC or Value == LOST).  When
   both TLVs are associated with the same address only certain
   combinations of these TLV values are necessary, and are the only
   combinations generated by the algorithm in Section 5. 7.  These
   combinations are indicated in Table 9. 7.

   Cells labeled with "Yes" indicate the possible combinations which are
   generated by the algorithm in Section 5. 7.  Cells labeled with "No"
   indicate combinations not generated by the algorithm in Section 5, 7,
   but which are correctly parsed and interpreted by the algorithm in
   Section 6. 8.

   +----------------+----------------+----------------+----------------+
   |                |     Type ==    |     Type ==    |     Type ==    |
   |                |  OTHER_NEIGHB  |  OTHER_NEIGHB, |  OTHER_NEIGHB, |
   |                |    (absent)    |    Value ==    |  Value == LOST |
   |                |                |    SYMMETRIC   |                |
   +----------------+----------------+----------------+----------------+
   | Type ==        |       No       |       Yes      |       Yes      |
   | LINK_STATUS    |                |                |                |
   | (absent)       |                |                |                |
   |                |                |                |                |
   | Type ==        |       Yes      |       Yes      |       Yes      |
   | LINK_STATUS,   |                |                |                |
   | Value == HEARD |                |                |                |
   |                |                |                |                |
   | Type ==        |       Yes      |       No       |       No       |
   | LINK_STATUS,   |                |                |                |
   | Value ==       |                |                |                |
   | SYMMETRIC      |                |                |                |
   |                |                |                |                |
   | Type ==        |       Yes      |       Yes      |       No       |
   | LINK_STATUS,   |                |                |                |
   | Value == LOST  |                |                |                |
   +----------------+----------------+----------------+----------------+

                                  Table 9

   In creating the 7

Appendix B.  HELLO message there are three stages:

   1.  collect the addresses into groups, each of which will form an
       address block (this heuristic assumes that each address will be
       included only once in a Message Example

   An example HELLO message, and that all TLVs
       associated sent by an originator node with it are included);

   2.  order the addresses in each group for most efficient TLV
       association;

   3.  add the TLVs in the most efficient manner, whether a single or
       multiple value.

   There
   MANET interface, is no straightforward way to perform these steps to create the
   most optimal (smallest) HELLO message.  Instead the following
   heuristics may be considered:

   1. as follows.  The easiest approach to grouping message uses IPv4 (four octet)
   addresses without prefix TLVs.  The message is to put them all in sent with a single address block.  Separate address blocks are appropriate
       when addresses have significantly different initial (head) bit
       sequences, and the address compression in the address block
       construction can be more efficient when addresses full
   message header (message semantics octet is 0) with different
       initial sequences can be compressed separately, gaining more than
       the overhead a hop limit of multiple address blocks.  Separate address blocks
       have 1
   and a lower overhead when either they use different TLVs, or
       when they use multivalue TLVs. hop count of 0.  The simplest heuristic overall message length is to use 50 octets.

   The message contains a single address block, unless addresses may be divided into one
       or more subnets, especially if these are associated message TLV block with
       different MANET interfaces content length 8 octets
   containing two message TLVs, of types VALIDITY_TIME and hence each
   INTERVAL_TIME.  Each uses either LINK_STATUS
       or OTHER_NEIGHB TLVs, but not both.

   2.  Grouping addresses that use a single TLV is straightforward, so with semantics value 4, indicating
   that each TLV type no start and value may be applied to stop indexes are included, and each has a continuous
       sequence value
   length of addresses.  This can be extended to cover 1 octet.  The values included (0x68 and 0x50) are time
   codes representing the case
       where addresses have more than one TLV.  An example default values of how to
       order all TLV combinations so that each TLV type parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds).

   The first address block contains 1 local interface address.  The
   semantics octet value is
       applied to a continuous sequence 2 indicates no address tail, and the head
   length of addresses is given.  (This
       order is not unique.)

       *  Type == LINK_STATUS, Value == LOST.

       *  Type == LINK_STATUS, Value == LOST 4 octets indicates no address mid sections.  This address
   block has no TLVs (TLV block content length 0 octets).

   The second, and Type == OTHER_NEIGHB,
          Value == SYMMETRIC.

       *  Type == OTHER_NEIGHB, Value == SYMMETRIC.

       *  Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
          Value == SYMMETRIC.

       *  Type == LINK_STATUS, Value == HEARD.

       *  Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
          Value == LOST.

       *  Type == OTHER_NEIGHB, Value == LOST.

       *  Type == LINK_STATUS, Value == SYMMETRIC.

       This order is not appropriate when multiple last, address block contains 4 neighbor interface
   addresses.  The semantics octet value TLVs are to be
       used, then it is more important to group all TLVs of 2 indicates no address tail,
   the same
       type together, even when having different values.  A possible
       ordering is

       *  Type == LINK_STATUS, Value == HEARD.

       *  Type == LINK_STATUS, Value == SYMMETRIC.

       *  Type == LINK_STATUS, Value == LOST.

       *  Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
          Value == SYMMETRIC.

       *  Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
          Value == LOST.

       *  Type == LINK_STATUS, Value == LOST and Type == OTHER_NEIGHB,
          Value == SYMMETRIC.

       *  Type == OTHER_NEIGHB, Value == SYMMETRIC.

       *  Type == OTHER_NEIGHB, Value == LOST.

       Where head length of 3 octets indicates address mid sections of one
   octet each.  The following TLV type uses single block (content length 7 octets)
   includes one LINK_STATUS TLV which reports the link status values and of
   all reported neighbors in a single multivalue TLV: the other multiple
       values, appropriate orderings can be devised.

   3.  When there are many first two
   addresses in an are HEARD, the third address block, is SYMMETRIC and the most
       efficient way to add TLVs fourth
   address is as up to five single value TLVs,
       each with a single octet LOST.  The TLV semantics value field.  When there are few
       addresses in an address block, the most efficient way to add TLVs
       is as up to two multiple value TLVs, with one octet of value per
       address each.  It may be appropriate to use one approach for each
       TLV type.  It is relatively straightforward to estimate the cost of each approach (adding TLV type, semantics, length and index
       overheads per TLV, and either one octet per value or per address
       as appropriate) and 20 indicates, in
   addition to select the probably lower cost approach.
       Alternatively a single decision based on the expected number of
       1-hop neighbor addresses may be made.

Appendix B.  HELLO Message Example

   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 that this is 48 octets (it does not
   need padding).

   The message has a message TLV block with content length 8 octets
   containing two message TLVs, of types VALIDITY_TIME and
   INTERVAL_TIME.  Each uses a TLV with semantics value 4, indicating multivalue TLV, that no start and stop
   indexes are included, and each has a since values for all addresses are included.
   The TLV value length of 4 octets indicates one octet per value per
   address.

      0                   1
   octet.  The values included (0x68 and 0x50) represent the default
   values of 6 seconds and                   2 seconds, respectively.

   The first address block contains                   3
      0 1 local interface address, with head
   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.

      0                   1                   2                   3
      0 1 2 3 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 0 0 1 1 0 0 0 1 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 0 0 1 0 0 0| 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|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     |0 0 0 0 0 1 0 0|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |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 0|0 0 0 0 0 0 1 1|             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Mid      |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Mid      |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 1 0 1 0 0|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     HEARD     |     HEARD     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   SYMMETRIC   |     LOST      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix C.  Time TLVs

   This appendix specifies a general time TLV structure for expressing
   either single time values or a set of time values with each value
   associated with a range of distances.  Furthermore, using this
   general time TLV structure, this document specifies the INTERVAL_TIME
   and VALIDITY_TIME TLVs, which are used by NHDP.

C.1.  Representing Time

   This document specifies a TLV structure in which time values are each
   represented in an 8 bit time code, one or more of which may be used
   in a TLV's value field.  Of these 8 bits, the least significant four
   bits represent the mantissa (a), and the most significant four bits
   represent the exponent (b), so that:

   o  time value = (1 + a/16) * 2^b * C

   o  time code = 16 * b + a

   All nodes in the network MUST use the same value of C, which will be
   specified in seconds, hence so will be all time values.  Note that
   ascending values of the time code represent ascending time values,
   time values may thus be compared by comparison of time codes.

   An algorithm for computing the time code representing the smallest
   representable time value not less than the time value t is:

   1.  find the largest integer b such that t/C >= 2^b;

   2.  set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest
       integer;

   3.  if a == 16 then set b = b + 1 and set a = 0;

   4.  if a and b are in the range 0 and 15 then the required time value
       can be represented by the time code 16 * b + a, otherwise it can
       not.

   The minimum time value that can be represented in this manner is C.
   The maximum time value that can be represented in this manner is
   63488 * C.

C.2.  General Time TLV Structure

   A Time TLV may be a packet, message or address block TLV.  If it is a
   packet or message TLV then it must be a single value TLV as defined
   in [1]; if it is an address block TLV then it may be single value or
   multivalue TLV.  The specific Time TLVs specified in this document,
   in Appendix C.3 are message, and hence single value, TLVs.  Note that
   even a single value Time TLV may contain a multiple octet <value>
   field.

   The purpose of a single value Time TLV is to allow a single time
   value to be determined by a node receiving an entity containing the
   Time TLV, based on its distance from the entity's originator.  The
   Time TLV may contain information that allows that time value to be a
   function of distance, and thus different receiving nodes may
   determine different time values.  If a receiving node will not be
   able to determine its distance from the originating node, then the
   form of this Time TLV with a single time code in a <value> field (or
   single value subfield) SHOULD be used.

   The <value> field of a single value Time TLV is specified, using the
   regular expression syntax of [1], by:

       <value> = {<time><distance>}*<time>

   where:

   <time>  is an 8 bit field containing a time code as defined in
      Appendix C.1.

   <distance>  is an 8 bit field specifying a distance from the message
      originator, in hops.

   A single value <value> field thus consists of an odd number of
   octets; with a repetition factor of n in the regular expression
   syntax it contains 2n+1 octets, thus the <length> field of a single
   value Time TLV, which MUST always be present, is given by:

   o  <length> = 2n+1

   A single value <value> field may be thus represented by:

       <t_1><d_1><t_2><d_2> ... <t_i><d_i> ...  <t_n><d_n><t_default>

   <d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence.
   Then, at the receiving node's distance from the originator node, the
   time value indicated is that represented by the time code:

   o  <t_1>, if n > 0 and distance <= <d_1>;

   o  <t_i+1>, if n > 1 and <d_i> < distance <= <d_i+1> for some i such
      that 1 <= i < n;
   o  <t_default> otherwise, i.e. if n == 0 or distance > <d_n>.

   In a multivalue Time TLV, each single value subfield of the
   multivalue Time TLV is defined as above.  Note that [1] requires that
   each single value subfield has the same length (i.e. the same value
   of n) but they need not use the same values of <d_1> to <d_n>.

C.3.  Message TLVs

   Two message TLVs are defined, for signaling message validity time
   (VALIDITY_TIME) and message interval (INTERVAL_TIME).

C.3.1.  VALIDITY_TIME TLV

   A VALIDITY TIME TLV is a message TLV that defines the validity time
   of the information carried in the message in which the TLV is
   contained.  After this time the receiving node MUST consider the
   message content to no longer be valid (unless repeated in a later
   message).  The validity time of a message MAY be specified to depend
   on the distance from its originator.  (This is appropriate if
   messages are sent with different hop limits, so that receiving nodes
   at greater distances receive information less frequently and must
   treat is as valid for longer.)

   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
   Appendix C.1.

C.3.2.  INTERVAL_TIME TLV

   An INTERVAL_TIME TLV is a message TLV that defines the maximum time
   before another message of the same type as this message from the same
   originator should be received.  This interval time MAY be specified
   to depend on the distance from the originator.  (This is appropriate
   if messages are sent with different hop limits, so that receiving
   nodes at greater distances have an increased interval time.)

   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
   Appendix C.1.

Appendix D.  Message Jitter

   Since NHDP employs periodic message transmission in order to detect
   neighborhoods, and since NHDP is a building block for MANET routing
   protocols employing other triggered or periodic message exchanges,
   this appendix presents global concerns pertaining to jittering of
   MANET control traffic.

D.1.  Jitter

   In order to prevent nodes in a MANET from simultaneous transmission,
   whilst retaining the MANET characteristic of maximum node autonomy, a
   randomization of the transmission time of packets by nodes, known as
   jitter, may be employed.  Note that while jitter may resolve the
   problem of simultaneous transmissions, the delays it introduces will
   otherwise only have a negative impact on a well-designed protocol.
   Thus jitter parameters should always be minimized, subject to their
   acceptably achieving their intent.  Three jitter mechanisms, which
   target different aspects of this problem, may be employed, with the
   aim of reducing the likelihood of simultaneous transmission, and, if
   it occurs, preventing it from continuing.

   Three cases exist:

   o  Periodic message generation;

   o  Externally triggered message generation;

   o  Message forwarding.

D.1.1.  Periodic message generation

   When a node generates a message periodically, two successive messages
   will be separated by a well-defined interval, denoted here
   MESSAGE_INTERVAL.  A node may maintain more than one such interval,
   e.g. for different message types or in different circumstances (such
   as backing off transmissions to avoid congestion).  Jitter may be
   applied by reducing this delay by a random amount, so that the delay
   between consecutive transmissions of a messages of the same type is
   equal to (MESSAGE_INTERVAL - jitter), where jitter is the random
   value.

   Subtraction of the random value from the message interval ensures
   that the message interval never exceeds the nominal message interval,
   and does not adversely affect timeouts or other mechanisms which may
   be based on message late arrival or failure to arrive.  Note that by
   basing the message transmission time on the previous transmission
   time, rather than by jittering a fixed clock, nodes can become
   completely desynchronized, which minimizes their probability of
   collisions.

   It is appropriate and convenient for the jitter value to be taken
   from a uniform distribution between zero and a maximum value, denoted
   here MAXJITTER.  MAXJITTER must be significantly less than the
   current value of MESSAGE_INTERVAL.  MAXJITTER may be a single fixed
   parameter (in which case it must be significantly less than all
   values of MESSAGE_INTERVAL) or be based on MESSAGE_INTERVAL (for
   example it may be a fixed proportion of MESSAGE_INTERVAL).

   Note that a node will know its own MESSAGE_INTERVAL value and can
   readily ensure that any MAXJITTER value used is appropriate.

D.1.2.  Externally triggered message generation

   When a node responds to an externally triggered change in
   circumstances which is likely to also affect other nodes by
   generating a message, that message may be jittered by delaying it by
   a random duration.  If this message is of a type which is
   periodically transmitted then it may be appropriate to restart its
   schedule of these messages, this should be based on this delayed
   time.  In some cases there may be a minimum interval between such
   messages, in this case it may be appropriate to jitter that minimum
   interval time.

   The normal delay on a triggered message may be generated uniformly in
   an interval between zero and a maximum delay, denoted here MAXJITTER.
   Selection of MAXJITTER will be protocol specific.  In some cases the
   delay may be fixed, or fixed according to the message type.  In the
   case of a regularly scheduled message, at an interval denoted here
   MESSAGE_INTERVAL, MAXJITTER must be significantly less than
   MESSAGE_INTERVAL.  This may require prior agreement as to the value
   (or minimum value) of MESSAGE_INTERVAL, be by inclusion of
   MESSAGE_INTERVAL (the time until the next relevant message, rather
   than the time since the last) in the message, or use any other
   protocol specific mechanism.

D.1.3.  Message forwarding

   When a node forwards a message it may be jittered by delaying it by a
   random time.  The normal delay on a triggered message may be
   generated uniformly in an interval between zero and a maximum delay,
   denoted here MAXJITTER.  The value of MAXJITTER will be protocol
   specific and may in some cases be fixed, possibly by message type.
   However in the case of a regularly scheduled message, at an interval
   denoted here MESSAGE_INTERVAL, MAXJITTER must be significantly less
   than MESSAGE_INTERVAL.  This may require prior agreement as to the
   value (or minimum value) of MESSAGE_INTERVAL, may be by inclusion in
   the message of MESSAGE_INTERVAL (the time until the next relevant
   message, rather than the time since the last message) or be by any
   other protocol specific mechanism.  The choice of MAXJITTER may also
   take into account the expected number of times that the message may
   be forwarded.

   For several possible reasons (differing parameters, message
   rescheduling, extreme random values) a node may receive a message
   while still waiting to forward an earlier message of the same type
   originating from the same node.  This is possible without jitter, but
   may occur more often with it.  The appropriate action to take is
   protocol specific (typically to discard the earlier message or to
   forward both, possible modifying timing to maintain message order).

   In many cases, including [3] and protocols using the full
   functionality of [1], messages are transmitted hop by hop in
   potentially multi-message packets, and some or all of those messages
   may need to be forwarded.  For efficiency this should be in a single
   packet, and hence the forwarding jitter of all messages received in a
   single packet should be the same.  For this to have the intended
   distribution it is necessary to choose a single random jitter for all
   messages.  It is not appropriate to give each message a random jitter
   and then using the smallest of these jitter values, as that produces
   a jitter with a reduced mean value.

   In addition, the protocol may permit messages received in different
   packets to be combined, possibly also with locally generated messages
   (scheduled or triggered).  However in this case the purpose of the
   jitter will be accomplished by choosing any of the independently
   scheduled times for these events as the single forwarding time; this
   may have to be the earliest time to achieve all constraints.  This is
   because without combining messages, a transmission was due at this
   time anyway.

Appendix E.  Utilizing Link Layer Information

   The interface between NHDP and any protocol(s) using NHDP is through
   the Neighborhood Information Base as defined in Section 5.  The
   message exchange and associated processing specified in Section 7 and
   Section 8 allow fully maintaining this Neighborhood Information Base.

   Different link layers, and even different implementations of the same
   link layer, may make varying amount of information available
   describing local connectivity.  If present, such link layer
   information MAY be used to supplement, or replace, elements of NHDP
   as follows:

   No link layer information  - Absent any link layer information on a
      MANET interface, NHDP MUST be employed for populating all sets of
      the Neighborhood Information Base as defined in this
      specification.

   Failed data delivery  - If link layer information is available on a
      MANET interface, identifying when data delivery to a presumed
      directly connected node has failed, NHDP MUST be employed for
      populating all sets of the Neighborhood Information Base as
      defined in this specification.  The link layer information MAY be
      used to degrade a presumed directly connected node from being
      considered as SYMMETRIC to being considered HEARD or LOST.  A
      HELLO message reflecting these changes MAY be generated,
      respecting the considerations in Section 7.

   Link quality information  - The link layer may make available "soft"
      information (possibly derived from the physical layer) relating to
      the link quality.  NHDP MAY be able to use this information, in a
      normalized form, to adjust the link status between LOST, HEARD     |   SYMMETRIC   |     LOST      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and
      SYMMETRIC.

   Local (1-hop) connectivity  - If link layer information is available
      on a MANET interface, identifying the local (1-hop) connectivity
      via that interface, then this information MAY be used as follows
      when generating HELLO messages over that interface:

      *  Step 1 in Hello Message Generation (Section 7) MAY be ignored.
         This implies that local connectivity verification over that
         MANET interface is not performed by NHDP, but is using the link
         layer information.

      *  All other steps in Hello Message Generation (Section 7) MUST be
         carried out, such that Neighborhood Address Association Sets
         and 2-Hop Neighbor Sets can be populated correctly.

      *  All MANET interfaces which do not have local (1-hop)
         connectivity information available MUST employ the message
         exchange as detailed in this specification.

Appendix C. F.  Security Considerations

   The objective of this protocol is to allow each node in the network
   to acquire information describing its 1-hop and symmetric 2-hop
   neighborhoods.  This is acquired through periodic message exchange between
   neighboring nodes, and the nodes.  The information is made available through a
   collection of sets, describing the node's 1-hop neighborhood and
   symmetric 2-hop neighborhood.

   Under normal circumstances, the information recorded in these sets is
   correct - i.e. corresponds to the actual network topology, apart from
   any changes which have not (yet) been tracked by the HELLO message
   exchanges.

   If some node for some reason, malice or malfunction,
   inject injects invalid
   HELLO messages, incorrect information may be recorded in the sets
   maintained.  The exact consequence of this inexactness depends on the
   use of these sets, and MUST be explicitly reflected in the
   specification of protocols which use information provided by NHDP.

   This appendix, therefore, only outlines the ways in which correctly
   formed, but still invalid, HELLO messages may appear.

Appendix F.1.  Invalid HELLO messages

   A correctly formed, but still invalid, HELLO message may take any of
   the following forms:

   1.

   A node may lie about its own identity:

      *  The Local Interface Block of the HELLO message may contain
         addresses which do not correspond to addresses of MANET
         interfaces of the local node which transmits the HELLO message;

   2.

      *  The Local Interface Block of the HELLO message may omit
         addresses of MANET interfaces of the local node which transmits
         the HELLO message;

   3.

      *  The Local Interface Block may contain OTHER_IF TLVs, indicating
         incorrectly that an address is associated with a MANET
         interface other than the one over which the HELLO message is
         being transmitted;

   4.

      *  The Local Interface Block may omit OTHER_IF TLVs, thereby
         indicating incorrect addresses associated with the MANET
         interface over which the HELLO message is being transmitted;

   5.
   A node may lie about the identity of other nodes:

      *  A present or absent address in an address block, other than in
         the Local Interface Block, does not in and by itself cause a
         problem.  It is the presence, absence or incorrectness of
         associated LINK_STATUS and OTHER_NEIGHB TLVs that cause
         problems;

   6.

      *  A present LINK_STATUS TLV may, incorrectly, identify an address
         as being of a node which is or was in the sending node's 1-hop
         neighborhood;

   7.

      *  A consistently absent LINK_STATUS TLV may, incorrectly, fail to
         identify an address as being of a node which is or was in the
         sending node's 1-hop neighborhood;

   8.

      *  A present OTHER_NEIGHB TLV may, incorrectly, identify an
         address as being of a node which is or was in the sending
         node's symmetric 1-hop neighborhood;

   9.

      *  A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail
         to identify an address as being of a node which is or was in
         the sending node's symmetric 1-hop neighborhood;

   10.

      *  The value of a LINK_STATUS or OTHER_NEIGHB TLV may incorrectly
         indicate the status (LOST, SYMMETRIC, HEARD) of a 1-hop
         neighbor.

Appendix D. G.  Flow and Congestion Control

   This document specifies one message type, the HELLO messages. message.  The
   size of each complete HELLO message is proportional to the size of
   the
   transmitting originating node's 1-hop neighborhood (this neighborhood; some or all of this
   information may be sent
   distributed across multiple interfaces). on each of the node's MANET interfaces.  HELLO messages
   MUST NOT be forwarded.

   A node MUST report its 1-hop neighborhood in HELLO messages on each
   of its MANET interfaces at least each REFRESH_INTERVAL.  Thus, this
   puts a lower bound on the control traffic, which traffic generated by each node in
   the network employing this neighborhood discovery protocol in the network generates. protocol.

   A node MUST ensure that two successive HELLO messages sent on the
   same MANET interface are separated by at least HELLO_MIN_INTERVAL.
   Thus, this puts an upper bound on the control traffic, which each
   node employing
   (If using jitter then this neighborhood discovery protocol in the network
   generates.

   In order for the protocol may be reduced to function, a mean minimum value of
   HELLO_MIN_INTERVAL - HP_MAXJITTER/2.)  Thus, this puts an upper bound
   on the control traffic generated by each node in the network MUST
   employ the HELLO signaling as described in
   employing this specification. neighborhood discovery protocol.

Appendix E. H.  Contributors

   This specification is the result of the joint efforts of the
   following contributors -- listed alphabetically.

   o  Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>

   o  Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>

   o  Emmanuel Baccelli, Hitachi Labs Europe, France,
      <Emmanuel.Baccelli@inria.fr>

   o  Thomas Heide Clausen, PCRI, France, <T.Clausen@computer.org>

   o  Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>

   o  Christopher Dearlove, BAE Systems, UK,
      <Chris.Dearlove@baesystems.com>

   o  Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>

Appendix F. I.  Acknowledgements

   The authors would like to acknowledge the team behind OLSRv1,
   specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent
   Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced
   Research in Engineering, Pakistan) for their contributions.

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews and comments on the
   specification and its components: Joe Macker (NRL), Alan Cullen (BAE
   Systems), Song-Yean Cho (Samsung Software Center) and the entire IETF MANET working group.

Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/

   Christopher M. Dearlove
   BAE Systems Advanced Technology Centre

   Phone: +44 1245 242194
   Email: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/ocs/sharedservices/atc/

   Justin W. Dean
   Naval Research Laboratory

   Phone: +1 202 767 3397
   Email: jdean@itd.nrl.navy.mil
   URI:   http://pf.itd.nrl.navy.mil/

   The OLSRv2 Design Team
   MANET Working Group

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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 Statement

   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.

Disclaimer of Validity

   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.

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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).