tech-invite   World Map     

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

RFC 6130

 
 
 

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

Part 2 of 4, p. 18 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
5.  Protocol Parameters and Constants

   The parameters and constants used in this specification are described
   in this section.

5.1.  Protocol and Port Numbers

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

5.2.  Multicast Address

   This protocol specifies HELLO messages, which are included in packets
   as defined by [RFC5444].  These packets may be locally transmitted
   using the link-local multicast address "LL-MANET-Routers", as
   specified in [RFC5498].

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

Top      Up      ToC       Page 19 
   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.3.1.  Message Intervals

   HELLO messages serve two principal functions:

   o  To advertise network addresses of this router's interface 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:
      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].

   HELLO_MIN_INTERVAL:
      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:
      The maximum interval between advertisements, in a HELLO message on
      this MANET interface, of each 1-hop neighbor network address and
      its status.  In all intervals of length REFRESH_INTERVAL, a router
      MUST include each 1-hop neighbor network address and its status in
      at least one HELLO message on this MANET interface.  (This may be
      in the same or in different HELLO messages.)

Top      Up      ToC       Page 20 
   REFRESH_INTERVAL thus represents the frequency at which a piece of
   information, as received in HELLO messages, can be expected to be
   refreshed.  Thus, the REFRESH_INTERVAL is used as a basis for
   determining when such information expires in receiving routers (see
   Section 5.3.2).  HELLO_INTERVAL represents the frequency of HELLO
   message emissions.  Logically, HELLO_INTERVAL cannot be greater than
   the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a
   timely manner.

   HELLO messages can, however, be sent with a higher frequency.  A
   possible use for sending HELLO messages at such a higher frequency
   includes sending partial HELLO messages (e.g., accommodating
   constraints on packet sizes from the underlying medium) refreshing
   only part of the information in each HELLO message.  Another use is
   for a router to send "empty HELLO messages", advertising its own
   presence frequently in smaller HELLO messages (e.g., in case HELLO
   message exchange success rates are used for link quality estimation,
   or to enable rapid detection by new routers in the neighborhood) in
   between HELLO messages refreshing neighbor information in other
   routers.

   The following constraints apply to these interface parameters:

   o  HELLO_INTERVAL > 0

   o  HELLO_MIN_INTERVAL >= 0

   o  HELLO_INTERVAL >= HELLO_MIN_INTERVAL

   o  REFRESH_INTERVAL >= HELLO_INTERVAL

   o  If an INTERVAL_TIME Message TLV as defined in [RFC5497] is
      included in a HELLO message, then HELLO_INTERVAL MUST be
      representable as described in [RFC5497].

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

   In the absence of any changes to the local neighborhood, a router
   will send a HELLO message on a MANET interface after an (possibly
   jittered) interval of length HELLO_INTERVAL.  For a router to employ
   this protocol in a purely responsive manner on a MANET interface,
   i.e., for the router to only send HELLO messages on that MANET
   interface as a response to external events, HELLO_INTERVAL (and hence
   also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such
   that a responsive HELLO message is always expected with a shorter
   period than this value.

Top      Up      ToC       Page 21 
   If a router has more than one MANET interface, then, even if the
   router configures different values of HELLO_INTERVAL on each MANET
   interface, the router SHOULD configure the same value of
   HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
   messages may be sent.  (This ensures that changes observed on one
   MANET interface are reported on other MANET interfaces, so that 1-hop
   neighbors connected to the latter can maintain up-to-date 2-hop
   neighborhood information.)

5.3.2.  Information Validity Times

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

   L_HOLD_TIME:
      The period of advertisement, on this MANET interface, of former
      1-hop neighbor network 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:
      Used as the Value in the VALIDITY_TIME Message TLV included in all
      HELLO messages on this MANET interface.  It is then used by each
      router receiving such a HELLO message to indicate the validity of
      the information taken from that HELLO message and recorded in the
      receiving router's Information Bases.

   Note that as each item of neighbor information is included in HELLO
   messages within an interval of length REFRESH_INTERVAL, constraints
   on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL.

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

Top      Up      ToC       Page 22 
5.3.3.  Link Quality

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

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

   HYST_REJECT:
      The link quality threshold below which a link becomes unusable, if
      it was not already so.

   INITIAL_QUALITY:
      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.

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

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

5.3.4.  Jitter

   If jitter, as defined in [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].

Top      Up      ToC       Page 23 
5.4.  Router Parameters

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

5.4.1.  Information Validity Time

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

   N_HOLD_TIME:
      Used as the period during which former 1-hop neighbor network
      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:
      The period for which a recently used local interface network
      address is recorded.

   The following constraints apply to these router parameters:

   o  N_HOLD_TIME >= 0

   o  I_HOLD_TIME >= 0

5.5.  Parameter Change Constraints

   If protocol parameters are changed dynamically, the constraints in
   this section apply.

   HELLO_INTERVAL

      o  If the HELLO_INTERVAL for a MANET interface increases, then the
         next HELLO message on this MANET interface MUST be generated
         according to the previous, shorter, HELLO_INTERVAL.  A number
         of subsequent HELLO messages MAY be generated according to the
         previous, shorter, HELLO_INTERVAL (but MUST include times
         according to current parameters).  This ensures that "promises"
         as to timely transmission of a future HELLO message are kept
         until these previous promises have expired.

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

Top      Up      ToC       Page 24 
   REFRESH_INTERVAL

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

      o  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 for the specification of
         REFRESH_INTERVAL is satisfied from the time of change.

   HYST_ACCEPT and HYST_REJECT

      o  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

      o  If L_HOLD_TIME changes, then the expiry times of all relevant
         Link Tuples MUST be changed.

   N_HOLD_TIME

      o  If N_HOLD_TIME changes, then the expiry times of all relevant
         Lost Neighbor Tuples MUST be changed.

   HP_MAXJITTER

      o  If HP_MAXJITTER changes, then the periodic HELLO message
         schedule on this MANET interface MAY be changed.

   HT_MAXJITTER

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

5.6.  Constants

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

6.  Local Information Base

   A router maintains a Local Information Base that records information
   about its interfaces (MANET and non-MANET).  Each interface of a
   router MUST be identified by at least one network address.  Such

Top      Up      ToC       Page 25 
   network addresses MAY be specific to that interface, or MAY in some
   circumstances be used by more than one interface as specified below.

   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.

   It is not necessary to include all addresses of an interface in the
   Local Information Base, and hence in HELLO messages.  However, any
   address that may be the source address of an IP datagram sent from
   that interface MUST be included (and at least one address MUST be
   included).  A protocol using this specification MAY add additional
   requirements to these, e.g., that any address that may be the
   destination address of an IP datagram is also included.

   The addresses assigned to an interface are "owned" by the router, and
   MUST NOT be used by any other router as an interface address.  If an
   address has a prefix length and represents a range of addresses, this
   applies to all addresses in that range (i.e., such ranges MUST NOT
   overlap).

   The addresses assigned to different interfaces on the same router
   MUST be distinct (hence, network address ranges MUST NOT overlap)
   except that:

   o  The same address MAY be assigned to any number of non-MANET
      interfaces as well as to one (or more if the following condition
      also applies) MANET interface.

   o  The same address MAY be assigned to two (or more if each pair
      satisfies this condition) MANET interfaces if those two MANET
      interfaces cannot communicate to, from, or one to and one from any
      other MANET interface of another router.

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 network
      addresses of this interface.

Top      Up      ToC       Page 26 
      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 network addresses
   that were recently used as local interface network addresses.  If a
   router's interface network addresses are immutable, then the Removed
   Interface Address Set is always empty and MAY be omitted.  It
   consists of Removed Interface Address Tuples, one per network
   address:

      (IR_local_iface_addr, IR_time)

   where:

      IR_local_iface_addr is a recently used network address of an
      interface of this router.

      IR_time specifies when this Tuple expires and MUST be removed.

7.  Interface Information Bases

   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 that can be reached in two
   hops using those links as the first hop.  Each Interface Information
   Base includes a Link Set and a 2-Hop Set.

   A network address of a symmetric 2-hop neighbor can also be present
   as the network address of a 1-hop neighbor.  This allows the router
   using this network address to be immediately considered as a
   symmetric 2-hop neighbor if it fails to be a symmetric 1-hop
   neighbor.

   An element that specifies a time is considered expired if the current
   time is greater than or equal to that time.  One such element,
   present in most Tuples, indicates, when expired, that the Tuple
   itself is considered expired and MUST be removed.  Tuples that 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.

Top      Up      ToC       Page 27 
7.1.  Link Set

   An interface's Link Set records links from other routers that 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 network
      addresses of the MANET interface of the 1-hop neighbor;

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

      L_SYM_time is the time up to 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 low 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 using link quality, 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 18.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;

Top      Up      ToC       Page 28 
   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

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

      (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)

   where:

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

      N2_2hop_addr is a network address of a symmetric 2-hop neighbor
      that 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 network addresses of current and recently symmetric
   1-hop neighbors.

8.1.  Neighbor Set

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

      (N_neighbor_addr_list, N_symmetric)

Top      Up      ToC       Page 29 
   where:

      N_neighbor_addr_list is an unordered list of the network 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 network addresses of routers
   that recently were symmetric 1-hop neighbors but that are now
   advertised as lost.  It consists of Lost Neighbor Tuples, each
   representing a single such network address:

      (NL_neighbor_addr, NL_time)

   where:

      NL_neighbor_addr is a network address of a router that 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 be updated in response to changes in
   the router's local interface configuration.  These MAY also change
   the Interface Information Base and the Neighbor Information Base.  If
   any changes to the latter Information Bases satisfy any of the
   conditions described in Section 13, then those changes MUST be
   applied immediately, unless noted otherwise below.

   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 network
   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

Top      Up      ToC       Page 30 
   MANET interface.  If using scheduled messages, then a message
   schedule MUST be established on the new MANET interface.

9.2.  Removing an Interface

   If an interface is removed from the router, then this MUST result in
   changes to the Local Information Base 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 network address (henceforth removed address) in the
       I_local_iface_addr_list of that Local Interface Tuple, if that
       network address is not in the I_local_iface_addr_list of any
       other Local Interface Tuple, then create a Removed Interface
       Address Tuple with:

       o  IR_local_iface_addr := removed address;

       o  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 network addresses
           in its N_neighbor_addr_list are contained in any
           L_neighbor_iface_addr_list in any remaining Link Tuple are
           removed.

   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 no 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 a Network Address to an Interface

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

Top      Up      ToC       Page 31 
   1.  Remove any Removed Interface Address Tuple whose
       IR_local_iface_addr is the added network address.

   2.  Remove any Neighbor Tuples whose N_neighbor_addr_list contains a
       network address that overlaps the added network address.

   3.  Remove any Link Tuples, in any Link Set, for which either:

       o  L_neighbor_iface_addr_list contains any network address in the
          N_neighbor_addr_list of any removed Neighbor Tuple; OR

       o  L_neighbor_iface_addr_list contains a network address that
          overlaps the added network address.

       Apply Section 13.2 but not Section 13.3.

   4.  Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps
       the added network address.

   5.  Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added
       network address.

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

   These changes, other than to the appropriate I_local_iface_addr_list,
   are made in order to maintain consistency of the Information Bases.
   Specifically, these changes remove any record of any use of this
   network address by routers in the 1-hop neighborhood or in the
   symmetric 2-hop neighborhood of this router.

9.4.  Removing a Network Address from an Interface

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

   1.  Identify the Local Interface Tuple that corresponds to the
       removed address.

   2.  If this is the only network address of that interface (the only
       network 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.

Top      Up      ToC       Page 32 
       2.  If the removed address is not in the I_local_iface_addr_list
           of any other Local Interface Tuple, then create a Removed
           Interface Address Tuple with:

           o  IR_local_iface_addr := removed address;

           o  IR_time := current time + I_HOLD_TIME.

   After removing the network 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:

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

   o  A HELLO message MAY use any combination of Message Header options
      specified in [RFC5444].

   o  HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if
      present, MUST have the value 1.

   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 that is not in conformance with
      [RFC5444] MUST be discarded without being processed.  A HELLO
      message can also be discarded without being processed for other
      reasons, see Section 12.1.

   o  This protocol specifies three Address Block TLVs.  It also uses
      two Message TLVs defined in [RFC5497].  These five TLV Types are
      all defined only with Type Extension = 0.  TLVs of other types,
      and of these types but without Type Extension = 0, are ignored by
      this protocol.  All references in this specification 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  Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497],
      representing H_HOLD_TIME for the transmitting MANET interface.

Top      Up      ToC       Page 33 
      The options included in [RFC5497] for representing zero and
      infinite times MUST NOT be used.

   A HELLO message transmitted due to a periodic timer SHOULD contain,
   and otherwise (i.e., transmitted for any other reason, in particular
   in response to any Information Base changes) MAY contain:

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

   A HELLO message MAY contain:

   o  Other Message TLVs.

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

10.1.1.  Address Blocks

   All network addresses in a router's Local Interface Set (i.e., in any
   I_local_iface_addr_list) MUST be represented as address objects (see
   [RFC5444]), and included in the Address Blocks in all generated HELLO
   messages, with the following permitted exception:

   o  If the MANET interface on which the HELLO message is to be sent
      has a single address with maximum prefix length (i.e., /32 for
      IPv4, /128 for IPv6), then that address MAY be omitted from being
      included in any Address Block, provided that this address is
      included as the sending address of the IP datagram in which the
      HELLO message is included.

   All network addresses of the router's interfaces included in any
   Address Block(s) 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 network address is        |
   |          |         | associated with the MANET interface on which |
   |          |         | the message was sent (THIS_IF) or another    |
   |          |         | interface of the sending router (OTHER_IF).  |
   +----------+---------+----------------------------------------------+

                     Table 1: LOCAL_IF TLV Definition

