Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Christopher Dearlove
Last updated 2013-07-08
Replaced by draft-ietf-manet-olsrv2-multitopology, RFC 7722
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dearlove-manet-olsrv2-multitopology-00
Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                           BAE Systems ATC
Intended status: Experimental                               July 8, 2013
Expires: January 9, 2014

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

Abstract

   This specification describes an extension to the Optimized Link State
   Routing Protocol version 2 (OLSRv2) to support multiple routing
   topologies, while retaining backward compatibility with routers
   implementing unextended OLSRv2.

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 January 9, 2014.

Copyright Notice

   Copyright (c) 2013 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                 Expires January 9, 2014                [Page 1]
Internet-Draft            Multi-Topology OLSRv2                July 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Notation . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  4
   5.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Router Configuration . . . . . . . . . . . . . . . . . . . . .  5
   7.  Information Bases  . . . . . . . . . . . . . . . . . . . . . .  5
     7.1.  Local Attached Network Set . . . . . . . . . . . . . . . .  6
     7.2.  Link Sets  . . . . . . . . . . . . . . . . . . . . . . . .  6
     7.3.  2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . .  6
     7.4.  Neighbor Set . . . . . . . . . . . . . . . . . . . . . . .  6
     7.5.  Router Topology Set  . . . . . . . . . . . . . . . . . . .  6
     7.6.  Routable Address Topology Set  . . . . . . . . . . . . . .  7
     7.7.  Attached Network Set . . . . . . . . . . . . . . . . . . .  7
     7.8.  Routing Sets . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . .  7
       8.1.1.  MPR_TYPES TLV  . . . . . . . . . . . . . . . . . . . .  7
     8.2.  Address Block TLVs . . . . . . . . . . . . . . . . . . . .  8
       8.2.1.  LINK_METRIC TLV  . . . . . . . . . . . . . . . . . . .  8
       8.2.2.  MPR TLV  . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  HELLO Message Generation . . . . . . . . . . . . . . . . . 10
     9.2.  HELLO Message Processing . . . . . . . . . . . . . . . . . 10
   10. TC Messages  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. TC Message Generation  . . . . . . . . . . . . . . . . . . 11
     10.2. TC Message Processing  . . . . . . . . . . . . . . . . . . 11
   11. MPR Calculation  . . . . . . . . . . . . . . . . . . . . . . . 11
   12. Routing Set Calculation  . . . . . . . . . . . . . . . . . . . 12
   13. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   16. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     17.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14

Dearlove                 Expires January 9, 2014                [Page 2]
Internet-Draft            Multi-Topology OLSRv2                July 2013

1.  Introduction

   The Optimized Link State Routing Protocol, version 2 [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 use alternative metrics for different packet
   routing.  This specification describes an extension to OLSRv2 that is
   designed to permit this, while maintaining maximal backward
   compatibility with routers supporting unextended OLSRv2.  (There may
   be one small adjustment in interpretation required, there is no
   change in the messages sent by an unextended OLSRv2 implementation.)

   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
   may be described as to create and maintain multiple Routing Sets, one
   for each link metric type supported by the router maintaining the
   sets.

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

   Additionally, this document uses the terminology of [RFC5444],
   [RFC6130] and [OLSRv2].

   References in this document to "unextended OLSRv2" indicate
   implementations of OLSRv2 that do not implement the extension
   described in this specification.

   This specification introduces the notation map[range -> type] to
   represent an associative map from elements of the range, which in
   this specification is always a set of link metric types that the
   router supports (either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as
   defined in Section 5), to a type, which in this specification is
   always either boolean or metric-value (either a representable link
   metric value, as described in [OLSRv2], or UNKNOWN_METRIC).

Dearlove                 Expires January 9, 2014                [Page 3]
Internet-Draft            Multi-Topology OLSRv2                July 2013

3.  Applicability Statement

   The protocol described in this specification is applicable to a
   mobile ad hoc network for which OLSRv2 is otherwise applicable (see
   [OLSRv2]), but in which multiple topologies are maintained, each
   characterised 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].

