Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                                  LIX, Ecole Polytechnique, France Polytechnique
Intended status: Standards Track                             C. Dearlove
Expires: January 11, September 10, 2009                              BAE Systems Advanced Technology
                                                                  Centre ATC
                                                                 J. Dean
                                               Naval Research Laboratory
                                                  The OLSRv2 Design Team
                                                     MANET Working Group
                                                           July 10, 2008
                                                           March 9, 2009

              MANET Neighborhood Discovery Protocol (NHDP)
                        draft-ietf-manet-nhdp-07
                        draft-ietf-manet-nhdp-08

Status of This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of which he BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or she is aware
   have been IETF Contributions published or will made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be disclosed, modified outside the IETF Standards Process, and any
   derivative works of which he or she becomes
   aware will it may not be disclosed, in accordance with Section 6 of BCP 79. created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 January 11, September 10, 2009.

Copyright Notice
   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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

1.  Introduction

   This document describes a neighborhood discovery protocol (NHDP) for
   a mobile ad hoc network (MANET) [RFC2501].  This protocol uses an
   exchange of HELLO messages in order that each node router can determine
   the presence of, and status of connectivity to, its 1-hop and symmetric 2-hop
   neighbors.  Messages are defined as instances of the specification [packetbb].

   This
   [RFC5444].

   1-hop and symmetric 2-hop neighborhood information is recorded in the
   form of Information Bases.  These may be used by other protocols,
   such as MANET routing protocols, for determining which require information regarding
   the local connectivity and node configuration. network connectivity.  This protocol is designed to
   maintain this the information in these Information Bases even in the
   presence of a dynamic network topology. topology and wireless ad hoc network
   interface characteristics.

   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)
   [RFC3626].

1.1.  Motivation

   MANETs differ from more traditional wired and infrastructure based
   wireless networks, due to their envisioned applicability also over
   more challenging network interfaces (e.g. wireless, lossy, broadcast
   interfaces with moderate and shared bandwidth, hidden and exposed
   terminals and interference from other network interfaces and the
   environment) and in more challenging topological conditions (e.g.
   rapid and unpredictable mobility, dynamic and non-predetermined
   network membership).  An approach, often taken by MANET routing
   protocols, is to collect local topological information up to 2 hops,
   in order to, for example, optimize their flooding performance within
   the MANET.

   Due to the properties of wireless transmissions, communication
   between two network interfaces on neighboring nodes routers may not be bi-
   directional;
   bidirectional; even if node router A is able to receive a packets from node
   router B, the converse is not guaranteed to be true.  Furthermore,
   because of the localized nature of wireless broadcasts broadcast communication, differing
   neighbor sets often exist for differing
   neighboring nodes routers within the same communications channel. channel may have
   different sets of neighbors.  If node router A is able to exchange packets
   with node router B and node router B is able to exchange packets with node router C
   on the same interface, this does not guarantee that node router A and node
   router C can exchange packets directly.

   Nodes

   Routers in a MANET may have multiple heterogeneous interfaces
   participating in the same MANET routing protocol, each of which with
   the characteristics as described above.  Between the same pair of
   nodes
   routers, more than one distinct communications channel (links) (link) may
   therefore exist, each with different properties.

   For MANET routing protocols to correctly identify candidate links for
   inclusion in a routing path, the existence and bi-directionality and, in many cases,
   bidirectionality of such distinct links between a node router and its
   neighbors must be established and monitored.

   The set of neighbor nodes routers of a given MANET node router may be
   continuously changing, often due to node router mobility or due to a changing
   physical environment in which the MANET is located.  There are
   typically no signals from lower layers which would enable an IP
   routing protocol to detect and, as appropriate, react to such
   changes.  Yet as such  Such changes are can often take place on a short timescale,
   such as of the order of seconds, requiring MANET IP routing protocols to also
   act rapidly to ensure sufficient suitable convergence properties.

   MANET routing protocols protocols, for example [RFC3626] and [RFC5449], often
   employ relay set reductions in order to conserve network capacity
   when maintaining network-wide topological information, with
   calculation of these reduced relay sets employing up to 2-hop two hop
   information.  Such is the case e.g. for [RFC3626].

   The neighborhood discovery protocol specified in this document
   provides continued tracking of neighborhood changes, continued bi-
   directionality
   bidirectionality tracking of links between neighbors neighbors, and local
   topological information up to two hops.  Combined, this allows a
   MANET routing protocol access to information describing link
   establishment/disappearance, and provides the necessary topological
   information for reduced relay set selection and other purposes.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   The

   All terms introduced in [RFC5444], including "packet", "message", "address", "address block", "TLV", and
   "Address Block", "TLV block" in this document Block" and "TLV", are to be interpreted as
   described in
   [packetbb]. there.

   Additionally, this document uses the following terminology:

   Node

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

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

   Address  - An IPv4 or IPv6 address, as recorded in the Information
      Bases specified by this protocol, and included in HELLO messages
      generated by this protocol, may be either an address or an address
      prefix.  The exception to this is addresses described as
      originator addresses; these must be simple addresses without a
      prefix length.  Non-
      originator  Non-originator addresses can be represented as a
      single address object in a HELLO message, as defined by [packetbb]. [RFC5444].  An
      address so represented is considered to have a prefix length equal
      to its length (in bits) when considered as an address object, and
      a similar convention is used in the Information Bases specified by
      this protocol.  Two addresses (address objects) are considered
      equal only if their prefix lengths are also equal.

   MANET interface  - An interface participating in a MANET and using
      this neighborhood discovery protocol.  A node router may have several
      MANET interfaces.

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

   Link  - A pair of MANET interfaces from two different nodes, routers, 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 router X is a 1-hop neighbor of a node router Y if a
      MANET interface of node router X is heard by a MANET interface of node
      router Y.

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

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

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

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

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

   Constant  - A constant is a numerical value which MUST be the same
      for all MANET interfaces of all nodes routers 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. router.  A node router MAY change interface parameter values at
      any time, subject to some constraints.

   Node

   Router parameter  - A node router parameter is a boolean or numerical
      value, specified for each node. router, and not specific to an
      interface.  A node router MAY change node router parameter values at any
      time, subject to some constraints.

3.  Applicability Statement

   This protocol:

   o  Is applicable to networks, especially wireless networks, in which
      unknown neighbors (i.e. other nodes with which direct
      communication can be established) can be reached by local
      broadcast

   Furthermore, this document uses the following notational conventions:

   X contains y, or multicast packets.

   o  Is designed to work y is contained in networks with a dynamic topology, X,  is an unordered list
      membership operator, returning true if the unordered list X
      includes the element y, and returning false otherwise.

   X contains Y, or Y is contained in X,  is an unordered list inclusion
      operator, returning true if the unordered list X contains all
      elements y which messages are contained in Y, and returning false
      otherwise.

   a := b  is an assignment operator, whereby the left side (a) is
      assigned the value of the right side (b). a and b may be lost, such as values,
      addresses, or unordered lists (they must be of the same type).

   c = d  is a comparison operator, returning true if the value of the
      left side (c) is equal to the value of the right side (d). c and d
      may be values, addresses, or unordered lists (they must be of the
      same type).  If c and d are unordered lists, then they are
      considered to be equal if they contain the same set of elements,
      regardless of the order in which they are recorded in either list
      (in which case c is contains d, and d contains c).

   e != f  is a comparison operator, returning true where (e = f) would
      have returned false, and returning false where (e = f) would have
      returned true.

3.  Applicability Statement

   This protocol:

   o  Provides each router with local topology information up to two
      hops away.

   o  Makes this local topology information a available to MANET routing
      protocols in Information Bases, which are defined in this
      specification.

   o  May interact with other protocols, such as MANET routing
      protocols, see Section 3.1.

   o  Is applicable to networks, especially wireless networks, in which
      unknown neighbors (i.e. other routers with which direct link layer
      communication can be established) can be reached by local
      broadcast or multicast packets.

   o  Is designed to work in networks with a dynamic topology, and in
      which messages may be lost, such as due to collisions in wireless
      networks.

   o  Supports nodes routers that each have one or more participating MANET
      interfaces.  The set of a node's router's interfaces may change over
      time.  Each interface may have one or more interface addresses,
      and these may also be dynamically changing.

   o  Can use the link local multicast address "LL-MANET-Routers", and
      either the "manet" UDP port or the "manet" IP protocol number, all
      as specified in [manet-iana].

   o  Uses the packet and message formats specified in [packetbb]. [RFC5444].  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 [packetbb]. [RFC5444].

   o  Can use relevant link layer information if it is available.

   o  Provides each node with local topology information up to two hops
      away.  This information is made available to other protocols, of
      which this protocol may be a part, in Information Bases defined in
      this specification.

   o  Is designed to work in a completely distributed manner, and does
      not depend on any central entity.

4.  Protocol Overview and Functioning

   The objective of

3.1.  Usage in Other Protocols

   Other protocols which use neighborhood discovery MAY need to interact
   with this protocol.  This protocol is, for each node: is designed to permit such
   interactions, in particular:

   o  Through accessing, and possibly extending, the information in the
      Local Information Base (Section 6), the Interface Information Base
      (Section 7) and the Neighbor Information Base (Section 8).  These
      Information Bases record the interface configuration of the
      router, as well as the local connectivity, up to two hops away.
      All updates to the elements specified in this document are subject
      to the constraints specified in Appendix B.

   o  Through accessing an outgoing HELLO message prior to it being
      transmitted over any MANET interface, and to add information (e.g.
      TLVs) as specified in [RFC5444].  This may, for example, be to
      allow a security protocol, as suggested in Section 16, to add a
      TLV containing a cryptographic signature to the message, or be to
      allow inserting relay selection information into a HELLO message
      by way of adding a TLV to an outgoing HELLO message prior to it
      being transmitted.

   o  Through accessing an incoming HELLO message, and potentially
      discard it prior to processing by this protocol.  This may, for
      example, allow a security protocol, as suggested in Section 16, to
      perform verification of HELLO message signatures and prevent
      processing of unverifiable HELLO messages by this protocol.

   o  Through accessing an incoming HELLO message after it has been
      completely processed by this protocol.  This may, in particular,
      allow a protocol which has added information, such as relay
      selection information by way of inclusion of appropriate TLVs,
      access to such information after appropriate updates has been
      recorded in the Information Bases in this protocol.

   o  Through requesting that a HELLO message be generated at a specific
      time.  In that case, HELLO message generation MUST still respect
      the constraints in Appendix B.

4.  Protocol Overview and Functioning

   The objective of this protocol is, for each router:

   o  To identify other nodes routers which can be heard, and those 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 interface addresses of the router'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 router and its interfaces.

   o  Discovers links with adjacent nodes. from neighboring routers.

   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  Parameters and constants used by the protocol.  Parameters used by
      this protocol may be, where appropriate, specific to a specific
      MANET
      interface. interface, or to a MANET router.  This protocol allows all
      parameters to be changed
      dynamically. dynamically, and to be set independently
      for each MANET router or MANET interface, as appropriate.

   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  Routers and Interfaces

   In order for a node router 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.

   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.

   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
   router has:

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

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

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

4.2.  Information Base Overview

   Each node router 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.  In particular note that it is not
   necessary to remove Tuples from Sets at the exact time indicated,
   only to behave as if the Tuples were removed at that time.

4.2.1.  Local Information Base

   Each node router 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. router.

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

   The Local Interface Set is used for generating HELLO messages,
   specifically for determining which interface addresses are to be
   included and identified through inclusion of an appropriate TLV as
   being a "local interface" of the router at which the HELLO message is
   generated.  The Removed Interface Address Set is used to allow a
   router to detect if a neighbor is advertising a formerly used
   address, and to exclude this from inclusion in the Interface
   Information Bases described below.

   The Local Information Base is used for generating signaling, but is
   not itself updated by signaling specified in this document.  Updates
   to the Local Information Base are due to changes of the router
   configuration, and may be allowed to trigger signaling.

4.2.2.  Interface Information Bases

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

   o  A Link Set, which records information about current and recently
      lost links between this interface and MANET interfaces of 1-hop
      neighbors.  The Link Set consists of Link Tuples, each of which
      contains information about a single link.  Recently lost links are
      recorded so that they can be advertised in HELLO messages,
      accelerating their removal from relevant 1-hop neighbors' Link
      Sets.  Link quality information, information (see Section 14), if used and
      available, is recorded in Link Tuples and may indicate that 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 routers (symmetric 2-hop neighbors).  The 2-Hop Set consists
      of 2-Hop Tuples, each of which records an interface address of a
      symmetric 2-hop neighbor, and all interface addresses of the
      corresponding symmetric 1-hop 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 Link Set consists of Neighbor
      Tuples, each of which records all interface addresses (whether
      directly linked or not) of for a single 1-hop neighbor.  Neighbor
      Tuples are maintained as long as there are corresponding current MANET interface is used for generating HELLO
   messages.  Specifically, the Link 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 interface address of such a
      neighbor.  These are recorded so that they can be advertised in
      HELLO messages, accelerating their removal from other nodes' 2-Hop
      Sets.

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 included to update these Information
   Bases.  Such updates are subject both
   allow other routers to the constraints specified in
   Appendix C.

   Signaling consists of a single type of message, known detect bidirectionality (if router A
   advertises router B as heard in a HELLO
   message.  Each node generates HELLO messages on each of its MANET
   interfaces.  Each HELLO message identifies and router B receives
   that MANET interface, HELLO message, then router B knows that bidirectional
   communication is possible between routers A and
   reports the other interfaces (MANET B), and non-MANET) of to populate
   the node.  Each 2-Hop Set (if router C receives a HELLO message includes information from the router B
   advertising a bidirectional link to address A, then router C knows
   that address A is reachable in two hops via router B).

   The Link Set for a MANET interface is itself updated upon receipt of the Interface
   Information Base of the
   a HELLO message, including to record link bidirectionality as
   indicated above.

   The 2-Hop Set for a MANET interface, interface is updated as indicated above,
   and from the Node
   Information Base.

