Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                          LIX, Ecole Polytechnique, France
Intended status: Standards Track                             C. Dearlove
Expires: December 31, 2007 June 8, 2008                    BAE Systems Advanced Technology
                                                                  Centre
                                                                 J. Dean
                                               Naval Research Laboratory
                                                  The OLSRv2 Design Team
                                                     MANET Working Group
                                                           June 29,
                                                        December 6, 2007

              MANET Neighborhood Discovery Protocol (NHDP)
                        draft-ietf-manet-nhdp-04
                        draft-ietf-manet-nhdp-05

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on December 31, 2007. June 8, 2008.

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  . . . . . . . . . . . . . . . . . . .  7
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  8
     4.1.  Nodes and Interfaces . . . . . . . . . . . . . . . . . . .  8  9
     4.2.  Information Base Overview  . . . . . . . . . . . . . . . .  9
       4.2.1.  Local Information Base . . . . . . . . . . . . . . . .  9
       4.2.2.  Interface Information Bases  . . . . . . . . . . . . . 10
       4.2.3.  Node Information Base  . . . . . . . . . . . . . . . . 10
     4.3.  Signaling Overview . . . . . . . . . . . . . . . . . . . . 10 11
       4.3.1.  HELLO Message Generation . . . . . . . . . . . . . . . 10 11
       4.3.2.  HELLO Message Content  . . . . . . . . . . . . . . . . 11
       4.3.3.  HELLO Message Processing . . . . . . . . . . . . . . . 12
     4.4.  Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Protocol Parameters and Constants  . . . . . . . . . . . . . . 12 14
     5.1.  Interface Parameters . . . . . . . . . . . . . . . . . . . 12 14
       5.1.1.  Message Intervals  . . . . . . . . . . . . . . . . . . 12 14
       5.1.2.  Information Validity Times . . . . . . . . . . . . . . 13 15
       5.1.3.  Link Quality . . . . . . . . . . . . . . . . . . . . . 14 16
       5.1.4.  Jitter . . . . . . . . . . . . . . . . . . . . . . . . 14 16
     5.2.  Node Parameters  . . . . . . . . . . . . . . . . . . . . . 15 17
       5.2.1.  Information Validity Time  . . . . . . . . . . . . . . 15 17
     5.3.  Parameter Change Constraints . . . . . . . . . . . . . . . 15 17
     5.4.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . 16 18
   6.  Local Information Base . . . . . . . . . . . . . . . . . . . . 17 19
     6.1.  Local Interface Set  . . . . . . . . . . . . . . . . . . . 17 19
     6.2.  Removed Interface Address Set  . . . . . . . . . . . . . . 19
   7.  Interface Information Base . . . . . . . . . . . . . . . . . . 18 21
     7.1.  Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 18 21
     7.2.  2-Hop Set  . . . . . . . . . . . . . . . . . . . . . . . . 19 22
   8.  Node Information Base  . . . . . . . . . . . . . . . . . . . . 20 23
     8.1.  Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 20 23
     8.2.  Lost Neighbor Set  . . . . . . . . . . . . . . . . . . . . 20 23
   9.  Local Information Base Changes . . . . . . . . . . . . . . . . 21 24
     9.1.  Adding an Interface  . . . . . . . . . . . . . . . . . . . 21 24
     9.2.  Removing an Interface  . . . . . . . . . . . . . . . . . . 21 24
     9.3.  Adding an Address to an Interface  . . . . . . . . . . . . 22 25
     9.4.  Removing an Address from an Interface  . . . . . . . . . . 22 25
   10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 23 27
     10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 23 27
       10.1.1. Local Interface Block  . . . . . . . . . . . Address Blocks . . . . . 24
       10.1.2. Neighbor Address Blocks . . . . . . . . . . . . . . . 24 28
   11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 26 30
     11.1. HELLO Message Specification  . . . . . . . . . . . . . . . 26 30
     11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 27 32
       11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 27 32
   12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 29 33
     12.1. Updating the Neighbor Set  . . . . . . . . . . . . . . . . 29 34
     12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 31 35
     12.3. Updating the Link Set  . . . . . . . . . . . . . . . . . . 31 35
     12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 32 37
   13. Other Information Base Changes . . . . . . . . . . . . . . . . 34 39
     13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 34 39
     13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 35 40
     13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 36 41
   14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 42
     14.1. Deployment Without Link Quality  . . . . . . . . . . . . . 37 42
     14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 37 42
     14.3. When Link Quality Changes  . . . . . . . . . . . . . . . . 38 43
     14.4. Updating Link Quality  . . . . . . . . . . . . . . . . . . 39 44
   15. Proposed Values for Parameters and Constants . . . . . . . . . 40 45
     15.1. Message Interval Interface Parameters  . . . . . . . . . . 40 45
     15.2. Information Validity Time Interface Parameters . . . . . . 40 45
     15.3. Information Validity Time Node Parameters  . . . . . . . . 40 45
     15.4. Link Quality Interface Parameters  . . . . . . . . . . . . 40 45
     15.5. Jitter Interface Parameters  . . . . . . . . . . . . . . . 40 45
     15.6. Constants  . . . . . . . . . . . . . . . . . . . . . . . . 40 46
   16. IANA Security Considerations  . . . . . . . . . . . . . . . . . . . . . 41 47
     16.1. Message Types  . . Invalid HELLO messages . . . . . . . . . . . . . . . . . . 47
   17. IANA Considerations  . . 41
     16.2. TLV Types . . . . . . . . . . . . . . . . . . . 49
     17.1. Message Types  . . . . . 41
     16.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 42
   17. References . . . . . . 49
     17.2. TLV Types  . . . . . . . . . . . . . . . . . . . . . 43
     17.1. Normative References . . . 49
     17.3. LINK_STATUS and OTHER_NEIGHB Values  . . . . . . . . . . . 50
   18. References . . . . . . . 43
     17.2. Informative References . . . . . . . . . . . . . . . . . . 43
   Appendix A.   Address Block TLV Combinations . 51
     18.1. Normative References . . . . . . . . . . 44
   Appendix B.   HELLO Message Example . . . . . . . . . 51
     18.2. Informative References . . . . . . 45
   Appendix C.   Constraints . . . . . . . . . . . . 51
   Appendix A.  Address Block TLV Combinations  . . . . . . . . 47 . . . 52
   Appendix D.   Security Considerations B.  HELLO Message Example . . . . . . . . . . . . . . 49 . . 53
   Appendix D.1. Invalid HELLO messages C.  Constraints . . . . . . . . . . . . . . . 49 . . . . . . 56
   Appendix E. D.  Flow and Congestion Control . . . . . . . . . . . . 51 . 59
   Appendix F. E.  Contributors  . . . . . . . . . . . . . . . . . . . . 52 60
   Appendix G. F.  Acknowledgements  . . . . . . . . . . . . . . . . . . 53 61
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 62
   Intellectual Property and Copyright Statements . . . . . . . . . . 55 63

1.  Introduction

   This document describes a neighborhood discovery protocol (NHDP) for
   a mobile ad hoc network (MANET) [8].  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 neighbors.

   This protocol
   is designed to maintain this neighborhood information is recorded in the presence form of a dynamic
   network topology.

   The information maintained by this protocol Information
   Bases.  These may be used by other protocols, such as MANET routing
   protocols, for determining local connectivity and node configuration.
   This protocol is designed to maintain this information in the
   presence of a dynamic network topology.

   This specification describes both 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 broadcast or multicast.  Link layer
   information 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) [7].