4.  Protocol Overview and Functioning

   The purpose of this specification is to establish and maintain
   multiple routing topologies in a MANET, each associated with a link
   metric type.  Routers in the MANET may each form part of some or all
   of these topologies, and ecah router will maintain a Routing Set for
   each topology that it forms part of, allowing separate routing of
   packets for each topology.

   Each router implementing this specification selects a set of link
   metric types for each OLSRv2 interface.  If there may be any routers
   in the MANET using unextended OLSRv2 then the link metric used by
   such routers must be included in those selected on all OLSRv2
   interfaces by all routers in the MANET, otherwise routers may make
   independent selections.

   Each router then determines an incoming link metric for each link
   metric type selected for each OLSRv2 interface.  These link metrics
   are distributed using link metric TLVs contained in all HELLO
   messages sent on OLSRv2 interfaces, and all TC messages.

   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.

   More so than OLSRv2, the use of multiple metric types across the
   MANET must be managed, by administrative configuration or otherwise.
   Similarly to other decisions that may be made using OLSRv2, a bad
   collective choice will make the MANET anywhere from inefficient to
   non-functional, so care will be needed in selecting supported link
   metric types across the MANET.

Dearlove                 Expires January 9, 2014                [Page 4]
Internet-Draft            Multi-Topology OLSRv2                July 2013

5.  Parameters

   The parameters used in [OLSRv2], including from its normative
   references, are used in this specification with a single change.

   Each OLSRv2 interface will support a number of link metric types,
   corresponding to type extensions of the LINK_METRIC TLV defined in
   [OLSRv2].  The router parameter LINK_METRIC_TYPE that is used by
   routers supporting unextended OLSRv2 is replaced in this
   specification by an interface parameter array IFACE_METRIC_TYPES and
   a router parameter array ROUTER_METRIC_TYPES, each of link metric
   types (i.e. type extensions used by the LINK_METRIC TLV that indicate
   what kind of link metric is being used.

   The term LINK_METRIC_TYPE is used for the parameter used by any
   routers in the MANET that implement unextended OLSRv2.

   The interface parameter array IFACE_METRIC_TYPES contains the link
   metric types supported on that OLSRv2 interface.  If there may be any
   routers implementing unextended OLSRv2 in the MANET, then
   IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE.

   The router parameter array ROUTER_METRIC_TYPES is the union of all of
   the IFACE_METRIC_TYPES, without repetitions.  Note that if there may
   be any routers implementing unextended OLSRv2 in the MANET, then
   ROUTER_METRIC_TYPES MUST include LINK_METRIC_TYPE.

6.  Router Configuration

   TBD.

7.  Information Bases

   The Information Bases specified in [OLSRv2], which extends those
   specified in in [RFC6130], are used in this specification with the
   following changes.  With the exception of the Routing Set, these
   changes are the extension of some elements that each represented a
   single value (boolean or a link-metric) in unextended OLSRv2, by
   elements that each represent multiple values, in the form of an
   associative map from a set of metric types (IFACE_METRIC_TYPES or
   ROUTER_METRIC_TYPES) to the value type.

   Note that, as in [OLSRv2], an implementation is free to organize its
   internal data in any manner it chooses, it needs only to behave as if
   it were organised as described in [OLSRv2] and this specification.

Dearlove                 Expires January 9, 2014                [Page 5]
Internet-Draft            Multi-Topology OLSRv2                July 2013

7.1.  Local Attached Network Set

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

7.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 [OLSRv2].

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

7.4.  Neighbor Set

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

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

   Each element N_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].

7.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

Dearlove                 Expires January 9, 2014                [Page 6]
Internet-Draft            Multi-Topology OLSRv2                July 2013

   corresponding value from this map is used, Router Topology Tuples
   whose corresponding value of TR_metric is UNKNOWN_METRIC are ignored.

7.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 value from this map is used, Routable Address Topology
   Tuples whose corresponding value of TA_metric is UNKNOWN_METRIC are
   ignored.

7.7.  Attached Network Set

   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 value from this map is used, Attached Network Tuples
   whose corresponding value of AN_metric is UNKNOWN_METRIC are ignored.

7.8.  Routing Sets

   There is a separate Routing Set for each link metric type in
   ROUTER_METRIC_TYPES.

8.  TLVs

   This specification makes the following additions and extensions to
   the TLVs defined in [OLSRv2].

8.1.  Message TLVs

   A single new Message TLV is defined in this specifiction.

8.1.1.  MPR_TYPES TLV

   A new allocation is made for an MPR_TYPES Message TLV.  The presence
   of this TLV is used to indicate that the router supports Multi-
   Topology 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 [OLSRv2].  For this reason, the MPR_TYPES TLV has been defined
   with the same Type as the MPR_WILLING TLV, but with Type Extension ==
   1.  (The different symbolic name is used for convenience, any

Dearlove                 Expires January 9, 2014                [Page 7]
Internet-Draft            Multi-Topology OLSRv2                July 2013

   reference to a TLV_TYPES TLV means to this TLV, with this Type and
   Type Extension.)

   This TLV may take a value field of any size.  Each octet in its value
   field will contain a link metric type.  These octets MAY be in any
   order, except that if there may be any routers in the MANET using
   unextended OLSRv2, then the first octet MUST be LINK_METRIC_TYPE.

