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

              MANET Neighborhood Discovery Protocol (NHDP)
                        draft-ietf-manet-nhdp-02
                        draft-ietf-manet-nhdp-03

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 August 5, December 1, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a 1-hop and symmetric 2-hop neighborhood
   discovery protocol (NHDP) for mobile ad hoc networks (MANETs).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  6  7
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  7  8
     4.1.  HELLO Message Generation  Nodes and Interfaces . . . . . . . . . . . . . . . . .  7
     4.2.  HELLO message content . .  8
     4.2.  Information Base Overview  . . . . . . . . . . . . . . . .  8  9
     4.3.  Node Behavior  Signaling Overview . . . . . . . . . . . . . . . . . . . . 10
       4.3.1.  HELLO Message Generation . .  8
   5.  Local Information Base . . . . . . . . . . . . . 10
       4.3.2.  HELLO Message Content  . . . . . . . 10
     5.1.  Local Interface Set . . . . . . . . . 11
   5.  Protocol Parameters and Constants  . . . . . . . . . . 10
   6.  Neighborhood Information Base . . . . 12
     5.1.  Interface Parameters . . . . . . . . . . . . 11
     6.1.  Link Set . . . . . . . 12
       5.1.1.  Message Intervals  . . . . . . . . . . . . . . . . . . 11
     6.2.  Symmetric Neighbor Set 12
       5.1.2.  Information Validity Times . . . . . . . . . . . . . . 13
       5.1.3.  Link Quality . . . . 12
     6.3.  Neighborhood Address Association Set . . . . . . . . . . . 13
     6.4.  2-Hop Neighbor Set . . . . . . 14
       5.1.4.  Jitter . . . . . . . . . . . . . . 13
   7.  Packets and Messages . . . . . . . . . . 14
     5.2.  Node Parameters  . . . . . . . . . . . . 15
     7.1.  HELLO Messages . . . . . . . . . 15
       5.2.1.  Information Validity Time  . . . . . . . . . . . . . . 15
       7.1.1.  Local Interface Block
     5.3.  Parameter Change Constraints . . . . . . . . . . . . . . . 15
     5.4.  Constants  . . . . . . 16
       7.1.2.  Address Block TLVs . . . . . . . . . . . . . . . . . . 16
   8.
   6.  Local Information Base Changes . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Adding a MANET
     6.1.  Local Interface Set  . . . . . . . . . . . . . . . . . . . 17
     8.2.  Removing a MANET
   7.  Interface Information Base . . . . . . . . . . . . . . . . 17
     8.3.  Adding an Address to a MANET Interface . . 18
     7.1.  Link Set . . . . . . . . 18
     8.4.  Removing an Address from a MANET Interface . . . . . . . . 18
     8.5.  Changing the Principal Address of a MANET Interface . . . 18
   9.  HELLO Message Generation . . . . . . 18
     7.2.  2-Hop  Set . . . . . . . . . . . . . 19
     9.1.  HELLO Message: Transmission . . . . . . . . . . . 19
   8.  Node Information Base  . . . . 20
       9.1.1.  HELLO Message: Jitter . . . . . . . . . . . . . . . . 21
   10. HELLO Message Processing 20
     8.1.  Neighbor Set . . . . . . . . . . . . . . . . . . . 22
     10.1. Populating the Link . . . . 20
     8.2.  Lost Neighbor Set  . . . . . . . . . . . . . . . . . 22
     10.2. Populating the Symmetric Neighbor Set . . . 20
   9.  Local Information Base Changes . . . . . . . 23
     10.3. Populating the Neighborhood Address Association Set . . . 24
     10.4. Populating the 2-Hop Neighbor Set . . . . . . 21
     9.1.  Adding an Interface  . . . . . . 25
     10.5. Neighborhood Changes . . . . . . . . . . . . . 21
     9.2.  Removing an Interface  . . . . . . 26
   11. Link Hysteresis . . . . . . . . . . . . 21
     9.3.  Adding an Address to an Interface  . . . . . . . . . . . 27
     11.1. Link Quality . 22
     9.4.  Removing an Address from an Interface  . . . . . . . . . . 22
   10. Packets and Messages . . . . . . . . . . . . 28
   12. Proposed Values for Constants  . . . . . . . . . . 23
     10.1. HELLO Messages . . . . . . 29
     12.1. Message Intervals . . . . . . . . . . . . . . . . 23
       10.1.1. Local Interface Block  . . . . 29
     12.2. Holding Times . . . . . . . . . . . . 23
       10.1.2. Neighbor Address Blocks  . . . . . . . . . . 29
     12.3. Hysteresis values . . . . . 24
   11. HELLO Message Generation . . . . . . . . . . . . . . . 29
     12.4. Jitter Times . . . . 26
     11.1. HELLO Message Specification  . . . . . . . . . . . . . . . 26
     11.2. HELLO Message Transmission . . . . 30
     12.5. Time . . . . . . . . . . . . 27
       11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . 30
   13. IANA Considerations . . 27
   12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 31
     13.1. Multicast Addresses 29
     12.1. Updating the Neighbor Set  . . . . . . . . . . . . . . . . 29
     12.2. Updating the Lost Neighbor Set . . . 31
     13.2. Message Types . . . . . . . . . . . 31
     12.3. Updating the Link Set  . . . . . . . . . . . 31
     13.3. TLV Types . . . . . . . 31
     12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . 31
     13.4. LINK_STATUS and OTHER_NEIGHB Values . 32
   13. Other Information Base Changes . . . . . . . . . . 32
   14. References . . . . . . 34
     13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 34
     13.2. Link Tuple Symmetric . . . 33
     14.1. Normative References . . . . . . . . . . . . . . . . 35
     13.3. Link Tuple Heard Timeout . . . 33
     14.2. Informative References . . . . . . . . . . . . . . 36
   14. Link Quality . . . . 33
   Appendix A.   Address Block TLV Combinations . . . . . . . . . . . 34
   Appendix B.   HELLO Message Example . . . . . . . . . . 37
     14.1. Deployment Without Link Quality  . . . . . 35
   Appendix C.   Time TLVs . . . . . . . . 37
     14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 37
     C.1.  Representing Time  .
     14.3. When Link Quality Changes  . . . . . . . . . . . . . . . . 38
     14.4. Updating Link Quality  . . . 37
     C.2.  General Time TLV Structure . . . . . . . . . . . . . . . 39
   15. Proposed Values for Parameters and Constants . 37
     C.3.  Message TLVs . . . . . . . . 40
     15.1. Message Interval Interface Parameters  . . . . . . . . . . 40
     15.2. Information Validity Time Interface Parameters . . . . . 39
       C.3.1.  VALIDITY_TIME TLV . 40
     15.3. Information Validity Time Node Parameters  . . . . . . . . 40
     15.4. Link Quality Interface Parameters  . . . . . . . . . 39
       C.3.2.  INTERVAL_TIME TLV . . . 40
     15.5. Jitter Interface Parameters  . . . . . . . . . . . . . . . 39
   Appendix D.   Message Jitter 40
     15.6. Constants  . . . . . . . . . . . . . . . . . . . 40
     D.1.  Jitter . . . . . 40
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 40
       D.1.1.  Periodic message generation 41
     16.1. Message Types  . . . . . . . . . . . . . 40
       D.1.2.  Externally triggered message generation . . . . . . . 41
       D.1.3.  Message forwarding . . 41
     16.2. TLV Types  . . . . . . . . . . . . . . . . 42
       D.1.4.  Maximum Jitter Determination . . . . . . . . 41
     16.3. LINK_STATUS and OTHER_NEIGHB Values  . . . . . 43
   Appendix E.   Utilizing Link Layer Information . . . . . . 41
   17. References . . . . 44
   Appendix F.   Security Considerations . . . . . . . . . . . . . . 46
   Appendix F.1. Invalid HELLO messages . . . . . . . . 43
     17.1. Normative References . . . . . . . 46
   Appendix G.   Flow and Congestion Control . . . . . . . . . . . . 48 43
     17.2. Informative References . . . . . . . . . . . . . . . . . . 43
   Appendix H.   Contributors A.   Address Block TLV Combinations . . . . . . . . . . . 44
   Appendix B.   HELLO Message Example  . . . . . . . . . . . . . . . 45
   Appendix C.   Constraints  . . . . . . . . . . . . . . . . . . . . 47
   Appendix D.   Security Considerations  . . . . . . . . . . . . . . 49
   Appendix D.1. Invalid HELLO messages . . . . . . . . . . . . . . . 49
   Appendix I. E.   Flow and Congestion Control  . . . . . . . . . . . . 51
   Appendix F.   Contributors . . . . . . . . . . . . . . . . . . . . 52
   Appendix G.   Acknowledgements . . . . . . . . . . . . . . . . . . 50 53
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 54
   Intellectual Property and Copyright Statements . . . . . . . . . . 52 55

1.  Introduction

   This document describes a neighborhood discovery protocol (NHDP) for
   a mobile ad hoc network (MANET).  The (MANET) [7].  This protocol uses an exchange
   of HELLO messages in order that each node can determine the presence
   and status of its 1-hop and symmetric 2-hop neighborhoods. neighbors.  This protocol
   is designed to maintain this information in the presence of a dynamic
   network topology.

   The information maintained by this protocol may be used by other
   protocols, such as MANET routing protocols, for determining local
   connectivity and node configuration.

   This specification describes both this the HELLO message exchange, the
   messages being defined as instances of the specification [1], and the
   information storage required for neighborhood discovery.

   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.

   This protocol is based on the neighborhood discovery process
   contained in the Optimized Link State Routing Protocol (OLSR) [3]. [6].

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]. [5].

   The terms "packet", "message", "address", "address block", "TLV", and
   "TLV block" in this document 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

   Interface  - A network device device, configured and assigned one or more IP
      addresses.

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

   Heard  - A MANET interface of node X is considered heard on a MANET
      interface of a node Y if the latter can receive traffic from the
      former.

   Link  - A pair of MANET interfaces from two different nodes, where at
      least one interface is able to receive traffic from heard by the other.

   Symmetric link  - A link where both MANET interfaces are able to
      receive traffic from heard by the
      other.

   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 of node X to is heard by a MANET interface on of node Y). Y.

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

   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 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 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.)

   Constant  - A constant is a numerical value which MUST be the same
      for all MANET interfaces of all nodes in the MANET, at all times.

   Interface parameter  - An interface parameter is a boolean or
      numerical value, specified separately for each MANET interface of
      each node.  A node MAY change interface parameter values at any
      time, subject to some constraints.

   Node parameter  - A node parameter is a boolean or numerical value,
      specified for each node.  A node MAY change node parameter values
      at any time, subject to some constraints.

3.  Applicability Statement

   This neighborhood discovery protocol supports nodes which each have
   one or more interfaces participating in the MANET. MANET [7].  It provides
   each node with local topology information up to two hops away.  This
   information is made available to other protocols through Interface
   Information Bases and a
   Neighborhood Node Information Base, described in Section 6. 7
   and Section 8.

   The protocol is designed to work in networks with a dynamic topology,
   and where messages may be lost, such as due to collisions in wireless
   networks.  If relevant link layer information is available then it
   may be used by this protocol.

   This protocol is designed to works work in a completely distributed manner manner,
   and does not depend on any central entity.  It does not require any
   changes to the format of IP packets, thus any existing IP protocol
   stack can be used as is.  It can use the link local multicast address
   and MANET UDP port specified in [2].

   This protocol uses the packet and message formats specified in [1].
   HELLO messages specified by this protocol may be extended using the
   TLV mechanisms described in [1].  For example, if multipoint relays
   (MPRs) are to be calculated similarly to as in OLSR [3] [6] 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 that also use [1].

4.  Protocol Overview and Functioning

   This protocol specifies local (one hop) signaling that:

   o  advertises  Advertises the presence of a node and its MANET interfaces; interfaces.

   o  discovers  Discovers links to from adjacent nodes; nodes.

   o  performs  Performs bidirectionality checks on the discovered links; links.

   o  advertises  Advertises discovered links links, and whether each is symmetric symmetric, to its
      1-hop neighbors neighbors, and hence discover discovers symmetric 2-hop neighbors; neighbors.

   o  maintains an  Maintains information base bases describing discovered links and links, their
      MANET interface addresses and status, 1-hop neighbors current and their MANET interfaces,
      symmetric former 1-hop neighbors
      neighbors, and symmetric 2-hop neighbors.

   Signaling consists of a single type of message, known as a HELLO
   message.  A HELLO message identifies its originator node and that
   node's MANET interfaces