2.  Terminology

   The keywords key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [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.

   Interface  - A network 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.

   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 heard by the other.

   Symmetric link  - A link where both MANET interfaces are heard by the
      other.

   1-hop neighbor  - A node X is a 1-hop neighbor of a node Y if a MANET
      interface of node X is heard by a MANET interface of node Y.

   Symmetric 1-hop neighbor  - A node X is a symmetric 1-hop neighbor of
      a node Y if a symmetric link exists between a MANET interface on
      node X 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 protocol:

   o  Is applicable to networks, especially wireless networks, in the MANET [8].  It provides
   each node which
      unknown neighbors (i.e. other nodes with which direct
      communication can be established) can be reached by local topology information up to two hops away.  This
   information is made available to other protocols through Interface
   Information Bases and a Node Information Base, described in Section 7
   and Section 8.

   The protocol is
      broadcast or multicast packets.

   o  Is designed to work in networks with a dynamic topology, and where in
      which messages may be lost, such as due to collisions in wireless
      networks.  If relevant link layer information is available then it

   o  Supports nodes that each have one or more participating MANET
      interfaces.  The set of a node's interfaces may be used by this protocol.

   This protocol is designed to work in a completely distributed manner, change over time.
      Each interface may have one or more interface addresses, and does not depend on any central entity.  It does these
      may also be dynamically changing.

   o  Does not require any changes to the format of IP packets, datagrams, thus
      any existing IP protocol stack can be used as is.  It can

   o  Can use the link local multicast address and MANET either the "manet"
      UDP port or the "manet" IP protocol number specified in [2].

   This protocol uses

   o  Uses the packet and message formats specified in [1].
   HELLO  Such
      packets may contain messages specified by this protocol as well as
      other protocols.

   o  Specifies signaling using HELLO messages.  The necessary contents
      of these messages are defined in this specification, and may be
      extended using the TLV mechanisms described in [1].  For example,

   o  Can use relevant link layer information if multipoint relays
   (MPRs) are to be calculated similarly it is available.

   o  Provides each node with local topology information up to as in OLSR [7] and signaled two hops
      away.  This information is made available to neighbors, then other protocols, of
      which this information protocol may be added a part, in Information Bases defined in
      this specification.

   o  Is designed to HELLO messages
   using an address block TLV.  HELLO messages can also be transmitted work in packets with messages from other protocols that also use [1]. a completely distributed manner, and does
      not depend on any central entity.

4.  Protocol Overview and Functioning

   This

   The objective of this protocol specifies is, for each node:

   o  To identify other nodes with which bidirectional links can be
      established (symmetric 1-hop neighbors).

   o  To agree on the status of such links with the corresponding
      symmetric 1-hop neighbor.

   o  To find the node's symmetric 2-hop neighbors.

   o  To record this information in Information Bases that can be used
      by other protocols, of which this neighborhood discovery protocol
      may be a part.

   These objectives are achieved using local (one hop) signaling that:

   o  Advertises the presence of a node and its interfaces.

   o  Discovers links from adjacent nodes.

   o  Performs bidirectionality checks on the discovered links.

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

   This specification defines, in turn:

   o  Maintains information bases describing discovered links, their
      MANET interface addresses  Parameters and status, current constants used by the protocol.  Parameters used by
      this protocol may be, where appropriate, specific to a MANET
      interface.  This protocol allows all parameters to be changed
      dynamically.

   o  The Information Bases describing local interfaces, discovered
      links and their status, current and former 1-hop neighbors, and
      symmetric 2-hop neighbors.

   o  The format of the HELLO message that is used for local signaling.

   o  The generation of HELLO messages from some of the information in
      the Information Bases.

   o  The updating of the Information Bases according to received HELLO
      messages and other events.

4.1.  Nodes and Interfaces

   In order for a node to participate in a MANET, it MUST have at least
   one, and possibly more, MANET interfaces.  Each MANET interface:

   o  Is characterized by a set of interface parameters, defining the
      behavior of this MANET interface.  Each MANET interface MAY be
      individually parameterized to accommodate the characteristics
      experienced and the behavior desired on that interface. parameterized.

   o  Has an Interface Information Base, recording information regarding
      links to this MANET interface and symmetric 2-hop neighbors which
      can be reached through such links.  Each MANET interface has its
      own Interface Information Base.

   o  Generates and processes HELLO messages, according to the interface
      parameters for that MANET interface.

   In addition to a set of MANET interfaces as described above, each
   node has:

   o  A Local Information Base, containing the IP addresses of the
      interfaces (MANET and non-MANET) of this node.  The contents of
      this Information Base are not changed by signaling.

   o  A Node Information Base, recording information regarding current
      and recently lost symmetric 1-hop neighbors of this node.

   A node may have both MANET interfaces and non-MANET interfaces.
   Interfaces of both of these types are recorded in a node's Local
   Information Base, which is used, but not updated, by the signaling of
   this protocol.

4.2.  Information Base Overview

   Each node maintains the Information Bases described in the following
   sections.  These are used for describing the protocol in this
   document.  An implementation of this protocol MAY maintain this
   information in the indicated form, or in any other organization which
   offers access to this information.

4.2.1.  Local Information Base

   Each node maintains a Local Information Base, which contains:

   o  The Local Interface Set, which consists of Local Interface Tuples,
      each of which records the addresses of an interface (MANET or non-
      MANET) of the node.

   o  The Removed Interface Address Set, which consists of Removed
      Interface Address Tuples, each of which records a recently used
      address of an interface (MANET or non-MANET) of the node.

4.2.2.  Interface Information Bases

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

   o  A Link Set, which consists of Link Tuples, each of which records information about a current or and recently
      lost link from a MANET links between this interface and MANET interfaces of a 1-hop neighbor to this MANET interface.  A
      neighbors.  The Link
      Tuple for Set consists of Link Tuples, each of which
      contains information about a single link.  Recently lost link is maintained for purposes of advertisement links are
      recorded so that they can be advertised in HELLO messages and hence accelerated messages,
      accelerating their removal of this link from
      the relevant 1-hop neighbors' Link
      Sets.  Link quality information, if used and available, may be is
      recorded in a Link
      Tuple; if this indicates that a link is of too low quality to be
      currently useable, then Tuples and may indicate that link is also links are treated as
      lost.

   o  A 2-Hop Set, which records the existence of bidirectional links
      between symmetric 1-hop neighbors of this MANET interface and
      other nodes (symmetric 2-hop neighbors).  The 2-Hop Set consists
      of 2-Hop Tuples, each of which records
      a MANET interface of a symmetric 1-hop neighbor, and an interface address of a
      symmetric 2-hop neighbor of this node.  The former MANET
      interface must have a symmetric link to this interface, neighbor, and all interface addresses of the
      former node must be a
      corresponding symmetric 1-hop neighbor of the latter node. neighbor.  The 2-Hop Set is updated
      by the signaling of this protocol, but is not itself reported in
      that signaling.

4.2.3.  Node Information Base

   Each node maintains a Node Information Base, which contains:

   o  The Neighbor Set, which records 1-hop neighbors, each of which
      must be currently heard, although this may be over a link with
      insufficient link quality.  The Neighbor Set consists of Neighbor
      Tuples, each of which records all interface addresses (whether
      directly linked or not) of a single 1-hop neighbor.  There MUST
      be a current link from a MANET interface of this 1-hop neighbor to
      a MANET interface of this node, although this link MAY be
      currently considered as lost due to insufficient link quality.  Neighbor
      Tuples are maintained in the Neighbor Set as long as there are corresponding current
      Link Tuples in the Link Set. A
      Neighbor Tuple allows all addresses of all interfaces of a 1-hop
      neighbors to be associated with each other, including addresses of
      interfaces not represented in the Link Set. Neighbor Tuples allow
      all addresses of interfaces of symmetric 1-hop neighbors to be
      included in HELLO messages on all MANET interfaces of this node. Tuples.

   o  The Lost Neighbor Set, which records recently lost symmetric 1-hop
      neighbors.  The Lost Neighbor Set consists of Lost Neighbor
      Tuples, each of which records an address of an interface address of such a recently
      lost symmetric 1-hop
      neighbor.  Lost Neighbor Tuples allow
      advertising such addresses as lost, in order  These are recorded so that these addresses they can be removed advertised in
      HELLO messages, accelerating their removal from other nodes' 2-Hop
      Sets.

   These sets are used for describing the protocol in this document.  An
   implementation of this protocol MAY maintain this information in the
   indicated form, or in any other organization which offers access to
   this information.

4.3.  Signaling Overview

   This protocol contains a signaling mechanism for maintaining the
   Interface Information Bases and the Node Information Base.  If
   information from the link layer, or any other source, is available
   and appropriate, it may also be used to update these. these Information
   Bases.  Such updates are subject to the constraints specified in
   Appendix C.

   Some links in a MANET 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 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 single type of message, known as a HELLO
   message.  Each node generates HELLO messages for on each of its MANET
   interfaces.  Each HELLO message identifies that MANET interface, and
   reports the other interfaces (MANET and non-MANET) of the node.  Each
   HELLO message includes information from the Link Set of the Interface
   Information Base of the MANET interface, and from the Node
   Information Base of
   the node. Base.

4.3.1.  HELLO Message Generation

   HELLO messages are generated by a node 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 the node itself, or its 1-hop
      neighborhood, for example on first becoming active or in response
      to a new, broken, or changed status link.

   o  In a combination of these proactive and responsive mechanisms.

   Jittering of HELLO message generation and transmission, as described
   in Section 11.2, MAY SHOULD be used if appropriate.

   HELLO messages are generated independently on each MANET interface of
   a node.  HELLO messages MAY be scheduled independently for each MANET
   interface, or, interface parameters permitting, using the same
   schedule for all MANET interfaces of a node.

4.3.2.  HELLO Message Content

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

   o  A HELLO message MUST contain all of the addresses in the Local
      Interface Set of the node to which the MANET interface belongs.

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

      *  All of the relevant information in the Link Set of the
         Interface Information Base of that MANET interface (other than link
         quality and information relating to pending links). interface.

      *  All of the relevant information in the Node Information Base of
         that node.

      This applies to otherwise purely responsive nodes as well as to
      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 include a VALIDITY_TIME message TLV that
      indicates the length of time for which the message content is to
      be considered valid, and included in the receiving node's
      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 period within
      which a further HELLO message is guaranteed to be sent on that
      MANET interface.

5.  Protocol Parameters and Constants

   The parameters and constants used

   o  Additional information may be added by a protocol using thsi
      protocol using the TLV mechanisms described in this specification [1].  For example,
      if multipoint relays (MPRs) are described to be calculated similarly to as
      in OLSR [7] and signaled to neighbors, then this section.

5.1.  Interface Parameters

   The interface parameters used by this specification information may
      be classified
   into the following four categories:

   o  Message intervals

   o  Information validity times

   o  Link quality

   o  Jitter

   These added to HELLO messages using an address block TLV.

4.3.3.  HELLO Message Processing

   All HELLO messages received by a node are detailed in the 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 used to update:

   o  The Interface Information Base for the constraints
   given in this section.  A particular case is where all MANET
   interfaces on all MANET nodes within a given MANET employ the same
   set of interface parameter values.

5.1.1.  Message Intervals

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

   HELLO messages serve two principal functions: is received.

   o  To advertise this nodes own addresses to its 1-hop neighbors.  The
      frequency of these advertisements is regulated by the interface
      parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. Node Information Base.

   Specifically:

   o  To advertise this nodes knowledge of each of its 1-hop neighbors.  The frequency of the advertisement of each such neighbor is
      regulated by the interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - node ensures that there is a single Neighbor Tuple
      corresponding to the maximum time between the transmission originator of two
      successive that HELLO messages on this MANET interface. message.

   o  If using
      periodic transmission of a Link Tuple corresponding to the link on which that HELLO messages, these SHOULD be at
      message was received exists, then its duration is extended,
      otherwise such a
      separation of HELLO_INTERVAL, possibly modified by jitter as
      specified in [4].

   HELLO_MIN_INTERVAL  - Link Tuple is created.  If the minimum interval between transmission of
      two successive HELLO messages, on this message
      indicates that the receiving MANET interface.  (This
      minimum interval MAY be modified by jitter, interface has been heard, then
      the link is considered symmetric, or its duration as defined in [4].)

   REFRESH_INTERVAL  - symmetric is
      extended.  If the maximum interval between advertisements in
      a HELLO message of each 1-hop neighbor address and its status. indicates that the receiving MANET
      interface is lost, then the link is no longer considered
      symmetric.  In
      all intervals of length REFRESH_INTERVAL, a node MUST include all
      1-hop neighbor information this case one or more Lost Neighbor Tuples may be
      created.

   o  If the link on which it the HELLO message is specified as sending received is symmetric,
      then any symmetrically advertised neighbors in at
      least one the HELLO message on this MANET interface.

   The following constraints apply
      are added to these interface parameters:

   o  HELLO_INTERVAL > 0

   o  HELLO_MIN_INTERVAL >= 0

   o  HELLO_INTERVAL >= HELLO_MIN_INTERVAL

   o  REFRESH_INTERVAL >= HELLO_INTERVAL

   o  If INTERVAL_TIME TLVs as defined in [3] the 2-Hop Set for the receiving interface, or if
      already present, the durations of the corresponding 2-Hop Tuples
      are included in HELLO
      messages, then HELLO_INTERVAL MUST be representable as described extended.

   In all cases the processing takes account of unexpected and erroneous
   information in [3].

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

   For a node to employ this protocol
   specified in Appendix C.

4.4.  Link Quality

   Some links in a purely responsive manner on a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both may be
   set marginal, e.g. due to a value adverse wireless
   propagation.  In order to avoid using such that marginal links, a responsive HELLO message link
   quality is always
   expected associated with each link in a shorter period than this.

5.1.2.  Information Validity Times

   The following interface parameters manage the validity time of Link Set, and links with
   insufficient link
   information:

   L_HOLD_TIME  - is quality are considered lost.  Modifying the period of advertisement, on this MANET
      interface, of former 1-hop neighbor addresses as lost in HELLO
      messages, allowing recipients link
   quality of these HELLO messages a link is OPTIONAL.  If link quality is not to
      accelerate removal of information from their Link Sets.
      L_HOLD_TIME can be modified
   it MUST be set to zero if accelerated indicate an always usable quality link.  Link
   quality information removal is not required.

   H_HOLD_TIME  - only used locally, it is not used as the value in
   signaling, and nodes may interoperate whether they are using the VALIDITY_TIME TLV included
   same, different, or no, link quality information.

5.  Protocol Parameters and Constants

   The parameters and constants used in all HELLO messages on this MANET interface. specification are described
   in this section.

5.1.  Interface Parameters

   The following constraints apply to these interface parameters: parameters used by this specification may be classified
   into the following four categories:

   o  L_HOLD_TIME >= 0  Message intervals

   o  H_HOLD_TIME >= REFRESH_INTERVAL  Information validity times

   o  If HELLO messages can be lost then both SHOULD be significantly
      greater than REFRESH_INTERVAL.  Link quality

   o  H_HOLD_TIME MUST be representable as described  Jitter

   These are detailed in [3].

5.1.3.  Link Quality

   The the following sections.

   Different MANET interfaces (on the same or on different nodes) MAY
   employ different interface parameters manage parameter values, and may change their
   interface parameter values dynamically, subject to the usage of link quality:

   HYST_ACCEPT  - constraints
   given in this section.  A particular case is the link quality threshold at or above which a link
      becomes usable, if it was not already so.

   HYST_REJECT  - is the link quality threshold below which where all MANET
   interfaces on all MANET nodes within a link
      becomes unusable, if it was not already so.

   INITIAL_QUALITY  - is given MANET employ the initial quality same
   set 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. interface parameter values.

5.1.1.  Message Intervals

   The following constraints apply to these interface parameters:

   o  0 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  0 <= INITIAL_QUALITY <= 1. parameters regulate HELLO message
   transmissions over a given MANET interface.

   HELLO messages serve two principal functions:

   o  If link quality  To advertise this node's own addresses to its 1-hop neighbors.
      The frequency of these advertisements is not updated, then INITIAL_QUALITY >=
      HYST_ACCEPT.

   o  If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false. regulated by the
      interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.

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

5.1.4.  Jitter

   If jitter, as defined in [4],  To advertise this node's knowledge of each of its 1-hop neighbors.
      The frequency of the advertisement of each such neighbor is used then
      regulated by the interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HP_MAXJITTER

   HELLO_INTERVAL  - represents is the value maximum time between the transmission of MAXJITTER used in [4] for
      periodically generated two
      successive HELLO messages on this MANET interface.

   HT_MAXJITTER  - represents the value  If using
      periodic transmission of MAXJITTER used in [4] for
      externally triggered HELLO messages on this MANET interface.

   For constraints on messages, these interface parameters see [4].

5.2.  Node Parameters

   Only one node parameter is defined SHOULD be at a
      separation of HELLO_INTERVAL, possibly modified by jitter as
      specified in [4].

   HELLO_MIN_INTERVAL  - is the minimum interval between transmission of
      two successive HELLO messages, on this specification, MANET interface.  (This
      minimum interval MAY be modified by jitter, as defined in [4].)

   REFRESH_INTERVAL  - is the
   category maximum interval between advertisements in
      a HELLO message of each 1-hop neighbor address and its status.  In
      all intervals of length REFRESH_INTERVAL, a node MUST include all
      1-hop neighbor information validity time.

5.2.1. which it is specified as sending in at
      least one HELLO message on this MANET interface.

   The following constraints apply to these interface parameters:

   o  HELLO_INTERVAL > 0

   o  HELLO_MIN_INTERVAL >= 0

   o  HELLO_INTERVAL >= HELLO_MIN_INTERVAL

   o  REFRESH_INTERVAL >= HELLO_INTERVAL

   o  If INTERVAL_TIME message TLVs as defined in [3] are included in
      HELLO messages, then HELLO_INTERVAL MUST be representable as
      described in [3].

   If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its
   neighbor advertisements between HELLO messages 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 value such that a responsive HELLO message is always
   expected in a shorter period than this.

5.1.2.  Information Validity Time Times

   The following node parameter manages interface parameters manage the validity time of lost
   symmetric 1-hop neighbor link
   information:

   N_HOLD_TIME

   L_HOLD_TIME  - is used as the period during which of advertisement, on this MANET
      interface, of former 1-hop neighbor addresses are advertised as lost in HELLO
      messages, allowing recipients of these HELLO messages to
      accelerate removal of information from their 2-Hop Link Sets.  N_HOLD_TIME
      L_HOLD_TIME can be set to zero if accelerated information removal
      is not required.

   The following constraint applies to this 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

   H_HOLD_TIME  - is used as the HELLO_INTERVAL for a MANET interface increases, then value in the
         next HELLO VALIDITY_TIME message on this MANET interface MUST be generated
         according to the previous, shorter, HELLO_INTERVAL.  Additional
         subsequent HELLO messages MAY be generated according to the
         previous, shorter, HELLO_INTERVAL.

      *  If the HELLO_INTERVAL for a MANET interface decreases, then the
         following TLV
      included in all HELLO messages on this MANET interface SHOULD be
         generated according interface.

   The following constraints apply to this current, shorter, HELLO_INTERVAL. these interface parameters:

   o  L_HOLD_TIME >= 0

   o  H_HOLD_TIME >= REFRESH_INTERVAL

      *

   o  If the REFRESH_INTERVAL for a MANET interface increases, then
         the content of subsequent HELLO messages must can be organized such
         that the specification of the old value of REFRESH_INTERVAL is
         satisfied for a further period equal to the old value of
         REFRESH_INTERVAL.

      *  If the REFRESH_INTERVAL for a MANET interface decreases, lost then
         it MAY both SHOULD be necessary to reschedule HELLO message generation on
         that MANET interface, significantly
      greater than REFRESH_INTERVAL.

   o  H_HOLD_TIME MUST be representable as described in order that [3].

5.1.3.  Link Quality

   The following interface parameters manage the specification usage of
         REFRESH_INTERVAL link quality:

   HYST_ACCEPT  - is satisfied from the time of change.

   HYST_ACCEPT and HYST_REJECT

      *  If HYST_ACCEPT link quality threshold at or above which a link
      becomes usable, if it was not already so.

   HYST_REJECT changes, then  - is the appropriate
         actions for link quality change, as specified in Section 14.3
         MUST be taken.

   L_HOLD_TIME

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

   N_HOLD_TIME

      *  If N_HOLD_TIME changes, then NL_time for all relevant Lost
         Neighbor Tuples SHOULD be changed.

   HP_MAXJITTER

      * threshold below which 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 these interface parameters:

   o  0 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  0 <= INITIAL_QUALITY <= 1.

   o  If HP_MAXJITTER changes, 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 periodic value of MAXJITTER used in [4] for
      periodically generated HELLO message
         schedule messages on this MANET interface MAY be changed.

   HT_MAXJITTER

      *  If interface.

   HT_MAXJITTER changes, then  - represents the value of MAXJITTER used in [4] for
      externally triggered HELLO messages on this MANET interface.

   For constraints on these interface MAY be rescheduled.

5.4.  Constants parameters see [4].

5.2.  Node Parameters

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

6.  Local Information Base

   A two node maintains a Local Information Base that records information
   about its local interfaces (MANET interfaces or otherwise).  Each
   such interface MUST have at least one address, and MAY have more than
   one address.  All addresses have an associated prefix length, which
   is included with all addresses parameters defined by this specification are in the Local
   category of information validity time.

5.2.1.  Information Base.  If an
   address otherwise does not have a prefix length then it Validity Time

   The following node parameter manages the validity time of lost
   symmetric 1-hop neighbor information:

   N_HOLD_TIME  - is considered
   to be equal to used as the address length.  Two period during which former 1-hop
      neighbor addresses are considered
   equal if and only if advertised as lost in HELLO messages,
      allowing recipients of these HELLO messages to accelerate removal
      of information from their associated prefix lengths are also equal.

   The Local Information Base 2-Hop Sets.  N_HOLD_TIME can be set to
      zero if accelerated information removal is not modified by this protocol.  This
   protocol MAY respond to changes of this Local Information Base which
   MUST reflect corresponding changes in the node's interface
   configuration.

6.1.  Local Interface Set

   A node's Local Interface Set records its local interfaces.  It
   consists of Local Interface Tuples, one per interface:

      (I_local_iface_addr_list, I_manet)

   where:

   I_local_iface_addr_list required.

   I_HOLD_TIME  - is a list of the addresses of this
      interface.

   I_manet  is period for which a boolean flag, describing if this recently used local
      interface address is a MANET
      interface.

7.  Interface Information Base

   A recorded.

   The following constraints applies to these node maintains an Interface Information Base parameters:

   o  N_HOLD_TIME >= 0

   o  I_HOLD_TIME >= 0

5.3.  Parameter Change Constraints

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

   HELLO_INTERVAL

      *  If the HELLO_INTERVAL for each of its a MANET
   interfaces.  This records information about links to that interface increases, then the
         next HELLO message on this MANET interface and symmetric 2-hop neighbors which can MUST be reached in two
   hops using those links as generated
         according to the first hop.  The Interface Information
   Base includes previous, shorter, HELLO_INTERVAL.  Additional
         subsequent HELLO messages MAY be generated according to the Link Set and
         previous, shorter, HELLO_INTERVAL.

      *  If the 2-Hop Set.

   A HELLO_INTERVAL for a MANET interface address can be present in both the Link Set and as
   of a symmetric 2-hop neighbor.  This allows decreases, then the node with
         following HELLO messages on this MANET interface address to MUST be immediately considered as a symmetric 2-hop
   neighbor if it fails
         generated according to be this current, shorter, HELLO_INTERVAL.

   REFRESH_INTERVAL

      *  If the REFRESH_INTERVAL for a symmetric 1-hop neighbor.

   All addresses MUST have an associated prefix length, which is
   included in all addresses in MANET interface increases, then
         the Interface Information Base.  Prefix
   lengths are indicated in content of subsequent HELLO messages using the PREFIX_LENGTH TLV
   specified in [1]; if an address has no must be organized such TLV, then its prefix
   length is equal to
         that the address length.  Two addresses are considered
   equal if and only if their associated prefix lengths are also equal.

7.1.  Link Set

   A node's Link Set records links from other nodes which are, or
   recently were, 1-hop neighbors.  It consists specification of Link Tuples, each
   representing a 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 the old value of REFRESH_INTERVAL is
         satisfied for a list of further period equal to the addresses old value of
         REFRESH_INTERVAL.

      *  If the REFRESH_INTERVAL for a MANET interface of decreases, then
         it MAY be necessary to reschedule HELLO message generation on
         that MANET interface, in order that the 1-hop neighbor;

   L_HEARD_time specification of
         REFRESH_INTERVAL is satisfied from the time until which the MANET interface of change.

   HYST_ACCEPT and HYST_REJECT

      *  If HYST_ACCEPT or HYST_REJECT changes, then the
      1-hop neighbor would be considered heard if not considering link
      quality;

   L_SYM_time  is the time until which the link to the 1-hop neighbor
      would be considered symmetric if not considering appropriate
         actions for link quality;

   L_quality  is a dimensionless number between 0 (inclusive) and 1
      (inclusive) describing the quality of a link; a greater value of
      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 yet established, link);

   L_lost  is a boolean flag, describing if a link is considered lost
      due to link quality; change, as specified in Section 14.3
         MUST be taken.

   L_HOLD_TIME

      *  If L_HOLD_TIME changes, then L_time  specifies when this Tuple expires and for all relevant Link
         Tuples MUST be removed.

   The status of changed.

   N_HOLD_TIME

      *  If N_HOLD_TIME changes, then NL_time for all relevant Lost
         Neighbor Tuples MUST be changed.

   HP_MAXJITTER

      *  If HP_MAXJITTER changes, then the link, as obtained through periodic HELLO message exchange,
   and also taking link quality into account, denoted L_status, is
   defined by:

   1.
         schedule on this MANET interface MAY be changed.

   HT_MAXJITTER

      *  If L_pending is true, then L_status = PENDING;

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

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

   4.  otherwise, if L_HEARD_time externally triggered HELLO
         messages on this MANET interface MAY be rescheduled.

