tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7181

 
 
 

The Optimized Link State Routing Protocol Version 2

Part 3 of 5, p. 34 to 56
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 34 
10.  Topology Information Base

   The Topology Information Base, defined for each router by this
   specification, stores information received in TC messages in the
   Advertising Remote Router Set, the Router Topology Set, the Routable
   Address Topology Set, and the Attached Network Set.

   Additionally, a Routing Set is maintained, derived from the
   information recorded in the Local Information Base, the Interface
   Information Bases, the Neighbor Information Base, and the rest of the
   Topology Information Base.

10.1.  Advertising Remote Router Set

   A router's Advertising Remote Router Set records information
   describing each remote router in the network that transmits TC
   messages, allowing outdated TC messages to be recognized and
   discarded.  It consists of Advertising Remote Router Tuples:

      (AR_orig_addr, AR_seq_number, AR_time)

   where:

      AR_orig_addr is the originator address of a received TC message,
      note that this does not include a prefix length;

      AR_seq_number is the greatest ANSN in any TC message received that
      originated from the router with originator address AR_orig_addr
      (i.e., that contributed to the information contained in this
      Tuple);

      AR_time is the time at which this Tuple expires and MUST be
      removed.

Top      Up      ToC       Page 35 
10.2.  Router Topology Set

   A router's Topology Set records topology information about the links
   between routers in the MANET.  It consists of Router Topology Tuples:

      (TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric,
       TR_time)

   where:

      TR_from_orig_addr is the originator address of a router that can
      reach the router with originator address TR_to_orig_addr in one
      hop (note that this does not include a prefix length);

      TR_to_orig_addr is the originator address of a router that can be
      reached by the router with originator address TR_from_orig_addr in
      one hop (note that this does not include a prefix length);

      TR_seq_number is the greatest ANSN in any TC message received that
      originated from the router with originator address
      TR_from_orig_addr (i.e., that contributed to the information
      contained in this Tuple);

      TR_metric is the neighbor metric from the router with originator
      address TR_from_orig_addr to the router with originator address
      TR_to_orig_addr;

      TR_time specifies the time at which this Tuple expires and MUST be
      removed.

10.3.  Routable Address Topology Set

   A router's Routable Address Topology Set records topology information
   about the routable addresses within the MANET, including via which
   routers they may be reached.  It consists of Routable Address
   Topology Tuples:

      (TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric,
       TA_time)

   where:

      TA_from_orig_addr is the originator address of a router that can
      reach the router with routable address TA_dest_addr in one hop
      (note that this does not include a prefix length);

Top      Up      ToC       Page 36 
      TA_dest_addr is a routable address of a router that can be reached
      by the router with originator address TA_from_orig_addr in one
      hop;

      TA_seq_number is the greatest ANSN in any TC message received that
      originated from the router with originator address
      TA_from_orig_addr (i.e., that contributed to the information
      contained in this Tuple);

      TA_metric is the neighbor metric from the router with originator
      address TA_from_orig_addr to the router with OLSRv2 interface
      address TA_dest_addr;

      TA_time specifies the time at which this Tuple expires and MUST be
      removed.

10.4.  Attached Network Set

   A router's Attached Network Set records information about networks
   (which may be outside the MANET) attached to other routers and their
   routable addresses.  It consists of Attached Network Tuples:

      (AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric,
       AN_time)

   where:

      AN_orig_addr is the originator address of a router that can act as
      gateway to the network with network address AN_net_addr (note that
      this does not include a prefix length);

      AN_net_addr is the network address of an attached network that may
      be reached via the router with originator address AN_orig_addr;

      AN_seq_number is the greatest ANSN in any TC message received that
      originated from the router with originator address AN_orig_addr
      (i.e., that contributed to the information contained in this
      Tuple);

      AN_dist is the number of hops to the network with network address
      AN_net_addr from the router with originator address AN_orig_addr;

      AN_metric is the metric of the link from the router with
      originator address AN_orig_addr to the attached network with
      address AN_net_addr;

      AN_time specifies the time at which this Tuple expires and MUST be
      removed.

Top      Up      ToC       Page 37 
10.5.  Routing Set

   A router's Routing Set records the first hop along a selected path to
   each destination for which any such path is known.  It consists of
   Routing Tuples:

      (R_dest_addr, R_next_iface_addr, R_local_iface_addr, R_dist,
       R_metric)

   where:

      R_dest_addr is the network address of the destination, either the
      network address of an interface of a destination router or the
      network address of an attached network;

      R_next_iface_addr is the network address of the "next hop" on the
      selected path to the destination;

      R_local_iface_addr is an address of the local interface over which
      an IP packet MUST be sent to reach the destination by the selected
      path.

      R_dist is the number of hops on the selected path to the
      destination;

      R_metric is the metric of the route to the destination with
      address R_dest_addr.

   The Routing Set for a router is derived from the contents of other
   Protocol Sets of the router (the Link Sets, the Neighbor Set, the
   Router Topology Set, the Routable Address Topology Set, the Attached
   Network Set, and OPTIONAL use of the 2-Hop Sets).  The Routing Set is
   updated (Routing Tuples added or removed, or the complete Routing Set
   recalculated) when routing paths are calculated, based on changes to
   these other Protocol Sets.  Routing Tuples are not subject to timer-
   based expiration.