4.3.1.  HELLO Message Generation is not itself used in generating HELLO messages are generated by messages.

4.2.3.  Neighbor Information Base

   Each router maintains a node for Neighbor Information Base, which contains:

   o  The Neighbor Set, which records 1-hop neighbors, each of its MANET
   interfaces, and MAY which
      must be sent:

   o  Proactively, at currently heard, although this may be over 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 link with
      insufficient link quality.  The Neighbor Set consists of these proactive and responsive mechanisms.

   Jittering Neighbor
      Tuples, each of HELLO message generation and transmission, which records all interface addresses of a single
      1-hop neighbor.  Neighbor Tuples are maintained as described
   in Section 11.2, SHOULD be used if appropriate.

   HELLO messages long as there
      are generated independently on corresponding current Link Tuples.

   o  The Lost Neighbor Set, which records recently lost symmetric 1-hop
      neighbors.  The Lost Neighbor Set consists of Lost Neighbor
      Tuples, each MANET of which records an interface address of such a node.  HELLO messages MAY
      neighbor.  These are recorded so that they can be scheduled independently advertised in
      HELLO messages, accelerating their removal from other routers'
      2-Hop Sets.

   The Neighbor Set is used for each MANET
   interface, or, recording which interface parameters permitting, using addresses of
   neighbor routers are associated to the same
   schedule router, and for all MANET interfaces of a node.

4.3.2.  HELLO Message Content

   Each including
   this when generating HELLO message sent over a MANET interface need not contain all
   of the information appropriate to messages such that MANET interface, however:

   o  A HELLO message MUST contain all of the addresses 2-Hop sets in the Local
      Interface other
   neighboring routers may record this information.  The Neighbor Set
   can itself be updated on receipt of a HELLO message.

   The Lost Neighbor Set is used for generating HELLO messages.
   Specifically, the node to which the MANET interface belongs.

   o  Within every time interval of length REFRESH_INTERVAL, the Lost Neighbor Set is used for determining which
   addresses are to be included in a HELLO
      messages sent on each MANET interface and identified through
   inclusion of an appropriate TLV as being "lost", i.e. formerly, but
   no longer, recorded as a node MUST collectively
      include:

      *  All of the relevant information in the Link symmetric neighbor.  The Lost Neighbor Set
   can itself be updated on receipt of a HELLO message.

4.3.  Signaling Overview

   This protocol contains a signaling mechanism for maintaining the
   Interface Information Base of that MANET interface.

      *  All of Bases and the relevant Neighbor Information Base.  If
   information in from the Node link layer, or any other source, is available
   and appropriate, it may also be used to update these Information Base of
         that node.

      This applies
   Bases.  Such updates are subject to otherwise purely responsive nodes as well the constraints specified in
   Appendix B.

   Signaling consists of a single type of message, known as to
      proactive nodes.  In either case it means that all information
      appropriate to that a HELLO
   message.  Each router generates HELLO messages on each of its MANET interface will have always been
      transmitted, in one or more
   interfaces.  HELLO messages, since messages are generated independently on each MANET
   interface of a MANET router; the time
      REFRESH_INTERVAL ago.

   o  A HELLO message MUST include content of a VALIDITY_TIME given HELLO message TLV that
      indicates
   depends on the length of time interface for which the it has been generated.

   Each HELLO message content identifies the MANET interface for which it is to
      be considered valid,
   generated and included in the receiving node's
      Interface Information Base.

   o  A periodically generated over which it is transmitted.  This allows its
   recipients to identify from which MANET interface this HELLO message SHOULD include an
      INTERVAL_TIME
   has been received.  Each HELLO message TLV that indicates also reports the current value other
   interfaces (MANET and non-MANET) of
      HELLO_INTERVAL for that MANET interface, i.e. the period within router, which allows
   recipients to associate a further set of interface addresses with a single
   neighbor.  Finally, each HELLO message is guaranteed to be sent on that
      MANET interface.

   o  Additional also includes information may be added by a protocol using this
      protocol using from
   the TLV mechanisms described in [packetbb].  For
      example, if multipoint relays (MPRs) are to be calculated
      similarly to as in OLSR [RFC3626] Link Set of the Interface Information Base of the MANET
   interface, and signaled from the Neighbor Information Base.  This serves to neighbors, then
      this information may be added
   allow detection of bidirectional communication between two MANET
   routers and over a pair of MANET interfaces, as well as to HELLO messages using an address
      block TLV.

4.3.3. determine
   symmetric 2-hop neighborhood information.

4.3.1.  HELLO Message Processing

   All Generation

   HELLO messages received are generated by a node are used to update:

   o  The Interface Information Base router for the each of its MANET interface on which
      that HELLO message is received.

   o  The Node Information Base.

   Specifically:
   interfaces, and MAY be sent:

   o  The node ensures that there is  Proactively, at a single Neighbor Tuple
      corresponding 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 the originator of that HELLO message. congestion or network
      stability.

   o  If  As a Link Tuple corresponding response to a change in the link on which that HELLO
      message was received exists, then router itself, or its duration is extended,
      otherwise such 1-hop
      neighborhood, for example on first becoming active or in response
      to a Link Tuple is created.  If the new, broken, or changed status link.

   o  In a combination of these proactive and responsive mechanisms.

   Jittering of HELLO message
      indicates that the receiving generation and transmission, as described
   in Section 11.2, SHOULD be used if appropriate.

   HELLO messages MAY be scheduled independently for each MANET
   interface, or, interface has been heard, then
      the link is considered symmetric, or its duration as symmetric is
      extended.  If parameters permitting, using the same
   schedule for all MANET interfaces of a router.

4.3.2.  HELLO Message Content

   Each HELLO message indicates that the receiving sent on a MANET interface is lost, then need not contain all of
   the link is no longer considered
      symmetric.  In this case one or more Lost Neighbor Tuples may be
      created. information appropriate to that MANET interface, however:

   o  If the link on which the  A HELLO message is received is symmetric,
      then any symmetrically advertised neighbors in MUST contain all of the HELLO message
      are added to addresses in the 2-Hop Local
      Interface Set for of the receiving interface, or if
      already present, router to which the durations MANET interface belongs.

   o  For each MANET interface, within every time interval of length
      equal to the corresponding 2-Hop Tuples
      are extended.

   In all cases parameter REFRESH_INTERVAL, the processing takes account HELLO
      messages sent MUST collectively include:

      *  All of unexpected and erroneous the relevant information in the HELLO message, maintaining Link Set of the constraints
   specified
         Interface Information Base of that MANET interface.

      *  All of the relevant information in Appendix C.

4.4.  Link Quality

   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 Neighbor Information
         Base of a link is OPTIONAL.  If link quality is not that router.

      This applies to be modified otherwise purely responsive routers as well as to
      proactive routers.  In either case it MUST be set means that all information
      appropriate to indicate an that MANET interface will have always usable quality link.  Link
   quality information is only used locally, it is not used been
      transmitted, in
   signaling, and nodes may interoperate whether they are using the
   same, different, one or no, link quality information.

5.  Protocol Parameters and Constants

   The parameters and constants used in more HELLO messages, since the time
      REFRESH_INTERVAL ago.  Note that this specification rule applies at all times,
      not just to times at which HELLO messages are described sent.  In
      considering whether to include information in this section.

5.1.  Interface Parameters

   The interface parameters used by this specification may be classified
   into a HELLO message, the following four categories:

   o  Message intervals

   o  Information validity
      sender MUST consider all times up to when it may send its next
      HELLO message on that MANET interface.

   o  Link quality

   o  Jitter

   These are detailed  A HELLO message MUST include a VALIDITY_TIME Message TLV, as
      specified in [timetlv], that indicates the following sections.

   Different MANET interfaces (on length of time for
      which the same or on different nodes) MAY
   employ different interface parameter values, message content is to be considered valid, and may change their
   interface parameter values dynamically, subject is
      therefore to the constraints
   given be included in this section. the receiving router's Interface
      Information Base.

   o  A particular case is where all MANET
   interfaces on all periodically generated HELLO message SHOULD include an
      INTERVAL_TIME Message TLV, as specified in [timetlv], that
      indicates the current value of HELLO_INTERVAL for that MANET nodes
      interface, i.e. the period within which a given MANET employ the same
   set of interface parameter values.

5.1.1.  Message Intervals

   The following interface parameters regulate further HELLO message
   transmissions over a given is
      guaranteed to be sent on that MANET interface.

   HELLO messages serve two principal functions:

   o  To advertise this node's own addresses to its 1-hop neighbors.
      The frequency of these advertisements is regulated  Additional information may be added by a protocol using this
      protocol using the
      interface parameters HELLO_INTERVAL TLV mechanisms described in [RFC5444].  For
      example, if multipoint relays (MPRs) are to be calculated
      similarly to as in [RFC3626] and HELLO_MIN_INTERVAL.

   o  To advertise signaled to neighbors, then this node's knowledge of each of its 1-hop neighbors.
      The frequency of the advertisement of each such neighbor is
      regulated
      information may be added to HELLO messages using an Address Block
      TLV.

4.3.3.  HELLO Message Processing

   All HELLO messages received by a router are used to update:

   o  The Interface Information Base for the MANET interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - on which
      that HELLO message is received.

   o  The Neighbor Information Base.

   Specifically:

   o  The router 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 the duration for which that Link
      Tuple is kept is extended, otherwise such a
      separation of HELLO_INTERVAL, possibly modified by jitter as
      specified in [RFC5148].

   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, as defined in
      [RFC5148].)

   REFRESH_INTERVAL  - interface
      has been heard, then the link is considered symmetric, or the 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
      duration for which it that Link Tuple is specified kept as sending in at
      least one symmetric is
      extended.  If the HELLO message on this indicates that the receiving 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 [timetlv] are included
      in HELLO messages, is lost, then HELLO_INTERVAL MUST the link is no longer considered
      symmetric.  In this case one or more Lost Neighbor Tuples may be representable as
      described in [timetlv].
      created.

   o  If REFRESH_INTERVAL > HELLO_INTERVAL, the link on which the HELLO message is received is symmetric,
      then a node may distribute its any symmetrically advertised neighbor advertisements between HELLO messages addresses in any manner, subject
   to the constraints above.

   For a node HELLO
      message are added to employ this protocol in a purely responsive manner on a
   MANET the 2-Hop Set for the receiving interface, REFRESH_INTERVAL or
      if already present, the duration for which the corresponding 2-Hop
      Tuples are kept are extended.

   In all cases the processing takes into account unexpected and HELLO_INTERVAL SHOULD both
   erroneous information in the HELLO message, maintaining the
   constraints specified in Appendix B.

4.4.  Link Quality

   Some links in a MANET 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 value is always
   expected recorded with each link in a shorter period than this value.

5.1.2.  Information Validity Times

   The following interface parameters manage the validity time of Link Set. A MANET
   router considers links for which an insufficient link
   information:

   L_HOLD_TIME  - quality is
   recorded to be lost.  Modifying the period of advertisement, on this MANET
      interface, recorded link quality of former 1-hop neighbor addresses as lost a link
   in HELLO
      messages, allowing recipients of these HELLO messages to
      accelerate removal of information from their the Link Sets.
      L_HOLD_TIME can Set is OPTIONAL.  If link quality is not to 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 routers may interoperate whether they are using the VALIDITY_TIME message TLV
      included
   same, different, or no, link quality information.  Link quality
   information is thus not equivalent to a link metric.

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

5.1.3.  Link Quality the following sections.

   Different MANET interfaces (on the same or on different routers) MAY
   employ different interface parameter values, and MAY change their
   interface parameter values dynamically, subject to the constraints
   given in this section.  A particular case is where all MANET
   interfaces on all MANET routers within a given MANET employ the same
   set of interface parameter values.

5.1.1.  Message Intervals

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

   HELLO messages serve two principal functions:

   o  To advertise this router's interface addresses to its 1-hop
      neighbors.  The frequency of link quality
   (see Section 4.4):

   HYST_ACCEPT  - these advertisements is regulated by
      the link quality threshold at or above which a link
      becomes usable, if it was not already so.

   HYST_REJECT  - interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.

   o  To advertise this router's knowledge of each of its 1-hop
      neighbors.  The frequency of the advertisement of each such
      neighbor is regulated by the link quality threshold below which a link
      becomes unusable, if it was not already so.

   INITIAL_QUALITY interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - is the initial quality maximum time between the transmission of two
      successive HELLO messages on this MANET interface.  If using
      periodic transmission of HELLO messages, these SHOULD be at a newly identified link.

   INITIAL_PENDING
      separation of HELLO_INTERVAL, possibly modified by jitter as
      specified in [RFC5148].

   HELLO_MIN_INTERVAL  - if true, then a newly identified link is
      considered pending, and is not usable until the link quality has
      reached or exceeded minimum interval between transmission of
      two successive HELLO messages, on this MANET interface.  (This
      minimum interval MAY be modified by jitter, as defined in
      [RFC5148].)

   REFRESH_INTERVAL  - is the HYST_ACCEPT threshold. 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 router MUST include
      all 1-hop neighbor information that 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 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  HELLO_MIN_INTERVAL >= 0 <= INITIAL_QUALITY <= 1.

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

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

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