5.4.  Constants

   The constant C is not expired, then L_status = HEARD;

   5.  otherwise, L_status = LOST.

7.2.  2-Hop  Set used as specified in [3].

6.  Local Information Base

   A node's 2-Hop Set records symmetric 2-hop neighbors, and the
   symmetric links to symmetric 1-hop neighbors through which the
   symmetric 2-hop neighbors can be reached.  It consists of 2-Hop
   Tuples, each representing a single interface address of a symmetric
   2-hop neighbor, and a single MANET interface of a symmetric 1-hop
   neighbor.

      (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)

   where:

   N2_neighbor_iface_addr_list  is a list of the addresses of the MANET
      interface of the symmetric 1-hop neighbor from which 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 the indicated symmetric 1-hop neighbor;

   N2_time  specifies when this Tuple expires and MUST be removed.

8.  Node Information Base

   Each node maintains a Node Local Information Base that records information
   about addresses of current its interfaces (MANET and recently symmetric 1-hop neighbors. non-MANET).  Each interface MUST have
   at least one address, and MAY have more than one address.

   All addresses MUST have an associated prefix length, which is
   included in all addresses in the Node Information Base.  Prefix
   lengths are indicated in HELLO messages using the PREFIX_LENGTH TLV
   specified in [1]; if length.  If an address
   has no such TLV, specified prefix length, then its prefix length is equal to
   the address length.  Two addresses are considered equal if and only
   if their associated prefix lengths are also equal.