11.  Received Message Information Base

   The Received Message Information Base, defined by this specification,
   records information required to ensure that a message is processed at
   most once and is forwarded at most once per OLSRv2 interface of a
   router, using MPR flooding.  Messages are recorded using their
   "signature", consisting of their type, originator address, and
   message sequence number.

Top      Up      ToC       Page 38 
11.1.  Received Set

   A router has a Received Set per OLSRv2 interface.  Each Received Set
   records the signatures of messages that have been received over that
   OLSRv2 interface.  Each consists of Received Tuples:

      (RX_type, RX_orig_addr, RX_seq_number, RX_time)

   where:

      RX_type is the received Message Type;

      RX_orig_addr is the originator address of the received message
      (note that this does not include a prefix length);

      RX_seq_number is the message sequence number of the received
      message;

      RX_time specifies the time at which this Tuple expires and MUST be
      removed.

11.2.  Processed Set

   A router has a single Processed Set that records signatures of
   messages that have been processed by the router.  It consists of
   Processed Tuples:

      (P_type, P_orig_addr, P_seq_number, P_time)

   where:

      P_type is the processed Message Type;

      P_orig_addr is the originator address of the processed message
      (note that this does not include a prefix length);

      P_seq_number is the message sequence number of the processed
      message;

      P_time specifies the time at which this Tuple expires and MUST be
      removed.

Top      Up      ToC       Page 39 
11.3.  Forwarded Set

   A router has a single Forwarded Set that records signatures of
   messages that have been forwarded by the router.  It consists of
   Forwarded Tuples:

      (F_type, F_orig_addr, F_seq_number, F_time)

   where:

      F_type is the forwarded Message Type;

      F_orig_addr is the originator address of the forwarded message
      (note that this does not include a prefix length);

      F_seq_number is the message sequence number of the forwarded
      message;

      F_time specifies the time at which this Tuple expires and MUST be
      removed.

12.  Information Base Properties

   This section describes some additional properties of Information
   Bases and their contents.

12.1.  Corresponding Protocol Tuples

   As part of this specification, in a number of cases, there is a
   natural correspondence from a Protocol Tuple in one Protocol Set to a
   single Protocol Tuple in another Protocol Set, in the same or another
   Information Base.  The latter Protocol Tuple is referred to as
   "corresponding" to the former Protocol Tuple.

   Specific examples of corresponding Protocol Tuples include:

   o  There is a Local Interface Tuple corresponding to each Link Tuple,
      where the Link Tuple is in the Link Set for a MANET interface and
      the Local Interface Tuple represents that MANET interface.

   o  There is a Neighbor Tuple corresponding to each Link Tuple that
      has L_HEARD_time not EXPIRED, such that N_neighbor_addr_list
      contains L_neighbor_iface_addr_list.

   o  There is a Link Tuple (in the Link Set in the same Interface
      Information Base) corresponding to each 2-Hop Tuple such that
      L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.

Top      Up      ToC       Page 40 
   o  There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such
      that N_neighbor_addr_list contains N2_neighbor_iface_addr_list.
      (This is the Neighbor Tuple corresponding to the Link Tuple
      corresponding to the 2-Hop Tuple.)

   o  There is an Advertising Remote Router Tuple corresponding to each
      Router Topology Tuple such that AR_orig_addr = TR_from_orig_addr.

   o  There is an Advertising Remote Router Tuple corresponding to each
      Routable Address Topology Tuple such that AR_orig_addr =
      TA_from_orig_addr.

   o  There is an Advertising Remote Router Tuple corresponding to each
      Attached Network Tuple such that AR_orig_addr = AN_orig_addr.

   o  There is a Neighbor Tuple corresponding to each Routing Tuple such
      that N_neighbor_addr_list contains R_next_iface_addr.

12.2.  Address Ownership

   Addresses or network addresses with the following properties are
   considered as "fully owned" by a router when processing a received
   message:

   o  Equaling its originator address; OR

   o  Equaling the O_orig_addr in an Originator Tuple; OR

   o  Equaling or being a sub-range of the I_local_iface_addr_list in a
      Local Interface Tuple; OR

   o  Equaling or being a sub-range of the IR_local_iface_addr in a
      Removed Interface Address Tuple; OR

   o  Equaling an AL_net_addr in a Local Attached Network Tuple.

   Addresses or network addresses with the following properties are
   considered as "partially owned" (which may include being fully owned)
   by a router when processing a received message:

   o  Overlapping (equaling or containing) its originator address; OR

   o  Overlapping (equaling or containing) the O_orig_addr in an
      Originator Tuple; OR

   o  Overlapping the I_local_iface_addr_list in a Local Interface
      Tuple; OR

Top      Up      ToC       Page 41 
   o  Overlapping the IR_local_iface_addr in a Removed Interface Address
      Tuple; OR

   o  Equaling or having as a sub-range an AL_net_addr in a Local
      Attached Network Tuple.

13.  Packets and Messages

   The packet and message format used by this protocol is defined in
   [RFC5444].  Except as otherwise noted, options defined in [RFC5444]
   may be freely used, in particular alternative formats defined by
   packet, message, Address Block, and TLV flags.

   This section describes the usage of the packets and messages defined
   in [RFC5444] by this specification and the TLVs defined by, and used
   in, this specification.

13.1.  Messages

   Routers using this protocol exchange information through messages.
   The Message Types used by this protocol are the HELLO message and the
   TC message.  The HELLO message is defined by [RFC6130] and extended
   by this specification (see Section 15).  The TC message is defined by
   this specification (see Section 16).

13.2.  Packets

   One or more messages sent by a router at the same time SHOULD be
   combined into a single packet, subject to any constraints on maximum
   packet size (such as derived from the MTU over a local single hop)
   that MAY be imposed.  These messages may have originated at the
   sending router or at another router and are being forwarded by the
   sending router.  Messages with different originating routers MAY be
   combined for transmission within the same packet.  Messages from
   other protocols defined using [RFC5444], including but not limited to
   NHDP [RFC6130], MAY be combined for transmission within the same
   packet.  This specification does not define or use any contents of
   the Packet Header.

   Forwarded messages MAY be jittered as described in [RFC5148],
   including the observation that the forwarding jitter of all messages
   received in a single packet SHOULD be the same.  The value of
   MAXJITTER used in jittering a forwarded message MAY be based on
   information in that message (in particular any Message TLVs with Type
   = INTERVAL_TIME or Type = VALIDITY_TIME) or otherwise SHOULD be with
   a maximum delay of F_MAXJITTER.  A router MAY modify the jitter
   applied to a message in order to more efficiently combine messages in
   packets, as long as the maximum jitter is not exceeded.

Top      Up      ToC       Page 42 
13.3.  TLVs

   This specification defines two Message TLVs and four Address Block
   TLVs.

   All references in this specification to TLVs that do not indicate a
   type extension assume Type Extension = 0.  TLVs in processed messages
   with a type extension that is neither zero as so assumed, nor a
   specifically indicated non-zero type extension, are ignored.

   Note that, following [RFC5444] and network byte order, bits in an
   octet are numbered from 0 (most significant) to 7 (least
   significant).

13.3.1.  Message TLVs

   The MPR_WILLING TLV is used in HELLO messages.  A message MUST NOT
   contain more than one MPR_WILLING TLV.

   +-------------+--------------+--------------------------------------+
   |     Type    | Value Length | Value                                |
   +-------------+--------------+--------------------------------------+
   | MPR_WILLING |   1 octet    | Bits 0-3 encode the parameter        |
   |             |              | WILL_FLOODING; bits 4-7 encode the   |
   |             |              | parameter WILL_ROUTING.              |
   +-------------+--------------+--------------------------------------+

                    Table 1: MPR_WILLING TLV Definition

   The CONT_SEQ_NUM TLV is used in TC messages.  A message MUST NOT
   contain more than one CONT_SEQ_NUM TLV.

   +--------------+--------------+-------------------------------------+
   |     Type     | Value Length | Value                               |
   +--------------+--------------+-------------------------------------+
   | CONT_SEQ_NUM |   2 octets   | The ANSN contained in the Neighbor  |
   |              |              | Information Base.                   |
   +--------------+--------------+-------------------------------------+

                   Table 2: CONT_SEQ_NUM TLV Definition

13.3.2.  Address Block TLVs

   The LINK_METRIC TLV is used in HELLO messages and TC messages.  It
   MAY use any type extension; only LINK_METRIC TLVs with type extension
   equal to LINK_METRIC_TYPE will be used by this specification.  An