5.1.4.  Jitter

   If jitter, INTERVAL_TIME Message TLVs as defined in [RFC5148], is used then these parameters [timetlv] are
   as follows:

   HP_MAXJITTER  - represents the value of MAXJITTER used included
      in [RFC5148]
      for periodically generated HELLO messages on this MANET interface.

   HT_MAXJITTER  - represents the value of MAXJITTER used messages, then HELLO_INTERVAL MUST be representable as
      described in [RFC5148]
      for externally triggered [timetlv].

   If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
   its neighbor advertisements between HELLO messages on this MANET interface.

   For in any manner,
   subject to the constraints on these interface parameters see [RFC5148].

5.2.  Node Parameters

   The two node parameters defined by above.

   For a router to employ this specification are protocol in the
   category of information validity time.

5.2.1. 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 value.

   If a router has more than one MANET interface, then, even if the
   router configures different values of HELLO_INTERVAL on each
   interface, the router SHOULD configure the same value of
   HELLO_MIN_INTERVAL on all interfaces on which responsive HELLO
   messages may be sent.

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 this information from their 2-Hop Link Sets.  N_HOLD_TIME can
      L_HOLD_TIME MAY be set to
      zero zero, if accelerated information removal
      is not required.

   I_HOLD_TIME

   H_HOLD_TIME  - is the period for which a recently used local
      interface address is recorded. as the value in the VALIDITY_TIME Message TLV
      included in all HELLO messages on this MANET interface.

   The following constraints applies apply to these node interface parameters:

   o  N_HOLD_TIME  L_HOLD_TIME >= 0

   o  I_HOLD_TIME  H_HOLD_TIME >= 0

5.3.  Parameter Change Constraints

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

   HELLO_INTERVAL

      * REFRESH_INTERVAL

   o  If the HELLO_INTERVAL for a MANET interface increases, then the
         next HELLO message on this MANET interface MUST be generated
         according to the previous, shorter, HELLO_INTERVAL.  Additional
         subsequent HELLO messages MAY can be generated according to the
         previous, shorter, HELLO_INTERVAL (but MUST include times
         according to current parameters).

      *  If the HELLO_INTERVAL for a MANET interface decreases, lost then the
         following HELLO messages on this MANET interface both parameters SHOULD be
      significantly greater than REFRESH_INTERVAL.

   o  H_HOLD_TIME MUST be
         generated according to this current, shorter, HELLO_INTERVAL.

   REFRESH_INTERVAL

      *  If the REFRESH_INTERVAL for a MANET interface increases, then
         the content of subsequent HELLO messages must be organized such
         that the specification of representable as described in [timetlv].

5.1.3.  Link Quality

   The following interface parameters manage the old value usage of REFRESH_INTERVAL link quality
   (see Section 14):

   HYST_ACCEPT  - is
         satisfied for a further period equal to the old value of
         REFRESH_INTERVAL.

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

   HYST_REJECT  - is the REFRESH_INTERVAL for link quality threshold below which a MANET interface decreases, then link
      becomes unusable, if it MAY be necessary to reschedule HELLO message generation on
         that MANET interface, in order that was not already so.

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

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

   The following constraints apply to these interface parameters:

   o  0 <= HYST_REJECT

      *  If <= HYST_ACCEPT or HYST_REJECT changes, then the appropriate
         actions for <= 1

   o  0 <= INITIAL_QUALITY <= 1.

   o  If link quality change, as specified in Section 14.3
         MUST be taken.

   L_HOLD_TIME

      * is not updated, then INITIAL_QUALITY >=
      HYST_ACCEPT.

   o  If L_HOLD_TIME changes, INITIAL_QUALITY >= HYST_ACCEPT, then L_time for all relevant Link
         Tuples MUST be changed.

   N_HOLD_TIME

      * INITIAL_PENDING := false.

   o  If N_HOLD_TIME changes, INITIAL_QUALITY < HYST_REJECT, then NL_time for all relevant Lost
         Neighbor Tuples MUST be changed.

   HP_MAXJITTER

      * INITIAL_PENDING := true.

5.1.4.  Jitter

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

   HP_MAXJITTER  - represents the periodic HELLO message
         schedule value of MAXJITTER used in [RFC5148]
      for periodically generated HELLO messages on this MANET interface MAY be changed.

   HT_MAXJITTER

      *  If interface.

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

   For constraints on these interface MAY be rescheduled.

5.4.  Constants parameters see [RFC5148].

5.2.  Router Parameters

   The constant C (time granularity) is used as specified two router parameters defined by this specification are in [timetlv].

6.  Local Information Base

   A node maintains a Local Information Base that records the
   category of information
   about its interfaces (MANET and non-MANET).  Each interface MUST have
   at least one address, and MAY have more than one address.

   The Local validity time.

5.2.1.  Information Base is not modified by signaling.  If a node's
   interface configuration changes, then Validity Time

   The following router parameter manages the Local Information Base MUST
   reflect these changes.  This MAY also result in signaling to
   advertise these changes.

6.1.  Local Interface Set

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

      (I_local_iface_addr_list, I_manet)

   where:

   I_local_iface_addr_list lost
   symmetric 1-hop neighbor information:

   N_HOLD_TIME  - is an unordered list of used as the period during which former 1-hop
      neighbor addresses are advertised as lost in HELLO messages,
      allowing recipients of these HELLO messages to accelerate removal
      of this interface.

   I_manet  is a boolean flag, describing information from their 2-Hop Sets.  N_HOLD_TIME MAY be set
      to zero, if this interface accelerated information removal is a MANET
      interface.

6.2.  Removed Interface Address Set

   A node's Removed Interface Address Set records addresses not required.

   I_HOLD_TIME  - is the period for which were a recently used local
      interface addresses.  If a node's interface addresses address is recorded.

   The following constraints applies to these router 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 immutable changed dynamically.

   HELLO_INTERVAL

      *  If the HELLO_INTERVAL for a MANET interface increases, then the
         next HELLO message on this set is always empty and MANET interface MUST be generated
         according to the previous, shorter, HELLO_INTERVAL.  Additional
         subsequent HELLO messages MAY be omitted.  It
   consists of Removed Interface Address Tuples, one per address:

      (IR_local_iface_addr, IR_time)

   where:

   IR_local_iface_addr  is generated according to the
         previous, shorter, HELLO_INTERVAL (but MUST include times
         according to current parameters).

      *  If the HELLO_INTERVAL for a recently used address of an MANET interface of
      this node.

   IR_time  specifies when decreases, then the
         following HELLO messages on this Tuple expires and MANET interface MUST be removed.

7.  Interface Information Base

   A node maintains an Interface Information Base for each of its MANET
   interfaces.  This records information about links
         generated according to that this current, shorter, HELLO_INTERVAL.

   REFRESH_INTERVAL

      *  If the REFRESH_INTERVAL for a MANET interface and symmetric 2-hop neighbors which can be reached in two
   hops using those links as increases, then
         the first hop.  The Interface Information
   Base includes content of subsequent HELLO messages must be organized such
         that the Link Set and specification of the 2-Hop Set.

   A MANET interface address can be present as old value of both a 1-hop neighbor
   and REFRESH_INTERVAL is
         satisfied for a symmetric 2-hop neighbor.  This allows further period equal to the node with this old value of
         REFRESH_INTERVAL.

      *  If the REFRESH_INTERVAL for a MANET interface address to decreases, then
         it MAY be immediately considered as a symmetric 2-hop
   neighbor if it fails necessary to be a symmetric 1-hop neighbor.

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 an unordered list of the addresses of
      the reschedule HELLO message generation on
         that MANET interface of the 1-hop neighbor;

   L_HEARD_time  is the time until which interface, in order that the MANET interface specification of the
      1-hop neighbor would be considered heard if not considering link
      quality;

   L_SYM_time
         REFRESH_INTERVAL is satisfied from the time until which the link to the 1-hop neighbor
      would be considered symmetric if not considering link quality;

   L_quality  is a dimensionless number between 0 (inclusive) of change.

   HYST_ACCEPT and 1
      (inclusive) describing HYST_REJECT

      *  If HYST_ACCEPT or HYST_REJECT changes, then 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 appropriate
         actions for link quality; 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 is denoted L_status.

   L_status can take the values PENDING, HEARD, SYMMETRIC and LOST.  The
   values LOST, SYMMETRIC and HEARD are defined in Section 17.3.
         schedule on this MANET interface MAY be changed.

   HT_MAXJITTER

      *  If HT_MAXJITTER changes, then externally triggered HELLO
         messages on this MANET interface MAY be rescheduled.

5.4.  Constants

   The
   value PENDING constant C (time granularity) is never used as specified in [timetlv].

6.  Local Information Base

   A router maintains a message, it Local Information Base that records information
   about its interfaces (MANET and non-MANET).  Each interface MUST have
   at least one address, and MAY have more than one address.

   The Local Information Base is only used locally not modified by signaling.  If a node,
   router's interface configuration changes, then the Local Information
   Base MUST reflect these changes.  This MAY also result in signaling
   to advertise these changes.

   Interfaces and any value distinct addresses MAY be excluded from LOST, SYMMETRIC the Local Information
   Base, and HEARD may be
   used.

   L_status is defined by:

   1.  If L_pending is true, then L_status = PENDING;

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

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

   4.  otherwise, hence from HELLO messages, if L_HEARD_time is they are not expired, then L_status = HEARD;

   5.  otherwise, L_status = LOST.

7.2.  2-Hop to be used for
   routing.

6.1.  Local Interface Set

   A node's 2-Hop router's Local Interface 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. its local interfaces.  It
   consists of 2-Hop Local Interface 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 an unordered list one per interface:

      (I_local_iface_addr_list, I_manet)

   where:

   I_local_iface_addr_list  is an unordered 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 Information Base that records information
   about addresses of current and recently symmetric 1-hop neighbors.

8.1.  Neighbor Set

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

      (N_neighbor_iface_addr_list, N_symmetric)

   where:

   N_neighbor_iface_addr_list  is an unordered list of the interface
      addresses of a 1-hop neighbor;

   N_symmetric interface.

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

8.2.  Lost Neighbor MANET
      interface.

   Local Interface Tuples are removed from the Local Interface Set only
   when the routers' interface configuration changes, subject to
   Section 9, i.e. they are not subject to timer-based expiration.

6.2.  Removed Interface Address Set

   A node's Lost Neighbor router's 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 router'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 router.

   IR_time  specifies when this Tuple expires and MUST be removed.

9.  Local Information Base Changes

   The Local

7.  Interface Information Base MUST change to respond

   A router maintains an Interface Information Base 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 local interface configuration. 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 the
   addition address can be present as of both a Local Interface Tuple to the Local Interface Set. If
   the new interface is 1-hop neighbor
   and a MANET interface then an initially empty
   Interface Information Base MUST be created for symmetric 2-hop neighbor.  This allows the router with this new
   MANET
   interface.  The actions in Section 9.3 MUST be taken for each interface address
   of this added interface.  A HELLO message MAY be sent on all MANET
   interfaces, it SHOULD to 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 an Interface

   If an interface symmetric 1-hop neighbor.

   An element which specifies a time is removed from considered expired if the node, then this MUST result in
   changes
   current time is greater than or equal to the Local Information Base and the Node Information Base
   as follows:

   1.  Identify the Local Interface Tuple that corresponds to time.  One such element
   in most Tuples when expired indicates that the
       interface to Tuple itself is
   considered expired and MUST be removed.

   2.  For each address (henceforth removed address) in the
       I_local_iface_addr_list of when that Local Interface Tuple, create element so
   indicates.  Tuples which do not have such a
       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 element are removed is a MANET interface (i.e. with
       I_manet == true) then:

       1.  Remove the Interface Information Base
   at other times as specified, for that MANET
           interface;
       2.  All example a Neighbor Tuple is removed
   when all corresponding Link Tuples for have been removed.

7.1.  Link Set

   A router's Link Set records links from other routers which none are, or
   recently were, 1-hop neighbors.  It consists 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 Tuples, each
   representing a node removes the Local Interface Tuple that contains the
   interface address that 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 used to define the node's originator
   address, as defined in [packetbb], then an unordered list of the node MAY change
   originator address.

   If addresses of
      the removed MANET interface of the 1-hop neighbor;
   L_HEARD_time  is the last time until which the MANET interface of the node,
   then there will
      1-hop neighbor would be no remaining Interface Information Bases, and considered heard if not considering link
      quality;

   L_SYM_time  is the
   node will longer participate in this protocol.

   After removing time until which the interface and making these changes, a HELLO
   message MAY be sent on all remaining MANET interfaces.

9.3.  Adding an Address to an Interface

   If an address is added to an interface then this is indicated by the
   addition of an address link to the appropriate I_local_iface_addr_list.
   The following changes MUST 1-hop neighbor
      would be made to the Information Bases:

   1.  The Neighbor Tuples, considered symmetric if any, whose N_neighbor_iface_addr_list
       contains the added address, are removed.

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

       *  the added address; OR

       *  any address in not considering link quality;

   L_quality  is a dimensionless number between 0 (inclusive) and 1
      (inclusive) describing the N_neighbor_iface_addr_list quality of the removed
          Neighbor Tuples, a link; a greater value of
      L_quality indicating a higher quality link;

   L_pending  is a boolean flag, describing if any

       are removed; apply Section 13.1, a link is considered
      pending (i.e. a candidate, 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 yet established, link);

   L_lost  is the added address,
       are removed.

   After adding the address and making these changes, a HELLO message
   MAY be sent on all MANET interfaces.

