Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                                  LIX, Ecole Polytechnique
Intended status: Standards Track                             C. Dearlove
Expires: September 27, 2009 January 14, 2010                                BAE Systems ATC
                                                                 J. Dean
                                               Naval Research Laboratory
                                                  The OLSRv2 Design Team
                                                     MANET Working Group
                                                          March 26,
                                                           July 13, 2009

              MANET Neighborhood Discovery Protocol (NHDP)
                        draft-ietf-manet-nhdp-09
                        draft-ietf-manet-nhdp-10

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or 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 modified outside the IETF Standards Process, and
   derivative works of it may not be 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 September 27, 2009. January 14, 2010.

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

1.  Introduction

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

   1-hop and symmetric 2-hop neighborhood information is recorded in the
   form of Information Bases.  These are available for use by other
   protocols, such as MANET routing protocols, which require information
   regarding the local network connectivity.  This protocol is designed
   to maintain the information in these Information Bases even in the
   presence of a dynamic network topology and wireless communication
   channel characteristics.

   This protocol makes no assumptions about the underlying link layer,
   other than support of 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 61
   Appendix E.  Interval and infrastructure Timer Illustrations  . . . . . . . . . . 62
     E.1.  HELLO Message Generation Timing  . . . . . . . . . . . . . 62
     E.2.  HELLO Message Processing Timing  . . . . . . . . . . . . . 68
     E.3.  Other HELLO Message Timing . . . . . . . . . . . . . . . . 69
   Appendix F.  Topology Pictures . . . . . . . . . . . . . . . . . . 71
     F.1.  Example 1: Standard Single Interface Topology  . . . . . . 71
     F.2.  Example 2: Dual Addressed Interface on One Hop Neighbor  . 72
     F.3.  Example 3: Dual Addressed Interface on Two Hop Neighbor  . 73
     F.4.  Example 4: Dual Addressed Interfaces . . . . . . . . . . . 73
     F.5.  Example 5: Dual Interface on Two Hop Neighbor  . . . . . . 74
     F.6.  Example 6: Dual interface on One Hop Neighbor  . . . . . . 74
     F.7.  Example 7: Dual Interface on One and Two Hop Neighbors . . 75
     F.8.  Example 8: Dual Interface Locally and on One Hop
           Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . 76
     F.9.  Example 9: Dual Interface on All Routers . . . . . . . . . 76
     F.10. Example 10: Dual Addressed Dual Interfaces on All
           Routers  . . . . . . . . . . . . . . . . . . . . . . . . . 77
     F.11. Example 11: Single Addressed Dual Interface Locally  . . . 78

1.  Introduction

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

   1-hop and symmetric 2-hop neighborhood information is recorded in the
   form of Information Bases.  These are available for use by other
   protocols, such as MANET routing protocols, which require information
   regarding the local network connectivity.  This protocol is designed
   to maintain the information in these Information Bases even in the
   presence of a dynamic network topology and wireless communication
   channel characteristics.

   This protocol makes no assumptions about the underlying link layer,
   other than support of local broadcast or multicast for communication
   to 1-hop neighbor routers.  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 their envisioned applicability also over
   more challenging communication channels (e.g., wireless, lossy,
   broadcast channels with moderate and shared bandwidth, hidden and
   exposed terminals and interference from other network devices and the
   environment) and in more challenging topological conditions (e.g.,
   rapid and unpredictable mobility, dynamic and non-predetermined
   network membership).

   Due to the properties of wireless transmissions, communication
   between two neighboring routers may not be bidirectional; even if
   router A is able to receive packets from router B, the converse is
   not guaranteed to be true.  Furthermore, because of the localized
   nature of wireless broadcast communication, neighboring routers
   within the same communications channel may have different sets of
   neighbors.  That is, when using the same communication channel, even
   if router A is able to exchange packets with router B and router B is
   able to exchange packets with router C, then this does not guarantee
   that router A and router C can exchange packets directly.

   Each router in a MANET may use more than one communication channel.
   In particular, between the same pair of routers, more than one
   distinct communication channel may exist, each with different
   properties.

   For use by MANET routing protocols, as well as for establishing a
   router's neighbors, a router may also need to determine whether each
   communication channel with that neighbor is bidirectional.

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

   MANET routing 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 two hop
   information.

   The neighborhood discovery protocol specified in this document
   provides continued tracking of neighborhood changes, link
   bidirectionality, 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].

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

   Additionally, this document uses the following terminology:

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

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

   Address  - An IPv4 or IPv6 address, as assigned to an interface.  It
      corresponds to an address as specified in [RFC5444], and may be
      either an address or an address prefix.  An address without a
      prefix length is considered to have a prefix length equal to its
      length (in bits).

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

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

   Link  - A link between two MANET interfaces exists if either can be
      heard by the other.

   Symmetric link  - A symmetric link between two MANET interfaces
      exists if both can be heard by the other.

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

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

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

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

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

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

   2-hop neighborhood  - The 2-hop neighborhood of a router X is the set
      of the 2-hop neighbors of router X. (This may include routers in
      the 1-hop neighborhood of router X.)

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

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

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

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

   Information Base  - A collection of information maintained by this
      protocol, and which is to be made available to MANET routing
      protocols.  An Information Base may be associated with a MANET
      interface, or with a router.

   Furthermore, this document uses the following notational conventions:

   X contains y, or y is contained in 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 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 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).  If c and d are
      addresses, they are considered equal only if their prefix lengths
      are also equal.

   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  Is applicable to networks, especially wireless networks, in which
      unknown neighbors 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 routers that each have one or more participating MANET
      interfaces.  The set of a router's interfaces may change over
      time.  Each interface may have one or more interface addresses,
      and these may also be dynamically changing.

   o  Provides each router with current local topology information up to
      two hops away, and makes this local topology information available
      to MANET routing protocols in Information Bases.

   o  Uses the packet and message formats specified in [RFC5444].  This
      includes the definition of a HELLO Message Type, used for
      signaling local topology information.

   o  Allows "external" and "internal" extensibility as enabled by
      [RFC5444].

   o  May interact with, and be extended by, other protocols, such as
      MANET routing protocols, see Section 16.

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

   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 this protocol is, for each router:

   o  To identify 1-hop neighbors and symmetric 1-hop neighbors of this
      router.

   o  To find the 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, which extend this neighborhood discovery
      protocol.

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

   o  Advertises the presence of a router and its interface addresses.

   o  Discovers links 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, where appropriate, be specific to a given MANET
      interface, or to a MANET router.  This protocol allows all
      parameters to be changed 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.

   o  The response to other events, such as the expiration of
      information in the Information Bases.

4.1.  Routers and Interfaces

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

   o  Is configured with one or more addresses.  These addresses MUST be
      unique at least within the router's 2-hop neighborhood.

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

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

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

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

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

4.2.  Information Base Overview

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

   Information in the Local Information Base is defined locally, and
   included in HELLO messages.  Information in the Interface Information
   Base and the Neighbor Information Base is determined from received
   HELLO messages; some of this information may also be included in
   transmitted HELLO messages.  Such information has a limited duration
   in which it is considered valid, this is determined from the
   VALIDITY_TIME TLV in the HELLO message in which the information is
   received, which in turn is set by the router which originated the
   HELLO message, using its corresponding interface parameter
   H_HOLD_TIME.

   Appendix E illustrates the relationship between message reception,
   included VALIDITY_TIME TLVs, and the duration for which information
   received in a HELLO message is considered valid.  Appendix F
   illustrates some example two hop topologies and how they correspond
   to information in the Information Bases.

4.2.1.  Local Information Base

   Each router maintains a Local Information Base, which contains the
   router's local configuration information, specifically:

   o  The Local Interface Set, which consists of Local Interface Tuples,
      each of which represents an interface (MANET or non-MANET) of the
      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 router.

   The Local Interface Set is used for generating HELLO messages,
   specifically for determining which interface addresses are to be
   included and identified as local interfaces.  The Removed Interface
   Address Set is used to avoid incorrectly recording a formerly used
   address as a symmetric 2-hop neighbor's address.

   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 router maintains, for each of its MANET interfaces, an Interface
   Information Base, which contains 1-hop neighborhood and symmetric
   2-hop neighborhood information collected from this MANET interface,
   specifically:

   o  A Link Set, which records information about current and recently
      lost links between this MANET interface and MANET interfaces of
      1-hop neighbors.  The Link Set consists of Link Tuples, each of
      which contains information about a single link.  Link quality
      information (see Section 14), when used, is recorded in Link
      Tuples.

   o  A 2-Hop Set, which records the existence of symmetric links
      between symmetric 1-hop neighbors of this MANET interface and
      other routers (symmetric 2-hop neighbors).  The 2-Hop Set consists
      of 2-Hop Tuples, each of which records an address of a symmetric
      2-hop neighbor, and all addresses of the corresponding symmetric
      1-hop neighbor.

   The Link Set for a MANET interface is used for generating HELLO
   messages.  Specifically, the Link Set information is included to both
   allow other routers to identify symmetric links and to populate the
   2-Hop Set. Recently lost links are recorded in the Link Set for a
   MANET interface so that they can be advertised in HELLO messages,
   accelerating their removal from relevant 1-hop neighbors' Link Sets.

   The Link Set for a MANET interface is itself updated on receiving a
   HELLO message, including recording symmetric links as indicated
   above.  The 2-Hop Set for a MANET interface is updated as indicated
   above, and is not itself used in generating HELLO messages.

4.2.3.  Neighbor Information Base

   Each router maintains a Neighbor Information Base, which contains
   collected information about current and recently lost 1-hop
   neighbors, specifically:

   o  The Neighbor Set consists of Neighbor Tuples, each of which
      records all addresses of a single 1-hop neighbor.  Neighbor Tuples
      are maintained as long as there are corresponding Link Tuples.

   o  The Lost Neighbor Set consists of Lost Neighbor Tuples, each of
      which records an address of a recently lost symmetric 1-hop
      neighbor.

   The Neighbor Set associates all addresses of each 1-hop neighbor.
   These addresses may be included when generating a HELLO message, so
   that other symmetric 1-hop neighbors can record this information in a
   2-Hop Set. The Neighbor Set can be updated on receiving a HELLO
   message.

   The Lost Neighbor Set is used to determine which addresses are to be
   included in a HELLO message as being lost (of a recently symmetric
   1-hop neighbor).  The Lost Neighbor Set can itself be updated on
   receiving a HELLO message.

4.3.  Signaling Overview

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

   Signaling consists of a single type of message, known as a HELLO
   message.  Each router generates HELLO messages on each of its MANET
   interfaces.  HELLO messages are generated independently on each MANET
   interface of a MANET router; the content of a given HELLO message
   depends on the MANET interface for which it has been generated.

   Each HELLO message identifies the MANET interface for which it is
   generated and transmitted; this allows recipients to identify that
   MANET interface.  Each HELLO message also over
   more challenging communication channels (e.g., wireless, lossy,
   broadcast channels reports the other
   interfaces (MANET and non-MANET) of the router; this allows
   recipients to associate a set of addresses with moderate a single 1-hop
   neighbor.  Each HELLO message also includes 1-hop neighbor
   information from the Information Bases; this allows detection of
   local symmetric links, and shared bandwidth, hidden symmetric 2-hop neighbors.

   HELLO message generation, and
   exposed terminals the validity of the information
   recorded as a consequence of processing a HELLO message, is affected
   by timers and interference from other validity information included in HELLO messages through
   TLVs.  The relationship between message timers and intervals is
   illustrated in Appendix E.

4.3.1.  HELLO Message Generation

   HELLO messages are generated by a router for each of its MANET
   interfaces, and MAY be sent:

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

   o  As a response to a change in the router itself, or its 1-hop
      neighborhood, for example on first becoming active or in response
      to a new, lost, or changed status link.

   o  In a combination of these proactive and responsive mechanisms.

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

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

4.3.2.  HELLO Message Content

   The content of a HELLO message MUST satisfy the
   environment) and following:

   o  A HELLO message MUST contain all of the addresses in more challenging topological conditions (e.g.,
   rapid and unpredictable mobility, dynamic and non-predetermined
   network membership).

   Due to the properties Local
      Interface Set of wireless transmissions, communication
   between two neighboring routers may not be bidirectional; even if the router A is able to receive packets from router B, which the converse is
   not guaranteed MANET interface belongs.

   o  For each MANET interface, within every time interval equal to be true.  Furthermore, because of the localized
   nature of wireless broadcast communication, neighboring routers
   within
      corresponding REFRESH_INTERVAL, the same communications channel may have different sets HELLO messages sent MUST
      collectively include all of
   neighbors.  That is, the relevant information in the
      corresponding Link Set and the Neighbor Information Base.  Note
      that when using determining whether to include information in a HELLO
      message, the same communication channel, even
   if router sender MUST consider all times up to the latest time
      when it may send its next HELLO message on this MANET interface.

   o  A HELLO message MUST include exactly one VALIDITY_TIME Message
      TLV, as specified in [RFC5497], that indicates the length of time
      for which the message content is able to exchange packets with router B be considered valid, and router B is
   able
      therefore to exchange packets with router C, then this does not guarantee
   that router A and router C can exchange packets directly.

   Each router be included in a MANET may use more than the receiving router's Interface
      Information Base.

   o  A periodically generated HELLO message SHOULD include exactly one communication channel.

   In particular, between
      INTERVAL_TIME Message TLV, as specified in [RFC5497], that
      indicates the same pair current value of routers, more than one
   distinct communication channel may exist, each with different
   properties.

   For use by HELLO_INTERVAL for that MANET routing protocols, as well as establishing
      interface, i.e. the period within which a
   router's neighbors, further HELLO message is
      guaranteed to be sent on that MANET interface.

4.3.3.  HELLO Message Processing

   HELLO messages received by a router may also need are used to determine whether each
   communication channel with update the Interface
   Information Base for the MANET interface on which that neighbor HELLO message
   is bidirectional. received and the Neighbor Information Base.  Specifically:

   o  The set of neighbor routers of a given MANET router may be
   continuously changing, often due ensures that there is a single Neighbor Tuple
      corresponding to the originator of that HELLO message.

   o  The router mobility or ensures that there is a changing
   physical environment in Link Tuple, with appropriate
      status (heard or symmetric) and advertised duration, corresponding
      to the link between the MANET interfaces on which that HELLO
      message was sent and received.  One or more Lost Neighbor Tuples
      may be created if the HELLO message reports that the link was
      lost.

   o  If the link between the MANET interfaces on which the HELLO
      message was sent and received is located.  There is
   typically no symmetric, then the router
      ensures that there are the appropriate 2-Hop Tuples, with
      advertised duration.

   The processing defined in this specification handles any unexpected
   and erroneous information from lower layers which would enable an IP
   routing protocol to detect and, as appropriate, react to such
   changes.  Such changes can often take place in a HELLO message, maintaining the
   constraints on Information Base contents specified in Appendix B.

4.4.  Link Quality

   Some links in a short timescale,
   such as of the order of seconds, requiring MANET routing protocols may be marginal, e.g., due to
   act rapidly adverse wireless
   propagation.  In order to ensure suitable convergence properties. avoid using such marginal links, a link
   quality value is recorded in each Link Tuple.  A MANET routing protocols, router
   considers links for example [RFC3626] and [RFC5449], often
   employ relay set reductions which an insufficient link quality is recorded as
   lost.  Modifying the recorded link quality in order a Link Tuple is
   OPTIONAL.  If link quality is not to conserve network capacity
   when maintaining network-wide topological information, with
   calculation of these reduced relay sets employing up be modified it MUST be set to two hop
   information.

   The neighborhood discovery protocol specified
   indicate an always usable quality link.

   Link quality information is only used locally and is not used in this document
   provides continued tracking of neighborhood changes,
   signaling.  Routers may interoperate whether they are using the same,
   different, or no, link
   bidirectionality, and local topological quality information.  Link quality information up
   is thus not equivalent 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 metric.

5.  Protocol Parameters and
   other purposes.

2.  Terminology Constants

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

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

   Additionally, this document uses the following terminology:

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

   Interface  - A network device, configured section.

5.1.  Protocol and assigned one or more
      addresses.

   Address  - An IPv4 or IPv6 address, Port Numbers

   This protocol specifies HELLO messages, which are included in packets
   as assigned to an interface.  It
      corresponds to an address defined by [RFC5444].  These packets may be sent either using the
   "manet" protocol number or the "manet" well-known UDP port number, as
   specified in [RFC5444], and [RFC5498].

5.2.  Multicast Address

   This protocol specifies HELLO messages, which are included in packets
   as defined by [RFC5444].  These packets may be
      either an address or an address prefix.  An address without a
      prefix length is considered to have a prefix length equal to its
      length (in bits).

   Origionator address  - An locally transmitted
   using the link local multicast address identifying a router, "LL-MANET-Routers", as
   specified in [RFC5444]; it is a simple address without a prefix length.

   MANET interface  - An [RFC5498].

5.3.  Interface Parameters

   The interface participating in a MANET and using parameters used by this neighborhood discovery protocol.  A router specification may have several
      MANET interfaces.

   Heard  - A MANET interface of router X is considered heard on a MANET
      interface of a router Y if the latter can receive traffic from be classified
   into the
      former. following four categories:

   o  Message intervals

   o  Information validity times

   o  Link  - A link between two MANET interfaces exists if either can be
      heard by quality

   o  Jitter

   These are detailed in the other.

   Symmetric link  - A symmetric link between two following sections.

   Different MANET interfaces
      exists if both can be heard by (on the other.

   1-hop neighbor  - A router X is a 1-hop neighbor of a router Y if a
      MANET same or on different routers) MAY
   employ different interface of router X is heard by a MANET parameter values, and MAY change their
   interface of
      router Y.

   Symmetric 1-hop neighbor  - parameter values dynamically, subject to the constraints
   given in this section.  A router X particular case is a symmetric 1-hop neighbor
      of a router Y if a symmetric link exists between a where all MANET interface
   interfaces on router X and a all MANET interface on router Y.

   2-hop neighbor  - A router X is a 2-hop neighbor of a router Y if
      router X is routers within a 1-hop neighbor given MANET employ the same
   set of a interface parameter values.