8.1.  Neighbor

   The Local Information Base is not modified by signaling.  This
   protocol responds to changes to this Local Information Base which
   MUST reflect corresponding changes in the node's interface
   configuration.

6.1.  Local Interface Set

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

      (N_neighbor_iface_addr_list, N_symmetric) one per interface:

      (I_local_iface_addr_list, I_manet)

   where:

   N_neighbor_iface_addr_list

   I_local_iface_addr_list  is a list of the interface addresses of a
      1-hop neighbor;

   N_symmetric this
      interface.

   I_manet  is a boolean flag, describing if this interface is a symmetric
      1-hop neighbor.

8.2.  Lost Neighbor MANET
      interface.

6.2.  Removed Interface Address Set

   A node's Lost Neighbor Removed Interface Address Set records addresses of all interfaces of
   nodes which recently were symmetric 1-hop neighbors, but
   recently local interface addresses.  If a node's interface addresses
   are now
   advertised as lost. immutable then this set is always empty and MAY be omitted.  It
   consists of Lost Neighbor Removed Interface Address Tuples, each
   representing a single such one per address:

      (NL_neighbor_iface_addr, NL_time)

      (IR_local_iface_addr, IR_time)

   where:

   NL_neighbor_iface_addr

   IR_local_iface_addr  is an a recently used address of an interface of a node which
      recently was a symmetric 1-hop neighbor of
      this node;

   NL_time node.

   IR_time  specifies when this Tuple expires and MUST be removed.

9.  Local

7.  Interface Information Base Changes

   The Local

   A node maintains an Interface Information Base MUST change to respond for each of its MANET
   interfaces.  This records information about links to changes that MANET
   interface and symmetric 2-hop neighbors which can be reached in two
   hops using those links as the
   node's interfaces. first hop.  The node MUST update its Interface and Node Information Bases in response to such changes.  If any changes in
   Base includes the
   Interface Link Set and Node Information Bases satisfy any of the conditions
   described in Section 13, then those changes must be applied
   immediately, unless noted otherwise. 2-Hop Set.

   A node MAY transmit HELLO messages in response to these changes.

9.1.  Adding an Interface

   If an MANET interface is added to the node then this is indicated by address can be present in both the
   addition Link Set and as
   of a Local Interface Tuple to the Local Interface Set. If symmetric 2-hop neighbor.  This allows the new interface is a MANET interface then an initially empty
   Interface Information Base MUST be created for node with this new MANET
   interface.  The actions in Section 9.3 MUST be taken for each
   interface address
   of the added interface.  A HELLO message MAY to be sent on all MANET
   interfaces, it SHOULD be sent on the new interface immediately considered as a symmetric 2-hop
   neighbor if it is a MANET
   interface.  If using scheduled messages, then a message schedule MUST fails to be established on a new MANET interface.

9.2.  Removing symmetric 1-hop neighbor.

   All addresses MUST have an Interface

   If a MANET interface associated prefix length.  Prefix lengths
   are indicated in HELLO messages as specified in [1]; if an address
   has no specified prefix length, then its prefix length is removed equal to
   the address length.  Two addresses are considered equal if and only
   if their associated prefix lengths are also equal.

7.1.  Link Set

   A node's Link Set records links from other nodes which are, or
   recently were, 1-hop neighbors.  It consists of Link Tuples, each
   representing a 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 list of the node, then this MUST result
   in removal addresses of information from the Local Information Base and MANET
      interface of the
   Neighborhood Information Base as follows:

   1.  Remove 1-hop neighbor;

   L_HEARD_time  is the Local Interface Tuple that corresponds to time until which the MANET interface to of the
      1-hop neighbor would be removed from considered heard if not considering link
      quality;

   L_SYM_time  is the Local Interface Set.

   2.  If time until which the interface link to the 1-hop neighbor
      would be removed considered symmetric if not considering link quality;

   L_quality  is a MANET interface (i.e. with
       I_manet == true) then:

       1.  Remove dimensionless number between 0 (inclusive) and 1
      (inclusive) describing the Interface Information Base for that MANET
           interface;

       2.  All Neighbor Tuples for which none quality of the addresses in its
           N_neighbor_iface_addr_list are found in any
           L_neighbor_iface_addr_list in any remaining Link Set, are
           removed.

   If a node removes the Local Interface Tuple that contains the
   interface address that link; a greater value of
      L_quality indicating a higher quality link;

   L_pending  is used 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 is considered lost
      due to define link quality;

   L_time  specifies when this Tuple expires and MUST be removed.

   The status of the node's originator
   address, link, as obtained through HELLO message exchange,
   and also taking link quality into account, denoted L_status, is
   defined in [1], 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_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 node MAY change originator
   address.

   If
   symmetric links to symmetric 1-hop neighbors through which the removed
   symmetric 2-hop neighbors can be reached.  It consists of 2-Hop
   Tuples, each representing a single interface address of a symmetric
   2-hop neighbor, and a single MANET interface of a symmetric 1-hop
   neighbor.

      (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)

   where:

   N2_neighbor_iface_addr_list  is a list of the addresses of the last MANET
      interface of the node,
   then there will be no remaining Interface Information Bases, and the
   node will longer participate in symmetric 1-hop neighbor from which this protocol.

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

9.3.  Adding an Address to an Interface

   If
      information was received;

   N2_2hop_iface_addr  is an address is added to of an interface then this is indicated by the
   addition of an address a symmetric
      2-hop neighbor which has a symmetric link (using any MANET
      interface) to the appropriate I_local_iface_addr_list.
   The following changes indicated symmetric 1-hop neighbor;

   N2_time  specifies when this Tuple expires and MUST be made to the removed.

8.  Node Information Bases:

   1.  The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list
       contains the added address, Base

   Each node maintains a Node Information Base that records information
   about addresses of current and recently symmetric 1-hop neighbors.

   All addresses MUST have an associated prefix length.  Prefix lengths
   are removed.

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

       *  the added address; OR

       *  any address HELLO messages as specified in the N_neighbor_iface_addr_list of the removed
          Neighbor Tuples, [1]; if any

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

   3.  Any Lost Neighbor Tuples whose NL_neighb_iface_addr an address
   has no specified prefix length, then its prefix length is equal to
   the added
       address, address length.  Two addresses are removed.

   4.  Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address, considered equal if and only
   if their associated prefix lengths are removed. also equal.

8.1.  Neighbor Set

   A HELLO message MAY be sent on node's Neighbor Set records all MANET interfaces.

9.4.  Removing an Address from an Interface

   If an address is removed from an interface then this addresses of each 1-hop
   neighbor.  It consists of Neighbor Tuples, each representing a single
   1-hop neighbor:

      (N_neighbor_iface_addr_list, N_symmetric)

   where:

   N_neighbor_iface_addr_list  is indicated by a list of the removal interface addresses of an address from the appropriate
   I_local_iface_addr_list.  If a
      1-hop neighbor;

   N_symmetric  is a boolean flag, describing if this list is 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 empty then the
   corresponding Local Interface
   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 an interface of a node which
      recently was a symmetric 1-hop neighbor of this node;

   NL_time  specifies when this Tuple expires and MUST be removed.

   If a node removes

9.  Local Information Base Changes

   The Local Information Base MUST change to respond to changes in the
   node's local interface address that is used configuration.  The node MUST update its
   Interface and Node Information Bases in response to define such changes.  If
   any changes in the
   node's originator address, as defined Interface and Node Information Bases satisfy any
   of the conditions described in [1], Section 13, then the those changes must be
   applied immediately, unless noted otherwise.

   A node MAY
   change originator address. transmit HELLO messages in response to these changes.

9.1.  Adding an Interface

   If an interface is added to the node then this is indicated by the
   addition of a Local Interface Tuple to the Local Interface Set. If
   the new interface is 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 this added interface.  A HELLO message MAY be sent on all MANET interfaces.

10.  Packets and Messages

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

   o  This protocol specifies one message type,
   interfaces, it SHOULD be sent on the HELLO message.

   o  HELLO new interface if it is a MANET
   interface.  If using scheduled messages, then a message header options MAY schedule MUST
   be used as specified by established on a
      protocol which uses new MANET interface.

9.2.  Removing an Interface

   If an interface is removed from the node, then this neighborhood discovery protocol.

   o  HELLO messages MUST NOT be forwarded.

   o  HELLO messages MAY be included result in multi-message packets
   changes to the Local Information Base and the Node Information Base
   as
      specified in [1].

   o  Packet header options MAY follows:

   1.  Identify the Local Interface Tuple that corresponds to the
       interface to be used as specified by a protocol which
      uses this neighborhood discovery protocol.

   o  This protocol specifies three address block TLVs.  It also uses
      two message TLVs defined in [3] and one removed.

   2.  For each address block TLV defined (henceforth removed address) in [1].  These six TLV types are all defined only with Subtype ==
      0.  TLVs of other types, and the
       I_local_iface_addr_list of these types but without Subtype ==
      0, are ignored by this protocol.  All references in this protocol
      to, for example, that Local Interface Tuple, create a TLV with Type == LINK_STATUS, are
       Removed Interface Address Tuple with:

       *  IR_local_iface_addr = removed address;

       *  IR_time = current time + I_HOLD_TIME.

   3.  Remove that Local Interface Tuple from the Local Interface Set.

   4.  If the interface to be
      considered as referring to removed is a TLV with Type == LINK_STATUS and
      Subtype MANET interface (i.e. with
       I_manet == 0.

10.1.  HELLO Messages

   A HELLO message MUST contain:

   o  A VALIDITY_TIME message TLV as specified in [3], representing
      H_HOLD_TIME for true) then:

       1.  Remove the transmitting Interface Information Base for that MANET interface.

   o  An address block, with an associated TLV block, known as
           interface;
       2.  All Neighbor Tuples for which none of the addresses in its
           N_neighbor_iface_addr_list are found in any
           L_neighbor_iface_addr_list in any remaining Link Set, are
           removed.

   If a node removes the Local Interface Block, as specified in Section 10.1.1.

   A HELLO message which Tuple that contains the
   interface address that is transmitted periodically SHOULD contain, and
   otherwise MAY contain:

   o  An INTERVAL_TIME message TLV used to define the node's originator
   address, as specified defined in [3], representing
      HELLO_INTERVAL for [1], then the transmitting node MAY change originator
   address.

   If the removed interface is the last MANET interface. interface of the node,
   then there will be no remaining Interface Information Bases, and the
   node will longer participate in this protocol.

   A HELLO message MAY contain:

   o  One or more address blocks, each with be sent on all remaining MANET interfaces.