9.4.  Removing an Address from an Interface

   If an address (henceforth removed address) boolean flag, describing if a link is removed from an
   interface then:

   1.  Identify the Local Interface Tuple that corresponds to the
       interface considered lost
      due to link quality;

   L_time  specifies when this Tuple expires and MUST be removed.

   2.  If this is the only address

   The status of that interface (the only address
       in the corresponding I_local_iface_addr_list) then remove that
       interface link, as specified in Section 9.2.

   3.  Otherwise:

       1.  Remove the removed address from this I_local_iface_addr_list.

       2.  Create a Removed Interface Address Tuple with:

           +  IR_local_iface_addr = removed address;

           +  IR_time = current time + I_HOLD_TIME.

   If a node removes the interface address that is used to define the
   node's originator address, as defined in [packetbb], then the node
   MAY change originator address.

   After removing the address and making these changes, a obtained through HELLO message
   MAY be sent on all MANET interfaces.

10.  Packets exchange,
   and Messages also taking link quality into account, is denoted L_status.
   L_status can take the values PENDING, HEARD, SYMMETRIC and LOST.  The packet
   values LOST, SYMMETRIC and message format used by this protocol is HEARD are defined in
   [packetbb], which Section 17.5.  The
   value PENDING is never used with the following considerations:

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

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

   o  HELLO messages MUST NOT be forwarded.

   o HELLO messages MAY be included in multi-message packets as
      specified in [packetbb].

   o  Packet header options MAY be message, it is only used as specified
   locally by a protocol which
      uses this neighborhood discovery protocol.

   o  Received HELLO messages MUST router, and any value distinct from LOST, SYMMETRIC and
   HEARD may be parsed in accordance with
      [packetbb].  A HELLO message which used.

   L_status is not in conformance with
      [packetbb] MUST be discarded.

   o  This protocol specifies three address block TLVs.  It also uses
      two message TLVs defined in [timetlv].  These five TLV types are
      all defined only with Type Extension == 0.  TLVs of other types,
      and of these types but without Type Extension == 0, are ignored by
      this protocol.  All references in this protocol to, for example, a
      TLV with Type == LINK_STATUS, are to be considered as referring to
      a TLV with Type == LINK_STATUS and Type Extension == 0.

10.1.  HELLO Messages

   A HELLO message MUST contain:

   o  A VALIDITY_TIME message TLV as specified in [timetlv],
      representing H_HOLD_TIME for the transmitting MANET interface.
      The options included in [timetlv] for representing zero and
      infinite times MUST NOT be used.

   A HELLO message which by:

   1.  If L_pending = true, then L_status := PENDING;

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

   3.  otherwise, if L_SYM_time is transmitted periodically SHOULD contain, and
   otherwise MAY contain:

   o  An INTERVAL_TIME message TLV as specified in [timetlv],
      representing HELLO_INTERVAL for the transmitting MANET interface.
      The options included in [timetlv] for representing zero and
      infinite times MUST NOT be used. 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 HELLO message MAY contain:

   o  One or more address blocks, each with an associated TLV block.

   o  Other message TLVs.

10.1.1.  Address Blocks

   All addresses in a node's Local Interface router's 2-Hop Set (i.e. in any
   I_local_iface_addr_list) MUST be included in the address blocks in
   all generated HELLO messages with the following exception.  If the
   MANET records symmetric 2-hop neighbor interface on which
   addresses, and the HELLO message is symmetric links to symmetric 1-hop neighbors
   through which the symmetric 2-hop neighbors can be sent has reached.  It
   consists of 2-Hop Tuples, each representing a single interface
   address with maximum prefix length then that address MAY be
   omitted.  All addresses of the node's interfaces included in an
   address block MUST be associated with a TLV with Type == LOCAL_IF, as
   defined in Table 1.

   +----------+---------+----------------------------------------------+
   |   Name   |  Value  | Description                                  |
   |          |  Length |                                              |
   +----------+---------+----------------------------------------------+
   | LOCAL_IF | 1 octet | Specifies that the address 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 an address     |
   |          |         | associated with the interface on which unordered list of the   |
   |          |         | message was sent (THIS_IF), another          |
   |          |         | interface addresses of
      the sending node (OTHER_IF), or |
   |          |         | an unspecified MANET interface of the sending node |
   |          |         | (UNSPEC_IF).                                 |
   +----------+---------+----------------------------------------------+

                                  Table 1

   Note that the value UNSPEC_IF is not used by symmetric 1-hop neighbor from which
      this protocol.  It information was received;

   N2_2hop_iface_addr  is
   provided for an expected alternative use 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 TLV.

   Address blocks MAY contain Tuple expires and MUST be removed.

8.  Neighbor Information Base

   Each router maintains a Neighbor Information Base that records
   information about addresses of current or and recently lost symmetric 1-hop neighbors'
   neighbors.

8.1.  Neighbor Set

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

      (N_neighbor_iface_addr_list, N_symmetric)

   where:

   N_neighbor_iface_addr_list  is associated with address block
   TLVs as described in Table 2.

   +--------------+---------+------------------------------------------+
   |     Name     |  Value  | Description                              |
   |              |  Length |                                          |
   +--------------+---------+------------------------------------------+
   |  LINK_STATUS | 1 octet | Specifies the status an unordered list of the link from    |
   |              |         | the indicated address (LOST, SYMMETRIC   |
   |              |         | or HEARD).                               |
   |              |         |                                          |
   | OTHER_NEIGHB | 1 octet | Specifies that the address is            |
   |              |         | (SYMMETRIC) or was (LOST) of an          |
   |              |         | interface
      addresses of a 1-hop neighbor;

   N_symmetric  is a boolean flag, describing if this is a symmetric
      1-hop neighbor  |
   |              |         | of neighbor.

   Neighbor Tuples are removed from the node transmitting Neighbor Set only when
   corresponding Link Tuples expire from the HELLO       |
   |              |         | message.                                 |
   +--------------+---------+------------------------------------------+

                                  Table 2 routers' Link Set, i.e.
   Neighbor Tuples are not directly subject to timer-based expiration.

8.2.  Lost Neighbor Set

   A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
   LOST) also performs the function router's Lost Neighbor Set records addresses of all interfaces of
   routers which recently were symmetric 1-hop neighbors, but are now
   advertised as lost.  It consists of Lost Neighbor Tuples, each
   representing a TLV with Type == OTHER_NEIGHB
   and the same value.  The latter SHOULD NOT also be included.  If a
   TLV with Type == LINK_STATUS and Value == SYMMETRIC single such address:

      (NL_neighbor_iface_addr, NL_time)

   where:

   NL_neighbor_iface_addr  is combined with
   a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter
   MUST be ignored, and SHOULD NOT be included.  See Appendix A.

   Other addresses MAY be included in an address blocks, but MUST NOT be
   associated with any of the TLVs specified in this section.

11.  HELLO Message Generation

   Each MANET an interface MUST generate HELLO messages according to the
   specification in of a router
      which recently was a symmetric 1-hop neighbor of this section.  HELLO message generation router;

   NL_time  specifies when this Tuple expires and
   scheduling MUST be according to the interface parameters for that
   MANET removed.

9.  Local Information Base Changes

   The Local Information Base MUST change to respond to changes in the
   router's local interface configuration.  The router MUST update its
   Interface Information Base and MAY Neighbor Information Base in response
   to such changes.  If any changes in the Interface Information Base or
   the Neighbor Information Base satisfy any of the conditions described
   in Section 13, then those changes must be independent for each MANET interface or,
   interface parameters permitting, MANET interfaces applied immediately, unless
   noted otherwise.

   A router MAY use the same
   schedule.

   If transmitting periodic transmit HELLO messages then, following a HELLO
   message transmission on in response to these changes.

9.1.  Adding an Interface

   If an interface is added to the router then this is indicated by the
   addition of a MANET interface, another HELLO message MUST
   be transmitted on Local Interface Tuple to the same MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive HELLO message
   transmissions on Local Interface Set. If
   the same new interface is a MANET interface then an initially empty
   Interface Information Base 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 each created for this new MANET
   interface.

   All addresses  The actions in any I_local_iface_addr_list Section 9.3 MUST be included, except
   that:

   o  If the interface on which the taken for each address
   of this added interface.  A HELLO message is to MAY be sent has a
      single on all MANET
   interfaces, it SHOULD be sent on the new interface address with maximum prefix length if it is a MANET
   interface.  If using scheduled messages, then that
      interface address MAY be omitted.

   All such included addresses a message schedule MUST
   be associated with established on a TLV with Type
   == LOCAL_IF and value according to the following:

   o new MANET interface.

9.2.  Removing an Interface

   If the address an interface is of removed from the sending interface, router, then Value == THIS_IF.

   o  Otherwise, Value == OTHER_IF.

   The following addresses of current or former 1-hop neighbors MAY be
   included this MUST result in any HELLO message:

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

   o  Other addresses of symmetric 1-hop neighbors from and to 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
   Base as follows:

   1.  Identify the Local Interface Information Base for this MANET interface.
      (These are advertised for a period equal Tuple that corresponds to this interface's
      L_HOLD_TIME after loss.)
   o  Other 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
       interface to N_HOLD_TIME after loss.)

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

   1. removed.

   2.  For each address (henceforth linked removed address) which appears in the
       I_local_iface_addr_list of that Local Interface Tuple, create a
       Link
       Removed Interface Address 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  IR_local_iface_addr := removed address;
       *  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 associated TLV with (Type == LINK_STATUS and Value ==
       SYMMETRIC), include the neighbor address with an associated TLV
       with:

       *  Type = OTHER_NEIGHB; AND

       *  Value = SYMMETRIC.  IR_time := current time + I_HOLD_TIME.

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

       *  Type = OTHER_NEIGHB; AND

       *  Value = LOST. Local Interface Set.

   4.  If a 1-hop neighbor 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 the interface to be included
   associated with that address in removed is a HELLO message sent on that MANET interface in every interval of length equal to (i.e. with
       I_manet = true) then:

       1.  Remove the Interface Information Base for that MANET interface's
   parameter REFRESH_INTERVAL.  TLVs associated with
           interface;

       2.  All Neighbor Tuples for which none of the same address
   included addresses in its
           N_neighbor_iface_addr_list are contained in any
           L_neighbor_iface_addr_list in any remaining Link Set, are
           removed.

   If a router removes the same HELLO message MAY be applied Local Interface Tuple that contains the
   interface address which is used to define the same or
   different copies of that address.

11.2.  HELLO Message Transmission

   HELLO messages are transmitted router's originator
   address, as defined in [RFC5444], then the packet/message format specified router MAY change
   originator address.  If this interface address may now be used by [packetbb] using
   another router (e.g. if the "LL-MANET-Routers" multicast address
   specified by [manet-iana] as destination IP address, using either the
   "manet" UDP port, was taken from a prefix no longer
   delegated to this router, or if the "manet" IP protocol number specified in
   [manet-iana].

11.2.1.  HELLO Message Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If using data link address was assigned with an
   expiration timer, and
   physical layers which are subject to packet loss due to collisions,
   HELLO messages SHOULD be jittered as described in [RFC5148].

   Internally triggered message generation (such as due to a change in
   local interfaces) MAY be treated as if externally generated message
   generation, or MAY be not jittered.

   HELLO messages renewed before expiration) then this router
   MUST NOT change originator address.

   If the removed interface is the last MANET interface of the router,
   then there will be forwarded, no remaining Interface Information Bases, and thus message forwarding
   jitter does not apply to HELLO messages.

   Each form of jitter described the
   router will longer participate in [RFC5148] requires a parameter
   MAXJITTER.  These this protocol.

   After removing the interface parameters may be dynamic, and are
   specified by:

   o  For periodic message generation: HP_MAXJITTER.

   o  For externally triggered message generation: HT_MAXJITTER.

   When HELLO message generation is delayed in order that making these changes, a HELLO
   message is not MAY be sent within HELLO_MIN_INTERVAL of the previous HELLO
   message on the same all remaining MANET interface, interfaces.

9.3.  Adding an Address to an Interface

   If an address is added to an interface then HELLO_MIN_INTERVAL SHOULD
   be reduced by jitter, with maximum reduction HP_MAXJITTER.  In this
   case HP_MAXJITTER is indicated by the
   addition of an address to the appropriate I_local_iface_addr_list.
   The following changes MUST NOT be greater than HELLO_MIN_INTERVAL.

12.  HELLO Message Processing

   On receiving a HELLO message, a node MUST first check made to the Information Bases:

   1.  The Neighbor Tuples, if any address
   associated with a TLV with Type == LOCAL_IF is one of any, whose N_neighbor_iface_addr_list
       contains the receiving
   node's current or recently used interface addresses (i.e. is added address, are removed.

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

       *  the Local Interface Set or is equal to added address; OR

       *  any
   IR_local_iface_addr address in the Removed Interface Address Set).  If so
   then N_neighbor_iface_addr_list of any removed
          Neighbor Tuple
       are removed; apply Section 13.2, but not Section 13.3.

   3.  Any Lost Neighbor Tuples whose NL_neighbor_iface_addr = the added
       address, are removed.

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

   After adding the address and making these changes, a HELLO message MUST
   MAY be discarded.

   Otherwise sent on all MANET interfaces.

9.4.  Removing an Address from an Interface

   If an address (henceforth removed address) is removed from an
   interface then:

   1.  Identify the receiving node MUST update its appropriate Local Interface
   Information Base and its Node Information Base according Tuple that corresponds to this
   section.  Section 12.1 the
       interface to Section 12.4 MUST be performed in the order
   presented. removed.

   2.  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 only address of that interface (the only address
       in the HELLO message corresponding I_local_iface_addr_list) then remove that
       interface as specified in [timetlv].  All information
      in Section 9.2.

   3.  Otherwise:

       1.  Remove the HELLO message has the same validity time.

   o  "Receiving removed address from this I_local_iface_addr_list.

       2.  Create a Removed Interface Address List" is the I_local_iface_addr_list
      corresponding to Tuple with:

           +  IR_local_iface_addr := removed address;

           +  IR_time := current time + I_HOLD_TIME.

   If a router removes the MANET interface on which the HELLO message
      was received

   o  "Sending Address List" address that is used to define the list of the addresses contained
   router's originator address, as defined in
      the HELLO message with an associated TLV with Type == LOCAL_IF and
      Value == THIS_IF.  If the Sending Address List is otherwise empty, [RFC5444], then the Sending Address List contains a single router
   MAY change originator address.  If this interface address (with
      maximum prefix length) equal to may now be
   used by another router then this router MUST change originator
   address.

   After removing the sending address of the IP
      datagram in which the and making these changes, a HELLO message was included.

   o  "Neighbor Address List"
   MAY be sent on all MANET interfaces.