5.3.1.  Message Intervals

   HELLO messages serve two principal functions:

   o  To advertise this router's interface addresses to its 1-hop neighbor of router Y, but
      is not router Y itself.

   Symmetric 2-hop neighbor  - A router X is a symmetric 2-hop neighbor
      neighbors.  The frequency of a router Y if router X these advertisements is a symmetric 1-hop neighbor regulated by
      the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.

   o  To advertise this router's knowledge of a
      symmetric 1-hop neighbor each of router Y, but is not router Y itself. its 1-hop neighborhood  -
      neighbors.  The 1-hop neighborhood frequency of a router X is the set advertisement of each such
      neighbor is regulated by the 1-hop neighbors of router X.

   Symmetric 1-hop neighborhood  - The symmetric 1-hop neighborhood of a
      router X interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - is the set of maximum time between the symmetric 1-hop neighbors transmission of router X.

   2-hop neighborhood  - The 2-hop neighborhood two
      successive HELLO messages on this MANET interface.  If using
      periodic transmission of HELLO messages, these SHOULD be at a router X is the set
      of the 2-hop neighbors
      separation of router X. (This may include routers HELLO_INTERVAL, possibly modified by jitter as
      specified in
      the 1-hop neighborhood of router X.)

   Symmetric 2-hop neighborhood [RFC5148].

   HELLO_MIN_INTERVAL  - The symmetric 2-hop neighborhood of a
      router X is the set of the symmetric 2-hop neighbors minimum interval between transmission of router X.
      two successive HELLO messages, on this MANET interface.  (This may include routers in the 1-hop neighborhood, or even
      minimum interval MAY be modified by jitter, as defined in
      the symmetric 1-hop neighborhood, of router X.)

   Constant
      [RFC5148].)

   REFRESH_INTERVAL  - A numerical value which MUST be is the same for all MANET
      interfaces of all routers maximum interval between advertisements in the MANET, at all times.

   Interface parameter  - A boolean or numerical value, specified
      separately for each MANET interface
      a HELLO message of each router.  A 1-hop neighbor address and its status.  In
      all intervals of length REFRESH_INTERVAL, a router MAY
      change interface parameter values at any time, subject to some
      constraints.

   Router parameter  - A boolean or numerical value, specified for MUST include
      each
      router, 1-hop neighbor address and not specific to an interface.  A router MAY change
      router parameter values its status in at any time, subject to some constraints.

   Information Base  - A collection of information maintained by this
      protocol, and which is to be made available to least one HELLO
      message on this MANET routing
      protocols.  An Information Base interface.  (This may be associated with a MANET
      interface, or with a router.

   Furthermore, this document uses in the following notational conventions:

   X contains y, same or y is contained in X,  is
      different HELLO messages.)
   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 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 INTERVAL_TIME Message TLV as defined in X, [RFC5497] is an unordered list inclusion
      operator, returning true if the unordered list X contains all
      elements y which are contained
      included in Y, and returning false
      otherwise. a := b  is an assignment operator, whereby the left side (a) is
      assigned the value of HELLO messages, then HELLO_INTERVAL MUST be
      representable as described in [RFC5497].

   If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
   its neighbor advertisements between HELLO messages in any manner,
   subject to the right side (b). constraints above.

   For a router to employ this protocol in a purely responsive manner on
   a MANET interface, REFRESH_INTERVAL and b may be values,
      addresses, or unordered lists (they must HELLO_INTERVAL SHOULD both be of the same type).

   c = d
   set to a value such that a responsive HELLO message is always
   expected in a comparison operator, returning true shorter period than this value.

   If a router has more than one MANET interface, then, even if the value
   router configures different values of HELLO_INTERVAL on each MANET
   interface, the
      left side (c) is equal to router SHOULD configure the same value of the right side (d). c and d
   HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
   messages may be values, addresses, or unordered lists (they must be sent.

5.3.2.  Information Validity Times

   The following interface parameters manage the validity time of link
   information:

   L_HOLD_TIME  - is the
      same type).  If c and d are unordered lists, then they are
      considered period of advertisement, on this MANET
      interface, of former 1-hop neighbor addresses as lost in HELLO
      messages, allowing recipients of these HELLO messages to
      accelerate removal of this information from their Link Sets.
      L_HOLD_TIME MAY be equal if they contain the same set of elements,
      regardless of to zero, if accelerated information removal
      is not required.

   H_HOLD_TIME  - is used as the order Value in which they are recorded the VALIDITY_TIME Message TLV
      included in either list
      (in which case c is contains d, and d contains c).  If c and d are
      addresses, they are considered equal only if their prefix lengths
      are also equal.

   e != f all HELLO messages on this MANET interface.  It 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  Is applicable to networks, especially wireless networks, in which
      unknown neighbors can be reached
      then used by local broadcast or multicast
      packets.

   o  Is designed to work in networks with each router receiving such a dynamic topology, HELLO message to
      indicate the validity of the information taken from that HELLO
      message and recorded in
      which the receiving router's Information Bases.

   The following constraints apply to these interface parameters:

   o  L_HOLD_TIME >= 0

   o  H_HOLD_TIME >= REFRESH_INTERVAL

   o  If HELLO messages may can be lost, such lost then both parameters SHOULD be
      significantly greater than REFRESH_INTERVAL.

   o  H_HOLD_TIME MUST be representable as due to collisions described in wireless
      networks.

   o  Supports routers that each have one or more participating MANET
      interfaces. [RFC5497].

5.3.3.  Link Quality

   The set of a router's interfaces may change over
      time.  Each following interface may have one parameters manage the usage of link quality
   (see Section 14):

   HYST_ACCEPT  - is the link quality threshold at or more interface addresses, above which a link
      becomes usable, if it was not already so.

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

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

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

   The following constraints apply to these may also be dynamically changing. interface parameters:

   o  Provides each router with current local topology information up to
      two hops away, and makes this local topology information available
      to MANET routing protocols in Information Bases.  0 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  Uses the packet and message formats specified  0 <= INITIAL_QUALITY <= 1.

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

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

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

5.3.4.  Jitter

   If jitter, as defined in [RFC5444].  This
      includes [RFC5148], is used then these parameters are
   as follows:

   HP_MAXJITTER  - represents the definition value of a MAXJITTER used in [RFC5148]
      for periodically generated HELLO Message Type, messages on this MANET interface.

   HT_MAXJITTER  - represents the value of MAXJITTER used in [RFC5148]
      for
      signalling local topology information.

   o  May interact with, and be extended by, other protocols, such as externally triggered HELLO messages on this MANET routing protocols, interface.

   For constraints on these interface parameters see Section 16.

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

   o  Is designed to work [RFC5148].

5.4.  Router Parameters

   The two router parameters defined by this specification are in a completely distributed manner, and does
      not depend on any central entity.

4.  Protocol Overview and Functioning the
   category of information validity time.

5.4.1.  Information Validity Time

   The objective following router parameter manages the validity time of this protocol is, for each router:

   o  To identify 1-hop neighbors and lost
   symmetric 1-hop neighbors of this
      router.

   o  To find neighbor information:

   N_HOLD_TIME  - is used as the interface 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 the router's symmetric 2-hop
      neighbors.

   o  To record this information in Information Bases that can from their 2-Hop Sets.  N_HOLD_TIME MAY be used
      by other protocols, of set
      to zero, if accelerated information removal is not required.

   I_HOLD_TIME  - is the period for which this neighborhood discovery a recently used local
      interface address is recorded.

   The following constraints applies to these router parameters:

   o  N_HOLD_TIME >= 0

   o  I_HOLD_TIME >= 0

5.5.  Parameter Change Constraints

   If protocol
      may be a part.

   These objectives parameters are achieved using local (1-hop) signaling that:

   o  Advertises changed dynamically, the presence of constraints in
   this section apply.

   HELLO_INTERVAL

      *  If the HELLO_INTERVAL for a router and its MANET interface addresses.

   o  Discovers links from neighboring routers.

   o  Performs bidirectionality checks increases, then the
         next HELLO message on this MANET interface MUST be generated
         according to the discovered links.

   o  Advertises discovered links, and whether each is symmetric, previous, shorter, HELLO_INTERVAL.  A number
         of subsequent HELLO messages MAY be generated according 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
         previous, shorter, HELLO_INTERVAL (but MUST include times
         according to current parameters).

      *  If the HELLO_INTERVAL for a given MANET
      interface, or to a interface decreases, then the
         following HELLO messages on this MANET router.  This protocol allows all
      parameters to interface MUST be changed dynamically, and
         generated according to be set independently this current, shorter, HELLO_INTERVAL.

   REFRESH_INTERVAL

      *  If the REFRESH_INTERVAL for each MANET router or a 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 interface increases, then
         the HELLO message that is used for local signaling.

   o  The generation content of subsequent HELLO messages from some must be organized such
         that the specification of the information in old value of REFRESH_INTERVAL is
         satisfied for a further period equal to the Information Bases.

   o  The updating old value of
         REFRESH_INTERVAL.

      *  If the Information Bases according REFRESH_INTERVAL for a MANET interface decreases, then
         it MAY be necessary to received reschedule HELLO
      messages and other events.

   o  The response to other events, such as message generation on
         that MANET interface, in order that the expiration specification of
      information in
         REFRESH_INTERVAL is satisfied from the Information Bases.

4.1.  Routers time of change.

   HYST_ACCEPT and Interfaces

   In order HYST_REJECT

      *  If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
         actions for a router to participate link quality change, as specified in a MANET, it Section 14.3,
         MUST have at
   least one, and possibly more, MANET interfaces.  Each MANET
   interface:

   o  Is configured with one or more addresses.  These addresses be taken.

   L_HOLD_TIME

      *  If L_HOLD_TIME changes, then L_time for all relevant Link
         Tuples MUST be
      unique within the router's 2-hop neighborhood.

   o  Has a set of interface parameters, defining 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 behavior of periodic HELLO message
         schedule on this MANET interface.  Each MANET interface MAY be individually
      parameterized.

   o  Has an Interface Information Base, recording information regarding
      links to changed.

   HT_MAXJITTER

      *  If HT_MAXJITTER changes, then externally triggered HELLO
         messages on this MANET interface and symmetric 2-hop neighbors which
      can MAY be reached through such links.

   o  Generates and processes HELLO messages.

   In addition to a set of MANET interfaces rescheduled.

5.6.  Constants

   The constant C (time granularity) is used as described above, each
   router has:

   o  A specified in [RFC5497].

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

   o

   A Neighbor router maintains a Local Information Base, recording Base that records information regarding
      current
   about its interfaces (MANET and recently lost 1-hop neighbors of this router.

   A router may non-MANET).  Each interface MUST have both MANET interfaces
   at least one address, and non-MANET interfaces.
   Interfaces of both of these types are recorded in a router's MAY have more than one address.

   The Local Information Base, which Base is used, but not updated, modified by signaling.  If a
   router's interface configuration changes, then the signaling of
   this protocol.

4.2. Local Information
   Base Overview

   Each 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 MUST reflect these changes.  This MAY maintain this
   information in the indicated form, or also result in any other organization which
   offers access to this information.  In particular note that it is not
   necessary signaling
   to remove Tuples advertise these changes.

   Interfaces and addresses MAY be excluded 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 router maintains a Local Information
   Base, which contains the and hence from HELLO messages, if they are not to be used for
   routing.

6.1.  Local Interface Set

   A router's local configuration information, specifically:

   o  The Local Interface Set, which Set records its local interfaces.  It
   consists of Local Interface Tuples,
      each of which represents an interface (MANET or non-MANET) of Tuples, one per interface:

      (I_local_iface_addr_list, I_manet)

   where:

   I_local_iface_addr_list  is an unordered list of the addresses of
      this interface.

   I_manet  is a boolean flag, describing if this interface is a MANET
      interface.

   Local Interface Tuples are removed from the Local Interface Set only
   when the
      router.

   o  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, which consists of Set

   A router's Removed Interface Address Tuples, each of which Set records a addresses which were
   recently used
      address of an as local interface (MANET or non-MANET) of addresses.  If a router's interface
   addresses are immutable then the router.

   The Local Removed Interface Address Set is used for generating HELLO messages,
   specifically for determining which interface addresses are to be
   included
   always empty and identified as local interfaces.  The MAY be omitted.  It consists of Removed Interface
   Address Set Tuples, one per address:

      (IR_local_iface_addr, IR_time)

   where:

   IR_local_iface_addr  is used to avoid incorrectly recording a formerly recently used address as a symmetric 2-hop neighbor's address.

   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 router maintains, for each of its MANET interfaces, an Interface
   Information Base, which contains 1-hop neighborhood and symmetric
   2-hop neighborhood information collected from this MANET interface,
   specifically:

   o  A Link Set, which records information about current and recently
      lost links between this MANET interface and MANET interfaces of
      1-hop neighbors.  The Link Set consists of Link Tuples, each of
      which contains information about a single link.  Link quality
      information (see Section 14),
      this router.

   IR_time  specifies when used, is recorded in Link
      Tuples.

   o this Tuple expires and MUST be removed.

7.  Interface Information Base

   A 2-Hop Set, which records the existence router maintains an Interface Information Base for each of symmetric its
   MANET interfaces.  This records information about links
      between symmetric 1-hop neighbors of this to that MANET
   interface and
      other routers (symmetric symmetric 2-hop neighbors). neighbors which can be reached in two
   hops using those links as the first hop.  The 2-Hop Interface Information
   Base includes the Link Set consists
      of and the 2-Hop Tuples, each of which records an Set.

   An address of a symmetric 2-hop neighbor, and all addresses neighbor can also be present as the
   address of a 1-hop neighbor.  This allows the corresponding router using this
   address to be immediately considered as a symmetric 2-hop neighbor if
   it fails to be a symmetric 1-hop neighbor.

   The Link Set for

   An element which specifies a MANET interface time is used for generating HELLO
   messages.  Specifically, considered expired if the Link Set information
   current time is included to both
   allow other routers to identify symmetric links and greater than or equal to populate the
   2-Hop Set. Recently lost links are recorded in the Link Set for a
   MANET interface so that they can be advertised time.  One such
   element, present in HELLO messages,
   accelerating their removal from relevant 1-hop neighbors' Link Sets.

   The Link Set for a MANET interface is most Tuples, indicates when expired that the
   Tuple itself updated on receiving a
   HELLO message, including recording symmetric links as indicated
   above.  The 2-Hop Set for a MANET interface is updated as indicated
   above, considered expired and is MUST be removed.  Tuples which
   do not itself used in generating HELLO messages.

4.2.3.  Neighbor Information Base

   Each router maintains have such a time element are removed at other times as
   specified, for example a Neighbor Information Base, Tuple is removed when all
   corresponding Link Tuples have been removed.

7.1.  Link Set

   A router's Link Set records links from other routers which contains
   collected information about current and are, or
   recently lost were, 1-hop
   neighbors, specifically:

   o  The Neighbor Set neighbors.  It consists of Neighbor Link Tuples, each of which
      records all addresses of
   representing a single 1-hop neighbor.  Neighbor Tuples
      are maintained as long as there are corresponding Link Tuples.

   o  The Lost Neighbor Set consists 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 Lost Neighbor Tuples, each the addresses of
      which records an address
      the MANET interface of a recently lost symmetric the 1-hop
      neighbor.

   The Neighbor Set associates all addresses neighbor;

   L_HEARD_time  is the time until which the MANET interface of each the
      1-hop neighbor.
   These addresses may neighbor would be included when generating a HELLO message, so
   that other symmetric considered heard if not considering link
      quality;

   L_SYM_time  is the time until which the link to the 1-hop neighbors can record this information in neighbor
      would be considered symmetric if not considering link quality;

   L_quality  is a
   2-Hop Set. The Neighbor Set can dimensionless number between 0 (inclusive) and 1
      (inclusive) describing the quality of a link; a greater value of
      L_quality indicating a higher quality link;
   L_pending  is a boolean flag, describing if a link is considered
      pending (i.e. a candidate, but not yet established, link);

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

   L_time  specifies when this Tuple expires and MUST be updated on receiving a HELLO
   message. removed.

   The Lost Neighbor Set status of the link, as obtained through HELLO message exchange
   and using link quality, is used to determine which addresses denoted L_status.  L_status can take the
   values PENDING, HEARD, SYMMETRIC and LOST.  The values LOST,
   SYMMETRIC and HEARD are to be
   included defined in a HELLO message as being lost (of a recently symmetric
   1-hop neighbor). Section 18.5.  The Lost Neighbor Set can itself be updated on
   receiving value PENDING
   is never used in a HELLO message.

4.3.  Signaling Overview

   This protocol contains message, it is only used locally by a signaling mechanism for maintaining the
   Interface Information Bases
   router, and the Neighbor Information Base.  If
   information from the link layer, or any other source, is available value distinct from LOST, SYMMETRIC and appropriate, it HEARD may also be used
   used.

   L_status is defined 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 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 router's 2-Hop Set records addresses of symmetric 2-hop neighbors,
   and the symmetric links to update symmetric 1-hop neighbors through which
   these Information
   Bases.  Such updates are subject to the constraints specified in
   Appendix B.

   Signaling symmetric 2-hop neighbors can be reached.  It consists of 2-Hop
   Tuples, each representing a single type of message, known as a HELLO
   message.  Each router generates HELLO messages on each of its MANET
   interfaces.  HELLO messages are generated independently on each MANET
   interface address of a symmetric 2-hop
   neighbor, and a single MANET router; the content interface of a given HELLO message
   depends on symmetric 1-hop neighbor.

      (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)

   where:

   N2_neighbor_iface_addr_list  is an unordered list of the MANET interface for which it has been generated.

   Each HELLO message identifies addresses of
      the MANET interface for which it is
   generated and transmitted; this allows recipients to identify that
   MANET interface.  Each HELLO message also reports the other
   interfaces (MANET and non-MANET) of the router; this allows
   recipients to associate a set of addresses with a single 1-hop
   neighbor.  Each HELLO message also includes symmetric 1-hop neighbor
   information from the Information Bases; which
      this allows detection information was received;
   N2_2hop_addr  is an address of
   local symmetric links, and a symmetric 2-hop neighbors.

4.3.1.  HELLO Message Generation

   HELLO messages are generated by neighbor which has a router for each of its
      symmetric link (using any MANET
   interfaces, and MAY be sent:

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

   o  As a response interface) to a change in the router itself, or its indicated
      symmetric 1-hop
      neighborhood, for example on first becoming active or in response
      to a new, lost, or changed status link.

   o  In a combination of these proactive and responsive mechanisms.

   Jittering of HELLO message generation neighbor;

   N2_time  specifies when this Tuple expires and transmission, as described
   in Section 11.2, SHOULD be used if appropriate.

   HELLO messages MAY MUST be scheduled independently for each MANET
   interface, or, interface parameters permitting, using the same
   schedule for all MANET interfaces of removed.

8.  Neighbor Information Base

   Each router maintains a router.

4.3.2.  HELLO Message Content

   The content Neighbor Information Base that records
   information about addresses of a HELLO message MUST satisfy the following:

   o current and recently symmetric 1-hop
   neighbors.

8.1.  Neighbor Set

   A HELLO message MUST contain router's Neighbor Set records all of the addresses in the Local
      Interface Set of the router to which the MANET interface belongs.

   o  For each MANET interface, within every time interval equal to the
      corresponding REFRESH_INTERVAL, the HELLO messages sent MUST
      collectively include all 1-hop neighbor.
   It consists of Neighbor Tuples, each representing a single 1-hop
   neighbor:

      (N_neighbor_addr_list, N_symmetric)

   where:

   N_neighbor_addr_list  is an unordered list of the relevant information in addresses of a
      1-hop neighbor;

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

   Neighbor Tuples are removed from the Neighbor Set only when
   corresponding Link Set and Tuples expire from the routers' Link Set, i.e.
   Neighbor Information Base.  Note
      that when determining whether to include information in a HELLO
      message, the sender MUST consider all times up Tuples are not directly subject to the latest time
      when it may send its next HELLO message on this MANET interface.

   o timer-based expiration.

8.2.  Lost Neighbor Set

   A HELLO message MUST include exactly one VALIDITY_TIME Message
      TLV, as specified in [RFC5497], that indicates the length router's Lost Neighbor Set records addresses of time
      for routers which the message content
   recently were symmetric 1-hop neighbors, but are now advertised as
   lost.  It consists of Lost Neighbor Tuples, each representing a
   single such address:

      (NL_neighbor_addr, NL_time)

   where:

   NL_neighbor_addr  is to be considered valid, an address of a router which recently was a
      symmetric 1-hop neighbor of this router;
   NL_time  specifies when this Tuple expires and is
      therefore to MUST be included removed.

9.  Local Information Base Changes

   The Local Information Base MUST change to respond to changes in the receiving
   router's local interface configuration.  The router MUST update its
   Interface Information Base.

   o  A periodically generated HELLO message SHOULD include exactly one
      INTERVAL_TIME Message TLV, as specified Base and Neighbor Information Base in response
   to such changes.  If any changes in [RFC5497], that
      indicates the current value Interface Information Base or
   the Neighbor Information Base satisfy any of HELLO_INTERVAL for that MANET
      interface, i.e. the period within which a further HELLO message is
      guaranteed to conditions described
   in Section 13, then those changes must be sent on that MANET interface.