4.1.  Nodes and addresses.  As Interfaces

   In order for a node receives HELLO
   messages and populates its information base, to participate in a list MANET, it MUST have at least
   one, possibly more, MANET interfaces.  Each MANET interface:

   o  Is characterized by a set of 1-hop
   neighbors' interface parameters, defining the
      behavior of this interface.  Each MANET interface addresses MAY be
      individually parameterized to accommodate the characteristics
      experienced and their link status (lost,
   symmetric or heard) is included in subsequent HELLO messages.  Thus, the periodic transmission allows nodes behavior desired on that interface.

   o  Has an Interface Information Base, recording information regarding
      links to continuously track changes
   in their 1-hop this MANET interface and symmetric 2-hop neighborhoods.  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 MAY be sent:

   o  Proactively, at a regular interval, known as HELLO_INTERVAL.
      HELLO_INTERVAL may be fixed, as suggested in Section 12, or may be
      dynamic.  For example HELLO_INTERVAL may be backed off due to
      congestion or network stability.  Note that if HELLO_INTERVAL is
      dynamic, it is interpreted as the interval within neighbors which the next
      HELLO message will
      can be sent on the same reached through such links.  Each MANET interface. interface has its
      own Interface Information Base.

   o  As a response  Generates and processes HELLO messages, according to a change in the node itself, or its neighborhood, interface
      parameters for example on first becoming active or in response to a new,
      broken or changed status link.

   o that interface.

   In addition to a combination of these proactive and responsive mechanisms.

   Jittering set of HELLO message generation and transmission, MANET interfaces as described
   in Section 9.1, MAY be used if appropriate.

   HELLO messages are sent independently on above, 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:
   node has:

   o  A HELLO message MUST contain all Local Information Base, containing the IP addresses of its own local interface
      information. the
      interfaces of this node.

   o  Within every time interval  A Node Information Base, recording information regarding current
      and recently lost symmetric 1-hop neighbors of length REFRESH_INTERVAL, HELLO
      messages sent over a this node.

   A node may have both MANET interface MUST include all interfaces and non-MANET interfaces.
   Interfaces of the
      information appropriate to that interface both of these types are recorded 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 message TLV that
      indicates the length of time for node's Local
   Information Base, which the message content is to
      be considered valid and included in used, but not updated, by the receiving node's
      Neighborhood signaling of
   this protocol.

4.2.  Information Base. Base Overview

   Each node maintains a Local Information Base, which contains:

   o  A HELLO message SHOULD include an INTERVAL_TIME message TLV that
      indicates  The Local Interface Set, which consists of Local Interface Tuples,
      each of which records the current value addresses of HELLO_INTERVAL.

4.3.  Node Behavior

   A an interface of the node.

   Each node MUST: maintains, for each of its MANET interfaces, an Interface
   Information Base, which contains:

   o  Respect  A Link Set, which consists of Link Tuples, each of which records
      information about a minimum interval, HELLO_MIN_INTERVAL, between successive
      HELLO message transmissions over current or recently lost link from a given interface.  If jitter is
      used then MANET
      interface of a 1-hop neighbor to this interval MAY be reduced, but only by MANET interface.  A Link
      Tuple for a random value
      not exceeding HP_MAXJITTER.

   o  Ensure that if HELLO_INTERVAL and other parameters are lost link is maintained
      dynamically, changes do not invalidate the guarantees for purposes of
      Section 9.1.

   o  Maintain, based on received advertisement
      in HELLO messages, estimates of its 1-hop messages and symmetric 2-hop neighborhoods as this protocol operates.
      Formally defined in Section 6, this can be summarized as
      consisting hence accelerated removal of this link from
      the following sets:

      Link Set  - Records the status relevant 1-hop neighbors' Link Sets.  Link quality
      information, if used and available, may be recorded in a Link
      Tuple; if this indicates that a link is of all links from too low quality to be
      currently useable, then that link is also treated as lost.

   o  A 2-Hop Set, which consists of 2-Hop Tuples, each of which records
      a MANET interface of a symmetric 1-hop neighbor, and an address of
      a symmetric 2-hop neighbor of this node.  The former MANET
      interface must have a symmetric link to current this interface, and the
      former node must be a symmetric 1-hop neighbors.

      Symmetric Neighbor neighbor of the latter node.
      The 2-Hop Set  - Records is updated by the status signaling of current and former
         symmetric this protocol, but is
      not itself reported in that signaling.

   Each node maintains a Node Information Base, which contains:

   o  The Neighbor Set, which consists of Neighbor Tuples, each of which
      records all interface addresses of a 1-hop neighbors.  If any neighbor.  There MUST
      be a current link from a MANET interface of these nodes have more
         than one this 1-hop neighbor to
      a MANET interface then of this set may record addresses
         that node, although this link MAY be
      currently considered as lost due to insufficient link quality.
      Neighbor Tuples are not maintained in the Link Set.

      Neighborhood Address Association Neighbor Set  - Allows as long as
      there are corresponding current Link Tuples in the Link Set. A
      Neighbor Tuple allows all addresses of
         the MANET all interfaces of each a 1-hop neighbor
      neighbors to be associated with each other.

      2-Hop Neighbor Set  - Records the other, including addresses of the MANET
      interfaces of symmetric 2-hop neighbors.

      The information not represented in the Link Set and Symmetric Set. Neighbor Set MUST Tuples allow
      all addresses of interfaces of symmetric 1-hop neighbors to be
      maintained
      included in order for a node to correctly generate HELLO
      messages.

5.  Local Information Base

   A node maintains a Local Information Base that records information
   about its MANET interfaces.  Each messages on all MANET interface MUST have at least
   one address, and MAY have more than one address.  All addresses have
   an associated prefix length, interfaces of this node.

   o  The Lost Neighbor Set, which is included all addresses in the
   Local Information Base.  If consists of Lost Neighbor Tuples,
      each of which records an address otherwise does not have of an interface of a
   prefix length it is set equal to the address length.  Two recently
      lost symmetric 1-hop neighbor.  Lost Neighbor Tuples allow
      advertising such addresses
   are considered equal if and only if their associated prefix lengths
   are also equal.

   One of the as lost, in order that these addresses of each MANET interface is denoted
      can be removed from other nodes' 2-Hop Sets.

   These sets are used for describing the principal
   address protocol in this document.  An
   implementation of that interface.  A node this protocol MAY choose which address is maintain this information in the
   principal address
   indicated form, or in any manner; it SHOULD choose the address so as other organization which offers access to minimize changes of principal address.  The selection of an
   address as
   this information.

   This protocol contains a principal address only affects how the node organizes
   its information storage, it has no effect on signaling mechanism for maintaining the messages it creates
   Interface Information Bases and sends.

   The Local the Node Information Base Base.  If
   information from the link layer, or any other source, is not modified by this protocol.  This
   protocol available
   and appropriate, it may respond be used to changes of this Local Information Base which
   MUST reflect corresponding changes in the node's status.

5.1.  Local Interface Set

   A node's Local Interface Set records its local update these.  Such updates are
   subject to the constraints specified in Appendix C.

   Some links in a MANET interfaces.  It
   consists may be marginal, e.g. due to adverse wireless
   propagation.  In order to avoid using such marginal links, a link
   quality is associated with each link in the Link Set, and links with
   insufficient link quality are considered lost.  Modifying the link
   quality of Local Interface Tuples, one per MANET interface:

      (I_local_iface_addr_list)

   where:

   I_local_iface_addr_list a link is OPTIONAL.  If link quality is not to be modified
   it MUST be set to indicate an always usable quality link.  Link
   quality information is only used locally, it is not used in
   signaling, and nodes may interoperate whether they are using the
   same, different, or no, link quality information.

4.3.  Signaling Overview

   Signaling consists of a list single type of the addresses message, known as a HELLO
   message.  Each node generates HELLO messages for each of this its MANET
   interfaces.  Each HELLO message identifies that MANET interface, with and
   reports the first other interfaces of the listed addresses being considered
      as node.  Each HELLO message
   includes information from the principal address Link Set of the interface.

6.  Neighborhood Information Base

   A node maintains a Neighborhood Information Base that records
   information about its 1-hop and symmetric 2-hop neighborhoods.  The
   Neighborhood Interface Information
   Base includes the Link Set, the Symmetric
   Neighbor Set, of the Neighborhood Address Association Set MANET interface, and from the 2-Hop
   Neighbor Set.

   A node, X, can be present in both the 1-hop and symmetric 2-hop
   neighborhoods Node Information Base of another node, Y, concurrently.  This allows node X
   to be immediately considered as a symmetric 2-hop neighbor
   the node.

4.3.1.  HELLO Message Generation

   HELLO messages are generated by a node Y
   if the link between them fails.

   All addresses MUST have an associated prefix length, which is
   included in all addresses in the Neighborhood Information Base.
   Prefix lengths are indicated for each of its MANET
   interfaces, and MAY be sent:

   o  Proactively, at a regular interval, known as HELLO_INTERVAL.
      HELLO_INTERVAL may be fixed, or may be dynamic.  For example
      HELLO_INTERVAL may be backed off due to congestion or network
      stability.

   o  As a response to a change in HELLO messages using the
   PREFIX_LENGTH TLV specified in [1]; if an address has no such TLV,
   then node itself, or its prefix length is equal 1-hop
      neighborhood, for example on first becoming active or in response
      to the address length.  Two addresses
   are considered equal if a new, broken, or changed status link.

   o  In a combination of these proactive and only responsive mechanisms.

   Jittering of HELLO message generation and transmission, as described
   in Section 11.2, MAY be used if their associated prefix lengths appropriate.

   HELLO messages are also equal.

6.1.  Link Set

   A node's Link Set records its 1-hop neighborhood.  It consists generated independently on each MANET interface of
   Link Tuples:

      (L_local_iface_addr, L_neighbor_iface_addr_list, L_SYM_time,
       L_ASYM_time, L_LOST_time, L_quality, L_pending, L_lost, L_time)

   where:

   L_local_iface_addr  is
   a node.  HELLO messages MAY be scheduled independently for each MANET
   interface, or, interface parameters permitting, using the principal address same
   schedule for all MANET interfaces of the local a node.

4.3.2.  HELLO Message Content

   Each HELLO message sent over a MANET interface on which need not contain all
   of the 1-hop neighbor is or was heard;

   L_neighbor_iface_addr_list  is a list information appropriate to that MANET interface, however:

   o  A HELLO message MUST contain all of the addresses of in the MANET
      interface Local
      Interface Set of the 1-hop neighbor;

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

   L_ASYM_time  is the MANET interface belongs.

   o  Within every time until which interval of length REFRESH_INTERVAL, the HELLO
      messages sent on each MANET interface of a node must collectively
      include:

      *  All of the 1-hop
      neighbor is considered heard;

   L_LOST_time  is information in the time until which Link Set of the Interface
         Information Base of that MANET interface (other than link
         quality and information relating to pending links).

      *  All of the 1-hop
      neighbor is considered lost; if L_lost is true and L_LOST_time is
      expired, then this Tuple information in the Node Information Base of that
         node.

      This applies to otherwise purely responsive nodes as well as
      proactive nodes.  In either case it means that all information
      appropriate to that MANET interface will have always been
      transmitted, in one or more HELLO messages, since the time
      REFRESH_INTERVAL ago.

   o  A HELLO message MUST be removed;
   L_quality  is include a dimensionless number between 0 (included) and 1
      (included) describing VALIDITY_TIME message TLV that
      indicates the quality length of a link;

   L_pending  is a boolean flag, describing if a link is considered
      pending (i.e. a candidate, but not yet established, link);

   L_lost  is a boolean flag, describing if a link time for which the message content is considered lost
      due to link quality and hysteresis;

   L_time  specifies when this Tuple expires and MUST
      be removed.

   The status considered valid, and included in the receiving node's
      Interface Information Base.

   o  A periodically generated HELLO message SHOULD include an
      INTERVAL_TIME message TLV that indicates the current value of
      HELLO_INTERVAL for that MANET interface, i.e. the link as obtained through simple period within
      which a further HELLO message exchange,
   denoted H_STATUS, can is guaranteed to be derived based sent on the elements L_SYM_time that
      MANET interface.

5.  Protocol Parameters and
   L_ASYM_time as defined in Table 1.

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

                                  Table 1 Constants

   The status of the link, taking link quality parameters and hysteresis constants used in this specification are described
   in this section.

5.1.  Interface Parameters

   The interface parameters used by this specification may be classified
   into
   account, denoted L_STATUS, is defined by:

   1.  if L_pending is true, then L_STATUS = PENDING;

   2.  otherwise, if L_lost is true, then L_STATUS = LOST;

   3.  otherwise, if L_LOST_time is not expired, then L_STATUS = LOST;

   4.  otherwise, L_STATUS = H_STATUS.

6.2.  Symmetric Neighbor Set

   A node's Symmetric Neighbor Set records its symmetric 1-hop
   neighborhood.  It consists of Symmetric Neighbor Tuples:

      (N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time)

   where:

   N_local_iface_addr  is the principal address of following four categories:

   o  Message intervals

   o  Information validity times

   o  Link quality

   o  Jitter

   These are detailed in the local following sections.

   Different MANET interfaces (on the same or on different nodes) MAY
   employ different interface parameter values, and may change their
   interface parameter values dynamically, subject to which the 1-hop neighbor has or had a symmetric link;

   N_neighbor_iface_addr constraints
   given in this section.  A particular case is an address of where all MANET
   interfaces on all MANET nodes within a given MANET interface employ the same
   set of interface parameter values.

5.1.1.  Message Intervals

   The following interface parameters regulate HELLO message
   transmissions over a given MANET interface.

   HELLO messages serve two principal functions:

   o  To advertise this nodes own addresses to its 1-hop
      neighbor which neighbors.  The
      frequency of these advertisements is or was a symmetric 1-hop neighbor of this node;

   N_SYM_time  is the time until which regulated by the 1-hop neighbor is considered
      to be a symmetric 1-hop neighbor;

   N_time  specifies when this Tuple expires interface
      parameters HELLO_INTERVAL and MUST be removed.

   The status HELLO_MIN_INTERVAL.

   o  To advertise this nodes knowledge of the 1-hop neighbor, denoted N_STATUS, can be derived
   based on the field N_SYM_time as defined in Table 2.

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

                                  Table 2