10.  Packets and Messages

   The packet and message format used by this protocol is the Sending Address List, plus the
      addresses contained defined in the HELLO message with an associated TLV
   [RFC5444], which is used with Type == LOCAL_IF and Value == OTHER_IF. the following considerations:

   o  EXPIRED indicates that a timer is set to a value clearly preceding  This protocol specifies one Message Type, the current time (e.g. current time - 1). HELLO message.

   o  "Removed Address List" is a list of addresses created by this  A HELLO message processing which were formerly reported as local by
      the node originating the MAY use any combination of Message Header options.

   o  HELLO message, but which are not included
      in the Neighbor Address List.  This list is initialized messages MUST NOT be forwarded.

   o  HELLO messages MAY be included in multi-message packets as empty.
      specified in [RFC5444].

   o  "Lost Address List" is a subset of the Removed Address List
      containing addresses  Received HELLO messages MUST be parsed in accordance with
      [RFC5444].  A HELLO message 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 not in conformance with
      [RFC5444] MUST update its Neighbor Set
   and populate the Removed Address List and Lost be discarded.  A HELLO message may also be
      discarded for other reasons, see Section 12.1.

   o  This protocol specifies three Address List:

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

       *  N_neighbor_iface_addr_list contains at least one address Block TLVs.  It also uses
      two Message TLVs defined in
          the Neighbor Address List.

   2.  If there [timetlv].  These five TLV Types are no matching Neighbor Tuples, then:

       1.  Create a new Neighbor Tuple with:

           +  N_neighbor_iface_addr_list = Neighbor Address List;

           +  N_symmetric
      all defined only with Type Extension = false.

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

       1.  If the N_neighbor_iface_addr_list 0.  TLVs of the matching Neighbor
           Tuple is not equal to the Neighbor Address List, then:

           1.  For each address (henceforth removed address) which is in
               the N_neighbor_iface_addr_list, other types,
      and of these types but not without Type Extension = 0, are ignored by
      this protocol.  All references in the Neighbor this protocol to, for example,
      an Address List:

               1.  Add the removed address Block TLV with Type = LINK_STATUS, are to the Removed be considered
      as referring to an Address List.

               2.  If N_symmetric == true, then add the removed address
                   to Block TLV with Type = LINK_STATUS and
      Type Extension = 0.

10.1.  HELLO Messages

   A HELLO message MUST contain:

   o  A VALIDITY_TIME Message TLV as specified in [timetlv],
      representing H_HOLD_TIME for the Lost Address List.

           2.  Update transmitting MANET interface.
      The options included in [timetlv] for representing zero and
      infinite times MUST NOT be used.

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

   o  An INTERVAL_TIME Message TLV as specified in [timetlv],
      representing HELLO_INTERVAL for the matching Neighbor Tuple by:

               -  N_neighbor_iface_addr_list = Neighbor Address List.

   4.  If there are two transmitting MANET interface.
      The options included in [timetlv] for representing zero and
      infinite times MUST NOT be used.

   A HELLO message MAY contain:

   o  Other Message TLVs.

   o  One or more matching Neighbor Tuples, then:

       1.  For Address Blocks, each address (henceforth removed address) with an associated Address Block
      TLV Block, which is MAY contain other Address Block TLVs.

10.1.1.  Address Blocks

   All addresses in a router's Local Interface Set (i.e. in the
           N_neighbor_iface_addr_list of any of the matching Neighbor
           Tuples:

           1.  Add the removed address to
   I_local_iface_addr_list) MUST be included in the Removed Address List.

           2.  If N_symmetric == true, then add Blocks in
   all generated HELLO messages with the removed address to following exception.  If the Lost Address List.

       2.  Replace
   MANET interface on which the matching Neighbor Tuples by HELLO message is to be sent has a single Neighbor
           Tuple with:

           +  N_neighbor_iface_addr_list = Neighbor
   interface address with maximum prefix length, then that address MAY
   be omitted from being included in an Address List;

           +  N_symmetric = false

12.2.  Updating Block, provided that
   this address is included as the Lost Neighbor Set

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

   1.  For each sending address (henceforth lost address) of the IP datagram in
   which the Lost HELLO message is included.  All addresses of the router's
   interfaces included in an Address
       List, if no Lost Neighbor Tuple Block MUST be associated with NL_neighbor_iface_addr ==
       lost address exists, then add a Lost Neighbor Tuple with:

       *  NL_neighbor_iface_addr = lost address;

       *  NL_time an
   Address Block TLV with Type = current time + N_HOLD_TIME.

12.3.  Updating LOCAL_IF, as defined in Table 1.

   +----------+---------+----------------------------------------------+
   |   Name   |  Value  | Description                                  |
   |          |  Length |                                              |
   +----------+---------+----------------------------------------------+
   | LOCAL_IF | 1 octet | Specifies that the Link Set

   On receiving a HELLO message, a node MUST update its Link Set for address is an address     |
   |          |         | associated with the
   MANET interface on which the HELLO   |
   |          |         | message is received:

   1.  Remove all addresses in was sent (THIS_IF) or another        |
   |          |         | interface of the Removed sending router (OTHER_IF).  |
   +----------+---------+----------------------------------------------+

                     Table 1: LOCAL_IF TLV definition

   Address List from the
       L_neighbor_iface_addr_list Blocks MAY contain current or recently lost 1-hop neighbors'
   interface addresses, each of all Link Tuples.

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

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

       *  L_neighbor_iface_addr_list contains one or more addresses associated with Address Block
   TLVs as described in Table 2.

   +--------------+---------+------------------------------------------+
   |     Name     |  Value  | Description                              |
   |              |  Length |                                          |
   +--------------+---------+------------------------------------------+
   |  LINK_STATUS | 1 octet | Specifies the Sending 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 new matching
       Link Tuple with:

       *  L_neighbor_iface_addr_list = empty;

       *  L_HEARD_time = EXPIRED;

       *  L_SYM_time = EXPIRED;
       *  L_quality = INITIAL_QUALITY;

       *  L_pending = INITIAL_PENDING;

       *  L_lost = false;

       *  L_time = current time + validity time.

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

       1.  If status of the node finds any address (henceforth receiving address)
           in link from    |
   |              |         | the Receiving Address List in an indicated address block in the
           HELLO message, then (LOST, SYMMETRIC   |
   |              |         | or HEARD).                               |
   | OTHER_NEIGHB | 1 octet | Specifies that the Link Tuple is modified as follows:

           1.  If any receiving address in the HELLO message is
               associated with            |
   |              |         | (SYMMETRIC) or was (LOST) of an          |
   |              |         | interface of a symmetric 1-hop neighbor  |
   |              |         | of the router transmitting the HELLO     |
   |              |         | message.                                 |
   +--------------+---------+------------------------------------------+

           Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition

   An Address Block TLV with Type == = LINK_STATUS and (Value
               == HEARD Value = SYMMETRIC or
   Value == SYMMETRIC) then:

               -  L_SYM_time = current time + validity time.

           2.  Otherwise if any receiving address in LOST also performs the HELLO message
               is associated function of an Address Block TLV with a
   Type = OTHER_NEIGHB and the same value.  The latter SHOULD NOT also
   be included.  If an Address Block TLV with Type == = LINK_STATUS and
   Value == LOST then:

               1.  if L_SYM_time has not expired, then:

                   1.  L_SYM_time = EXPIRED.

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

                       *  L_time = current time + L_HOLD_TIME.

       2.  L_neighbor_iface_addr_list = Sending SYMMETRIC is combined with an Address List.

       3.  L_HEARD_time = max(current time + validity time, L_SYM_time).

       4.  If L_status == PENDING, then:

           +  L_time Block TLV with Type = max(L_time, L_HEARD_time).

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

           +  L_time
   OTHER_NEIGHB and Value = max(L_time, L_HEARD_time + L_HOLD_TIME).

12.4.  Updating LOST then the 2-Hop Set

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

   1.  Remove all be ignored, and
   SHOULD NOT be included.  See Appendix A.

   Other addresses MAY be included in the Removed Address List from the
       N2_neighbor_iface_addr_list Blocks, but MUST NOT be
   associated with any of all 2-Hop Tuples.

   2.  If the Link Tuple with L_neighbor_iface_addr_list == Sending Address List has L_status == SYMMETRIC then:

       1.  For each address (henceforth 2-hop address) Block TLVs specified in an address
           block of the this
   specification.

11.  HELLO message, which is not in Message Generation

   Each MANET interface MUST generate HELLO messages according to the Neighbor
           Address List,
   specification in any I_local_iface_addr_list, or equal this section.  HELLO messages are generated for each
   HELLO interface independently.  HELLO message generation and
   scheduling MUST be according 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 interface parameters for that
   MANET interface, and Value == SYMMETRIC,

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

               -  N2_neighbor_iface_addr_list contains one or more
                  addresses in MAY be independent for each MANET interface or,
   interface parameters permitting, MANET interfaces MAY use the Sending Address List; AND

               -  N2_2hop_iface_addr == 2-hop address.

               then create same
   schedule.

   If transmitting periodic HELLO messages then, following 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 HELLO
   message transmission on 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 MANET interface, another HELLO message MUST
   be changed when some
   events occur.  These events may result from transmitted on the same MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive HELLO message processing,
   or may
   transmissions on the same MANET interface MUST be otherwise separated by at
   least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.

11.1.  HELLO Message Specification

   HELLO messages are generated (e.g. expiry of timers or link quality
   changes).

   Events which cause changes independently on each MANET interface.

   All addresses in the Information Bases are: any I_local_iface_addr_list MUST be included, except
   that:

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

   o  A Link Tuple's state changes to symmetric.

   o  A Link Tuple's L_HEARD_time expires, or interface on which the Link Tuple HELLO message is removed.

   o  Local to be sent has a
      single interface address with maximum prefix length then that
      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 be omitted, provided that this address is
      included as the sending address of these
   changes in HELLO message(s), subject to the constraints IP datagram in
   Section 11.

   A node which transmits the
      HELLO messages in response to message is included.

   All such changes
   SHOULD transmit a HELLO message: included addresses MUST be associated with an Address Block
   TLV included with Type := LOCAL_IF and Value according to the
   following:

   o  On all MANET interfaces, if  If the Neighbor Set changes such as to
      indicate address is an address of the change in symmetry sending interface, then Value
      := THIS_IF.

   o  Otherwise, Value := OTHER_IF.

   The following addresses of any 1-hop neighbors (including
      addition current or removal of symmetric former 1-hop neighbors). neighbors MAY be
   included in any HELLO message:

   o  Otherwise, on all those  Addresses of MANET interfaces whose Link Set changes
      such as to indicate a change in status of any 1-hop neighbors
      (including from the addition or removal Link Set
      of any 1-hop neighbors, the Interface Information Base for this MANET interface, other
      than those considered pending).

13.1.  Link Tuple Not Symmetric

   If for any from Link Tuple Tuples with L_status == SYMMETRIC: = PENDING.

   o  L_status changes to any other value; OR  Other addresses of symmetric 1-hop neighbors from the Neighbor Set
      of this router's Neighbor Information Base.

   o  Addresses of MANET interfaces of previously symmetric or heard
      1-hop neighbors connected on this MANET interface from the Link Tuple is removed;

   then:

   1.  All 2-Hop Tuples for
      Set of the same Interface Information Base for this MANET interface with:

       *  N2_neighbor_iface_addr_list contains one or more addresses in
          L_neighbor_iface_addr_list; interface.
      (These are removed.

   2.  For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list:

       1.  If there advertised for a period equal to this interface's
      L_HOLD_TIME after loss.)

   o  Other addresses of previously symmetric 1-hop neighbors from the
      Lost Neighbor Set of this router's Neighbor Information Base.
      (These are no remaining Link Tuples advertised for any a period equal to N_HOLD_TIME after
      loss.)

   Each such address MUST be associated with one or more appropriate
   Address Block TLVs, respecting the parameter REFRESH_INTERVAL for
   each association for each MANET interface
           with:

           +  L_neighbor_iface_addr_list interface.  Specifically:

   1.  For each address (henceforth linked address) which is contained
       in
              N_neighbor_iface_addr_list; AND

           + an L_neighbor_iface_addr_list of a Link Tuple in the Link Set
       for this MANET interface, for which L_status == SYMMETRIC;

           then modify != PENDING, include
       the Neighbor Tuple by:

           1.  N_symmetric = false. linked address with an associated Address Block TLV with:

       *  Type := LINK_STATUS; AND

       *  Value := L_status.

   2.  For each address (henceforth neighbor address) which is contained
       in an N_neighbor_iface_addr_list in
               N_neighbor_iface_addr_list, add a Lost Neighbor Tuple
               with:

               -  NL_neighbor_iface_addr = neighbor address;

               -  NL_time with
       N_symmetric = current time + N_HOLD_TIME.

13.2.  Link Tuple Symmetric

   If, for any Link Tuple true, and which does has 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 already been included with
       an associated Address Block TLV with Type = LINK_STATUS and Value
       = SYMMETRIC, include the Neighbor Tuple whose N_neighbor_iface_addr_list includes
       L_neighbor_iface_addr_list, set: neighbor address with an associated
       Address Block TLV with:

       *  N_symmetric = true.

   2.  Remove all  Type := OTHER_NEIGHB; AND

       *  Value := SYMMETRIC.

   3.  For each Lost Neighbor Tuples Tuple whose 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
       (henceforth lost address) has not already been included, include
       the Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list, if no Link Tuples for any MANET
       interface remain lost address with an associated Address Block TLV with:

       *  L_neighbor_iface_addr_list contained in
          N_neighbor_iface_addr_list;  Type := OTHER_NEIGHB; AND

       *  L_HEARD_time is not expired;

       then remove  Value := LOST.

   If any such addresses have been added since the Neighbor Tuple.

14.  Link Quality

   Link quality is a mechanism whereby a node MAY take considerations
   other than last HELLO message exchange into account for determining when a link
   is and is not a candidate for being considered as HEARD
   was sent on this MANET interface, 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 if their status (as indicated by a node,
   these TLVs 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, values they associate with that address) have
   changed since that address was last reported on this MANET interface,
   then that address, and the node indicated TLVs, 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, be included in the L_quality value of
   HELLO message.

   If a Link Tuple 1-hop neighbor address is
   used specified with more than one
   associated Address Block TLV, then these Address Block TLVs MAY be
   independently included or excluded from each HELLO message.  Each
   such Address Block TLV MUST be included associated with that address
   in conjunction a HELLO message sent on that MANET interface in every interval of
   length equal to that MANET interface's parameter REFRESH_INTERVAL.
   Address Block TLVs associated with two thresholds, HYST_ACCEPT and HYST_REJECT, the same address included in the
   same HELLO message MAY be applied to set the flags L_pending and L_lost same or different copies of
   that Link Tuple.  Based on
   these flags, address.

11.2.  HELLO Message Transmission

   HELLO messages are transmitted in the packet/message format specified
   by [RFC5444] using the "LL-MANET-Routers" multicast address specified
   by [manet-iana] as destination IP address, using either the "manet"
   UDP port, or the "manet" IP protocol number specified in
   [manet-iana].

11.2.1.  HELLO Message Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If using data link status and
   physical layers which are subject to advertise for that Link Tuple is
   determined packet loss due to collisions,
   HELLO messages SHOULD be jittered as described in Section 7.1.

   The use of two thresholds implements link hysteresis, whereby [RFC5148].

   Internally triggered message generation (such as due to a link
   which has HYST_REJECT <= L_quality < HYST_ACCEPT may change in
   local interfaces) MAY be either
   accepted or rejected (depending on which threshold it has most
   recently crossed, or treated as 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 externally generated message
   generation, or MAY be not jittered.

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

   Each form of jitter described in [RFC5148] requires a neighbor parameter
   MAXJITTER.  These interface in any state until
      L_quality is acceptable:

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

      *  Otherwise this parameters may be dynamic, and are
   specified by:

   o  For periodic message generation: HP_MAXJITTER.

   o  For externally triggered message generation: HT_MAXJITTER.

   When HELLO message generation is such delayed in order 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 HELLO
   message is not yet advertised has L_pending == true.

   o  Once L_quality >= HYST_ACCEPT, sent within HELLO_MIN_INTERVAL of the L_pending flag is set false,
      indicating that previous HELLO
   message on the link can same MANET interface, then HELLO_MIN_INTERVAL SHOULD
   be advertised.

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

   o  If reduced by jitter, with maximum reduction HP_MAXJITTER, as
   described in [RFC5148].  In this case HP_MAXJITTER MUST NOT be
   greater than HELLO_MIN_INTERVAL.

12.  HELLO Message Processing

   On receiving a link has L_pending == false and L_quality < HYST_REJECT, HELLO message, a router MUST first check if the
      link
   message is LOST invalid for processing by this router, as defined in
   Section 12.1.  Otherwise the receiving router MUST update its
   appropriate Interface Information Base and is advertised its Neighbor Information
   Base 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 specified in Section 12.3 to the exchange of HELLO messages.

14.3.  When Link Quality Changes

   If L_quality for a link changes, then the following actions Section 12.6.  These updates
   MUST be
   taken:

   1.  If L_quality >= HYST_ACCEPT then performed in 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. order in which they are presented in this
   specification.  If L_status is not equal to PENDING, and L_quality < HYST_REJECT
       then any changes satisfy any of 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 conditions
   described in Section 13 then the indicated consequences MUST also be taken.

   If L_quality for a link is updated based on HELLO
   applied immediately, unless noted otherwise.

   All message reception,
   or on reception processing, including determination of whether a packet including message
   is invalid, considers only TLVs with Type Extension = 0.  TLVs with
   any other type extension are ignored.  All references to, for
   example, a HELLO message, then L_quality
   MUST be updated prior TLV with Type = LINK_STATUS refer to the a TLV with Type =
   LINK_STATUS and Type Extension = 0.

12.1.  Invalid Message

   A received HELLO message is invalid for processing described in
   Section 12.  (If the receipt by this router if
   any of the HELLO message, or the packet
   containing it, creates the Link Tuple then the Link Tuple MUST be
   created following conditions are true.

   o  The message has a <msg-hop-limit> field in its <msg-header> with the appropriately updated L_quality value, rather a
      value other than
   with L_quality = INITIAL_QUALITY.)

14.4.  Updating Link Quality

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

   o  Information from the link layer, such as signal to noise ratio or
      acknowledgement reception and loss information. message need not have a
      <msg-hop-limit> field.)

   o  Receipt or loss of packets.  If packets include  The message has a packet sequence
      number as defined <msg-hop-count> field in [packetbb], then packets on a link SHOULD
      have sequential packet sequence numbers, whether or not they
      include HELLO messages.  Link quality can be updated when its <msg-header> with a packet
      is received based on, for example, whether the last N out of M
      packets on
      value other than zero.  (Note that the link were received, or message need not have a "leaky integrator"
      tracking packets.
      <msg-hop-count> field.)

   o  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion of a  The message does not have a Message TLV with Type == INTERVAL_TIME, as defined in [timetlv], = VALIDITY_TIME
      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 its Message TLV Block.

   o  The message has more than one Message TLV with Type =
      VALIDITY_TIME in a lost packet.

15.  Proposed Values for Parameters its Message TLV Block, and Constants

   This section lists the parameters and constants used in the
   specification of the protocol, these Message TLVs
      indicate different validity times, as specified by [timetlv].

   o  The message has any Address Block TLV(s) with Type = LOCAL_IF and proposed values of each which may
   be used when a
      any single value v such that v != THIS_IF and v!= OTHER_IF.

   o  Any address (including different copies of each an address, in the same
      or different Address Blocks) is used.

15.1.  Message Interval Interface Parameters

   o  HELLO_INTERVAL = 2 seconds

   o  HELLO_MIN_INTERVAL associated with more than one
      value by one or more Address Block TLV(s) with Type = HELLO_INTERVAL/4 LOCAL_IF.

   o  REFRESH_INTERVAL  Any address (the local address) associated with an Address Block
      TLV with Type = HELLO_INTERVAL

15.2.  Information Validity Time LOCAL_IF is one of the receiving router's current
      or recently used interface addresses (i.e. the local address is
      contained in any I_local_iface_addr_list in the Local Interface Parameters

   o  H_HOLD_TIME = 3 x REFRESH_INTERVAL

   o  L_HOLD_TIME
      Set or the local address = H_HOLD_TIME

15.3.  Information Validity Time Node Parameters any IR_local_iface_addr in the Removed
      Interface Address Set).

   o  N_HOLD_TIME  The message has any Address Block TLV(s) with Type = L_HOLD_TIME LINK_STATUS
      with any single value v such that v != LOST, v != SYMMETRIC, and
      v!= HEARD.

   o  I_HOLD_TIME = N_HOLD_TIME

15.4.  Link Quality Interface Parameters

   If link quality is changed, then parameter values will depend on  Any address (including different copies of an address, in the
   link quality process.  If link quality same
      or different Address Blocks) is not changed, then:

   o  HYST_ACCEPT = 1

   o  HYST_REJECT associated with more than one
      value by one or more Address Block TLVs with Type = 0 LINK_STATUS.

   o  INITIAL_QUALITY  The message has any Address Block TLV(s) with Type = 1

   o  INITIAL_PENDING = false

15.5.  Jitter Interface Parameters

   o  HP_MAXJITTER = HELLO_INTERVAL/4

   o  HT_MAXJITTER = HP_MAXJITTER

15.6.  Constants OTHER_NEIGHB
      with any single value v such that v!= LOST and v!= SYMMETRIC.

   o  C = 1/1024 second

16.  Security Considerations

   The objective  Any address (including different copies of this protocol is to allow each node an address, in the network
   to acquire information describing its 1-hop and symmetric 2-hop
   neighborhoods.  This same
      or different Address Blocks) is acquired through associated with more than one
      value by one or more Address Block TLVs with Type = OTHER_NEIGHB.

   An invalid message exchange between
   neighboring nodes.  The information is made available through MUST be silently discarded, without updating the
   Interface
   router's Information Bases Bases.  A router MAY recognize additional
   reasons for identifying that a message is badly formed, and Node Information Base, describing discard
   such messages.

12.2.  Definitions

   For the
   node's 1-hop neighborhood and symmetric 2-hop neighborhood.

   Under normal circumstances, purpose of this section, note the information recorded in these
   Information Bases following definitions:

   o  "validity time" is correct - i.e. corresponds to the actual network
   topology, apart calculated from any changes which have not (yet) been tracked by the Message TLV with Type =
      VALIDITY_TIME of the HELLO message exchanges.

   If some node for some reason, malice or malfunction, injects invalid
   HELLO messages, incorrect information may be recorded as specified in [timetlv].
      (Note that, as specified by Section 12.1, there must be such a
      Message TLV, and if there is more than one, they must indicate the
   Information Bases.  The protocol specification does, however, prevent
   inconsistent
      same validity time.)  All information from being injected in the protocol sets
   through HELLO message has the constraints in Appendix C.  The exact consequence of
   information inexactness depends on
      same validity time.

   o  "Receiving Address List" is the use of these Information
   Bases, and should be reflected in I_local_iface_addr_list
      corresponding to the specification of protocols MANET interface on which use information provided by NHDP.

   This section, therefore, only outlines the 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
      was received
   o  "Sending Address List" is the list of the following forms.  Note that a present or absent address in an
   address block, does not addresses contained in and by itself cause a problem.  It is
      the
   presence, absence, or 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 associated
         LOCAL_IF Address Block TLV which do not correspond to addresses of interfaces
         of the node transmitting the HELLO message.

      *  The HELLO message may omit addresses, or their associated with Type =
      LOCAL_IF TLV, of interfaces of the local node transmitting and Value = THIS_IF.  If the
         HELLO message (other than Sending Address List is
      otherwise empty, then the allowed omission of Sending Address List contains a single
      address (with maximum prefix length) equal to the only
         local interface sending address
      of the MANET interface over IP datagram in which the HELLO message is transmitted, if that was included.

   o  "Neighbor Address List" is the case).

      *  The Sending Address List, plus the
      addresses contained in the HELLO message may incorrectly specify the LOCAL_IF TLV
         value associated with one or more local interface addresses,
         indicating incorrectly whether they are an associated
      Address Block TLV with the
         MANET interface over which the HELLO message Type = LOCAL_IF and Value = OTHER_IF.

   o  EXPIRED indicates that a timer is transmitted.

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

      *  A present LINK_STATUS TLV may, incorrectly, identify an address
         as being of set to a MANET interface which is or was heard on the
         MANET interface over which value clearly preceding
      the HELLO message current time (e.g. current time - 1).

   o  "Removed Address List" is transmitted.

      *  A consistently absent LINK_STATUS TLV may, incorrectly, fail to
         identify an address as being of a MANET interface list of addresses created by this
      HELLO message processing which is or
         was heard on were formerly reported as local by
      the MANET interface over which router originating the HELLO message
         is transmitted.

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

      *  A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail
         to identify an address Neighbor Address List.  This list is initialized
      as being of empty.

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

12.3.  Updating the sending node's symmetric 1-hop neighborhood;

      *  The value of Neighbor Set

   On receiving a LINK_STATUS TLV may incorrectly indicate HELLO message, the
         status (LOST, SYMMETRIC or HEARD) of router MUST update its Neighbor Set
   and populate the link from a 1-hop
         neighbor. Removed Address List and Lost Address List:

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

       *  The value of an OTHER_NEIGHB TLV may incorrectly indicate  N_neighbor_iface_addr_list contains at least one address in
          the
         status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.

17.  IANA Considerations

17.1.  Message Types

   This specification defines Neighbor Address List.

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

       1.  Create a new Neighbor Tuple with:

           +  N_neighbor_iface_addr_list := Neighbor Address List;

           +  N_symmetric := false.

   3.  If there is one message type, to be allocated from the
   0-223 range of matching Neighbor Tuple, then:

       1.  If the "Message Types" namespace defined matching Neighbor Tuple's N_neighbor_iface_addr_list
           != Neighbor Address List, then:

           1.  For each address (henceforth removed address) which is
               contained in [packetbb],
   as specified that N_neighbor_iface_addr_list, but is not
               contained in Table 3.

                    +-------+------+------------------+
                    |  Name | Type | Description      |
                    +-------+------+------------------+
                    | HELLO | TBD1 | Local signaling. |
                    +-------+------+------------------+

                                  Table 3