4.3.3.  HELLO Message Processing applied immediately, unless
   noted otherwise.

   A router MAY transmit HELLO messages received by a router are used in response to update the these changes.

9.1.  Adding an Interface
   Information Base for the MANET

   If an interface on which that HELLO message is received and added to the Neighbor Information Base.  Specifically:

   o  The router ensures that there then this is a single Neighbor Tuple
      corresponding to indicated by the originator
   addition of that HELLO message.

   o  The router ensures that there is a Link Tuple, with appropriate
      status (heard or symmetric) and advertised duration, corresponding Local Interface Tuple to the link between Local Interface Set. If
   the new interface is a MANET interfaces on which that HELLO
      message was sent and received.  One or more Lost Neighbor Tuples
      may interface then an initially empty
   Interface Information Base MUST be created if the for this new MANET
   interface.  The actions in Section 9.3 MUST be taken for each address
   of this added interface.  A HELLO message reports that the link was
      lost.

   o  If the link between the MAY be sent on all MANET interfaces
   interfaces, it SHOULD be sent on which the HELLO
      message was sent and received new interface if it is symmetric, a MANET
   interface.  If using scheduled messages, then a message schedule MUST
   be established on the router
      ensures that there are new MANET interface.

9.2.  Removing an Interface

   If an interface is removed from the appropriate 2-Hop Tuples, with
      advertised duration.

   The processing defined in router, then this specification handles any unexpected
   and erroneous information MUST result in a HELLO message, maintaining
   changes to the
   constraints on Local Information Base contents specified in Appendix B.

4.4.  Link Quality

   Some links in a MANET may be marginal, e.g., due and to adverse wireless
   propagation.  In order the Neighbor Information
   Base as follows:

   1.  Identify the Local Interface Tuple that corresponds to avoid using such marginal links, the
       interface to be removed.

   2.  For each address (henceforth removed address) in the
       I_local_iface_addr_list of that Local Interface Tuple, create a link
   quality value
       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 removed is recorded in each Link Tuple.  A a MANET router
   considers links interface (i.e. with
       I_manet = true) then:

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

       2.  All Neighbor Tuples for which an insufficient link quality is recorded as
   lost.  Modifying none of the recorded link quality addresses in its
           N_neighbor_addr_list are contained in any
           L_neighbor_iface_addr_list in a any remaining Link Tuple is
   OPTIONAL. Set, are
           removed.

   If link quality the removed interface is not to be modified it MUST the last MANET interface of the router,
   then there will be set to
   indicate an always usable quality link.

   Link quality information is only used locally no remaining Interface Information Bases, and is not used in
   signaling.  Routers may interoperate whether they are using the 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 this specification are described
   router will longer participate in this section.

5.1.  Protocol protocol.

   After removing the interface and Port Numbers

   This protocol specifies making these changes, a HELLO messages, which are included in packets
   as defined by [RFC5444].  These packets may
   message MAY be sent either using the
   "manet" protocol number or the "manet" well-known UDP port number, as
   specified in [RFC5498].

5.2.  Multicast on all remaining MANET interfaces.

9.3.  Adding an Address

   This protocol specifies HELLO messages, which are included in packets
   as defined to an Interface

   If an address is added to an interface then this is indicated by [RFC5444].  These packets may be locally transmitted
   using the link local multicast
   addition of an address "LL-MANET-Routers", as
   specified in [RFC5498].

5.3.  Interface Parameters to the appropriate I_local_iface_addr_list.
   The interface parameters used by this specification may following changes MUST be classified
   into made to the following four categories:

   o  Message intervals

   o Information validity times

   o Bases:

   1.  The Neighbor Tuples, if any, whose N_neighbor_addr_list contains
       the added address, are removed.

   2.  Any Link Tuples, in any Link quality

   o  Jitter

   These are detailed Set, whose
       L_neighbor_iface_addr_list contains:

       *  the added address; OR

       *  any address in the following sections.

   Different MANET interfaces (on N_neighbor_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_addr = the same or on different routers) MAY
   employ different interface parameter values, added
       address, are removed.

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

   After adding the address and making these changes, a HELLO message
   MAY change their
   interface parameter values dynamically, subject to the constraints
   given in this section.  A particular case is where all MANET
   interfaces be sent on all MANET routers within a given MANET employ interfaces.

   These changes, other than to the same
   set of interface parameter values.

5.3.1.  Message Intervals

   HELLO messages serve two principal functions:

   o  To advertise this router's interface addresses appropriate I_local_iface_addr_list,
   are made in order to its 1-hop
      neighbors.  The frequency maintain consistency of these advertisements is regulated by the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.

   o  To advertise this router's knowledge of each of its 1-hop
      neighbors.  The frequency Information Bases.
   Specifically, these changes remove any record of the advertisement any use of each such
      neighbor is regulated this
   address by routers in the interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - is the maximum time between 1-hop neighborhood or in the transmission symmetric
   2-hop neighborhood of two
      successive HELLO messages on this MANET interface. router.

9.4.  Removing an Address from an Interface

   If using
      periodic transmission of HELLO messages, these SHOULD an address (henceforth removed address) is removed from an
   interface then:

   1.  Identify the Local Interface Tuple that corresponds to the
       address to be at a
      separation of HELLO_INTERVAL, possibly modified by jitter as
      specified in [RFC5148].

   HELLO_MIN_INTERVAL  - removed.

   2.  If this is the minimum interval between transmission only address of
      two successive HELLO messages, on this MANET interface.  (This
      minimum interval MAY be modified by jitter, as defined that interface (the only address
       in
      [RFC5148].)

   REFRESH_INTERVAL  - is the maximum interval between advertisements corresponding I_local_iface_addr_list) then remove that
       interface as specified in
      a HELLO message of each 1-hop neighbor Section 9.2.

   3.  Otherwise:

       1.  Remove the removed address and its status.  In
      all intervals of length REFRESH_INTERVAL, from this I_local_iface_addr_list.

       2.  Create a router MUST include
      each 1-hop neighbor Removed Interface Address Tuple with:

           +  IR_local_iface_addr := removed address;

           +  IR_time := current time + I_HOLD_TIME.

   After removing the address and its status in at least one making these changes, a HELLO message
   MAY be sent on this all MANET interface.  (This may be interfaces.

10.  Packets and Messages

   The packet and message format used by this protocol is defined in
   [RFC5444], which is used with the same or in
      different HELLO messages.)

   The following constraints apply to these interface parameters:

   o  HELLO_INTERVAL > 0

   o  HELLO_MIN_INTERVAL >= 0

   o  HELLO_INTERVAL >= HELLO_MIN_INTERVAL considerations:

   o  REFRESH_INTERVAL >= HELLO_INTERVAL  This protocol specifies one Message Type, the HELLO message.

   o  If an INTERVAL_TIME  A HELLO message MAY use any combination of Message TLV as defined in [RFC5497] is
      included Header options
      specified in a [RFC5444].

   o  HELLO messages, then HELLO_INTERVAL messages MUST NOT be
      representable as described in [RFC5497].

   If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
   its neighbor advertisements between forwarded.

   o  HELLO messages MAY be included in any manner,
   subject to the constraints above.

   For a router to employ this protocol multi-message packets as
      specified in a purely responsive manner on
   a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both [RFC5444].

   o  Received HELLO messages MUST be
   set to a value such that a responsive parsed in accordance with
      [RFC5444].  A HELLO message which is always
   expected not 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 MANET
   interface, the router SHOULD configure the same value of
   HELLO_MIN_INTERVAL on all MANET interfaces on which responsive conformance with
      [RFC5444] MUST be discarded.  A HELLO
   messages message may also be sent.

5.3.2.  Information Validity Times

   The following interface parameters manage the validity time
      discarded for other reasons, see Section 12.1.

   o  This protocol specifies three Address Block TLVs.  It also uses
      two Message TLVs defined in [RFC5497].  These five TLV Types are
      all defined only with Type Extension = 0.  TLVs of link
   information:

   L_HOLD_TIME  - is the period other types,
      and of advertisement, on these types but without Type Extension = 0, are ignored by
      this MANET
      interface, of former 1-hop neighbor addresses as lost protocol.  All references in HELLO
      messages, allowing recipients of these HELLO messages to
      accelerate removal of this information from their Link Sets.
      L_HOLD_TIME MAY be set specification to, for
      example, an Address Block TLV with Type = LINK_STATUS, are to zero, if accelerated information removal
      is not required.

   H_HOLD_TIME  - is used be
      considered as the value in the referring to an Address Block TLV with Type =
      LINK_STATUS and Type Extension = 0.

10.1.  HELLO Messages

   A HELLO message MUST contain:

   o  Exactly one VALIDITY_TIME Message TLV
      included as specified in all HELLO messages on this [RFC5497],
      representing H_HOLD_TIME for the transmitting MANET interface.
      The following constraints apply to these interface parameters:

   o  L_HOLD_TIME >= 0

   o  H_HOLD_TIME >= REFRESH_INTERVAL

   o  If HELLO messages can options included in [RFC5497] for representing zero and
      infinite times MUST NOT be lost then both parameters used.

   A HELLO message which is transmitted periodically SHOULD be
      significantly greater than REFRESH_INTERVAL. contain, and
   otherwise MAY contain:

   o  H_HOLD_TIME MUST be representable  Exactly one INTERVAL_TIME Message TLV as described specified in [RFC5497].

5.3.3.  Link Quality

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

   HYST_ACCEPT  - is [RFC5497],
      representing HELLO_INTERVAL for the link quality threshold at transmitting MANET interface.
      The options included in [RFC5497] for representing zero and
      infinite times MUST NOT be used.

   A HELLO message MAY contain:

   o  Other Message TLVs.

   o  One or above which a link
      becomes usable, if it was not already so.

   HYST_REJECT  - is the link quality threshold below more Address Blocks, each with an associated Address Block
      TLV Block, which MAY contain other Address Block TLVs.

10.1.1.  Address Blocks

   All addresses in a link
      becomes unusable, if it was not already so.

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

   INITIAL_PENDING  - if true, then a newly identified link is
      considered pending, and is not usable until the link quality has
      reached or exceeded router's Local Interface Set (i.e. in any
   I_local_iface_addr_list) MUST be included in the Address Blocks in
   all generated HELLO messages with the HYST_ACCEPT threshold.

   The following constraints apply to these interface parameters:

   o  0 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  0 <= INITIAL_QUALITY <= 1.

   o exception.  If link quality the
   MANET interface on which the HELLO message is not updated, then INITIAL_QUALITY >=
      HYST_ACCEPT.

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

   o  If INITIAL_QUALITY < HYST_REJECT, to be sent has a single
   address with maximum prefix length (i.e. /32 for IPv4, /128 for
   IPv6), then INITIAL_PENDING := true.

5.3.4.  Jitter

   If jitter, as defined that address MAY be omitted from being included in [RFC5148], any
   Address Block, provided that this address is used then these parameters are included as follows:

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

   HT_MAXJITTER  - represents which the value HELLO message is included.
   All addresses of MAXJITTER used the router's interfaces included in [RFC5148]
      for externally triggered HELLO messages on this MANET interface.

   For constraints on these interface parameters see [RFC5148].

5.4.  Router Parameters

   The two router parameters an Address Block
   MUST be associated with an Address Block TLV with Type = LOCAL_IF, as
   defined by this specification are in Table 1.

   +----------+---------+----------------------------------------------+
   |   Name   |  Value  | Description                                  |
   |          |  Length |                                              |
   +----------+---------+----------------------------------------------+
   | LOCAL_IF | 1 octet | Specifies that the
   category of information validity time.

5.4.1.  Information Validity Time

   The following router parameter manages address is an address     |
   |          |         | associated with the validity time MANET interface on which |
   |          |         | the message was sent (THIS_IF) or another    |
   |          |         | interface of the sending router (OTHER_IF).  |
   +----------+---------+----------------------------------------------+

                     Table 1: LOCAL_IF TLV definition

   Address Blocks MAY contain current or recently lost
   symmetric 1-hop neighbor information:

   N_HOLD_TIME  - neighbors'
   addresses, each of which is used associated with one or both Address Block
   TLVs as described in Table 2.

   +--------------+---------+------------------------------------------+
   |     Name     |  Value  | Description                              |
   |              |  Length |                                          |
   +--------------+---------+------------------------------------------+
   |  LINK_STATUS | 1 octet | Specifies the period during which former status 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 of a symmetric 1-hop neighbor addresses are advertised as lost in HELLO messages,
      allowing recipients  |
   |              |         | of these the router transmitting the HELLO messages to accelerate removal     |
   |              |         | message.                                 |
   +--------------+---------+------------------------------------------+

           Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition

   An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
   Value = LOST also performs the function of this information from their 2-Hop Sets.  N_HOLD_TIME MAY be set
      to zero, if accelerated information removal is not required.

   I_HOLD_TIME  - is an Address Block TLV with
   Type = OTHER_NEIGHB and the period for which a recently used local
      interface address is recorded. same Value.  The following constraints applies to these router parameters:

   o  N_HOLD_TIME >= 0

   o  I_HOLD_TIME >= 0

5.5.  Parameter Change Constraints

   If protocol parameters are changed dynamically, latter SHOULD NOT also
   be included associated with the constraints in
   this section apply.

   HELLO_INTERVAL

      * same address.  If an Address Block
   TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an
   Address Block TLV with Type = OTHER_NEIGHB and Value = LOST
   associated with the HELLO_INTERVAL for a MANET interface increases, same address, then the
         next HELLO message on this MANET interface latter MUST be generated
         according to the previous, shorter, HELLO_INTERVAL.  A number
         of subsequent HELLO messages ignored,
   and SHOULD NOT be included.  See Appendix A.

   Other addresses MAY be generated according to the
         previous, shorter, HELLO_INTERVAL (but included in Address Blocks, but MUST include times
         according to current parameters).

      *  If the HELLO_INTERVAL for a MANET interface decreases, then NOT be
   associated with any of the
         following HELLO messages on Address Block TLVs specified in this
   specification.

11.  HELLO Message Generation

   Each MANET interface 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 generate HELLO messages must be organized such
         that the specification of the old value of REFRESH_INTERVAL is
         satisfied for a further period equal to the old value of
         REFRESH_INTERVAL.

      *  If the REFRESH_INTERVAL for a MANET interface decreases, then
         it MAY be necessary according to reschedule HELLO message generation on
         that MANET interface, in order that the
   specification of
         REFRESH_INTERVAL is satisfied from the time of change.

   HYST_ACCEPT and HYST_REJECT

      *  If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
         actions for link quality change, as specified in Section 14.3,
         MUST be taken.

   L_HOLD_TIME

      *  If L_HOLD_TIME changes, then L_time this section.  HELLO messages are generated for all relevant Link
         Tuples each
   MANET interface independently.  HELLO message generation and
   scheduling MUST be changed.

   N_HOLD_TIME

      *  If N_HOLD_TIME changes, then NL_time according to the interface parameters for all relevant Lost
         Neighbor Tuples MUST that
   MANET interface, and MAY be changed.

   HP_MAXJITTER

      *  If HP_MAXJITTER changes, then independent for each MANET interface or,
   interface parameters permitting, MANET interfaces MAY use the same
   schedule.

   If transmitting periodic HELLO messages then, following a HELLO
   message
         schedule transmission on this a MANET interface MAY interface, another HELLO message MUST
   be changed.

   HT_MAXJITTER

      *  If HT_MAXJITTER changes, then externally triggered transmitted on the same MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive HELLO
         messages message
   transmissions on this the same MANET interface MAY MUST be rescheduled.

5.6.  Constants

   The constant C (time granularity) is used separated by at
   least HELLO_MIN_INTERVAL, except as specified noted in [RFC5497].

6.  Local Information Base

   A router maintains a Local Information Base that records information
   about its interfaces (MANET and non-MANET).  Each interface Section 11.2.1.

11.1.  HELLO Message Specification

   HELLO messages are generated independently on each MANET interface.

   All addresses in any I_local_iface_addr_list MUST have
   at least one address, and MAY have more than one address.

   The Local Information Base is not modified by signaling. be included, except
   that:

   o  If a
   router's the interface configuration changes, then on which the Local Information
   Base MUST reflect these changes.  This HELLO message is to be sent has a
      single address with maximum prefix length (i.e. /32 for IPv4, /128
      for IPv6) then that address MAY also result be omitted, provided that this
      address is included as the sending address of the IP datagram in signaling
   to advertise these changes.

   Interfaces and
      which the HELLO message is included.

   All such included addresses MAY MUST be excluded from the Local Information
   Base, associated with an Address Block
   TLV with Type := LOCAL_IF and hence from HELLO messages, if they are not Value according to be used for
   routing.

6.1.  Local Interface Set

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

      (I_local_iface_addr_list, I_manet)

   where:

   I_local_iface_addr_list the following:

   o  If the address is an unordered list address of the sending MANET interface, then
      Value := THIS_IF.

   o  Otherwise, Value := OTHER_IF.

   The following addresses of
      this interface.

   I_manet  is a boolean flag, describing if this interface is a current or former 1-hop neighbors MAY be
   included in any HELLO message, respecting the parameter
   REFRESH_INTERVAL for each association for that MANET
      interface.

   Local Interface Tuples are removed interface:

   o  Addresses of MANET interfaces of 1-hop neighbors from the Local Interface Link Set only
   when
      of 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 router's Removed Interface Address Set records addresses which were
   recently used as local interface addresses.  If a router's Information Base for this MANET interface (i.e.
      from an L_neighbor_iface_addr_list), other than those from Link
      Tuples with L_status = PENDING.

   o  Other addresses are immutable then of symmetric 1-hop neighbors from the Removed Interface Address Neighbor Set is
   always empty and 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 a recently used address of an interface
      of
      this router.

   IR_time  specifies when this Tuple expires and MUST be removed.

7.  Interface this router's Neighbor Information Base

   A router maintains (i.e. from an Interface Information Base for each
      N_neighbor_addr_list).

   o  Addresses of its MANET interfaces.  This records information about links to that MANET
   interface and interfaces of previously symmetric 2-hop or heard
      1-hop neighbors which can be reached in two
   hops using those links as the first hop.  The Interface Information
   Base includes connected on this MANET interface from the Link
      Set and the 2-Hop Set.

   An address of a symmetric 2-hop neighbor can also be present as the
   address of a 1-hop neighbor.  This allows the router using Interface Information Base for this
   address to be immediately considered as a symmetric 2-hop neighbor if
   it fails to be a MANET interface
      (i.e. from an L_neighbor_iface_addr_list with L_status = LOST).

   o  Other addresses of previously symmetric 1-hop neighbor.

   An element which specifies a time is considered expired if the
   current time is greater than or equal to that time.  One such
   element, present in most Tuples, indicates when expired that neighbors from the
   Tuple itself is considered expired and MUST be removed.  Tuples which
   do not have such a time element are removed at other times as
   specified, for example a
      Lost Neighbor Tuple is removed when all
   corresponding Link Tuples have been removed.