Top      Up      ToC       Page 43 
   address MUST NOT be associated with more than one link metric value
   for any given type extension, kind (link or neighbor), and direction
   using this TLV.

   +-------------+--------------+--------------------------------------+
   |     Type    | Value Length | Value                                |
   +-------------+--------------+--------------------------------------+
   | LINK_METRIC |   2 octets   | Bits 0-3 indicate kind(s) and        |
   |             |              | direction(s); bits 4-7 indicate      |
   |             |              | exponent (b); and bits 8-15 indicate |
   |             |              | mantissa (a).                        |
   +-------------+--------------+--------------------------------------+

                    Table 3: LINK_METRIC TLV Definition

   The exponent and mantissa use the representation defined in
   Section 6.  Each bit of the types and directions sub-field, if set
   ('1'), indicates that the link metric is of the indicated kind and
   direction.  Any combination of these bits MAY be used.

                   +-----+-----------------+-----------+
                   | Bit |       Kind      | Direction |
                   +-----+-----------------+-----------+
                   |  0  |   Link metric   | Incoming  |
                   |  1  |   Link metric   | Outgoing  |
                   |  2  | Neighbor metric | Incoming  |
                   |  3  | Neighbor metric | Outgoing  |
                   +-----+-----------------+-----------+

               Table 4: LINK_METRIC TLV Types and Directions

   The MPR TLV is used in HELLO messages and indicates that an address
   with which it is associated is of a symmetric 1-hop neighbor that has
   been selected as an MPR.

   +------+--------------+---------------------------------------------+
   | Type | Value Length | Value                                       |
   +------+--------------+---------------------------------------------+
   | MPR  |   1 octet    | FLOODING indicates that the corresponding   |
   |      |              | address is of a neighbor selected as a      |
   |      |              | flooding MPR; ROUTING indicates that the    |
   |      |              | corresponding address is of a neighbor      |
   |      |              | selected as a routing MPR; and FLOOD_ROUTE  |
   |      |              | indicates both (see Section 24.6).          |
   +------+--------------+---------------------------------------------+

                        Table 5: MPR TLV Definition

Top      Up      ToC       Page 44 
   The NBR_ADDR_TYPE TLV is used in TC messages.

   +---------------+--------------+------------------------------------+
   |      Type     | Value Length | Value                              |
   +---------------+--------------+------------------------------------+
   | NBR_ADDR_TYPE |   1 octet    | ORIGINATOR indicates that the      |
   |               |              | corresponding address (which MUST  |
   |               |              | have maximum prefix length) is an  |
   |               |              | originator address; ROUTABLE       |
   |               |              | indicates that the corresponding   |
   |               |              | network address is a routable      |
   |               |              | address of an interface; and       |
   |               |              | ROUTABLE_ORIG indicates that the   |
   |               |              | corresponding address is both (see |
   |               |              | Section 24.6).                     |
   +---------------+--------------+------------------------------------+

                   Table 6: NBR_ADDR_TYPE TLV Definition

   If an address is both an originator address and a routable address,
   then it may be associated with either one Address Block TLV with Type
   := NBR_ADDR_TYPE and Value := ROUTABLE_ORIG, or with two Address
   Block TLVs with Type:= NBR_ADDR_TYPE, one with Value := ORIGINATOR
   and one with Value := ROUTABLE.

   The GATEWAY TLV is used in TC messages.  An address MUST NOT be
   associated with more than one hop count value using this TLV.

     +---------+--------------+-------------------------------------+
     |   Type  | Value Length | Value                               |
     +---------+--------------+-------------------------------------+
     | GATEWAY |   1 octet    | Number of hops to attached network. |
     +---------+--------------+-------------------------------------+

                      Table 7: GATEWAY TLV Definition

   All address objects included in a TC message according to this
   specification MUST be associated either with at least one TLV with
   Type := NBR_ADDR_TYPE or with a TLV with Type := GATEWAY, but not
   both.  Any other address objects MAY be included in Address Blocks in
   a TC message but are ignored by this specification.

Top      Up      ToC       Page 45 
14.  Message Processing and Forwarding

   This section describes the optimized flooding operation (MPR
   flooding) used when control messages, as instances of [RFC5444], are
   intended for MANET-wide distribution.  This flooding mechanism
   defines when a received message is, or is not, processed and/or
   forwarded.

   This flooding mechanism is used by this protocol and MAY be used by
   extensions to this protocol that define, and hence own, other Message
   Types, to manage processing and/or forwarding of these messages.
   This specification contains elements (P_type, RX_type, F_type)
   required only for such usage.

   This flooding mechanism is always used for TC messages (see
   Section 16).  Received HELLO messages (see Section 15) are, unless
   invalid, always processed and never forwarded by this flooding
   mechanism.  They thus do not need to be recorded in the Received
   Message Information Base.

   The processing selection and forwarding mechanisms are designed to
   only need to parse the Message Header in order to determine whether a
   message is to be processed and/or forwarded and not to have to parse
   the Message Body even if the message is forwarded (but not
   processed).  An implementation MAY only parse the Message Body if
   necessary or MAY always parse the Message Body and reject the message
   if it cannot be so parsed or any other error is identified.

   An implementation MUST discard the message silently if it is unable
   to parse the Message Header or (if attempted) the Message Body, or if
   a message (other than a HELLO message) does not include a message
   sequence number.

