tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6130

 Errata 
Proposed STD
Pages: 88
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MANET

Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Part 1 of 4, p. 1 to 18
None       Next RFC Part

Updated by:    7183    7188    7466


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        T. Clausen
Request for Comments: 6130                      LIX, Ecole Polytechnique
Category: Standards Track                                    C. Dearlove
ISSN: 2070-1721                                          BAE Systems ATC
                                                                 J. Dean
                                               Naval Research Laboratory
                                                              April 2011


  Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Abstract

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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6130.

Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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

Page 2 
   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.

Table of Contents

  1. Introduction .....................................................4
      1.1. Motivation .................................................5
   2. Terminology .....................................................6
   3. Applicability Statement .........................................9
   4. Protocol Overview and Functioning ..............................10
      4.1. Routers and Interfaces ....................................11
      4.2. Information Base Overview .................................12
           4.2.1. Local Information Base .............................13
           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 ..............................16
           4.3.3. HELLO Message Processing ...........................17
      4.4. Link Quality ..............................................17
   5. Protocol Parameters and Constants ..............................18
      5.1. Protocol and Port Numbers .................................18
      5.2. Multicast Address .........................................18
      5.3. Interface Parameters ......................................18
           5.3.1. Message Intervals ..................................19
           5.3.2. Information Validity Times .........................21
           5.3.3. Link Quality .......................................22
           5.3.4. Jitter .............................................22
      5.4. Router Parameters .........................................23
           5.4.1. Information Validity Time ..........................23
      5.5. Parameter Change Constraints ..............................23
      5.6. Constants .................................................24
   6. Local Information Base .........................................24
      6.1. Local Interface Set .......................................25
      6.2. Removed Interface Address Set .............................26
   7. Interface Information Bases ....................................26
      7.1. Link Set ..................................................27
      7.2. 2-Hop Set .................................................28
   8. Neighbor Information Base ......................................28
      8.1. Neighbor Set ..............................................28
      8.2. Lost Neighbor Set .........................................29
   9. Local Information Base Changes .................................29

Top      ToC       Page 3 
      9.1. Adding an Interface .......................................29
      9.2. Removing an Interface .....................................30
      9.3. Adding a Network Address to an Interface ..................30
      9.4. Removing a Network Address from an Interface ..............31
   10. Packets and Messages ..........................................32
      10.1. HELLO Messages ...........................................32
           10.1.1. Address Blocks ....................................33
   11. HELLO Message Generation ......................................34
      11.1. HELLO Message Specification ..............................35
      11.2. HELLO Message Transmission ...............................37
           11.2.1. HELLO Message Jitter ..............................37
   12. HELLO Message Processing ......................................38
      12.1. Invalid Message ..........................................38
      12.2. Definitions ..............................................40
      12.3. Updating the Neighbor Set ................................41
      12.4. Updating the Lost Neighbor Set ...........................42
      12.5. Updating the Link Sets ...................................42
      12.6. Updating the 2-Hop Set ...................................44
   13. Other Information Base Changes ................................45
      13.1. Link Tuple Symmetric .....................................46
      13.2. Link Tuple Not Symmetric .................................47
      13.3. Link Tuple Heard Timeout .................................48
   14. Link Quality ..................................................48
      14.1. Deployment without Link Quality ..........................49
      14.2. Basic Principles of Link Quality .........................49
      14.3. When Link Quality Changes ................................50
      14.4. Updating Link Quality ....................................51
   15. Proposed Values for Parameters and Constants ..................51
      15.1. Message Interval Interface Parameters ....................51
      15.2. Information Validity Time Interface Parameters ...........51
      15.3. Information Validity Time Router Parameters ..............52
      15.4. Link Quality Interface Parameters ........................52
      15.5. Jitter Interface Parameters ..............................52
      15.6. Constants ................................................52
   16. Usage with Other Protocols ....................................52
   17. Security Considerations .......................................54
      17.1. Invalid HELLO Messages ...................................56
      17.2. Authentication, Integrity, and Confidentiality
            Suggestions ..............................................57
   18. IANA Considerations ...........................................57
      18.1. Expert Review: Evaluation Guidelines .....................58
      18.2. Message Types ............................................58
      18.3. Message-Type-Specific TLV Type Registries ................58
      18.4. Address Block TLV Types ..................................59
      18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60
   19. Contributors ..................................................61
   20. Acknowledgments ...............................................61
   21. References ....................................................62