9.3.  Adding an associated TLV block,
      known as Neighbor Address Blocks, as specified in Section 10.1.2.

   o  Other message TLVs.

10.1.1.  Local to an Interface Block

   The first

   If an address block, plus following TLV block, in a HELLO message is known as the Local Interface Block.  The Local Interface Block added to an interface then this is
   not distinguished in any way other than indicated by being the first
   addition of an address
   block in to the HELLO message. appropriate I_local_iface_addr_list.
   The Local Interface Block following changes MUST contain all of be made to the addresses in that
   node's Local Interface Set. Those addresses, Information Bases:

   1.  The Neighbor Tuples, if any, which correspond
   to interfaces other than whose N_neighbor_iface_addr_list
       contains the MANET interface for which added address, are removed.

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

       *  the HELLO
   message is transmitted MUST be associated with a corresponding TLV
   with Type == OTHER_IF as specified added address; OR

       *  any address in Table 1.  Addresses the N_neighbor_iface_addr_list of the
   MANET interface on which removed
          Neighbor Tuples, if any

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

   3.  Any Lost Neighbor Tuples whose NL_neighbor_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 from an Interface

   If an address (henceforth removed address) is transmitted removed from an
   interface then this is indicated by the removal of that address from
   the appropriate I_local_iface_addr_list.  If this list is now empty
   then the corresponding Local Interface Tuple MUST NOT be
   associated with such a TLV.

   Note that removed.

   Create a Local Removed Interface Block MAY include more than one address
   for each MANET interface, and hence Address Tuple with:

   o  IR_local_iface_addr = removed address;

   o  IR_time = current time + I_HOLD_TIME.

   If a HELLO message MAY contain more
   than one node removes the interface address without an OTHER_IF TLV.

   +----------+--------+-----------------------------------------------+
   |   Name   |  Value | Description                                   |
   |          | Length |                                               |
   +----------+--------+-----------------------------------------------+
   | OTHER_IF | 0 bits | Specifies that is used to define the
   node's originator address, as defined in [1], then the Local      |
   |          |        | Interface Block of the message, is an address |
   |          |        | associated with an interface other than the   |
   |          |        | MANET interface node MAY
   change originator address.

   A HELLO message MAY be sent on which the all MANET interfaces.

10.  Packets and Messages

   The packet and message format used by this protocol is       |
   |          |        | transmitted                                   |
   +----------+--------+-----------------------------------------------+

                                  Table 1

10.1.2.  Neighbor Address Blocks

   Address blocks, each defined in
   [1], which is used with a the following TLV block, in considerations:

   o  This protocol specifies one message type, the HELLO message.

   o  HELLO message header options MAY be used as specified by a
      protocol which uses this neighborhood discovery protocol.

   o  HELLO message,
   after the Local Interface Block, are known messages MUST NOT be forwarded.

   o  HELLO messages MAY be included in multi-message packets as Neighbor Address
   Blocks.  These Neighbor Address Blocks are not distinguished
      specified in any
   way other than [1].

   o  Packet header options MAY be used as specified by not being the first address block in the a protocol which
      uses this neighborhood discovery protocol.

   o  Received HELLO
   message. messages MUST be parsed in accordance with [1].  A
      HELLO message MAY contain no Neighbor Address Blocks.

   A Neighbor Address Block contains current or recently lost 1-hop
   neighbors' interface addresses, each of which is associated not in conformance with [1] MUST be
      discarded.

   o  This protocol specifies three address block TLVs.  It also uses
      two message TLVs as described in Table 2.  Other addresses MAY be
   included defined in Neighbor Address Blocks, but MUST NOT be associated [3].  These five TLV types are all
      defined only with
   any of the Type Extension == 0.  TLVs specified in Table 2.

   +--------------+--------+-------------------------------------------+
   |     Name     |  Value | Description                               |
   |              | Length |                                           |
   +--------------+--------+-------------------------------------------+
   |  LINK_STATUS | 8 bits | Specifies the status of the link from the |
   |              |        | indicated address (LOST, SYMMETRIC or     |
   |              |        | HEARD)                                    |
   |              |        |                                           |
   | OTHER_NEIGHB | 8 bits | Specifies that the address is (SYMMETRIC) |
   |              |        | or was (LOST) of an interface of a        |
   |              |        | symmetric 1-hop neighbor other types, and
      of the node      |
   |              |        | transmitting the HELLO message            |
   +--------------+--------+-------------------------------------------+

                                  Table 2

   A TLV with these types but without Type Extension == LINK_STATUS and (Value == SYMMETRIC or Value ==
   LOST) also performs the function of 0, are ignored by
      this protocol.  All references in this protocol to, for example, a
      TLV with Type == OTHER_IF and
   the same value.  The latter SHOULD NOT also LINK_STATUS, are to be included.  If considered as referring to
      a TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with a
   TLV with Type Extension == OTHER_IF and Value == LOST then the latter MUST be
   ignored, and SHOULD NOT be included.  See Appendix A.

11. 0.

10.1.  HELLO Message Generation

   Each MANET interface MUST generate Messages

   A HELLO messages according to message MUST contain:

   o  A VALIDITY_TIME message TLV as specified in [3], representing
      H_HOLD_TIME for the
   specification transmitting MANET interface.  The options
      included in this section.  HELLO message generation [3] for representing zero and
   scheduling infinite times MUST NOT
      be according to the interface parameters for that
   MANET interface used.

   A HELLO message which is transmitted periodically SHOULD contain, and
   otherwise MAY be independent contain:

   o  An INTERVAL_TIME message TLV as specified in [3], representing
      HELLO_INTERVAL for each the transmitting 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 interface.  The options
      included in [3] for representing zero and infinite times MUST NOT
      be transmitted on the same MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive used.

   A HELLO message
   transmissions on the same MANET interface MUST be separated by at
   least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.

11.1.  HELLO Message Specification

   HELLO messages are generated independently on MAY contain:

   o  One or more address blocks, each MANET interface.

   A HELLO with an associated TLV block.

   o  Other message MUST include TLVs.

10.1.1.  Address Blocks

   All addresses in a node's Local Interface Block, as specified Set (i.e. in
   Section 10.1.1, as its first address block.

   Other addresses which any
   I_local_iface_addr_list) MUST be included in Neighbor Address Blocks, as
   specified in Section 10.1.2, the address blocks in
   all generated HELLO messages sent over a given
   MANET interface are:

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

   o  Other addresses of symmetric 1-hop neighbors from following exception.  If 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 on which the Interface Information Base for this MANET interface.
      (These are advertised for a period equal HELLO message is to this interface's
      L_HOLD_TIME after loss.)

   o  Other be sent has a single
   interface address with maximum prefix length then that address MAY be
   omitted.  All addresses of previously symmetric 1-hop neighbors from the
      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 interfaces included in
   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 = 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 == true, and which has not already been included with
       an block MUST be associated TLV with (Type == LINK_STATUS and Value ==
       SYMMETRIC), include the neighbor address with an associated a TLV
       with:

       * with Type = OTHER_NEIGHB; AND

       * == LOCAL_IF, as
   defined in Table 1.

   +----------+--------+-----------------------------------------------+
   |   Name   |  Value = SYMMETRIC.

   3.  For each Lost Neighbor Tuple whose NL_neighbor_iface_addr
       (henceforth lost address) has not already been included, include | Description                                   |
   |          | Length |                                               |
   +----------+--------+-----------------------------------------------+
   | LOCAL_IF | 8 bits | Specifies that the lost address with an associated TLV with:

       *  Type = OTHER_NEIGHB; AND

       *  Value = LOST.

   If is an address is specified with more than one associated TLV, then
   these TLVs MAY be independently included or excluded from each HELLO
   message.  Each such TLV MUST be included      |
   |          |        | associated with that address
   in a HELLO the interface on which the    |
   |          |        | message was sent on that MANET (THIS_IF), another interface in every interval |
   |          |        | of
   length equal to the sending node (OTHER_IF), or an         |
   |          |        | unspecified interface of the sending node     |
   |          |        | (UNSPEC_IF).                                  |
   +----------+--------+-----------------------------------------------+

                                  Table 1

   Note that MANET interface's parameter REFRESH_INTERVAL.
   TLVs the value UNSPEC_IF is not used by this protocol.

   Address blocks MAY contain current or recently lost 1-hop neighbors'
   interface addresses, each of which is associated with the same address included block
   TLVs as described in Table 2.

   +--------------+--------+-------------------------------------------+
   |     Name     |  Value | Description                               |
   |              | Length |                                           |
   +--------------+--------+-------------------------------------------+
   |  LINK_STATUS | 8 bits | Specifies the same HELLO
   message MAY be applied to status of the same link from the |
   |              |        | indicated address (LOST, SYMMETRIC or different copies of     |
   |              |        | HEARD).                                   |
   |              |        |                                           |
   | OTHER_NEIGHB | 8 bits | Specifies that
   address.

11.2.  HELLO Message Transmission

   HELLO messages are transmitted in the packet/message format specified
   by [1] using the "LL MANET Routers" multicast address specified by
   [2] as destination IP address, using is (SYMMETRIC) |
   |              |        | or was (LOST) of an interface of a        |
   |              |        | symmetric 1-hop neighbor of the node      |
   |              |        | transmitting the MANET UDP port specified in
   [2].

11.2.1.  HELLO Message Jitter HELLO messages MAY be sent using periodic message generation message.           |
   +--------------+--------+-------------------------------------------+

                                  Table 2

   A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or
   externally triggered message generation.  If using data link Value ==
   LOST) also performs the function of a TLV with Type == OTHER_NEIGHB
   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 the same value.  The latter SHOULD NOT also be included.  If a change in
   local interfaces) MAY
   TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with
   a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter
   MUST be treated as if externally generated message
   generation, or ignored, and SHOULD NOT be included.  See Appendix A.

   Other addresses MAY be not jittered.

   HELLO messages included in address blocks, but MUST NOT be forwarded, and thus message forwarding
   jitter does not apply to
   associated with any of the TLVs specified in this section.

11.  HELLO messages. Message Generation

   Each form of jitter described MANET interface MUST generate HELLO messages according to the
   specification in [4] requires a parameter MAXJITTER.
   These this section.  HELLO message generation and
   scheduling MUST be according to the interface parameters may be dynamic, for that
   MANET interface and are specified by:

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

   o  For externally triggered message generation: HT_MAXJITTER. independent for each MANET interface or,
   interface parameters permitting, MANET interfaces MAY use the same
   schedule.

   If transmitting periodic HELLO messages are also periodically generated, then HT_MAXJITTER
      also MUST be significantly less than HELLO_INTERVAL.

   When then, following a HELLO
   message generation is delayed in order that transmission on a MANET interface, another HELLO message is not sent within HELLO_MIN_INTERVAL of MUST
   be transmitted on the previous same MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive HELLO message
   transmissions on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
   be reduced by jitter, with maximum reduction HP_MAXJITTER.  In this
   case HP_MAXJITTER interface MUST NOT be greater than HELLO_MIN_INTERVAL.