14.1.  Actions When Receiving a Message

   On receiving, on an OLSRv2 interface, a message of a type specified
   to be using this mechanism, which includes the TC messages defined in
   this specification, a router MUST perform the following:

   1.  If the router recognizes from the originator address of the
       message that the message is one that the receiving router itself
       originated (i.e., the message originator address is the
       originator address of this router or is an O_orig_addr in an
       Originator Tuple), then the message MUST be silently discarded.

Top      Up      ToC       Page 46 
   2.  Otherwise:

       1.  If the message is of a type that may be processed, then the
           message is considered for processing according to
           Section 14.2.

       2.  If the message is of a type that may be forwarded, AND:

           +  <msg-hop-limit> is present and <msg-hop-limit> > 1; AND

           +  <msg-hop-count> is not present or <msg-hop-count> < 255,

           then the message is considered for forwarding according to
           Section 14.3.

14.2.  Message Considered for Processing

   If a message (the "current message") is considered for processing,
   then the following tasks MUST be performed:

   1.  If the sending address (i.e., the source address of the IP
       datagram containing the current message) does not match (taking
       into account any address prefix) a network address in an
       L_neighbor_iface_addr_list of a Link Tuple, with L_status =
       SYMMETRIC, in the Link Set for the OLSRv2 interface on which the
       current message was received (the "receiving interface"), then
       processing the current message is OPTIONAL.  If the current
       message is not processed, then the following steps are not
       carried out.

   2.  If a Processed Tuple exists with:

       *  P_type = the Message Type of the current message; AND

       *  P_orig_addr = the originator address of the current message;
          AND

       *  P_seq_number = the message sequence number of the current
          message,

       then the current message MUST NOT be processed.

   3.  Otherwise:

       1.  Create a Processed Tuple in the Processed Set with:

           +  P_type := the Message Type of the current message;

Top      Up      ToC       Page 47 
           +  P_orig_addr := the originator address of the current
              message;

           +  P_seq_number := the sequence number of the current
              message;

           +  P_time := current time + P_HOLD_TIME.

       2.  Process the current message according to its Message Type.
           For a TC message, this is as defined in Section 16.3.

14.3.  Message Considered for Forwarding

   If a message (the "current message") is considered for forwarding,
   then the following tasks MUST be performed:

   1.  If the sending address (i.e., the source address of the IP
       datagram containing the current message) does not match (taking
       into account any address prefix) a network address in an
       L_neighbor_iface_addr_list of a Link Tuple, with L_status =
       SYMMETRIC, in the Link Set for the OLSRv2 interface on which the
       current message was received (the "receiving interface"), then
       the current message MUST be silently discarded.

   2.  Otherwise:

       1.  If a Received Tuple exists in the Received Set for the
           receiving interface, with:

           +  RX_type = the Message Type of the current message; AND

           +  RX_orig_addr = the originator address of the current
              message; AND

           +  RX_seq_number = the sequence number of the current
              message,

           then the current message MUST be silently discarded.

       2.  Otherwise:

           1.  Create a Received Tuple in the Received Set for the
               receiving interface with:

               -  RX_type := the Message Type of the current message;

               -  RX_orig_addr := originator address of the current
                  message;

Top      Up      ToC       Page 48 
               -  RX_seq_number := sequence number of the current
                  message;

               -  RX_time := current time + RX_HOLD_TIME.

           2.  If a Forwarded Tuple exists with:

               -  F_type = the Message Type of the current message; AND

               -  F_orig_addr = the originator address of the current
                  message; AND

               -  F_seq_number = the sequence number of the current
                  message,

               then the current message MUST be silently discarded.

           3.  Otherwise, if the sending address matches (taking account
               of any address prefix), any network address in an
               L_neighbor_iface_addr_list of a Link Tuple in the Link
               Set for the receiving OLSRv2 interface that has L_status
               = SYMMETRIC and L_mpr_selector = true, then:

               1.  Create a Forwarded Tuple in the Forwarded Set with:

                   o  F_type := the Message Type of the current message;

                   o  F_orig_addr := originator address of the current
                      message;

                   o  F_seq_number := sequence number of the current
                      message;

                   o  F_time := current time + F_HOLD_TIME.

               2.  The Message Header of the current message is modified
                   by:

                   o  Decrement <msg-hop-limit> in the Message Header by
                      1; AND

                   o  If present, increment <msg-hop-count> in the
                      Message Header by 1.

               3.  The message is transmitted over all OLSRv2
                   interfaces, as described in Section 13.

Top      Up      ToC       Page 49 
           4.  Otherwise, the current message MUST be silently
               discarded.

