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 3 of 4, p. 38 to 62
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 38 
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 and, if so, discard the message without further
   processing.  Otherwise, for each received and valid HELLO message,
   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 in that section 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 address length as specified in the Message Header is not equal
      to the length of the addresses used by this router.

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

Top      Up      ToC       Page 39 
   o  The message has a <msg-hop-count> field in its Message Header with
      a value other than zero.  (Note that the message does not need to
      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.

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

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

   o  Any address object (including different address objects
      representing the same network 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 object (henceforth local address) associated with an
      Address Block TLV with Type = LOCAL_IF represents one of the
      receiving router's current or recently used network addresses
      (i.e., local address overlaps any network address in any
      I_local_iface_addr_list in the Local Interface Set or 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  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 object (including different copies of an address
      object, in the same or different Address Blocks) is associated
      with an Address Block TLV with Type = LOCAL_IF and with an Address
      Block TLV with Type = LINK_STATUS.

   o  Any address object (including different copies of an address
      object, in the same or different Address Blocks) is associated
      with an Address Block TLV with Type = LOCAL_IF and with an Address
      Block TLV with Type = OTHER_NEIGHB.

Top      Up      ToC       Page 40 
   o  Any address object (including different copies of an address
      object, 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  Any address object (including different copies of an address
      object, 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.

   A router MAY recognize additional reasons for identifying that a
   message is badly formed and therefore invalid for processing, e.g.,
   to allow a security protocol as suggested in Section 17 to perform
   verification of HELLO message signatures and prevent processing of
   unverifiable HELLO messages by this protocol.

   An invalid message MUST be silently discarded, without updating the
   router's Information Bases.

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 [RFC5497].
      (Note that, as specified by Section 12.1, there must be exactly
      one such Message TLV in the HELLO message.)  All information in
      the HELLO message used by this specification 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

   o  "Sending Address List" is an unordered list of network addresses
      of the MANET interface over which the HELLO message was sent,
      i.e., is an unordered list of the network addresses represented by
      address objects 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 network address with maximum prefix
      length (i.e., /32 for IPv4, /128 for IPv6) with an address equal
      to the sending address of the IP datagram in which the HELLO
      message was included.

   o  "Neighbor Address List" is an unordered list of all the network
      addresses of all the interfaces of the router that generated the
      HELLO message, i.e., is the Sending Address List, plus the network

Top      Up      ToC       Page 41 
      addresses represented by address objects 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 network addresses created by
      this HELLO message processing that were formerly reported as local
      by the router originating the HELLO message but that 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 network addresses that 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 (henceforth matching Neighbor Tuples)
       where N_neighbor_addr_list contains any network address that
       overlaps with any network address in the Neighbor Address List.

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

       1.  Create a new Neighbor Tuple with:

           o  N_neighbor_addr_list := Neighbor Address List;

           o  N_symmetric := false.

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

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

           1.  For each network address (henceforth removed address)
               that is contained in that N_neighbor_addr_list but that
               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.

Top      Up      ToC       Page 42 
           2.  Update the matching Neighbor Tuple by:

               o  N_neighbor_addr_list := Neighbor Address List.

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

       1.  For each network address (henceforth removed address) that is
           contained in the N_neighbor_addr_list of any of the matching
           Neighbor Tuples but is not contained in the Neighbor Address
           List:

           1.  Add removed address to the Removed Address List.

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

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

           o  N_neighbor_addr_list := Neighbor Address List;

           o  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 network address (henceforth lost address) that is
       contained in the Lost Address List, if no Lost Neighbor Tuple
       with NL_neighbor_addr = lost address exists, then add a Lost
       Neighbor Tuple with:

       o  NL_neighbor_addr := lost address;

       o  NL_time := current time + N_HOLD_TIME.

12.5.  Updating the Link Sets

   On receiving a HELLO message, a router MUST update its Link Sets:

   1.  Remove all network 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.

Top      Up      ToC       Page 43 
   The router MUST then update its Link Set for the MANET interface on
   which the HELLO message is received:

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

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

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

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

       o  L_neighbor_iface_addr_list := empty;

       o  L_HEARD_time := EXPIRED;

       o  L_SYM_time := EXPIRED;

       o  L_quality := INITIAL_QUALITY;

       o  L_pending := INITIAL_PENDING;

       o  L_lost := false;

       o  L_time := current time + validity time.

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

       1.  If the router finds any network 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:

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

Top      Up      ToC       Page 44 
                   1.  L_SYM_time := EXPIRED.

                   2.  if L_status = HEARD, then:

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

           o  L_time := max(L_time, L_HEARD_time).

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

           o  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 network 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 network address (henceforth 2-hop address) in an
           Address Block of the HELLO message, where:

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

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

           o  a 2-hop address != any IR_local_iface_addr

           perform the following processing:

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

               o  Type = LINK_STATUS and Value = SYMMETRIC; OR

Top      Up      ToC       Page 45 
               o  Type = OTHER_NEIGHB and Value = SYMMETRIC,

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

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

               o  N2_2hop_addr = 2-hop address,

               then create a 2-Hop Neighbor Tuple with:

               o  N2_2hop_addr := 2-hop address.

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

               o  N2_neighbor_iface_addr_list := Sending Address List;

               o  N2_time := current time + validity time.

           2.  Otherwise, if a 2-hop address has an Address Block TLV
               with:

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

               o  Type = OTHER_NEIGHB and Value = LOST;

               then remove all 2-Hop Tuples with:

               o  N2_neighbor_iface_addr_list containing one or more
                  network addresses in the Sending Address List; AND

               o  N2_2hop_addr = 2-hop address.

13.  Other Information Base Changes

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

   Events that cause changes in the Information Bases are:

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

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

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

   o  Local interface network address changes.  In this case, the
      actions specified in Section 9 are performed.

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

   If a Link Tuple is removed, or if L_status changes from SYMMETRIC and
   L_HEARD_time expires, then the actions specified in Section 13.2 MUST
   be performed before the actions specified in Section 13.3 are
   performed 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 that 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 that does not have L_status = SYMMETRIC:

   o  L_status changes to SYMMETRIC;

   then:

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

       o  N_symmetric := true.

Top      Up      ToC       Page 47 
   2.  Remove all Lost Neighbor Tuples whose NL_neighbor_addr is
       contained in that N_neighbor_addr_list.

   This includes any newly created Link Tuples whose status is
   immediately updated such that L_status = SYMMETRIC.  (Note that in
   this specification, all Link Tuples are created such that their
   L_status is not SYMMETRIC, but a Link Tuple may be immediately
   updated by subsequent processing of the same HELLO message that
   caused the creation of the Link Tuple such that the Link Tuple's
   L_status changes to SYMMETRIC.)

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:

       o  N2_neighbor_iface_addr_list contains one or more network
          addresses in L_neighbor_iface_addr_list;

       are removed.

   2.  For the Neighbor Tuple whose N_neighbor_addr_list contains
       L_neighbor_iface_addr_list:

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

           o  L_neighbor_iface_addr_list is contained in
              N_neighbor_addr_list; AND

           o  L_status = SYMMETRIC;

           then modify the Neighbor Tuple by:

           1.  N_symmetric := false.

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

               o  NL_neighbor_addr := neighbor address;

Top      Up      ToC       Page 48 
               o  NL_time := current time + N_HOLD_TIME.

13.3.  Link Tuple Heard Timeout

   If, for any Link Tuple:

   o  L_HEARD_time expires; OR

   o  the Link Tuple is removed;

   then:

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

       o  L_neighbor_iface_addr_list is contained in
          N_neighbor_addr_list; AND

       o  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.
   As such, it is a "link admission" mechanism.

   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.  Link
   quality information is specified as a normalized, dimensionless
   figure in the interval zero to one, inclusive, a higher value
   indicating a better link quality.

   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.  Sections 14.3 and 14.4 detail link quality
   functioning.

Top      Up      ToC       Page 49 
14.1.  Deployment without Link Quality

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

   o  INITIAL_PENDING := false;

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

14.2.  Basic Principles of Link Quality

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

   The use of two thresholds implements link hysteresis, whereby a link
   that 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 overly 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:

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

      o  Otherwise, the link is advertised when L_quality >=
         HYST_REJECT.

      A link that 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.

Top      Up      ToC       Page 50 
   o  A link that has an acceptable quality may be advertised as HEARD,
      SYMMETRIC or LOST according to the exchange of HELLO messages.

   In order that these principles can all hold, a router MUST NOT
   define:

   o  INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR

   o  INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.

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:

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

           o  L_lost := true;

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

   As a result of this processing, the L_STATUS of a Link Tuple may
   change.  In this case, the processing actions corresponding to this
   change, as specified 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.)

Top      Up      ToC       Page 51 
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 acknowledgment reception and loss information.

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

   o  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion in HELLO
      messages of a Message TLV with Type := INTERVAL_TIME, as defined
      in [RFC5497]), 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 that 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

Top      Up      ToC       Page 52 
15.3.  Information Validity Time Router Parameters

   o  N_HOLD_TIME := L_HOLD_TIME

   o  I_HOLD_TIME := N_HOLD_TIME

15.4.  Link Quality Interface Parameters

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

   o  HYST_ACCEPT := 1

   o  HYST_REJECT := 0

   o  INITIAL_QUALITY := 1

   o  INITIAL_PENDING := false

15.5.  Jitter Interface Parameters

   o  HP_MAXJITTER := HELLO_INTERVAL/4

   o  HT_MAXJITTER := HP_MAXJITTER

15.6.  Constants

   o  C := 1/1024 second

16.  Usage with Other Protocols

   Other protocols, such as MANET routing protocols, that 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 17, to add a
      TLV containing a cryptographic signature to the message, or be to

Top      Up      ToC       Page 53 
      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
      discarding it prior to processing by this protocol.  This may, for
      example, allow a security protocol as suggested in Section 17 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 that has added information, such as relay
      selection information by way of inclusion of appropriate TLVs,
      access to such information after appropriate updates have 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.

   Address objects in HELLO messages are processed according to their
   associated Address Block TLVs.  All such address objects are to be
   processed according to this specification are associated with Address
   Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS (and
   type extension zero).  Address objects not associated with an Address
   Block TLV of any of these Types are therefore not processed by the
   protocol described in this specification.

   A protocol, such as a MANET routing protocol, interacting with this
   protocol may need to add information to HELLO messages.  This may be
   in the form of associating TLVs (of Type other than LOCAL_IF,
   OTHER_NEIGHB, or LINK_STATUS) to address objects already included by
   this specification.

   A protocol, such as a MANET routing protocol, interacting with this
   protocol may also add information to HELLO messages by inserting
   address objects not already included by this specification.  Such
   address objects are in the following called "inserted addresses".
   These inserted addresses may added to Address Blocks already present
   by virtue of the HELLO message generation in this specification, or
   may appear in new Address Blocks.  In both cases, the following MUST
   be observed:

   o  An inserted address MUST NOT be associated with an Address Block
      TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS.  Consequently,
      the processing in this specification will ignore such address
      objects.

Top      Up      ToC       Page 54 
   o  Each inserted address MUST be associated with an Address Block
      TLV, to be defined by the specification of the protocol inserting
      the address object.  In this way, all addresses present in a HELLO
      message are associated with an Address Block TLV defining their
      semantics.

   Informally speaking, Address Block TLVs define the semantics of
   address objects in an Address Block.  If an address object in an
   Address Block does not have any Address Block TLVs associated, that
   address object has no semantics.  Consequently, all protocols using
   the protocol defined in this specification MUST respect the
   following:

   o  An address object in an Address Block, which is not associated
      with any Address Block TLV, MUST be silently ignored; the mere
      presence of an address object without an associated Address Block
      TLV in a HELLO message MUST NOT cause any processing.

   A protocol interacting with this protocol MAY also add an originator
   address to HELLO messages, as specified in [RFC5444].  Such an
   originator address MUST be unique to the originating router, it MAY
   be a local interface address of the router.  It SHOULD be used
   consistently, but SHOULD NOT be constrained in any other way.

   Strict adherence to these points will enable unambiguous coexistence
   of future "extensions" to HELLO messages.

   In some cases, a protocol interacting with the protocol defined in
   this specification, may need to recognize which HELLO messages to
   process and which HELLO messages to discard.  It is the
   responsibility of that protocol to ensure that such messages are
   suitably identifiable, e.g., through inclusion of a Message TLV or
   through recognizing an administrative configuration (such as address
   ranges).  Note that such a protocol interacting with this protocol
   MAY specify such interaction by recognizing an additional reason for
   discarding a message.  As suggested in Section 17 this might, for
   example, be a security protocol discarding a message that does not
   carry a Message TLV containing a cryptographic signature.

17.  Security Considerations

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

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

   If a router for some reason, whether malice or malfunction, transmits
   invalid HELLO messages, incorrect information may be recorded in
   other routers' Information Bases.  This protocol specification does,
   however, prevent inconsistent information from being included in the
   Information Bases through the specified processing, which maintains
   the constraints in Appendix B.  The exact consequence of information
   inexactness depends on the use of these Information Bases, and SHOULD
   therefore be reflected in the specification of protocols that use
   information provided by this neighborhood discovery protocol.

   This section, therefore, firstly outlines the ways in which correctly
   formed, but still invalid, HELLO messages may appear, in
   Section 17.1.

   Injection of invalid HELLO messages into a network may be prevented
   in a number of ways.  If, for example, a network is deployed in a
   site to which access is strictly regulated, so that physical access
   and proximity to the network is prevented, then further security
   mechanisms to protect against malicious routers injecting invalid
   HELLO messages may not be required.  Similarly, if the link layer
   over which the network is formed provides appropriate
   confidentiality, authentication, and integrity, then this may, for a
   given deployment, suffice to appropriately protect against disclosure
   of information to an eavesdropper, and against a malicious router
   injecting invalid HELLO messages.  In the latter case, the link layer
   would discard frames that fail the link-layer checks, without
   attempting to deliver such frames to IP.  Finally, certain usage may
   be of a nature where disruption of service is of no consequence, or
   at least not of sufficient consequence to warrant deployment of
   additional security mechanisms.

   A further point to stress, and which follows from the discussions
   above is, that it will not be the case that "one size security fits
   all".  Different deployments may have different requirements.  For
   example, in a deployment of a low-value sensor network,
   authentication using a simple message authentication code and shared
   symmetric keys may suffice, while anything beyond that may require
   too many computational resources to be viable.  Conversely, in, for
   example, a community network, verifying not only that the originator
   of a HELLO message "has the right key" but also the precise identity
   of the originator may be required to be proved, and computational
   resources may be available to make such a requirement feasible.

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

17.1.  Invalid HELLO Messages

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

   A router may provide false information about its own identity:

      o  The HELLO message may contain address objects with an
         associated LOCAL_IF Address Block TLV that do not correspond to
         addresses of interfaces of the router transmitting the HELLO
         message.

      o  The HELLO message may omit network 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 network address of the
         MANET interface over which the HELLO message is transmitted, if
         that is the case).

      o  The HELLO message may incorrectly specify the LOCAL_IF Address
         Block TLV Value associated with one or more local interface
         network 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:

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

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

Top      Up      ToC       Page 57 
      o  A present OTHER_NEIGHB Address Block TLV may, incorrectly,
         identify a network address as being of a router that is or was
         in the sending router's symmetric 1-hop neighborhood.

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

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

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

17.2.  Authentication, Integrity, and Confidentiality Suggestions

   The security suggestions in [RFC5444] regarding inclusion of a
   cryptographic signature in a Message TLV or a Packet TLV can be
   applied to this protocol.  Failure to verify either form of
   cryptographic signature should cause a HELLO message to be rejected
   without being processed.

   The following simplification of the suggestions for end-to-end
   authentication for integrity in [RFC5444] may be applied to HELLO
   messages:

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

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

18.  IANA Considerations

   This specification defines one Message Type, which has been allocated
   from the "Message Types" registry of [RFC5444], and three Address
   Block TLV Types, which have been allocated from the "Address Block
   TLV Types" registry of [RFC5444].

Top      Up      ToC       Page 58 
18.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].

18.2.  Message Types

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

                    +------+-------------------------+
                    | Type | Description             |
                    +------+-------------------------+
                    |   0  | HELLO : Local signaling |
                    +------+-------------------------+

                     Table 3: Message Type Assignment

18.3.  Message-Type-Specific TLV Type Registries

   IANA has created a registry for Message-Type-specific Message TLVs
   for HELLO messages, in accordance with Section 6.2.1 of [RFC5444],
   and with initial assignments and allocation policies as specified in
   Table 4.

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

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

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

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

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

Top      Up      ToC       Page 59 
18.4.  Address Block TLV Types

   This specification defines three Address Block TLV Types, which have
   been allocated from the "Address Block TLV Types" namespace defined
   in [RFC5444].  IANA has made allocations in the 0-127 range for these
   types.  Three new type extension registries have been created, with
   assignments as specified in Tables 6, 7, and 8.  Specifications of
   these Address Block TLVs are in Section 10.1.1, with Value Constants
   defined in Section 18.5.

   +----------+------+-----------+------------------------+------------+
   |   Name   | Type |    Type   | Description            | Allocation |
   |          |      | extension |                        | policy     |
   +----------+------+-----------+------------------------+------------+
   | LOCAL_IF |   2  |     0     | Specifies that the     |            |
   |          |      |           | network address is     |            |
   |          |      |           | associated with this   |            |
   |          |      |           | local interface of the |            |
   |          |      |           | sending router         |            |
   |          |      |           | (THIS_IF = 0) or       |            |
   |          |      |           | another local          |            |
   |          |      |           | interface of the       |            |
   |          |      |           | sending router         |            |
   |          |      |           | (OTHER_IF = 1)         |            |
   | LOCAL_IF |   2  |   1-255   | Unassigned             | Expert     |
   |          |      |           |                        | Review     |
   +----------+------+-----------+------------------------+------------+

           Table 6: Address Block TLV Type Assignment: LOCAL_IF

   +-------------+------+-----------+---------------------+------------+
   |     Name    | Type |    Type   | Description         | Allocation |
   |             |      | extension |                     | policy     |
   +-------------+------+-----------+---------------------+------------+
   | LINK_STATUS |   3  |     0     | Specifies the       |            |
   |             |      |           | status of the link  |            |
   |             |      |           | from the indicated  |            |
   |             |      |           | network address     |            |
   |             |      |           | (LOST = 0,          |            |
   |             |      |           | SYMMETRIC = 1, or   |            |
   |             |      |           | HEARD = 2)          |            |
   | LINK_STATUS |   3  |   1-255   | Unassigned          | Expert     |
   |             |      |           |                     | Review     |
   +-------------+------+-----------+---------------------+------------+

          Table 7: Address Block TLV Type Assignment: LINK_STATUS

Top      Up      ToC       Page 60 
   +--------------+------+-----------+--------------------+------------+
   |     Name     | Type |    Type   | Description        | Allocation |
   |              |      | extension |                    | policy     |
   +--------------+------+-----------+--------------------+------------+
   | OTHER_NEIGHB |   4  |     0     | Specifies the      |            |
   |              |      |           | status of the      |            |
   |              |      |           | relationship with  |            |
   |              |      |           | the router that    |            |
   |              |      |           | uses the indicated |            |
   |              |      |           | network address on |            |
   |              |      |           | one or more        |            |
   |              |      |           | interfaces (LOST = |            |
   |              |      |           | 0, or SYMMETRIC =  |            |
   |              |      |           | 1)                 |            |
   | OTHER_NEIGHB |   4  |   1-255   | Unassigned         | Expert     |
   |              |      |           |                    | Review     |
   +--------------+------+-----------+--------------------+------------+

         Table 8: Address Block TLV Type Assignment: OTHER_NEIGHB

18.5.  LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values

   Note: This information is recorded here for clarity and for use
   elsewhere in this specification.  The information required by IANA is
   included in the descriptions of the Address Block TLVs allocated in
   Section 18.4.

   The Values that the LOCAL_IF Address Block TLV can use are the
   following:

   o  THIS_IF := 0

   o  OTHER_IF := 1

   The Values that the LINK_STATUS Address Block TLV can use are the
   following:

   o  LOST := 0

   o  SYMMETRIC := 1

   o  HEARD := 2

   The Values that the OTHER_NEIGHB Address Block TLV can use are the
   following:

   o  LOST := 0

Top      Up      ToC       Page 61 
   o  SYMMETRIC := 1

19.  Contributors

   This specification is the result of the joint efforts of the
   following contributors from the OLSRv2 Design Team, listed
   alphabetically:

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

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

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

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

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

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

20.  Acknowledgments

   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.

Top      Up      ToC       Page 62 
21.  References

21.1.  Normative References

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

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

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

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              March 2009.

   [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
              (MANET) Protocols", RFC 5498, March 2009.

21.2.  Informative References

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

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

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


Next RFC Part