6.3.  Neighborhood Address Association Set

   A node's Neighborhood Address Association Set records the MANET
   interface configuration each of its 1-hop neighbors.  It consists
      The frequency of
   Neighborhood Address Association Tuples:

      (NA_neighbor_iface_addr_list, NA_time)

   where:

   NA_neighbor_iface_addr_list  is a list the advertisement of each such neighbor is
      regulated by the interface addresses parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - is the maximum time between the transmission of a
      1-hop neighbor;

   NA_time  specifies when two
      successive HELLO messages on this Tuple expires and MUST MANET interface.  If using
      periodic transmission of HELLO messages, these SHOULD be removed.

6.4.  2-Hop Neighbor Set

   A node's 2-Hop Neighbor Set records its symmetric 2-hop neighborhood.
   It consists at a
      separation of 2-Hop Neighbor Tuples:

      (N2_local_iface_addr, N2_neighbor_iface_addr_list,
       N2_2hop_iface_addr, N2_time)

   where:

   N2_local_iface_addr HELLO_INTERVAL, possibly modified by jitter as
      specified in [4].

   HELLO_MIN_INTERVAL  - is the principal address minimum interval between transmission of the local MANET
      interface
      two successive HELLO messages, on which this information was received;

   N2_neighbor_iface_addr_list MANET interface.  (This
      minimum interval MAY be modified by jitter, as defined in [4].)

   REFRESH_INTERVAL  - is a list of the addresses of the MANET
      interface maximum interval between advertisements in
      a HELLO message of the each 1-hop neighbor from which this information was
      received;

   N2_2hop_iface_addr  is an address and its status.  In
      all intervals of length REFRESH_INTERVAL, a MANET interface of a symmetric
      2-hop neighbor which has a symmetric link (using any MANET
      interface) to the indicated symmetric node MUST include all
      1-hop neighbor;

   N2_time  specifies the time at neighbor information which this Tuple expires and MUST be
      removed.

7.  Packets and Messages

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

   o  this protocol specifies at
      least one message type, the HELLO message;

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

   The following constraints apply to these interface parameters:

   o  HELLO messages MUST NOT be forwarded;  HELLO_INTERVAL > 0

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

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

7.1.  HELLO Messages

   A HELLO message MUST contain:  HELLO_INTERVAL >= HELLO_MIN_INTERVAL

   o  A VALIDITY_TIME message TLV  REFRESH_INTERVAL >= HELLO_INTERVAL

   o  If INTERVAL_TIME TLVs as specified defined in Appendix C,
      representing time value (at distance one hop) H_HOLD_TIME, which [3] are included in HELLO
      messages, then HELLO_INTERVAL MUST NOT be less than REFRESH_INTERVAL. representable as described
      in [3].

   If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its
   neighbor advertisements between HELLO messages may be
      lost then H_HOLD_TIME in any manner, subject
   to the constraints above.

   For a node to employ this protocol in a purely responsive manner on a
   MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
   set to a multiple of REFRESH_INTERVAL.

   o  An address block, and associated TLV block, known as the Local
      Interface Block, as specified in Section 7.1.1.

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

   o  An INTERVAL_TIME message TLV as specified always
   expected in Appendix C,
      representing a shorter period than this.

5.1.2.  Information Validity Times

   The following interface parameters manage the validity time value (at distance one hop) HELLO_INTERVAL.

   A HELLO message MAY contain:

   o  One or more address blocks, with associated address block TLVs,
      containing current or of link
   information:

   L_HOLD_TIME  - is the period of advertisement, on this MANET
      interface, of former 1-hop neighbors' MANET interface
      addresses.  Other addresses (i.e. neighbor addresses of non-neighbor nodes)
      MAY be included as lost in these address blocks, but MUST NOT be
      associated with any HELLO
      messages, allowing recipients of the TLVs specified in Section 7.1.2.

   o  Other message TLVs.

7.1.1.  Local Interface Block

   The first address block, plus following TLV block, in a these HELLO message messages to
      accelerate removal of information from their Link Sets.
      L_HOLD_TIME can be set to zero if accelerated information removal
      is known not required.

   H_HOLD_TIME  - is used as the Local Interface Block.  The Local Interface Block is
   not distinguished value in any way other than by being the first address
   block VALIDITY_TIME TLV included
      in the message.

   The Local Interface Block MUST contain all of the addresses of all of
   the HELLO messages on this MANET interfaces of the originating node (i.e. all addresses
   appearing in an I_local_iface_addr_list).  Those addresses, if any,
   which correspond interface.

   The following constraints apply to MANET interfaces other than that on which the these interface parameters:

   o  L_HOLD_TIME >= 0

   o  H_HOLD_TIME >= REFRESH_INTERVAL

   o  If HELLO message is transmitted messages can be lost then both SHOULD be significantly
      greater than REFRESH_INTERVAL.

   o  H_HOLD_TIME MUST be associated with a corresponding
   TLV with Type == OTHER_IF representable as specified described in Section 7.1.2, addresses of
   the MANET [3].

5.1.3.  Link Quality

   The following interface on which parameters manage the HELLO message usage of link quality:

   HYST_ACCEPT  - is transmitted MUST
   NOT be associated with such the link quality threshold at or above which a TLV.  Other addresses (i.e. link
      becomes usable, if it was not of any
   MANET interface of this node) already so.

   HYST_REJECT  - is the link quality threshold below which are local a link
      becomes unusable, if it was not already so.

   INITIAL_QUALITY  - is the initial quality of a newly identified link.

   INITIAL_PENDING  - if true, then a newly identified link is
      considered pending, and is not usable until the link quality has
      reached or exceeded the HYST_ACCEPT threshold.

   The following constraints apply to this node only may
   be included these interface parameters:

   o  0 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  0 <= INITIAL_QUALITY <= 1.

   o  If link quality is not updated, then INITIAL_QUALITY >=
      HYST_ACCEPT.

   o  If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false.

   o  If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true.

5.1.4.  Jitter

   If jitter, as defined in [4], is used then these parameters are as
   follows:

   HP_MAXJITTER  - represents the Local Interface Block, they MUST be included value of MAXJITTER used in [4] for
      periodically generated HELLO messages transmitted on all MANET interfaces, and MUST always
   be associated with a TLV with Type == OTHER_IF.

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

7.1.2.  Address Block TLVs

   The three address block TLVs interface.

   HT_MAXJITTER  - represents the value of MAXJITTER used in [4] for
      externally triggered HELLO messages are specified in
   Table 3.

   +----------------+------+-------------------+-----------------------+
   |      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 on this MANET interface.

   For constraints on these interface parameters see [4].

5.2.  Node Parameters

   Only one node parameter is defined by this specification, in the
   category of LOST or        |
   |                |      |                   | SYMMETRIC             |
   +----------------+------+-------------------+-----------------------+

                                  Table 3

8.  Local information validity time.

5.2.1.  Information Base Changes Validity Time

   The Local Information Base MUST change to respond to changes in following node parameter manages the
   node's MANET interfaces.  The protocol MUST update its Neighborhood
   Information Base validity time of lost
   symmetric 1-hop neighbor information:

   N_HOLD_TIME  - is used as the period during which former 1-hop
      neighbor addresses are advertised as lost in response to such changes, and MAY transmit HELLO messages,
      allowing recipients of these HELLO messages in response to such changes.

8.1.  Adding a MANET Interface

   If a MANET interface accelerate removal
      of information from their 2-Hop Sets.  N_HOLD_TIME can be set to
      zero if accelerated information removal is added not required.

   The following constraint applies to the node then this is indicated by node parameter:

   o  N_HOLD_TIME >= 0

5.3.  Parameter Change Constraints

   This section presents guidelines, applicable if protocol parameters
   are changed dynamically.

   HELLO_INTERVAL

      *  If the addition of HELLO_INTERVAL for a Local Interface Tuple to MANET interface increases, then the Local Interface Set.
   The Neighbor Interface Base is not changed.  A
         next HELLO message MAY be
   sent on all this MANET interfaces, it SHOULD interface MUST be sent on generated
         according to the new interface.
   If using scheduled messages, a message schedule MUST previous, shorter, HELLO_INTERVAL.  Additional
         subsequent HELLO messages MAY be established
   on generated according to the new interface.

8.2.  Removing a MANET Interface
         previous, shorter, HELLO_INTERVAL.

      *  If the HELLO_INTERVAL for a MANET interface is removed from the node, decreases, then the
         following HELLO messages on this MUST result MANET interface SHOULD be the removal of information from the Local Information Base and the
   Neighborhood Information Base as follows:

   1.  Identify the Local Interface Tuple from the Local Interface Set
       which corresponds
         generated according to this current, shorter, HELLO_INTERVAL.

   REFRESH_INTERVAL

      *  If the REFRESH_INTERVAL for a MANET interface to be removed, and:

       1.  all Link Tuples whose L_local_iface_addr is included in increases, then
         the
           I_local_iface_addr_list content of that Local Interface Tuple MUST subsequent HELLO messages must be
           removed;

       2.  all Symmetric Neighbor Tuples whose N_local_iface_addr is
           included in organized such
         that the I_local_iface_addr_list specification of that Local
           Interface Tuple MUST be removed;

       3.  all 2-Hop Neighbor Tuples whose N2_local_iface_addr the old value of REFRESH_INTERVAL is
           included in
         satisfied for a further period equal to the I_local_iface_addr_list old value of
         REFRESH_INTERVAL.

      *  If the Local
           Interface Tuple MUST REFRESH_INTERVAL for a MANET interface decreases, then
         it MAY be removed;

       4. necessary to reschedule HELLO message generation on
         that MANET interface, in order that the Local Interface Tuple MUST be removed specification of
         REFRESH_INTERVAL is satisfied from the Local
           Interface Set.

   2.  All Neighborhood Address Association Tuples for which none time of change.

   HYST_ACCEPT and HYST_REJECT

      *  If HYST_ACCEPT or HYST_REJECT changes, then the
       addresses appropriate
         actions for link quality change, as specified in its NA_neighbor_iface_addr_list may Section 14.3
         MUST be found in any
       L_neighbor_iface_addr_list in the taken.

   L_HOLD_TIME

      *  If L_HOLD_TIME changes, then L_time for all relevant Link Set
         Tuples SHOULD be removed. changed.

   N_HOLD_TIME

      *  If the removed interface is the last MANET interface of the node, N_HOLD_TIME changes, then the Neighborhood Information Base NL_time for all relevant Lost
         Neighbor Tuples SHOULD be empty, and changed.

   HP_MAXJITTER

      *  If HP_MAXJITTER changes, then the node
   no longer participates in the protocol.

   A periodic HELLO message
         schedule on this MANET interface MAY be sent changed.

   HT_MAXJITTER

      *  If HT_MAXJITTER changes, then externally triggered HELLO
         messages on all remaining MANET interfaces.

8.3.  Adding an Address to a this MANET Interface

   If an address interface MAY be rescheduled.

5.4.  Constants

   The constant C is added to used as specified in [3].

6.  Local Information Base

   A node maintains a MANET Local Information Base that records information
   about its local interfaces (MANET interfaces or otherwise).  Each
   such interface then this is indicated by
   the addition of MUST have at least one address, and MAY have more than
   one address.  All addresses have an address to the appropriate
   I_local_iface_addr_list.  No change associated prefix length, which
   is made to included with all addresses in the Neighbor Local Information Base.  A HELLO message MAY be sent on all MANET
   interfaces.

8.4.  Removing an Address from a MANET Interface  If an
   address is removed from otherwise does not have a MANET interface prefix length then this it is
   indicated by the removal of an address considered
   to the appropriate
   I_local_iface_addr_list.  No change is made be equal to the Neighbor address length.  Two addresses are considered
   equal if and only if their associated prefix lengths are also equal.

   The Local Information Base unless the removed address is the principal address not modified by this protocol.  This
   protocol MAY respond to changes of the MANET Interface, in this Local Information Base which case first a new principal address
   of
   MUST reflect corresponding changes in the node's interface is selected, as described in Section 8.5.
   configuration.

6.1.  Local Interface Set

   A HELLO
   message MAY be sent on all MANET node's Local Interface Set records its local interfaces.

8.5.  Changing the Principal Address  It
   consists of a MANET Local Interface

   If the principal address of Tuples, one per interface:

      (I_local_iface_addr_list, I_manet)

   where:

   I_local_iface_addr_list  is a MANET interface list of a node the addresses of this
      interface.

   I_manet  is changed
   then a boolean flag, describing if this interface is indicated by a reordering MANET
      interface.