15.  HELLO Messages

   The HELLO Message Type is owned by NHDP [RFC6130], and HELLO messages
   are thus generated, transmitted, received, and processed by NHDP.
   This protocol, as permitted by [RFC6130], also uses HELLO messages,
   including adding to HELLO message generation and implementing
   additional processing based on received HELLO messages.  HELLO
   messages are not forwarded by NHDP [RFC6130] or by OLSRv2.

15.1.  HELLO Message Generation

   HELLO messages sent over OLSRv2 interfaces are generated as defined
   in [RFC6130] and then modified as described in this section.  HELLO
   messages sent on other MANET interfaces are not modified by this
   specification.

   HELLO messages sent over OLSRv2 interfaces are extended by adding the
   following elements:

   o  A message originator address, recording this router's originator
      address.  This MUST use a <msg-orig-addr> element, unless:

      *  The message specifies only a single local interface address
         (i.e., contains only one address object that is associated with
         an Address Block TLV with Type = LOCAL_IF and that has no
         prefix length or a maximum prefix length) that will then be
         used as the message originator address; OR

      *  The message does not include any local interface network
         addresses (i.e., has no address objects associated with an
         Address Block TLV with Type = LOCAL_IF), as permitted by the
         specification in [RFC6130], when the router that generated the
         HELLO message has only one interface address and will use that
         as the sending address of the IP datagram in which the HELLO
         message is contained.  In this case, that address will be used
         as the message originator address.

   o  A Message TLV with Type := MPR_WILLING MUST be included.

   o  The following cases associate Address Block TLVs with one or more
      addresses from a Link Tuple or a Neighbor Tuple if these are
      included in the HELLO message.  In each case, the TLV MUST be
      associated with at least one address object for an address from
      the relevant Tuple; the TLV MAY be associated with more such
      addresses (including a copy of that address object, possibly not

Top      Up      ToC       Page 50 
      itself associated with any other indicated TLVs, in the same or a
      different Address Block).  These additional TLVs MUST NOT be
      associated with any other addresses in a HELLO message that will
      be processed by NHDP [RFC6130].

      *  For each Link Tuple for which L_in_metric != UNKNOWN_METRIC and
         for which one or more addresses in its
         L_neighbor_iface_addr_list are included as address objects with
         an associated Address Block TLV with Type = LINK_STATUS and
         Value = HEARD or Value = SYMMETRIC, at least one of these
         addresses MUST be associated with an Address Block TLV with
         Type := LINK_METRIC indicating an incoming link metric with
         value L_in_metric.

      *  For each Link Tuple for which L_out_metric != UNKNOWN_METRIC
         and for which one or more addresses in its
         L_neighbor_iface_addr_list are included as address objects with
         an associated Address Block TLV with Type = LINK_STATUS and
         Value = SYMMETRIC, at least one of these addresses MUST be
         associated with an Address Block TLV with Type := LINK_METRIC
         indicating an outgoing link metric with value L_out_metric.

      *  For each Neighbor Tuple for which N_symmetric = true and for
         which one or more addresses in its N_neighbor_addr_list are
         included as address objects with an associated Address Block
         TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value =
         SYMMETRIC, at least one of these addresses MUST be associated
         with an Address Block TLV with Type := LINK_METRIC indicating
         an incoming neighbor metric with value N_in_metric.

      *  For each Neighbor Tuple for which N_symmetric = true and for
         which one or more addresses in its N_neighbor_addr_list are
         included as address objects with an associated Address Block
         TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value =
         SYMMETRIC, at least one of these addresses MUST be associated
         with an Address Block TLV with Type := LINK_METRIC indicating
         an outgoing neighbor metric with value N_out_metric.

      *  For each Neighbor Tuple with N_flooding_mpr = true and for
         which one or more network addresses in its N_neighbor_addr_list
         are included as address objects in the HELLO message with an
         associated Address Block TLV with Type = LINK_STATUS and Value
         = SYMMETRIC, at least one of these addresses MUST be associated
         with an Address Block TLV with Type := MPR and Value :=
         FLOODING or Value := FLOOD_ROUTE.

Top      Up      ToC       Page 51 
      *  For each Neighbor Tuple with N_routing_mpr = true and for which
         one or more network addresses in its N_neighbor_addr_list are
         included as address objects in the HELLO message with an
         associated Address Block TLV with Type = LINK_STATUS and Value
         = SYMMETRIC, at least one of these addresses MUST be associated
         with an Address Block TLV with Type := MPR and Value := ROUTING
         or Value := FLOOD_ROUTE.

15.2.  HELLO Message Transmission

   HELLO messages are scheduled and transmitted by NHDP [RFC6130].  This
   protocol MAY require that an additional HELLO message be sent on each
   OLSRv2 interface when either of the router's sets of MPRs changes, in
   addition to the cases specified in [RFC6130] and subject to the
   constraints specified in [RFC6130] (notably on minimum HELLO message
   transmission intervals).

