Internet DRAFT - draft-ietf-manet-olsrv2-multitopology

draft-ietf-manet-olsrv2-multitopology






Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                          BAE Systems Applied Intelligence
Updates: 7188, 7631                                         Laboratories
(if approved)                                                 T. Clausen
Intended status: Experimental                   LIX, Ecole Polytechnique
Expires: March 31, 2016                               September 28, 2015


 Multi-Topology Extension for the Optimized Link State Routing Protocol
                           version 2 (OLSRv2)
                draft-ietf-manet-olsrv2-multitopology-07

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 31, 2016.

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



Dearlove & Clausen       Expires March 31, 2016                 [Page 1]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   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       Expires March 31, 2016                 [Page 2]

Internet-Draft            Multi-Topology OLSRv2           September 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 . . . . . . . . . . . . . . . . . 14
   9.  TC Messages  . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  TC Message Generation  . . . . . . . . . . . . . . . . . . 15
     9.2.  TC Message Processing  . . . . . . . . . . . . . . . . . . 16
   10. MPR Calculation  . . . . . . . . . . . . . . . . . . . . . . . 16
   11. Routing Set Calculation  . . . . . . . . . . . . . . . . . . . 16
   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  . . . . . . . . . . . . . . . . . 19
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     16.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23







Dearlove & Clausen       Expires March 31, 2016                 [Page 3]

Internet-Draft            Multi-Topology OLSRv2           September 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 route over other than minimum hop routes,
   using a link metric.

   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, as for example to 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 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       Expires March 31, 2016                 [Page 4]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   o  Operation in realistic deployments, and details thereof, including
      in particular indicating 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 on an alternative mechanism).

   o  Any data link layer issues, and any cross-layer issues, including
      whether NHDP link quality was used, and how.

   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 latter list applies to unextended [RFC7181]
   as well as this extension, and potentially to other MANET routing
   protocols.  This may also allow experimentation with link metric
   types that are not compromises to handle 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:





Dearlove & Clausen       Expires March 31, 2016                 [Page 5]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   Router -  A MANET router that implements [RFC7181].

   MT-OLSRv2 -  The protocol defined in this specification as an
      extension to [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.




Dearlove & Clausen       Expires March 31, 2016                 [Page 6]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   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
   created that are known to contain only MT-OLSRv2 routers.  In both
   cases, but especially the former, management may be required to
   ensure that the MANET will function as required, and does 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 which are not 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.)  However 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.  Both
   HELLO and TC messages generated by an MT-OLSRv2 router (other than
   one using only the single metric type used by non-MT-OLSRv2 routers)
   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).

   In addition to link and neighbor metric values for each link metric
   type, router MPR (multipoint relay) and MPR selector status, and
   advertised neighbor status, is maintained per supported neighbor
   metric type, for each symmetric 1-hop neighbor.  Each router may
   choose a different willingness to be a routing MPR for each link
   metric type that it supports.

   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



Dearlove & Clausen       Expires March 31, 2016                 [Page 7]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   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 non-functional, 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 containing any non-MT-OLSRv2
   routers).


5.  Parameters

   The parameters used in [RFC7181], including from 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 may be any routers that do not
   implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST first include
   LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate
   with any routers that do not implement MT-OLSRv2.  In that case,
   ROUTER_METRIC_TYPES MUST also first include LINK_METRIC_TYPE.

   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       Expires March 31, 2016                 [Page 8]

Internet-Draft            Multi-Topology OLSRv2           September 2015


6.  Information Bases

   The Information Bases specified in [RFC7181], which extend those
   specified in 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].

   Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link



Dearlove & Clausen       Expires March 31, 2016                 [Page 9]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   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
   Network Tuples whose corresponding value from AN_metric is



Dearlove & Clausen       Expires March 31, 2016                [Page 10]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   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 an including HELLO message is sent.  These octets
   MAY be in any order, except that if there may be any routers in the
   MANET not implementing 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, specified by [RFC7181], and which
   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       Expires March 31, 2016                [Page 11]

Internet-Draft            Multi-Topology OLSRv2           September 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 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').

   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, i.e., as
   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] (link metric
   type) 0 as defined by administrative action.  This specification
   extends this range to 0-7.  This specification will work with any
   combination of Type Extensions both within and without that range
   (assuming that the latter are defined as specified in [RFC7181]).





Dearlove & Clausen       Expires March 31, 2016                [Page 12]

Internet-Draft            Multi-Topology OLSRv2           September 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 lsb)
   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.  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 MUST be the TLV Value
   of the MPR TLV, generated according to [RFC7181].

   Subsequent bits (in increasing significance within an octet, then
   continuing with the least significant bit in the next octet, if
   required) in the TLV Value field indicate which link metric types,
   for which the corresponding address is selected as a routing MPR,
   link metric types (including the first) being indicated in, and used
   in the same order as, the Value field of an MPR_TYPES Message TLV,
   excluding the link metric type LINK_METRIC_TYPE, which already
   occupies the second bit.

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, in [RFC7181] defined to
   be one octet long, containing the number of hops to that attached
   network.

   This specification, as enabled by [RFC7181], allows the extension 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].

   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) being indicated in the Value field
   of an MPR_TYPES Message TLV.