7.  Interface Information Base

   A node maintains an Interface Information Base for each of the appropriate
   I_local_iface_addr_list.  The following changes MUST be made its MANET
   interfaces.  This records information about links to that MANET
   interface and symmetric 2-hop neighbors which can be reached in two
   hops using those links as the
   Local first hop.  The Interface Information Base:

   1.  all
   Base includes the Link Tuples whose L_local_iface_addr is equal to Set and the old
       first 2-Hop Set.

   A MANET interface address can be present in this I_local_iface_addr_list have that
       L_local_iface_addr set equal to both the new first Link Set and as
   of a symmetric 2-hop neighbor.  This allows the node with this MANET
   interface address to be immediately considered as a symmetric 2-hop
   neighbor if it fails to be a symmetric 1-hop neighbor.

   All addresses MUST have an associated prefix length, which is
   included in this
       I_local_iface_addr_list;

   2. all Symmetric Neighbor Tuples whose N_local_iface_addr is equal
       to addresses in the old first address Interface Information Base.  Prefix
   lengths are indicated in this I_local_iface_addr_list have
       that N_local_iface_addr set equal to HELLO messages using the new first address PREFIX_LENGTH TLV
   specified in
       this I_local_iface_addr_list;

   3.  all 2-Hop Neighbor Tuples whose N2_local_iface_addr [1]; if an address has no such TLV, then its prefix
   length is equal to the old first address in this I_local_iface_addr_list have that
       N2_local_iface_addr set length.  Two addresses are considered
   equal to the new first address in this
       I_local_iface_addr_list. if and only if their associated prefix lengths are also equal.

7.1.  Link Set

   A HELLO message SHOULD NOT be sent in response to this change.

9.  HELLO Message Generation

   HELLO messages MUST be generated and transmitted independently on node's Link Set records links from other nodes which are, or
   recently were, 1-hop neighbors.  It consists of Link Tuples, each MANET interface.  If using the HELLO message interval
   HELLO_INTERVAL then, following
   representing a HELLO message transmission on single link:

      (L_neighbor_iface_addr_list, L_HEARD_time,
       L_SYM_time, L_quality, L_pending, L_lost, L_time)

   where:

   L_neighbor_iface_addr_list  is a
   MANET interface, another HELLO message MUST be sent on list of the same
   interface after an interval not greater than HELLO_INTERVAL.  Two
   successive HELLO message transmissions on addresses of the same MANET
      interface
   MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in
   Section 9.1.1.

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

   Other addresses which MUST be included in HELLO messages are:

   o  addresses of 1-hop neighbors from the Link Set;

   o  addresses of 1-hop neighbors from the Symmetric Neighbor Set.

   These addresses MUST NOT be included in the Local Interface Block.
   These addresses MAY be included in any HELLO messages sent on the
   appropriate MANET interface.  These addresses, and their associated
   TLVs, are:

   1.  For each address which appears in an L_neighbor_iface_addr_list
       (a neighbor address) in one or more Link Tuples whose
       L_local_iface_addr neighbor;

   L_HEARD_time  is the principal address of time until which the MANET interface over which of the HELLO message is to
      1-hop neighbor would be sent (i.e. considered heard if not considering link
      quality;

   L_SYM_time  is the
       first address listed in time until which the corresponding
       I_local_iface_addr_list), and whose L_STATUS does not equal
       PENDING, include link to the 1-hop neighbor address 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.
      would be considered symmetric 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 considering link quality;

   L_quality  is a dimensionless number between 0 (inclusive) and 1
      (inclusive) describing the quality of these Symmetric Neighbor
           Tuples, N_STATUS == SYMMETRIC, then include this
           N_neighbor_iface_addr with an associated TLV with:

           +  Type = OTHER_NEIGHB; AND

           +  Value = SYMMETRIC.

       3.  otherwise if, for all a link; a greater value of these Symmetric Neighbor Tuples,
           N_STATUS == LOST, and this address has
      L_quality indicating a higher quality link;
   L_pending  is a boolean flag, describing if a link is considered
      pending (i.e. a candidate, but not already been
           included with an associated TLV with Type == LINK_STATUS and
           Value == LOST, then include yet established, link);

   L_lost  is a boolean flag, describing if a link is considered lost
      due to link quality;

   L_time  specifies when this N_neighbor_iface_addr with
           an associated TLV with:

           +  Type = OTHER_NEIGHB; AND

           +  Value = LOST.

   On each of its MANET interfaces, for each specified 1-hop neighbor
   address and associated TLV, the address Tuple expires and associated TLV MUST be
   included in at least one removed.

   The status of the link, as obtained through HELLO message in every interval of length
   REFRESH_INTERVAL. exchange,
   and also taking link quality into account, denoted L_status, is
   defined by:

   1.  If an address L_pending is specified with more than one associated TLV, true, then
   these TLVs MAY be independently included or excluded from each HELLO
   messages as long as each such TLV L_status = PENDING;

   2.  otherwise, if L_lost is included associated with that
   address in a HELLO message sent on that MANET interface in every
   interval of length REFRESH_INTERVAL.

   TLVs associated with the same address included in true, then L_status = LOST;

   3.  otherwise, if L_SYM_time is not expired, then L_status =
       SYMMETRIC;

   4.  otherwise, if L_HEARD_time is not expired, then L_status = HEARD;

   5.  otherwise, L_status = LOST.

7.2.  2-Hop  Set

   A node's 2-Hop Set records symmetric 2-hop neighbors, and the same HELLO
   message MAY be applied
   symmetric links to symmetric 1-hop neighbors through which the same or different copies
   symmetric 2-hop neighbors can be reached.  It consists of that
   address.

9.1.  HELLO Message: Transmission

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

   If the parameters of the protocol are changed, then guarantees given
   for the old values a symmetric
   2-hop neighbor, and a single MANET interface of the parameters MUST still be respected.  In
   particular:

   o  If HELLO_INTERVAL a symmetric 1-hop
   neighbor.

      (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)

   where:

   N2_neighbor_iface_addr_list  is increased, then a HELLO message MUST be sent
      within list of the old HELLO_INTERVAL addresses 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.

9.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 symmetric 1-hop neighbor from which are subject to packet loss due this
      information was received;

   N2_2hop_iface_addr  is an address of an interface of a symmetric
      2-hop neighbor which has a symmetric link (using any MANET
      interface) 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 the indicated symmetric 1-hop neighbor;

   N2_time  specifies when this Tuple expires and MUST NOT be forwarded, and thus message forwarding
   jitter does not apply to HELLO messages. removed.

8.  Node Information Base

   Each form of jitter described in Appendix D requires node maintains a parameter
   MAXJITTER.  These parameters may be dynamic, Node Information Base that records information
   about addresses of current 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 recently symmetric 1-hop neighbors.

   All addresses MUST be significantly less than HELLO_INTERVAL.

   When HELLO message generation have an associated prefix length, which is delayed
   included in all addresses in order that a HELLO
   message is not sent within HELLO_MIN_INTERVAL of the previous Node Information Base.  Prefix
   lengths are indicated in HELLO
   message on messages using the same MANET interface, PREFIX_LENGTH TLV
   specified in [1]; if an address has no such TLV, 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.

10.  HELLO Message Processing

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

   For prefix
   length is equal to the purpose of this section, note the following definitions:

   o  the "validity time" address length.  Two addresses are considered
   equal if and only if their associated prefix lengths are also equal.

8.1.  Neighbor Set

   A node's Neighbor Set records all interface addresses of each 1-hop
   neighbor.  It consists of Neighbor Tuples, each representing a message single
   1-hop neighbor:

      (N_neighbor_iface_addr_list, N_symmetric)

   where:

   N_neighbor_iface_addr_list  is calculated from the
      VALIDITY_TIME TLV a list of the HELLO message as specified in Appendix C;

   o  the "Receiving Address List" is the I_local_iface_addr_list
      corresponding to the MANET interface on which the HELLO message
      was received;

   o  the "Receiving Address" addresses of a
      1-hop neighbor;

   N_symmetric  is the first address in the Receiving
      Address List, i.e. a boolean flag, describing if this is the principal a symmetric
      1-hop neighbor.

8.2.  Lost Neighbor Set

   A node's Lost Neighbor Set records addresses of all interfaces of
   nodes which recently were symmetric 1-hop neighbors, but are now
   advertised as lost.  It consists of Lost Neighbor Tuples, each
   representing a single such address:

      (NL_neighbor_iface_addr, NL_time)

   where:

   NL_neighbor_iface_addr  is an address of the MANET an interface
      on of a node which the HELLO message
      recently was received;

   o  the "Sending Address List" is the list a symmetric 1-hop neighbor of this node;

   NL_time  specifies when this Tuple expires and MUST be removed.

9.  Local Information Base Changes

   The Local Information Base MUST change to respond to changes in the addresses contained
   node's interfaces.  The node MUST update its Interface and Node
   Information Bases in response to such changes.  If any changes in the Local
   Interface Block and Node Information Bases satisfy any of the conditions
   described in Section 13, then those changes must be applied
   immediately, unless noted otherwise.

   A node MAY transmit HELLO message which do not
      have messages in response to these changes.

9.1.  Adding an associated TLV with Type == OTHER_IF;

   o  the word EXPIRED indicates that a timer Interface

   If an interface is set added to a value clearly
      preceding the current time (e.g. current time - 1).

10.1.  Populating node then this is indicated by the Link Set

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

   1. Local Interface Tuple to the Local Interface Set. If there
   the new interface is no Link Tuple such that:

       *  L_local_iface_addr == Receiving Address; AND

       *  L_neighbor_iface_addr_list contains one or more addresses a MANET interface then an initially empty
   Interface Information Base MUST be created for this new MANET
   interface.  The actions in Section 9.3 MUST be taken for each address
   of the added interface.  A HELLO message MAY be sent on all MANET
   interfaces, it SHOULD be sent on the Sending Address List.

       then create a new Link Tuple with:

       *  L_local_iface_addr = Receiving Address;

       *  L_SYM_time = EXPIRED;

       *  L_quality = INITIAL_QUALITY;

       *  L_pending = INITIAL_PENDING;

       *  L_lost = false;
       *  L_LOST_time = EXPIRED;

       *  L_time = current time + validity time.

   2.  This Link Tuple (existing or new) interface if it is a MANET
   interface.  If using scheduled messages, then modified as follows:

       1. a message schedule MUST
   be established on a new MANET interface.

9.2.  Removing an Interface

   If a MANET interface is removed from the node finds any address in the Receiving Address List node, then this MUST result
   in one removal of the address blocks included in the HELLO message,
           other than information from the Local Interface Block, then Information Base and the Link Tuple is
           modified
   Neighborhood Information Base as follows:

   1.  If any such address in  Remove the HELLO message 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. Local Interface Tuple that corresponds to the
       interface to be removed from the Local Interface Set.

   2.  Otherwise if any such address in  If the HELLO message interface to be removed is
               associated with a TLV MANET interface (i.e. with Type == LINK_STATUS and Value
       I_manet == LOST true) then:

       1.  if L_STATUS == SYMMETRIC:

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

                   o  L_SYM_time = EXPIRED.

       2.  L_neighbor_iface_addr_list = Sending Address List;

       3.  L_ASYM_time = current time + validity time;

       4.  L_time = max(L_time, L_ASYM_time).

10.2.  Populating  Remove the Symmetric Interface Information Base for that MANET
           interface;

       2.  All Neighbor Set

   On receiving a HELLO message, a node SHOULD update Tuples for which none of the addresses in its Symmetric
   Neighbor Set:

   1.  If any address
           N_neighbor_iface_addr_list are found in the Receiving Address List is any
           L_neighbor_iface_addr_list in an address
       block of the HELLO message, other than any remaining Link Set, are
           removed.

   If a node removes the Local Interface Block,
       with an associated TLV with Type == LINK_STATUS and (Value ==
       HEARD or Value == SYMMETRIC) then:

       1.  For each Tuple that contains the
   interface address (henceforth neighbor address) in that is used to define the HELLO
           message's Local Interface Block where a corresponding link
           tuple with L_STATUS == SYMMETRIC exists node's originator
   address, as defined in [1], then the link set:

           1. node MAY change originator
   address.

   If there the removed interface is no Symmetric Neighbor Tuple such that:

               -  N_local_iface_addr == Receiving Address; AND

               -  N_neighbor_iface_addr == neighbor address, the last MANET interface of the node,
   then create a new Symmetric Neighbor Tuple with:

               -  N_local_iface_addr = Receiving Address;

               -  N_neighbor_iface_addr = neighbor address;

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

               -  N_SYM_time = current time + validity time;

               -  N_time = N_SYM_time + N_HOLD_TIME.

   2.  Otherwise if any address in the Receiving Address List is in an
       address block of the HELLO message, other than the Local there will be no remaining Interface Block, with an associated TLV with Type == LINK_STATUS Information Bases, and Value == LOST, then:

       1.  For each address (henceforth neighbor address) in the
   node will longer participate in this protocol.

   A HELLO message Local MAY be sent on all remaining MANET interfaces.

9.3.  Adding an Address to an Interface Block, if there exists a Symmetric
           Neighbor Tuple with:

           +  N_local_iface_addr == Receiving Address; AND

           +  N_neighbor_iface_addr == neighbor address,

   If an address is added to an interface then update this Symmetric Neighbor Tuple is indicated by the
   addition of an address to have:

           +  N_SYM_time = EXPIRED;

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

10.3.  Populating the Neighborhood Address Association Set

   On receiving a HELLO message, appropriate I_local_iface_addr_list.
   The following changes MUST be made to the node SHOULD update its Neighborhood
   Address Association Set: Information Bases:

   1.  Remove all Neighborhood Address Association Tuples where:

       *  NA_neighbor_iface_addr_list  The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list
       contains at least one address
          which is contained in the Local Interface Block of added address, are removed.

   2.  Any Link Tuples, in any Link Set, whose
       L_neighbor_iface_addr_list contains:

       *  the
          received HELLO message,

       and create a new Neighborhood Address Association Tuple with: added address; OR

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

       *  NA_time = current time + validity time.

