From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7722.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc7722.txt (limited to 'doc/rfc/rfc7722.txt') 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, + . + + [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, + . + + [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, + . + + [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, + . + + [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, + . + + [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, + . + +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, + . + + [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, + . + + + +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, + . + + [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, + . + +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] + -- cgit v1.2.3