15.3.  HELLO Message Processing

   When received on an OLSRv2 interface, HELLO messages are made
   available to this protocol in two ways, both as permitted by
   [RFC6130]:

   o  Such received HELLO messages MUST be made available to this
      protocol on reception, which allows them to be discarded before
      being processed by NHDP [RFC6130], for example, if the information
      added to the HELLO message by this specification is inconsistent.

   o  Such received HELLO messages MUST be made available to OLSRv2
      after NHDP [RFC6130] has completed its processing thereof, unless
      discarded as malformed by NHDP, for processing by OLSRv2.

15.3.1.  HELLO Message Discarding

   In addition to the reasons specified in [RFC6130] for discarding a
   HELLO message on reception, a HELLO message received on an OLSRv2
   interface MUST be discarded before processing by NHDP [RFC6130] or
   this specification if it:

   o  Has more than one Message TLV with Type = MPR_WILLING.

   o  Has a message originator address, or a network address
      corresponding to an address object associated with an Address
      Block TLV with Type = LOCAL_IF, that is partially owned by this
      router.  (Some of these cases are already excluded by [RFC6130].)

Top      Up      ToC       Page 52 
   o  Includes any address object associated with an Address Block TLV
      with Type = LINK_STATUS or Type = OTHER_NEIGHB that overlaps the
      message's originator address.

   o  Contains any address that will be processed by NHDP [RFC6130] that
      is associated, using the same or different address objects, with
      two different values of link metric with the same kind and
      direction using a TLV with Type = LINK_METRIC and Type Extension =
      LINK_METRIC_TYPE.  This also applies to different addresses that
      are both of the OLSRv2 interface on which the HELLO message was
      received.

   o  Contains any address object associated with an Address Block TLV
      with Type = MPR that is not also associated with an Address Block
      TLV with Type = LINK_STATUS and Value = SYMMETRIC (including using
      a different copy of that address object in the same or a different
      Address Block).

15.3.2.  HELLO Message Usage

   HELLO messages are first processed as specified in [RFC6130].  That
   processing includes identifying (or creating) a Link Tuple and a
   Neighbor Tuple corresponding to the originator of the HELLO message
   (the "current Link Tuple" and the "current Neighbor Tuple").  After
   this, the following processing MUST also be performed if the HELLO
   message is received on an OLSRv2 interface and contains a TLV with
   Type = MPR_WILLING:

   1.  If the HELLO message has a well-defined message originator
       address, i.e., has an <msg-orig-addr> element or has zero or one
       network addresses associated with a TLV with Type = LOCAL_IF:

       1.  Remove any Neighbor Tuple, other than the current Neighbor
           Tuple, with N_orig_addr = message originator address, taking
           any consequent action (including removing one or more Link
           Tuples) as specified in [RFC6130].

       2.  The current Link Tuple is then updated according to:

           1.  Update L_in_metric and L_out_metric as described in
               Section 15.3.2.1;

           2.  Update L_mpr_selector as described in Section 15.3.2.3.

       3.  The current Neighbor Tuple is then updated according to:

           1.  N_orig_addr := message originator address;

Top      Up      ToC       Page 53 
           2.  Update N_in_metric and N_out_metric as described in
               Section 15.3.2.1;

           3.  Update N_will_flooding and N_will_routing as described in
               Section 15.3.2.2;

           4.  Update N_mpr_selector as described in Section 15.3.2.3.

       4.  All 2-Hop Tuples that were updated as described in [RFC6130]
           are then updated according to:

           1.  Update N2_in_metric and N2_out_metric as described in
               Section 15.3.2.1.

   2.  If there are any changes to the router's Information Bases, then
       perform the processing defined in Section 17.

15.3.2.1.  Updating Metrics

   For each address in a received HELLO message with an associated TLV
   with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, an
   incoming (to the message originator) link metric value is defined.
   If the HELLO message contains a TLV with Type = LINK_METRIC and Type
   Extension = LINK_METRIC_TYPE that associates that address value with
   a metric value of the appropriate kind (link) and direction
   (incoming) of metric, then the incoming link metric is that metric
   value; otherwise, the incoming link metric is defined as
   UNKNOWN_METRIC.

   For each address in a received HELLO message with an associated TLV
   with Type = LINK_STATUS and Value = SYMMETRIC, an outgoing (from the
   message originator) link metric value is defined.  If the HELLO
   message contains a TLV with Type = LINK_METRIC and Type Extension =
   LINK_METRIC_TYPE that associates that address value with a metric
   value of the appropriate kind (link) and direction (outgoing) of
   metric, then the outgoing link metric is that metric value;
   otherwise, the outgoing link metric is defined as UNKNOWN_METRIC.

   For each address in a received HELLO message with an associated TLV
   with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC,
   an incoming (to the message originator) neighbor metric value is
   defined.  If the HELLO message contains a TLV with Type = LINK_METRIC
   and Type Extension = LINK_METRIC_TYPE that associates that address
   value with a metric value of the appropriate kind (neighbor) and
   direction (incoming) of metric, then the incoming neighbor metric is
   that metric value; otherwise, the incoming neighbor metric is defined
   as UNKNOWN_METRIC.

