RFC 7722

Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)

📅 published December 2015, from ietf

Multi-Topology Extension for OLSRv2 🦋

Okay bestie, the title block first, because it's the tea ☕:

  • RFC number and title: RFC 7722, Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
  • Authors: C. Dearlove (BAE Systems) and T. Clausen (LIX, Ecole Polytechnique)
  • Category: Experimental 🧪 (ISSN 2070-1721)
  • Date: December 2015
  • Updates: RFC 7188 and RFC 7631, by changing and extending their TLV registries and descriptions 🔧 The title block lists no Obsoletes entry.

Abstract ✨

This spec adds multi-topology support to OLSRv2, the routing protocol, so one network can keep several routing topologies going at once 🌸. The best part is that it stays interoperable with OLSRv2 routers that don't have this extension, so nobody gets left out 🫶. It also updates RFC 7188 and RFC 7631 by changing and adding to their TLV registries and descriptions.

Status of This Memo 📜

This document is not an Internet Standards Track spec. It's being shared for people to look at, try out in experiments, and evaluate 🔬.

It defines an Experimental Protocol for the Internet community. It's an IETF product, so it reflects the consensus of the IETF community, got public review, and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is on the road to becoming an Internet Standard, though, so check Section 2 of RFC 5741 for the details 💅.

For current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7722 💖.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read these carefully, because they spell out your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 📝.

Table of Contents 🗂️

   1. Introduction ....................................................4
      1.1. Motivation and Experimentation .............................4
   2. Terminology and Notation ........................................5
   3. Applicability Statement .........................................6
   4. Protocol Overview and Functioning ...............................6
   5. Parameters ......................................................8
   6. Information Bases ...............................................9
      6.1. Local Attached Network Set .................................9
      6.2. Link Sets ..................................................9
      6.3. 2-Hop Sets .................................................9
      6.4. Neighbor Set ...............................................9
      6.5. Router Topology Set .......................................10
      6.6. Routable Address Topology Set .............................10
      6.7. Attached Network Set ......................................10
      6.8. Routing Sets ..............................................11
   7. TLVs ...........................................................11
      7.1. Message TLVs ..............................................11
           7.1.1. MPR_TYPES TLV ......................................11
           7.1.2. MPR_WILLING TLV ....................................11
      7.2. Address Block TLVs ........................................12
           7.2.1. LINK_METRIC TLV ....................................12
           7.2.2. MPR TLV ............................................13
           7.2.3. GATEWAY TLV ........................................13
   8. HELLO Messages .................................................14
      8.1. HELLO Message Generation ..................................14
      8.2. HELLO Message Processing ..................................15
   9. TC Messages ....................................................15
      9.1. TC Message Generation .....................................15
      9.2. TC Message Processing .....................................16
   10. MPR Calculation ...............................................16
   11. Routing Set Calculation .......................................17
   12. Management Considerations .....................................17
   13. IANA Considerations ...........................................18
      13.1. Expert Review: Evaluation Guidelines .....................18
      13.2. Message TLV Types ........................................18
      13.3. Address Block TLV Types ..................................20
   14. Security Considerations .......................................21
   15. References ....................................................22
      15.1. Normative References .....................................22
      15.2. Informative References ...................................22
   Acknowledgments ...................................................23
   Authors' Addresses ................................................23

1. Introduction 🌷

OLSRv2 ([RFC7181]) is a proactive link state routing protocol built for Mobile Ad Hoc Networks (MANETs) ([RFC2501]) 🚀. Its big upgrade over the Experimental precursor, [RFC3626], is that it can use link metrics to pick routes that aren't just the fewest hops. Iconic behaviour, honestly 👑.

Here's the catch, though: OLSRv2 still uses one single link metric type for every route. In some MANETs, it would be way more useful to route packets using several link metric types. This spec adds an extension to OLSRv2 that makes that possible, while keeping interoperability with OLSRv2 routers that don't have the extension as close to perfect as it can get 🫶.

What does OLSRv2 do? It builds and maintains a Routing Set, which holds everything needed to fill an IP routing table 🗺️. This extension does the same job but multiplies it: it creates and maintains multiple Routing Sets, one for each link metric type that the router supports 💜.

1.1. Motivation and Experimentation 🔬

Multi-topology routing is a natural fit for a link state routing protocol, like OSPF (see [RFC4915]). The thing is, multi-topology routing for OLSRv2 doesn't have much operational, or even experimental, experience behind it yet 🥺. That's why this spec is being published: to gather that experience. The hope is that once there's enough solid experimental evidence, an OLSRv2 Multi-Topology Routing Extension can be proposed for the Standards Track 🎯.