12. separated by at
   least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.

11.1.  HELLO Message Processing

   On receiving a Specification

   HELLO message, a node MUST first check if any address
   in its Local Interface Block is one of its interface messages are generated independently on each MANET interface.

   All addresses (i.e.
   is in any I_local_iface_addr_list in the Local Interface Set). MUST be included, except
   that:

   o  If so
   then the interface on which the HELLO message MUST is to be discarded.

   Otherwise the receiving node sent has a
      single interface address with maximum prefix length then that
      interface address MAY be omitted.

   All such included addresses MUST update its appropriate Interface
   Information Base be associated with a TLV with Type
   == LOCAL_IF and its Node Information Base value according to this
   section. the following:

   o  If any changes satisfy any the address is of the conditions described in
   Section 13 sending interface, then the indicated consequences MUST Value == THIS_IF.

   o  Otherwise, Value == OTHER_IF.

   The following addresses of current or former 1-hop neighbors MAY be applied
   immediately, unless noted otherwise.

   For
   included in any HELLO message:

   o  Addresses of MANET interfaces of 1-hop neighbors from the purpose Link Set
      of this section, note the following definitions: Interface Information Base for this MANET interface.

   o  "validity time" is calculated  Other addresses of symmetric 1-hop neighbors from the VALIDITY_TIME TLV Neighbor Set
      of the
      HELLO message as specified in [3]. this node's Node Information Base.

   o  "Receiving Address List" is the I_local_iface_addr_list
      corresponding to the  Addresses of MANET interface interfaces of previously symmetric or heard
      1-hop neighbors connected on which the HELLO message
      was received

   o  "Neighbor Address List" is this MANET interface from the list Link
      Set of the addresses contained in
      the Local Interface Block of the HELLO message. Information Base for this MANET interface.
      (These are advertised for a period equal to this interface's
      L_HOLD_TIME after loss.)
   o  "Sending Address List" is  Other addresses of previously symmetric 1-hop neighbors from the list
      Lost Neighbor Set of this node's Node Information Base.  (These
      are advertised for a period equal to N_HOLD_TIME after loss.)

   Each such address MUST be associated with one or more appropriate
   TLVs, respecting the addresses contained parameter REFRESH_INTERVAL for each association
   for each MANET interface.  Specifically:

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

       *  Type == OTHER_IF.

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

   o  "Removed Address List" is a list of addresses created by this
      HELLO message processing = LINK_STATUS; AND

       *  Value = L_status.

   2.  For each address (henceforth neighbor address) which were formerly reported as local by
      the node originating the HELLO message, but appears in
       an N_neighbor_iface_addr_list in a Neighbor Tuple with
       N_symmetric == true, and which are has not already been included
      in with
       an associated TLV with (Type == LINK_STATUS and Value ==
       SYMMETRIC), include the neighbor address with an associated TLV
       with:

       *  Type = OTHER_NEIGHB; AND

       *  Value = SYMMETRIC.

   3.  For each Lost Neighbor Address List.  This list is initialized as empty.

   o  "Lost Address List" is a subset of the Removed Address List
      containing addresses which were formerly considered as symmetric.
      This list is initialized as empty.

12.1.  Updating the Neighbor Set

   On receiving a HELLO message, the node MUST update its Neighbor Set
   and populate Tuple whose NL_neighbor_iface_addr
       (henceforth lost address) has not already been included, include
       the Removed Address List and Lost Address List:

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

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

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

       1.  Create a new Neighbor Tuple with an associated TLV with:

           +  N_neighbor_iface_addr_list

       *  Type = Neighbor Address List;

           +  N_symmetric OTHER_NEIGHB; AND

       *  Value = false.

   3. LOST.

   If there a 1-hop neighbor address is specified with more than one matching Neighbor Tuple, then:

       1.  If the N_neighbor_iface_addr_list
   associated TLV, then these TLVs MAY be independently included or
   excluded from each HELLO message.  Each such TLV MUST be included
   associated with that address in a HELLO message sent on that MANET
   interface in every interval of the matching Neighbor
           Tuple is not length equal to that MANET interface's
   parameter REFRESH_INTERVAL.  TLVs associated with the Neighbor Address List, then:

           1.  For each same address (henceforth removed address) which is
   included in the N_neighbor_iface_addr_list, but not same HELLO message MAY be applied to the same or
   different copies of that address.

11.2.  HELLO Message Transmission

   HELLO messages are transmitted in the Neighbor
               Address List:

               1.  Add packet/message format specified
   by [1] using the removed "LL-MANET-Routers" multicast address to specified by
   [2] as destination IP address, using either the Removed Address List.

               2.  If N_symmetric == true, then add "manet" UDP port, or
   the removed address
                   to the Lost Address List.

           2.  Update the matching Neighbor Tuple by:

               -  N_neighbor_iface_addr_list = Neighbor Address List.

   4. "manet" IP protocol number specified in [2].

11.2.1.  HELLO Message Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If there using data link and
   physical layers which are two 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 change in
   local interfaces) MAY be treated as if externally generated message
   generation, or more matching Neighbor Tuples, then:

       1. MAY be not jittered.

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

   Each form of jitter described in [4] requires a parameter MAXJITTER.
   These interface parameters may be dynamic, and are specified by:

   o  For each address (henceforth removed address) which periodic message generation: HP_MAXJITTER.

   o  For externally triggered message generation: HT_MAXJITTER.

   When HELLO message generation is delayed in the
           N_neighbor_iface_addr_list of any order that a HELLO
   message is not sent within HELLO_MIN_INTERVAL of the matching Neighbor
           Tuples:

           1.  Add the removed address to previous HELLO
   message on the Removed Address List.

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

       2.  Replace the matching Neighbor Tuples HELLO_MIN_INTERVAL SHOULD
   be reduced by a single Neighbor
           Tuple with:

           +  N_neighbor_iface_addr_list = Neighbor Address List;

           +  N_symmetric = false

12.2.  Updating the Lost Neighbor Set

   On receiving a HELLO message, a node jitter, with maximum reduction HP_MAXJITTER.  In this
   case HP_MAXJITTER MUST update its Lost Neighbor
   Set:

   1.  For each address (henceforth lost address) in the Lost Neighbor
       List, NOT be greater than HELLO_MIN_INTERVAL.

12.  HELLO Message Processing

   On receiving a HELLO message, a node MUST first check if no Lost Neighbor Tuple with NL_neighbor_iface_addr ==
       lost any address exists, then add
   associated with a Lost Neighbor Tuple with:

       *  NL_neighbor_iface_addr = lost address;

       *  NL_time = TLV with Type == LOCAL_IF is one of the receiving
   node's current time + N_HOLD_TIME.

12.3.  Updating or recently used interface addresses (i.e. is in any
   I_local_iface_addr_list in the Link Local Interface Set

   On receiving a or is equal to any
   IR_local_iface_addr in the Removed Interface Address Set).  If so
   then the HELLO message, a message MUST be discarded.

   Otherwise the receiving node MUST update its Link Set for 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 message TLV
      of the HELLO message as specified in [3].  All information in the
      HELLO message has the same validity time.

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

   o  "Sending Address List" is received:

   1.  Remove all the list of the addresses contained in
      the Removed HELLO message with an associated TLV with Type == LOCAL_IF and
      Value == THIS_IF.  If the Sending Address List from is otherwise empty,
      then the
       L_neighbor_iface_addr_list Sending Address List contains a single address (with
      maximum prefix length) equal to the sending address of all Link Tuples.

   2.  Remove all Link Tuples whose L_neighbor_iface_addr_list the IP
      datagram in which the HELLO message was included.

   o  "Neighbor Address List" is now
       empty; apply Section 13.1, the Sending Address List, plus the
      addresses contained in the HELLO message with an associated TLV
      with Type == LOCAL_IF and Value == OTHER_IF.

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

   o  "Removed Address List" is a list of addresses created by this
      HELLO message processing which were formerly reported as local by
      the node originating the HELLO message, but which are not Section 13.3.

   3. included
      in the Neighbor Address List.  This list is initialized as empty.

   o  "Lost Address List" is a subset of the Removed Address List
      containing addresses which were formerly considered as symmetric.
      This list is initialized as empty.

12.1.  Updating the Neighbor Set

   On receiving a HELLO message, the node MUST update its Neighbor Set
   and populate the Removed Address List and Lost Address List:

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

       *  L_neighbor_iface_addr_list  N_neighbor_iface_addr_list contains at least one or more addresses address in
          the Sending Neighbor Address List.

   4.

   2.  If there is more than one matching Link Tuple, then remove them
       all; apply Section 13.1, but not Section 13.3.

   5.  If are no matching Link Tuples remain, then create Neighbor Tuples, then:

       1.  Create a new matching
       Link Neighbor 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

           +  N_neighbor_iface_addr_list = current time Neighbor Address List;

           + validity time.

   6.  The  N_symmetric = false.

   3.  If there is one matching Link Neighbor Tuple, existing or new, is then modified as
       follows: then:

       1.  If the MANET interface finds any N_neighbor_iface_addr_list of the matching Neighbor
           Tuple is not equal to the Neighbor Address List, then:

           1.  For each address (henceforth
           receiving removed address) which is in
               the Receiving Address List N_neighbor_iface_addr_list, but not in a the Neighbor
               Address Block in List:

               1.  Add the HELLO message, then removed address to the Link
           Tuple is modified as follows:

           1. Removed Address List.

               2.  If any receiving N_symmetric == true, then add the removed address in
                   to the HELLO message is
               associated with a TLV with Type == LINK_STATUS and (Value
               == HEARD or Value == SYMMETRIC) then: Lost Address List.

           2.  Update the matching Neighbor Tuple by:

               -  L_SYM_time  N_neighbor_iface_addr_list = current time + validity time.

           2.  Otherwise if any receiving Neighbor Address List.

   4.  If there are two or more matching Neighbor Tuples, then:

       1.  For each address (henceforth removed address) which is in the HELLO message
               is associated with a TLV with Type == LINK_STATUS and
               Value == LOST then:

               1.  if L_SYM_time has not expired, then:
           N_neighbor_iface_addr_list of any of the matching Neighbor
           Tuples:

           1.  L_SYM_time = EXPIRED.  Add the removed address to the Removed Address List.

           2.  if L_status  If N_symmetric == HEARD or SYMMETRIC, then:

                       *  L_time = current time + L_HOLD_TIME.

       2.  L_neighbor_iface_addr_list = Sending true, then add the removed address to
               the Lost Address List.

       3.  L_HEARD_time = max(current time

       2.  Replace the matching Neighbor Tuples by a single Neighbor
           Tuple with:

           + validity time, L_SYM_time).

       4.  If L_status == PENDING, then:  N_neighbor_iface_addr_list = Neighbor Address List;

           +  L_time  N_symmetric = max(L_time, L_HEARD_time).

       5.  Otherwise false

