tech-invite   World Map     

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

RFC 7181

 
 
 

The Optimized Link State Routing Protocol Version 2

Part 2 of 5, p. 10 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.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.)

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

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

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

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

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

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

Next RFC Part