Top      ToC       Page 4 
      21.1. Normative References .....................................62
      21.2. Informative References ...................................62
   Appendix A. Address Block TLV Combinations ........................63
   Appendix B. Constraints ...........................................64
   Appendix C. HELLO Message Example .................................66
   Appendix D. Flow and Congestion Control ...........................69
   Appendix E. Interval and Timer Illustrations ......................70
      E.1.  HELLO Message Generation Timing ..........................70
      E.2.  HELLO Message Processing Timing ..........................76
      E.3.  Other HELLO Message Timing ...............................77
   Appendix F.  Topology Pictures ....................................79
      F.1.  Example 1: Standard Single Interface Topology ............79
      F.2.  Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80
      F.3.  Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81
      F.4.  Example 4: Dual Addressed Interfaces .....................81
      F.5.  Example 5: Dual Interface on 2-Hop Neighbor ..............82
      F.6.  Example 6: Dual interface on 1-Hop Neighbor ..............82
      F.7.  Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83
      F.8.  Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84
      F.9.  Example 9: Dual Interface on All Routers .................85
      F.10. Example 10: Dual Addressed Dual Interfaces on All
                        Routers ......................................86
      F.11. Example 11: Single Addressed Dual Interface Locally ......87

1.  Introduction

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

   1-hop neighborhood information is recorded for use by MANET routing
   protocols to determine direct (1-hop) connectivity to neighboring
   routers. 2-hop symmetric neighborhood information is recorded so as
   to enable MANET routing protocols to employ flooding reduction
   techniques, e.g., to select reduced relay sets for efficient network-
   wide traffic dissemination.

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

Top      ToC       Page 5 
   This protocol makes no assumptions about the underlying link layer,
   other than support of local broadcast or multicast for communication
   to 1-hop neighbor routers.  Link-layer information may be used if
   available and applicable.

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

1.1.  Motivation

   MANETs differ from more traditional wired and infrastructure-based
   wireless networks due to their envisioned applicability over more
   challenging communication channels (e.g., wireless, lossy, broadcast
   channels with moderate and shared bandwidth, hidden and exposed
   terminals, and interference from other network devices and the
   environment) and in more challenging topological conditions (e.g.,
   rapid and unpredictable mobility, dynamic and non-predetermined
   network membership).

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

   Each router in a MANET may use more than one communication channel.
   In particular, between the same pair of routers, more than one
   distinct communication channel may exist, each with different
   properties.  This may, for example, be the case where MANET routers
   are equipped with multiple distinct wireless interfaces, operating at
   different frequencies.

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

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

Top      ToC       Page 6 
   such as of the order of seconds, requiring MANET routing protocols to
   act rapidly to ensure suitable convergence properties.

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

   The neighborhood discovery protocol specified in this document
   provides continued tracking of neighborhood changes, link bi-
   directionality, 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", "TLV", "address", "address prefix", and
   "address object" are to be interpreted as described therein.

   Additionally, this document uses the following terminology:

   Network Address:
      An address plus an associated prefix length.  This may be an
      address with an associated maximum prefix length or an address
      prefix including a prefix length.  A network address thus
      represents a range of addresses.

   Router:
      A MANET router that implements this neighborhood discovery
      protocol.

   Interface:
      A router's attachment to a communications medium.  An interface is
      assigned one or more addresses.

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