Experiments with this extension are super encouraged 🙌. Reports are especially welcome when the experiments have planned objectives and scenarios, including link, position, and mobility information. Results that cover the following are of particular importance:

  • Operation in networks that contain both routers implementing this extension and routers implementing only [RFC7181]. In particular, are there any unexpected interactions that can break the network? 😱
  • Operation in networks with dynamic topologies, both due to mobility and due to link metric changes for reasons other than mobility.
  • Operation in realistic deployments, and details thereof, including how many concurrent topologies were required.
  • Behavior of Routing Sets, including measures of successful route establishment.

Reports on these are also valuable:

  • Which link metric types were useful, and how the metrics to associate with a given link were established.
  • How packet types were associated with link metric types (whether using Diffserv or an alternative mechanism).
  • Any data link-layer issues, and any cross-layer issues, including whether and how Neighborhood Discovery Protocol (NHDP) link quality was used.
  • Transport- and higher-layer issues observed, if any.
  • Resource requirements observed from running the protocol, including processing, storage, and bandwidth.
  • Network performance, including packet delivery results.
  • Any other implementation issues.

The first bullet above applies to plain OLSRv2 ([RFC7181]) as well as to this extension, and it could also apply to other MANET routing protocols 🦋. This spec also lets you experiment with link metric types that aren't compromises for handling multiple traffic types 🧚.

2. Terminology and Notation 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those capitalised words are the ones with real force, so treat them seriously 💅.

This spec uses the terminology of [RFC5444], [RFC6130], and [RFC7181], and those specs are the ones to read for what those terms mean 📚. On top of that, it adds the following terms:

Router - A MANET router that implements [RFC7181].

MT-OLSRv2 - The protocol defined in this specification as an extension to OLSRv2 [RFC7181].

This spec introduces the notation map[A -> B] for an associative mapping 🗂️. The domain (A) is always a set of link metric types the router supports, meaning either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as defined in Section 5. The codomain (B) is the set of all possible values of an appropriate type. Here, that type is always one of:

  • boolean (true or false),
  • willingness (a 4-bit unsigned integer from 0 to 15),
  • number of hops (an 8-bit unsigned integer from 0 to 255), or
  • link metric (either a representable link metric value, as described in [RFC7181], or UNKNOWN_METRIC).

3. Applicability Statement 🎀

This protocol works for any MANET where OLSRv2 already works (see [RFC7181], Section 3), with one twist: several topologies are kept at once, and each one is defined by a different link metric type 🌈.

The spec assumes, though doesn't cover itself, that the network layer can pick which topology each packet uses. One example is the Diffserv Code Point (DSCP) defined in [RFC2474] 💫. That selection MUST be consistent. Every router that receives a packet has to make the same choice of link metric type, so each packet sticks to a single topology. Otherwise a packet could end up "looping" around the network, and nobody wants that 😭.

4. Protocol Overview and Functioning ✨

Okay bestie, so the whole point of this spec is to extend OLSRv2 [RFC7181] so a router can set up and maintain multiple routing topologies in a MANET 🦋. Each topology gets its own link metric type. Routers can be part of some or all of these topologies, and each one keeps a Routing Set for every topology it's in, so packets get routed separately for each topology. It's giving organized chaos, but make it make sense 💅.

MT-OLSRv2 is designed to play nicely with plain OLSRv2 🫶. A MANET can have both MT-OLSRv2 routers (MT-OLSRv2 routers) and routers that don't implement MT-OLSRv2 and might not even know it exists (non-MT-OLSRv2 routers). A MANET can also be made of only MT-OLSRv2 routers. Either way, but especially when you have both kinds mixed together, you might need some management so the MANET actually functions the way it should and doesn't, for example, unnecessarily fragment 🧩. (Honestly this stuff already happens in an OLSRv2-based MANET using multiple interfaces, so it's not new drama 😭.)

OLSRv2 is an extension of NHDP [RFC6130] ✨. BUT this extension doesn't modify NHDP at all. It only changes the Protocol Sets that are specific to OLSRv2, or the elements in Protocol Tuples that OLSRv2 added and that NHDP neither includes nor uses. It also doesn't use or touch the link quality mechanism in [RFC6130] 🙈.

Each router running this spec picks a set of link metric types for each of its OLSRv2 interfaces 🎀. If every router in the MANET implements MT-OLSRv2, the spec doesn't restrict how those sets get picked. (The issues from the paragraph above still apply though, so don't get too comfy 👀.) If the MANET has non-MT-OLSRv2 routers, though, the single link metric those routers use has to be included in the set of link metrics for each OLSRv2 interface of an MT-OLSRv2 router that might be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANET 💜.

