doc: Add RFC documents

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]
+