10.4.  Populating the 2-Hop removed
          Neighbor Set

   On receiving a HELLO message the node SHOULD update its 2-Hop Tuples, if any

       are removed; apply Section 13.1, but not Section 13.3.

   3.  Any Lost Neighbor Set:

   1.  If there exists a Link Tuple with L_local_iface_addr == Source Tuples whose NL_neighb_iface_addr is the added
       address, are removed.

   4.  Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address,
       are removed.

   A HELLO message MAY be sent on all MANET interfaces.

9.4.  Removing an Address and for which L_STATUS == SYMMETRIC then:

       1.  For each address (henceforth 2-hop neighbor address) in from an Interface

   If an address block is removed from an interface then this is indicated by
   the removal of an address from the HELLO message, other than appropriate
   I_local_iface_addr_list.  If this list is now empty then the
   corresponding Local Interface Block, which is not in any I_local_iface_addr_list
           (i.e. is not an address of Tuple MUST be removed.

   If a MANET node removes the interface of address that is used to define the receiving
           node):

           1.  If
   node's originator address, as defined in [1], then the 2-hop neighbor address has an associated TLV with:

               -  Type == LINK_STATUS node MAY
   change originator address.

   A HELLO message MAY be sent on all MANET interfaces.

10.  Packets and Value == SYMMETRIC; OR

               -  Type == OTHER_NEIGHB Messages

   The packet and Value == SYMMETRIC,

               then, if there message format used by this protocol is no 2-Hop Neighbor Tuple such that:

               -  N2_local_iface_addr == Receiving Address;

               -  N2_neighbor_iface_addr_list contains one or more
                  addresses defined in
   [1], which is used with the Sending Address List; AND

               -  N2_2hop_iface_addr == 2-hop neighbor address.

               then create a 2-Hop Neighbor Tuple with:

               -  N2_local_iface_addr = Receiving Address;

               -  N2_2hop_iface_addr = 2-hop neighbor address. following considerations:

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

               -  N2_neighbor_iface_addr_list = Sending Address List;

               -  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_list contains protocol specifies one or more
                  addresses in message type, the Sending Address List; AND

               -  N2_2hop_iface_addr == 2-hop neighbor address.

10.5.  Neighborhood Changes

   If L_STATUS of a Link Tuple changes from SYMMETRIC to any other
   status, due to any of:

   o  L_SYM_time expires; HELLO message.

   o  L_SYM_time is set to EXPIRED  HELLO message header options MAY be used as result of processing specified by a TLV with
      Type == LINK_STATUS and Value == LOST;
      protocol which uses this neighborhood discovery protocol.

   o  A change  HELLO messages MUST NOT be forwarded.

   o  HELLO messages MAY be included in L_quality resulting multi-message packets as
      specified in L_quality < HYST_REJECT

   then all 2-Hop Neighbor Tuples with:

   o  N2_local_iface_addr == L_local_iface_addr from the Link Tuple,
      AND; [1].

   o  N2_neighbor_iface_addr_list contains one or more addresses in the
      L_neighbor_iface_addr_list from the Link Tuple,

   MUST be deleted.

   In this, or any other case of neighborhood change, a node  Packet header options MAY send be used as specified by a protocol which
      uses this neighborhood discovery protocol.

10.1.  HELLO Messages

   A HELLO message reporting updated information, subject to MUST contain:

   o  A VALIDITY_TIME message TLV as specified in [3], representing
      H_HOLD_TIME for the
   constraints transmitting MANET interface.

   o  An address block, with an associated TLV block, known as the Local
      Interface Block, as specified in Section 9.

11.  Link Hysteresis

   Link hysteresis allows associating a L_quality value with a link.
   Using this L_quality in conjunction with two thresholds, HYST_ACCEPT 10.1.1.

   A HELLO message which is transmitted periodically SHOULD contain, and HYST_REJECT, as well
   otherwise MAY contain:

   o  An INTERVAL_TIME message TLV as specified in [3], representing
      HELLO_INTERVAL for the transmitting MANET interface.

   A HELLO message MAY contain:

   o  One or more address blocks, each link a L_pending and a L_lost
   flag, with an associated TLV block,
      known as Neighbor Address Blocks, as specified in Section 6.1 allows determining the L_STATUS of a link. 10.1.2.

   o  Other message TLVs.

10.1.1.  Local Interface Block

   The basic principles of link hysteresis are first address block, plus following TLV block, in a HELLO message
   is known as follows:

   o  A node does the Local Interface Block.  The Local Interface Block is
   not advertise a neighbor interface distinguished in any state until
      L_quality is acceptable.  If INITIAL_PENDING == true, this is such
      that L_quality >= HYST_ACCEPT, otherwise this is such that
      L_quality >= HYST_REJECT; to ensure way other than by being the latter a node MUST NOT
      define INITIAL_PENDING == false and INITIAL_QUALITY < HYST_REJECT.
      (A node also first address
   block in the HELLO message.

   The Local Interface Block MUST NOT define INITIAL_PENDING == true and
      INITIAL_QUALITY >= HYST_ACCEPT.)  A link which is not yet
      advertised has L_pending == true.

   o  Once L_quality >= HYST_ACCEPT, contain all of the L_pending flag is set false,
      indicating addresses in that
   node's Local Interface Set. Those addresses, if any, which correspond
   to interfaces other than the link can be advertised.

   o  A link MANET interface for which L_pending == false the HELLO
   message is advertised until its
      L_quality drops below HYST_REJECT.

   o  If a link has L_pending == false and L_quality < HYST_REJECT, the
      link is LOST and is advertised as such.  This link is not
      reconsidered as a candidate HEARD or SYMMETRIC link until
      L_quality >= HYST_ACCEPT.

   o  A link which has an acceptable quality may be advertised as HEARD,
      SYMMETRIC or LOST according to the exchange of HELLO messages.

   If L_quality for a link changes, the following actions transmitted MUST be taken: associated with a corresponding TLV
   with Type == OTHER_IF as specified in Table 1.  if L_quality >= HYST_ACCEPT then  Addresses of the corresponding Link Tuple is
       modified by:

       *  L_pending = false;

       *  L_lost = false;

       *  L_LOST_time = EXPIRED.

   2.  if L_quality < HYST_REJECT then
   MANET interface on which the corresponding Link Tuple HELLO message is
       modified by:

       *  L_lost = true
       *  L_LOST_time = current time + L_HOLD_TIME

       Any corresponding Tuples in the Symmetric Neighbor Set and 2-Hop
       Neighbor Set transmitted MUST NOT be removed.

   If L_quality for
   associated with such a link is updated based on HELLO message reception,
   or on reception of TLV.

   Note that a packet including Local Interface Block MAY include more than one address
   for each MANET interface, and hence a HELLO message, then L_quality
   MUST be updated prior to message MAY contain more
   than one address without an OTHER_IF TLV.

   +--------------+-----------------+----------------------------------+
   |     Name     |   Value Length  | Description                      |
   +--------------+-----------------+----------------------------------+
   |   OTHER_IF   |      0 bits     | Specifies that the HELLO processing described address, in
   Section 10.  (If   |
   |              |                 | the receipt Local Interface Block of the HELLO |
   |              |                 | message, or the packet
   containing it, creates the Link Tuple then instead the Link Tuple
   MUST be created is an address           |
   |              |                 | associated with an interface     |
   |              |                 | other than the updated L_quality value.)

11.1.  Link Quality

   A node MAY never update link quality (L_quality).  In this case MANET interface   |
   |              |                 | on which the
   node MUST define:

   o  INITIAL_PENDING = false;

   o  INITIAL_QUALITY >= HYST_REJECT (there message is no reason not to define
      INITIAL_QUALITY = 1).

   A node MAY update link quality based on any information available to
   it.  Particular cases that MAY be used include:

   o  Link layer information, see Appendix E.

   o  Receipt or loss of packets.  Provided packets include          |
   |              |                 | transmitted                      |
   +--------------+-----------------+----------------------------------+

                                  Table 1

10.1.2.  Neighbor Address Blocks

   Address blocks, each with a packet
      sequence number as defined following TLV block, in [1], packets on a link SHOULD have
      sequential packet sequence numbers, whether or not they include
      HELLO messages.  Link quality can be updated when a packet is
      received based on, for example, whether the last N out of M
      packets on the link were received, or a "leaky integrator"
      tracking packets.

   o  Receipt or loss of HELLO messages.  If message,
   after the maximum interval
      between HELLO messages is Local Interface Block, are known (possibly by inclusion of a
      message TLV with Type == INTERVAL_TIME as defined in Appendix C.2 Neighbor Address
   Blocks.  These Neighbor Address Blocks are not distinguished in HELLO messages) then any
   way other than by not being the loss of HELLO messages can be
      determined without first address block in the need to receive a HELLO
   message.  Note that
      if this case is combined with the previous case then care must be
      taken to avoid "double counting" a lost  A HELLO message in a MAY contain no Neighbor Address Blocks.

   A Neighbor Address Block contains current or recently lost
      packet.

12.  Proposed Values for Constants

   This section lists proposed values for the constants used in the
   specification 1-hop
   neighbors' interface addresses, each of the protocol.

12.1.  Message Intervals

   o  HELLO_INTERVAL = 2 seconds

   o  REFRESH_INTERVAL = HELLO_INTERVAL

   o  HELLO_MIN_INTERVAL = HELLO_INTERVAL/4

12.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

12.3.  Hysteresis values

   If link quality is not changed then:

   o  HYST_ACCEPT = 1

   o  HYST_REJECT = 0

   o  INITIAL_QUALITY = 1

   o  INITIAL_PENDING = false

   Otherwise, i.e. if link quality which is changed, then these parameters
   will associated with
   address block TLVs as described in Table 2.  Other addresses MAY be dependent on the link quality process used.  Example possible
   parameters are:

   o  HYST_ACCEPT = 0.75

   o  HYST_REJECT = 0.25

   o  INITIAL_QUALITY = 0.5

   o  INITIAL_PENDING = true

12.4.  Jitter Times

   o  HP_MAXJITTER = HELLO_INTERVAL/4

   o  HT_MAXJITTER = HELLO_INTERVAL/4

12.5.  Time

   o  C = 0.0625 second (1/16 second)

   In order to achieve interoperability, C
   included in Neighbor Address Blocks, but MUST NOT be the same on all
   nodes.

13.  IANA Considerations

13.1.  Multicast Addresses

   A well-known link-local multicast address, ALL-MANET-NEIGHBORS, must
   be registered and defined for both IPv6 and IPv4.

13.2.  Message Types

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

   +--------------------+-------+--------------------------------------+ the TLVs specified in Table 2.

   +--------------+-----------------+----------------------------------+
   |      Mnemonic     Name     |   Value Length  | Description                      |
   +--------------------+-------+--------------------------------------+
   +--------------+-----------------+----------------------------------+
   |  LINK_STATUS |      8 bits     | Specifies the status of the link |        HELLO
   |  TBD              | Local signaling                 |
   +--------------------+-------+--------------------------------------+

                                  Table 4

13.3.  TLV Types

   This specification defines two Message TLV types, which must be
   allocated from the "Assigned Message TLV Types" repository of [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 5

   This specification defines three Address Block TLV types, which must
   be allocated from the "Assigned Address Block TLV Types" repository
   of [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 the status of the link to  |
   |                    |       | the indicated address (LOST,       |
   |              |                 | (LOST, SYMMETRIC or HEARD)       |
   |              |                 |                                  |
   | OTHER_NEIGHB |  TBD      8 bits     | Specifies that the address is    |
   |              |                 | (SYMMETRIC) or was (LOST) of a MANET an  |
   |              |                 | interface of a symmetric 1-hop   |
   |              |                 | neighbor of the node transmitting             |
   |              |                 | transmitting the HELLO message, but does not have |
   |                    |       | a matching or better LINK_STATUS TLV message   |
   +--------------------+-------+--------------------------------------+
   +--------------+-----------------+----------------------------------+

                                  Table 6

13.4. 2

   A TLV with Type == LINK_STATUS and OTHER_NEIGHB Values

   The values which (Value == SYMMETRIC or Value ==
   LOST) also performs the LINK_STATUS function of a TLV can use are with Type == OTHER_IF and
   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

14.  References

14.1.  Normative References

   [1]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
        MANET Packet/Message Format", Work In
        Progress 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.

14.2.  Informative References

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

Appendix A.  Address Block TLV Combinations same value.  The algorithm for generating HELLO messages in Section 9 specifies
   which addresses MAY latter SHOULD NOT also 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 included.  If a TLV
   with Type == LINK_STATUS may have three possible values (Value == HEARD, and Value == SYMMETRIC or Value is combined with a
   TLV with Type == LOST), OTHER_IF and TLVs of TYPE == OTHER_NEIGHB may
   have two possible values (Value == SYMMETRIC or Value == LOST).  When
   both TLVs are associated with LOST then the same address only certain
   combinations of these TLV values are necessary, latter MUST be
   ignored, and are the only
   combinations generated by SHOULD NOT be included.  See Appendix A.

11.  HELLO Message Generation

   Each MANET interface MUST generate HELLO messages according to the algorithm in Section 9.  These
   combinations are indicated
   specification in Table 7.

   Cells labeled with "Yes" indicate the possible combinations which are
   generated by this section.  HELLO message generation and
   scheduling MUST be according to the algorithm interface parameters for that
   MANET interface and MAY be independent for each MANET interface or,
   interface parameters permitting, MANET interfaces MAY use the same
   schedule.

   If transmitting periodic HELLO messages then, following a HELLO
   message transmission on a MANET interface, another HELLO message MUST
   be transmitted on the same MANET 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 noted in Section 9.  Cells labeled with "No"
   indicate combinations not 11.2.1.

11.1.  HELLO Message Specification

   HELLO messages are generated by the algorithm independently on each MANET interface.

   A HELLO message MUST include a Local Interface Block, as specified in
   Section 9,
   but 10.1.1, as its first address block.

   Other addresses which MUST be included in Neighbor Address Blocks, as
   specified in Section 10.1.2, in HELLO messages sent over a given
   MANET interface are:

   o  Addresses of MANET interfaces of 1-hop neighbors from the Link Set
      of the Interface Information Base for this MANET interface.

   o  Other addresses of symmetric 1-hop neighbors from the Neighbor Set
      of this node's Node Information Base.

   o  Addresses of MANET interfaces of previously symmetric or heard
      1-hop neighbors connected on this MANET interface from the Link
      Set of the Interface Information Base for this MANET interface.
      (These are correctly parsed and interpreted by advertised for a period equal to this interface's
      L_HOLD_TIME after loss.)

   o  Other addresses of previously symmetric 1-hop neighbors from the algorithm
      Lost Neighbor Set of this node's Node Information Base.  (These
      are advertised for a period equal to N_HOLD_TIME after loss.)

   The addresses, and their associated TLVs, which may be included in
   Section 10.

   +----------------+----------------+----------------+----------------+
   |                |     Type ==    |     Type ==    |
   any HELLO message sent on this MANET interface (respecting
   REFRESH_INTERVAL for this MANET interface) are:

   1.  For each address (henceforth linked address) which appears in a
       Link Tuple in the Link Set for this MANET interface, for which
       L_status does not equal PENDING, include the linked address with
       an associated TLV with:

       *  Type ==    |
   |                |  OTHER_NEIGHB  |  OTHER_NEIGHB, |  OTHER_NEIGHB, |
   |                |    (absent)    |    Value ==    | = LINK_STATUS; AND

       *  Value = L_status.

   2.  For each address (henceforth neighbor address) which appears in
       an N_neighbor_iface_addr_list in a Neighbor Tuple with
       N_symmetric == LOST |
   |                |                |    SYMMETRIC   |                |
   +----------------+----------------+----------------+----------------+
   | Type true, and which has not already been included with
       an associated TLV with (Type ==        |       No       |       Yes      |       Yes      |
   | LINK_STATUS    |                |                |                |
   | (absent)       |                |                |                |
   |                |                |                |                |
   | Type ==        |       Yes      |       Yes      |       Yes      |
   | LINK_STATUS,   |                |                |                |
   | and Value == HEARD |                |                |                |
   |                |                |                |                |
   |
       SYMMETRIC), include the neighbor address with an associated TLV
       with:

       *  Type ==        |       Yes      |       No       |       No       |
   | LINK_STATUS,   |                |                |                |
   | = OTHER_NEIGHB; AND

       *  Value ==       |                |                |                |
   | SYMMETRIC      |                |                |                |
   |                |                |                |                |
   | = SYMMETRIC.

   3.  For each Lost Neighbor Tuple whose NL_neighbor_iface_addr
       (henceforth lost address) has not already been included, include
       the lost address with an associated TLV with:

       *  Type ==        |       Yes      |       Yes      |       No       |
   | LINK_STATUS,   |                |                |                |
   | = OTHER_NEIGHB; AND

       *  Value == LOST  |                |                |                |
   +----------------+----------------+----------------+----------------+

                                  Table 7

Appendix B.  HELLO Message Example

   An example HELLO message, sent by = LOST.

   If an originator node with a single
   MANET interface, is as follows.  The message uses IPv4 (four octet)
   addresses without prefix TLVs.  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 address is 50 octets.

   The message contains a message TLV block specified with content length 8 octets
   containing two message TLVs, of types VALIDITY_TIME and
   INTERVAL_TIME. more than one associated TLV, then
   these TLVs MAY be independently included or excluded from each HELLO
   message.  Each uses a such TLV MUST be included associated with semantics value 4, indicating that no start and stop indexes are included, and each has address
   in a value
   length HELLO message sent on that MANET interface in every interval of 1 octet.  The values
   length equal to that MANET interface's parameter REFRESH_INTERVAL.
   TLVs associated with the same address included (0x68 and 0x50) are time
   codes representing in the default values same HELLO
   message MAY be applied to the same or different copies of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds).

   The first address block contains 1 local interface that
   address.  The
   semantics octet value 2 indicates no address tail, and

11.2.  HELLO Message Transmission

   HELLO messages are transmitted in the head
   length of 4 octets indicates no address mid sections.  This packet/message format specified
   by [1] using the "LL MANET Routers" multicast address
   block has no TLVs (TLV block content length 0 octets).

   The second, and last, address block contains 4 neighbor interface
   addresses.  The semantics octet value 2 indicates no address tail,
   the head length of 3 octets indicates address mid sections of one
   octet each.  The following TLV block (content length 7 octets)
   includes one LINK_STATUS TLV which reports specified by
   [2] as destination IP address, using the MANET UDP port specified in
   [2].

11.2.1.  HELLO Message Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If using data link status values of
   all reported neighbors and
   physical layers which are subject to packet loss due to collisions,
   HELLO messages SHOULD be jittered as described in [4].

   Internally triggered message generation (such as due to a single multivalue TLV: the first two
   addresses are HEARD, the third address is SYMMETRIC change in
   local interfaces) MAY be treated as if externally generated message
   generation, or MAY be not jittered.

   HELLO messages MUST NOT be forwarded, and the fourth
   address is LOST.  The TLV semantics value thus message forwarding
   jitter does not apply to HELLO messages.

   Each form of 20 indicates, jitter described in
   addition to that this is [4] requires a multivalue TLV, that no start parameter MAXJITTER.
   These interface parameters may be dynamic, and stop
   indexes are included, since values for all addresses 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 included.
   The TLV value length of 4 octets indicates one octet per value per
   address.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 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.

12.  HELLO     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 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| Processing

   On receiving a HELLO message, a node MUST first check if any address
   in its Local Interface Block is one of its interface addresses (i.e.
   is in any I_local_iface_addr_list in the Local Interface Set).  If so
   then the HELLO message MUST be discarded.

   Otherwise the receiving node MUST update its appropriate Interface
   Information Base and its Node Information Base according to this
   section.  If any changes satisfy any of the conditions described in
   Section 13 then the indicated consequences MUST be applied
   immediately, unless noted otherwise.

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

   o  "validity time" is calculated from the 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 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 1 1 1|  LINK_STATUS  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |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
      HELLO message as specified in a TLV's value field.  Of these 8 bits, [3].

   o  "Receiving Address List" is the least significant four
   bits represent the mantissa (a), and I_local_iface_addr_list
      corresponding to the most significant four bits
   represent MANET interface on which the exponent (b), so that:

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

   o  time code = 16 * b + a

   All nodes in the network MUST use  "Neighbor Address List" is the same value list of C, which will be
   specified the addresses contained 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 Local Interface Block of time codes.

   An algorithm for computing the time code representing HELLO message.

   o  "Sending Address List" is the smallest
   representable time value not less than list of the time value t is:

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

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

   3.  if a HELLO message which do not have
      an associated TLV with Type == 16 then set b = b + 1 and set OTHER_IF.

   o  EXPIRED indicates that a = 0;

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

   The minimum time value that can be represented in this manner is C.
   The maximum (e.g. current 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 - 1).

   o  "Removed Address List" is a
   packet or list of addresses created by this
      HELLO message TLV then it must be a single value TLV processing which were formerly reported 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 local 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 HELLO message, but which are not included
      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> Neighbor Address List.  This list is an 8 bit field containing a time code initialized as defined in
      Appendix C.1.

   <distance> empty.

   o  "Lost Address List" 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 subset of n in the regular expression
   syntax it contains 2n+1 octets, thus the <length> field of a single
   value Time TLV, Removed Address List
      containing addresses which MUST always be present, were formerly considered as symmetric.
      This list 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 initialized as empty.

12.1.  Updating the Neighbor Set

   On receiving node's distance from the originator node, a HELLO message, the
   time value indicated is that represented by node MUST update its Neighbor Set
   and populate the time code:

   o  <t_1>, if n > 0 Removed Address List 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 Lost Address List:

   1.  Find all Neighbor Tuples (hereafter matching Neighbor Tuples)
       where:

       *  N_neighbor_iface_addr_list contains at least one address in
          the Neighbor Address List.

   2.  If there are no matching Neighbor Tuples, then:

       1.  Create a multivalue Time TLV, each single value subfield new Neighbor Tuple with:

           +  N_neighbor_iface_addr_list = Neighbor Address List;

           +  N_symmetric = false.

   3.  If there is one matching Neighbor Tuple, then:

       1.  If the N_neighbor_iface_addr_list of the
   multivalue Time TLV matching Neighbor
           Tuple is defined as above.  Note that [1] requires that
   each single value subfield has not equal to the same length (i.e. Neighbor Address List, then:

           1.  For each address (henceforth removed address) which is in
               the same value
   of n) N_neighbor_iface_addr_list, but they need not use in the same values of <d_1> Neighbor
               Address List:

               1.  Add the removed address to <d_n>.

C.3.  Message TLVs

   Two message TLVs the Removed Address List.

               2.  If N_symmetric == true, then add the removed address
                   to the Lost Address List.

           2.  Update the matching Neighbor Tuple by:

               -  N_neighbor_iface_addr_list = Neighbor Address List.

   4.  If there are defined, for signaling message validity time
   (VALIDITY_TIME) and message interval (INTERVAL_TIME).

C.3.1.  VALIDITY_TIME TLV

   A VALIDITY TIME TLV two or more matching Neighbor Tuples, then:

       1.  For each address (henceforth removed address) which is a message TLV that defines in the validity time
           N_neighbor_iface_addr_list of any of the information carried in the message in which matching Neighbor
           Tuples:

           1.  Add the TLV is
   contained.  After this time removed address to the receiving node MUST consider Removed Address List.

           2.  If N_symmetric == true, then add the
   message content removed address to no longer be valid (unless repeated in
               the Lost Address List.

       2.  Replace the matching Neighbor Tuples by a later
   message).  The validity time of a message MAY be specified to depend
   on single Neighbor
           Tuple with:

           +  N_neighbor_iface_addr_list = Neighbor Address List;

           +  N_symmetric = false

12.2.  Updating the distance from its originator.  (This is appropriate if
   messages are sent with different hop limits, so that Lost Neighbor Set

   On 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 HELLO message, 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 node MUST update its Lost Neighbor
   Set:

   1.  For each address (henceforth lost address) in the originator.  (This is appropriate Lost Neighbor
       List, if messages are sent no Lost Neighbor Tuple with different hop limits, so that NL_neighbor_iface_addr ==
       lost address exists, then add a Lost Neighbor Tuple with:

       *  NL_neighbor_iface_addr = lost address;

       *  NL_time = current time + N_HOLD_TIME.

12.3.  Updating the Link Set

   On 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 HELLO message, a building block node MUST update its Link Set for the
   MANET routing
   protocols employing other triggered or periodic interface on which the HELLO message exchanges,
   this appendix presents global concerns pertaining to jittering of
   MANET control traffic.

D.1.  Jitter

   In order to prevent nodes is received:

   1.  Remove all addresses in a MANET from simultaneous transmission,
   whilst retaining the MANET characteristic of maximum node autonomy, a
   randomization of Removed Address List from the transmission time
       L_neighbor_iface_addr_list of packets by nodes, known as
   jitter, MAY be employed.  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.

   Each of these cases uses a parameter, denoted MAXJITTER, for all Link Tuples.

   2.  Remove all Link Tuples whose L_neighbor_iface_addr_list is now
       empty; apply Section 13.1, but not Section 13.3.

   3.  Find all Link Tuples (hereafter matching Link Tuples) where:

       *  L_neighbor_iface_addr_list contains one or more addresses in
          the
   maximum timing variation that it introduces. Sending Address List.

   4.  If there is more than one of
   these cases is used by matching Link Tuple, then remove them
       all; apply Section 13.1, but not Section 13.3.

   5.  If no matching Link Tuples remain, then create a protocol, it MAY use the same new matching
       Link Tuple with:

       *  L_neighbor_iface_addr_list = empty;

       *  L_HEARD_time = EXPIRED;

       *  L_SYM_time = EXPIRED;

       *  L_quality = INITIAL_QUALITY;

       *  L_pending = INITIAL_PENDING;

       *  L_lost = false;
       *  L_time = current time + validity time.

   6.  The matching Link Tuple, existing or a different
   value of MAXJITTER for each case.  It also MAY use new, is then modified as
       follows:

       1.  If the same or
   different values of MAXJITTER according to message type, and under
   different circumstances - MANET interface finds any address (henceforth
           receiving address) in particular if other parameters (such as
   message interval) vary.

   Issues relating to the value of MAXJITTER are considered Receiving Address List in
   Appendix D.1.4.

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
   MESSAGE_INTERVAL.  A node MAY maintain more than one such interval,
   e.g. for different message types or
           Neighbor Address Block in different circumstances (such the HELLO message, then the Link
           Tuple is modified 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 follows:

           1.  If any receiving address in the same type HELLO message is
   equal to (MESSAGE_INTERVAL
               associated with a TLV with Type == LINK_STATUS and (Value
               == HEARD or Value == SYMMETRIC) then:

               - jitter), where jitter is the random
   value.

   Subtraction of the random value from the message interval ensures
   that  L_SYM_time = current time + validity time.

           2.  Otherwise if any receiving address in the HELLO message interval never exceeds MESSAGE_INTERVAL,
               is associated with a TLV with Type == LINK_STATUS and does
               Value == LOST then:

               1.  if L_SYM_time has not adversely affect timeouts or other mechanisms which may be based
   on message late arrival expired, then:

                   1.  L_SYM_time = EXPIRED.

                   2.  if L_status == HEARD or failure to arrive.  By basing the message
   transmission SYMMETRIC, then:

                       *  L_time = current time on the previous transmission + L_HOLD_TIME.

       2.  L_neighbor_iface_addr_list = Sending Address List.

       3.  L_HEARD_time = max(current time + validity time, rather than by
   jittering L_SYM_time).

       4.  If L_status == PENDING, then:

           +  L_time = max(L_time, L_HEARD_time).

       5.  Otherwise if L_status == HEARD or SYMMETRIC, then:

           +  L_time = max(L_time, L_HEARD_time + L_HOLD_TIME).

12.4.  Updating the 2-Hop Set

   On receiving a fixed clock, nodes can become completely desynchronized,
   which minimizes their probability of repeated collisions.  This is
   particularly useful when combined with externally triggered HELLO message
   generation and rescheduling.

   The jitter value SHOULD be taken from a uniform distribution between
   zero and MAXJITTER.

   Note that a node will know MUST update its own MESSAGE_INTERVAL value and can
   readily ensure that any MAXJITTER value used satisfies 2-Hop Set for the conditions
   in Appendix D.1.4.

D.1.2.  Externally triggered message generation

   An internal or external condition or event MAY trigger
   MANET interface on which the HELLO message
   generation by a node.  Depending upon was received:

   1.  Remove all addresses in the protocol, this condition
   MAY trigger generation of a single message, initiation Removed Address List from the
       N2_neighbor_iface_addr_list of a new
   periodic message schedule, or rescheduling of existing periodic
   messaging.  Collision between externally triggered messages is made
   more likely if more than one node is likely to respond to the same
   event.  To reduce this likelihood, an externally triggered message
   MAY be jittered by delaying it by a random duration; an internally
   triggered message MAY also be so jittered if appropriate.  This delay
   SHOULD be generated uniformly in an interval between zero and
   MAXJITTER. all 2-Hop Tuples.

   2.  If periodically transmitted messages are rescheduled,
   then this SHOULD be based on this delayed time, the Link Tuple with subsequent
   messages treated as described L_neighbor_iface_addr_list == Sending
       Address List has L_STATUS == SYMMETRIC then:

       1.  For each address (henceforth 2-hop address) in Appendix D.1.1.

   When messages are triggered, whether or not they are also
   periodically transmitted, a protocol MAY impose a minimum interval
   between messages Neighbor
           Address Block of the same type, denoted MESSAGE_MIN_INTERVAL.  It
   is however appropriate to also allow this interval to be reduced by
   jitter, so that when a message HELLO message, which is transmitted not in the next message is
   allowed after a time (MESSAGE_MIN_INTERVAL - jitter), where jitter
   SHOULD be generated uniformly
           Neighbor Address List or in any I_local_iface_addr_list:

           1.  If the 2-hop address has an interval between zero associated TLV with:

               -  Type == LINK_STATUS and
   MAXJITTER (using a value of MAXJITTER appropriate to periodic message
   transmission).  This Value == SYMMETRIC; OR

               -  Type == OTHER_NEIGHB and Value == SYMMETRIC,

               then, if there is because otherwise, when external triggers are no 2-Hop Tuple such that:

               -  N2_neighbor_iface_addr_list contains one or more frequent than MESSAGE_MIN_INTERVAL, it takes the role of
   MESSAGE_INTERVAL and the arguments applying to jittering of the
   latter also apply to
                  addresses in the former.  This also permits
   MESSAGE_MIN_INTERVAL to equal MESSAGE_INTERVAL even when jitter is
   used.

D.1.3.  Message forwarding

   When a node forwards a message, it may be jittered by delaying it by Sending Address List; AND

               -  N2_2hop_iface_addr == 2-hop address.

               then create a random duration. 2-Hop Neighbor Tuple with:

               -  N2_2hop_iface_addr = 2-hop address.

               This delay SHOULD be generated uniformly in an
   interval between zero and MAXJITTER.

   Unlike the cases of periodically generated and externally triggered
   messages, a node is not automatically aware of the message
   originator's value of MESSAGE_INTERVAL, which is required to select a
   value of MAXJITTER which 2-Hop Tuple (existing or new) is known to be valid.  This may require
   prior agreement then modified 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
               follows:

               -  N2_neighbor_iface_addr_list = Sending Address List;

               -  N2_time = current time since + validity time.

           2.  Otherwise if the last message) 2-hop 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 Tuples with:

               -  N2_neighbor_iface_addr_list contains one or more
                  addresses in the Sending Address List; AND

               -  N2_2hop_iface_addr == 2-hop address.

13.  Other Information Base Changes

   The Interface and Node Information Bases MUST be by any other protocol
   specific mechanism, which changed when some
   events occur.  These events may include estimation of the value of
   MESSAGE_INTERVAL based on received message times.

   For several possible reasons (differing parameters, result from HELLO message
   rescheduling, extreme random values) a node processing,
   or may receive a message
   while still waiting to forward an earlier message be otherwise generated (e.g. expiry of timers or link quality
   changes).

   Events which cause changes in the same type
   originating Information Bases are:

   o  A Link Tuple's state changes from symmetric, or the same node.  This Link Tuple is possible without jitter, but
   may occur more often with it.  The appropriate action to take is
   protocol specific (typically
      removed.

   o  A Link Tuple's state changes to discard the earlier message symmetric.

   o  A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed.

   o  Local interface address changes, as specified in Section 9.

   o  Link quality changes, as specified in Section 14.

   A node MAY report updated information in response to
   forward both, possible modifying timing any of these
   changes in HELLO message(s), subject to maintain message order).

   In many cases, including [3] and protocols using the full
   functionality of [1], constraints in
   Section 11.

   A node which transmits HELLO messages are transmitted hop by hop in
   potentially multi-message packets, and some response to such changes
   SHOULD transmit a HELLO message:

   o  On all MANET interfaces, if the Neighbor Set changes such as to
      indicate the change in symmetry of any 1-hop neighbors (including
      addition or removal of symmetric 1-hop neighbors).

   o  Otherwise, on all those MANET interfaces whose Link Set changes
      such as to indicate a change in status of any 1-hop neighbors
      (including the addition or removal of any 1-hop neighbors, other
      than those messages
   may need considered pending).

13.1.  Link Tuple Not Symmetric

   If for any Link Tuple with L_status == SYMMETRIC:

   o  L_status changes to be forwarded. any other value; OR

   o  the Link Tuple is removed;

   then:

   1.  All 2-Hop Tuples for the same MANET interface with:

       *  N2_neighbor_iface_addr_list contains one or more addresses in
          L_neighbor_iface_addr_list;

       are removed.

   2.  For efficiency this should be the Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list:

       1.  If there are no remaining Link Tuples for any MANET interface
           with:

           +  L_neighbor_iface_addr_list contained in
              N_neighbor_iface_addr_list; AND

           +  L_status == SYMMETRIC;

           then modify the Neighbor Tuple by:

           1.  N_symmetric = false.

           2.  For each address (henceforth neighbor address) in
               N_neighbor_iface_addr_list, add a single
   packet, and hence Lost Neighbor Tuple
               with:

               -  NL_neighbor_iface_addr = neighbor address;

               -  NL_time = current time + N_HOLD_TIME.

13.2.  Link Tuple Symmetric

   If, for any Link Tuple which does not have L_status == SYMMETRIC:

   o  L_status changes to SYMMETRIC;

   (this includes a newly created Link Tuple which is immediately
   updated to have L_status == SYMMETRIC) then:

   1.  For the Neighbor Tuple whose N_neighbor_iface_addr_list includes
       L_neighbor_iface_addr_list, set:

       *  N_symmetric = true.

   2.  Remove all Lost Neighbor Tuples whose LN_neighbor_iface_addr is
       included in that N_neighbor_iface_addr_list.

13.3.  Link Tuple Heard Timeout

   If, for any Link Tuple:

   o  L_HEARD_time expires; OR

   o  the Link Tuple is removed;

   then:

   1.  For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list, if no Link Tuples for any MANET
       interface remain with:

       *  L_neighbor_iface_addr_list contained in
          N_neighbor_iface_addr_list;

       *  L_HEARD_time is not expired;

       then remove the Neighbor Tuple.

14.  Link Quality

   Link quality is a mechanism whereby a node MAY take considerations
   other than message exchange into account for determining when a link
   is and is not a candidate for being considered as HEARD or SYMMETRIC.

   For deployments where no link quality is used, the considerations in
   Section 14.1 apply.  For deployments were link quality is used, the
   general principles of link quality usage are described in
   Section 14.2.  Section 14.3 and Section 14.4 detail link quality
   functioning.

   Link quality is used only locally by a node, and nodes may fully
   interoperate whether they are using the same, different or no link
   quality methods.

14.1.  Deployment Without Link Quality

   In order for a node to not employ link quality, the node MUST define:

   o  INITIAL_PENDING = false;

   o  INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define
      INITIAL_QUALITY = 1).

14.2.  Basic Principles of Link Quality

   To enable link quality usage, the L_quality value of a Link Tuple is
   used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT,
   to set the flags L_pending and L_lost of that Link Tuple.  Based on
   these flags, the link status to advertise for that Link Tuple is
   determined as described in Section 7.1.

   The use of two thresholds implements link hysteresis, whereby a link
   which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either
   accepted or rejected (depending on which threshold it has most
   recently crossed, or if neither the value of INITIAL_QUALITY).  With
   appropriate values of these parameters, this prevents over-rapid
   changes of link status.

   The basic principles of link quality usage are as follows:

   o  A node does not advertise a neighbor interface in any state until
      L_quality is acceptable:

      *  If INITIAL_PENDING == true, then this is such that L_quality >=
         HYST_ACCEPT.

      *  Otherwise this is such that L_quality >= HYST_REJECT.  To
         ensure this, a node MUST NOT define INITIAL_PENDING == false
         and INITIAL_QUALITY < HYST_REJECT.  (A node also MUST NOT
         define INITIAL_PENDING == true and INITIAL_QUALITY >=
         HYST_ACCEPT.)

      *  A link which is not yet advertised has L_pending == true.

   o  Once L_quality >= HYST_ACCEPT, the L_pending flag is set false,
      indicating that the link can be advertised.

   o  A link for which L_pending == false is advertised until its
      L_quality drops below HYST_REJECT.

   o  If a link has L_pending == false and L_quality < HYST_REJECT, the
      link is LOST and is advertised as such.  This link is not
      reconsidered as a candidate HEARD or SYMMETRIC link until
      L_quality >= HYST_ACCEPT.

   o  A link which has an acceptable quality may be advertised as HEARD,
      SYMMETRIC or LOST according to the exchange of HELLO messages.

14.3.  When Link Quality Changes

   If L_quality for a link changes, then the following actions MUST be
   taken:

   1.  If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is
       modified by:

       1.  L_pending = false.

       2.  L_lost = false.

       3.  If L_status == HEARD or L_status == SYMMETRIC, then:

           +  L_time = max(L_time, L_HEARD_time + L_HOLD_TIME)

   2.  If L_status is not equal to PENDING, and L_quality < HYST_REJECT
       then the corresponding Link Tuple is modified by:

       1.  If L_lost == false, then:

           +  L_lost = true

           +  L_time = min(L_time, current time + L_HOLD_TIME)

   Any appropriate action indicted in Section 13 MUST also be taken.

   If L_quality for a link is updated based on HELLO message reception,
   or on reception of a packet including a HELLO message, then L_quality
   MUST be updated prior to the HELLO message processing described in
   Section 12.  (If the receipt of the HELLO message, or the packet
   containing it, creates the Link Tuple then instead the Link Tuple
   MUST be created with the updated, from INITIAL_QUALITY, L_quality
   value.)

14.4.  Updating Link Quality

   A node MAY update link quality based on any information available to
   it.  Particular cases that MAY be used include:

   o  Information from the link layer, such as signal to noise ratio.

   o  Receipt or loss of packets.  If packets include a packet sequence
      number as defined in [1], then packets on a link SHOULD have
      sequential packet sequence numbers, whether or not they include
      HELLO messages.  Link quality can be updated when a packet is
      received based on, for example, whether the last N out of M
      packets on the link were received, or a "leaky integrator"
      tracking packets.

   o  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion of a message
      TLV with Type == INTERVAL_TIME, as defined in [3], in HELLO
      messages) then the loss of HELLO messages can be determined
      without the need to receive a HELLO message.  Note that if this
      case is combined with the previous case then care must be taken to
      avoid "double counting" a lost HELLO message in a lost packet.

15.  Proposed Values for Parameters and Constants

   This section lists the parameters and constants used in the
   specification of the protocol, and proposed values of each which may
   be used when a single value of each is used.

15.1.  Message Interval Interface Parameters

   o  HELLO_INTERVAL = 2 seconds

   o  HELLO_MIN_INTERVAL = HELLO_INTERVAL/4

   o  REFRESH_INTERVAL = HELLO_INTERVAL

15.2.  Information Validity Time Interface Parameters

   o  H_HOLD_TIME = 3 x REFRESH_INTERVAL

   o  L_HOLD_TIME = H_HOLD_TIME

15.3.  Information Validity Time Node Parameters

   o  N_HOLD_TIME = L_HOLD_TIME

15.4.  Link Quality Interface Parameters

   If link quality is changed, then parameter values will depend on the
   link quality process.  If link quality is not changed, then:

   o  HYST_ACCEPT = 1

   o  HYST_REJECT = 0

   o  INITIAL_QUALITY = 1

   o  INITIAL_PENDING = false

15.5.  Jitter Interface Parameters

   o  HP_MAXJITTER = HELLO_INTERVAL/4

   o  HT_MAXJITTER = HP_MAXJITTER

15.6.  Constants

   o  C = 0.0625 second (1/16 second)

16.  IANA Considerations

16.1.  Message Types

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

      +--------------+------+--------------------------------------+
      |     Name     | Type | Description                          |
      +--------------+------+--------------------------------------+
      |     HELLO    |  TBD | Local signaling                      |
      +--------------+------+--------------------------------------+

16.2.  TLV Types

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

   +--------------+------+---------------------------------------------+
   |     Name     | Type | Description                                 |
   +--------------+------+---------------------------------------------+
   |   OTHER_IF   |  TBD | Specifies that the address, in the Local    |
   |              |      | Interface Block, is an address associated   |
   |              |      | with an interface other than the MANET      |
   |              |      | interface on which the message is           |
   |              |      | transmitted                                 |
   |              |      |                                             |
   |  LINK_STATUS |  TBD | Specifies the status of the link from the   |
   |              |      | indicated address (LOST, SYMMETRIC or       |
   |              |      | HEARD)                                      |
   |              |      |                                             |
   | OTHER_NEIGHB |  TBD | Specifies that the address is (SYMMETRIC)   |
   |              |      | or recently was (LOST) of an interface of a |
   |              |      | symmetric 1-hop neighbor of the node        |
   |              |      | transmitting the message                    |
   +--------------+------+---------------------------------------------+

16.3.  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

17.  References

17.1.  Normative References

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

   [2]  Chakeres, I., "Internet Assigned Numbers Authority (IANA)
        Allocations for the Mobile Ad hoc Networks (MANET) Working
        Group", Work In Progress draft-ietf-manet-iana-04.txt, May 2007.

   [3]  Clausen, T. and C. Dearlove, "Representing multi-value time in
        MANETs", Work In Progress draft-ietf-manet-timetlv-00.txt,
        April 2007.

   [4]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
        considerations in MANETs", Work In
        Progress draft-ietf-manet-jitter-00.txt, April 2007.

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

17.2.  Informative References

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

   [7]  Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET):
        Routing Protocol Performance Issues and Evaluation
        Considerations", RFC 2501, January 1999.