7.1.  Link Set

   A of this router's Link Set records links Neighbor Information Base (i.e.
      from other routers which are, an NL_neighbor_addr).

   Each such address MUST be associated with one or
   recently were, 1-hop neighbors.  It consists of Link Tuples, more appropriate
   Address Block TLVs.  Specifically:

   1.  For 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 address (henceforth linked address) which is contained
       in an unordered list of the addresses L_neighbor_iface_addr_list of a Link Tuple in the Link Set
       for this MANET interface of the 1-hop neighbor;

   L_HEARD_time  is the time until interface, for which L_status != PENDING, include
       the MANET interface of the
      1-hop linked address with an associated Address Block TLV with:

       *  Type := LINK_STATUS; AND

       *  Value := L_status.

   2.  For each address (henceforth neighbor would be considered heard if not considering link
      quality;

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

   L_quality is contained
       in an N_neighbor_addr_list in a dimensionless number between 0 (inclusive) Neighbor Tuple with N_symmetric =
       true, and 1
      (inclusive) describing which has not already been included with an associated
       Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC,
       include 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 neighbor address with an associated Address Block TLV
       with:

       *  Type := OTHER_NEIGHB; AND

       *  Value := SYMMETRIC.

   3.  For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
       lost address) has not yet established, link);

   L_lost  is a boolean flag, describing if a link is considered already been included, include the lost
      due
       address with an associated Address Block TLV with:

       *  Type := OTHER_NEIGHB; AND

       *  Value := LOST.

   If any such addresses have been added to low link quality;

   L_time  specifies when this Tuple expires and MUST be removed.

   The status of the link, as obtained through these Information Bases
   since the last HELLO message exchange was sent on this MANET interface, or if
   their status (as indicated by these TLVs and using link quality, is denoted L_status.  L_status can take the
   values PENDING, HEARD, SYMMETRIC and LOST.  The values LOST,
   SYMMETRIC Values they
   associate with that address) have changed since that address was last
   reported on this MANET interface, then that address, and HEARD are defined the
   indicated TLVs, MUST be included in Section 18.5.  The value PENDING the HELLO message.

   If an address of a 1-hop neighbor is never 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 a HELLO message, it is only used locally by a
   router, and any value distinct from LOST, SYMMETRIC and HEARD may 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 the same address included in the
   same HELLO message MAY be
   used.

   L_status is defined 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 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 router's 2-Hop Set records addresses applied to the same or different copies of symmetric 2-hop neighbors,
   that address.

11.2.  HELLO Message Transmission

   HELLO messages are transmitted in the format specified by [RFC5444].

11.2.1.  HELLO Message Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If using data link and the symmetric links to symmetric 1-hop neighbors through
   physical layers which
   these symmetric 2-hop neighbors can are subject to packet loss due to collisions,
   HELLO messages SHOULD be reached.  It consists of 2-Hop
   Tuples, each representing a single address of jittered as described in [RFC5148].

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

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

   Each form of jitter described in [RFC5148] requires a single MANET parameter
   MAXJITTER.  These interface of 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 a symmetric 1-hop neighbor.

      (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)

   where:

   N2_neighbor_iface_addr_list HELLO
   message is an unordered list not sent within HELLO_MIN_INTERVAL of the addresses of previous HELLO
   message on the same MANET interface of the symmetric 1-hop neighbor from which interface, then HELLO_MIN_INTERVAL SHOULD
   be reduced by jitter, with maximum reduction HP_MAXJITTER, as
   described in [RFC5148].  In this information was received;

   N2_2hop_iface_addr  is an address of case HP_MAXJITTER MUST NOT be
   greater than HELLO_MIN_INTERVAL.

12.  HELLO Message Processing

   On receiving a symmetric 2-hop neighbor which
      has HELLO message, a symmetric link (using any MANET interface) to router MUST first check if the indicated
      symmetric 1-hop neighbor;

   N2_time  specifies when
   message is invalid for processing by this Tuple expires and router, as defined in
   Section 12.1.  Otherwise the receiving router MUST be removed.

8.  Neighbor update its
   appropriate Interface Information Base

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

8.1.  Neighbor Set

   A router's Neighbor Set records all 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 as specified in Section 12.3 to Section 12.6.  These updates
   MUST be performed in the order in which they are presented in this
   specification.  If any changes satisfy any of the addresses conditions
   described in Section 13 then the indicated consequences in that
   section MUST be applied immediately, unless noted otherwise.

   All message processing, including determination of whether a 1-hop neighbor;

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

   Neighbor Tuples are removed from the Neighbor Set invalid, considers only when
   corresponding Link Tuples expire from the routers' Link Set, i.e.
   Neighbor Tuples TLVs with Type Extension = 0.  TLVs with
   any other type extension are not directly subject ignored.  All references to, for
   example, a TLV with Type = LINK_STATUS refer to timer-based expiration.

8.2.  Lost Neighbor Set

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

      (NL_neighbor_iface_addr, NL_time)

   where:

   NL_neighbor_iface_addr TLV with Type =
   LINK_STATUS and Type Extension = 0.

12.1.  Invalid Message

   A received HELLO message is an invalid for processing by this router if
   any of the following conditions are true:

   o  The address length as specified in the Message Header is not equal
      to the length of the addresses used by this router.

   o  The message has a router which recently was <msg-hop-limit> field in its Message Header with
      a symmetric 1-hop neighbor of this router;

   NL_time  specifies when this Tuple expires and MUST be removed.

9.  Local Information Base Changes value other than one.  (Note that the message need not have a
      <msg-hop-limit> field.)

   o  The Local Information Base MUST change to respond to changes message has a <msg-hop-count> field in its Message Header with
      a value other than zero.  (Note that the
   router's local interface configuration. message need not have a
      <msg-hop-count> field.)

   o  The router MUST update message does not have a Message TLV with Type = VALIDITY_TIME
      in its
   Interface Information Base Message TLV Block.

   o  The message has more than one Message TLV with Type =
      VALIDITY_TIME in its Message TLV Block.

   o  The message has more than one Message TLV with Type =
      INTERVAL_TIME in its Message TLV Block.

   o  The message has any Address Block TLV(s) with Type = LOCAL_IF and Neighbor Information Base
      any single Value v such that v != THIS_IF and v != OTHER_IF.

   o  Any address (including different copies of an address, in the same
      or different Address Blocks) is associated with more than one
      Value by one or more Address Block TLV(s) with Type = LOCAL_IF.

   o  Any address (henceforth the local address) associated with an
      Address Block TLV with Type = LOCAL_IF is one of the receiving
      router's current or recently used addresses (i.e. the local
      address is contained in response
   to such changes.  If any changes I_local_iface_addr_list in the Local
      Interface Information Base Set or the Neighbor Information Base satisfy local address = any of the conditions described
   in Section 13, then those changes must be applied immediately, unless
   noted otherwise.

   A router MAY transmit HELLO messages IR_local_iface_addr in response to these changes.

9.1.  Adding an
      the Removed Interface

   If Address Set).

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

   o  Any address (including different copies of an interface is added to address, in the router then this same
      or different Address Blocks) is indicated associated with more than one
      Value by the
   addition of a Local Interface Tuple to the Local Interface Set. If
   the new interface is a MANET interface then an initially empty
   Interface Information Base MUST be created for this new MANET
   interface. one or more Address Block TLVs with Type = LINK_STATUS.

   o  The actions in Section 9.3 MUST be taken for each message has any Address Block TLV(s) with Type = OTHER_NEIGHB
      with any single Value v such that v != LOST and v != SYMMETRIC.

   o  Any address (including different copies of this added interface.  A HELLO message MAY be sent on all MANET
   interfaces, it SHOULD be sent on an address, in the new interface if it same
      or different Address Blocks) is a MANET
   interface.  If using scheduled messages, then associated with more than one
      Value by one or more Address Block TLVs with Type = OTHER_NEIGHB.

   A router MAY recognize additional reasons for identifying that a
   message schedule MUST
   be established on the new MANET interface.

9.2.  Removing an Interface

   If an interface is removed from the router, then this MUST result in
   changes to the Local Information Base badly formed and to therefore invalid for processing.

   An invalid message MUST be silently discarded, without updating the Neighbor
   router's Information
   Base as follows:

   1.  Identify the Local Interface Tuple that corresponds to the
       interface to be removed.

   2. Bases.

12.2.  Definitions

   For each address (henceforth removed address) in the
       I_local_iface_addr_list purpose of that Local Interface Tuple, create 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 this section, note the interface to be removed following definitions:

   o  "validity time" is a MANET interface (i.e. calculated from the Message TLV with
       I_manet Type = true) then:

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

       2.  All Neighbor Tuples for which none
      VALIDITY_TIME of the addresses in its
           N_neighbor_iface_addr_list are contained HELLO message as specified in any
           L_neighbor_iface_addr_list [RFC5497].
      (Note that, as specified by Section 12.1, there must be exactly
      one such Message TLV in any remaining Link Set, are
           removed.

   If a router removes the Local Interface Tuple that contains the
   address which is used to define the router's originator address, as
   defined HELLO message.)  All information in [RFC5444], then
      the router MAY change originator address.
   If this address may now be HELLO message used by another router (e.g., if this specification has the same validity
      time.

   o  "Receiving Address List" is the
   address was taken from a prefix no longer delegated I_local_iface_addr_list
      corresponding to this router,
   or if the address MANET interface on which the HELLO message
      was assigned received

   o  "Sending Address List" is the list of the addresses contained in
      the HELLO message with an expiration timer, associated Address Block TLV with Type =
      LOCAL_IF and not
   renewed before expiration) then this router MUST change its
   originator address. Value = THIS_IF.  If the removed interface Sending Address List is
      otherwise empty, then the last MANET interface Sending Address List contains a single
      address (with maximum prefix length, i.e. /32 for IPv64, /128 for
      IPv6) equal to the sending address of the router,
   then there will be no remaining Interface Information Bases, and IP datagram in which the
   router will longer participate
      HELLO message was included.

   o  "Neighbor Address List" is the Sending Address List, plus the
      addresses contained in this protocol.

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

9.3.  Adding with an associated
      Address to an Interface

   If an address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.

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

   o  "Removed Address List" is a list of addresses created by this
      HELLO message processing which were formerly reported as local by
      the router originating the HELLO message, but which are not
      included in the Neighbor Address List.  This list is initialized
      as empty.

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

12.3.  Updating the
   addition of an address to Neighbor Set

   On receiving a HELLO message, the appropriate I_local_iface_addr_list.
   The following changes router MUST be made to update its Neighbor Set
   and populate the Information Bases: Removed Address List and Lost Address List:

   1.  The  Find all Neighbor Tuples, 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 Tuples (henceforth matching Neighbor Tuples)
       where:

       *  any  N_neighbor_addr_list contains at least one address in the N_neighbor_iface_addr_list of any removed
          Neighbor Tuple Address List.

   2.  If there are removed; apply Section 13.2, but not Section 13.3. no matching Neighbor Tuples, then:

       1.  Create a new Neighbor Tuple with:

           +  N_neighbor_addr_list := Neighbor Address List;

           +  N_symmetric := false.

   3.  Any Lost  If there is one matching Neighbor Tuples whose NL_neighbor_iface_addr = Tuple, then:

       1.  If the added
       address, are removed.

   4.  Any 2-Hop Tuples whose N2_2hop_iface_addr = matching Neighbor Tuple's N_neighbor_addr_list !=
           Neighbor Address List, then:

           1.  For each address (henceforth removed address) which is
               contained in that N_neighbor_addr_list, but is not
               contained in the added address,
       are removed.

   After adding Neighbor Address List:

               1.  Add the removed address and making these changes, a HELLO message
   MAY be sent on all MANET interfaces.

   These changes, other than to the appropriate I_local_iface_addr_list,
   are made in order to maintain consistency of Removed Address List.

               2.  If N_symmetric = true, then add the Information Bases.
   Specifically, these changes remove any record of any use of this removed address by routers in the 1-hop neighborhood or in
                   to the symmetric
   2-hop neighborhood of this router.

9.4.  Removing an Lost Address from an Interface List.

           2.  Update the matching Neighbor Tuple by:

               -  N_neighbor_addr_list := Neighbor Address List.

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

       1.  For each address (henceforth removed address) which is removed from an
   interface then:

   1.  Identify
           contained in the Local Interface Tuple that corresponds to N_neighbor_addr_list of any of the matching
           Neighbor Tuples:

           1.  Add the removed address to be removed. the Removed Address List.

           2.  If this is the only address of that interface (the only address
       in the corresponding I_local_iface_addr_list) N_symmetric = true, then remove that
       interface as specified in Section 9.2.

   3.  Otherwise:

       1.  Remove add the removed address from this I_local_iface_addr_list. to
               the Lost Address List.

       2.  Create  Replace the matching Neighbor Tuples by a Removed Interface Address single Neighbor
           Tuple with:

           +  IR_local_iface_addr  N_neighbor_addr_list := removed address; Neighbor Address List;

           +  IR_time  N_symmetric := current time + I_HOLD_TIME.

   If false

12.4.  Updating the Lost Neighbor Set

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

   1.  For each address that (henceforth lost address) which is used to define the router's
   originator address, as defined contained in [RFC5444], then
       the router MAY
   change originator address.  If this address may now be used by
   another router (e.g., Lost Address List, if the address was taken from a prefix no
   longer delegated to this router, or if the address was assigned Lost Neighbor Tuple with
   an expiration timer, and not renewed before expiration)
       NL_neighbor_addr = lost address exists, then this add a Lost Neighbor
       Tuple with:

       *  NL_neighbor_addr := lost address;

       *  NL_time := current time + N_HOLD_TIME.

12.5.  Updating the Link Set

   On receiving a HELLO message, a router MUST change update its originator address.

   After removing Link Set for
   the MANET interface on which the address and making these changes, a HELLO message
   MAY be sent on all MANET interfaces.

10.  Packets and Messages

   The packet and message format used by this protocol is defined received:

   1.  Remove all addresses in
   [RFC5444], which is used with the following considerations:

   o  This protocol specifies one Message Type, Removed Address List from the HELLO message.

   o  A HELLO message MAY use any combination
       L_neighbor_iface_addr_list of Message Header options.

   o  HELLO messages MUST NOT be forwarded.

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

   o  Received HELLO messages MUST be parsed in accordance with
      [RFC5444].  A HELLO message which all Link Tuples.

   2.  Remove all Link Tuples whose L_neighbor_iface_addr_list is now
       empty; apply Section 13.2, but not in conformance with
      [RFC5444] MUST be discarded.  A HELLO message may also be
      discarded for other reasons, see Section 12.1.

   o  This protocol specifies three Address Block TLVs.  It also uses
      two Message TLVs defined in [RFC5497].  These five TLV Types are 13.3.

   3.  Find all defined only with Type Extension = 0.  TLVs of other types,
      and of these types Link Tuples (henceforth matching Link Tuples) where:

       *  L_neighbor_iface_addr_list contains one or more addresses in
          the Sending Address List.

   4.  If there is more than one matching Link Tuple, then remove them
       all; apply Section 13.2, but without Type Extension = 0, are ignored by
      this protocol.  All references 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 the router finds any address (henceforth receiving
           address) in this specification to, for
      example, an the Receiving Address Block TLV with Type = LINK_STATUS, are to be
      considered as referring to List in an Address Block TLV with Type =
      LINK_STATUS and Type Extension = 0.

10.1.  HELLO Messages

   A HELLO message MUST contain:

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

   A HELLO message which message, then the Link Tuple is transmitted periodically SHOULD contain, and
   otherwise MAY contain:

   o  Exactly one INTERVAL_TIME Message TLV modified as specified
           follows:

           1.  If any receiving address in [RFC5497],
      representing HELLO_INTERVAL for the transmitting MANET interface.
      The options included in [RFC5497] for representing zero and
      infinite times MUST NOT be used.

   A HELLO message MAY contain:

   o  Other Message TLVs.

   o  One or more Address Blocks, each is
               associated with an associated Address Block TLV Block, which MAY contain other Address Block TLVs.

10.1.1.  Address Blocks

   All addresses in a router's Local Interface 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 interface on which the HELLO message is to be sent has a single
   address Type =
               LINK_STATUS and with maximum prefix length, then that address MAY be omitted
   from being included in Value = HEARD or Value = SYMMETRIC
               then:

               -  L_SYM_time := current time + validity time.

           2.  Otherwise if any Address Block, provided that this address
   is included as the sending receiving address of the IP datagram in which the HELLO message
               is included.  All addresses of the router's interfaces
   included in an Address Block MUST be associated with an Address Block TLV with Type = LOCAL_IF, as defined in Table 1.

   +----------+---------+----------------------------------------------+
   |   Name   |
               LINK_STATUS and Value  | Description                                  |
   |          |  Length |                                              |
   +----------+---------+----------------------------------------------+
   | LOCAL_IF | 1 octet | Specifies that = 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 address is an address     |
   |          |         | associated with 2-Hop Set

   On receiving a HELLO message a router MUST update its 2-Hop Set for
   the MANET interface on which |
   |          |         | the HELLO message was sent (THIS_IF) or another    |
   |          |         | interface of received:

   1.  Remove all addresses in the sending router (OTHER_IF).  |
   +----------+---------+----------------------------------------------+

                     Table 1: LOCAL_IF TLV definition
   Address Blocks MAY contain current or recently lost 1-hop neighbors'
   addresses, each of which is associated with one or both Removed Address Block
   TLVs as described in Table 2.

   +--------------+---------+------------------------------------------+
   |     Name     |  Value  | Description                              |
   |              |  Length |                                          |
   +--------------+---------+------------------------------------------+
   |  LINK_STATUS | 1 octet | Specifies List from the status
       N2_neighbor_iface_addr_list of all 2-Hop Tuples.

   2.  If the link from    |
   |              |         | the indicated address (LOST, Link Tuple whose L_neighbor_iface_addr_list = Sending
       Address List, has L_status = SYMMETRIC   |
   |              |         | or HEARD).                               |
   | OTHER_NEIGHB | 1 octet | Specifies that the then:

       1.  For each address is            |
   |              |         | (SYMMETRIC) or was (LOST) of (henceforth 2-hop address) in an          |
   |              |         | interface of a symmetric 1-hop neighbor  |
   |              |         | Address
           Block of the router transmitting the HELLO     |
   |              |         | message.                                 |
   +--------------+---------+------------------------------------------+

           Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition

   An message, where:

           +  2-hop address is not contained in the Neighbor Address
              List;

           +  2-hop address is not contained in 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
               with:

               -  Type = LINK_STATUS and Value = SYMMETRIC or
   Value = LOST also performs the function of an Address Block TLV with SYMMETRIC; OR

               -  Type = OTHER_NEIGHB and Value = SYMMETRIC,

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

               -  N2_neighbor_iface_addr_list contains one or more
                  addresses in the same value.  The latter SHOULD NOT also
   be included associated with the same Sending Address List; AND

               -  N2_2hop_addr = 2-hop address.  If

               then create a 2-Hop Neighbor Tuple with:

               -  N2_2hop_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
               with:

               -  Type = LINK_STATUS and Value = SYMMETRIC is combined with an
   Address Block TLV with LOST or Value = HEARD;
                  OR

               -  Type = OTHER_NEIGHB and Value = LOST
   associated with the same address, LOST;

               then the latter MUST be ignored,
   and SHOULD NOT be included.  See Appendix A.

   Other remove all 2-Hop Tuples with:

               -  N2_neighbor_iface_addr_list contains one or more
                  addresses MAY be included in the Sending Address Blocks, but List; AND

               -  N2_2hop_addr = 2-hop address.

13.  Other Information Base Changes

   The Interface and Neighbor Information Bases MUST NOT be
   associated with any changed when
   certain events occur.  These events may result from HELLO message
   processing, or may be otherwise generated (e.g., expiry of timers or
   link quality changes).

   Events which cause changes in the Address Block TLVs Information Bases are:

   o  A Link Tuple's L_status changes to SYMMETRIC.  In this case, the
      actions specified in Section 13.1 are performed.

   o  A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple
      is removed.  In this case, the actions specified in Section 13.2
      are performed.

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