8.2.  Address Block TLVs

   New Type Extensions are defined for the LINK_METRIC TLV defined in
   [OLSRv2].  Some adjustment is required to the MPR TLV defined in
   [OLSRv2].  Three options are presented in this document, the final
   version of this specification will have to pick one.

8.2.1.  LINK_METRIC TLV

   This is unchanged from the definition in [OLSRv2].  However that
   specification defined a single type extension (link metric type) 0 as
   defined by administrative action.  This specification extends this
   range, it is suggested to either to 0-7 or 0-15.  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 [OLSRv2]).

8.2.2.  MPR TLV

   The value field of this TLV has only the values 1, 2, and 3 specified
   in [OLSRv2], and 3 denotes both 1 and 2.  The value field could thus
   be reinterpreted as a bitfield, where bit 0 denotes flooding status,
   and bits 1-7 denote routing MPR status for up to 7 link metric types.
   What these metric types are will be specified by the value field of
   an MPR_TYPES TLV, in the same order.

   There are however two problems with this approach:

   o  A strict implementation of OLSRv2 may reject any values other than
      1, 2, or 3.  To resolve this either an update to OLSRv2 is
      required (although implementations that are liberal in how they
      handle received messages may already behave in this manner) or an
      alternative, described below, must instead be used.  Note that
      such an extension has been proposed in [OLSRv2-Extensions].  If
      that proposal is adopted (and this specification is a motivation
      for part of it) then this would address this issue.

   o  Restricting the MPR TLV to have single octet values (as specified
      in [OLSRv2], and which a strict implementation of OLSRv2 might
      require) limits the number of link metric types that a router can

Dearlove                 Expires January 9, 2014                [Page 8]
Internet-Draft            Multi-Topology OLSRv2                July 2013

      handle to 7.  This might be acceptable as a design choice.
      Alternatively the single value field of an MPR TLV may be allowed
      to be of variable size, one or more octets.

   A proposed option to support more than 1 or 7 link metric types is to
   use a second MPR TLV with Type Extension 1.  This can carry the
   remaining MPR signalling for link metric types from the second, or
   eighth.

   The following options may thus be considered.  Note that a single
   choice is to be made for the final specification.

   1.  An unlimited (up to 255) number of link metric types, all carried
       in the MPR TLV with Type Extension 0, which is redefined
       accordingly, with a variable single value length.  This requires
       an unextended OLSRv2 implementation to accommodate both the
       variable length and that it must consider only the first two bits
       of the first value octet.

   2.  An maximum of 7 link metric types used by any router, all carried
       in the MPR TLV with Type Extension 0, which is redefined
       accordingly, but retaining a one octet single value length.  This
       requires an unextended OLSRv2 implementation to consider only the
       first two bits of the value octet.

   3.  An unlimited (up to 255) number of link metric types, the first
       seven in the MPR TLV with Type Extension 0, the remainder in an
       MPR TLV with Type Extension 1.  This imposes the same requirement
       on an unextended OLSRv2 implementation as the previous option.

   4.  An unlimited (up to 255) number of link metric types, the first
       one (LINK_METRIC_VALUE) in the MPR TLV with Type Extension 0, the
       remainder in an MPR TLV with Type Extension 1.  This imposes no
       new requirements on an unextended OLSRv2 implementation.

   Note that adoption of [OLSRv2-Extensions] would make option 2 well-
   defined, and option 4 unnecessary.  Option 1 is not currently
   addressed speccifically in [OLSRv2-Extensions].  Option 3 would be
   possible if the one octet MPR TLV single value is retained, but more
   than seven topologies are required.

9.  HELLO Messages

   The following changes are made to the generation and processing of
   HELLO messages compared to that described in [OLSRv2] by routers that
   implement this extension.

Dearlove                 Expires January 9, 2014                [Page 9]
Internet-Draft            Multi-Topology OLSRv2                July 2013