17.2. the Neighbor Address Block TLV Types

   This specification defines three List:

               1.  Add the removed address block TLV types, which must
   be allocated from to the "Address Block TLV Types" namespace defined in
   [packetbb].  IANA are requested Removed Address List.

               2.  If N_symmetric = true, then add the removed address
                   to make allocations in the 8-127
   range for these types.  This will create three new type extension
   registries with assignments as specified in Table 4, Table 5 and
   Table 6.  Specifications of these TLVs are in Section 10.1.1, with
   value constants defined in Section 17.3.

   +----------+------+-----------+-------------------------------------+
   |   Name   | Type |    Type   | Description                         |
   |          |      | extension |                                     |
   +----------+------+-----------+-------------------------------------+
   | LOCAL_IF | TBD2 |     0     | Specifies that Lost Address List.

           2.  Update the matching Neighbor Tuple by:

               -  N_neighbor_iface_addr_list := Neighbor Address List.

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

       1.  For each address (henceforth removed address) which is       |
   |          |      |           | associated with a local interface   |
   |          |      |           |
           contained in the N_neighbor_iface_addr_list of any of the sending node.                |
   |          |      |           |                                     |
   |          |      |   1-255   | Expert Review                       |
   +----------+------+-----------+-------------------------------------+

                                  Table 4
   +-------------+------+-----------+----------------------------------+
   |     Name    | Type |    Type   | Description                      |
   |             |      | extension |                                  |
   +-------------+------+-----------+----------------------------------+
   | LINK_STATUS | TBD3 |     0     | Specifies
           matching Neighbor Tuples:

           1.  Add the status of removed address to the link |
   |             |      |           | from Removed Address List.

           2.  If N_symmetric = true, then add the indicated removed address       |
   |             |      |           | (LOST, SYMMETRIC or HEARD).      |
   |             |      |           |                                  |
   |             |      |   1-255   | Expert Review                    |
   +-------------+------+-----------+----------------------------------+

                                  Table 5

   +--------------+------+-----------+---------------------------------+
   |     Name     | Type |    Type   | Description                     |
   |              |      | extension |                                 |
   +--------------+------+-----------+---------------------------------+
   | OTHER_NEIGHB | TBD4 |     0     | Specifies that to
               the Lost Address List.

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

           +  N_neighbor_iface_addr_list := Neighbor Address List;

           +  N_symmetric := false

12.4.  Updating the Lost Neighbor Set

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

   1.  For each address (henceforth lost address) which is   |
   |              |      |           | (SYMMETRIC) or recently was     |
   |              |      |           | (LOST) of an interface of contained in
       the Lost Address List, if no Lost Neighbor Tuple with
       NL_neighbor_iface_addr = lost address exists, then add a     |
   |              |      |           | symmetric 1-hop neighbor of Lost
       Neighbor Tuple with:

       *  NL_neighbor_iface_addr := lost address;

       *  NL_time := current time + N_HOLD_TIME.

12.5.  Updating the |
   |              |      |           | node transmitting Link Set

   On receiving a HELLO message, a router MUST update its Link Set for
   the message.  |
   |              |      |           |                                 |
   |              |      |   1-255   | Expert Review                   |
   +--------------+------+-----------+---------------------------------+

                                  Table 6

   Type extensions indicated as Expert Review SHOULD be allocated as
   described in [packetbb], based MANET interface on Expert Review as defined in
   [RFC5226].

17.3.  LINK_STATUS and OTHER_NEIGHB Values

   The values which the LOCAL_IF TLV can use are HELLO message is received:

   1.  Remove all addresses in the following:

   o  UNSPEC_IF = 0

   o  THIS_IF = 1

   o  OTHER_IF = 2

   The values which Removed Address List from the LINK_STATUS TLV can use are
       L_neighbor_iface_addr_list of all Link Tuples.

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

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

       *  L_neighbor_iface_addr_list contains one or more addresses in
          the following:

   o  LOST = 0

   o  SYMMETRIC = 1
   o  HEARD = 2 Sending Address List.

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

   5.  If no matching Link Tuples remain, then create a new matching
       Link Tuple with:

       *  L_neighbor_iface_addr_list := empty;

       *  L_HEARD_time := EXPIRED;

       *  L_SYM_time := EXPIRED;

       *  L_quality := INITIAL_QUALITY;

       *  L_pending := INITIAL_PENDING;

       *  L_lost := false;

       *  L_time := current time + validity time.

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

       1.  If the OTHER_NEIGHB TLV can use are router finds any address (henceforth receiving
           address) in the following:

   o  LOST = 0

   o  SYMMETRIC = 1

18.  References

18.1.  Normative References

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

   [RFC5148]     Clausen, T., Dearlove, C., and B. Adamson, "Jitter
                 considerations Receiving Address List in MANETs", RFC 5148, February 2008.

   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226,
                 BCP 26, May 2008.

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

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

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

18.2.  Informative References

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

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

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 HELLO message, then the Link Tuple is modified as
           follows:

           1.  If any receiving address blocks, and with
   which in the HELLO message is
               associated TLVs.  These TLVs may have Type == LINK_STATUS or
   Type == OTHER_NEIGHB, or both.  TLVs with an Address Block TLV with Type == =
               LINK_STATUS may
   have three possible values (Value == HEARD, and with Value == SYMMETRIC = HEARD or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two
   possible values (Value == = SYMMETRIC or Value == LOST).  When both
   TLVs are
               then:

               -  L_SYM_time := current time + validity time.

           2.  Otherwise if any receiving address in the HELLO message
               is associated with the same address only certain combinations
   of these an Address Block TLV values are necessary, with Type =
               LINK_STATUS and are Value = LOST then:

               1.  if L_SYM_time has not expired, then:

                   1.  L_SYM_time := EXPIRED.

                   2.  if L_status = HEARD or L_status = 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 L_status = SYMMETRIC, then:

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

12.6.  Updating the only combinations
   generated by 2-Hop Set

   On receiving a HELLO message a router MUST update its 2-Hop Set for
   the algorithm in Section 11.  These combinations are
   indicated MANET interface on which the HELLO message was received:

   1.  Remove all addresses in Table 7.

   Cells labeled with "Yes" indicate the possible combinations which are
   generated by Removed Address List from the algorithm
       N2_neighbor_iface_addr_list of all 2-Hop Tuples.

   2.  If the Link Tuple whose L_neighbor_iface_addr_list = Sending
       Address List, has L_status = SYMMETRIC then:

       1.  For each address (henceforth 2-hop address) in Section 11.  Cells labeled with "No"
   indicate combinations not generated by an Address
           Block of the algorithm HELLO message, where:

           +  2-hop address is not contained in Section 11,
   but which are correctly parsed and interpreted by the algorithm Neighbor Address
              List;

           +  2-hop address is not contained in
   Section 12.

   +----------------+----------------+----------------+----------------+
   |                |     Type ==    | any
              I_local_iface_addr_list; AND
           +  2-hop address != any IR_local_iface_addr

           4.  If 2-hop address has an associated Address Block TLV
               with:

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

               -  Type ==    |
   |                | = OTHER_NEIGHB  |  OTHER_NEIGHB, |  OTHER_NEIGHB, |
   |                |    (absent)    |    Value ==    | and Value == LOST |
   |                |                |    SYMMETRIC   |                |
   +----------------+----------------+----------------+----------------+
   | = 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.

           5.  Otherwise if the 2-hop address has an Address Block TLV
               with:

               -  Type ==        |       No       |       Yes      |       Yes      |
   | = LINK_STATUS    |                |                |                |
   | (absent)       |                |                |                |
   |                |                |                |                |
   | Type ==        |       Yes      |       Yes      |       Yes      |
   | LINK_STATUS,   |                |                |                |
   | and Value == HEARD |                |                |                |
   |                |                |                |                |
   | Type ==        |       Yes      |       No       |       No       |
   | LINK_STATUS,   |                |                |                |
   | = LOST or Value ==       |                |                |                |
   | SYMMETRIC      |                |                |                |
   |                |                |                |                |
   | = HEARD;
                  OR

               -  Type ==        |       Yes      |       Yes      |       No       |
   | LINK_STATUS,   |                |                |                |
   | = OTHER_NEIGHB and Value == LOST  |                |                |                |
   +----------------+----------------+----------------+----------------+

                                  Table 7

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) =o LOST;

               then remove all 2-Hop Tuples with:

               -  N2_neighbor_iface_addr_list contains one or more
                  addresses without specified prefix lengths.  The message is
   transmitted with a full message header (flags octet value is 240)
   with a hop limit of 1 and a hop count of 0. in the Sending Address List; AND

               -  N2_2hop_iface_addr = 2-hop address.

13.  Other Information Base Changes

   The overall Interface and Neighbor Information Bases MUST be changed when
   some events occur.  These events may result from HELLO message
   length
   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 L_status changes to symmetric.

   o  A Link Tuple's L_status changes from symmetric, or the Link Tuple
      is 49 octets.

   The message contains removed.

   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.

   If a message TLV block with content length 8 octets
   containing two message TLVs, of types VALIDITY_TIME Link Tuple is removed, or if L_status changes from symmetric and
   INTERVAL_TIME.  Each uses a TLV with flags octet value 16, indicating
   L_HEARD_time expires, then Section 13.2 MUST be performed before
   Section 13.3 for that each has a value.  Each has a value length Link Tuple.

   A router MAY report updated information in response to any of 1 octet; these
   changes in HELLO message(s), subject to the
   values included (0x64 and 0x58) are time codes representing constraints in
   Section 11.

   A router which transmits HELLO messages in response to such changes
   SHOULD transmit a HELLO message:

   o  On all MANET interfaces, if the
   default values Neighbor Set changes such as to
      indicate the change in symmetry of parameters H_HOLD_TIME and HELLO_INTERVAL,
   respectively (6 seconds and 2 seconds) assuming the default value any 1-hop neighbors (including
      addition or removal of
   constant C (1/1024 second).

   The message has symmetric 1-hop neighbors).

   o  Otherwise, on all those MANET interfaces whose Link Set changes
      such as to indicate a single address block containing 5 addresses.  The
   flags octet value 128 indicates an address head but no address tail.
   The head length change in L_status of 3 octets indicates address mid sections any 1-hop neighbors
      (including the addition or removal of one
   octet each (Mid 0 to Mid 4).

   The following TLV block (content length 14 octets) any 1-hop neighbors, other
      than those considered pending).

13.1.  Link Tuple Symmetric

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

   o  L_status := SYMMETRIC;

   (this includes two TLVs.
   The first is a LOCAL_IF TLV newly created Link Tuple which (with flags octet value 80)
   indicates that a single address, with index 0 (i.e.  Head:Mid 0) is
   the single local interface address of this node (the 1 octet value
   THIS_IF indicates that this address is of this interface).  The
   second is a LINK_STATUS TLV which (with flags octet value 48)
   specifies immediately
   updated to have L_status := SYMMETRIC) then:

   1.  For the link status values of Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list, set:

       *  N_symmetric := true.

   2.  Remove all reported neighbors Lost Neighbor Tuples whose NL_neighbor_iface_addr is
       contained in a
   single multivalue TLV which covers the addresses that N_neighbor_iface_addr_list.

13.2.  Link Tuple Not Symmetric

   If for any Link Tuple with indexes 1 L_status = SYMMETRIC:

   o  L_status changes to 4.
   The TLV value length of 4 octets indicates one octet per value per
   address.  The last four 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 first 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
           where:

           +  L_neighbor_iface_addr_list is 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.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 where:

       *  L_neighbor_iface_addr_list is contained in
          N_neighbor_iface_addr_list; AND

       *  L_HEARD_time is not expired;

       then remove the Neighbor Tuple.

14.  Link Quality

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

   Link quality information for a link is generated (e.g. through access
   to signal to noise ratio, packet loss rate, or other information from
   the link layer) 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 used only locally, i.e. is not included in
   signaling, and routers may interoperate whether they are using the
   same, different, or no, link quality information.

   For deployments where no link quality is used, the considerations in
   Section 14.1 apply.  For deployments where 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.

14.1.  Deployment Without Link Quality

   In order for a router to not employ link quality, the router 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, on the value of parameter
   INITIAL_PENDING).  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 router 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 router MUST NOT define INITIAL_PENDING = false
         and INITIAL_QUALITY < HYST_REJECT.  (A router 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 router sets L_pending := 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 != 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 the Link Tuple MUST be
   created with the appropriately updated L_quality value, rather than
   with L_quality := INITIAL_QUALITY.)

14.4.  Updating Link Quality

   A router 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 or
      packet acknowledgement reception and loss information.

   o  Receipt or loss of control packets.  If control packets include a
      sequential packet sequence number, as defined in [RFC5444], then
      link quality can be updated when a control packet is received,
      whether or not it contains a HELLO message.  The link quality may
      then, for example, be based on whether the last N out of M control
      packets on the link were received, or may use a "leaky integrator"
      tracking packet reception and loss.

   o  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion in HELLO
      messages of a Message TLV with Type := INTERVAL_TIME, as defined
      in [timetlv]) then the loss of HELLO messages can be determined
      without the need to receive a later 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 Router 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 := 1/1024 second

16.  Security Considerations

   The objective of this protocol is to allow each router in the network
   to acquire information describing its 1-hop and symmetric 2-hop
   neighborhoods.  This is acquired through message exchange between
   neighboring routers.  The information is made available through the
   Interface Information Bases and Neighbor Information Base, describing
   the router's 1-hop neighborhood and symmetric 2-hop neighborhood.

   Under normal circumstances, the information recorded in these
   Information Bases 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 a router for some reason, whether malice or malfunction, injects
   invalid HELLO messages, incorrect information may be recorded in
   other routers' Information Bases.  The protocol specification does,
   however, prevent inconsistent information from being injected in the
   protocol sets through the constraints in Appendix B.  The exact
   consequence of information inexactness depends on the use of these
   Information Bases, and should be reflected in the specification of
   protocols which use information provided by NHDP.

   This section, therefore, only outlines the ways in which correctly
   formed, but still invalid, HELLO messages may appear, in
   Section 16.1.  In addition, in Section 16.2, the security suggestions
   in [RFC5444] are considered for applicability.