11.  HELLO Message Generation

   Each MANET case, the actions specified in Section 13.3 are performed.

   o  Local interface MUST generate HELLO messages according to address changes.  In this case, the
   specification actions
      specified in Section 9 are performed.

   o  Link quality changes.  In this section.  HELLO messages case, the actions specified in
      Section 14 are generated for each
   MANET interface independently.  HELLO message generation performed.

   If a Link Tuple is removed, or if L_status changes from SYMMETRIC and
   scheduling
   L_HEARD_time expires, then the actions specified in Section 13.2 MUST
   be according to performed before the interface parameters for that
   MANET interface, and MAY be independent actions specified in Section 13.3 are
   performed for each MANET interface or,
   interface parameters permitting, MANET interfaces that Link Tuple.

   A router MAY use report updated information in response to any of these
   changes in HELLO message(s), subject to the same
   schedule.

   If transmitting periodic constraints in
   Section 11.

   A router which transmits HELLO messages then, following a HELLO
   message transmission on in response to such changes
   SHOULD transmit a MANET interface, another HELLO message MUST
   be transmitted on the same message:

   o  On all MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive HELLO message
   transmissions on interfaces, if the same MANET interface MUST be separated by at
   least HELLO_MIN_INTERVAL, except Neighbor Set changes such as noted to
      indicate the change in Section 11.2.1.

11.1.  HELLO Message Specification

   HELLO messages are generated independently symmetry of any 1-hop neighbors (including
      addition or removal of symmetric 1-hop neighbors).

   o  Otherwise, on each all those MANET interface.

   All addresses interfaces whose Link Set changes
      such as to indicate a change in L_status of any I_local_iface_addr_list MUST be included, except
   that:

   o  If 1-hop neighbors
      (including the interface on addition or removal of any 1-hop neighbors, other
      than those considered pending).

13.1.  Link Tuple Symmetric

   If, for any Link Tuple which the HELLO message is does not have L_status = SYMMETRIC:

   o  L_status changes to be sent has SYMMETRIC;

   (this includes a
      single address with maximum prefix length then that address MAY be
      omitted, provided that this address is included as the sending
      address of the IP datagram in newly created Link Tuple which is immediately
   updated such that L_status = SYMMETRIC) then:

   1.  For the HELLO message Neighbor Tuple whose N_neighbor_addr_list contains
       L_neighbor_iface_addr_list, set:

       *  N_symmetric := true.

   2.  Remove all Lost Neighbor Tuples whose NL_neighbor_addr is included.

   All such included addresses MUST be associated with an Address Block
   TLV
       contained in that N_neighbor_addr_list.

13.2.  Link Tuple Not Symmetric

   If for any Link Tuple with Type := LOCAL_IF and Value according L_status = SYMMETRIC:

   o  L_status changes to the following: any other value; OR

   o  If  the address Link Tuple is an address of removed;

   then:

   1.  All 2-Hop Tuples for the sending same MANET interface, then
      Value := THIS_IF.

   o  Otherwise, Value := OTHER_IF.

   The following addresses of current interface with:

       *  N2_neighbor_iface_addr_list contains one or former 1-hop neighbors MAY be
   included more addresses in any HELLO message, respecting the parameter
   REFRESH_INTERVAL for each association for that MANET interface:

   o  Addresses of MANET interfaces of 1-hop neighbors from
          L_neighbor_iface_addr_list;

       are removed.

   2.  For the Neighbor Tuple whose N_neighbor_addr_list contains
       L_neighbor_iface_addr_list:

       1.  If there are no remaining Link Set
      of the Interface Information Base Tuples for this any MANET interface (i.e.
      from an L_neighbor_iface_addr_list), other than those from Link
      Tuples with
           where:

           +  L_neighbor_iface_addr_list is contained in
              N_neighbor_addr_list; AND

           +  L_status = PENDING.

   o  Other addresses of symmetric 1-hop neighbors from SYMMETRIC;

           then modify the Neighbor Set
      of this router's Tuple by:

           1.  N_symmetric := false.

           2.  For each address (henceforth neighbor address) in
               N_neighbor_addr_list, add a Lost Neighbor Information Base (i.e. from an
      N_neighbor_iface_addr_list). Tuple with:

               -  NL_neighbor_addr := neighbor address;

               -  NL_time := current time + N_HOLD_TIME.

13.3.  Link Tuple Heard Timeout

   If, for any Link Tuple:

   o  Addresses of MANET interfaces of previously symmetric or heard
      1-hop neighbors connected on this MANET interface from  L_HEARD_time expires; OR

   o  the Link Tuple is removed;

   then:

   1.  For the Neighbor Tuple whose N_neighbor_addr_list contains
       L_neighbor_iface_addr_list, if no Link
      Set of the Interface Information Base Tuples for this any MANET
       interface
      (i.e. from an remain where:

       *  L_neighbor_iface_addr_list with L_status = LOST).

   o  Other addresses of previously symmetric 1-hop neighbors from is contained in
          N_neighbor_addr_list; AND

       *  L_HEARD_time is not expired;

       then remove the
      Lost Neighbor Set of this router's Neighbor Information Base (i.e. 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 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 an NL_neighbor_iface_addr).

   Each such address MUST be associated with one the link layer) and used only locally, i.e. is not
   included in signaling, and routers may interoperate whether they are
   using the same, different, or more appropriate
   Address Block TLVs.  Specifically:

   1. no, link quality information.

   For each address (henceforth linked address) which deployments where no link quality is contained used, the considerations in an L_neighbor_iface_addr_list
   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 Set
       for this MANET interface, for which L_status != PENDING, include Tuple.  Based on
   these flags, the linked address with an associated Address Block TLV with:

       *  Type := LINK_STATUS; AND

       *  Value := L_status.

   2.  For each address (henceforth neighbor address) which link status to advertise for that Link Tuple is contained
       in an N_neighbor_iface_addr_list
   determined as described in Section 7.1.

   The use of two thresholds implements link hysteresis, whereby a Neighbor Tuple with
       N_symmetric = true, and link
   which has not already been included with
       an associated Address Block TLV with Type = LINK_STATUS and Value
       = SYMMETRIC, include the neighbor address with an associated
       Address Block TLV with:

       *  Type := OTHER_NEIGHB; AND

       *  Value := SYMMETRIC.

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

       *  Type := OTHER_NEIGHB; AND

       *  Value := LOST.

   If any such addresses have been added to these Information Bases
   since the last HELLO message was sent on this MANET interface, HYST_REJECT <= L_quality < HYST_ACCEPT may be either
   accepted or rejected (depending on which threshold it has most
   recently crossed, or, if
   their status (as indicated by these TLVs and the values they
   associate with that address) have changed since that address was last
   reported neither, on this MANET interface, then that address, and the
   indicated TLVs, MUST be included in the HELLO message.

   If an address value of parameter
   INITIAL_PENDING).  With appropriate values of a 1-hop neighbor is 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 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 HELLO message sent on that MANET neighbor interface in every interval of
   length equal to that MANET interface's parameter REFRESH_INTERVAL.
   Address Block TLVs associated with any state
      until L_quality is acceptable:

      *  If INITIAL_PENDING = true, then the same address included in link is advertised when
         link L_quality >= HYST_ACCEPT.

      *  Otherwise the
   same HELLO message MAY be applied to link is advertised when L_quality >= HYST_REJECT.

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

   o  Once L_quality >= HYST_ACCEPT, the same or different copies of router sets L_pending := false,
      indicating that address.

11.2.  HELLO Message Transmission

   HELLO messages are transmitted in the format specified by [RFC5444].

11.2.1.  HELLO Message Jitter

   HELLO messages MAY link can be sent using periodic message generation or
   externally triggered message generation. advertised.

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

   o  If using data a link has L_pending = false and
   physical layers which are subject to packet loss due to collisions,
   HELLO messages SHOULD be jittered L_quality < HYST_REJECT, the
      link is LOST and is advertised as described in [RFC5148].

   Internally triggered message generation (such such.  This link is not
      reconsidered as due to a change in
   local interfaces) MAY candidate HEARD or SYMMETRIC link until
      L_quality >= HYST_ACCEPT.

   o  A link which has an acceptable quality may be treated advertised as if externally generated message
   generation, HEARD,
      SYMMETRIC or MAY be not jittered.

   HELLO messages MUST NOT be forwarded, and thus message forwarding
   jitter does not apply LOST according to the exchange of HELLO messages.

   Each form of jitter described in [RFC5148] requires

   In order that these principles can all hold, a parameter
   MAXJITTER.  These interface parameters may be dynamic, and are
   specified by: router MUST NOT
   define:

   o  For periodic message generation: HP_MAXJITTER.  INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR

   o  For externally triggered message generation: HT_MAXJITTER.  INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.

14.3.  When HELLO message generation is delayed in order that Link Quality Changes

   If L_quality for a HELLO
   message is not sent within HELLO_MIN_INTERVAL of link changes, then the previous HELLO
   message on following actions MUST be
   taken:

   1.  If L_quality >= HYST_ACCEPT then the same MANET interface, 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 HELLO_MIN_INTERVAL SHOULD
   be reduced by jitter, with maximum reduction HP_MAXJITTER, as
   described 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 [RFC5148].  In this case HP_MAXJITTER Section 13 MUST NOT also be
   greater than HELLO_MIN_INTERVAL.

12. taken.

   If L_quality for a link is updated based on HELLO Message Processing

   On receiving message reception,
   or on reception of a packet including a HELLO message, a router then L_quality
   MUST first check if be updated prior to the HELLO message is invalid for processing by this router, as defined in
   Section 12.1.  Otherwise the receiving router MUST update its
   appropriate Interface Information Base and its Neighbor Information
   Base as specified described in
   Section 12.3 to Section 12.6.  These updates
   MUST be performed in 12.  (If the order in which they are presented in this
   specification.  If any changes satisfy any receipt of the conditions
   described in Section 13 HELLO message, or the packet
   containing it, creates the Link Tuple, then the indicated consequences in that
   section Link Tuple MUST be applied immediately, unless noted otherwise.

   All message processing, including determination of whether a message
   is invalid, considers only TLVs with Type Extension = 0.  TLVs with
   any other type extension are ignored.  All references to, for
   example, a TLV
   created with Type = LINK_STATUS refer to a TLV the appropriately updated L_quality value, rather than
   with Type =
   LINK_STATUS and Type Extension = 0.

12.1.  Invalid Message L_quality := INITIAL_QUALITY.)

14.4.  Updating Link Quality

   A received HELLO message is invalid for processing by this router if MAY update link quality based on any of the following conditions are true:

   o  The address length as specified in the the Message Header is not
      equal information available
   to the length of the addresses used by this router.

   o  The message has a <msg-hop-limit> field in its Message Header with
      a value other than one.  (Note it.  Particular cases that MAY be used include:

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

   o  The message has  Receipt or loss of control packets.  If control packets include a <msg-hop-count> field
      sequential packet sequence number, as defined in its Message Header with [RFC5444], then
      link quality can be updated when a value other than zero.  (Note that the message need control packet is received,
      whether or not have it contains a
      <msg-hop-count> field.)

   o HELLO message.  The message does not have 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 Message TLV with Type = VALIDITY_TIME
      in its Message TLV Block. "leaky integrator"
      tracking packet reception and loss.

   o  The message has more than one Message TLV with Type =
      VALIDITY_TIME  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion in its Message TLV Block.

   o  The message has more than one HELLO
      messages of a Message TLV with Type =
      INTERVAL_TIME := INTERVAL_TIME, as defined
      in its Message TLV Block.

   o  The message has any Address Block TLV(s) with Type = LOCAL_IF and
      any single value v such that v != THIS_IF and v != OTHER_IF.

   o  Any address (including different copies [RFC5497]) then the loss of an address, 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 same
      or different Address Blocks) is associated with more than one
      value by one or more Address Block TLV(s) with Type = LOCAL_IF.

   o  Any address (henceforth parameters and constants used in the local address) associated with an
      Address Block TLV with Type = LOCAL_IF is one
   specification of the receiving
      router's current or recently protocol, and proposed values of each which may
   be used addresses (i.e. the local
      address when a single value of each is contained in any I_local_iface_addr_list in the Local used.

15.1.  Message Interval Interface Set or the local address = any IR_local_iface_addr in
      the Removed Parameters

   o  HELLO_INTERVAL := 2 seconds

   o  HELLO_MIN_INTERVAL := HELLO_INTERVAL/4

   o  REFRESH_INTERVAL := HELLO_INTERVAL

15.2.  Information Validity Time Interface Address Set). Parameters

   o  The message has any Address Block TLV(s) with Type = LINK_STATUS
      with any single value v such that v != LOST, v != SYMMETRIC, and v
      != HEARD.  H_HOLD_TIME := 3 x REFRESH_INTERVAL

   o  Any address (including different copies of an address, in  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 same
      or different Address Blocks)
   link quality process.  If link quality is associated with more than one
      value by one or more Address Block TLVs with Type = LINK_STATUS. 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  The message has any Address Block TLV(s)  HP_MAXJITTER := HELLO_INTERVAL/4

   o  HT_MAXJITTER := HP_MAXJITTER

15.6.  Constants

   o  C := 1/1024 second

16.  Usage with Type = OTHER_NEIGHB Other Protocols

   Other protocols, such as MANET routing protocols, which use
   neighborhood discovery may need to interact with any single value v this protocol.  This
   protocol is designed to permit such that v != LOST and v != SYMMETRIC. interactions, in particular:

   o  Any address (including different copies of an address,  Through accessing, and possibly extending, the information in the same
      or different Address Blocks) is associated with more than one
      value by one or more Address Block TLVs with Type = OTHER_NEIGHB.

   An invalid message MUST be silently discarded, without updating
      Local Information Base (Section 6), the
   router's Interface Information Bases.  A router MAY recognize additional
   reasons for identifying that a message is badly formed, Base
      (Section 7) and discard
   such messages.

12.2.  Definitions

   For the purpose Neighbor Information Base (Section 8).  These
      Information Bases record the interface configuration of this section, note the following definitions:

   o  "validity time" is calculated from
      router, as well as the Message TLV with Type =
      VALIDITY_TIME of 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 [RFC5497].
      (Note that, [RFC5444].  This may, for example, be
      to allow a security protocol, as specified by suggested in Section 12.1, there must be exactly
      one such Message 17, to add a
      TLV in containing a cryptographic signature to the HELLO message.)  All message, or be to
      allow inserting relay selection information in
      the into a HELLO message used
      by this specification has the same validity
      time.

   o  "Receiving Address List" is the I_local_iface_addr_list
      corresponding way of adding a TLV to the MANET interface on which the an outgoing HELLO message
      was received prior to it
      being transmitted.

   o  "Sending Address List" is the list of the addresses contained in
      the HELLO message with  Through accessing an associated Address Block TLV with Type =
      LOCAL_IF incoming HELLO message, and Value = THIS_IF.  If the Sending Address List is
      otherwise empty, then the Sending Address List contains potentially
      discarding it prior to processing by this protocol.  This may, for
      example, allow a single
      address (with maximum prefix length) equal security protocol as suggested in Section 17 to the sending address
      perform verification of the IP datagram in which the HELLO message was included.

   o  "Neighbor Address List" is the Sending Address List, plus the
      addresses contained in the HELLO message with an associated
      Address Block TLV with Type = LOCAL_IF signatures and Value = OTHER_IF.

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

   o  "Removed Address List" is a list prevent
      processing of addresses created unverifiable HELLO messages by this protocol.

   o  Through accessing an incoming HELLO message processing which were formerly reported as local after it has been
      completely processed by
      the router originating the HELLO message, but which are not
      included in the Neighbor Address List. this protocol.  This list is initialized
      as empty.

   o  "Lost Address List" is may, in particular,
      allow a subset of the Removed Address List
      containing addresses protocol which were formerly considered as symmetric.
      This list is initialized has added information, such as empty.

12.3.  Updating relay
      selection information by way of inclusion of appropriate TLVs,
      access to such information after appropriate updates have been
      recorded in the Neighbor Set

   On receiving Information Bases in this protocol.

   o  Through requesting that a HELLO message, the router MUST update its Neighbor Set
   and populate the Removed Address List and Lost Address List:

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

       *  N_neighbor_iface_addr_list contains message be generated at least one address in
          the 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 matching Neighbor Tuple, then:

       1.  If specific
      time.  In that case, HELLO message generation MUST still respect
      the matching Neighbor Tuple's N_neighbor_iface_addr_list
           != Neighbor Address List, then:

           1.  For each address (henceforth removed address) which is
               contained constraints in that N_neighbor_iface_addr_list, but Appendix B.

17.  Security Considerations

   The objective of this protocol is not
               contained in the Neighbor Address List:

               1.  Add the removed address to allow each router in the Removed Address List.

               2.  If N_symmetric = true, then add the removed address network
   to the 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 acquire information describing its 1-hop neighborhood and
   symmetric 2-hop neighborhood.  This is acquired through HELLO message
   exchange between neighboring routers.  This information is
           contained in the N_neighbor_iface_addr_list of any of made
   available through the
           matching Interface Information Bases and Neighbor Tuples:

           1.  Add the removed address to
   Information Base, describing the Removed Address List.

           2.  If N_symmetric = true, then add router's 1-hop neighborhood and
   symmetric 2-hop neighborhood.

   Under normal circumstances, the removed address information recorded in these
   Information Bases is correct, i.e. corresponds to the Lost Address List.

       2.  Replace the matching Neighbor Tuples actual network
   topology, apart from any changes which have not (yet) been tracked 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, message exchanges.

   If a router MUST update its Lost Neighbor
   Set:

   1.  For each address (henceforth lost address) for some reason, whether malice or malfunction, transmits
   invalid HELLO messages, incorrect information may be recorded in
   other routers' Information Bases.  This protocol specification does,
   however, prevent inconsistent information from being included in the
   Information Bases through the specified processing, which is contained maintains
   the constraints in Appendix B.  The exact consequence of information
   inexactness depends on the Lost Address List, if no Lost Neighbor Tuple with
       NL_neighbor_iface_addr = lost address exists, then add a Lost
       Neighbor Tuple with:

       *  NL_neighbor_iface_addr := lost address;

       *  NL_time := current time + N_HOLD_TIME.

12.5.  Updating use of these Information Bases, and should
   be reflected in the Link Set

   On receiving a HELLO message, a router MUST update its Link Set for specification of protocols which use information
   provided by this neighborhood discovery protocol.

   This section, therefore, firstly outlines the MANET interface on ways in which the correctly
   formed, but still invalid, HELLO message is received:

   1.  Remove all addresses messages may appear, in the Removed Address List from the
       L_neighbor_iface_addr_list
   Section 17.1.

   Injection of all Link Tuples.

   2.  Remove all Link Tuples whose L_neighbor_iface_addr_list invalid HELLO messages into a network may be prevented
   by different means.  If, for example, a network is now
       empty; apply Section 13.2, but not Section 13.3.

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

       *  L_neighbor_iface_addr_list contains one or more addresses deployed in a site
   to which access is strictly regulated, in order that physical access
   and proximity to the Sending Address List.

   4.  If there network is more than one matching Link Tuple, prevented, then remove them
       all; apply Section 13.2, but further security
   mechanisms to protect against malicious routers injecting invalid
   HELLO messages may 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 be required.  Similarly, if the router finds any address (henceforth receiving
           address) in link layer
   over which the Receiving Address List in network is formed provides appropriate
   confidentiality, authentication, and integrity, then this may, for a
   given deployment, suffice to appropriately protect against disclosure
   of information to an Address Block in
           the eavesdropper, and against a malicious router
   injecting invalid HELLO message, then messages.  In the Link Tuple is modified as
           follows:

           1.  If any receiving address in latter case the HELLO message link layer
   would discard frames that fail the link layer checks, without
   attempting to deliver such frames to IP.  Finally, certain usage may
   be of a nature where disruption of service is
               associated with an Address Block TLV with Type =
               LINK_STATUS and with Value = HEARD of no consequence, or Value = SYMMETRIC
               then:

               -  L_SYM_time := current time + validity time.

           2.  Otherwise if any receiving address in
   at least not of sufficient consequence to warrant deployment of
   additional security mechanisms.

   A further point to stress, and which follows from the HELLO discussions
   above is, that it will not be the case that "one size security fits
   all".  Different deployments may have different requirements.  For
   example in a deployment of a low value sensor network, authentication
   using a simple message
               is associated with an Address Block TLV with Type =
               LINK_STATUS authentication code and Value = LOST then:

               1.  if L_SYM_time has shared symmetric keys
   may suffice, while anything beyond that may require too many
   computational resources to be viable.  Conversely, in, for example, a
   community network, verifying 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 only that the 2-Hop Set

   On receiving originator of a HELLO
   message "has the right key" but also the precise identity of the
   originator may be required to be proved, and computational resources
   may be available to make such a router MUST update its 2-Hop Set requirement feasible.

   Section 17.2, therefore, does not specify a single "one-size-fits-
   all" mechanism, but rather details how the security suggestions in
   [RFC5444] are considered for applicability within the MANET interface on which context of this
   protocol, and with the purpose of aiding deployment-specific security
   mechanisms to be developed.