9.1.  HELLO Message Generation

   A generated HELLO message to be sent on an OLSRv2 interface is
   extended by:

   o  Adding an MPR_TYPES TLV.  The value octets will be the link metric
      types in ROUTER_METRIC_TYPES.

   o  Including LINK_METRIC TLVs that report all values of L_in_metric,
      L_out_metric, N_in_metric and 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 [OLSRv2].

   o  Including MPR TLVs with Type Extension == 0, and possibly Type
      Extension == 1, depending on the chosen option from Section 8.2.2.
      For each link metric type in ROUTER_METRIC_TYPES, and for the
      choice of flooding MPRs, these MUST cover at least one address of
      each 1-hop symmetric neighbor reported in the HELLO message, as
      described for a single link metric type in [OLSRv2].

9.2.  HELLO Message Processing

   On receipt of a HELLO message, a router implementing this extension
   MUST, in addition to the processing described in [OLSRv2]:

   1.  Determine the list of link metric types supported by the sending
       router, either from an MPR_TYPES TLV or, if not present, the type
       LINK_METRIC_TYPE supported by an unextended OLSRv2 router.

   2.  For those link metric types supported by both routers, set the
       appropriate L_out_metric, N_in_metric, N_out_metric,
       N_mpr_selector, N_advertised, N2_in_metric and N2_out_metric
       values as described for the single such elements in [OLSRv2].

   3.  For any other metric types supported by the receiving router
       only, set those elements to their default value (UNKNOWN_METRIC
       or false).

10.  TC Messages

   The following changes are made to the generation and processing of TC
   messages compared to that described in [OLSRv2] by routers that
   implement this extension.

Dearlove                 Expires January 9, 2014               [Page 10]
Internet-Draft            Multi-Topology OLSRv2                July 2013

10.1.  TC Message Generation

   A generated TC message is extended by:

   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 [OLSRv2].

10.2.  TC Message Processing

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

   o  Set the appropriate TR_metric, TA_metric and AN_metric elements
      using the rules for setting the single elements of those types
      specified in [OLSRv2].

   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.

11.  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 does 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
   how.  This decision MUST be made in a manner that ensures that
   flooded messages will reach the same symmetric 2-hop neighbors as for
   unextended 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.

Dearlove                 Expires January 9, 2014               [Page 11]
Internet-Draft            Multi-Topology OLSRv2                July 2013

12.  Routing Set Calculation

   A Routing Set is calculated for each supported link metric type.  The
   calculation may be as for [OLSRv2], 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.

13.  Management

   Multi-Topology OLSRv2 may require greater management than unextended
   OLSRv2.  In particular ulti-Topology OLSRv2 requires the following
   management:

   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.)

   o  Ensuring that the MANET is sufficiently connected.  Note that if
      there is any possibility that there are any routers implementing
      unextended OLSRv2, then the MANET will be connected, to the
      maximum extent possible, using the link metric type
      LINK_METRIC_TYPE.

   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).  An obvious approach is to map
      each DiffServ Code Point (DSCP) [RFC2474] to a single link metric.
      (This will usually be a many to one mapping.)

   o  Note that there could be cases where an unextended OLSRv2 router
      is the source or destination of an IP packet that is mapped to a
      link metric that is not the link metric LINK_METRIC_TYPE used by
      the unextended OLSRv2 router.  If the unextended OLSRv2 router is
      the source, then routing may work if the first extended OLSRv2
      router to receive the packet supports the appropriate link metric
      type.  At worst the packet will be dropped, it will not loop.  If
      the unextended OLSRv2 router is the destination, then the packet
      will never reach its destination, the source will not have a
      suitable routing table entry for the destination.  Network
      management may be required to ensure that the MANET still
      functions in these cases.

Dearlove                 Expires January 9, 2014               [Page 12]
Internet-Draft            Multi-Topology OLSRv2                July 2013

14.  IANA Considerations

   TBD.

15.  Security Considerations

   TBD.

16.  Acknowledgments

   TBD.

17.  References

17.1.  Normative References

   [OLSRv2]   Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              work in progress draft-ietf-manet-olsrv2-19, March 2013.

   [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.

17.2.  Informative References

   [OLSRv2-Extensions]
              Dearlove, C., "Routing MPR and Other Extensions for the
              Optimized Link State Routing Protocol version 2 (OLSRv2)",
              work in
              progress draft-dearlove-manet-olsrv2-extensions-00,
              July 2013.

   [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.

Dearlove                 Expires January 9, 2014               [Page 13]
Internet-Draft            Multi-Topology OLSRv2                July 2013

   [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.

Author's Address

   Christopher Dearlove
   BAE Systems Advanced Technology Centre
   West Hanningfield Road
   Great Baddow, Chelmsford
   United Kingdom

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

Dearlove                 Expires January 9, 2014               [Page 14]