Dearlove & Clausen       Expires March 31, 2016                [Page 13]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   +---------+---------------------------------------------------------+
   |   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 that described in [RFC7181] by 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].

8.2.  HELLO Message Processing

   On receipt of a HELLO message on an OLSRv2 interface, a router
   implementing MT-OLSRv2 MUST, in addition to the processing described
   in [RFC7181]:




Dearlove & Clausen       Expires March 31, 2016                [Page 14]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   1.  If in this deployment there may be any 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 or, if not present, the single link metric
       type LINK_METRIC_TYPE.

   3.  For those link metric types supported by both routers, 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 values as described for single such elements 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 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].

   o  When not all the same, 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.




Dearlove & Clausen       Expires March 31, 2016                [Page 15]

Internet-Draft            Multi-Topology OLSRv2           September 2015


9.2.  TC Message Processing

   On receipt of a TC message, a router implementing this extension
   MUST, in addition to the processing specified in [RFC7181]:

   o  If in this deployment there may be any 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  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, and if so
   which and how.  This decision 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, but
   nevertheless that 2-Hop Tuple MUST be considered when determining
   flooding MPRs.


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



Dearlove & Clausen       Expires March 31, 2016                [Page 16]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   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
      DiffServ Code Point (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 may contain non-MT-OLSRv2 routers, which is
      also subject to management, then the rules for link metric
      assignment to OLSRv2 interfaces in this specification 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 being easier in, for example, a denser
      network).  Note that if there is any possibility that there are
      any 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 they were to do so 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 will then either be
      dropped (if that MT-OLSRv2 router is not part of that topology, or
      is not aware of the destination within that topology) or will be
      routed by that topology to the destination.  Such a packet will
      not loop.

   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



Dearlove & Clausen       Expires March 31, 2016                [Page 17]

Internet-Draft            Multi-Topology OLSRv2           September 2015


      originating router is a non-MT-OLSRv2 router) or will not be
      transmitted (if the originating router is an MT-OLSRv2 router).
      Routers SHOULD be managed so that this does not occur.


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 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       Expires March 31, 2016                [Page 18]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   +-----------+-------------+-------------------------+---------------+
   |    Type   |     Name    | Description             | Reference     |
   | Extension |             |                         |               |
   +-----------+-------------+-------------------------+---------------+
   |     0     | MPR_WILLING | First (most             | [RFC7181]     |
   |           |             | significant) half octet | [RFC7631]     |
   |           |             | of Value field          | This          |
   |           |             | specifies the           | specification |
   |           |             | 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   | This          |
   |           |             | supported on this       | specification |
   |           |             | OLSRv2 interface of     |               |
   |           |             | this router (one octet  |               |
   |           |             | each).                  |               |
   |   2-223   |             | Unassigned              |               |
   |  224-255  |             | Reserved for            | [RFC7181]     |
   |           |             | Experimental Use        |               |
   +-----------+-------------+-------------------------+---------------+

                Table 2: Type 7 Message TLV Type Extensions

13.3.  Address Block TLV Types

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













Dearlove & Clausen       Expires March 31, 2016                [Page 19]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   +-------+-------+----------+----------------------------------------+
   |  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  | This          |
   |           |         | via a gateway on the        | specification |
   |           |         | originating router.  The    |               |
   |           |         | number of hops is indicated |               |
   |           |         | by the Value field, one     |               |
   |           |         | octet per link metric type  |               |
   |           |         | reported in an MPR_TYPES    |               |
   |           |         | Message TLV (in the same    |               |
   |           |         | order) or (if no MPR_TYPES  |               |
   |           |         | Message TLV is present)     |               |
   |           |         | using a single octet        |               |
   |   1-223   |         | Unassigned                  |               |
   |  224-255  |         | Reserved for Experimental   | [RFC7631]     |
   |           |         | Use                         |               |
   +-----------+---------+-----------------------------+---------------+

            Table 4: Type 10 Address Block TLV Type Extensions

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



Dearlove & Clausen       Expires March 31, 2016                [Page 20]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   +-------------+------+-----------+-------------------+--------------+
   |     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 operate 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 over 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.


15.  Acknowledgments

   The authors would like to thank (in alphabetical order): Juliusz
   Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems),



Dearlove & Clausen       Expires March 31, 2016                [Page 21]

Internet-Draft            Multi-Topology OLSRv2           September 2015


   Susan Hares (Huawei) and Henning Rogge (FGAN) for discussions and
   suggestions.


16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC6130]  Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              RFC 7181, 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,
              April 2014.

   [RFC7631]  Dearlove, C. and T. Clausen, "TLV Naming in the MANET
              Generalized Packet/Message Format", RFC 7631,
              January 2015.

16.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,
              December 1998.

   [RFC2501]  Macker, J. and S. Corson, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501, January 1999.

   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",



Dearlove & Clausen       Expires March 31, 2016                [Page 22]

Internet-Draft            Multi-Topology OLSRv2           September 2015


              RFC 4915, June 2007.


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       Expires March 31, 2016                [Page 23]