RFC 7181
The Optimized Link State Routing Protocol Version 2
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.
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);
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.
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.
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.
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.
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
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.
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 Definition13.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
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
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.
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.
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;
+ 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;
- 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.
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
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.
* 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].)
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;
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.
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:
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)
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)