Top      ToC       Page 7 
   Heard:
      A MANET interface of router X is considered heard on a MANET
      interface of a router Y if the latter can receive control
      messages, according to this specification, from the former.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Furthermore, this document uses the following notational conventions:

   X contains y, or y is contained in X
      An unordered list membership operator.  X is an unordered list and
      y is an element.  "X contains y" or "y is contained in X" returns
      true if the unordered list X includes the element y, and returns
      false otherwise.

   X contains Y, or Y is contained in X
      An unordered list inclusion operator.  X and Y are both unordered
      lists.  "X contains Y" or "Y is contained in X" returns true if
      the unordered list X contains all elements y which are contained
      in Y, and returns false otherwise.

   A overlaps B
      If A and B are network addresses, and the range of addresses
      represented by A and the range of addresses represented by B both
      contain at least one common address.  (This is only possible if
      one range is a sub-range of the other.)

Top      ToC       Page 9 
   a := b
      An assignment operator, whereby the left side (a) is assigned the
      value of the right side (b). a and b may be values, network
      addresses, or unordered lists (they must be of the same type).

   c = d
      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, network 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 c contains d and d contains c (i.e.,
      they contain the same set of elements, regardless of the order in
      which they are recorded in the lists).  If c and d are network
      addresses, they are considered equal only if both addresses and
      prefix lengths are equal (i.e., they represent the same).

   e != f
      A comparison operator, returning not (e = f), i.e., returning true
      where (e = f) would have returned false, and returning false where
      (e = f) would have returned true.

3.  Applicability Statement

   This protocol:

   o  Is applicable to networks, especially wireless networks, in which
      unknown neighbors can be reached by local broadcast or multicast
      packets.

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

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

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

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

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

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

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

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

4.  Protocol Overview and Functioning

   The objective of this protocol is, for each router:

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

   o  To find the interface network addresses of the router's symmetric
      2-hop neighbors.

   o  To record this information in Information Bases and thus make this
      information available to other protocols that use this
      neighborhood discovery protocol.

   o  To be available for use by other protocols, which MAY extend the
      information in these Information Bases, including adding new Sets
      to Information Bases, new elements to protocol Tuples and new TLVs
      to be included in outgoing HELLO messages and processed when in
      incoming HELLO messages.

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

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

   o  Discovers links from neighboring routers.

   o  Performs bi-directionality checks on the discovered links.

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

   This specification defines, in turn:

   o  Parameters and constants used by the protocol.  Parameters used by
      this protocol may, where appropriate, be specific to a given MANET
      interface or to a MANET router.  This protocol allows all
      parameters to be changed dynamically, and to be set independently
      for each MANET router or MANET interface, as appropriate.

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

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

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

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

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

4.1.  Routers and Interfaces

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

   Each MANET interface:

   o  Is configured with one or more network addresses.  Each address in
      the range of addresses represented by that network address MUST
      satisfy the following properties:

      o  It MUST be unique to this router, i.e., it MUST NOT be assigned
         to any interface of any other router.

      o  If assigned to other MANET interfaces, on the same router,
         these MANET interfaces MUST be isolated, i.e., addresses may
         only be assigned to different interfaces on the same router if
         no MANET interface on another router can communicate with both.
         For example, interfaces using distinct radio "channels" MAY be
         assigned the same address.

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

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

   o  Generates and processes HELLO messages.

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

   o  A Local Information Base, containing the network 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 protocol state using Information Bases,
   described in the following sections.  Each Information Base consists
   of a number of Protocol Sets.  Each Protocol Set contains a number of
   Protocol Tuples.

   An implementation of this protocol MAY maintain this information in
   the indicated form, or in any other organization that offers access
   to this information.  In particular, note that it is not necessary to
   remove Protocol Tuples from Protocol Sets at the exact time
   indicated, only to behave as if the Protocol Tuples were removed at
   that time.

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

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

Top      ToC       Page 13 
4.2.1.  Local Information Base

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

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

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

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

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

4.2.2.  Interface Information Bases

   Each router maintains, for each of its MANET interfaces, an Interface
   Information Base, which contains 1-hop neighborhood and symmetric
   2-hop neighborhood information collected from this MANET interface,
   specifically:

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

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

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

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

4.2.3.  Neighbor Information Base

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

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

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

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

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

