[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 6130

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


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

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

Copyright Notice



Clausen, et al.        Expires September 10, 2009               [Page 1]

Internet-Draft                 MANET-NHDP                     March 2009


   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
     3.1.  Usage in Other Protocols . . . . . . . . . . . . . . . . . 10
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . . 10
     4.1.  Routers and Interfaces . . . . . . . . . . . . . . . . . . 11
     4.2.  Information Base Overview  . . . . . . . . . . . . . . . . 12
       4.2.1.  Local Information Base . . . . . . . . . . . . . . . . 12
       4.2.2.  Interface Information Bases  . . . . . . . . . . . . . 13
       4.2.3.  Neighbor Information Base  . . . . . . . . . . . . . . 14
     4.3.  Signaling Overview . . . . . . . . . . . . . . . . . . . . 14
       4.3.1.  HELLO Message Generation . . . . . . . . . . . . . . . 15
       4.3.2.  HELLO Message Content  . . . . . . . . . . . . . . . . 15
       4.3.3.  HELLO Message Processing . . . . . . . . . . . . . . . 16
     4.4.  Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Protocol Parameters and Constants  . . . . . . . . . . . . . . 17
     5.1.  Interface Parameters . . . . . . . . . . . . . . . . . . . 18
       5.1.1.  Message Intervals  . . . . . . . . . . . . . . . . . . 18
       5.1.2.  Information Validity Times . . . . . . . . . . . . . . 19
       5.1.3.  Link Quality . . . . . . . . . . . . . . . . . . . . . 20
       5.1.4.  Jitter . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.2.  Router Parameters  . . . . . . . . . . . . . . . . . . . . 21
       5.2.1.  Information Validity Time  . . . . . . . . . . . . . . 21
     5.3.  Parameter Change Constraints . . . . . . . . . . . . . . . 21
     5.4.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . 23
   6.  Local Information Base . . . . . . . . . . . . . . . . . . . . 23
     6.1.  Local Interface Set  . . . . . . . . . . . . . . . . . . . 23
     6.2.  Removed Interface Address Set  . . . . . . . . . . . . . . 23
   7.  Interface Information Base . . . . . . . . . . . . . . . . . . 24
     7.1.  Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.2.  2-Hop Set  . . . . . . . . . . . . . . . . . . . . . . . . 25



Clausen, et al.        Expires September 10, 2009               [Page 2]

Internet-Draft                 MANET-NHDP                     March 2009


   8.  Neighbor Information Base  . . . . . . . . . . . . . . . . . . 26
     8.1.  Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 26
     8.2.  Lost Neighbor Set  . . . . . . . . . . . . . . . . . . . . 26
   9.  Local Information Base Changes . . . . . . . . . . . . . . . . 27
     9.1.  Adding an Interface  . . . . . . . . . . . . . . . . . . . 27
     9.2.  Removing an Interface  . . . . . . . . . . . . . . . . . . 27
     9.3.  Adding an Address to an Interface  . . . . . . . . . . . . 28
     9.4.  Removing an Address from an Interface  . . . . . . . . . . 29
   10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 29
     10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 30
       10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 31
   11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 32
     11.1. HELLO Message Specification  . . . . . . . . . . . . . . . 32
     11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 34
       11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 34
   12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 35
     12.1. Invalid Message  . . . . . . . . . . . . . . . . . . . . . 35
     12.2. Definitions  . . . . . . . . . . . . . . . . . . . . . . . 36
     12.3. Updating the Neighbor Set  . . . . . . . . . . . . . . . . 37
     12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 38
     12.5. Updating the Link Set  . . . . . . . . . . . . . . . . . . 39
     12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 40
   13. Other Information Base Changes . . . . . . . . . . . . . . . . 41
     13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 42
     13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 43
     13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 43
   14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 44
     14.1. Deployment Without Link Quality  . . . . . . . . . . . . . 44
     14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 45
     14.3. When Link Quality Changes  . . . . . . . . . . . . . . . . 46
     14.4. Updating Link Quality  . . . . . . . . . . . . . . . . . . 46
   15. Proposed Values for Parameters and Constants . . . . . . . . . 47
     15.1. Message Interval Interface Parameters  . . . . . . . . . . 47
     15.2. Information Validity Time Interface Parameters . . . . . . 47
     15.3. Information Validity Time Router Parameters  . . . . . . . 47
     15.4. Link Quality Interface Parameters  . . . . . . . . . . . . 47
     15.5. Jitter Interface Parameters  . . . . . . . . . . . . . . . 48
     15.6. Constants  . . . . . . . . . . . . . . . . . . . . . . . . 48
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 48
     16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48
     16.2. Authentication, Integrity and Confidentiality
           Suggestions  . . . . . . . . . . . . . . . . . . . . . . . 50
   17. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 50
     17.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 50
     17.2. Message Types  . . . . . . . . . . . . . . . . . . . . . . 50
     17.3. Message-Type-specific TLV Type Registries  . . . . . . . . 51
     17.4. Address Block TLV Types  . . . . . . . . . . . . . . . . . 51
     17.5. LINK_STATUS and OTHER_NEIGHB Values  . . . . . . . . . . . 52



Clausen, et al.        Expires September 10, 2009               [Page 3]

Internet-Draft                 MANET-NHDP                     March 2009


   18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
   19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
   20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
     20.1. Normative References . . . . . . . . . . . . . . . . . . . 54
     20.2. Informative References . . . . . . . . . . . . . . . . . . 54
   Appendix A.  Address Block TLV Combinations  . . . . . . . . . . . 54
   Appendix B.  Constraints . . . . . . . . . . . . . . . . . . . . . 55
   Appendix C.  HELLO Message Example . . . . . . . . . . . . . . . . 58
   Appendix D.  Flow and Congestion Control . . . . . . . . . . . . . 60










































Clausen, et al.        Expires September 10, 2009               [Page 4]

Internet-Draft                 MANET-NHDP                     March 2009


1.  Introduction

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

   1-hop and symmetric 2-hop neighborhood information is recorded in the
   form of Information Bases.  These may be used by other protocols,
   such as MANET routing protocols, 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 ad hoc network
   interface characteristics.

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

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

1.1.  Motivation

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

   Due to the properties of wireless transmissions, communication
   between two network interfaces on neighboring routers may not be
   bidirectional; even if router A is able to receive a 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.  If router A is able to exchange packets
   with router B and router B is able to exchange packets with router C
   on the same interface, this does not guarantee that router A and



Clausen, et al.        Expires September 10, 2009               [Page 5]

Internet-Draft                 MANET-NHDP                     March 2009


   router C can exchange packets directly.

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

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

   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 are
   typically no signals from lower layers which would enable an IP
   routing protocol to detect and, as appropriate, react to such
   changes.  Such changes are 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, continued
   bidirectionality tracking of links between neighbors, and local
   topological information up to two hops.  Combined, this allows a
   MANET routing protocol access to information describing link
   establishment/disappearance, and provides the necessary topological
   information for reduced relay set selection and other purposes.

2.  Terminology

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

   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:



Clausen, et al.        Expires September 10, 2009               [Page 6]

Internet-Draft                 MANET-NHDP                     March 2009


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

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

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

   MANET interface  - An interface participating in a MANET and using
      this neighborhood discovery protocol.  A 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 pair of MANET interfaces from two different routers, where
      at least one interface is heard by the other.

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

   1-hop neighbor  - A 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.

   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.







Clausen, et al.        Expires September 10, 2009               [Page 7]

Internet-Draft                 MANET-NHDP                     March 2009


   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.

   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 constant is a numerical value which MUST be the same
      for all MANET interfaces of all routers in the MANET, at all
      times.

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

   Router parameter  - A router parameter is 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.

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




Clausen, et al.        Expires September 10, 2009               [Page 8]

Internet-Draft                 MANET-NHDP                     March 2009


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

3.  Applicability Statement

   This protocol:

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

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

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

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

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

   o  Supports 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  Can use the link local multicast address "LL-MANET-Routers", and
      either the "manet" UDP port or the "manet" IP protocol number, all
      as specified in [manet-iana].

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

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

   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.



Clausen, et al.        Expires September 10, 2009               [Page 9]

Internet-Draft                 MANET-NHDP                     March 2009


3.1.  Usage in Other Protocols

   Other protocols 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
      Local Information Base (Section 6), the Interface Information Base
      (Section 7) and the Neighbor Information Base (Section 8).  These
      Information Bases record the interface configuration of the
      router, as well as the local connectivity, up to two hops away.
      All updates to the elements specified in this document are subject
      to the constraints specified in Appendix B.

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

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

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

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

4.  Protocol Overview and Functioning

   The objective of this protocol is, for each router:

   o  To identify other routers which can be heard, and those with which
      bidirectional links can be established (symmetric 1-hop
      neighbors).




Clausen, et al.        Expires September 10, 2009              [Page 10]

Internet-Draft                 MANET-NHDP                     March 2009


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

   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, of which this neighborhood discovery protocol
      may be a part.

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

   o  Advertises the presence of a router and its interfaces.

   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 be, where appropriate, specific to a specific
      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.

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:





Clausen, et al.        Expires September 10, 2009              [Page 11]

Internet-Draft                 MANET-NHDP                     March 2009


   o  Is characterized by a set of interface parameters, defining the
      behavior of this MANET interface.  Each MANET interface MAY be
      individually parameterized.

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

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

   In addition to a set of MANET interfaces as described above, each
   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.

4.2.1.  Local Information Base

   Each router maintains a Local Information Base, which contains:

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




Clausen, et al.        Expires September 10, 2009              [Page 12]

Internet-Draft                 MANET-NHDP                     March 2009


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

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

4.2.2.  Interface Information Bases

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

   o  A Link Set, which records information about current and recently
      lost links between this interface and MANET interfaces of 1-hop
      neighbors.  The Link Set consists of Link Tuples, each of which
      contains information about a single link.  Recently lost links are
      recorded so that they can be advertised in HELLO messages,
      accelerating their removal from relevant 1-hop neighbors' Link
      Sets.  Link quality information (see Section 14), if used and
      available, is recorded in Link Tuples and may indicate that links
      are treated as lost.

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

   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 detect bidirectionality (if router A
   advertises router B as heard in a HELLO message and router B receives
   that HELLO message, then router B knows that bidirectional
   communication is possible between routers A and B), and to populate
   the 2-Hop Set (if router C receives a HELLO message from router B
   advertising a bidirectional link to address A, then router C knows
   that address A is reachable in two hops via router B).




Clausen, et al.        Expires September 10, 2009              [Page 13]

Internet-Draft                 MANET-NHDP                     March 2009


   The Link Set for a MANET interface is itself updated upon receipt of
   a HELLO message, including to record link bidirectionality 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:

   o  The Neighbor Set, which records 1-hop neighbors, each of which
      must be currently heard, although this may be over a link with
      insufficient link quality.  The Neighbor Set consists of Neighbor
      Tuples, each of which records all interface addresses of a single
      1-hop neighbor.  Neighbor Tuples are maintained as long as there
      are corresponding current Link Tuples.

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

   The Neighbor Set is used for recording which interface addresses of
   neighbor routers are associated to the same router, and for including
   this when generating HELLO messages such that 2-Hop sets in other
   neighboring routers may record this information.  The Neighbor Set
   can itself be updated on receipt of a HELLO message.

   The Lost Neighbor Set is used for generating HELLO messages.
   Specifically, the Lost Neighbor Set is used for determining which
   addresses are to be included in a HELLO and identified through
   inclusion of an appropriate TLV as being "lost", i.e. formerly, but
   no longer, recorded as a symmetric neighbor.  The Lost Neighbor Set
   can itself be updated on receipt of a HELLO message.

4.3.  Signaling Overview

   This protocol contains a signaling mechanism for maintaining the
   Interface Information 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



Clausen, et al.        Expires September 10, 2009              [Page 14]

Internet-Draft                 MANET-NHDP                     March 2009


   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 interface for which it has been generated.

   Each HELLO message identifies the MANET interface for which it is
   generated and over which it is transmitted.  This allows its
   recipients to identify from which MANET interface this HELLO message
   has been received.  Each HELLO message also reports the other
   interfaces (MANET and non-MANET) of the router, which allows
   recipients to associate a set of interface addresses with a single
   neighbor.  Finally, each HELLO message also includes information from
   the Link Set of the Interface Information Base of the MANET
   interface, and from the Neighbor Information Base.  This serves to
   allow detection of bidirectional communication between two MANET
   routers and over a pair of MANET interfaces, as well as to determine
   symmetric 2-hop neighborhood information.

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
      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, broken, or changed status link.

   o  In a combination of these proactive and responsive mechanisms.

   Jittering of HELLO message generation and transmission, as described
   in Section 11.2, 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

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

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



Clausen, et al.        Expires September 10, 2009              [Page 15]

Internet-Draft                 MANET-NHDP                     March 2009


   o  For each MANET interface, within every time interval of length
      equal to the corresponding parameter REFRESH_INTERVAL, the HELLO
      messages sent MUST collectively include:

      *  All of the relevant information in the Link Set of the
         Interface Information Base of that MANET interface.

      *  All of the relevant information in the Neighbor Information
         Base of that router.

      This applies to otherwise purely responsive routers as well as to
      proactive routers.  In either case it means that all information
      appropriate to that MANET interface will have always been
      transmitted, in one or more HELLO messages, since the time
      REFRESH_INTERVAL ago.  Note that this rule applies at all times,
      not just to times at which HELLO messages are sent.  In
      considering whether to include information in a HELLO message, the
      sender MUST consider all times up to when it may send its next
      HELLO message on that MANET interface.

   o  A HELLO message MUST include a VALIDITY_TIME Message TLV, as
      specified in [timetlv], that indicates the length of time for
      which the message content is to be considered valid, and is
      therefore to be included in the receiving router's Interface
      Information Base.

   o  A periodically generated HELLO message SHOULD include an
      INTERVAL_TIME Message TLV, as specified in [timetlv], that
      indicates the current value of HELLO_INTERVAL for that MANET
      interface, i.e. the period within which a further HELLO message is
      guaranteed to be sent on that MANET interface.

   o  Additional information may be added by a protocol using this
      protocol using the TLV mechanisms described in [RFC5444].  For
      example, if multipoint relays (MPRs) are to be calculated
      similarly to as in [RFC3626] and signaled to neighbors, then this
      information may be added to HELLO messages using an Address Block
      TLV.

4.3.3.  HELLO Message Processing

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

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

   o  The Neighbor Information Base.




Clausen, et al.        Expires September 10, 2009              [Page 16]

Internet-Draft                 MANET-NHDP                     March 2009


   Specifically:

   o  The router ensures that there is a single Neighbor Tuple
      corresponding to the originator of that HELLO message.

   o  If a Link Tuple corresponding to the link on which that HELLO
      message was received exists, then the duration for which that Link
      Tuple is kept is extended, otherwise such a Link Tuple is created.
      If the HELLO message indicates that the receiving MANET interface
      has been heard, then the link is considered symmetric, or the
      duration for which that Link Tuple is kept as symmetric is
      extended.  If the HELLO message indicates that the receiving MANET
      interface is lost, then the link is no longer considered
      symmetric.  In this case one or more Lost Neighbor Tuples may be
      created.

   o  If the link on which the HELLO message is received is symmetric,
      then any symmetrically advertised neighbor addresses in the HELLO
      message are added to the 2-Hop Set for the receiving interface, or
      if already present, the duration for which the corresponding 2-Hop
      Tuples are kept are extended.

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

4.4.  Link Quality

   Some links in a MANET may be marginal, e.g. due to adverse wireless
   propagation.  In order to avoid using such marginal links, a link
   quality value is recorded with each link in the Link Set. A MANET
   router considers links for which an insufficient link quality is
   recorded to be lost.  Modifying the recorded link quality of a link
   in the Link Set is OPTIONAL.  If link quality is not to be modified
   it MUST be set to indicate an always usable quality link.  Link
   quality information is only used locally, it is not used in
   signaling, and 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
   in this section.







Clausen, et al.        Expires September 10, 2009              [Page 17]

Internet-Draft                 MANET-NHDP                     March 2009


5.1.  Interface Parameters

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

   o  Message intervals

   o  Information validity times

   o  Link quality

   o  Jitter

   These are detailed in the following sections.

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

5.1.1.  Message Intervals

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

   HELLO messages serve two principal functions:

   o  To advertise this router's interface addresses to its 1-hop
      neighbors.  The frequency of 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 of the advertisement of each such
      neighbor is regulated by the interface parameter REFRESH_INTERVAL.

   Specifically, these parameters are as follows:

   HELLO_INTERVAL  - is the maximum time between the transmission of two
      successive HELLO messages on this MANET interface.  If using
      periodic transmission of HELLO messages, these SHOULD be at a
      separation of HELLO_INTERVAL, possibly modified by jitter as
      specified in [RFC5148].







Clausen, et al.        Expires September 10, 2009              [Page 18]

Internet-Draft                 MANET-NHDP                     March 2009


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

   REFRESH_INTERVAL  - is the maximum interval between advertisements in
      a HELLO message of each 1-hop neighbor address and its status.  In
      all intervals of length REFRESH_INTERVAL, a router MUST include
      all 1-hop neighbor information that it is specified as sending in
      at least one HELLO message on this MANET interface.

   The following constraints apply to these interface parameters:

   o  HELLO_INTERVAL > 0

   o  HELLO_MIN_INTERVAL >= 0

   o  HELLO_INTERVAL >= HELLO_MIN_INTERVAL

   o  REFRESH_INTERVAL >= HELLO_INTERVAL

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

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

   For a router to employ this protocol in a purely responsive manner on
   a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
   set to a value such that a responsive HELLO message is always
   expected in a shorter period than this value.

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

5.1.2.  Information Validity Times

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







Clausen, et al.        Expires September 10, 2009              [Page 19]

Internet-Draft                 MANET-NHDP                     March 2009


   L_HOLD_TIME  - is the 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 set to zero, if accelerated information removal
      is not required.

   H_HOLD_TIME  - is used as the value in the VALIDITY_TIME Message TLV
      included in all HELLO messages on this 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 be lost then both parameters SHOULD be
      significantly greater than REFRESH_INTERVAL.

   o  H_HOLD_TIME MUST be representable as described in [timetlv].

5.1.3.  Link Quality

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

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

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

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

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

   The following constraints apply to these interface parameters:

   o  0 <= HYST_REJECT <= HYST_ACCEPT <= 1

   o  0 <= INITIAL_QUALITY <= 1.

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





Clausen, et al.        Expires September 10, 2009              [Page 20]

Internet-Draft                 MANET-NHDP                     March 2009


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

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

5.1.4.  Jitter

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

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

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

   For constraints on these interface parameters see [RFC5148].

5.2.  Router Parameters

   The two router parameters defined by this specification are in the
   category of information validity time.

5.2.1.  Information Validity Time

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

   N_HOLD_TIME  - is used as the period during which former 1-hop
      neighbor addresses are advertised as lost in HELLO messages,
      allowing recipients of these HELLO messages to accelerate removal
      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 the period for which 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.3.  Parameter Change Constraints

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





Clausen, et al.        Expires September 10, 2009              [Page 21]

Internet-Draft                 MANET-NHDP                     March 2009


   HELLO_INTERVAL

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

      *  If the HELLO_INTERVAL for a MANET interface decreases, then the
         following HELLO messages on this 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 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 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 for all relevant Link
         Tuples MUST be 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 periodic HELLO message
         schedule on this MANET interface MAY be changed.





Clausen, et al.        Expires September 10, 2009              [Page 22]

Internet-Draft                 MANET-NHDP                     March 2009


   HT_MAXJITTER

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

5.4.  Constants

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

6.  Local Information Base

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

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

   Interfaces and addresses MAY be excluded from the Local Information
   Base, and hence from HELLO messages, if they are not 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  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 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 local interface addresses.  If a router's interface
   addresses are immutable then this set is always empty and MAY be



Clausen, et al.        Expires September 10, 2009              [Page 23]

Internet-Draft                 MANET-NHDP                     March 2009


   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 Information Base

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

   A MANET interface address can be present as of both a 1-hop neighbor
   and a symmetric 2-hop neighbor.  This allows the router with this
   MANET interface address to be immediately considered as a symmetric
   2-hop neighbor if it fails to be a symmetric 1-hop neighbor.

   An element which specifies a time is considered expired if the
   current time is greater than or equal to that time.  One such element
   in most Tuples when expired indicates that the Tuple itself is
   considered expired and MUST be removed when that element so
   indicates.  Tuples which do not have such a time element are removed
   at other times as specified, for example a Neighbor 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 are, or
   recently were, 1-hop neighbors.  It consists of Link Tuples, each
   representing a single link:

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

   where:

   L_neighbor_iface_addr_list  is an unordered list of the addresses of
      the MANET interface of the 1-hop neighbor;





Clausen, et al.        Expires September 10, 2009              [Page 24]

Internet-Draft                 MANET-NHDP                     March 2009


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

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

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

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

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

   L_time  specifies when this Tuple expires and MUST be removed.

   The status of the link, as obtained through HELLO message exchange,
   and also taking link quality into account, is denoted L_status.
   L_status can take the values PENDING, HEARD, SYMMETRIC and LOST.  The
   values LOST, SYMMETRIC and HEARD are defined in Section 17.5.  The
   value PENDING is never used in a HELLO message, it is only used
   locally by a router, and any value distinct from LOST, SYMMETRIC and
   HEARD 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 symmetric 2-hop neighbor interface
   addresses, and the symmetric links to symmetric 1-hop neighbors
   through which the symmetric 2-hop neighbors can be reached.  It
   consists of 2-Hop Tuples, each representing a single interface
   address of a symmetric 2-hop neighbor, and a single MANET interface



Clausen, et al.        Expires September 10, 2009              [Page 25]

Internet-Draft                 MANET-NHDP                     March 2009


   of a symmetric 1-hop neighbor.

      (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)

   where:

   N2_neighbor_iface_addr_list  is an unordered list of the addresses of
      the MANET interface of the symmetric 1-hop neighbor from which
      this information was received;

   N2_2hop_iface_addr  is an address of an interface of a symmetric
      2-hop neighbor which has a symmetric link (using any MANET
      interface) to the indicated symmetric 1-hop neighbor;

   N2_time  specifies when this Tuple expires and MUST be removed.

8.  Neighbor Information Base

   Each router maintains a 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 interface addresses of each 1-hop
   neighbor.  It consists of Neighbor Tuples, each representing a single
   1-hop neighbor:

      (N_neighbor_iface_addr_list, N_symmetric)

   where:

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

   N_symmetric  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 Tuples expire from the routers' Link Set, i.e.
   Neighbor Tuples are not directly subject to timer-based expiration.

8.2.  Lost Neighbor Set

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



Clausen, et al.        Expires September 10, 2009              [Page 26]

Internet-Draft                 MANET-NHDP                     March 2009


      (NL_neighbor_iface_addr, NL_time)

   where:

   NL_neighbor_iface_addr  is an address of an interface of a router
      which recently was a symmetric 1-hop neighbor of this router;

   NL_time  specifies when this Tuple expires and MUST be removed.

9.  Local Information Base Changes

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

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

9.1.  Adding an Interface

   If an interface is added to the router then this is indicated by the
   addition of a Local Interface Tuple to the Local Interface Set. If
   the new interface is a MANET interface then an initially empty
   Interface Information Base MUST be created for this new MANET
   interface.  The actions in Section 9.3 MUST be taken for each address
   of this added interface.  A HELLO message MAY be sent on all MANET
   interfaces, it SHOULD be sent on the new interface if it is a MANET
   interface.  If using scheduled messages, then a message schedule MUST
   be established on a 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 and to the Neighbor Information
   Base as follows:

   1.  Identify the Local Interface Tuple that corresponds to 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
       Removed Interface Address Tuple with:

       *  IR_local_iface_addr := removed address;




Clausen, et al.        Expires September 10, 2009              [Page 27]

Internet-Draft                 MANET-NHDP                     March 2009


       *  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 a MANET interface (i.e. with
       I_manet = true) then:

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

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

   If a router removes the Local Interface Tuple that contains the
   interface address which is used to define the router's originator
   address, as defined in [RFC5444], then the router MAY change
   originator address.  If this interface address may now be used by
   another router (e.g. if the address was taken from a prefix no longer
   delegated to this router, or if the address was assigned with an
   expiration timer, and not renewed before expiration) then this router
   MUST change originator address.

   If the removed interface is the last MANET interface of the router,
   then there will be no remaining Interface Information Bases, and the
   router will longer participate 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 an Address to an Interface

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

   1.  The 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

       *  any address in the N_neighbor_iface_addr_list of any removed
          Neighbor Tuple




Clausen, et al.        Expires September 10, 2009              [Page 28]

Internet-Draft                 MANET-NHDP                     March 2009


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

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

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

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

9.4.  Removing an Address from an Interface

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

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

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

   3.  Otherwise:

       1.  Remove the removed address from this I_local_iface_addr_list.

       2.  Create a Removed Interface Address Tuple with:

           +  IR_local_iface_addr := removed address;

           +  IR_time := current time + I_HOLD_TIME.

   If a router removes the interface address that is used to define the
   router's originator address, as defined in [RFC5444], then the router
   MAY change originator address.  If this interface address may now be
   used by another router then this router MUST change originator
   address.

   After removing 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 in
   [RFC5444], which is used with the following considerations:





Clausen, et al.        Expires September 10, 2009              [Page 29]

Internet-Draft                 MANET-NHDP                     March 2009


   o  This protocol specifies one Message Type, the HELLO message.

   o  A HELLO message MAY use any combination 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 is 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 [timetlv].  These five TLV Types are
      all defined only with Type Extension = 0.  TLVs of other types,
      and of these types but without Type Extension = 0, are ignored by
      this protocol.  All references in this protocol to, for example,
      an Address Block TLV with Type = LINK_STATUS, are to be considered
      as referring to an Address Block TLV with Type = LINK_STATUS and
      Type Extension = 0.

10.1.  HELLO Messages

   A HELLO message MUST contain:

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

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

   o  An INTERVAL_TIME Message TLV as specified in [timetlv],
      representing HELLO_INTERVAL for the transmitting MANET interface.
      The options included in [timetlv] for representing zero and
      infinite times MUST NOT be used.

   A HELLO message MAY contain:

   o  Other Message TLVs.

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





Clausen, et al.        Expires September 10, 2009              [Page 30]

Internet-Draft                 MANET-NHDP                     March 2009


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
   interface address with maximum prefix length, then that address MAY
   be omitted from being included in an Address Block, provided that
   this address is included as the sending 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   |  Value  | Description                                  |
   |          |  Length |                                              |
   +----------+---------+----------------------------------------------+
   | LOCAL_IF | 1 octet | Specifies that the address is an address     |
   |          |         | associated with the 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 1-hop neighbors'
   interface addresses, each of which is associated with Address Block
   TLVs as described in Table 2.

   +--------------+---------+------------------------------------------+
   |     Name     |  Value  | Description                              |
   |              |  Length |                                          |
   +--------------+---------+------------------------------------------+
   |  LINK_STATUS | 1 octet | Specifies the 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  |
   |              |         | of the router transmitting the HELLO     |
   |              |         | message.                                 |
   +--------------+---------+------------------------------------------+

           Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition

   An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
   Value = LOST also performs the function of an Address Block TLV with
   Type = OTHER_NEIGHB and the same value.  The latter SHOULD NOT also



Clausen, et al.        Expires September 10, 2009              [Page 31]

Internet-Draft                 MANET-NHDP                     March 2009


   be included.  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 then the latter MUST be ignored, and
   SHOULD NOT be included.  See Appendix A.

   Other addresses MAY be included in Address Blocks, but MUST NOT be
   associated with any of the Address Block TLVs specified in this
   specification.

11.  HELLO Message Generation

   Each MANET interface MUST generate HELLO messages according to the
   specification in this section.  HELLO messages are generated for each
   HELLO interface independently.  HELLO message generation and
   scheduling MUST be according to the interface parameters for that
   MANET interface, and MAY be independent for each MANET interface or,
   interface parameters permitting, MANET interfaces MAY use the same
   schedule.

   If transmitting periodic HELLO messages then, following a HELLO
   message transmission on a MANET interface, another HELLO message MUST
   be transmitted on the same MANET interface after an interval not
   greater than HELLO_INTERVAL.  Two successive HELLO message
   transmissions on the same MANET interface MUST be separated by at
   least HELLO_MIN_INTERVAL, except as noted in Section 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 be included, except
   that:

   o  If the interface on which the HELLO message is to be sent has a
      single interface address with maximum prefix length then that
      interface address MAY be omitted, provided that this address is
      included as the sending address of the IP datagram in which the
      HELLO message is included.

   All such included addresses MUST be associated with an Address Block
   TLV included with Type := LOCAL_IF and Value according to the
   following:

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

   o  Otherwise, Value := OTHER_IF.




Clausen, et al.        Expires September 10, 2009              [Page 32]

Internet-Draft                 MANET-NHDP                     March 2009


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

   o  Addresses of MANET interfaces of 1-hop neighbors from the Link Set
      of the Interface Information Base for this MANET interface, other
      than those from Link Tuples with L_status = PENDING.

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

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

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

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

   1.  For each address (henceforth linked address) which is contained
       in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set
       for this MANET interface, for which L_status != PENDING, include
       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 is contained
       in an N_neighbor_iface_addr_list in a Neighbor Tuple with
       N_symmetric = true, and which has not already been included with
       an associated 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:



Clausen, et al.        Expires September 10, 2009              [Page 33]

Internet-Draft                 MANET-NHDP                     March 2009


       *  Type := OTHER_NEIGHB; AND

       *  Value := LOST.

   If any such addresses have been added since the last HELLO message
   was sent on this MANET interface, 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 on this MANET interface,
   then that address, and the indicated TLVs, MUST be included in the
   HELLO message.

   If a 1-hop neighbor address 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 a HELLO message sent on that MANET interface in every interval of
   length equal to that MANET interface's parameter REFRESH_INTERVAL.
   Address Block TLVs associated with the same address included in the
   same HELLO message MAY be applied to the same or different copies of
   that address.

11.2.  HELLO Message Transmission

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

11.2.1.  HELLO Message Jitter

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

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

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

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





Clausen, et al.        Expires September 10, 2009              [Page 34]

Internet-Draft                 MANET-NHDP                     March 2009


   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 HELLO
   message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
   message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
   be reduced by jitter, with maximum reduction HP_MAXJITTER, as
   described in [RFC5148].  In this case HP_MAXJITTER MUST NOT be
   greater than HELLO_MIN_INTERVAL.

12.  HELLO Message Processing

   On receiving a HELLO message, a router MUST first check if the
   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 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 conditions
   described in Section 13 then the indicated consequences 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 with Type = LINK_STATUS refer to a TLV with Type =
   LINK_STATUS and Type Extension = 0.

12.1.  Invalid Message

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

   o  The message has a <msg-hop-limit> field in its <msg-header> with a
      value other than one.  (Note that the message need not have a
      <msg-hop-limit> field.)

   o  The message has a <msg-hop-count> field in its <msg-header> with a
      value other than zero.  (Note that the message need not have a
      <msg-hop-count> field.)

   o  The message does not have a Message TLV with Type = VALIDITY_TIME
      in its Message TLV Block.

   o  The message has more than one Message TLV with Type =
      VALIDITY_TIME in its Message TLV Block, and these Message TLVs
      indicate different validity times, as specified by [timetlv].



Clausen, et al.        Expires September 10, 2009              [Page 35]

Internet-Draft                 MANET-NHDP                     March 2009


   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 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 (the local address) associated with an Address Block
      TLV with Type = LOCAL_IF is one of the receiving router's current
      or recently used interface addresses (i.e. the local address is
      contained in any I_local_iface_addr_list in the Local Interface
      Set or the local address = any IR_local_iface_addr in the Removed
      Interface 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 address, in the same
      or different Address Blocks) is associated with more than one
      value by one or more Address Block TLVs with Type = LINK_STATUS.

   o  The 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 an address, 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 the
   router's Information Bases.  A router MAY recognize additional
   reasons for identifying that a message is badly formed, and discard
   such messages.

12.2.  Definitions

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

   o  "validity time" is calculated from the Message TLV with Type =
      VALIDITY_TIME of the HELLO message as specified in [timetlv].
      (Note that, as specified by Section 12.1, there must be such a
      Message TLV, and if there is more than one, they must indicate the
      same validity time.)  All information in the HELLO message has the
      same validity time.

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



Clausen, et al.        Expires September 10, 2009              [Page 36]

Internet-Draft                 MANET-NHDP                     March 2009


   o  "Sending Address List" is the list of the addresses contained in
      the HELLO message with an associated Address Block TLV with Type =
      LOCAL_IF and Value = THIS_IF.  If the Sending Address List is
      otherwise empty, then the Sending Address List contains a single
      address (with maximum prefix length) equal to the sending address
      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 and Value = OTHER_IF.

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

   o  "Removed Address List" is a list of addresses created by this
      HELLO message processing which were formerly reported as local by
      the 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 initialized as empty.

12.3.  Updating the Neighbor Set

   On receiving 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 (hereafter matching Neighbor Tuples)
       where:

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

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

       1.  Create a new Neighbor Tuple with:

           +  N_neighbor_iface_addr_list := Neighbor Address List;

           +  N_symmetric := false.

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

       1.  If the matching Neighbor Tuple's N_neighbor_iface_addr_list
           != Neighbor Address List, then:




Clausen, et al.        Expires September 10, 2009              [Page 37]

Internet-Draft                 MANET-NHDP                     March 2009


           1.  For each address (henceforth removed address) which is
               contained in that N_neighbor_iface_addr_list, but is not
               contained in the Neighbor Address List:

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

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

           2.  Update the matching Neighbor Tuple by:

               -  N_neighbor_iface_addr_list := Neighbor Address List.

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

       1.  For each address (henceforth removed address) which is
           contained in the N_neighbor_iface_addr_list of any of the
           matching Neighbor Tuples:

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

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

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

           +  N_neighbor_iface_addr_list := Neighbor Address List;

           +  N_symmetric := false

12.4.  Updating the Lost Neighbor Set

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

   1.  For each address (henceforth lost address) which is contained in
       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.







Clausen, et al.        Expires September 10, 2009              [Page 38]

Internet-Draft                 MANET-NHDP                     March 2009


12.5.  Updating the Link Set

   On receiving a HELLO message, a router MUST update its Link Set for
   the MANET interface on which the HELLO message is received:

   1.  Remove all addresses in the Removed Address List from the
       L_neighbor_iface_addr_list of all Link Tuples.

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

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

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

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

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

       *  L_neighbor_iface_addr_list := empty;

       *  L_HEARD_time := EXPIRED;

       *  L_SYM_time := EXPIRED;

       *  L_quality := INITIAL_QUALITY;

       *  L_pending := INITIAL_PENDING;

       *  L_lost := false;

       *  L_time := current time + validity time.

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

       1.  If the router finds any address (henceforth receiving
           address) in the Receiving Address List in an Address Block in
           the HELLO message, then the Link Tuple is modified as
           follows:

           1.  If any receiving address in the HELLO message is
               associated with an Address Block TLV with Type =
               LINK_STATUS and with Value = HEARD or Value = SYMMETRIC
               then:



Clausen, et al.        Expires September 10, 2009              [Page 39]

Internet-Draft                 MANET-NHDP                     March 2009


               -  L_SYM_time := current time + validity time.

           2.  Otherwise if any receiving address in the HELLO message
               is associated with an Address Block TLV with Type =
               LINK_STATUS and Value = LOST then:

               1.  if L_SYM_time has not expired, then:

                   1.  L_SYM_time := EXPIRED.

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

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

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

       1.  For each address (henceforth 2-hop address) in an Address
           Block of the HELLO 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




Clausen, et al.        Expires September 10, 2009              [Page 40]

Internet-Draft                 MANET-NHDP                     March 2009


           +  2-hop address != any IR_local_iface_addr

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

               -  Type = LINK_STATUS and Value = SYMMETRIC; OR

               -  Type = OTHER_NEIGHB and Value = SYMMETRIC,

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

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

               -  N2_2hop_iface_addr = 2-hop address.

               then create a 2-Hop Neighbor Tuple with:

               -  N2_2hop_iface_addr := 2-hop address.

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

               -  N2_neighbor_iface_addr_list := Sending Address List;

               -  N2_time := current time + validity time.

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

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

               -  Type = OTHER_NEIGHB and Value =o LOST;

               then remove all 2-Hop Tuples with:

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

               -  N2_2hop_iface_addr = 2-hop address.

13.  Other Information Base Changes

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



Clausen, et al.        Expires September 10, 2009              [Page 41]

Internet-Draft                 MANET-NHDP                     March 2009


   Events which cause changes in the Information Bases are:

   o  A Link Tuple's L_status changes to symmetric.

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

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

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

   o  Link quality changes, as specified in Section 14.

   If a Link Tuple is removed, or if L_status changes from symmetric and
   L_HEARD_time expires, then Section 13.2 MUST be performed before
   Section 13.3 for that Link Tuple.

   A router MAY report updated information in response to any of these
   changes in HELLO message(s), subject to the constraints in
   Section 11.

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

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

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

13.1.  Link Tuple Symmetric

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

   o  L_status := SYMMETRIC;

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

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

       *  N_symmetric := true.





Clausen, et al.        Expires September 10, 2009              [Page 42]

Internet-Draft                 MANET-NHDP                     March 2009


   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  the Link Tuple is removed;

   then:

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

       *  N2_neighbor_iface_addr_list contains one or more addresses in
          L_neighbor_iface_addr_list;

       are removed.

   2.  For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
       L_neighbor_iface_addr_list:

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

           +  L_neighbor_iface_addr_list is contained in
              N_neighbor_iface_addr_list; AND

           +  L_status = SYMMETRIC;

           then modify the Neighbor Tuple by:

           1.  N_symmetric := false.

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

               -  NL_neighbor_iface_addr := neighbor address;

               -  NL_time := current time + N_HOLD_TIME.

13.3.  Link Tuple Heard Timeout

   If, for any Link Tuple:





Clausen, et al.        Expires September 10, 2009              [Page 43]

Internet-Draft                 MANET-NHDP                     March 2009


   o  L_HEARD_time expires; OR

   o  the Link Tuple is removed;

   then:

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

       *  L_neighbor_iface_addr_list is contained in
          N_neighbor_iface_addr_list; AND

       *  L_HEARD_time is not expired;

       then remove the Neighbor Tuple.

14.  Link Quality

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

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

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

14.1.  Deployment Without Link Quality

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

   o  INITIAL_PENDING := false;

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







Clausen, et al.        Expires September 10, 2009              [Page 44]

Internet-Draft                 MANET-NHDP                     March 2009


14.2.  Basic Principles of Link Quality

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

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

   The basic principles of link quality usage are as follows:

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

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

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

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

   o  Once L_quality >= HYST_ACCEPT, the router sets L_pending := false,
      indicating that the link can be advertised.

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

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

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







Clausen, et al.        Expires September 10, 2009              [Page 45]

Internet-Draft                 MANET-NHDP                     March 2009


14.3.  When Link Quality Changes

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

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

       1.  L_pending := false.

       2.  L_lost := false.

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

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

   2.  If L_status != PENDING, and L_quality < HYST_REJECT then the
       corresponding Link Tuple is modified by:

       1.  If L_lost = false, then:

           +  L_lost := true

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

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

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

14.4.  Updating Link Quality

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

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

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



Clausen, et al.        Expires September 10, 2009              [Page 46]

Internet-Draft                 MANET-NHDP                     March 2009


      packets on the link were received, or may use a "leaky integrator"
      tracking packet reception and loss.

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

15.  Proposed Values for Parameters and Constants

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

15.1.  Message Interval Interface Parameters

   o  HELLO_INTERVAL := 2 seconds

   o  HELLO_MIN_INTERVAL := HELLO_INTERVAL/4

   o  REFRESH_INTERVAL := HELLO_INTERVAL

15.2.  Information Validity Time Interface Parameters

   o  H_HOLD_TIME := 3 x REFRESH_INTERVAL

   o  L_HOLD_TIME := H_HOLD_TIME

15.3.  Information Validity Time Router Parameters

   o  N_HOLD_TIME := L_HOLD_TIME

   o  I_HOLD_TIME := N_HOLD_TIME

15.4.  Link Quality Interface Parameters

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

   o  HYST_ACCEPT := 1

   o  HYST_REJECT := 0





Clausen, et al.        Expires September 10, 2009              [Page 47]

Internet-Draft                 MANET-NHDP                     March 2009


   o  INITIAL_QUALITY := 1

   o  INITIAL_PENDING := false

15.5.  Jitter Interface Parameters

   o  HP_MAXJITTER := HELLO_INTERVAL/4

   o  HT_MAXJITTER := HP_MAXJITTER

15.6.  Constants

   o  C := 1/1024 second

16.  Security Considerations

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

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

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

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

16.1.  Invalid HELLO messages

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



Clausen, et al.        Expires September 10, 2009              [Page 48]

Internet-Draft                 MANET-NHDP                     March 2009


   LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.

   A router may provide false information about its own identity:

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

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

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

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

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

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

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

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

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

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



Clausen, et al.        Expires September 10, 2009              [Page 49]

Internet-Draft                 MANET-NHDP                     March 2009


         neighbor.

16.2.  Authentication, Integrity and Confidentiality Suggestions

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

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

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

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

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

17.  IANA Considerations

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

17.1.  Expert Review: Evaluation Guidelines

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

17.2.  Message Types

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






Clausen, et al.        Expires September 10, 2009              [Page 50]

Internet-Draft                 MANET-NHDP                     March 2009


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

                     Table 3: Message Type assignment

17.3.  Message-Type-specific TLV Type Registries

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

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

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

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

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

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

17.4.  Address Block TLV Types

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






Clausen, et al.        Expires September 10, 2009              [Page 51]

Internet-Draft                 MANET-NHDP                     March 2009


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

           Table 6: Address Block TLV Type assignment: LOCAL_IF

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

          Table 7: Address Block TLV Type assignment: LINK_STATUS

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

         Table 8: Address Block TLV Type assignment: OTHER_NEIGHB

17.5.  LINK_STATUS and OTHER_NEIGHB Values

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

   o  THIS_IF := 0

   o  OTHER_IF := 1

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



Clausen, et al.        Expires September 10, 2009              [Page 52]

Internet-Draft                 MANET-NHDP                     March 2009


   following:

   o  LOST := 0

   o  SYMMETRIC := 1

   o  HEARD := 2

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

   o  LOST := 0

   o  SYMMETRIC := 1

18.  Contributors

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

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

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

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

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

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

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

19.  Acknowledgements

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

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews and comments on the
   specification and its components (listed alphabetically): Alan Cullen
   (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
   Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
   and the entire IETF MANET working group.

20.  References





Clausen, et al.        Expires September 10, 2009              [Page 53]

Internet-Draft                 MANET-NHDP                     March 2009


20.1.  Normative References

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

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

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

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

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

20.2.  Informative References

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

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

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

Appendix A.  Address Block TLV Combinations

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



Clausen, et al.        Expires September 10, 2009              [Page 54]

Internet-Draft                 MANET-NHDP                     March 2009


   Cells labeled with "Yes" indicate the possible combinations which are
   generated by the algorithm in Section 11.  Cells labeled with "No"
   indicate combinations not generated by the algorithm in Section 11,
   but which are correctly parsed and interpreted by the algorithm in
   Section 12.  The cell labeled with "No*" is actually inconsistent, it
   is handled by ignoring the Address Block TLV with Type =
   OTHER_NEIGHB.

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

          Table 9: LINK_STATUS and OTHER_NEIGHB TLV combinations

Appendix B.  Constraints

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

   In each Local Interface Tuple:

   o  I_local_iface_addr_list MUST NOT be empty.

   o  I_local_iface_addr_list MUST NOT contain any duplicated addresses.

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

   In each Removed Interface Address Tuple:




Clausen, et al.        Expires September 10, 2009              [Page 55]

Internet-Draft                 MANET-NHDP                     March 2009


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

   o  IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
      other Removed Interface Address Tuple.

   In each Link Tuple:

   o  L_neighbor_iface_addr_list MUST NOT be empty.

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

   o  L_neighbor_iface_addr_list MUST NOT contain any duplicated
      addresses.

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

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

   o  L_HEARD_time MUST NOT be greater than L_time.

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

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

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

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

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

   In each Neighbor Tuple:

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

   o  N_neighbor_iface_addr_list MUST NOT contain any duplicated
      addresses.





Clausen, et al.        Expires September 10, 2009              [Page 56]

Internet-Draft                 MANET-NHDP                     March 2009


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

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

      *  L_neighbor_iface_addr_list contained in
         N_neighbor_iface_addr_list; AND

      *  L_status = SYMMETRIC.

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

      *  L_neighbor_iface_addr_list contained in
         N_neighbor_iface_addr_list.

      All such Link Tuples MUST NOT have L_status = SYMMETRIC.  At least
      one such Link Tuple MUST have L_HEARD_time not expired.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list
      of any Local Interface Tuple or the IR_local_iface_addr of any
      Removed Interface Address Tuple.

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

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

   In each 2-Hop Tuple:

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

      *  L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND

      *  L_status = SYMMETRIC.

   o  N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of
      any Local Interface Tuple or the IR_local_iface_addr of any
      Removed Interface Address Tuple.

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



Clausen, et al.        Expires September 10, 2009              [Page 57]

Internet-Draft                 MANET-NHDP                     March 2009


      N2_neighbor_iface_addr_list.

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

Appendix C.  HELLO Message Example

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

   The message has full Message Header (four bit flags field value is
   15).  Its four bit Message Address Length field has value 3 and hence
   addresses in the message have length four octets, here being IPv4
   addresses.  The message is as transmitted with a hop limit of 1 and a
   hop count of 0.  The overall message length is 49 octets.

   The message contains a Message TLV Block with content length 8 octets
   containing two Message TLVs, of types VALIDITY_TIME and
   INTERVAL_TIME.  Each uses a Message TLV with flags octet value 16,
   indicating that each has a value.  Each has a value length of 1
   octet; the values included (0x64 and 0x58) are time codes
   representing the default values of parameters H_HOLD_TIME and
   HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
   default value of constant C (1/1024 second).

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

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








Clausen, et al.        Expires September 10, 2009              [Page 58]

Internet-Draft                 MANET-NHDP                     March 2009


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

   Note that this example is for illustrative purposes.  The essential
   information can be conveyed, more efficiently (assuming that the
   local interface address will be supplied by IP, and that the
   INTERVAL_TIME TLV is not needed) by the 29 octets:

















Clausen, et al.        Expires September 10, 2009              [Page 59]

Internet-Draft                 MANET-NHDP                     March 2009


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     HELLO     |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mid 1     |     Mid 2     |     Mid 3     |     Mid 4     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |0 0 0 1 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

Appendix D.  Flow and Congestion Control

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

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

   A router MUST ensure that two successive HELLO messages sent on the
   same MANET interface are separated by at least HELLO_MIN_INTERVAL.
   (If using jitter then this may be reduced to a mean minimum value of
   HELLO_MIN_INTERVAL - HP_MAXJITTER/2.)  Thus, this puts an upper bound
   on the control traffic generated by each router in the network
   employing this protocol.

Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/




Clausen, et al.        Expires September 10, 2009              [Page 60]

Internet-Draft                 MANET-NHDP                     March 2009


   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

































Clausen, et al.        Expires September 10, 2009              [Page 61]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/