17.1.  Invalid HELLO messages

   A correctly formed, but still invalid, HELLO message was received:

   1.  Remove all addresses in the Removed Address List from the
       N2_neighbor_iface_addr_list may take any 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 following forms.  Note that a present or absent address (henceforth 2-hop address) in an
   Address
           Block of the HELLO message, where:

           +  2-hop address is Block, does not contained in and by itself cause a problem.  It is the Neighbor
   presence, absence, or incorrectness of associated LOCAL_IF,
   LINK_STATUS and OTHER_NEIGHB Address
              List;

           +  2-hop address is not contained in any
              I_local_iface_addr_list; AND

           +  2-hop address != any IR_local_iface_addr

           4.  If 2-hop address has 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
               with:

               -  Type = LINK_STATUS and Value = SYMMETRIC; OR

               -  Type = OTHER_NEIGHB and Value = SYMMETRIC,

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

               -  N2_neighbor_iface_addr_list contains one or more which do not correspond to addresses in
         of interfaces of 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 router transmitting the HELLO message.

      *  The HELLO message may omit addresses, or new) 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 then modified as
               follows:

               -  N2_neighbor_iface_addr_list := Sending Address List;

               -  N2_time := current time + validity time.

           5.  Otherwise transmitted, if that is the 2-hop address has an case).

      *  The HELLO message may incorrectly specify the LOCAL_IF Address
         Block 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 associated with one or more
                  addresses in local interface
         addresses, indicating incorrectly whether they are associated
         with the MANET interface over which the Sending Address List; AND

               -  N2_2hop_iface_addr = 2-hop address.

13.  Other Information Base Changes

   The Interface and Neighbor Information Bases MUST be changed when
   certain events occur.  These events may result from HELLO message
   processing, or is
         transmitted.

   A router may be otherwise generated (e.g., expiry provide false information about the identity of timers other
   routers:

      *  A present LINK_STATUS Address Block TLV may, incorrectly,
         identify an address as being of a MANET interface which is or
   link quality changes).

   Events
         was heard on the MANET interface over which cause changes in the Information Bases are:

   o HELLO message
         is transmitted.

      *  A Link Tuple's L_status changes consistently absent LINK_STATUS Address Block TLV may,
         incorrectly, fail to SYMMETRIC.  In this case, the
      actions specified in Section 13.1 are performed.

   o  A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple identify an address as being of a MANET
         interface which is removed.  In this case, the actions specified in Section 13.2
      are performed.

   o  A Link Tuple's L_HEARD_time expires, or was heard on the Link Tuple is removed.
      In this case, the actions specified in Section 13.3 are performed.

   o  Local MANET interface address changes.  In this case, over
         which the actions
      specified 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 Section 9 are performed.

   o  Link quality changes.  In this case, the actions specified in
      Section 14 are performed.

   If
         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 Link Tuple router
         which is removed, or if L_status changes from 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 and
   L_HEARD_time expires, then or HEARD) of the actions specified in Section 13.2 MUST
   be performed before link from
         a 1-hop neighbor.

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

17.2.  Authentication, Integrity and Confidentiality Suggestions

   The security suggestions in section Section 13.3 are
   performed for that Link Tuple.

   A router MAY report updated information [RFC5444] regarding inclusion of a
   cryptographic signature in response a Message TLV or a Packet TLV can be
   applied to any this protocol.  Failure to verify either form of these
   changes in
   cryptographic signature should cause a HELLO message(s), subject message to be rejected
   without being processed.

   The following simplification of the constraints in
   Section 11.

   A router which transmits HELLO messages suggestions for end-to-end
   authentication for integrity in response [RFC5444] may be applied to such changes
   SHOULD transmit a HELLO message:
   messages:

   o  On all MANET interfaces, if  As the Neighbor Set changes such as Message Header fields <msg-hop-count> and <msg-hop-limit>
      are either omitted or will always have the values 0 and 1,
      respectively, an end to
      indicate end cryptographic signature can be
      calculated based on the change entire HELLO message, including its
      unmodified Message Header.

   The security mechanisms suggested in symmetry of any 1-hop neighbors (including
      addition or removal of symmetric 1-hop neighbors).

   o  Otherwise, on all those MANET interfaces whose Link Set changes
      such as [RFC5444] with respect to indicate a change in L_status of any 1-hop neighbors
      (including
   confidentiality can be directly applied to this protocol.

18.  IANA Considerations

   This specification defines one Message Type, which must be allocated
   from the addition or removal "Message Types" repository of 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 changes to SYMMETRIC;

   (this includes a newly created Link Tuple [RFC5444], and three Address
   Block TLV Types, which is immediately
   updated such that L_status = SYMMETRIC) then:

   1.  For must be allocated from the Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list, set:

       *  N_symmetric := true.

   2.  Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is
       contained in that N_neighbor_iface_addr_list.

13.2.  Link Tuple Not Symmetric

   If for any Link Tuple with L_status = SYMMETRIC:

   o  L_status changes to any other value; OR

   o "Address Block TLV
   Types" repository of [RFC5444].

18.1.  Expert Review: Evaluation Guidelines

   For the Link Tuple is removed;

   then:

   1.  All 2-Hop Tuples for registries where an Expert Review is required, the designated
   expert SHOULD take the same MANET interface with:

       *  N2_neighbor_iface_addr_list contains one or more addresses in
          L_neighbor_iface_addr_list; general recommendations into
   consideration as are removed.

   2.  For specified by [RFC5444].

18.2.  Message Types

   This specification defines one Message Type, to be allocated from 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
   0-223 range of the Neighbor Tuple by:

           1.  N_symmetric := false.

           2.  For each address (henceforth neighbor address) "Message Types" namespace defined in
               N_neighbor_iface_addr_list, add [RFC5444], as
   specified in Table 3.

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

                     Table 3: Message Type assignment

18.3.  Message-Type-specific TLV Type Registries

   IANA is requested to create 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, registry 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 Message-Type-specific
   Message TLVs for any MANET
       interface remain where:

       *  L_neighbor_iface_addr_list is contained HELLO messages, in
          N_neighbor_iface_addr_list; AND
       *  L_HEARD_time is not expired;

       then remove the Neighbor Tuple.

14.  Link Quality

   Link quality accordance with Section 6.2.1 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 mechanism whereby a router MAY take considerations
   other than message exchange into account registry for determining when a link
   is and is not a candidate Message-Type-specific
   Address Block TLVs for being considered HELLO messages, in accordance with Section
   6.2.1 of [RFC5444], and with initial assignments and allocation
   policies 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 specified in Table 5.

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

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

18.4.  Address Block TLV Types

   This specification defines three Address Block TLV Types, which must
   be allocated from the link layer) and used only locally, i.e. is not
   included "Address Block TLV Types" namespace defined in signaling, and routers may interoperate whether they
   [RFC5444].  IANA are
   using the same, different, or no, link quality information.

   For deployments where no link quality is used, the considerations requested to make allocations 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 0-127 range
   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 these types.  This will create three new type extension
   registries with assignments as specified in Table 6, Table 7 and
   Table 8.  Specifications of Link Quality

   To enable link quality usage, these Address Block TLVs are in
   Section 10.1.1, with Value Constants defined in Section 18.5.

   +------------+------+-----------+-----------------------------------+
   |    Name    | Type |    Type   | Description                       |
   |            |      | extension |                                   |
   +------------+------+-----------+-----------------------------------+
   |  LOCAL_IF  | TBD2 |     0     | Specifies that the L_quality value of a Link Tuple address is
   used in conjunction     |
   |            |      |           | associated with two thresholds, HYST_ACCEPT and HYST_REJECT,
   to set a local interface |
   |            |      |           | of the flags L_pending and L_lost sending router             |
   | Unassigned | TBD2 |   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 that Link Tuple.  Based on
   these flags, the link status to advertise for |
   |             |      |           | from the indicated address       |
   |             |      |           | (LOST, SYMMETRIC or HEARD)       |
   |  Unassigned | TBD3 |   1-255   | Expert Review                    |
   +-------------+------+-----------+----------------------------------+

          Table 7: Address Block TLV Type assignment: LINK_STATUS
   +--------------+------+-----------+---------------------------------+
   |     Name     | Type |    Type   | Description                     |
   |              |      | extension |                                 |
   +--------------+------+-----------+---------------------------------+
   | OTHER_NEIGHB | TBD4 |     0     | Specifies that Link Tuple the address 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   |
   |              |      |           | (SYMMETRIC) 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 was     |
   |              |      |           | (LOST) of link status.

   The basic principles an interface of link quality usage are as follows:

   o  A router does not advertise a     |
   |              |      |           | symmetric 1-hop neighbor interface in any state
      until L_quality is acceptable:

      *  If INITIAL_PENDING = true, then of the link is advertised when
         link L_quality >= HYST_ACCEPT.

      *  Otherwise |
   |              |      |           | router transmitting the link is advertised when L_quality >= HYST_REJECT.

      A link message |
   |  Unassigned  | TBD4 |   1-255   | Expert Review                   |
   +--------------+------+-----------+---------------------------------+

         Table 8: Address Block TLV Type assignment: OTHER_NEIGHB

18.5.  LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values

   The Values 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 LOCAL_IF Address Block TLV can be advertised. use are the
   following:

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

   o  If a link has L_pending = false and L_quality < HYST_REJECT,  OTHER_IF := 1

   The Values which the
      link is LINK_STATUS Address Block TLV can use are the
   following:

   o  LOST and is advertised as such.  This link is not
      reconsidered as a candidate HEARD or := 0

   o  SYMMETRIC link until
      L_quality >= HYST_ACCEPT. := 1

   o  A link  HEARD := 2

   The Values which has an acceptable quality may be advertised as HEARD,
      SYMMETRIC or the OTHER_NEIGHB Address Block TLV can use are the
   following:

   o  LOST according to := 0

   o  SYMMETRIC := 1

19.  Contributors

   This specification is the exchange result of HELLO messages.

   In order that these principles can all hold, a router MUST NOT
   define: the joint efforts of the
   following contributors, listed alphabetically.

   o  INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR  Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>

   o  INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.

14.3.  When Link Quality Changes

   If L_quality  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>

20.  Acknowledgements

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

   The authors would like to gratefully acknowledge the following actions MUST be
   taken:

   1.  If L_quality >= HYST_ACCEPT then people
   for intense technical discussions, early reviews and comments on 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,
   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.

21.  References

21.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 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 C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing multi-value
              time + L_HOLD_TIME).

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

   If L_quality MANETs", RFC 5497, March 2009.

   [RFC5498]  Chakeres, I., "IANA Allocations 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 MANET Protocols",
              RFC 5498, March 2009.

21.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 message processing described messages 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 11 specifies
   which 1-hop addresses may be used include:

   o  Information from included in the link layer, such as signal to noise ratio or
      packet acknowledgement reception Address Blocks, and loss information.

   o  Receipt with
   which associated Address Block TLVs.  These Address Block TLVs may
   have Type = LINK_STATUS 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 Type = OTHER_NEIGHB, or not it contains a HELLO message.  The link quality both.  Address
   Block TLVs with Type = LINK_STATUS may
      then, for example, be based on whether the last N out of M control
      packets on the link were received, have three possible Values
   (Value = HEARD, Value = SYMMETRIC or may use a "leaky integrator"
      tracking packet reception Value = LOST), and loss.

   o  Receipt Address Block
   TLVs of TYPE = OTHER_NEIGHB may have two possible Values (Value =
   SYMMETRIC or loss Value = LOST).  When both Address Block TLVs are
   associated with the same address only certain combinations of HELLO messages.  If these
   Address Block TLV Values are necessary, and are the maximum interval
      between HELLO messages is known (such as only combinations
   generated by inclusion the algorithm in HELLO
      messages of a Message TLV with Type := INTERVAL_TIME, as defined Section 11.  These combinations are
   indicated in [RFC5497]) then Table 9.

   Cells labeled with "Yes" indicate the loss of HELLO messages can be determined
      without possible combinations which are
   generated by the need to receive a later HELLO message.  Note that if
      this case is combined algorithm in Section 11.  Cells labeled with "No"
   indicate combinations not generated by the previous case then care must be
      taken to avoid "double counting" a lost HELLO message algorithm in a lost
      packet.

15.  Proposed Values for Parameters Section 11,
   but which are correctly parsed and Constants

   This section lists interpreted by the parameters and constants used algorithm in
   Section 12.  The cell labeled with "No*" is actually inconsistent, it
   is handled by ignoring the
   specification of the protocol, Address Block TLV with Type =
   OTHER_NEIGHB.

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

          Table 9: LINK_STATUS and proposed values of each OTHER_NEIGHB TLV combinations

Appendix B.  Constraints

   Any process 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. updates the Local Information Validity Time Base or the Neighbor
   Information Base MUST ensure that all constraints specified in this
   appendix are maintained.

   In each Local Interface Parameters

   o  H_HOLD_TIME := 3 x REFRESH_INTERVAL Tuple:

   o  L_HOLD_TIME := H_HOLD_TIME

15.3.  Information Validity Time Router Parameters  I_local_iface_addr_list MUST NOT be empty.

   o  N_HOLD_TIME := L_HOLD_TIME  I_local_iface_addr_list MUST NOT contain any duplicated addresses.

   o  I_HOLD_TIME := N_HOLD_TIME

15.4.  Link Quality Interface Parameters

   If link quality  I_local_iface_addr_list MUST NOT contain any address which is changed, then parameter values will depend on in
      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 I_local_iface_addr_list of any other Local Interface Parameters

   o  HP_MAXJITTER := HELLO_INTERVAL/4

   o  HT_MAXJITTER := HP_MAXJITTER

15.6.  Constants Tuple.

   In each Removed Interface Address Tuple:

   o  C := 1/1024 second

16.  Usage with Other Protocols

   Other protocols, such as MANET routing protocols,  IR_local_iface_addr MUST NOT contain any address which use
   neighborhood discovery may need to interact with this protocol.  This
   protocol is designed to permit such interactions, in particular:

   o  Through accessing, and possibly extending, the information in the
      I_local_iface_addr_list of any Local Information Base (Section 6), the Interface Information Base
      (Section 7) and the Neighbor Information Base (Section 8).  These
      Information Bases record Tuple.

   o  IR_local_iface_addr MUST NOT equal the interface configuration 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
      router, as well as the local connectivity, up to two hops away.
      All updates to the elements specified 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 this document are subject
      to the constraints specified L_neighbor_iface_addr_list of any other Link Tuple in Appendix B. the
      same Link Set.

   o  Through accessing an outgoing HELLO message prior  If L_HEARD_time has not expired then there MUST be a Neighbor
      Tuple whose N_neighbor_addr_list contains
      L_neighbor_iface_addr_list.

   o  L_HEARD_time MUST NOT be greater than L_time.

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

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

   o  If L_quality >= HYST_ACCEPT then L_pending MUST be false.

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

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

   In each Neighbor Tuple:

   o  N_neighbor_addr_list MUST NOT contain 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 address which is in Section 17, to add a
      TLV containing a cryptographic signature to the message,
      I_local_iface_addr_list of any Local Interface Tuple or be to
      allow inserting relay selection information into a HELLO message
      by way the
      IR_local_iface_addr of adding a TLV to an outgoing HELLO message prior to it
      being transmitted. any Removed Interface Address Tuple.

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

   o  N_neighbor_addr_list MUST NOT contain any address which is in Section 17 to
      perform verification of HELLO message signatures and prevent
      processing the
      N_neighbor_addr_list of unverifiable HELLO messages by this protocol. any other Neighbor Tuple.

   o  Through accessing an incoming HELLO message after it has been
      completely processed by this protocol.  This may,  If N_symmetric is = true, then there MUST be one or more Link
      Tuples with:

      *  L_neighbor_iface_addr_list contained in particular,
      allow a protocol which has added information, N_neighbor_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_addr_list.

      All such as relay
      selection information by way of inclusion of appropriate TLVs,
      access to Link Tuples MUST NOT have L_status = SYMMETRIC.  At least
      one such information after appropriate updates Link Tuple MUST have been
      recorded L_HEARD_time not expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_addr MUST NOT be in the Information Bases 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_addr MUST NOT equal the NL_neighbor_addr of any other
      Lost Neighbor Tuple.

   o  NL_neighbor_addr MUST NOT be in this protocol. the N_neighbor_addr_list of any
      Neighbor Tuple with N_symmetric = true.

   In each 2-Hop Tuple:

   o  Through requesting that a HELLO message  There MUST be generated at a specific
      time.  In that case, HELLO message generation 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_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_addr MUST still respect NOT be the constraints in Appendix B.

17.  Security Considerations

   The objective N2_2hop_addr of this protocol is to allow each router any other 2-Hop Tuple
      in the network
   to acquire information describing its 1-hop neighborhood same 2-Hop Set and
   symmetric 2-hop neighborhood.  This with the same
      N2_neighbor_iface_addr_list.

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

Appendix C.  HELLO Message Example

   An example HELLO message, transmitted by an originating router with a
   single MANET interface, is acquired through message
   exchange between neighboring routers. as follows.

   The information is made
   available through the Interface Information Bases message has Message Header containing hop-limit, hop-count and Neighbor
   Information Base, describing the router's 1-hop neighborhood
   message sequence number (four bit Flags field value is 14).  Its four
   bit Message Address Length field has value 3 and
   symmetric 2-hop neighborhood.

   Under normal circumstances, the information recorded hence addresses in these
   Information Bases is correct, i.e. corresponds to
   the actual network
   topology, apart from any changes which message have not (yet) been tracked by
   the HELLO length four octets, here being IPv4 addresses.  The
   message exchanges.

   If is as transmitted with a router for some reason, whether malice or malfunction, transmits
   invalid HELLO messages, incorrect information may be recorded in
   other routers' Information Bases. hop limit of 1 and a hop count of 0.
   The protocol specification does,
   however, prevent inconsistent information from being included in the
   protocol sets through the defined processing overall message length is 45 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 maintains the
   constraints in Appendix B.  The exact consequence each has a Value.  Each has a Value Length of information
   inexactness depends on 1
   octet; the use of these Information Bases, Values included (0x64 and should
   be reflected in 0x58) are time codes
   representing the specification default values 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 17.1.  In addition, in Section 17.2, parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the security suggestions
   in [RFC5444] are considered for applicability.