Top      Up      ToC       Page 54 
   For each address in a received HELLO message with an associated TLV
   with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC,
   an outgoing (from the message originator) neighbor metric value is
   defined.  If the HELLO message contains a TLV with Type = LINK_METRIC
   and Type Extension = LINK_METRIC_TYPE that associates that address
   value with a metric value of the appropriate kind (neighbor) and
   direction (outgoing) of metric, then the outgoing neighbor metric is
   that metric value; otherwise, the outgoing neighbor metric is defined
   as UNKNOWN_METRIC.

   The link metric elements L_in_metric and L_out_metric in a Link Tuple
   are updated according to the following:

   o  For any Link Tuple, L_in_metric MAY be set to any representable
      value by a process outside this specification at any time.
      L_in_metric MUST be so set whenever L_status becomes equal to
      HEARD or SYMMETRIC (if no other value is available, then the value
      MAXIMUM_METRIC MUST be used).  Setting L_in_metric MAY use
      information based on the receipt of a packet including a HELLO
      message that causes the creation or updating of the Link Tuple.

   o  When, as specified in [RFC6130], a Link Tuple is updated (possibly
      immediately after being created) due to the receipt of a HELLO
      message, if L_status = SYMMETRIC, then L_out_metric is set equal
      to the incoming link metric for any included address of the
      interface on which the HELLO message was received.  (Note that the
      rules for discarding HELLO messages in Section 15.3.1 make this
      value unambiguous.)  If there is any such address, but no such
      link metric, then L_out_metric is set to UNKNOWN_METRIC.

   The neighbor metric elements N_in_metric and N_out_metric in a
   Neighbor Tuple are updated according to Section 17.3.

   The metric elements N2_in_metric and N2_out_metric in any 2-Hop Tuple
   updated as defined in [RFC6130] are updated to equal the incoming
   neighbor metric and outgoing neighbor metric, respectively,
   associated with the corresponding N2_2hop_addr.  If there are no such
   metrics, then these elements are set to UNKNOWN_METRIC.

15.3.2.2.  Updating Willingness

   N_will_flooding and N_will_routing in the current Neighbor Tuple are
   updated using the Message TLV with Type = MPR_WILLING (note that this
   must be present) as follows:

Top      Up      ToC       Page 55 
   o  N_will_flooding := bits 0-3 of the value of that TLV; AND

   o  N_will_routing := bits 4-7 of the value of that TLV.

   (Each being in the range 0 to 15, i.e., WILL_NEVER to WILL_ALWAYS.)

15.3.2.3.  Updating MPR Selector Status

   L_mpr_selector is updated as follows:

   1.  If a router finds an address object representing any of its
       relevant local interface network addresses (i.e., those contained
       in the I_local_iface_addr_list of an OLSRv2 interface) with an
       associated Address Block TLV with Type = MPR and Value = FLOODING
       or Value = FLOOD_ROUTE in the HELLO message (indicating that the
       originating router has selected the receiving router as a
       flooding MPR), then, for the current Link Tuple:

       *  L_mpr_selector := true.

   2.  Otherwise (i.e., if no such address object and Address Block TLV
       was found), if a router finds an address object representing any
       of its relevant local interface network addresses (i.e., those
       contained in the I_local_iface_addr_list of an OLSRv2 interface)
       with an associated Address Block TLV with Type = LINK_STATUS and
       Value = SYMMETRIC in the HELLO message, then, for the current
       Link Tuple:

       *  L_mpr_selector := false.

   N_mpr_selector is updated as follows:

   1.  If a router finds an address object representing any of its
       relevant local interface network addresses (those contained in
       the I_local_iface_addr_list of an OLSRv2 interface) with an
       associated Address Block TLV with Type = MPR and Value = ROUTING
       or Value = FLOOD_ROUTE in the HELLO message (indicating that the
       originating router has selected the receiving router as a routing
       MPR), then, for the current Neighbor Tuple:

       *  N_mpr_selector := true;

       *  N_advertised := true.

   2.  Otherwise (i.e., if no such address object and Address Block TLV
       was found), if a router finds an address object representing any
       of its relevant local interface network addresses (those
       contained in the I_local_iface_addr_list of an OLSRv2 interface)

Top      Up      ToC       Page 56 
       with an associated Address Block TLV with Type = LINK_STATUS and
       Value = SYMMETRIC in the HELLO message, then, for the current
       Neighbor Tuple:

       *  N_mpr_selector := false;

       *  The router MAY also set N_advertised := false.



(page 56 continued on part 4)

Next RFC Part