Each router then works out an incoming link metric for each link metric type it selected on each OLSRv2 interface 🌸. These get distributed using link metric TLVs that go in all HELLO messages sent on OLSRv2 interfaces and in all TC messages. Unless a router is only using the single metric type that non-MT-OLSRv2 routers use, both HELLO and TC messages from an MT-OLSRv2 router include an MPR_TYPES Message TLV. That TLV says "hey, I'm an MT-OLSRv2 router" and lists which metric types it supports (on the sending OLSRv2 interface, for a HELLO message) 🍓.

An MT-OLSRv2 router keeps track of the following for each supported neighbour metric type and for each symmetric 1-hop neighbor:

  • link and neighbour metric values,
  • routing MPR status,
  • routing MPR selector status, and
  • advertised neighbour status.

Each router can choose a different willingness to be a routing MPR for each link metric type it supports 🧚.

Real talk: a network using MT-OLSRv2 is usually going to need more management than one using plain OLSRv2 💀. In particular, using multiple metric types across the MANET has to be managed, either through administrative configuration or some other way. Same as other decisions you make with OLSRv2, a bad collective choice of metric type use can make the MANET anywhere from inefficient to totally nonfunctional 😱. So be careful picking the supported link metric types across the whole MANET 🔥.

The meanings of link metric types are totally up to the MANET operator 👑. For example, they could represent different types of packets, packets in streams of different rates, or packets with different trust requirements ✨. Heads up: packets generally won't get delivered to routers that don't support that link metric type, so the MANET, and the packets sent through it, need to be managed accordingly (especially if the MANET has any non-MT-OLSRv2 routers) 🫠.

5. Parameters 🎀

The parameters used in [RFC7181], and in its normative references, are used in this specification with the following changes ✨.

Each OLSRv2 interface supports a number of link metric types, which correspond to Type Extensions of the LINK_METRIC TLV defined in [RFC7181] 🦋. The router parameter LINK_METRIC_TYPE is used by routers that don't implement MT-OLSRv2, and it's used with that definition in this specification. For routers that DO implement MT-OLSRv2, it gets replaced by two things: an interface parameter array IFACE_METRIC_TYPES and a router parameter array ROUTER_METRIC_TYPES 💅. Each element in these arrays is a link metric type (aka a type extension used by the LINK_METRIC TLV [RFC7181]).

The interface parameter array IFACE_METRIC_TYPES holds the link metric types supported on that OLSRv2 interface. The router parameter array ROUTER_METRIC_TYPES is the union of all the IFACE_METRIC_TYPES 🌈. Both arrays MUST be without repetitions 🙅‍♀️.

If a deployment might have routers that don't implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as its first element, so the OLSRv2 interface can talk to those routers 🫶. In that case, ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE as its first element 💜.

Also, the router parameter WILL_ROUTING gets extended into an array of values, one for each link metric type in the router parameter list ROUTER_METRIC_TYPES 🍓.

6. Information Bases 🧚

The Information Bases specified in [RFC7181], which extend the ones specified in [RFC6130], get further extended here ✨. Except for the Routing Set, the extensions in this spec swap single values (boolean, willingness, number of hops, or link metric) from [RFC7181] for elements that hold multiple values (associative mappings from a set of metric types to their corresponding values). The subsections below break that down 💖.

Note that, just like in [RFC7181], an implementation is free to organize its internal data however it wants 🌸. It only needs to behave as if it were organized the way [RFC7181] and this specification describe 🫶.

6.1. Local Attached Network Set 🌈

Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops] 🦋.

Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] ✨.

Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link metric] 🎀.

Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link metric] 🍓.

The elements of L_in_metric MUST be set following the same rules that apply to setting the single element L_in_metric in [RFC7181] 👑.

6.3. 2-Hop Sets 🔥

Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 💜.

Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 🫶.

6.4. Neighbor Set 🧚

Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 🌸.

Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 🦋.

Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> willingness] ✨.

Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> boolean] 💅.

Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> boolean] 🎀.

Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> boolean] 🌈.

6.5. Router Topology Set 🍓

Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 🧚.

Heads up: some values of TR_metric can now be UNKNOWN_METRIC 😬. When you build a Routing Set and only use the matching link metric value from this mapping, Router Topology Tuples whose matching value in TR_metric is UNKNOWN_METRIC get ignored 🙈.

6.6. Routable Address Topology Set 💖

Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 🌸.

Same deal: some values of TA_metric can now be UNKNOWN_METRIC 🫠. When building a Routing Set with just the matching link metric value, Routable Address Topology Tuples whose matching value in TA_metric is UNKNOWN_METRIC get ignored 💜.