17.1.  Invalid HELLO messages

   A correctly formed, but still invalid, HELLO
   default value of constant C (1/1024 second).

   The message may take any 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
   the 3 octets indicates
   address Mid sections of one octet each (Mid 0 to Mid 4).

   The following forms.  Note that Address Block TLV Block (content length 14 octets)
   includes two Address Block TLVs.  The first is a present or absent address in an LOCAL_IF Address Block, does not in and by itself cause
   Block TLV which (with Flags octet value 80) indicates that a problem.  It single
   address, with index 0 (i.e.  Head:Mid 0) is the
   presence, absence, or incorrectness single local
   interface address of associated LOCAL_IF,
   LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.

   A this router may provide false information about its own identity:

      * (the 1 octet Value THIS_IF indicates
   that this address is of this interface).  The HELLO message may contain addresses with an associated
         LOCAL_IF second is a LINK_STATUS
   Address Block TLV which do not correspond to addresses
         of interfaces of (with Flags octet value 48) specifies the router transmitting
   link status values of all reported neighbors in a single multivalue
   Address Block TLV which covers the HELLO message.

      * addresses with indexes 1 to 4.
   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 TLV Value Length of 4 octets indicates one octet
   per Value per address.  The last four addresses have associated link
   status, the MANET interface over
         which first and second HEARD, the HELLO message is transmitted, if that is third SYMMETRIC, and the case).

      *  The
   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 message may incorrectly specify the     |1 1 1 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 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 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 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    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |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 Address Block TLV may,
         incorrectly, fail to identify an address as being of a MANET
         interface which is or was heard on  |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 conveyed, more efficiently (assuming that the MANET
   local 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 will be supplied by IP, and that the
         sending router's symmetric 1-hop neighborhood;

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

      *  The value of a 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 Address Block TLV may incorrectly
         indicate the status (LOST,  |0 0 0 1 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   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.

17.2.  Authentication, Integrity   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

Appendix D.  Flow and Confidentiality Suggestions

   The security suggestions in [RFC5444] regarding inclusion of a
   cryptographic signature in a Congestion Control

   This protocol specifies one Message TLV or a Packet TLV can be
   applied to this protocol.  Failure to verify either form Type, the HELLO message.  The
   maximum size of
   cryptographic signature causes a HELLO message is proportional to be rejected without
   being processed.

   The following simplification the size of the suggestions for end-to-end
   authentication and integrity in [RFC5444] may be applied to
   originating router's 1-hop neighborhood.  HELLO
   messages:

   o  As the Message Header fields <msg-hop-count> and <msg-hop-limit>
      are either omitted or will always have the values 0 and 1,
      respectively, an end to end cryptographic signature can messages MUST NOT be
      calculated based on the entire HELLO message, including
   forwarded.

   A router MUST report its
      unmodified Message Header.

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

18.  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 "Address Block TLV
   Types" repository HELLO messages on each
   of [RFC5444].

18.1.  Expert Review: Evaluation Guidelines

   For its MANET interfaces at least each REFRESH_INTERVAL.  This puts a
   lower bound on the registries where an Expert Review is required, control traffic generated by each router in the designated
   expert SHOULD take
   network employing this protocol.

   A router MUST ensure that two successive HELLO messages sent on the
   same general recommendations into
   consideration as MANET interface are specified separated by [RFC5444].

18.2.  Message Types

   This specification defines one Message Type, to at least HELLO_MIN_INTERVAL.
   (If using jitter then this may be allocated from the
   0-223 range reduced to a mean minimum value of
   HELLO_MIN_INTERVAL - HP_MAXJITTER/2.)  Thus, this puts an upper bound
   on the "Message Types" namespace defined control traffic generated by each router in [RFC5444], the network
   employing this protocol.

Appendix E.  Interval and Timer Illustrations

   This informative appendix illustrates the relationship between
   message timers and intervals.  (The adjustments to this timing when
   using timing jitter, as
   specified defined in Table 3.

                    +-------+------+-----------------+
                    |  Name | Type | Description     |
                    +-------+------+-----------------+
                    | [RFC5148], are not shown.)

E.1.  HELLO | TBD1 | Local signaling |
                    +-------+------+-----------------+

                     Table 3: Message Type assignment

18.3.  Message-Type-specific TLV Type Registries

   IANA is requested to create Generation Timing

   Figure 1 illustrates a registry for Message-Type-specific
   Message TLVs basic HELLO message schedule for a router, on
   a MANET interface, employing strictly periodic transmission of HELLO messages, in accordance with Section 6.2.1
   messages.  The router transmits a HELLO message each HELLO_INTERVAL.
   Each HELLO message contains all neighbor addresses 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: the router that
   are to be reported in any such HELLO Message-Type-specific Message TLV Types

   IANA message.  (The parameter
   REFRESH_INTERVAL, not shown, is requested in this example equal to create the
   parameter HELLO_INTERVAL.)

   The router includes a registry for Message-Type-specific
   Address Block TLVs for HELLO messages, in accordance with Section
   6.2.1 of [RFC5444], and with initial assignments and allocation
   policies as specified VALIDITY_TIME TLV in Table 5.

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

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

18.4.  Address Block TLV Types

   This specification defines three Address Block TLV Types, message,
   encoding the parameter H_HOLD_TIME, the duration for which must
   information received in the HELLO message should be allocated from considered valid
   by receiving routers.  Receiving routers will, when recording the "Address Block TLV Types" namespace defined in
   [RFC5444].  IANA are requested to make allocations
   information received in the 0-127 range HELLO message, each use this for these types.  This will create three new type extension
   registries with assignments as specified in Table 6, Table 7 setting
   the L_HEARD_time, L_SYM_time and
   Table 8.  Specifications L_time elements of these Address Block TLVs are their
   corresponding Link Tuple, and the N2_time in
   Section 10.1.1, with Value Constants defined the corresponding 2-Hop
   Tuple for each address.  Only L_time is illustrated in Section 18.5.

   +------------+------+-----------+-----------------------------------+
   |    Name    | Type Figure 1.

     H_HOLD_TIME:         |-----------------------------|   ...

     HELLO_INTERVAL:      |---------|---------|---------|   ...

     Time:             ---*---------*---------*---------*------>

                          ^         ^         ^         ^
                          |    Type         | Description         |         |
         HELLO (a, b, c, d)         |         | extension         |
                                    |
   +------------+------+-----------+-----------------------------------+         |  LOCAL_IF         | TBD2
                   HELLO (a, b, c, d)         |     0         | Specifies that the address is   ...
                                              |         |
                             HELLO (a, b, c, d)         |
                                                        |
                                       HELLO (a, b, c, d)

     L_time:              |-----------------------------|
                                    |--------------------   ...
                                              |----------   ...
                                                        | associated with   ...

           Figure 1: HELLO message generation: regular schedule
   Figure 2 illustrates a message schedule similar to Figure 1, where
   the router announces its own presence more frequently by sending
   additional HELLO messages.  HELLO messages are still sent regularly,
   at a reduced interval defined by a local interface |
   |            |      |           | new value of HELLO_INTERVAL.
   However REFRESH_INTERVAL has not been reduced.  Each neighbor address
   included in these HELLO messages need be advertised only once within
   each REFRESH_INTERVAL.  Consequently the sending router additional HELLO messages
   due to the reduced value of HELLO_INTERVAL may therefore be empty.
   (This is not the only allowed distribution of neighbor addresses,
   they could, for example, be sent alternately a, b and c, d.)

     H_HOLD_TIME:         |-----------------------------|   ...

     REFRESH_INTERVAL:    |---------|---------|---------|   ...

     HELLO_INTERVAL:      |----|----|----|----|----|----|   ...

     Time:             ---*---------*---------*---------*------>

                          ^    ^    ^    ^    ^    ^    ^
                          |    | Unassigned    | TBD2    |   1-255    | Expert Review    |
   +------------+------+-----------+-----------------------------------+

           Table 6: Address Block TLV Type assignment: LOCAL_IF
   +-------------+------+-----------+----------------------------------+    |     Name
         HELLO (a, b, c, d)    | Type    |    Type    | Description    |    |    |
                               | extension    |    |
   +-------------+------+-----------+----------------------------------+    | LINK_STATUS    | TBD3    |     0
                        HELLO ()    | Specifies the status of the link    |    |    |    |
                                    | from the indicated address    |    |    |    |
                   HELLO (a, b, c, d)    | (LOST, SYMMETRIC or HEARD)    |    |  Unassigned    | TBD3
                                         |   1-255    | Expert Review    |
   +-------------+------+-----------+----------------------------------+

          Table 7: Address Block TLV Type assignment: LINK_STATUS

   +--------------+------+-----------+---------------------------------+    |     Name   ...
                                  HELLO ()    | Type    |    Type    | Description
                                              |    |    |
                             HELLO (a, b, c, d)    | extension    |
                                                   |
   +--------------+------+-----------+---------------------------------+    | OTHER_NEIGHB
                                            HELLO ()    | TBD4
                                                        |     0
                                       HELLO (a, b, c, d)

     L_time:              |-----------------------------|
                               |-------------------------   ...
                                    |--------------------   ...
                                         |---------------   ...
                                              |----------   ...
                                                   |-----   ...
                                                        | Specifies   ...

    Figure 2: HELLO message generation: regular schedule with different
                    HELLO_INTERVAL and REFRESH_INTERVAL

   HELLO messages may also be sent in response to events.  The minimal
   interval between two successive HELLO message transmissions by a
   router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO
   message emission rate.  Hence, for each HELLO message transmission, a
   router must wait at least HELLO_MIN_INTERVAL before the next HELLO
   message transmission.  Similarly, the maximum interval between two
   successive HELLO message transmissions is HELLO_INTERVAL, setting a
   lower bound on the message transmission rate.  Hence, for each HELLO
   message transmission, the router must ensure that the next HELLO
   message transmission must not wait more than HELLO_INTERVAL.

   Figure 3 illustrates a message schedule similar to Figure 1, but with
   HELLO messages responding to events at maximum rate, i.e. with HELLO
   messages being sent each HELLO_MIN_INTERVAL.  Note that when a HELLO
   message is sent, it is assumed that the address is   |
   |              |      |           | (SYMMETRIC) or recently was     |
   |              |      |           | (LOST) of following messages may all be
   scheduled at an interface interval of HELLO_INTERVAL, and hence each HELLO
   message contains all neighbor addresses.  In each HELLO message in
   this example, a     |
   |              |      |           | symmetric 1-hop new neighbor of address is added, reflecting the |
   |              |      |           | router transmitting changes
   occuring since the last HELLO message was sent.  HELLO messages are
   sent at the maximum allowed rate in order to signal these changes as
   rapidly as possible.

     H_HOLD_TIME:         |-----------------------------|   ...

     HELLO_INTERVAL:      |---------|---------|---------|   ...

     HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...

     Time:             ---*---------*---------*---------*------>

                          ^    ^    ^    ^    ^    ^    ^
                          |    |  Unassigned    | TBD4    |   1-255    | Expert Review    |
   +--------------+------+-----------+---------------------------------+

         Table 8: Address Block TLV Type assignment: OTHER_NEIGHB

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

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

20.  Acknowledgements

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

   The authors would like to gratefully acknowledge    |
                   HELLO ()    |    |    |    |    |    |
                               |    |    |    |    |    |
                       HELLO (a)    |    |    |    |    |
                                    |    |    |    |    |
                         HELLO (a, b)    |    |    |    |
                                         |    |    |    |   ...
                           HELLO (a, b, c)    |    |    |
                                              |    |    |
                             HELLO (a, b, c, d)    |    |
                                                   |    |
                               HELLO (a, b, c, d, e)    |
                                                        |
                                 HELLO (a, b, c, d, e, f)

     L_time:              |-----------------------------|
                               |-------------------------   ...
                                    |--------------------   ...
                                         |---------------   ...
                                              |----------   ...
                                                   |-----   ...
                                                        |   ...

   Figure 3: HELLO message generation: regular schedule with responsive
                                 messages

   Figure 4 shows the following people
   for intense technical discussions, early reviews same example as Figure 3, but with an increased
   REFRESH_INTERVAL, and comments on showing partial HELLO messages which include
   only the
   specification necessary addresses.

     H_HOLD_TIME:         |-----------------------------|   ...

     REFRESH_INTERVAL:    |-------------------|----------   ...
                               |-------------------|-----   ...
                                    |-------------------|   ...
                                         |---------------   ...
                                              |----------   ...
                                                   |-----   ...
                                                        |   ...

     HELLO_INTERVAL:      |---------|---------|---------|   ...

     HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...

     Time:             ---*---------*---------*---------*------>

                          ^    ^    ^    ^    ^    ^    ^
                          |    |    |    |    |    |    |
                   HELLO ()    |    |    |    |    |    |
                               |    |    |    |    |    |
                       HELLO (a)    |    |    |    |    |
                                    |    |    |    |    |
                            HELLO (b)    |    |    |    |
                                         |    |    |    |   ...
                                 HELLO (c)    |    |    |
                                              |    |    |
                                   HELLO (a, d)    |    |
                                                   |    |
                                        HELLO (b, e)    |
                                                        |
                                             HELLO (c, f)

     L_time:              |-----------------------------|
                               |-------------------------   ...
                                    |--------------------   ...
                                         |---------------   ...
                                              |----------   ...
                                                   |-----   ...
                                                        |   ...

   Figure 4: HELLO message generation: regular schedule with responsive
        messages 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), different HELLO_INTERVAL and REFRESH_INTERVAL
   Figure 5 summarizes the entire IETF MANET working group.

21.  References

21.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 overall relationship between the intervals
   governing HELLO message transmissions by a router.

     H_HOLD_TIME:         |------------------------------------|

     REFRESH_INTERVAL:    |----------------|

     HELLO_INTERVAL:      |----------|

     HELLO_MIN_INTERVAL:  |---|

     Time:             ----------------------------------------------->

                          ^   ^      ^     ^                   ^
                          |   |      |     |                   |
                          |   |      |     |           Time until which
              HELLO message   |      |     |           received HELLO
              transmission    |      |     |           message content
                              |      |     |           is valid.
                              |      |     |
                              |      |     Time before which all
                              |      |     neighbor information must
                              |      |     be transmitted 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.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing multi-value HELLO
                              |      |     messages (one or more)
                              |      |
                              |      Latest time for next HELLO message
                              |      transmission
                              |
                              Earliest time in MANETs", RFC 5497, March 2009.

   [RFC5498]  Chakeres, I., "IANA Allocations for next HELLO message
                              transmission

               Figure 5: HELLO message generation intervals

E.2.  HELLO Message Processing Timing

   Figure 6 illustrates the Link Set timers when receiving a HELLO
   message not including the address of the receiving MANET Protocols",
              RFC 5498, March 2009.

21.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 interface.

     VALIDITY_TIME:    |--------------------------|

     L_time:           |--------------------------|

     L_HEARD_time:     |--------------------------|

     L_SYM_time:     *-| (i.e. expired)

     Time:          ---*-------------------------------->
                       ^
                       |
                HELLO () received

          Figure 6: HELLO message processing: address not present

   Figure 7 illustrates the Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC5449]  Clausen, T., Baccelli, E., Nguyen, D., Set timers when, following the received
   HELLO message illustrated in Figure 6, a router receives a HELLO
   message including the address (a) of the receiving interface with
   link status = HEARD (or SYM).

     VALIDITY_TIME:    |--------------------------|
                             |--------------------------|

     L_time:           |--------------------------|
                             |--------------------------|

     L_HEARD_time:     |--------------------------|
                             |--------------------------|

     L_SYM_time:     *-| (i.e. expired)
     L_SYM_time:             |--------------------------|

     Time:            -*-----*--------------------------------->
                       ^     ^
                       |     |
      HELLO () received      |
                             |
      HELLO (a:HEARD) received

            Figure 7: HELLO message processing: address present

   Figure 8 illustrates the Link Set timers when, following the received
   HELLO messages illustrated in Figure 7, a router receives a HELLO
   message including the address (a) of the receiving interface with
   link status = LOST.

     VALIDITY_TIME:    |--------------------------|
                             |--------------------------|
                                   |--------------------------|

     L_time:           |--------------------------|
                             |--------------------------|
                                   |--------------------------|

     L_HEARD_time:     |--------------------------|
                             |--------------------------|
                                   |--------------------------|

     L_SYM_time:     *-| (i.e. expired)
                             |--------------------------|
                                 *-| (i.e. expired)

     Time:            -*-----*-----*--------------------------------->
                       ^     ^     ^
                       |     |     |
       HELLO () received     |     |
                             |     |
      HELLO (a:HEARD) received     |
                                   |
             HELLO (a:LOST) received

             Figure 8: HELLO message processing: address lost

E.3.  Other HELLO Message Timing

   There are three other timing parameters which are used by a router to
   control HELLO message generation and P. Jacquet,
              "OSPF Multipoint Relay (MPR) Extension for Ad Hoc
              Networks", RFC 5449, February 2009.

Appendix A.  Address Block processing.

   Figure 9 illustrates the time, with duration L_HOLD_TIME, during
   which the appropriate addresses of a formerly, but no longer,
   symmetric 1-hop neighbor, as connected by this MANET interface, are
   advertised as LOST using a LINK_STATUS TLV Combinations

   The algorithm for generating in HELLO messages in Section 11 specifies
   which on this
   MANET interface, thus allowing that 1-hop addresses may neighbor to update its Link
   Set accordingly.

     L_HOLD_TIME:   |----------------------------|

     Time:       ---*---------------------------------->
                    ^                            ^
                    |                            |
         Formerly symmetric 1-hop neighbor       |
         ceases to be included in the Address Blocks, and with symmetric on this          |
         MANET interface                         |
                                                 |
                      Time until which associated Address Block TLVs.  These Address Block TLVs may
   have Type = addresses of this
                      neighbor connected using this MANET
                      interface are advertised in HELLO
                      messages on this MANET interface
                      using a LINK_STATUS or Type TLV, Value = OTHER_NEIGHB, or both.  Address
   Block TLVs LOST

       Figure 9: HELLO message generation: advertisement of formerly
         symmetric 1-hop neighbor on this MANET interface as lost

   Figure 10 illustrates the time, with Type = duration N_HOLD_TIME, during
   which all addresses of a formerly, but no longer, symmetric 1-hop
   neighbor, are advertised as LOST in HELLO messages on all MANET
   interfaces using an OTHER_NEIGHB TLV (if not also reported using a
   LINK_STATUS may have three possible values
   (Value = HEARD, Value = SYMMETRIC or Value = LOST), and Address Block
   TLVs TLV) thus allowing all other symmetric 1-hop neighbors to
   update their 2-Hop Sets accordingly.

     L_HOLD_TIME:   |----------------------------|

     Time:       ---*---------------------------------->
                    ^                            ^
                    |                            |
         Formerly symmetric 1-hop neighbor       |
         ceases to be symmetric                  |
                                                 |
                      Time until which addresses of TYPE = this
                      neighbor are advertised in HELLO
                      messages on all MANET interfaces
                      using an OTHER_NEIGHB may have two possible values (Value =
   SYMMETRIC or TLV,
                      Value = LOST).  When both Address Block TLVs are
   associated with LOST

      Figure 10: HELLO message generation: advertisement of formerly
          symmetric 1-hop neighbor on any MANET interface as lost

   Figure 11 illustrates the same time, with duration I_HOLD_TIME, during
   which a formerly, but no longer, used local interface address only certain combinations is
   excluded from being considered as a 2-hop neighbor address (in order
   that a router is not recorded as its own 2-hop neighbor during that
   period).

     I_HOLD_TIME:      |----------------------------|

     Time:          ---*----------------------------------->
                       ^                            ^
                       |                            |
       Formerly used local interface                |
       address ceases to be assigned                |
       to a local interface                         |
                                                    |
                               Time until which this address
                               is excluded from being included
                               in this router's 2-Hop Set

                Figure 11: Local interface removed address