Top      Up      ToC       Page 34 
   Address Blocks MAY contain current or recently lost 1-hop neighbors'
   network addresses, represented as address objects (see [RFC5444]),
   each of which is associated with one or both 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 network address and to the |
   |              |         | MANET interface over which the HELLO     |
   |              |         | message is transmitted (LOST, SYMMETRIC, |
   |              |         | or HEARD).                               |
   | OTHER_NEIGHB | 1 octet | Specifies that the network address is    |
   |              |         | (SYMMETRIC) or was (LOST) of a MANET     |
   |              |         | 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.  Including the latter
   associated with the same address object is discouraged for efficiency
   reasons.  If an Address Block TLV with Type = LINK_STATUS and Value =
   SYMMETRIC is combined with an Address Block TLV with Type =
   OTHER_NEIGHB and Value = LOST associated with the same address
   object, then the latter MUST be ignored and SHOULD NOT be included.
   See Appendix A.

   Other network addresses MAY be represented as address objects (see
   [RFC5444]) and 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
   MANET 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.

Top      Up      ToC       Page 35 
   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 network addresses in any I_local_iface_addr_list MUST be
   included, represented as address objects (see [RFC5444]), except
   that:

   o  If the interface on which the HELLO message is to be sent has a
      single address with maximum prefix length (i.e., /32 for IPv4,
      /128 for IPv6), then that address MAY 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 address objects MUST be associated with an Address
   Block TLV with Type := LOCAL_IF and Value according to the following:

   o  If the address object represents a network address of the sending
      MANET interface, then Value := THIS_IF.

   o  Otherwise, Value := OTHER_IF.

   If such a network address is included in more than one
   I_local_iface_addr_list, then, for efficiency reasons, it is
   encouraged that the corresponding address object is associated with
   only one Value using an Address Block TLV with Type := LOCAL_IF; this
   MUST be Value := THIS_IF if the address object represents a network
   address of the sending MANET interface.

   The following network addresses of current or former 1-hop neighbors
   MAY be represented as address objects (see [RFC5444]) and included in
   any HELLO message, respecting the parameter REFRESH_INTERVAL for each
   association for that MANET interface, and according to the following:

   o  Network addresses of MANET interfaces of 1-hop neighbors from the
      Link Set of the Interface Information Base for this MANET
      interface (i.e., from an L_neighbor_iface_addr_list), other than
      those from Link Tuples with L_status = PENDING.