4.3.  Signaling Overview

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

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

   Each HELLO message:

   o  Identifies, as far as is required, the MANET interface for which
      it is generated and transmitted; this allows recipients of that
      HELLO message to identify that MANET interface from among those it
      may hear.

   o  Reports the network addresses of other interfaces (MANET and non-
      MANET) of the router; this allows recipients of that HELLO message
      to associate a set of network addresses with a single 1-hop
      neighbor.

   o  Includes 1-hop neighbor information from the Information Bases;
      this allows detection of local symmetric links, and symmetric
      2-hop neighbors.

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

4.3.1.  HELLO Message Generation

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

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

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

   o  In a combination of these proactive and responsive mechanisms.

   Jittering of HELLO message generation and transmission SHOULD be used
   as described in Section 11.2, unless the medium access control
   mechanism in use prevents any simultaneous transmissions by
   potentially interfering routers.

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

4.3.2.  HELLO Message Content

   The content of a HELLO message MUST satisfy the following:

   o  A HELLO message MUST contain all of the network addresses in the
      Local Interface Set of the router on which the HELLO message is
      being generated.  This includes:

      o  At least one network address of each MANET interface of the
         router.

      o  Network addresses that include all source addresses of any IP
         datagrams sent by the router on any MANET interface.

      o  All other network addresses of the router that are to be made
         known to any other router for any reason.

   o  For each MANET interface, within every time interval equal to the
      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
      collectively include all of the relevant information in the
      corresponding Link Set and the Neighbor Information Base.  Note
      that when determining whether to include information in a HELLO
      message, the sender MUST consider all times up to the latest time
      when it may send its next HELLO message on this MANET interface.

   o  For each MANET interface, within every time interval equal to the
      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
      collectively include all of the relevant information in the
      corresponding Link Set and the Neighbor Information Base.

   o  When determining whether to include a given piece of neighbor
      information in a HELLO message, it is not sufficient to consider
      whether that information has been sent in the interval of length
      REFRESH_INTERVAL up to the current time.  Instead, the router MUST
      consider the interval of length REFRESH_INTERVAL that will end at
      the latest possible time at which the next HELLO message will be
      sent on this MANET interface.  (Normally, this will be
      HELLO_INTERVAL past the current time, but MAY be earlier if this
      router elects to divide its neighbor information among more than
      one HELLO message in order to reduce the size of its HELLO
      messages.)  All neighbor information MUST be sent in this
      interval, i.e., the router MUST ensure that this HELLO message
      includes all neighbor information that has not already been
      included in any HELLO messages sent since the start of this

Top      ToC       Page 17 
      interval (normally, the current time - (REFRESH_INTERVAL -
      HELLO_INTERVAL)).

   o  A HELLO message MUST include exactly one VALIDITY_TIME Message
      TLV, as specified in [RFC5497], that indicates the length of time
      for which the message content is 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 exactly one
      INTERVAL_TIME Message TLV, as specified in [RFC5497], 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.

4.3.3.  HELLO Message Processing

   HELLO messages received by a router are used to update the Interface
   Information Base for the MANET interface over which that HELLO
   message was received, as well as the Neighbor Information Base of the
   router.  Specifically:

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

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

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

   The processing defined in this specification handles any unexpected
   and erroneous information in a HELLO message, maintaining the
   constraints on Information Base contents 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 in each Link Tuple.  A MANET router
   considers links for which an insufficient link quality is recorded as
   lost.  Modifying the recorded link quality in a Link Tuple is

Top      ToC       Page 18 
   OPTIONAL.  If link quality is not to be modified, it MUST be set to
   indicate an always usable quality link.

   Note that link quality is a "link admittance" mechanism, allowing a
   router to determine that a given link is too unstable to even
   consider for use.  It is specifically not a link metric nor is it a
   substitute for one.

   Link quality information is only used locally and is not used in
   signaling.  Routers may interoperate whether they are using the same,
   different, or no link quality information.  Link quality information
   is thus not equivalent to a link metric.

   Link quality information is defined in this specification as a
   normalized, dimensionless value in the interval zero to one,
   inclusive, where the greater the value, the better the link quality.
   See Section 14 for further details.



(page 18 continued on part 2)

Next RFC Part