12.2.  Updating the Lost Neighbor Set

   On receiving a HELLO message, a node MUST update its Lost Neighbor
   Set:

   1.  For each address (henceforth lost address) in the Lost Address
       List, if L_status no Lost Neighbor Tuple with NL_neighbor_iface_addr == HEARD or SYMMETRIC, then:

           +  L_time
       lost address exists, then add a Lost Neighbor Tuple with:

       *  NL_neighbor_iface_addr = max(L_time, L_HEARD_time lost address;

       *  NL_time = current time + L_HOLD_TIME).

12.4. N_HOLD_TIME.

12.3.  Updating the 2-Hop Link Set

   On receiving a HELLO message message, a node MUST update its 2-Hop Link Set for the
   MANET interface on which the HELLO message was is received:

   1.  Remove all addresses in the Removed Address List from the
       N2_neighbor_iface_addr_list
       L_neighbor_iface_addr_list of all 2-Hop Link Tuples.

   2.  If the  Remove all Link Tuple with Tuples whose L_neighbor_iface_addr_list == Sending
       Address List has L_STATUS == SYMMETRIC then:

       1.  For each address (henceforth 2-hop address) in a Neighbor
           Address Block of the HELLO message, which is now
       empty; apply Section 13.1, but not in the
           Neighbor Address List or in any I_local_iface_addr_list:

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

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

               -  Type == OTHER_NEIGHB and Value == SYMMETRIC,

               then, if there is no 2-Hop Tuple such that:

               -  N2_neighbor_iface_addr_list 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 Sending Address List; AND

               -  N2_2hop_iface_addr == 2-hop address. List.

   4.  If there is more than one 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 2-Hop Neighbor new matching
       Link Tuple with:

               -  N2_2hop_iface_addr

       *  L_neighbor_iface_addr_list = 2-hop address.

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

               -  N2_neighbor_iface_addr_list empty;

       *  L_HEARD_time = Sending Address List;

               -  N2_time EXPIRED;

       *  L_SYM_time = current EXPIRED;
       *  L_quality = INITIAL_QUALITY;

       *  L_pending = INITIAL_PENDING;

       *  L_lost = false;

       *  L_time = current time + validity time.

           2.  Otherwise if

   6.  The matching Link Tuple, existing or new, is then modified as
       follows:

       1.  If the 2-hop node finds any address has (henceforth receiving address)
           in the Receiving Address List in an address block in the
           HELLO message, then the Link Tuple is modified as follows:

           1.  If any receiving address in the HELLO message is
               associated with a TLV with:

               - with Type == LINK_STATUS and (Value
               == LOST HEARD or Value ==
                  HEARD); OR SYMMETRIC) then:

               -  L_SYM_time = current time + validity time.

           2.  Otherwise if any receiving address in the HELLO message
               is associated with a TLV with Type == OTHER_NEIGHB LINK_STATUS and
               Value == LOST;

               then remove all 2-Hop Tuples with:

               -  N2_neighbor_iface_addr_list contains one LOST then:

               1.  if L_SYM_time has not expired, then:

                   1.  L_SYM_time = EXPIRED.

                   2.  if L_status == HEARD or more SYMMETRIC, then:

                       *  L_time = current time + L_HOLD_TIME.

       2.  L_neighbor_iface_addr_list = Sending Address List.

       3.  L_HEARD_time = max(current time + validity time, 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 HELLO message a node MUST update its 2-Hop Set for the
   MANET interface on which the HELLO message was received:

   1.  Remove all addresses in the Removed Address List from the
       N2_neighbor_iface_addr_list of all 2-Hop Tuples.

   2.  If the Link Tuple with L_neighbor_iface_addr_list == Sending
       Address List; AND

               -  N2_2hop_iface_addr List has L_status == SYMMETRIC then:

       1.  For each address (henceforth 2-hop address.

13. address) in an address
           block of the HELLO message, which is not in the Neighbor
           Address List, in any I_local_iface_addr_list, or equal to any
           IR_local_iface_addr:

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

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

               -  Type == OTHER_NEIGHB and Value == SYMMETRIC,

               then, if there is no 2-Hop Tuple such that:

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

               -  N2_2hop_iface_addr == 2-hop address.

               then create a 2-Hop Neighbor Tuple with:

               -  N2_2hop_iface_addr = 2-hop address.

               This 2-Hop 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 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 changed when some
   events occur.  These events may result from HELLO message processing,
   or may be otherwise generated (e.g. expiry of timers or link quality
   changes).

   Events which cause changes in the Information Bases are:

   o  A Link Tuple's state changes from symmetric, or the Link Tuple is
      removed.

   o  A Link Tuple's state changes to 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 any of these
   changes in HELLO message(s), subject to the constraints in
   Section 11.

   A node which transmits HELLO messages in 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 considered pending).

13.1.  Link Tuple Not Symmetric

   If for any Link Tuple with L_status == SYMMETRIC:

   o  L_status changes to 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 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 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 NL_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

   o  I_HOLD_TIME = N_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 1/1024 second (1/16 second)

16.  IANA  Security Considerations

16.1.  Message Types

   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 specification defines one is acquired through message type, which must be allocated
   from exchange between
   neighboring nodes.  The information is made available through the "Assigned Message Types" repository of [1] with assignment
   as specified
   Interface Information Bases and Node Information Base, describing the
   node's 1-hop neighborhood and symmetric 2-hop neighborhood.

   Under normal circumstances, the information recorded in Table 3.

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

                                  Table 3

16.2.  TLV Types

   This specification defines three address block TLV types, these
   Information Bases is correct - i.e. corresponds to the actual network
   topology, apart from any changes which must 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 allocated from recorded in the "Assigned Address Block TLV Types" repository
   of [1] with assignments as specified
   Information Bases.  The protocol specification does, however, prevent
   inconsistent information from being injected in Table 4.

   +--------------+------+---------+-----------------------------------+
   |     Name     | Type | Subtype | Description                       |
   +--------------+------+---------+-----------------------------------+
   |   OTHER_IF   |  TBD |    0    | Specifies that the address is     |
   |              |      |         | associated with an interface      |
   |              |      |         | other than protocol sets
   through the MANET interface constraints in Appendix C.  The exact consequence of
   information inexactness depends on |
   |              |      |         | which the message is transmitted  |
   |              |      |         |                                   |
   |              |      |  1-255  | RESERVED                          |
   |              |      |         |                                   |
   |  LINK_STATUS |  TBD |    0    | Specifies use of these Information
   Bases, and should be reflected in the status specification of protocols
   which use information provided by NHDP.

   This section, therefore, only outlines the link  |
   |              |      |         | from ways in which correctly
   formed, but still invalid, HELLO messages may appear.

16.1.  Invalid HELLO messages

   A correctly formed, but still invalid, HELLO message may take any of
   the indicated following forms.  Note that a present or absent address (LOST, |
   |              |      |         | SYMMETRIC or HEARD)               |
   |              |      |         |                                   |
   |              |      |  1-255  | RESERVED                          |
   |              |      |         |                                   |
   | OTHER_NEIGHB |  TBD |    0    | Specifies that the in an
   address block, does not in and by itself cause a problem.  It is     |
   |              |      |         | (SYMMETRIC) the
   presence, absence, or recently was       |
   |              |      |         | (LOST) incorrectness of associated LOCAL_IF,
   LINK_STATUS and OTHER_NEIGHB TLVs that causes problems.

   A node may provide false information about its own identity:

      *  The HELLO message may contain addresses with an interface associated
         LOCAL_IF TLV which do not correspond to addresses of a       |
   |              |      |         | symmetric 1-hop neighbor interfaces
         of the   |
   |              |      |         | node transmitting the HELLO message.

      *  The HELLO message     |
   |              |      |         |                                   |
   |              |      |  1-255  | RESERVED                          |
   +--------------+------+---------+-----------------------------------+

                                  Table 4
   Subtypes indicated as RESERVED may be allocated by standards action,
   as specified in [6].

16.3.  LINK_STATUS and OTHER_NEIGHB Values

   The values omit addresses, or their associated
         LOCAL_IF TLV, of interfaces of the local node transmitting the
         HELLO message (other than the allowed omission of the only
         local interface address of the MANET interface over which the LINK_STATUS TLV can use are
         HELLO message is transmitted, if that is the following:

   o  LOST = 0

   o  SYMMETRIC = 1

   o  HEARD = 2 case).

      *  The values which HELLO message may incorrectly specify the OTHER_NEIGHB LOCAL_IF TLV can use
         value associated with one or more local interface addresses,
         indicating incorrectly whether they are associated with 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-07.txt, June 2007.

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

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

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

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

   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", October 1998.

17.2.  Informative References

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

   [8]  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 message is transmitted.

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

      *  A present LINK_STATUS TLV may, incorrectly, identify an address blocks after the Local
   Interface Block, and with
         as being of a MANET interface which associated TLVs.  These TLVs may have
   Type == LINK_STATUS or Type == OTHER_NEIGHB, is or both.  TLVs with Type
   == was heard on the
         MANET interface over which the HELLO message is transmitted.

      *  A consistently absent LINK_STATUS may have three possible values (Value == HEARD, Value
   == SYMMETRIC or Value == LOST), and TLVs TLV may, incorrectly, fail to
         identify an address as being of TYPE == OTHER_NEIGHB may
   have two possible values (Value == SYMMETRIC a MANET interface which is or Value == LOST).  When
   both TLVs are associated with
         was heard on the same MANET interface over which the HELLO message
         is transmitted.

      *  A present OTHER_NEIGHB TLV may, incorrectly, identify an
         address only certain
   combinations as being of these TLV values are necessary, and are the only
   combinations generated by the algorithm a node which is or was in Section 11.  These
   combinations are indicated 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 Table 5.

   Cells labeled with "Yes"
         the sending node's symmetric 1-hop neighborhood;

      *  The value of a LINK_STATUS TLV may incorrectly indicate the possible combinations which are
   generated by
         status (LOST, SYMMETRIC or HEARD) of the algorithm in Section 11.  Cells labeled with "No" link from a 1-hop
         neighbor.

      *  The value of an OTHER_NEIGHB TLV may incorrectly indicate combinations not generated by the algorithm in Section 11,
   but
         status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.

17.  IANA Considerations

17.1.  Message Types

   This specification defines one message type, which are correctly parsed and interpreted by must be allocated
   from the algorithm "Assigned Message Types" repository of [1] with assignment
   as specified in
   Section 12.

   +----------------+----------------+----------------+----------------+
   |                |     Type == Table 3.

                    +-------+------+------------------+
                    |     Type ==  Name | Type ==    |
   |                |  OTHER_NEIGHB  |  OTHER_NEIGHB, |  OTHER_NEIGHB, |
   |                |    (absent)    |    Value ==    |  Value == LOST |
   |                |                |    SYMMETRIC | Description      |
   +----------------+----------------+----------------+----------------+
                    +-------+------+------------------+
                    | Type == HELLO |       No TBD1 |       Yes Local signaling. |       Yes
                    +-------+------+------------------+

                                  Table 3

