RFC 7181
The Optimized Link State Routing Protocol Version 2
4. Protocol Overview and Functioning
The objectives of this protocol are for each router to: o Identify all destinations in the network. o Identify a sufficient subset of links in the network, in order that shortest routes can be calculated to all available destinations. o Provide a Routing Set containing these shortest routes from this router to all destinations (routable addresses and local links).4.1. Overview
These objectives are achieved, for each router, by: o Using NHDP [RFC6130] to identify symmetric 1-hop neighbors and symmetric 2-hop neighbors. o Reporting its participation in OLSRv2, and its willingness to be a flooding MPR and to be a routing MPR, by extending the HELLO messages defined in [RFC6130] by the addition of an MPR_WILLING Message TLV. The router's "flooding willingness" indicates how willing it is to participate in MPR flooding. The router's "routing willingness" indicates how willing it is to be an intermediate router for routing. Note that a router is still able to be a routing source or destination, even if unwilling to perform either function. o Extending the HELLO messages defined in [RFC6130] to allow the addition of directional link metrics to advertised links with other routers participating in OLSRv2 and to indicate which link metric type is being used by those routers. Both incoming and outgoing link metrics may be reported, the former determined by the advertising router. o Selecting flooding MPRs and routing MPRs from among its willing symmetric 1-hop neighbors such that, for each set of MPRs, all symmetric 2-hop neighbors are reachable either directly or via at least one selected MPR, using a path of appropriate minimum total metric for at least routing MPR selection. An analysis and examples of MPR selection algorithms are given in [MPR]; a suggested algorithm, appropriately adapted for each set of MPRs, is included in Appendix B of this specification. Note that it is not necessary for routers to use the same algorithm in order to interoperate in the same MANET, but each such algorithm must have the appropriate properties, described in Section 18.
o Signaling its flooding MPR and routing MPR selections, by
extending the HELLO messages defined in [RFC6130] to report this
information by the addition of MPR Address Block TLV(s) associated
with the appropriate network addresses.
o Extracting its flooding MPR selectors and routing MPR selectors
from received HELLO messages, using the included MPR Address Block
TLV(s).
o Defining a TC (Topology Control) Message Type using the message
format specified in [RFC5444]. TC messages are used to
periodically signal links between routing MPR selectors and itself
throughout the MANET. This signaling includes suitable
directional neighbor metrics (the best link metric in that
direction between those routers).
o Allowing its TC messages, as well as HELLO messages, to be
included in packets specified in [RFC5444], using the "manet" IP
protocol or UDP port as specified in [RFC5498].
o Diffusing TC messages by using a flooding reduction mechanism,
denoted "MPR flooding"; only the flooding MPRs of a router will
retransmit messages received from (i.e., originated or last
relayed by) that router.
Note that the indicated extensions to [RFC6130] are of forms
permitted by that specification.
This specification defines:
o The requirement to use [RFC6130], its parameters, constants, HELLO
messages, and Information Bases, each as extended in this
specification.
o Two new Information Bases: the Topology Information Base and the
Received Message Information Base.
o TC messages, which are used for MANET wide signaling (using MPR
flooding) of selected topology (link state) information.
o A requirement for each router to have an originator address to be
included in, or deducible from, HELLO messages and TC messages.
o The specification of new Message TLVs and Address Block TLVs that
are used in HELLO messages and TC messages, including for
reporting neighbor status, MPR selection, external gateways, link
metrics, willingness to be an MPR, and content sequence numbers.
Note that the generation of (incoming) link metric values is to be
undertaken by a process outside this specification; this
specification concerns only the distribution and use of those
metrics.
o The generation of TC messages from the appropriate information in
the Information Bases.
o The updating of the Topology Information Base according to
received TC messages.
o The MPR flooding mechanism, including the inclusion of message
originator address and sequence number to manage duplicate
messages, using information recorded in the Received Message
Information Base.
o The response to other events, such as the expiration of
information in the Information Bases.
This protocol inherits the stability of a link state algorithm and
has the advantage of having routes immediately available when needed,
due to its proactive nature.
This protocol only interacts with IP through routing table management
and the use of the sending IP address for IP datagrams containing
messages used by this specification.
4.2. Routers and Interfaces
In order for a router to participate in a MANET using this protocol,
it must have at least one, and possibly more, OLSRv2 interfaces.
Each OLSRv2 interface:
o Is a MANET interface, as specified in [RFC6130]. In particular,
it must be configured with one or more network addresses; these
addresses must each be specific to this router and must include
any address that will be used as the sending address of any IP
packet sent on this OLSRv2 interface.
o Has a number of interface parameters, adding to those specified in
[RFC6130].
o Has an Interface Information Base, extending that specified in
[RFC6130].
o Generates and processes HELLO messages according to [RFC6130],
extended as specified in Section 15.
In addition to a set of OLSRv2 interfaces as described above, each
router:
o May have one or more non-OLSRv2 interfaces (which may include
MANET interfaces and/or non-MANET interfaces) and/or local
attached networks for which this router can accept IP packets.
All routable addresses for which the router is to accept IP
packets must be used as an (OLSRv2 or non-OLSRv2) interface
network address or as an address of a local attached network of
the router.
o Has a number of router parameters, adding to those specified in
[RFC6130].
o Has a Local Information Base, extending that specified in
[RFC6130], including selection of an originator address and
recording any locally attached networks.
o Has a Neighbor Information Base, extending that specified in
[RFC6130] to record MPR selection and advertisement information.
o Has a Topology Information Base, recording information received in
TC messages.
o Has a Received Message Information Base, recording information
about received messages to ensure that each TC message is only
processed once, and forwarded at most once on each OLSRv2
interface, by a router.
o Generates, receives, and processes TC messages.
4.3. Information Base Overview
Each router maintains the Information Bases described in the
following sections. These are used for describing the protocol in
this specification. An implementation of this protocol may maintain
this information in the indicated form or in any other organization
that offers access to this information. In particular, note that it
is not necessary to remove Tuples from Sets at the exact time
indicated, only to behave as if the Tuples were removed at that time.
4.3.1. Local Information Base
The Local Information Base is specified in [RFC6130] and contains a
router's local configuration. It is extended in this specification
to also record an originator address and to include a router's:
o Originator Set, containing addresses that were recently used as
this router's originator address, that is used, together with the
router's current originator address, to enable a router to
recognize and discard control traffic that was originated by the
router itself.
o Local Attached Network Set, containing network addresses of
networks to which this router can act as a gateway, that it
advertises in its TC messages.
4.3.2. Interface Information Base
The Interface Information Base for each OLSRv2 interface is as
specified in [RFC6130], extended to also record, in each Link Set,
link metric values (incoming and outgoing) and flooding MPR selector
information.
4.3.3. Neighbor Information Base
The Neighbor Information Base is specified in [RFC6130] and is
extended to also record, in the Neighbor Tuple for each neighbor:
o Its originator address.
o Neighbor metric values, these being the minimum of the link metric
values in the indicated direction for all symmetric 1-hop links
with that neighbor.
o Its willingness to be a flooding MPR and to be a routing MPR.
o Whether it has been selected by this router as a flooding MPR or
as a routing MPR and whether it is a routing MPR selector of this
router. (Whether it is a flooding MPR selector of this neighbor
is recorded in the Interface Information Base.)
o Whether it is to be advertised in TC messages sent by this router.
4.3.4. Topology Information Base
The Topology Information Base in each router contains:
o An Advertising Remote Router Set, recording each remote router
from which TC messages have been received. This is used in order
to determine if a received TC message contains fresh or outdated
information; a received TC message is ignored in the latter case.
o A Router Topology Set, recording links between routers in the
MANET, as described by received TC messages.
o A Routable Address Topology Set, recording routable addresses in
the MANET (available as IP packet destinations) and from which
remote router these routable addresses can be directly reached
(i.e., in a single IP hop from that remote router), as reported by
received TC messages.
o An Attached Network Set, recording networks to which a remote
router has advertised that it may act as a gateway. These
networks may be reached in one or more IP hops from that remote
router.
o A Routing Set, recording routes from this router to all available
destinations. The IP routing table is to be updated using this
Routing Set. (A router may choose to use any or all destination
network addresses in the Routing Set to update the IP routing
table. This selection is outside the scope of this
specification.)
The purpose of the Topology Information Base is to record information
used, in addition to that in the Local Information Base, the
Interface Information Bases, and the Neighbor Information Base, to
construct the Routing Set (which is also included in the Topology
Information Base).
This specification describes the calculation of the Routing Set based
on a Topology Graph constructed in two phases. First, a "backbone"
graph representing the routers in the MANET, and the connectivity
between them, is constructed from the Local Information Base, the
Neighbor Information Base, and the Router Topology Set. Second, this
graph is "decorated" with additional destination network addresses
using the Local Information Base, the Routable Address Topology Set,
and the Attached Network Set.
The Topology Graph does not need to be recorded in the Topology
Information Base; it can either be constructed as required when the
Routing Set is to be changed or need not be explicitly constructed
(as illustrated in Appendix C). An implementation may, however,
construct and retain the Topology Graph if preferred.
4.3.5. Received Message Information Base
The Received Message Information Base in each router contains: o A Received Set for each OLSRv2 interface, describing TC messages received by this router on that OLSRv2 interface. o A Processed Set, describing TC messages processed by this router. o A Forwarded Set, describing TC messages forwarded by this router. The Received Message Information Base serves the MPR flooding mechanism by ensuring that received messages are forwarded at most once by a router and also ensures that received messages are processed exactly once by a router. The Received Message Information Base may also record information about other Message Types that use the MPR flooding mechanism.4.4. Signaling Overview
This protocol generates and processes HELLO messages according to [RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are extended according to Section 15 of this specification to include an originator address, link metrics, and MPR selection information. This specification defines a single Message Type, the TC message. TC messages are sent by their originating router proactively, at a regular interval, on all OLSRv2 interfaces. This interval may be fixed or dynamic, for example, it may be backed off due to congestion or network stability. TC messages may also be sent as a response to a change in the router itself, or its advertised symmetric 1-hop neighborhood, for example, on first being selected as a routing MPR. Because TC messages are sent periodically, this protocol is tolerant of unreliable transmissions of TC messages. Message losses may occur more frequently in wireless networks due to collisions or other transmission problems. This protocol may use "jitter", randomized adjustments to message transmission times, to reduce the incidence of collisions, as specified in [RFC5148]. This protocol is tolerant of out-of-sequence delivery of TC messages due to in-transit message reordering. Each router maintains an Advertised Neighbor Sequence Number (ANSN) that is incremented when its recorded neighbor information that is to be included in its TC messages changes. This ANSN is included in the router's TC messages. The recipient of a TC message can use this included ANSN to identify which of the information it has received is most recent, even if
messages have been reordered while in transit. Only the most recent information received is used; older information received later is discarded. TC messages may be "complete" or "incomplete". A complete TC message advertises all of the originating router's routing MPR selectors; it may also advertise other symmetric 1-hop neighbors. Complete TC messages are generated periodically (and also, optionally, in response to symmetric 1-hop neighborhood changes). Incomplete TC messages may be used to report additions to advertised information, without repeating unchanged information. TC messages, and HELLO messages as extended by this specification, define (by inclusion or by deduction when having a single address) an originator address for the router that created the message. A TC message reports both the originator addresses and routable addresses of its advertised neighbors, distinguishing the two using an Address Block TLV (an address may be both routable and an originator address). TC messages also report the originator's locally attached networks. TC messages are MPR flooded throughout the MANET. A router retransmits a TC message received on an OLSRv2 interface if and only if the message did not originate at this router and has not been previously forwarded by this router, this is the first time the message has been received on this OLSRv2 interface, and the message is received from (i.e., originated from or was last relayed by) one of this router's flooding MPR selectors. Some TC messages may be MPR flooded over only part of the network, e.g., allowing a router to ensure that nearer routers are kept more up to date than distant routers, such as is used in Fisheye State Routing [FSR] and Fuzzy Sighted Link State routing [FSLS]. This is enabled using [RFC5497]. TC messages include outgoing neighbor metrics that will be used in the selection of routes.4.5. Link Metrics
OLSRv1 [RFC3626] created minimum hop routes to destinations. However, in many, if not most, circumstances, better routes (in terms of quality of service for end users) can be created by use of link metrics.
OLSRv2, as defined in this specification, supports metric-based routing, i.e., it allows links to each have a chosen metric. Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are those with the minimum sum of the link metrics along that route. Link metrics are defined to be directional; the link metric from one router to another may be different from that on the reverse link. The link metric is assessed at the receiver, as on a (typically) wireless link, that is the better informed as to link information. Both incoming and outgoing link information is used by OLSRv2; the distinctions in this specification must be clearly followed. This specification also defines both incoming and outgoing neighbor metrics for each symmetric 1-hop neighbor, these being the minimum value of the link metrics in the same direction for all symmetric links with that neighbor. Note that this means that all neighbor metric values are link metric values and that specification of, for example, link metric value encoding also includes encoding of neighbor metric values. This specification does not define the nature of the link metric. However, this specification allows, through use of the type extension of a defined Address Block TLV, for link metrics with specific meanings to be defined and either allocated by IANA or privately used. Each HELLO or TC message carrying link (or neighbor) metrics thus indicates which link metric information it is carrying, allowing routers to determine if they can interoperate. If link metrics require additional signaling to determine their values, whether in HELLO messages or otherwise, then this is permitted but is outside the scope of this specification. Careful consideration should be given to how to use link metrics. In particular, it is advisable to not simply default to use of all links with equal metrics (i.e., hop count) for routing without careful consideration of whether that is appropriate or not.4.6. Flooding MPRs and Routing MPR
This specification uses two sets of MPRs: flooding MPRs and routing MPRs. These are selected separately, because: o Flooding MPRs may use metrics; routing MPRs must use metrics. o When flooding MPRs use metrics, these are outgoing link metrics; routing MPRs use incoming neighbor metrics.
o Flooding MPRs must be selected per OLSRv2 interface; routing MPRs
need not be selected per OLSRv2 interface.
4.7. Routing Set Use
The purpose of the Routing Set is to determine and record routes
(local interface network address and next-hop interface network
address) to all possible routable addresses advertised by this
protocol as well as all destinations that are local, i.e., within one
hop, to the router (whether using routable addresses or not). Only
symmetric links are used in such routes.
It is intended that the Routing Set can be used for IP packet
routing, by using its contents to update the IP routing table. That
update, and whether any Routing Tuples are not used when updating the
IP routing table, is outside the scope of this specification.
The signaling in this specification has been designed so that a
"backbone" Topology Graph of routers, each identified by its
originator address, with at most one direct connection between any
pair of routers, can be constructed (from the Neighbor Set and the
Router Topology Set) using a suitable minimum path length algorithm.
This Topology Graph can then have other network addresses (routable
or of symmetric 1-hop neighbors) added to it (using the Interface
Information Bases, the Routable Address Topology Set, and the
Attached Network Set).
5. Protocol Parameters and Constants
The parameters and constants used in this specification are those
defined in [RFC6130] plus those defined in this section. The
separation in [RFC6130] into interface parameters, router parameters,
and constants is also used in this specification.
Similarly to the parameters in [RFC6130], parameters defined in this
specification MAY be changed dynamically by a router and need not be
the same on different routers, even in the same MANET, or, for
interface parameters, on different interfaces of the same router.
5.1. Protocol and Port Numbers
This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets MUST be sent either using the
"manet" protocol number or the "manet" UDP well-known port number, as
specified in [RFC5498].
TC messages and HELLO messages [RFC6130] MUST, in a given MANET, either both use IP or both use UDP, in order for it to be possible to combine messages of both protocols into the same [RFC5444] packet for transmission.5.2. Multicast Address
This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MAY be transmitted using the Link-Local multicast address "LL-MANET-Routers", as specified in [RFC5498].5.3. Interface Parameters
A single additional interface parameter is specified for OLSRv2 interfaces only.5.3.1. Received Message Validity Time
The following parameter manages the validity time of recorded received message information: RX_HOLD_TIME: The period after receipt of a message by the appropriate OLSRv2 interface of this router for which that information is recorded, in order that the message is recognized as having been previously received on this OLSRv2 interface. The following constraints apply to this parameter: o RX_HOLD_TIME > 0 o RX_HOLD_TIME SHOULD be greater than the maximum difference in time that a message may take to traverse the MANET, taking into account any message forwarding jitter as well as propagation, queuing, and processing delays.5.4. Router Parameters
The following router parameters are specified for routers.5.4.1. Local History Times
The following router parameter manages the time for which local information is retained:
O_HOLD_TIME:
The time for which a recently used and replaced originator address
is used to recognize the router's own messages.
The following constraint applies to this parameter:
o O_HOLD_TIME > 0
5.4.2. Link Metric Parameters
All routes found using this specification use a single link metric
type that is specified by the router parameter LINK_METRIC_TYPE,
which may take any value from 0 to 255, both inclusive.
5.4.3. Message Intervals
The following parameters regulate TC message transmissions by a
router. TC messages are usually sent periodically but MAY also be
sent in response to changes in the router's Neighbor Set and/or Local
Attached Network Set. In a highly dynamic network, and with a larger
value of the parameter TC_INTERVAL and a smaller value of the
parameter TC_MIN_INTERVAL, TC messages MAY be transmitted more often
in response to changes than periodically. However, because a router
has no knowledge of, for example, routers remote to it (i.e., beyond
two hops away) joining the network, TC messages MUST NOT be sent
purely responsively.
TC_INTERVAL:
The maximum time between the transmission of two successive TC
messages by this router. When no TC messages are sent in response
to local network changes (by design or because the local network
is not changing), then TC messages MUST be sent at a regular
interval TC_INTERVAL, possibly modified by jitter, as specified in
[RFC5148].
TC_MIN_INTERVAL:
The minimum interval between transmission of two successive TC
messages by this router. (This minimum interval MAY be modified
by jitter, as specified in [RFC5148].)
The following constraints apply to these parameters:
o TC_INTERVAL > 0
o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL
o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are included in TC messages, then TC_INTERVAL MUST be representable by way of the exponent-mantissa notation described in Section 5 of [RFC5497].5.4.4. Advertised Information Validity Times
The following parameters manage the validity time of information advertised in TC messages: T_HOLD_TIME: Used as the minimum value in the TLV with Type = VALIDITY_TIME included in all TC messages sent by this router. If a single value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used, then this will be the only value in that TLV. A_HOLD_TIME: The period during which TC messages are sent after they no longer have any advertised information to report but are sent in order to accelerate outdated information removal by other routers. The following constraints apply to these parameters: o T_HOLD_TIME > 0 o A_HOLD_TIME >= 0 o T_HOLD_TIME >= TC_INTERVAL o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME SHOULD be significantly greater than TC_INTERVAL; a value >= 3 x TC_INTERVAL is RECOMMENDED. o T_HOLD_TIME MUST be representable by way of the exponent-mantissa notation described in Section 5 of [RFC5497].5.4.5. Processing and Forwarding Validity Times
The following parameters manage the processing and forwarding validity time of recorded message information: P_HOLD_TIME: The period after receipt of a message that is processed by this router for which that information is recorded, in order that the message is not processed again if received again.
F_HOLD_TIME:
The period after receipt of a message that is forwarded by this
router for which that information is recorded, in order that the
message is not forwarded again if received again.
The following constraints apply to these parameters:
o P_HOLD_TIME > 0
o F_HOLD_TIME > 0
o Both of these parameters SHOULD be greater than the maximum
difference in time that a message may take to traverse the MANET,
taking into account any message forwarding jitter as well as
propagation, queuing, and processing delays.
5.4.6. Jitter
If jitter, as defined in [RFC5148], is used, then the governing
jitter parameters are as follows:
TP_MAXJITTER:
Represents the value of MAXJITTER used in [RFC5148] for
periodically generated TC messages sent by this router.
TT_MAXJITTER:
Represents the value of MAXJITTER used in [RFC5148] for externally
triggered TC messages sent by this router.
F_MAXJITTER:
Represents the default value of MAXJITTER used in [RFC5148] for
messages forwarded by this router. However, before using
F_MAXJITTER, a router MAY attempt to deduce a more appropriate
value of MAXJITTER, for example, based on any TLVs with Type =
INTERVAL_TIME or Type = VALIDITY_TIME contained in the message to
be forwarded.
For constraints on these parameters, see [RFC5148].
5.4.7. Hop Limit
The parameter TC_HOP_LIMIT is the hop limit set in each TC message.
TC_HOP_LIMIT MAY be a single fixed value or MAY be different in TC
messages sent by the same router. However, each other router, at any
hop count distance, MUST see a regular pattern of TC messages in
order that meaningful values of TLVs with Type = INTERVAL_TIME and
Type = VALIDITY_TIME at each hop count distance can be included as
defined in [RFC5497]. Thus, the pattern of TC_HOP_LIMIT MUST be
defined to have this property. For example, the repeating pattern
(255 4 4) satisfies this property (having period TC_INTERVAL at hop
counts up to 4, inclusive, and 3 x TC_INTERVAL at hop counts greater
than 4), but the repeating pattern (255 255 4 4) does not satisfy
this property because at hop counts greater than 4, message intervals
are alternately TC_INTERVAL and 3 x TC_INTERVAL.
The following constraints apply to this parameter:
o The maximum value of TC_HOP_LIMIT >= the network diameter in hops;
a value of 255 is RECOMMENDED. Note that if using a pattern of
different values of TC_HOP_LIMIT as described above, then only the
maximum value in the pattern is so constrained.
o All values of TC_HOP_LIMIT >= 2.
5.4.8. Willingness
Each router has two willingness parameters: WILL_FLOODING and
WILL_ROUTING, each of which MUST be in the range WILL_NEVER to
WILL_ALWAYS, inclusive.
WILL_FLOODING represents the router's willingness to be selected as a
flooding MPR and hence to participate in MPR flooding, in particular
of TC messages.
WILL_ROUTING represents the router's willingness to be selected as a
routing MPR and hence to be an intermediate router on routes.
In either case, the higher the value, the greater the router's
willingness to be a flooding or routing MPR, as appropriate. If a
router has a willingness value of WILL_NEVER (the lowest possible
value), it does not perform the corresponding task. A MANET using
this protocol with too many routers having either of the willingness
parameters WILL_FLOODING or WILL_ROUTING equal to WILL_NEVER will not
function; it MUST be ensured, by administrative or other means, that
this does not happen.
Note that the proportion at which the routers having a willingness
value equal to WILL_NEVER is "too many" depends on the network
topology -- which, in a MANET, may change dynamically. Willingness
is intended to enable that certain routers (e.g., routers that have
generous resources, such as a permanent power supply) can be
configured to assume more of the network operation, while others
(e.g., routers that have lesser resources, such as are battery
operated) can avoid such tasks. A general guideline would be that
only if a router is not actually able to assume the task (flooding or routing) should it be configured with the corresponding willingness WILL_NEVER. If a router has a willingness value equal to WILL_ALWAYS (the highest possible value), then it will always be selected as a flooding or routing MPR, as appropriate, by all symmetric 1-hop neighbors. In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS, flooding reduction will effectively be disabled, and flooding will perform as blind flooding. In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS, topology reduction will effectively be disabled, and all routers will advertise all of their links in TC messages. A router that has WILL_ROUTING = WILL_NEVER will not act as an intermediate router in the MANET. Such a router can act as a source, destination, or gateway to another routing domain. Different routers MAY have different values for WILL_FLOODING and/or WILL_ROUTING. The following constraints apply to these parameters: o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS5.5. Parameter Change Constraints
If protocol parameters are changed dynamically, then the constraints in this section apply. RX_HOLD_TIME * If RX_HOLD_TIME for an OLSRv2 interface changes, then the expiry time for all Received Tuples for that OLSRv2 interface MAY be changed. O_HOLD_TIME * If O_HOLD_TIME changes, then the expiry time for all Originator Tuples MAY be changed.
TC_INTERVAL
* If TC_INTERVAL increases, then the next TC message generated by
this router MUST be generated according to the previous,
shorter TC_INTERVAL. Additional subsequent TC messages MAY be
generated according to the previous, shorter, TC_INTERVAL.
* If TC_INTERVAL decreases, then the following TC messages from
this router MUST be generated according to the current,
shorter, TC_INTERVAL.
P_HOLD_TIME
* If P_HOLD_TIME changes, then the expiry time for all Processed
Tuples MAY be changed.
F_HOLD_TIME
* If F_HOLD_TIME changes, then the expiry time for all Forwarded
Tuples MAY be changed.
TP_MAXJITTER
* If TP_MAXJITTER changes, then the periodic TC message schedule
on this router MAY be changed immediately.
TT_MAXJITTER
* If TT_MAXJITTER changes, then externally triggered TC messages
on this router MAY be rescheduled.
F_MAXJITTER
* If F_MAXJITTER changes, then TC messages waiting to be
forwarded with a delay based on this parameter MAY be
rescheduled.
TC_HOP_LIMIT
* If TC_HOP_LIMIT changes, and the router uses multiple values
after the change, then message intervals and validity times
included in TC messages MUST be respected. The simplest way to
do this is to start any new repeating pattern of TC_HOP_LIMIT
values with its largest value.
LINK_METRIC_TYPE
* If LINK_METRIC_TYPE changes, then all link metric information
recorded by the router is invalid. The router MUST take the
following actions and all consequent actions described in
Section 17 and [RFC6130].
+ For each Link Tuple in any Link Set for an OLSRv2 interface,
either update L_in_metric (the value MAXIMUM_METRIC MAY be
used) or remove the Link Tuple from the Link Set.
+ For each Link Tuple that is not removed, set:
- L_out_metric := UNKNOWN_METRIC;
- L_SYM_time := EXPIRED;
- L_MPR_selector := false.
+ Remove all Router Topology Tuples, Routable Address Topology
Tuples, Attached Network Tuples, and Routing Tuples from
their respective Protocol Sets in the Topology Information
Base.
5.6. Constants
The following constants are specified for routers. Unlike router
parameters, constants MUST NOT change and MUST be the same on all
routers.
5.6.1. Link Metric Constants
The constant minimum and maximum link metric values are defined by:
o MINIMUM_METRIC := 1
o MAXIMUM_METRIC := 16776960
The symbolic value UNKNOWN_METRIC is defined in Section 6.1.
5.6.2. Willingness Constants
The constant minimum, RECOMMENDED default, and maximum willingness values are defined by: o WILL_NEVER := 0 o WILL_DEFAULT := 7 o WILL_ALWAYS := 155.6.3. Time Constant
The constant C (time granularity) is used as specified in [RFC5497]. It MUST be the same as is used by [RFC6130], with RECOMMENDED value: o C := 1/1024 second Note that this constant is used in the representation of time intervals. Time values (such as are stored in Protocol Tuples) are not so represented. A resolution of C in such values is sufficient (but not necessary) for such values.6. Link Metric Values
A router records a link metric value for each direction of a link of which it has knowledge. These link metric values are used to create metrics for routes by the addition of link metric values.6.1. Link Metric Representation
Link metrics are reported in messages using a compressed representation that occupies 12 bits, consisting of a 4-bit field and an 8-bit field. The compressed representation represents positive integer values with a minimum value of 1 and a maximum value that is slightly smaller than the maximum 24-bit value. Only those values that have exact representation in the compressed form are used. Route metrics are the summation of no more than 256 link metric values and can therefore be represented using no more than 32 bits. Link and route metrics used in the Information Bases defined in this specification refer to the uncompressed values, and arithmetic involving them does likewise and assumes full precision in the result. (How an implementation records the values is not part of this specification, as long as it behaves as if recording uncompressed values. An implementation can, for example, use 32-bit values for all link and route metrics.)
In some cases, a link metric value may be unknown. This is indicated in this specification by the symbolic value UNKNOWN_METRIC. An implementation may use any representation of UNKNOWN_METRIC as it is never included in messages or used in any computation. (Possible representations are zero or any value greater than the maximum representable metric value.)6.2. Link Metric Compressed Form
The 12-bit compressed form of a link metric uses a modified form of a representation with an 8-bit mantissa (denoted a) and a 4-bit exponent (denoted b). Note that if represented as the 12-bit value 256b+a, then the ordering of those 12-bit values is identical to the ordering of the represented values. The value so represented is (257+a)2^b - 256, where ^ denotes exponentiation. This has a minimum value (when a = 0 and b = 0) of MINIMUM_METRIC = 1 and a maximum value (when a = 255 and b = 15) of MAXIMUM_METRIC = 2^24 - 256. An algorithm for computing a and b for the smallest representable value not less than a link metric value v such that MINIMUM_METRIC <= v <= MAXIMUM_METRIC is: 1. Find the smallest integer b such that v + 256 <= 2^(b + 9). 2. Set a := (v - 256(2^b - 1)) / (2^b) - 1, rounded up to the nearest integer.7. Local Information Base
The Local Information Base, as defined for each router in [RFC6130], is extended by this protocol by: o Recording the router's originator address. The originator address MUST be unique to this router. It MUST NOT be used by any other router as an originator address. It MAY be included in any network address in any I_local_iface_addr_list of this router; it MUST NOT be included in any network address in any I_local_iface_addr_list of any other router. It MAY be included in, but MUST NOT be equal to, the AL_net_addr in any Local Attached Network Tuple in this or any other router. o The addition of an Originator Set, defined in Section 7.1, and a Local Attached Network Set, defined in Section 7.2.
All routable addresses of the router for which it is to accept IP packets as destination MUST be included in the Local Interface Set or the Local Attached Network Set.7.1. Originator Set
A router's Originator Set records addresses that were recently used as originator addresses by this router. If a router's originator address is immutable, then the Originator Set is always empty and MAY be omitted. It consists of Originator Tuples: (O_orig_addr, O_time) where: O_orig_addr is a recently used originator address; note that this does not include a prefix length. O_time specifies the time at which this Tuple expires and MUST be removed.7.2. Local Attached Network Set
A router's Local Attached Network Set records its local non-OLSRv2 interfaces via which it can act as a gateway to other networks. The Local Attached Network Set MUST be provided to this protocol and MUST reflect any changes in the router's status. (In cases where the router's configuration is static, the Local Attached Network Set will be constant; in cases where the router has no such non-OLSRv2 interfaces, the Local Attached Network Set will be empty.) The Local Attached Network Set is not modified by this protocol. This protocol will respond to (externally provided) changes to the Local Attached Network Set. It consists of Local Attached Network Tuples: (AL_net_addr, AL_dist, AL_metric) where: AL_net_addr is the network address of an attached network that can be reached via this router. This SHOULD be a routable address. It is constrained as described below. AL_dist is the number of hops to the network with network address AL_net_addr from this router. AL_metric is the metric of the link to the attached network with address AL_net_addr from this router.
Attached networks local to this router only (i.e., not reachable except via this router) SHOULD be treated as local non-MANET interfaces and added to the Local Interface Set, as specified in [RFC6130], rather than added to the Local Attached Network Set. Because an attached network is not specific to the router and may be outside the MANET, an attached network MAY also be attached to other routers. Routing to an AL_net_addr will use maximum prefix length matching; consequently, an AL_net_addr MAY include, but MUST NOT equal or be included in, any network address that is of any interface of any router (i.e., is included in any I_local_iface_addr_list) or equal any router's originator address. It is not the responsibility of this protocol to maintain routes from this router to networks recorded in the Local Attached Network Set. Local Attached Network Tuples are removed from the Local Attached Network Set only when the router's local attached network configuration changes, i.e., they are not subject to timer-based expiration or changes due to received messages.8. Interface Information Base
An Interface Information Base, as defined in [RFC6130], is maintained for each MANET interface. The Link Set and 2-Hop Set in the Interface Information Base for an OLSRv2 interface are modified by this protocol. In some cases, it may be convenient to consider these Sets as also containing these additional elements for other MANET interfaces, taking the indicated values on creation but never being updated.8.1. Link Set
The Link Set is modified by adding these additional elements to each Link Tuple: L_in_metric is the metric of the link from the OLSRv2 interface with addresses L_neighbor_iface_addr_list to this OLSRv2 interface; L_out_metric is the metric of the link to the OLSRv2 interface with addresses L_neighbor_iface_addr_list from this OLSRv2 interface; L_mpr_selector is a boolean flag, describing if this neighbor has selected this router as a flooding MPR, i.e., is a flooding MPR selector of this router.
L_in_metric will be specified by a process that is external to this specification. Any Link Tuple with L_status = HEARD or L_status = SYMMETRIC MUST have a specified value of L_in_metric if it is to be used by this protocol. A Link Tuple created (but not updated) by [RFC6130] MUST set: o L_in_metric := UNKNOWN_METRIC; o L_out_metric := UNKNOWN_METRIC; o L_mpr_selector := false.8.2. 2-Hop Set
The 2-Hop Set is modified by adding these additional elements to each 2-Hop Tuple: N2_in_metric is the neighbor metric from the router with address N2_2hop_iface_addr to the router with OLSRv2 interface addresses N2_neighbor_iface_addr_list; N2_out_metric is the neighbor metric to the router with address N2_2hop_iface_addr from the router with OLSRv2 interface addresses N2_neighbor_iface_addr_list. A 2-Hop Tuple created (but not updated) by [RFC6130] MUST set: o N2_in_metric := UNKNOWN_METRIC; o N2_out_metric := UNKNOWN_METRIC.9. Neighbor Information Base
A Neighbor Information Base, as defined in [RFC6130], is maintained for each router. It is modified by this protocol by adding these additional elements to each Neighbor Tuple in the Neighbor Set. In some cases, it may be convenient to consider these Sets as also containing these additional elements for other MANET interfaces, taking the indicated values on creation but never being updated. N_orig_addr is the neighbor's originator address, which may be unknown. Note that this originator address does not include a prefix length;
N_in_metric is the neighbor metric of any link from this neighbor
to an OLSRv2 interface of this router, i.e., the minimum of all
corresponding L_in_metric with L_status = SYMMETRIC and
L_in_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such
Link Tuples;
N_out_metric is the neighbor metric of any link from an OLSRv2
interface of this router to this neighbor, i.e., the minimum of
all corresponding L_out_metric with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no
such Link Tuples;
N_will_flooding is the neighbor's willingness to be selected as a
flooding MPR, in the range from WILL_NEVER to WILL_ALWAYS, both
inclusive, taking the value WILL_NEVER if no OLSRv2-specific
information is received from this neighbor;
N_will_routing is the neighbor's willingness to be selected as a
routing MPR, in the range from WILL_NEVER to WILL_ALWAYS, both
inclusive, taking the value WILL_NEVER if no OLSRv2-specific
information is received from this neighbor;
N_flooding_mpr is a boolean flag, describing if this neighbor is
selected as a flooding MPR by this router;
N_routing_mpr is a boolean flag, describing if this neighbor is
selected as a routing MPR by this router;
N_mpr_selector is a boolean flag, describing if this neighbor has
selected this router as a routing MPR, i.e., is a routing MPR
selector of this router.
N_advertised is a boolean flag, describing if this router has
elected to advertise a link to this neighbor in its TC messages.
A Neighbor Tuple created (but not updated) by [RFC6130] MUST set:
o N_orig_addr := unknown;
o N_in_metric := UNKNOWN_METRIC;
o N_out_metric := UNKNOWN_METRIC;
o N_will_flooding := WILL_NEVER;
o N_will_routing := WILL_NEVER;
o N_routing_mpr := false;
o N_flooding_mpr := false; o N_mpr_selector := false; o N_advertised := false. The Neighbor Information Base also includes a variable, the Advertised Neighbor Sequence Number (ANSN), whose value is included in TC messages to indicate the freshness of the information transmitted. The ANSN is incremented whenever advertised information (the originator and routable addresses included in Neighbor Tuples with N_advertised = true and local attached networks recorded in the Local Attached Network Set in the Local Information Base) changes, including addition or removal of such information.
(page 34 continued on part 3)
