summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7722.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7722.txt')
-rw-r--r--doc/rfc/rfc7722.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7722.txt b/doc/rfc/rfc7722.txt
new file mode 100644
index 0000000..331d790
--- /dev/null
+++ b/doc/rfc/rfc7722.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Dearlove
+Request for Comments: 7722 BAE Systems
+Updates: 7188, 7631 T. Clausen
+Category: Experimental LIX, Ecole Polytechnique
+ISSN: 2070-1721 December 2015
+
+
+ Multi-Topology Extension
+ for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
+
+Abstract
+
+ This specification describes an extension to the Optimized Link State
+ Routing Protocol version 2 (OLSRv2) to support multiple routing
+ topologies, while retaining interoperability with OLSRv2 routers that
+ do not implement this extension.
+
+ This specification updates RFCs 7188 and 7631 by modifying and
+ extending TLV registries and descriptions.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7722.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 1]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+Copyright Notice
+
+ 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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 2]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+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
+
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 3]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+1. Introduction
+
+ The Optimized Link State Routing Protocol version 2 [RFC7181]
+ (OLSRv2) is a proactive link state routing protocol designed for use
+ in Mobile Ad Hoc Networks (MANETs) [RFC2501]. One of the significant
+ improvements of OLSRv2 over its Experimental precursor [RFC3626] is
+ the ability of OLSRv2 to use link metrics to select routes other than
+ minimum hop routes.
+
+ A limitation that remains in OLSRv2 is that it uses a single link
+ metric type for all routes. However, in some MANETs it would be
+ desirable to be able to route packets using more than one link metric
+ type. This specification describes an extension to OLSRv2 that is
+ designed to permit this, while maintaining maximal interoperability
+ with OLSRv2 routers not implementing this extension.
+
+ The purpose of OLSRv2 can be described as to create and maintain a
+ Routing Set, which contains all the necessary information to populate
+ an IP routing table. In a similar way, the role of this extension
+ can be described as to create and maintain multiple Routing Sets, one
+ for each link metric type supported by the router maintaining the
+ sets.
+
+1.1. Motivation and Experimentation
+
+ Multi-topology routing is a natural extension to a link state routing
+ protocol, such as OSPF (see [RFC4915]). However multi-topology
+ routing for OLSRv2 does not yet benefit from extensive operational,
+ or even experimental, experience. This specification is published to
+ facilitate collecting such experience, with the intent that once
+ suitable experimental evidence has been collected, an OLSRv2 Multi-
+ Topology Routing Extension will be proposed for advancement onto the
+ Standards Track.
+
+ Any experiments using this protocol extension are encouraged.
+ Reports from such experiments planned with pre-specified objectives
+ and scenarios (including link, position, and mobility information)
+ are particularly encouraged. Results from such experiments,
+ documenting the following, are of particular importance:
+
+ o 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?
+
+ o Operation in networks with dynamic topologies, both due to
+ mobility and due to link metric changes for reasons other than
+ mobility.
+
+
+
+
+Dearlove & Clausen Experimental [Page 4]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ o Operation in realistic deployments, and details thereof, including
+ how many concurrent topologies were required.
+
+ o Behavior of Routing Sets, including measures of successful route
+ establishment.
+
+ In addition, reports from experiments covering the following are also
+ of value:
+
+ o Which link metric types were useful, and how the metrics to
+ associate with a given link were established.
+
+ o How packet types were associated with link metric types (whether
+ using Diffserv or an alternative mechanism).
+
+ o Any data link-layer issues, and any cross-layer issues, including
+ whether and how Neighborhood Discovery Protocol (NHDP) link
+ quality was used.
+
+ o Transport- and higher-layer issues observed, if any.
+
+ o Resource requirements observed from running the protocol,
+ including processing, storage, and bandwidth.
+
+ o Network performance, including packet delivery results.
+
+ o Any other implementation issues.
+
+ The first bullet in the list directly above applies to unextended
+ OLSRv2 [RFC7181] as well as with this extension, and potentially to
+ other MANET routing protocols. This specification also allows
+ experimentation with link metric types that are not 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].
+
+ This specification uses the terminology of [RFC5444], [RFC6130], and
+ [RFC7181], which is to be interpreted as described in those
+ specifications.
+
+ Additionally, this specification uses the following terminology:
+
+ Router - A MANET router that implements [RFC7181].
+
+
+
+Dearlove & Clausen Experimental [Page 5]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ MT-OLSRv2 - The protocol defined in this specification as an
+ extension to OLSRv2 [RFC7181].
+
+ This specification introduces the notation map[A -> B] to represent
+ an associative mapping. The domain of this mapping (A) is, in this
+ specification, always a set of link metric types that the router
+ supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as
+ defined in Section 5. The codomain of this mapping (B) is a set of
+ all possible values of an appropriate type. In this specification,
+ this type is always one of:
+
+ o boolean (true or false),
+
+ o willingness (a 4-bit unsigned integer from 0 to 15),
+
+ o number of hops (an 8-bit unsigned integer from 0 to 255), or
+
+ o link metric (either a representable link metric value, as
+ described in [RFC7181], or UNKNOWN_METRIC).
+
+3. Applicability Statement
+
+ The protocol described in this specification is applicable to a MANET
+ for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3),
+ but in which multiple topologies are maintained, each characterized
+ by a different choice of link metric type. It is assumed, but
+ outside the scope of this specification, that the network layer is
+ able to choose which topology to use for each packet, for example,
+ using the Diffserv Code Point (DSCP) defined in [RFC2474]. This
+ selection of topology MUST be consistent; that is, each router
+ receiving a packet must make the same choice of link metric type, in
+ order that each packet uses a single topology. This is necessary to
+ avoid the possibility of a packet "looping" in the network.
+
+4. Protocol Overview and Functioning
+
+ The purpose of this specification is to extend OLSRv2 [RFC7181] so as
+ to enable a router to establish and maintain multiple routing
+ topologies in a MANET, each topology associated with a link metric
+ type. Routers in the MANET may each form part of some or all of
+ these topologies, and each router will maintain a Routing Set for
+ each topology that it forms part of, allowing separate routing of
+ packets for each topology.
+
+ MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be
+ created containing both routers that implement MT-OLSRv2 (MT-OLSRv2
+ routers) and routers that do not implement MT-OLSRv2 and may be
+ unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be
+
+
+
+Dearlove & Clausen Experimental [Page 6]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ created that are known to contain only MT-OLSRv2 routers. In both
+ cases, but especially where a MANET contains both MT-OLSRv2 routers
+ and non-MT-OLSRv2 routers, management may be required to ensure that
+ the MANET will function as required, and will not, for example,
+ unnecessarily fragment. (Such issues already arise in an
+ OLSRv2-based MANET using multiple interfaces.)
+
+ OLSRv2 is an extension of NHDP [RFC6130]. However, the extension in
+ this specification does not modify NHDP, it only modifies Protocol
+ Sets that are specific to OLSRv2, or elements in Protocol Tuples that
+ were added by OLSRv2 and that are neither included in nor used by
+ NHDP. In addition it does not use or modify the link quality
+ mechanism in [RFC6130].
+
+ Each router implementing this specification selects a set of link
+ metric types for each of its OLSRv2 interfaces. If all routers in
+ the MANET implement MT-OLSRv2, then there are no restrictions within
+ this specification on how these sets of link metrics are selected.
+ (However, the issues described in the preceding paragraph still
+ apply.) On the other hand, in MANETs containing non-MT-OLSRv2
+ routers, the single link metric used by these non-MT-OLSRv2 routers
+ must be included in the set of link metrics for each OLSRv2 interface
+ of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a
+ non-MT-OLSRv2 router in the MANET.
+
+ Each router then determines an incoming link metric for each link
+ metric type selected for each of its OLSRv2 interfaces. These link
+ metrics are distributed using link metric TLVs contained in all HELLO
+ messages sent on OLSRv2 interfaces and in all TC messages. Unless
+ using only the single metric type used by non-MT-OLSRv2 routers, both
+ HELLO and TC messages generated by an MT-OLSRv2 router include an
+ MPR_TYPES Message TLV that indicates that this is an MT-OLSRv2 router
+ and which metric types it supports (on the sending OLSRv2 interface
+ for a HELLO message).
+
+ An MT-OLSRv2 router maintains, for each supported neighbour metric
+ type and for each symmetric 1-hop neighbor, the following:
+
+ o link and neighbour metric values,
+
+ o routing MPR status,
+
+ o routing MPR selector status, and
+
+ o advertised neighbour status.
+
+ Each router may choose a different willingness to be a routing MPR
+ for each link metric type that it supports.
+
+
+
+Dearlove & Clausen Experimental [Page 7]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ A network using MT-OLSRv2 will usually require greater management
+ than one using unmodified OLSRv2. In particular, the use of multiple
+ metric types across the MANET must be managed, by administrative
+ configuration or otherwise. As also for other decisions that may be
+ made when using OLSRv2, a bad collective choice of metric type use
+ will make the MANET anywhere from inefficient to nonfunctional, so
+ care will be needed in selecting supported link metric types across
+ the MANET.
+
+ The meanings of link metric types are at the discretion of the MANET
+ operator. They could be used, for example, to represent packets of
+ different types, packets in streams of different rates, or packets
+ with different trust requirements. Note that packets will generally
+ not be delivered to routers that do not support that link metric
+ type, and the MANET, and the packets sent in it, will need to be
+ managed accordingly (especially if the MANET contains 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 will support a number of link metric types,
+ corresponding to Type Extensions of the LINK_METRIC TLV defined in
+ [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers
+ that do not implement MT-OLSRv2, and used with that definition in
+ this specification, is replaced in routers implementing MT-OLSRv2 by
+ 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 (i.e., a type extension used by the LINK_METRIC
+ TLV [RFC7181]).
+
+ The interface parameter array IFACE_METRIC_TYPES contains the link
+ metric types supported on that OLSRv2 interface. The router
+ parameter array ROUTER_METRIC_TYPES is the union of all of the
+ IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.
+
+ If in a given deployment there might be routers that do not implement
+ MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as
+ its first element, so that the OLSRv2 interface can communicate with
+ those routers. In that case, ROUTER_METRIC_TYPES MUST also include
+ LINK_METRIC_TYPE as its first element.
+
+ In addition, the router parameter WILL_ROUTING is extended to an
+ array of values, one each for each link metric type in the router
+ parameter list ROUTER_METRIC_TYPES.
+
+
+
+
+Dearlove & Clausen Experimental [Page 8]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+6. Information Bases
+
+ The Information Bases specified in [RFC7181], which extend those
+ specified in [RFC6130], are further extended in this specification.
+ With the exception of the Routing Set, the extensions in this
+ specification are the replacement of single values (boolean,
+ willingness, number of hops, or link metric) from [RFC7181] with
+ elements representing multiple values (associative mappings from a
+ set of metric types to their corresponding values). The following
+ subsections detail these extensions.
+
+ Note that, as in [RFC7181], an implementation is free to organize its
+ internal data in any manner it chooses; it needs only to behave as if
+ it were organized as described in [RFC7181] and this specification.
+
+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].
+
+6.2. Link Sets
+
+ 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 the setting of 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].
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 9]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ 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].
+
+ Note that some values of TR_metric may now take the value
+ UNKNOWN_METRIC. When used to construct a Routing Set, where just the
+ corresponding link metric value from this mapping is used, Router
+ Topology Tuples whose corresponding value from TR_metric is
+ UNKNOWN_METRIC are ignored.
+
+6.6. Routable Address Topology Set
+
+ Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link
+ metric].
+
+ Note that some values of TA_metric may now take the value
+ UNKNOWN_METRIC. When used to construct a Routing Set, where just the
+ corresponding link metric value from this mapping is used, Routable
+ Address Topology Tuples whose corresponding value from TA_metric is
+ UNKNOWN_METRIC are 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].
+
+ Note that some values of AN_metric may now take the value
+ UNKNOWN_METRIC. When used to construct a Routing Set, where just the
+ corresponding link metric value from this mapping is used, Attached
+
+
+
+Dearlove & Clausen Experimental [Page 10]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ Network Tuples whose corresponding value from AN_metric is
+ UNKNOWN_METRIC are ignored.
+
+6.8. Routing Sets
+
+ There is a separate Routing Set for each link metric type in
+ ROUTER_METRIC_TYPES.
+
+7. TLVs
+
+ This specification 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.
+
+ The presence of this TLV in a message is used to indicate that the
+ router supports MT-OLSRv2, in the same way that the presence of the
+ MPR_WILLING TLV is used to indicate that the router supports OLSRv2,
+ as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has
+ been 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 will contain a link metric type that is supported, either on
+ any OLSRv2 interface, when included in a TC message, or on the OLSRv2
+ interface on which a HELLO message including this TLV is sent. These
+ octets MAY be in any order, but if there might be routers in the
+ MANET that do not implement MT-OLSRv2, then the first octet MUST be
+ LINK_METRIC_TYPE.
+
+7.1.2. MPR_WILLING TLV
+
+ The MPR_WILLING TLV, which is used in HELLO messages, is specified in
+ [RFC7181], and extended in this specification as enabled by
+ [RFC7188].
+
+ The interpretation of this TLV, which is specified by [RFC7181] and
+ uses all of its single-octet Value field, is unchanged. That
+ interpretation uses bits 0-3 of its Value field to specify its
+
+
+
+Dearlove & Clausen Experimental [Page 11]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ willingness to be a flooding TLV, and bits 4-7 of its Value field to
+ be a routing TLV. Those latter bits are, when using this
+ specification, interpreted as its willingness to be a routing TLV
+ using the link metric type LINK_METRIC_TYPE.
+
+ The extended use of this message TLV, as defined by this
+ specification, defines additional 4-bit sub-fields of the Value
+ field, starting with bits 4-7 of the first octet and continuing with
+ bits 0-3 of the second octet, to represent willingness to be a
+ routing MPR using the link metric types specified in this OLSRv2
+ interface's IFACE_METRIC_TYPES parameter, ordered as reported in the
+ included MPR_TYPES Message TLV. Note that this means that, if there
+ might be any non-MT-OLSRv2 routers, then the link metric type
+ LINK_METRIC_TYPE will continue to occupy bits 4-7 of the first octet.
+ (If there is no such TLV included, then the router does not support
+ MT-OLSRv2, and only the first octet of the Value field will be used.)
+
+ If the number of link metric types in this OLSRv2 interface's
+ IFACE_METRIC_TYPES parameter is even, then there will be an unused
+ 4-bit sub-field in bits 4-7 of the last octet of a full-sized Value
+ field. These bits will not be used; they SHOULD all be cleared ('0')
+ on transmission and MUST be ignored on receipt.
+
+ If the Value field in an MPR_WILLING TLV is shorter than its full
+ length, then, as specified in [RFC7188], missing Value octets, i.e.,
+ missing willingness values, are considered as zero (WILL_NEVER).
+ This is the correct behavior. (In particular, it means that an
+ OLSRv2 router that is not implementing MT-OLSRv2 will not act as a
+ routing MPR for any link metric that it does not recognize.)
+
+7.2. Address Block TLVs
+
+ New Type Extensions are defined for the LINK_METRIC TLV defined in
+ [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV,
+ both defined in [RFC7181], are extended, as enabled by [RFC7188].
+
+7.2.1. LINK_METRIC TLV
+
+ The LINK_METRIC TLV is used in HELLO messages and TC messages. This
+ TLV is unchanged from the definition in [RFC7181].
+
+ Only a single Type Extension was specified by [RFC7181] -- 0 for
+ "Link metric meaning as assigned by administrative action". This
+ specification extends it to the range 0-7. This specification will
+ work with any combination of Type Extensions both within and outside
+ that range (assuming that the latter are defined as specified in
+ [RFC7181]).
+
+
+
+
+Dearlove & Clausen Experimental [Page 12]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+7.2.2. MPR TLV
+
+ The MPR TLV is used in HELLO messages and indicates that an address
+ with which it is associated is of a symmetric 1-hop neighbor that has
+ been selected as an MPR.
+
+ The Value field of this address block TLV is, in [RFC7181], defined
+ to be one octet long, with the values 1, 2, and 3 defined. [RFC7188]
+ redefines this Value field to be a bitfield where bit 7 (the least
+ significant bit) denotes flooding status, bit 6 denotes routing MPR
+ status, and bits 5-0 are unallocated (respecting the semantics of the
+ bits/values 1, 2, and 3 from [RFC7181]).
+
+ This specification, as enabled by [RFC7188], extends the MPR TLV to
+ have a variable-length Value field. Bits are allocated in increasing
+ significance within as many octets as are required. These bits
+ specify, in order, that:
+
+ o The neighbor with that network address has been selected as
+ flooding MPR (1 bit).
+
+ o 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 indicated in the Value field of an MPR_TYPES Message TLV.
+
+ For interoperability with a router not implementing MT-OLSRv2, the
+ two least significant bits of the first octet in the Value field of
+ this TLV is as 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 indicate that a network
+ address is of an attached network.
+
+ The Value field of this address block TLV is defined by [RFC7181] to
+ be one octet long, containing the number of hops to that attached
+ network.
+
+ This specification, as enabled by [RFC7188], allows the extension of
+ the GATEWAY TLV to have a variable-length Value field when the number
+ of hops to each attached network is different for different link
+ metric types. For interoperability with a router not implementing
+ MT-OLSRv2, the first octet in the Value field of this TLV MUST be the
+ TLV Value of the GATEWAY TLV generated according to [RFC7181].
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 13]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ Any subsequent octets in the TLV Value field indicate the number of
+ hops to the attached network for each other link metric type. Link
+ metric types (including the first) 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 are made to the generation and processing of
+ HELLO messages compared to the description in [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 that used) is extended by:
+
+ o 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.
+
+ o 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, in the
+ same order as reported in the MPR_TYPES TLV, each value (also
+ including one representing WILL_FLOODING) occupying 4 bits.
+
+ o Including LINK_METRIC Address Block TLVs that report all values in
+ L_in_metric, L_out_metric, N_in_metric, and N_out_metric elements
+ that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
+ being the link metric type, and otherwise following the rules for
+ such inclusions specified in [RFC7181].
+
+ o 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].
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 14]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+8.2. HELLO Message Processing
+
+ On receipt of a HELLO message on an OLSRv2 interface, a router
+ implementing MT-OLSRv2 MUST do the following, in addition to the
+ processing described in [RFC7181]:
+
+ 1. If in this deployment there might be routers that do not
+ implement MT-OLSRv2, the HELLO message contains an MPR_TYPES
+ Message TLV, and the first link metric type that 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, either from an
+ MPR_TYPES Message TLV (if present) or from the single link metric
+ type LINK_METRIC_TYPE.
+
+ 3. For all link metric types 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 using the rules for
+ setting the single elements of those types specified in
+ [RFC7181].
+
+ 4. For any other metric types supported by the receiving router only
+ (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set
+ the elements listed in the previous point to their default
+ values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or
+ false.
+
+9. TC Messages
+
+ The following changes are made to the generation and processing of TC
+ messages compared to that described in [RFC7181] by routers that
+ implement MT-OLSRv2.
+
+9.1. TC Message Generation
+
+ A generated TC message is extended by:
+
+ o 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.
+
+ o Including LINK_METRIC TLVs that report all values of N_out_metric
+ that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
+ being the link metric type, and otherwise following the rules for
+ such inclusions specified in [RFC7181].
+
+
+
+Dearlove & Clausen Experimental [Page 15]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ o Including a number of hops per reported (in an MPR_TYPES Message
+ TLV) link metric type in the Value field of each GATEWAY TLV
+ included, in the same order as reported in the MPR_TYPES TLV.
+
+9.2. TC Message Processing
+
+ On receipt of a TC message, a router implementing this extension MUST
+ do the following, in addition to the processing specified in
+ [RFC7181]:
+
+ o If in this deployment there might be routers that do not implement
+ MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and
+ the first link metric type that it reports is not
+ LINK_METRIC_TYPE, then the TC message MUST be silently discarded.
+
+ o For all link metric types reported and supported by the receiving
+ router, set the appropriate TR_metric, TA_metric, AN_dist, and
+ AN_metric elements using the rules for setting the single elements
+ of those types specified in [RFC7181].
+
+ o For any other metric types supported by the receiving router that
+ do not 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 are calculated for each link metric type in
+ ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2
+ interfaces that do not support that link metric type are not
+ considered. The determined status (routing MPR or not routing MPR)
+ for each link metric type is recorded in the relevant element of
+ N_routing_mpr.
+
+ Each router may make its own decision as to 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 are
+ used. These decisions MUST be made in a manner that ensures that
+ flooded messages will reach the same symmetric 2-hop neighbors as
+ would be the case for a router not supporting MT-OLSRv2.
+
+ Note that it is possible that a 2-Hop Tuple in the Information Base
+ for a given OLSRv2 interface does not support any of the link metric
+ types that are in the router's corresponding IFACE_METRIC_TYPES;
+ nevertheless, that 2-Hop Tuple MUST be considered when determining
+ flooding MPRs.
+
+
+
+
+Dearlove & Clausen Experimental [Page 16]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+11. Routing Set Calculation
+
+ A Routing Set is calculated for each link metric type in
+ ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except
+ that where an element is now represented by a map, the value from the
+ map for the selected link metric type is used. Where this is a link
+ metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for
+ the calculation.
+
+12. Management Considerations
+
+ MT-OLSRv2 may require greater management than unextended OLSRv2. In
+ particular, a MANET using MT-OLSRv2 requires the following management
+ considerations:
+
+ o Deciding which link metric, and hence which Routing Set to use,
+ for received packets, hence 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.)
+
+ o 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.
+
+ o 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.
+
+ o 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,
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 17]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ 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.
+
+ o 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
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 18]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ +-----------+-------------+-------------------------+---------------+
+ | 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 19]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+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
+
+
+
+Dearlove & Clausen Experimental [Page 20]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ 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
+
+ This extension to OLSRv2 allows a router to support more than one
+ link metric type for each link advertised in HELLO and TC messages,
+ and for routers to support different sets of types. Link metric
+ values of additional types are reported by the inclusion of
+ additional TLVs in the messages sent by a router, which will report
+ known values of all supported types.
+
+ HELLO and TC message processing is then extended simply to record,
+ for each supported type, all of the received link metric values for
+ each link. Protocol-internal processing (specifically, MPR set and
+ shortest path calculations) then operates as specified in [RFC7181]
+ for each link metric type that the router supports.
+
+ Consequently, the security considerations, including the security
+ architecture and the mandatory security mechanisms, from [RFC7181]
+ are directly applicable to MT-OLSRv2.
+
+ Furthermore, this extension does not introduce any additional
+ vulnerabilities beyond those of [RFC7181], because each link metric
+ type is used independently, and each one could have been the single
+ link metric type supported by an implementation of [RFC7181]
+ receiving the same information, as received information of an
+ unsupported type is ignored by all routers.
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 21]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+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>.
+
+
+
+Dearlove & Clausen Experimental [Page 22]
+
+RFC 7722 Multi-Topology OLSRv2 December 2015
+
+
+ [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 would like to thank (in alphabetical order): Juliusz
+ Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems),
+ Susan Hares (Huawei), and Henning Rogge (FGAN) for discussions and
+ suggestions.
+
+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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen Experimental [Page 23]
+