6.7. Attached Network Set 🦋

Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops] ✨.

Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link metric] 🫶.

Some values of AN_metric can now be UNKNOWN_METRIC too 👀. When building a Routing Set with just the matching link metric value, Attached Network Tuples whose matching value in AN_metric is UNKNOWN_METRIC get ignored 🔥.

6.8. Routing Sets 👑

There's a separate Routing Set for each link metric type in ROUTER_METRIC_TYPES 🌈. Each one is its own little kingdom 👑.

7. TLVs 💅

This spec makes the following additions and extensions to the TLVs defined in [RFC7181] 🎀.

7.1. Message TLVs 🧚

One new Message TLV is defined in this specification, and one existing Message TLV is extended by this specification 🍓.

7.1.1. MPR_TYPES TLV 💖

The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 interfaces and TC messages. A message MUST NOT contain more than one MPR_TYPES TLV 🙅‍♀️. Only one per message, no exceptions, bestie 🚫.

The presence of this TLV in a message indicates that the router supports MT-OLSRv2 🌸. It works the same way the presence of the MPR_WILLING TLV indicates that a router supports OLSRv2, as specified in [RFC7181] 🦋. For this reason, the MPR_TYPES TLV was defined with the same Type as the MPR_WILLING TLV, but with Type Extension = 1 ✨.