17.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] with assignments as specified in Table 4.

   +--------------+------+-----------+---------------------------------+
   |     Name     | LINK_STATUS Type |    Type   | Description                     |
   |              | (absent)      | extension |                                 |
   +--------------+------+-----------+---------------------------------+
   |   LOCAL_IF   | TBD2 |     0     | Specifies that the address is   |
   |              | Type ==      |       Yes           |       Yes associated with a local         |       Yes
   |              | LINK_STATUS,      |           | interface of the sending node.  |
   |              | Value == HEARD      |           |                                 |
   |              |      |   1-255   | RESERVED                        |
   |              | Type ==      |       Yes           |       No                                 |       No
   |  LINK_STATUS | LINK_STATUS, TBD3 |     0     | Specifies the status of the     |
   |              | Value ==      |           | link from the indicated address |
   |              |      |           | (LOST, SYMMETRIC or HEARD).     |
   |              |      |           |                                 |
   |              |      |   1-255   | Type == RESERVED                        |       Yes
   |       Yes              |       No      |           | LINK_STATUS,                                 |
   | OTHER_NEIGHB | TBD4 |     0     | Value == LOST Specifies that the address is   |
   |              |      |
   +----------------+----------------+----------------+----------------+

                                  Table 5

Appendix B.  HELLO Message Example

   An example HELLO message, transmitted by           | (SYMMETRIC) or recently was     |
   |              |      |           | (LOST) of 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 interface of 1 and a hop count     |
   |              |      |           | symmetric 1-hop neighbor of 0.  The overall message length is 50
   octets. the |
   |              |      |           | node transmitting the message.  |
   |              |      |           |                                 |
   |              |      |   1-255   | RESERVED                        |
   +--------------+------+-----------+---------------------------------+

                                  Table 4
   Type extensions indicated as RESERVED may be allocated by standards
   action, as specified in [6].

17.3.  LINK_STATUS and OTHER_NEIGHB Values

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

   The first address block contains following:

   o  UNSPEC_IF = 0

   o  THIS_IF = 1 local interface address.  The
   semantics octet value

   o  OTHER_IF = 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, values which 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 can use are HEARD, the third address is following:

   o  LOST = 0

   o  SYMMETRIC and the fourth
   address is LOST. = 1

   o  HEARD = 2

   The TLV semantics value of 40 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 which the OTHER_NEIGHB TLV value length of 4 octets indicates one octet per value per
   address.

      0                   1                   2                   3 can use are the following:

   o  LOST = 0

   o  SYMMETRIC = 1 2 3 4 5 6 7 8 9 0

18.  References

18.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-11.txt, November 2007.

   [2]  Chakeres, I., "IANA Allocations for MANET Protocols", Work In
        Progress draft-ietf-manet-iana-07.txt, November 2007.

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

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

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

   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.

18.2.  Informative References

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

   [8]  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 1-hop addresses may be included in the address blocks, 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 specified prefix lengths.  The message is
   transmitted with a full message header other than version number
   (message semantics octet is 0) with a hop limit of 1 and a hop count
   of 0.  The overall message length is 49 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 8, indicating
   that no start and stop indexes are included, and each has a value
   length of 1 octet.  The values included (0x6C and 0x58) are time
   codes representing the default values of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
   default value of constant C (1/1024 second).

   The message has a single address block containing 5 addresses.  The
   semantics octet value 2 indicates no address tail, the head length of
   3 octets indicates address mid sections of one octet each (Mid 0 to
   Mid 4).

   The following TLV block (content length 14 octets) includes two TLVs.
   The first is a LOCAL_IF TLV which (with semantics value 16) indicates
   that a single address, with index 0 (i.e.  Head:Mid 0) is the single
   local interface address of this node.  The second is a LINK_STATUS
   TLV which (with semantics octet 32) specifies the link status values
   of all reported neighbors in a single multivalue TLV which covers the
   addresses with indexes 1 to 4.  The TLV value length of 4 octets
   indicates one octet per value per address.  The last four addresses
   are first and second HEARD, third SYMMETRIC, and fourth LOST.

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

Appendix C.  Constraints

   Any process which updates the Local Information Base or the
   Neighborhood Information Base MUST ensure that all constraints
   specified in this appendix are maintained.

   In each Local Interface Tuple:

   o  I_local_iface_addr_list MUST NOT be empty.

   o  I_local_iface_addr_list MUST NOT contain any address which is in
      the I_local_iface_addr_list of any other Local Interface Tuple.

   In each Link Tuple:

   o  L_neighbor_iface_addr_list MUST NOT be empty.

   o  L_neighbor_iface_addr_list MUST NOT contain any address which is
      in the I_local_iface_addr_list of any Local Interface Tuple.

   o  L_neighbor_iface_addr_list MUST NOT contain any address which is
      in the L_neighbor_iface_addr_list of any other Link Tuple in the
      same Link Set.

   o  If L_HEARD_time has not expired then there MUST be a Neighbor
      Tuple whose N_neighbor_iface_addr_list contains
      L_neighbor_iface_addr_list.

   o  L_HEARD_time MUST NOT be 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 L_quality >= HYST_ACCEPT then L_pending MUST be false.

   o  If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST.

   o  L_pending MUST NOT be set to true if it is currently false.

   In each Neighbor Tuple:

   o  N_neighbor_iface_addr_list MUST NOT contain any address which is
      in the I_local_iface_addr_list of any Local Interface Tuple.

   o  N_neighbor_iface_addr_list MUST NOT contain any address which is
      in the N_neighbor_iface_addr_list of any other Neighbor Tuple.

   o  If N_symmetric == true, then there MUST     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

   Note that this example is for illustrative purposes.  The essential
   information can be one or conveyed, more Link Tuples
      with:

      *  L_neighbor_iface_addr_list contained in
         N_neighbor_iface_addr_list; AND

      *  L_status == SYMMETRIC.

   o  If N_symmetric == false, then there MUST efficiently (assuming that the
   local interface address will be 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 supplied by IP, and that the
   INTERVAL_TIME is not expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_iface_addr MUST NOT be in needed) by the 29 octets:

      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 1 1 1 1 0|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 1 1 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                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mid 1     |     Mid 2     |     Mid 3     |     Mid 4     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |0 0 1 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

Appendix C.  Constraints

   Any process which updates the I_local_iface_addr_list
      of any Local Interface Tuple.

   o  NL_neighbor_iface_addr MUST NOT equal Information Base or the NL_neighbor_iface_addr
      of any other Lost Neighbor Tuple.

   o  NL_neighbor_iface_addr Node
   Information Base MUST NOT be ensure that all constraints specified in the
      N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric
      == true. this
   appendix are maintained.

   In each 2-Hop Tuple:

   o  There MUST be a Link Tuple associated with the same MANET
      interface with:

      *  L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND

      *  L_status == SYMMETRIC.

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

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

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

Appendix 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  I_local_iface_addr_list MUST NOT contain any duplicated addresses.

   o  I_local_iface_addr_list MUST NOT contain any address which is in
      the sets
   maintained.  The protocol specification does, however, prevent
   inconsistent information from being injected I_local_iface_addr_list of any other Local Interface Tuple.

   In each Removed Interface Address Tuple:

   o  IR_local_iface_addr MUST NOT contain any address which is in the protocol sets
   through the constraints in Appendix C.  The exact consequence
      I_local_iface_addr_list of
   information inexactness depends on any Local Interface Tuple.

   o  IR_local_iface_addr MUST NOT equal the use IR_local_iface_addr of these sets, and should any
      other Removed Interface Address Tuple.

   In each Link Tuple:

   o  L_neighbor_iface_addr_list MUST NOT be reflected empty.

   o  L_neighbor_iface_addr_list MUST NOT contain any address which is
      in the specification I_local_iface_addr_list 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 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 Tuple or the
      IR_local_iface_addr of any Removed Interface Address Tuple.

   o  L_neighbor_iface_addr_list MUST NOT contain any duplicated
      addresses.

   o  L_neighbor_iface_addr_list MUST NOT contain any address which is
      in the HELLO message may L_neighbor_iface_addr_list of any other Link Tuple in the
      same Link Set.

   o  If L_HEARD_time has not expired then there MUST be a Neighbor
      Tuple whose N_neighbor_iface_addr_list contains
      L_neighbor_iface_addr_list.

   o  L_HEARD_time MUST NOT be 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 L_quality >= HYST_ACCEPT then L_pending MUST be false.

   o  If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST.

   o  L_pending MUST NOT be set to true if it is currently false.

   In each Neighbor Tuple:

   o  N_neighbor_iface_addr_list MUST NOT contain
         addresses any address which do not correspond to addresses of interfaces of
         the node transmitting is
      in the HELLO message.

      *  The I_local_iface_addr_list of any Local Interface Block of Tuple or the HELLO message may omit
         addresses
      IR_local_iface_addr of interfaces of the local node transmitting the
         HELLO message.

      *  The Local any Removed Interface Block may Address Tuple.

   o  N_neighbor_iface_addr_list MUST NOT contain additional OTHER_IF TLVs,
         indicating incorrectly that an any duplicated
      addresses.

   o  N_neighbor_iface_addr_list MUST NOT contain any address is associated with an
         interface other than that over which the HELLO message is
         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 transmitted.

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

      *  A present or absent address in a Neighbor Block, does not Tuple.

   o  If N_symmetric == true, then there MUST be one or more Link Tuples
      with:

      *  L_neighbor_iface_addr_list contained in
         and by itself cause a problem.  It is the presence, absence,
         N_neighbor_iface_addr_list; AND

      *  L_status == SYMMETRIC.

   o  If N_symmetric == false, then there MUST be one or
         incorrectness of associated LINK_STATUS and OTHER_NEIGHB TLVs
         that causes problems. more Link
      Tuples with:

      *  A present LINK_STATUS TLV may, incorrectly, identify an address
         as being  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 expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list
      of a MANET interface which is any Local Interface Tuple or was heard on the
         MANET interface over which IR_local_iface_addr of any
      Removed Interface Address Tuple.

   o  NL_neighbor_iface_addr MUST NOT equal the HELLO message is transmitted.

      *  A consistently absent LINK_STATUS TLV may, incorrectly, fail to
         identify an address as being NL_neighbor_iface_addr
      of any other Lost Neighbor Tuple.

   o  NL_neighbor_iface_addr MUST NOT be in the
      N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric
      == true.

   In each 2-Hop Tuple:

   o  There MUST be a MANET interface which is or
         was heard on Link Tuple associated with the same MANET
      interface over which the HELLO message
         is transmitted. with:

      *  A present OTHER_NEIGHB TLV may, incorrectly, identify an
         address as being of a node which is or was  L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND

      *  L_status == SYMMETRIC.

   o  N2_2hop_iface_addr MUST NOT be in the sending
         node's symmetric 1-hop neighborhood;

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

      *  The value IR_local_iface_addr of a LINK_STATUS TLV may incorrectly indicate any
      Removed Interface Address Tuple.

   o  N2_2hop_iface_addr MUST NOT be the
         status (LOST, SYMMETRIC or HEARD) N2_2hop_iface_addr of any other
      2-Hop Tuple in the link from a 1-hop
         neighbor.

      *  The value of an OTHER_NEIGHB TLV may incorrectly indicate same 2-Hop Set and with the
         status (LOST or SYMMETRIC) same
      N2_neighbor_iface_addr_list.

   o  N2_2hop_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list
      of a symmetric 1-hop neighbor. the same 2-Hop Tuple.

Appendix E. D.  Flow and Congestion Control

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

Appendix F. E.  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, LIX, 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 G. F.  Acknowledgements

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

   Christopher Dearlove
   BAE Systems Advanced Technology Centre

   Phone: +44 1245 242194
   Email: chris.dearlove@baesystems.com
   URI:   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).