Appendix A.  Address Block TLV Combinations

   The algorithm for generating HELLO messages in Section 11 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 11.  These
   combinations are indicated in Table 5.

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

   +----------------+----------------+----------------+----------------+
   |                |     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 5

Appendix B.  HELLO Message Example

   An example HELLO message, transmitted by an originator node with a
   single MANET interface, is as follows.  The message uses IPv4 (four
   octet) addresses without prefix TLVs.  The message is transmitted
   with a full message header (message semantics octet is 0) with a hop
   limit of 1 and a hop count of 0.  The overall message length is 50
   octets.

   The message contains 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
   that no start and stop indexes are included, and each has a value
   length of 1 octet.  The values included (0x68 and 0x50) are time
   codes representing the default values of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming a
   default value of constant C (0.0625 second).

   The first address block contains 1 local interface address.  The
   semantics octet value 2 indicates no address tail, and the head
   length of 4 octets indicates no address mid sections.  This address
   block has no TLVs (TLV block content length 0 octets).

   The second, and last, address block contains 4 neighbor interface
   addresses.  The semantics octet value 2 indicates no address tail,
   the head length of 3 octets indicates address mid sections of one
   octet each.  The following TLV block (content length 7 octets)
   includes one LINK_STATUS TLV which reports the link status values of
   all reported 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 20 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 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 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 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 1 1 1|  LINK_STATUS  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1 0 1 0 0|0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   SYMMETRIC   |     LOST      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix C.  Constraints

   Any process which updates the forwarding jitter of all messages received in a
   single packet should be Local Information Base or the same.  (This also requires
   Neighborhood Information Base MUST ensure that a single
   value of MAXJITTER is used in this case.)  For this to have the
   intended uniform 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 to use the smallest of these jitter
   values, as that produces a jitter with a non-uniform distribution and
   a reduced mean value.

   In addition, the protocol may permit messages received in different
   packets to be combined, possibly also with locally generated messages
   (periodically generated or triggered).  However constraints
   specified 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.