Top      Up      ToC       Page 36 
   o  Other network addresses of symmetric 1-hop neighbors from the
      Neighbor Set of this router's Neighbor Information Base (i.e.,
      from an N_neighbor_addr_list).

   o  Network 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 (i.e., from an L_neighbor_iface_addr_list with L_status
      = LOST).

   o  Other network addresses of previously symmetric 1-hop neighbors
      from the Lost Neighbor Set of this router's Neighbor Information
      Base (i.e., from an NL_neighbor_addr).

   Each such address object (see [RFC5444]) MUST be associated with one
   or more appropriate Address Block TLVs.  Specifically:

   1.  For each address object (henceforth linked address) that
       represents a network address 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:

       o  Type := LINK_STATUS; AND

       o  Value := L_status.

   2.  For each address object (henceforth neighbor address) that
       represents a network address contained in an N_neighbor_addr_list
       in a Neighbor Tuple with N_symmetric = true and that has not
       already been included with an associated Address Block TLV with
       Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor
       network address with an associated Address Block TLV with:

       o  Type := OTHER_NEIGHB; AND

       o  Value := SYMMETRIC.

   3.  For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
       lost address) has not already been represented as an address
       object and included, include lost address with an associated
       Address Block TLV with:

       o  Type := OTHER_NEIGHB; AND

       o  Value := LOST.