Appendix F.  Topology Pictures

   This appendix illustrates various examples of physical topologies, as
   well as how these
   Address Block TLV values are necessary, and are the only combinations
   generated logically recorded by NHDP from the algorithm in Section 11.  These combinations are
   indicated in Table 9.

   Cells labeled with "Yes" indicate point of
   view of the possible combinations router A. This representation is a composite of
   information which would be contained within A's various Information
   Bases after NHDP has been running for sufficiently long time for the
   state to converge.

   Note that the examples given in this appendix are
   generated NOT exhaustive, but
   are selected to be illustrative of NHDP neighborhood representations
   of physical MANET topologies.

   The example topologies presented contain 3 physical routers A, B and
   C. Each of these routers has one or two distinct interfaces, denoted
   "top" and "bottom".  Each interface has one or two addresses, and
   symmetric connectivity between a pair of interfaces is illustrated by the algorithm in Section 11.  Cells labeled with "No"
   indicate combinations not generated
   these being connected by a line.

   In all examples, the algorithm in Section 11,
   but which are correctly parsed and interpreted topology is described as it is recorded by the algorithm NHDP
   in
   Section 12.  The cell labeled router A.

F.1.  Example 1: Standard Single Interface Topology

   In Figure 12, each router has a single interface, each with "No*" a single
   IP address.  This is actually inconsistent, it the simplest possible network, and the resulting
   representation is handled by ignoring given to the Address Block TLV with Type =
   OTHER_NEIGHB.

   +----------------+----------------+----------------+----------------+
   |                |     Type =     |     Type =     |     Type =     |
   |                |  OTHER_NEIGHB  |  OTHER_NEIGHB, |  OTHER_NEIGHB, |
   |                |    (absent)    |     Value =    |  Value = LOST  |
   |                |                |    SYMMETRIC   |                |
   +----------------+----------------+----------------+----------------+
   | Type =         |       No       |       Yes      |       Yes      |
   | LINK_STATUS    |                |                |                |
   | (absent)       |                |                |                |
   | Type =         |       Yes      |       Yes      |       Yes      |
   | LINK_STATUS,   |                |                |                |
   | Value = HEARD  |                |                |                |
   | Type =         |       Yes      |       No       |       No*      |
   | LINK_STATUS,   |                |                |                |
   | Value =        |                |                |                |
   | SYMMETRIC      |                |                |                |
   | Type =         |       Yes      |       Yes right in Figure 12.

         __________ __________
        |       No          |          | LINK_STATUS,
       {1}        {2}        {3}
        |          |          |              {1}--------{2}--------{3}
     +--'--+    +--'--+    +--'--+
     |  A  | Value = LOST    |  B  |    |  C  |
   +----------------+----------------+----------------+----------------+

          Table 9: LINK_STATUS
     +-----+    +-----+    +-----+

         Figure 12: Standard single interface topology (left), and OTHER_NEIGHB TLV combinations

Appendix B.  Constraints

   Any process which updates the
                 corresponding NHDP representation (right)

   The Local Information Base or the Neighbor
   Information Base MUST ensure that all constraints specified Set in this
   appendix are maintained.

   In each A contains a single 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
   Tuple which is in
      the has an 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 {1}.  This value is in
   denoted with a {1} on the
      I_local_iface_addr_list leftmost part of any Local Interface Tuple.

   o  IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
      other Removed resulting
   representation.

   The Interface Address Tuple.

   In each Information Base has only one Link Tuple:

   o  L_neighbor_iface_addr_list MUST NOT be empty.

   o  L_neighbor_iface_addr_list MUST NOT contain any address Set, which is
      in
   represents the I_local_iface_addr_list "top" interface of any Local Interface Tuple A, 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 {1}.  This Link Set's only
   Link Tuple has an L_neighbor_iface_addr_list MUST NOT contain any address which is containing {2}; this
   corresponds to the dashed line from {1} to {2} to the right in
   Figure 12.  The 2-Hop Set contains a single 2-Hop Tuple, with
   N2_neighbor_iface_addr_list being {2} and N2_hop_addr being {3}; this
   corresponds to the L_neighbor_iface_addr_list of any other Link Tuple dashed line from {2} to {3} to the right in
   Figure 12.

   The descriptions of the
      same Link Set.

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

   o  L_HEARD_time MUST NOT be greater than L_time.

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

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

   o  If L_quality >= HYST_ACCEPT then L_pending MUST be false.

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

   o  L_pending MUST NOT following examples in this appendix will be set to true if it is currently false.

   In each
   derived similarly, and use the same notational conventions.

F.2.  Example 2: Dual Addressed Interface on One Hop Neighbor Tuple:

   o  N_neighbor_iface_addr_list MUST NOT contain any address which

   In Figure 13, the network is identical to that in Example 1, except
   that the I_local_iface_addr_list middle router, B, has two IP addresses on its single
   interface.

         __________ __________
        |          |          |
       {1}       {2,4}       {3}
        |          |          |              {1}-------{2,4}-------{3}
     +--'--+    +--'--+    +--'--+
     |  A  |    |  B  |    |  C  |
     +-----+    +-----+    +-----+

      Figure 13: Single interfaces, with 1-hop neighbor B having two
      addresses (left), and corresponding NHDP representation (right)

   The content 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 Information Base is in the N_neighbor_iface_addr_list of any other this case
   identical to Example 1, except that L_neighbor_iface_addr_list is
   {2,4} and N2_neighbor_iface_addr_list is {2,4}.

F.3.  Example 3: Dual Addressed Interface on Two Hop Neighbor Tuple.

   o  If N_symmetric

   In Figure 14, the network is = true, then there MUST be one or more Link
      Tuples with:

      *  L_neighbor_iface_addr_list contained identical to that in
         N_neighbor_iface_addr_list; AND
      *  L_status = SYMMETRIC.

   o  If N_symmetric Example 1, except
   that the rightmost router, C, has two IP addresses on its interface.

         __________ __________
        |          |          |
       {1}        {2}       {3,4}                             _.---{3}
        |          |          |              {1}--------{2}--<_
     +--'--+    +--'--+    +--'--+                             '---{4}
     |  A  |    |  B  |    |  C  |
     +-----+    +-----+    +-----+

      Figure 14: Single interfaces, with 2-hop neighbor C having two
      addresses (left), and corresponding NHDP representation (right)

   The content of the Interface Information Base is = false, then there MUST be one or more Link in this case
   identical to than in Example 1, except that the 2-Hop Set contains an
   extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
   N2_hop_addr being {4}.  These two 2-Hop Tuples with:

      *  L_neighbor_iface_addr_list contained are illustrated by the
   two lines from {2} to {3} and (2) to {4}, respectively.

F.4.  Example 4: Dual Addressed Interfaces

   In Figure 15, the network is identical to that in
         N_neighbor_iface_addr_list.

      All such Link Tuples MUST NOT have L_status = SYMMETRIC.  At least
      one such Link Tuple MUST Example 1, except
   that all routers have L_HEARD_time not expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_iface_addr MUST NOT be two IP addresses on their interface.  The Local
   Information Base in router A is the same as in Example 1, except that
   I_local_iface_addr_list is {1,5}.

         __________ __________
        |          |          |
      {1,5}      {2,6}      {3,4}                             _.---{3}
        |          |          |             {1,5}------{2,6}-<_
     +--'--+    +--'--+    +--'--+                             '---{4}
     |  A  |    |  B  |    |  C  |
     +-----+    +-----+    +-----+

      Figure 15: Single interfaces, all routers having two addresses
           (left), and corresponding NHDP representation (right)

   The content 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 Information Base is in the
      N_neighbor_iface_addr_list this case a
   combination of any the Interface Information Bases from Example 1,
   Example 2 and Example 3.

F.5.  Example 5: Dual Interface on Two Hop Neighbor Tuple with N_symmetric
      = true.

   In Figure 16, all routers have a single IP address on each 2-Hop Tuple:

   o  There MUST be interface,
   and with the 2-hop neighbor having two interfaces.

         __________ __________
        |          |          |
       {1}        {2}        {3}                              _.---{3}
        |          |          |              {1}--------{2}--<_
     +--'--+    +--'--+    +-----+                             '---{4}
     |  A  |    |  B  |    |  C  |
     +-----+    +-----+    +-----+
                              |
                             {4}

       Figure 16: Single addresses, with 2-hop neighbor C having two
     interfaces (left), and corresponding NHDP representation (right)

   The Interface Information Base is identical to that in Example 3;
   NHDP does not distinguish topologically between this example and
   Example 3.

F.6.  Example 6: Dual interface on One Hop Neighbor

   In Figure 17, all routers have a single IP address on each interface,
   and with the 1-hop neighbor having two interfaces.

         __________
        |          |
       {1}        {2}                                   ,-.
        |          |                         {1}-------/{2}\-------{4}
     +--'--+    +--'--+    +-----+                     \{5}/
     |  A  |    |  B  |    |  C  |                      `-'
     +-----+    +-----+    +-----+
                   |          |
                  {5}        {4}
                   |__________|

       Figure 17: Single addresses, with 1-hop neighbor B having two
     interfaces (left), and corresponding NHDP representation (right)

   The Local Information Base is identical to that in Example 1.

   The Interface Information Base has only one Link Set containing one
   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 being {2}.  The 2-Hop Set
   contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being
   {2} and N2_hop_addr being {4}.

   The Neighbor Information Base contains a Neighbor Set containing a
   single Neighbor Tuple, which represents router B, with
   N_neighbor_addr_list being {2,5}.  This entry is represented on the same
      N2_neighbor_iface_addr_list.

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

Appendix C.  HELLO Message Example

   An example HELLO message, transmitted Figure 17 by an originator router circling {2} with {5}.

   Note that router A does not have information indicating which of
   router B's interfaces is connected to router C. However, router A
   knows that the address {4} (and thus router C) is reachable by using
   {2} as next hop.

F.7.  Example 7: Dual Interface on One and Two Hop Neighbors

   In Figure 18, all routers have a single MANET IP address on each 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 both the message 1-hop and 2-hop neighbors have length four octets, here being IPv4
   addresses.  The message is as transmitted two interfaces.
   Furthermore, there are now two physical links between routers B and
   C, over distinct interface pairs.

         __________ __________
        |          |          |
       {1}        {2}        {3}                        ,-.    _.---{3}
        |          |          |              {1}-------/{2}\--<_
     +--'--+    +--'--+    +-----+                     \{5}/    '---{4}
     |  A  |    |  B  |    |  C  |                      `-'
     +-----+    +-----+    +-----+
                   |          |
                  {5}        {4}
                   |__________|

    Figure 18: Single addresses, with a hop limit of 1 1-hop and a
   hop count of 0. 2-hop neighbors B and C
    having two interfaces (left), and corresponding NHDP representation
                                  (right)

   The overall message length Local Information Base is 49 octets. identical to that in Example 1.

   The message contains a Message TLV Block with content length 8 octets
   containing Link Set is identical to that in Example 6, and the 2-Hop Set
   contains, as in Example 5 (and similarly to Examples 3 and 4), two Message TLVs, of types VALIDITY_TIME
   2-Hop Tuples representing the two links between routers B and
   INTERVAL_TIME.  Each uses a Message TLV with flags octet value 16,
   indicating C

   Note that each has a value.  Each has a value length router A does not have information describing which of 1
   octet;
   router B's interfaces is connected to which interfaces of router C,
   or even that the values included (0x64 interfaces with addresses {3} and 0x58) {4} are time codes
   representing the default values interfaces
   of parameters H_HOLD_TIME the same router.  However, router A knows that the addresses {3}
   and
   HELLO_INTERVAL, respectively (6 seconds {4} (and thus router C) are reachable using {2} as next hop.

F.8.  Example 8: Dual Interface Locally and 2 seconds) assuming the
   default value of constant C (1/1024 second).

   The message has on One Hop Neighbor

   In Figure 19, all routers have a single Address Block containing 5 addresses.  The
   flags octet value 128 indicates an address Head but no IP address Tail, on each interface,
   and both A and its the 1-hop neighbor B have two interfaces.
   Furthermore, there are now two physical links between routers A and
   B, over distinct interface pairs.

         __________ __________
        |          |          |                         ,-.
       {1}        {2}        {3}             {1}-------/{2}\--------{3}
        |          |          |                        \{5}/
     +--'--+    +--'--+    +-----+                      `-'
     |  A  |    |  B  |    |  C  |
     +-----+    +-----+    +-----+                      ,-.
        |          |                                   /{2}\
       {6}        {5}                        {6}-------\{5}/--------{3}
        |__________|                                    `-'

   Figure 19: Single addresses, with both A and 1-hop neighbor B having
   two interfaces (left), and no address prefixes. corresponding NHDP representation (right)

   The Head Length of 3 octets indicates
   address Mid sections Local Information Set contains two Local Interface Tuples, with
   I_local_iface_addr_list of {1} and {6}, respectively.

   Each Interface Information Base's Link Set contains one octet each (Mid 0 to Mid 4).

   The following Address Block TLV Block (content length 14 octets)
   includes two Address Block TLVs. Link Tuple,
   representing the links between {1} and {2}, and between {6} and {5},
   respectively.  The first is a LOCAL_IF Address
   Block TLV which (with flags octet value 80) indicates that 2-Hop Set for interface {1} contains a single
   address,
   2-Hop Tuple, with index 0 (i.e.  Head:Mid 0) is the single local N2_neighbor_iface_addr_list being {2} and
   N2_hop_addr being {3}.  The 2-Hop Set for interface address of this router (the 1 octet value THIS_IF indicates
   that this address is of this interface). {6} contains a
   single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and
   N2_hop_addr being {3}.

   The second is Neighbor Information Base contains a LINK_STATUS
   Address Block TLV Neighbor Set containing a
   single Neighbor Tuple, which (with flags octet value 48) specifies the
   link status values of represents router B, with
   N_neighbor_addr_list being {2,5}.  This entry is denoted by circling
   {2} with {5}.

F.9.  Example 9: Dual Interface on All Routers

   In Figure 20, all reported neighbors in routers have a single multivalue
   Address Block TLV which covers the addresses IP address on each interface,
   and all routers have two interfaces.  Furthermore, there are now two
   physical links between A and B, over distinct interface pairs, and
   two physical links between B and C, also over distinct interface
   pairs.

         __________ __________
        |          |          |                         ,-.    _.---{3}
       {1}        {2}        {3}             {1}-------/{2}\--<_
        |          |          |                        \{5}/    '---{4}
     +--'--+    +--'--+    +-----+                      `-'
     |  A  |    |  B  |    |  C  |
     +-----+    +-----+    +-----+                      ,-.
        |          |          |                        /{2}\   _.---{3}
       {6}        {5}        {4}             {6}-------\{5}/--<_
        |__________|__________|                         `-'     '---{4}

    Figure 20: Single addresses, with indexes 1 all routers having two interfaces
           (left), and corresponding NHDP representation (right)

   The Local Information Set is identical to 4.
   The Address Block TLV value length of 4 octets indicates one octet
   per value per address. that in Example 8.  The last four addresses have associated link
   status, the first and second HEARD,
   Interface Information Base for each interface in A is also identical
   to that in Example 8, except that an additional 2-Hop Tuple is
   present in each 2-Hop Set, each representing the third SYMMETRIC, link between router
   B and the
   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     |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 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 1 1|                     Head interface of router C with address {4}.

   As in Example 7, router A does not have information describing which
   of router B's interfaces is connected to which interface of C, or
   even that the interfaces with addresses {3} and {4} are interfaces of
   the same router.  However, router A knows that the addresses {3} and
   {4} (and router C) are reachable by using {2} or {5} (depending on
   via which of its local interfaces) as next hop.

F.10.  Example 10: Dual Addressed Dual Interfaces on All Routers

   In Figure 21, all routers have two IP addresses on each interface,
   and all routers have two interfaces.  Furthermore, there are now two
   physical links between A and B, over distinct interface pairs, and
   two physical links between B and C, also over distinct interface
   pairs.

         __________ __________                        _         _.--{9}
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          |     Mid 0          |     Mid 1                     ,' `.   _.-<__-{10}
      {1,2}      {5,6}      {9,10}          {1,2}--|{5,6}|-<_   __
        |     Mid 2          |     Mid 3          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |{7,8}|   '-<_ -{11}
     +--'--+    +--'--+    +-----+                  `._,'        '-{12}
     |     Mid 4     |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|   LOCAL_IF  A  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |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    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  B  |  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  C  |   SYMMETRIC                    _
     +-----+    +-----+    +-----+                  ,' `.       _.--{9}
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          |     LOST          |
     +-+-+-+-+-+-+-+-+

   Note that this                    |{5,6}|  _.-<__-{10}
      {3,4}      {7,8}     {11,12}          {3,4}--|{7,8}|-<_   __
        |__________|__________|                     `._,'    '-<_ -{11}
                                                                 '-{12}

     Figure 21: Dual addresses, with all routers having two interfaces
           (left) and corresponding NHDP representation (right)

   This example is for illustrative purposes.  The essential the combination of all the preceding examples in this
   appendix.  The Local Information Set in A contains Local Information
   Tuples for each of its interfaces, and each Interface Information
   Base contains in its Link Set a representation of links {1,2}-{5,6}
   or {3,4}-{7,8}, respectively.  The Neighbor Set (in the Neighbor
   Information Base) records the existence of router B and all of its
   addresses on all its interfaces, i.e. {5,6,7,8}.

   As in Example 9, each interface address of router C is represented in
   the 2-Hop Set of each Interface Information Base as a link from
   router B to each of these addresses.  Router A does not have
   information can be conveyed, more efficiently (assuming describing which of router B's interfaces is connected to
   which interface of C, nor that the
   local interface address will be supplied by IP, addresses {9}, {10}, {11}, and
   {12} are addresses of the same router (or that some of these, such as
   {9} and {10}, are addresses on the
   INTERVAL_TIME TLV is not needed) by same interface of the 29 octets:

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

F.11.  Example 11: Single Addressed Dual Interface Locally

   In Figure 22, all routers have a single interface, except for router
   A which has two.  Each of A's two interfaces has a link with the
   single interface of router B. All interfaces have a single address.

         __________ __________
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     _____|          |     Mid 1
       {1}   |     Mid 2    {2}        {3}             {1}--------{2}---------{3}
        |     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  +--'--+    +-----+
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  A  |     LOST |
     +-+-+-+-+-+-+-+-+

Appendix D.  Flow and Congestion Control

   This protocol specifies one Message Type,  |  B  |    |  C  |
     +-----+ |  +-----+    +-----+
        |    |
       {6}   |                               {6}--------{2}---------{3}
        |____|

      Figure 22: Single addresses, with A having two interfaces, both
    linked to the HELLO message.  The
   maximum size single interface of a HELLO message B (left), and corresponding NHDP
                          representation (right)

   This is proportional similar to Example 8, except that the size of single address {2} also
   replaces the
   originating router's 1-hop neighborhood.  HELLO messages MUST NOT be
   forwarded.

   A router MUST report its 1-hop neighborhood address {5}.  In particular both Link Tuples (one 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 Link Set, each router in its corresponding Interface Information Base)
   have L_neighbor_iface_addr_list being {2}, the
   network employing this protocol.

   A router MUST ensure that two successive HELLO messages sent on Neighbor Set (in the
   same MANET interface are separated by at least HELLO_MIN_INTERVAL.
   (If using jitter then this may be reduced to
   Neighbor Information Base) contains a mean minimum value of
   HELLO_MIN_INTERVAL - HP_MAXJITTER/2.)  Thus, this puts an upper bound
   on the control traffic generated by single Neighbor Tuple with
   N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each
   2-Hop Set, each router in the network
   employing this protocol. its corresponding Interface Information Base) have
   N2_neighbor_iface_list being {2} and N2_2hop_addr being {3}.

Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/

   Christopher Dearlove
   BAE Systems 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