D.1.4.  Maximum Jitter Determination

   In considering how the maximum jitter (one or more instances of
   parameter MAXJITTER) may be determined, the following points may be
   noted:

   o  While jitter may resolve the problem of simultaneous
      transmissions, the timing changes (in particular the delays) it
      introduces will otherwise only have a negative impact on a well-
      designed protocol.  Thus MAXJITTER should always be minimized,
      subject to acceptably achieving its intent.

   o  When messages are periodically generated, all of the following
      that appendix are relevant apply to maintained.

   In each instance of MAXJITTER:

      *  it MUST NOT be greater than MESSAGE_INTERVAL/2;

      *  it SHOULD be significantly less than MESSAGE_INTERVAL;

      *  it MUST NOT be greater than MESSAGE_MIN_INTERVAL;

      *  it SHOULD Local Interface Tuple:

   o  I_local_iface_addr_list MUST NOT be greater than MESSAGE_MIN_INTERVAL/2. empty.

   o  As well as the decision as to whether to use jitter being
      dependent on the medium access control and lower layers,  I_local_iface_addr_list MUST NOT contain any address which is in
      the
      selection I_local_iface_addr_list of the MAXJITTER parameter should any other Local Interface Tuple.

   In each Link Tuple:

   o  L_neighbor_iface_addr_list MUST NOT be appropriate to
      those mechanisms. empty.

   o  As jitter is intended to reduce collisions, greater jitter, i.e.
      an increased value of MAXJITTER,  L_neighbor_iface_addr_list MUST NOT contain any address which is appropriate when
      in the chance I_local_iface_addr_list of
      collisions is greater.  This is particularly the case with
      increased node density, where node density should be considered
      relative to (the square of) the interference range rather than
      useful signal range. any Local Interface Tuple.

   o  The choice of MAXJITTER used when forwarding messages may also
      take into account the expected number of times that the message
      may be sequentially forwarded, up to the network diameter in hops.

Appendix E.  Utilizing Link Layer Information

   The interface between NHDP and  L_neighbor_iface_addr_list MUST NOT contain any protocol(s) using NHDP address which is through
   the Neighborhood Information Base as defined in Section 6.  The
   message exchange and associated processing specified
      in Section 9 and
   Section 10 allow fully maintaining this Neighborhood Information
   Base.

   Different link layers, and even different implementations the L_neighbor_iface_addr_list of any other Link Tuple in the
      same
   link layer, may make varying amount of information available
   describing local connectivity. Link Set.

   o  If present, such link layer
   information MAY L_HEARD_time has not expired then there MUST 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 Neighbor
      Tuple whose N_neighbor_iface_addr_list contains
      L_neighbor_iface_addr_list.

   o  L_HEARD_time MUST NOT be employed for populating all sets of
      the Neighborhood Information Base as defined in this
      specification.

   Failed data delivery  - greater than L_time.

   o  L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are
      expired).

   o  L_quality MUST NOT be less than 0 or greater than 1.

   o  If link layer information is available on a
      MANET interface, identifying when data delivery to a presumed
      directly connected node has failed, NHDP L_quality >= HYST_ACCEPT then L_pending MUST be employed for
      populating all sets of the Neighborhood Information Base as
      defined in this specification.  The link layer information MAY false.

   o  If L_quality < HYST_REJECT then L_status MUST be
      used to degrade a presumed directly connected node from being
      considered as SYMMETRIC to being considered HEARD PENDING or LOST.  A
      HELLO message reflecting these changes MAY be generated,
      respecting the considerations in Section 9.

   Link quality information  - The link layer may make available "soft"
      information (possibly derived from the physical layer) relating to
      the link quality.  NHDP MAY

   o  L_pending MUST NOT be able set to use this information, true if it is currently false.

   In each Neighbor Tuple:

   o  N_neighbor_iface_addr_list MUST NOT contain any address which is
      in a
      normalized form, to adjust the link status between LOST, HEARD and
      SYMMETRIC. I_local_iface_addr_list of any Local (1-hop) connectivity  - If link layer information Interface Tuple.

   o  N_neighbor_iface_addr_list MUST NOT contain any address which is available
      on a MANET interface, identifying
      in the local (1-hop) connectivity
      via that interface, N_neighbor_iface_addr_list of any other Neighbor Tuple.

   o  If N_symmetric == true, then this information MAY there MUST be used as follows
      when generating HELLO messages over that interface: one or more Link Tuples
      with:

      *  Step 1  L_neighbor_iface_addr_list contained in Hello Message Generation (Section 9) MAY
         N_neighbor_iface_addr_list; AND

      *  L_status == SYMMETRIC.

   o  If N_symmetric == false, then there MUST be ignored.
         This implies that local connectivity verification over that
         MANET interface is one or more Link
      Tuples with:

      *  L_neighbor_iface_addr_list contained in
         N_neighbor_iface_addr_list.

      All such Link Tuples MUST NOT have L_status == SYMMETRIC.  At
      least one such Link Tuple MUST have L_HEARD_time not performed by NHDP, but is using expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list
      of any Local Interface Tuple.

   o  NL_neighbor_iface_addr MUST NOT equal the link
         layer information.

      *  All NL_neighbor_iface_addr
      of any other steps in Hello Message Generation (Section 9) Lost Neighbor Tuple.

   o  NL_neighbor_iface_addr MUST NOT be
         carried out, such that Neighborhood Address Association Sets
         and 2-Hop in the
      N_neighbor_iface_addr_list of any Neighbor Sets can Tuple with N_symmetric
      == true.

   In each 2-Hop Tuple:

   o  There MUST be populated correctly.

      *  All a Link Tuple associated with the same MANET interfaces which do not have local (1-hop)
         connectivity information available
      interface with:

      *  L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND

      *  L_status == SYMMETRIC.

   o  N2_2hop_iface_addr MUST employ NOT be in the message
         exchange as detailed I_local_iface_addr_list of
      any Local Interface Tuple.

   o  N2_2hop_iface_addr MUST NOT be the N2_2hop_iface_addr of any other
      2-Hop Tuple in this specification. the same 2-Hop Set and with the same
      N2_neighbor_iface_addr_list.

   o  N2_2hop_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list
      of the same 2-Hop Tuple.

Appendix F. D.  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 message exchange between
   neighboring 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, injects invalid
   HELLO messages, incorrect information may be recorded in the sets
   maintained.  The protocol specification does, however, prevent
   inconsistent information from being injected in the protocol sets
   through the constraints in Appendix C.  The exact consequence of this
   information inexactness depends on the use of these sets, and MUST should
   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. D.1.  Invalid HELLO messages

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

   A node may provide false information 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 transmitting the HELLO message; message.

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

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

      *  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; transmitted.

   A node may provide false information about the identity of other
   nodes:

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

      *  A present LINK_STATUS TLV may, incorrectly, identify an address
         as being of a node MANET interface which is or was in heard on the sending node's 1-hop
         neighborhood;
         MANET interface over which the HELLO message is transmitted.

      *  A consistently absent LINK_STATUS TLV may, incorrectly, fail to
         identify an address as being of a node MANET interface which is or
         was in heard on the
         sending node's 1-hop neighborhood; MANET interface over which the HELLO message
         is transmitted.

      *  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;

      *  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;

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

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

Appendix G. E.  Flow and Congestion Control

   This document protocol specifies one message type, the HELLO message.  The
   maximum size of each complete a HELLO message is proportional to the size of the
   originating node's 1-hop neighborhood; some or all of this
   information on each of the node's MANET interfaces. neighborhood.  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  This puts a
   lower bound on the control traffic generated by each node in the
   network employing this neighborhood discovery protocol.

   A node MUST ensure that two successive HELLO messages sent on the
   same MANET interface are separated by at least HELLO_MIN_INTERVAL.
   (If using jitter then this may be reduced to 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
   employing this neighborhood discovery protocol.

Appendix H. F.  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 I. G.  Acknowledgements

   The authors would like to acknowledge the team behind OLSRv1,
   specified in RFC3626, RFC3626 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), 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/   http://www.ThomasClausen.org/

   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/   http://www.baesystems.com/

   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

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

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