Top      Up      ToC       Page 37 
   If any such network addresses have been added to these Information
   Bases 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 network address) have changed since that network
   address was last reported on this MANET interface, then that network
   address, and the indicated TLVs, SHOULD be included in the HELLO
   message.

   If the address object (see [RFC5444]) representing a network address
   of a 1-hop neighbor is specified with more than one associated
   Address Block TLV, then these Address Block TLVs MAY be independently
   included or excluded from each HELLO message.  Each such Address
   Block TLV MUST be included associated with the address object
   representation of that network 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 object included in the same HELLO
   message MAY be applied to the same or different copies of that
   address object.

   An implementation of this protocol MAY limit the information included
   in each HELLO message, for example, to accommodate smaller MTU sizes.
   HELLO messages remain constrained by the above requirements, in
   particular, that all local interface information MUST be included in
   all HELLO messages, and that all neighbor information MUST be sent
   within each interval of length REFRESH_INTERVAL.  This neighbor
   information MAY, however, be sent in the same or in different HELLO
   messages.

11.2.  HELLO Message Transmission

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

11.2.1.  HELLO Message Jitter

   HELLO messages MAY be sent using periodic message generation or
   externally triggered message generation.  If using data link and
   physical layers that 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.

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

   o  For periodic message generation: HP_MAXJITTER.

   o  For externally triggered message generation: HT_MAXJITTER.

   When HELLO message generation is delayed in order that 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.



(page 38 continued on part 3)

Next RFC Part