This TLV may take a Value field of any size 🫶. Each octet in its Value field contains a link metric type that is supported, either on any OLSRv2 interface (when it's in a TC message) or on the OLSRv2 interface where the HELLO message including this TLV gets sent 🌈. These octets MAY be in any order 🎀. But if there might be routers in the MANET that don't implement MT-OLSRv2, then the first octet MUST be LINK_METRIC_TYPE 💜. Non-negotiable, the first one has to be that 🔥.

7.1.2. MPR_WILLING TLV 💖

Okay bestie, the MPR_WILLING TLV lives in HELLO messages. It's specified in [RFC7181], and this spec extends it, which [RFC7188] makes possible. ✨

The meaning of this TLV doesn't change. [RFC7181] defines it and uses the whole single-octet Value field. Bits 0-3 of the Value field say how willing the router is to be a flooding TLV, and bits 4-7 say how willing it is to be a routing TLV. With this spec, those latter bits are read as the willingness to be a routing TLV using the link metric type LINK_METRIC_TYPE. 🦋

This spec also adds extra 4-bit sub-fields to the Value field. They start at bits 4-7 of the first octet and keep going into bits 0-3 of the second octet. They show willingness to be a routing MPR for each link metric type in this OLSRv2 interface's IFACE_METRIC_TYPES parameter, in the order listed in the included MPR_TYPES Message TLV. Here's the lowkey important bit: if there might be any non-MT-OLSRv2 routers around, LINK_METRIC_TYPE keeps occupying bits 4-7 of the first octet. 🫶

If the number of link metric types in IFACE_METRIC_TYPES is even, the last octet of a full-sized Value field has an unused 4-bit sub-field in bits 4-7. Those bits aren't used. They SHOULD all be cleared ('0') when sent, and they MUST be ignored when received. 💅

If the Value field in an MPR_WILLING TLV is shorter than its full length, [RFC7188] says the missing Value octets, meaning the missing willingness values, count as zero (WILL_NEVER). This is the correct behavior. (So an OLSRv2 router that isn't implementing MT-OLSRv2 won't act as a routing MPR for any link metric it doesn't recognize. Iconic. 👑)

7.2. Address Block TLVs 🎀

New Type Extensions are defined for the LINK_METRIC TLV from [RFC7181]. The Value fields of the MPR TLV and the GATEWAY TLV, both also defined in [RFC7181], are extended, as [RFC7188] enables. 🌸

The LINK_METRIC TLV is used in HELLO messages and TC messages. It's unchanged from its definition in [RFC7181]. 🧚

[RFC7181] only specified one Type Extension: 0, for "Link metric meaning as assigned by administrative action". This spec stretches that to the range 0-7. It works with any combination of Type Extensions, both inside and outside that range (assuming the ones outside are defined as specified in [RFC7181]). 💜

7.2.2. MPR TLV 🌈

The MPR TLV is used in HELLO messages. It indicates that the address it's associated with belongs to a symmetric 1-hop neighbor that has been selected as an MPR. 🍓

In [RFC7181], the Value field of this address block TLV is one octet long, with the values 1, 2, and 3 defined. [RFC7188] redefines the Value field as a bitfield. Bit 7 (the least significant bit) shows flooding status, bit 6 shows routing MPR status, and bits 5-0 are unallocated, while still respecting the meanings of the values 1, 2, and 3 from [RFC7181]. 🔥

This spec, enabled by [RFC7188], makes the MPR TLV's Value field variable-length. Bits are allocated in increasing significance, spread across as many octets as needed. In order, these bits say:

  • The neighbor with that network address has been selected as flooding MPR (1 bit).
  • The neighbor with that network address has been selected as routing MPR for each link metric type (1 bit each), in the same order as listed in the Value field of an MPR_TYPES Message TLV.

For interoperability with a router that isn't implementing MT-OLSRv2, the two least significant bits of the first octet in this TLV's Value field are the TLV Value of an MPR TLV generated according to [RFC7181], as updated by [RFC7188]. 🦋

7.2.3. GATEWAY TLV 🚪

The GATEWAY TLV is used in TC messages to show that a network address belongs to an attached network. ✨

[RFC7181] defines the Value field of this address block TLV as one octet long, containing the number of hops to that attached network. 💖

This spec, enabled by [RFC7188], lets the GATEWAY TLV have a variable-length Value field. That's needed when the number of hops to each attached network differs across link metric types. For interoperability with a router that isn't implementing MT-OLSRv2, the first octet in this TLV's Value field MUST be the TLV Value of the GATEWAY TLV generated according to [RFC7181]. 🫶

Any later octets in the TLV Value field show the number of hops to the attached network for each other link metric type. Link metric types, including the first one, are ordered as indicated in the Value field of an MPR_TYPES Message TLV. 🌸

+---------+---------------------------------------------------------+
|   Type  | Value                                                   |
+---------+---------------------------------------------------------+
| GATEWAY | Number of hops to attached network for each link metric |
|         | type.                                                   |
+---------+---------------------------------------------------------+

                   Table 1: GATEWAY TLV Definition

8. HELLO Messages 💌

The following changes apply to how HELLO messages are generated and processed compared to [RFC7181], for routers that implement MT-OLSRv2. 🎀

8.1. HELLO Message Generation 🛠️

A generated HELLO message to be sent on an OLSRv2 interface (whose IFACE_METRIC_TYPES parameter will be the one used) gets extended by:

  • Adding an MPR_TYPES Message TLV. The Value octets will be the link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE. 🍓
  • Extending the MPR_WILLING Message TLV Value field to report the willingness values from the WILL_ROUTING parameter list that correspond to the link metric types in IFACE_METRIC_LIST. They go in the same order as reported in the MPR_TYPES TLV, and each value (including one representing WILL_FLOODING) takes up 4 bits. 🌈
  • Including LINK_METRIC Address Block TLVs that report all values in the L_in_metric, L_out_metric, N_in_metric, and N_out_metric elements that are not equal to UNKNOWN_METRIC. The TLV Type Extension is the link metric type, and otherwise the rules for such inclusions from [RFC7181] apply. 📏
  • Including MPR Address Block TLVs such that, for each link metric type in IFACE_METRIC_TYPES and for the choice of flooding MPRs, the indicated addresses MUST be of the MPRs in an MPR set as specified for a single link metric type in [RFC7181]. 🦋

8.2. HELLO Message Processing 🧠

When a HELLO message comes in on an OLSRv2 interface, a router implementing MT-OLSRv2 MUST do the following, on top of the processing described in [RFC7181]:

  1. If in this deployment there might be routers that don't implement MT-OLSRv2, the HELLO message contains an MPR_TYPES Message TLV, and the first link metric type it reports is not LINK_METRIC_TYPE, then the HELLO message MUST be silently discarded. 🙈
  2. Determine the list of link metric types supported by the sending router on its corresponding OLSRv2 interface. Use an MPR_TYPES Message TLV (if present), or else the single link metric type LINK_METRIC_TYPE. 💜
  3. For all link metric types that are reported and supported by the receiving router, set the appropriate L_out_metric, N_in_metric, N_out_metric, N_will_routing, N_mpr_selector, N_advertised, N2_in_metric, and N2_out_metric elements. Use the rules for setting the single elements of those types specified in [RFC7181]. ✨
  4. For any other metric types supported only by the receiving router (meaning in IFACE_METRIC for the receiving OLSRv2 interface), set the elements listed in the previous point to their default values. Those are UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or false. 🌸

9. TC Messages 📡

The following changes apply to how TC messages are generated and processed compared to [RFC7181], by routers that implement MT-OLSRv2. 💅

9.1. TC Message Generation 🎁

A generated TC message gets extended by:

  • Adding an MPR_TYPES TLV. The Value octets will be the link metric types in ROUTER_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE. 🍓
  • Including LINK_METRIC TLVs that report all values of N_out_metric that are not equal to UNKNOWN_METRIC. The TLV Type Extension is the link metric type, and otherwise the rules for such inclusions from [RFC7181] apply. 📏
  • Including a number of hops per reported link metric type (listed in an MPR_TYPES Message TLV) in the Value field of each GATEWAY TLV included. They go in the same order as reported in the MPR_TYPES TLV. 🌈

9.2. TC Message Processing 🧩

When a TC message is received, a router implementing this extension MUST do the following, on top of the processing specified in [RFC7181]:

  • If in this deployment there might be routers that don't implement MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and the first link metric type it reports is not LINK_METRIC_TYPE, then the TC message MUST be silently discarded. 🙈
  • For all link metric types that are reported and supported by the receiving router, set the appropriate TR_metric, TA_metric, AN_dist, and AN_metric elements. Use the rules for setting the single elements of those types specified in [RFC7181]. 🦋
  • For any other metric types supported by the receiving router that don't have an advertised outgoing neighbor metric of that type, set the corresponding elements of TR_metric, TA_metric, and AN_metric to UNKNOWN_METRIC. (The corresponding element of AN_dist may be set to any value.) 💫

10. MPR Calculation 🧮

Routing MPRs get calculated for each link metric type in ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 interfaces that don't support that link metric type are not considered. The determined status (routing MPR or not routing MPR) for each link metric type gets recorded in the relevant element of N_routing_mpr. 🌟

Each router may make its own decision about whether or not to use a link metric, or link metrics, for flooding MPR calculation. If using link metric(s), each router decides which one(s) and how they're used. These decisions MUST be made in a way that ensures flooded messages reach the same symmetric 2-hop neighbors as they would for a router not supporting MT-OLSRv2. 🤝

Note that a 2-Hop Tuple in the Information Base for a given OLSRv2 interface might not support any of the link metric types in the router's corresponding IFACE_METRIC_TYPES. Even so, that 2-Hop Tuple MUST be considered when determining flooding MPRs. 🫶

11. Routing Set Calculation ✨

Okay so, a Routing Set gets calculated for every link metric type listed in ROUTER_METRIC_TYPES 💅. The calculation may follow [RFC7181], with one twist: wherever an element is now stored as a map, you grab the value from that map for the selected link metric type. And if that value is UNKNOWN_METRIC, that protocol Tuple just gets ignored for the calculation 🙈

12. Management Considerations 🎀

Bestie, MT-OLSRv2 may need way more babysitting than unextended OLSRv2 🥺 A MANET running MT-OLSRv2 needs these management considerations:

  • Deciding which link metric, and therefore which Routing Set, to use for received packets, and so how to use the Routing Sets to configure the network layer (IP). All routers MUST make the same decision for the same packet. An obvious approach is to map each DSCP [RFC2474] to a single link metric. (This may be a many-to-one mapping.)

Let me fix that: the keyword must be capitalised and unwrapped, so here is the corrected bullet:

  • Deciding which link metric, and therefore which Routing Set, to use for received packets, and so how to use the Routing Sets to configure the network layer (IP). All routers MUST make the same decision for the same packet. An obvious approach is to map each DSCP [RFC2474] to a single link metric. (This may be a many-to-one mapping.)
  • Selecting which link metrics to support on each OLSRv2 interface and implementing that decision. (Different interfaces may have different physical and data link-layer properties, and this may inform the selection of link metrics to support, and their values.) If the MANET might contain non-MT-OLSRv2 routers, which are also subject to management, then the rules in this specification for link metric assignment to OLSRv2 interfaces for that case MUST be followed.
  • Ensuring that the MANET is sufficiently connected, by ensuring that, for example, sufficiently many routers implement each metric type required. (This is easier in, for example, a denser network.) Note that if there is any possibility that there are routers not implementing MT-OLSRv2, then the MANET will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE, but this will only serve to deliver packets that use that link metric type. 💖
  • Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets that will be routed by a topology that they are not part of. However, if that were to happen, then such packets will be routed until either they reach their destination or they reach an MT-OLSRv2 router. In the latter case, the packet then either will be dropped (if that MT-OLSRv2 router is not part of that topology, or is not aware of the destination within that topology) or will be routed by that topology to the destination. Such a packet will not loop. 🦋
  • If a packet is created for a destination that is not part of the corresponding topology, then it may or may not be delivered (if the originating router is a non-MT-OLSRv2 router) or will not be sent (if the originating router is an MT-OLSRv2 router). Routers SHOULD be managed so that topologies are as complete as possible and that packets are not sent if they may not be delivered. In particular, non-MT-OLSRv2 routers SHOULD only send packets that will be routed using the topology using the link metric type LINK_METRIC_TYPE. 🧚

13. IANA Considerations 📋

Okay, this part is the registry paperwork 🍓 This specification adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV, using a new name. It also modifies the Value field of an existing Message TLV and that of an existing Address Block TLV. Finally, this specification makes additional allocations from the LINK_METRIC Address Block TLV Type registry. ✨

13.1. Expert Review: Evaluation Guidelines

For the registry where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444] and [RFC7631]. 🫶

13.2. Message TLV Types

This specification modifies the Message TLV Type 7, replacing Table 4 of [RFC7631] by Table 2, changing the description of the Type Extension MPR_WILLING, and adding the Type Extension TLV_TYPES. Each of these TLVs MUST NOT be included more than once in a Message TLV Block. 💅

   +-----------+-------------+-------------------------+---------------+
   |    Type   |     Name    | Description             | Reference     |
   | Extension |             |                         |               |
   +-----------+-------------+-------------------------+---------------+
   |     0     | MPR_WILLING | First (most             | [RFC7181]     |
   |           |             | significant) half-octet | [RFC7631]     |
   |           |             | of Value field          | RFC 7722      |
   |           |             | specifies the           |               |
   |           |             | originating router's    |               |
   |           |             | willingness to act as a |               |
   |           |             | flooding MPR;           |               |
   |           |             | subsequent half-octets  |               |
   |           |             | specify the originating |               |
   |           |             | router's willingness to |               |
   |           |             | act as a routing MPR,   |               |
   |           |             | either for the link     |               |
   |           |             | metric types reported   |               |
   |           |             | in an MPR_TYPES TLV (in |               |
   |           |             | the same order), or (if |               |
   |           |             | no MPR_TYPES TLV is     |               |
   |           |             | present) for the single |               |
   |           |             | administratively agreed |               |
   |           |             | link metric type        |               |
   |     1     |  MPR_TYPES  | The link metric types   | RFC 7722      |
   |           |             | supported on this       |               |
   |           |             | OLSRv2 interface of     |               |
   |           |             | this router (one octet  |               |
   |           |             | each).                  |               |
   |   2-223   |             | Unassigned              |               |
   |  224-255  |             | Reserved for            | [RFC7181]     |
   |           |             | Experimental Use        |               |
   +-----------+-------------+-------------------------+---------------+

                Table 2: Type 7 Message TLV Type Extensions

13.3. Address Block TLV Types

Table 7 of [RFC7188] is replaced by Table 3. 🌸

   +-------+-------+----------+----------------------------------------+
   |  Bit  | Value |   Name   |               Description              |
   +-------+-------+----------+----------------------------------------+
   | First | First | Flooding |   If set, then the neighbor with that  |
   | octet | octet |          |  network address has been selected as  |
   | bit 7 |  0x01 |          |              flooding MPR              |
   |  From |  From |  Routing |   If set, then the neighbor with that  |
   | first | first |          |  network address has been selected as  |
   | octet | octet |          |    routing MPR, either for the link    |
   | bit 6 |  0x02 |          |  metric types reported in an MPR_TYPES |
   |       |       |          |   TLV (in the same order), or (if no   |
   |       |       |          |  MPR_TYPES TLV is present) then (first |
   |       |       |          |    octet bit 6, value 0x02) for the    |
   |       |       |          |   single administratively agreed link  |
   |       |       |          |               metric type              |
   +-------+-------+----------+----------------------------------------+

                        Table 3: MPR TLV Bit Values

Table 14 of [RFC7631] is replaced by Table 4. The only changes are to the Description and the References for the GATEWAY TLV. 🍭

   +-----------+---------+-----------------------------+---------------+
   |    Type   |   Name  | Description                 | References    |
   | Extension |         |                             |               |
   +-----------+---------+-----------------------------+---------------+
   |     0     | GATEWAY | Specifies that a given      | [RFC7181]     |
   |           |         | network address is reached  | RFC 7722      |
   |           |         | via a gateway on the        |               |
   |           |         | originating router.  The    |               |
   |           |         | number of hops is indicated |               |
   |           |         | by the Value field, one     |               |
   |           |         | octet per link metric type  |               |
   |           |         | reported in an MPR_TYPES    |               |
   |           |         | Message TLV (in the same    |               |
   |           |         | order) or (if no MPR_TYPES  |               |
   |           |         | Message TLV is present)     |               |
   |           |         | using a single octet        |               |
   |   1-223   |         | Unassigned                  |               |
   |  224-255  |         | Reserved for Experimental   | [RFC7631]     |
   |           |         | Use                         |               |
   +-----------+---------+-----------------------------+---------------+

            Table 4: Type 10 Address Block TLV Type Extensions

Table 13 of [RFC7181] is replaced by Table 5. The only change is that 8 Type Extensions are allocated as assigned by administrative action, in order to support administratively determined multi-topologies. 🌈

   +-------------+------+-----------+-------------------+--------------+
   |     Name    | Type |    Type   | Description       | Allocation   |
   |             |      | Extension |                   | Policy       |
   +-------------+------+-----------+-------------------+--------------+
   | LINK_METRIC |   7  |    0-7    | Link metric       |              |
   |             |      |           | meaning assigned  |              |
   |             |      |           | by administrative |              |
   |             |      |           | action.           |              |
   | LINK_METRIC |   7  |   8-223   | Unassigned.       | Expert       |
   |             |      |           |                   | Review       |
   | LINK_METRIC |   7  |  224-255  | Unassigned.       | Experimental |
   |             |      |           |                   | Use          |
   +-------------+------+-----------+-------------------+--------------+

          Table 5: Address Block TLV Type assignment: LINK_METRIC

14. Security Considerations 🔐✨

okay bestie, this extension lets a router support more than one link metric type for each link it advertises in HELLO and TC messages 🦋. Different routers can even support different sets of types 💅. The extra link metric values come along as additional TLVs in the messages a router sends, and those TLVs report the known values for all of its supported types 🌈.

HELLO and TC message processing gets a simple upgrade 🎀. For each supported type, the router just records every link metric value it receives for each link. After that, the protocol-internal stuff (specifically the MPR set and shortest path calculations) works exactly as specified in [RFC7181], once for each link metric type the router supports 💜.

So the security considerations from [RFC7181] are directly applicable to MT-OLSRv2 🔥. That includes the security architecture and the mandatory security mechanisms, so everything from that document carries over, no cap 🧚.

Also, this extension does not add any extra vulnerabilities beyond the ones in [RFC7181] 🙈. Each link metric type is used independently, and each one could have been the only link metric type supported by an [RFC7181] implementation getting the same information. Received information of an unsupported type is ignored by all routers, so nothing sneaky happens there 💀✨.

15. References 📚

15.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
           "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
           Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
           <http://www.rfc-editor.org/info/rfc5444>.

[RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
           Network (MANET) Neighborhood Discovery Protocol (NHDP)",
           RFC 6130, DOI 10.17487/RFC6130, April 2011,
           <http://www.rfc-editor.org/info/rfc6130>.

[RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
           "The Optimized Link State Routing Protocol Version 2",
           RFC 7181, DOI 10.17487/RFC7181, April 2014,
           <http://www.rfc-editor.org/info/rfc7181>.

[RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routing
           Protocol Version 2 (OLSRv2) and MANET Neighborhood
           Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
           DOI 10.17487/RFC7188, April 2014,
           <http://www.rfc-editor.org/info/rfc7188>.

[RFC7631]  Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad
           Hoc Network (MANET) Generalized Packet/Message Format",
           RFC 7631, DOI 10.17487/RFC7631, September 2015,
           <http://www.rfc-editor.org/info/rfc7631>.

15.2. Informative References

[RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
           "Definition of the Differentiated Services Field (DS
           Field) in the IPv4 and IPv6 Headers", RFC 2474,
           DOI 10.17487/RFC2474, December 1998,
           <http://www.rfc-editor.org/info/rfc2474>.

[RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
           (MANET): Routing Protocol Performance Issues and
           Evaluation Considerations", RFC 2501,
           DOI 10.17487/RFC2501, January 1999,
           <http://www.rfc-editor.org/info/rfc2501>.

[RFC3626]  Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link
           State Routing Protocol (OLSR)", RFC 3626,
           DOI 10.17487/RFC3626, October 2003,
           <http://www.rfc-editor.org/info/rfc3626>.

[RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
           Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
           RFC 4915, DOI 10.17487/RFC4915, June 2007,
           <http://www.rfc-editor.org/info/rfc4915>.

Acknowledgments 🫶

the authors want to thank (in alphabetical order) these amazing people for their discussions and suggestions 💖: Juliusz Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems), Susan Hares (Huawei), and Henning Rogge (FGAN) 👑.

Authors' Addresses 🌸

Christopher Dearlove
BAE Systems Applied Intelligence Laboratories
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom

Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI:   http://www.baesystems.com/


Thomas Heide Clausen
LIX, Ecole Polytechnique

Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI:   http://www.ThomasClausen.org/
📦 where this page comes from