16.1.  Invalid HELLO messages

   A correctly formed, but still invalid, HELLO message may take any of
   the following forms.  Note that a present or absent address in an
   Address Block, does not in and by itself cause a problem.  It is the
   presence, absence, or incorrectness of associated LOCAL_IF,
   LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.

   A router may provide false information about its own identity:

      *  The HELLO message may contain addresses with an associated
         LOCAL_IF Address Block TLV which do not correspond to addresses
         of interfaces of the router transmitting the HELLO message.

      *  The HELLO message may omit addresses, or their associated
         LOCAL_IF Address Block TLV, of interfaces of the router
         transmitting the HELLO message (other than the allowed omission
         of the only local interface address of the MANET interface over
         which the HELLO message is transmitted, if that is the case).

      *  The HELLO message may incorrectly specify the LOCAL_IF Address
         Block TLV value associated with one or more local interface
         addresses, indicating incorrectly whether they are associated
         with the MANET interface over which the HELLO message is
         transmitted.

   A router may provide false information about the identity of other
   routers:

      *  A present LINK_STATUS Address Block TLV may, incorrectly,
         identify an address as being of a MANET interface which is or
         was heard on the MANET interface over which the HELLO message
         is transmitted.

      *  A consistently absent LINK_STATUS Address Block TLV may,
         incorrectly, fail to identify an address as being of a MANET
         interface which is or was heard on the MANET interface over
         which the HELLO message is transmitted.

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

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

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

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

16.2.  Authentication, Integrity and Confidentiality Suggestions

   The security mechanisms suggested in [RFC5444] with respect to
   authentication and integrity can be applied to this neighborhood
   discovery protocol, with the following additional considerations:

   o  As HELLO messages MUST NOT be forwarded, the fields <msg-hop-
      count> and <msg-hop-limit> are either omitted, or will always have
      the values of 0 and 1, respectively.

   o  Consequently, a cryptographic signature can be calculated based on
      the entire HELLO message, including its Message Header, and
      included in a Message TLV of an appropriate type.

   o  As HELLO messages MUST NOT be forwarded, and in case hop-by-hop
      packet level authentication and integrity is ensured by including
      an appropriate Packet TLV containing a cryptographic signature
      across the entire packet, inclusion of an additional Message TLV
      containing a cryptographic signature for the HELLO Message may not
      be necessary.

   The security mechanisms suggested in [RFC5444] with respect to
   confidentiality can be directly applied to this neighborhood
   discovery protocol.

17.  IANA Considerations

   This specification defines one Message Type, which must be allocated
   from the "Message Types" repository of [RFC5444], and three Address
   Block TLV Types, which must be allocated from the "Message TLV Types"
   repository of [RFC5444].

17.1.  Expert Review: Evaluation Guidelines

   For the registries where an Expert Review is required, the designated
   expert SHOULD take the same general recommendations into
   consideration as are specified by [RFC5444].

17.2.  Message Types

   This specification defines one Message Type, to be allocated from the
   0-223 range of the "Message Types" namespace defined in [RFC5444], as
   specified in Table 3.

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

                     Table 3: Message Type assignment

17.3.  Message-Type-specific TLV Type Registries

   IANA is requested to create a registry for Message-Type-specific
   Message TLVs for HELLO messages, in accordance with Section 6.4 of
   [RFC5444], and with initial assignments and allocation policies as
   specified in Table 4.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 128-223 | Unassigned  | Expert Review     |
               +---------+-------------+-------------------+

          Table 4: HELLO Message-Type-specific Message TLV Types

   IANA is requested to create a registry for Message-Type-specific
   Address Block TLVs for HELLO messages, in accordance with Section 6.5
   of [RFC5444], and with initial assignments and allocation policies as
   specified in Table 5.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 128-223 | Unassigned  | Expert Review     |
               +---------+-------------+-------------------+

       Table 5: HELLO Message-Type-specific Address Block TLV Types

17.4.  Address Block TLV Types

   This specification defines three Address Block TLV Types, which must
   be allocated from the "Address Block TLV Types" namespace defined in
   [RFC5444].  IANA are requested to make allocations in the 0-127 range
   for these types.  This will create three new type extension
   registries with assignments as specified in Table 6, Table 7 8 9 and
   Table 8.  Specifications of these Address Block TLVs are in
   Section 10.1.1, with value constants defined in Section 17.5.

   +----------+------+-----------+-------------------------------------+
   |   Name   | Type |    Type   | Description                         |
   |          |      | extension |                                     |
   +----------+------+-----------+-------------------------------------+
   | LOCAL_IF | TBD2 |     0     | Specifies that the address is       |
   |          |      |           | associated with a local interface   |
   |          |      |           | of the sending router               |
   |          |      |   1-255   | Expert Review                       |
   +----------+------+-----------+-------------------------------------+

           Table 6: Address Block TLV Type assignment: LOCAL_IF

   +-------------+------+-----------+----------------------------------+
   |     Name    | Type |    Type   | Description                      |
   |             |      | extension |                                  |
   +-------------+------+-----------+----------------------------------+
   | LINK_STATUS | TBD3 |     0     | Specifies the status of the link |
   |             |      |           | from the indicated address       |
   |             |      |           | (LOST, SYMMETRIC or HEARD)       |
   |             |      |   1-255   | Expert Review                    |
   +-------------+------+-----------+----------------------------------+

          Table 7: Address Block TLV Type assignment: LINK_STATUS

   +--------------+------+-----------+---------------------------------+
   |     Name     | Type |    Type   | Description                     |
   |              |      | extension |                                 |
   +--------------+------+-----------+---------------------------------+
   | OTHER_NEIGHB | TBD4 |     0     | Specifies that the address is   |
   |              |      |           | (SYMMETRIC) or recently was     |
   |              |      |           | (LOST) of an interface of a     |
   |              |      |           | symmetric 1-hop neighbor of the |
   |              |      |           | router transmitting the message |
   |              |      |   1-255   | Expert Review                   |
   +--------------+------+-----------+---------------------------------+

         Table 8: Address Block TLV Type assignment: OTHER_NEIGHB

17.5.  LINK_STATUS and OTHER_NEIGHB Values

   The values which the LOCAL_IF Address Block TLV can use are the
   following:

   o  THIS_IF := 0

   o  OTHER_IF := 1

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

   o  LOST := 0

   o  SYMMETRIC := 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  HEARD := 2

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

   o  LOST := 0

   o  SYMMETRIC := 1

18.  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  Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>

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

   o  Christopher Dearlove, BAE Systems ATC, UK,
      <chris.dearlove@baesystems.com>

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

19.  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 (listed alphabetically): Alan Cullen
   (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
   Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
   and the entire IETF MANET working group.

20.  References

20.1.  Normative References

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

   [RFC5148]     Clausen, T., Dearlove, C., and B. Adamson, "Jitter
                 considerations in MANETs", RFC 5148, February 2008.

   [RFC5444]     Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
                 "Generalized MANET Packet/Message Format", RFC 5444,
                 February 2009.

   [timetlv]     Clausen, T. and C. Dearlove, "Representing multi-value
                 time in MANETs", Work In
                 Progress draft-ietf-manet-timetlv-08.txt,
                 September 2008.

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

20.2.  Informative References

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

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

   [RFC5449]     Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet,
                 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc
                 Networks", RFC 5449, February 2009.

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 Address Block TLVs.  These Address Block TLVs may
   have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both.  Address
   Block TLVs with Type = LINK_STATUS may have three possible values
   (Value = HEARD, Value = SYMMETRIC or Value = LOST), and Address Block
   TLVs of TYPE = OTHER_NEIGHB may have two possible values (Value =
   SYMMETRIC or Value = LOST).  When both Address Block TLVs are
   associated with the same address only certain combinations of these
   Address Block TLV values are necessary, and are the only combinations
   generated by the algorithm in Section 11.  These combinations are
   indicated in Table 9.

   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.  The cell labeled with "No*" is actually inconsistent, it
   is handled by ignoring the Address Block TLV with Type =
   OTHER_NEIGHB.

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

          Table 9: LINK_STATUS and OTHER_NEIGHB TLV combinations

Appendix B.  Constraints

   Any process which updates the Local Information Base or the Neighbor
   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 duplicated addresses.

   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 Removed Interface Address Tuple:

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

   o  IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
      other Removed Interface Address 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 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 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 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator 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 or the
      IR_local_iface_addr of any Removed Interface Address Tuple.

   o  N_neighbor_iface_addr_list MUST NOT contain any duplicated
      addresses.

   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 is = true, then there MUST be one or more Link
      Tuples with:

      *  L_neighbor_iface_addr_list contained in
         N_neighbor_iface_addr_list; AND

      *  L_status = SYMMETRIC.

   o  If N_symmetric is = false, then there MUST 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 not expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list
      of any Local Interface Tuple or the IR_local_iface_addr of any
      Removed Interface Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Tuple.

   o  NL_neighbor_iface_addr MUST NOT equal the 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 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 or the IR_local_iface_addr of any
      Removed Interface Address Tuple.

   o  N2_2hop_iface_addr 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.

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

Appendix C.  HELLO Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 Example

   An example HELLO message, transmitted by an originator router with a
   single MANET interface, is as follows.

   The message has full Message Header (four bit flags field value is
   15).  Its four bit Message Address Length field has value 3 and hence
   addresses in the message have length four octets, here being IPv4
   addresses.  The message is as transmitted with a hop limit of 1 1|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mid 0     |     Mid 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 Message TLV with flags octet value 16,
   indicating that each has a value.  Each has a value length of 1     |     Mid
   octet; the values included (0x64 and 0x58) are time codes
   representing the default values of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2     |     Mid seconds) assuming the
   default value of constant C (1/1024 second).

   The message has a single Address Block containing 5 addresses.  The
   flags octet value 128 indicates an address Head but no address Tail,
   and no address prefixes.  The Head Length of 3     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | octets indicates
   address Mid 4     |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|   LOCAL_IF    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|    THIS_IF    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  LINK_STATUS  |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 sections of one octet each (Mid 0 to Mid 4).

   The following Address Block TLV Block (content length 14 octets)
   includes two Address Block TLVs.  The first is a LOCAL_IF Address
   Block TLV which (with flags octet value 80) indicates that a single
   address, with index 0 (i.e.  Head:Mid 0) is the single local
   interface address of this router (the 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

   Note octet value THIS_IF indicates
   that this example address is for illustrative purposes. of this interface).  The essential
   information can be conveyed, more efficiently (assuming that second is a LINK_STATUS
   Address Block TLV which (with flags octet value 48) specifies the
   local interface address will be supplied by IP,
   link status values of all reported neighbors in a single multivalue
   Address Block TLV which covers the addresses with indexes 1 to 4.
   The Address Block TLV value length of 4 octets indicates one octet
   per value per address.  The last four addresses have associated link
   status, the first and that second HEARD, the
   INTERVAL_TIME is not needed) by third SYMMETRIC, and the 29 octets:
   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 0 1     |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 1 1|0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0| 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mid 1     |     Mid 2     |     Mid 3     |     Mid 4 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 0 1 1 1|  LINK_STATUS 0 0 0| VALIDITY_TIME |0 0 0 1 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

Appendix C.  Constraints

   Any process which updates the Local Information Base or the Node
   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 duplicated addresses.

   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 Removed Interface Address Tuple:

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

   o  IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
      other Removed Interface Address 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 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 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 INTERVAL_TIME |0 0 0 1 0 0 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 or the
      IR_local_iface_addr of any Removed Interface Address Tuple.

   o  N_neighbor_iface_addr_list MUST NOT contain any duplicated
      addresses.

   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 be one or 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 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     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 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|    THIS_IF    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  LINK_STATUS  |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   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.

      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 any Local Interface Tuple or the IR_local_iface_addr of any
      Removed Interface Address Tuple.

   o  NL_neighbor_iface_addr MUST NOT equal the 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 Link Tuple associated with efficiently (assuming that the same MANET
   local 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 or the IR_local_iface_addr of any
      Removed Interface Address Tuple.

   o  N2_2hop_iface_addr MUST NOT address will be the N2_2hop_iface_addr of any other
      2-Hop Tuple in the same 2-Hop Set supplied by IP, and with the same
      N2_neighbor_iface_addr_list.

   o  N2_2hop_iface_addr MUST NOT be in that the N2_neighbor_iface_addr_list
      of
   INTERVAL_TIME TLV is not needed) by the same 2-Hop Tuple. 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 0 0 0 1 1|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 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 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 0 1 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

Appendix D.  Flow and Congestion Control

   This protocol specifies one message type, Message Type, the HELLO message.  The
   maximum size of a HELLO message is proportional to the size of the
   originating node's router's 1-hop neighborhood.  HELLO messages MUST NOT be
   forwarded.

   A node router 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 router in the
   network employing this protocol.

   A node router 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 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  Thomas Heide Clausen, 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 F.  Acknowledgements

   The authors would like to acknowledge the team behind OLSRv1,
   specified in RFC3626 for their contributions.

   The authors would like jitter then this may be reduced to gratefully acknowledge the following people
   for intense technical discussions, early reviews and comments a mean minimum value of
   HELLO_MIN_INTERVAL - HP_MAXJITTER/2.)  Thus, this puts an upper bound
   on the
   specification and its components (listed alphabetically): Alan Cullen
   (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
   Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
   and control traffic generated by each router in the entire IETF MANET working group. network
   employing this protocol.

Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France Polytechnique

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/
   Christopher Dearlove
   BAE Systems Advanced Technology Centre ATC

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

   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.