GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7722

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7722.txt · Last modified: 2015/12/29 05:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki