draft-ietf-manet-olsrv2-multitopology-07.txt   rfc7722.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Internet Engineering Task Force (IETF) C. Dearlove
Internet-Draft BAE Systems Applied Intelligence Request for Comments: 7722 BAE Systems
Updates: 7188, 7631 Laboratories Updates: 7188, 7631 T. Clausen
(if approved) T. Clausen Category: Experimental LIX, Ecole Polytechnique
Intended status: Experimental LIX, Ecole Polytechnique ISSN: 2070-1721 December 2015
Expires: March 31, 2016 September 28, 2015
Multi-Topology Extension for the Optimized Link State Routing Protocol Multi-Topology Extension
version 2 (OLSRv2) for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multitopology-07
Abstract Abstract
This specification describes an extension to the Optimized Link State This specification describes an extension to the Optimized Link State
Routing Protocol version 2 (OLSRv2) to support multiple routing Routing Protocol version 2 (OLSRv2) to support multiple routing
topologies, while retaining interoperability with OLSRv2 routers that topologies, while retaining interoperability with OLSRv2 routers that
do not implement this extension. do not implement this extension.
This specification updates RFCs 7188 and 7631 by modifying and This specification updates RFCs 7188 and 7631 by modifying and
extending TLV registries and descriptions. extending TLV registries and descriptions.
Status of this Memo 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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on March 31, 2016. 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.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Motivation and Experimentation . . . . . . . . . . . . . . 4 1.1. Motivation and Experimentation .............................4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation ........................................5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement .........................................6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning ...............................6
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Parameters ......................................................8
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 9 6. Information Bases ...............................................9
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 9 6.1. Local Attached Network Set .................................9
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Link Sets ..................................................9
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. 2-Hop Sets .................................................9
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Neighbor Set ...............................................9
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 10 6.5. Router Topology Set .......................................10
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 10 6.6. Routable Address Topology Set .............................10
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 10 6.7. Attached Network Set ......................................10
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 11 6.8. Routing Sets ..............................................11
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. TLVs ...........................................................11
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Message TLVs ..............................................11
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 11 7.1.1. MPR_TYPES TLV ......................................11
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 11 7.1.2. MPR_WILLING TLV ....................................11
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 12 7.2. Address Block TLVs ........................................12
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 12 7.2.1. LINK_METRIC TLV ....................................12
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.2. MPR TLV ............................................13
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 13 7.2.3. GATEWAY TLV ........................................13
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 8. HELLO Messages .................................................14
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 14 8.1. HELLO Message Generation ..................................14
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 14 8.2. HELLO Message Processing ..................................15
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. TC Messages ....................................................15
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 15 9.1. TC Message Generation .....................................15
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 16 9.2. TC Message Processing .....................................16
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 16 10. MPR Calculation ...............................................16
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 16 11. Routing Set Calculation .......................................17
12. Management Considerations . . . . . . . . . . . . . . . . . . 17 12. Management Considerations .....................................17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations ...........................................18
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18 13.1. Expert Review: Evaluation Guidelines .....................18
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18 13.2. Message TLV Types ........................................18
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 19 13.3. Address Block TLV Types ..................................20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14. Security Considerations .......................................21
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 15. References ....................................................22
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15.1. Normative References .....................................22
16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 15.2. Informative References ...................................22
16.2. Informative References . . . . . . . . . . . . . . . . . . 22 Acknowledgments ...................................................23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses ................................................23
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol, version 2 [RFC7181] The Optimized Link State Routing Protocol version 2 [RFC7181]
(OLSRv2) is a proactive link state routing protocol designed for use (OLSRv2) is a proactive link state routing protocol designed for use
in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant in Mobile Ad Hoc Networks (MANETs) [RFC2501]. One of the significant
improvements of OLSRv2 over its Experimental precursor [RFC3626] is improvements of OLSRv2 over its Experimental precursor [RFC3626] is
the ability of OLSRv2 to route over other than minimum hop routes, the ability of OLSRv2 to use link metrics to select routes other than
using a link metric. minimum hop routes.
A limitation that remains in OLSRv2 is that it uses a single link 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 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 desirable to be able to route packets using more than one link metric
type. This specification describes an extension to OLSRv2 that is type. This specification describes an extension to OLSRv2 that is
designed to permit this, while maintaining maximal interoperability designed to permit this, while maintaining maximal interoperability
with OLSRv2 routers not implementing this extension. with OLSRv2 routers not implementing this extension.
The purpose of OLSRv2 can be described as to create and maintain a The purpose of OLSRv2 can be described as to create and maintain a
Routing Set, which contains all the necessary information to populate Routing Set, which contains all the necessary information to populate
an IP routing table. In a similar way, the role of this extension 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 can be described as to create and maintain multiple Routing Sets, one
for each link metric type supported by the router maintaining the for each link metric type supported by the router maintaining the
sets. sets.
1.1. Motivation and Experimentation 1.1. Motivation and Experimentation
Multi-topology routing is a natural extension to a link state routing Multi-topology routing is a natural extension to a link state routing
protocol, as for example to OSPF (see [RFC4915]). However multi- protocol, such as OSPF (see [RFC4915]). However multi-topology
topology routing for OLSRv2 does not yet benefit from extensive routing for OLSRv2 does not yet benefit from extensive operational,
operational, or even experimental, experience. This specification is or even experimental, experience. This specification is published to
published to facilitate collecting such experience, with the intent facilitate collecting such experience, with the intent that once
that once suitable experimental evidence has been collected, an suitable experimental evidence has been collected, an OLSRv2 Multi-
OLSRv2 Multi-Topology Routing Extension will be proposed for Topology Routing Extension will be proposed for advancement onto the
advancement onto Standards Track. Standards Track.
Any experiments using this protocol extension are encouraged. Any experiments using this protocol extension are encouraged.
Reports from such experiments planned with pre-specified objectives Reports from such experiments planned with pre-specified objectives
and scenarios (including link, position and mobility information) are and scenarios (including link, position, and mobility information)
particularly encouraged. Results from such experiments, documenting are particularly encouraged. Results from such experiments,
the following, are of particular importance: documenting the following, are of particular importance:
o Operation in networks that contain both routers implementing this o Operation in networks that contain both routers implementing this
extension, and routers implementing only [RFC7181], in particular extension and routers implementing only [RFC7181]. In particular,
are there any unexpected interactions that can break the network? are there any unexpected interactions that can break the network?
o Operation in networks with dynamic topologies, both due to o Operation in networks with dynamic topologies, both due to
mobility and due to link metric changes for reasons other than mobility and due to link metric changes for reasons other than
mobility. mobility.
o Operation in realistic deployments, and details thereof, including o Operation in realistic deployments, and details thereof, including
in particular indicating how many concurrent topologies were how many concurrent topologies were required.
required.
o Behavior of routing sets, including measures of successful route o Behavior of Routing Sets, including measures of successful route
establishment. establishment.
In addition, reports from experiments covering the following are also In addition, reports from experiments covering the following are also
of value: of value:
o Which link metric types were useful, and how the metrics to o Which link metric types were useful, and how the metrics to
associate with a given link were established. associate with a given link were established.
o How packet types were associated with link metric types (whether o How packet types were associated with link metric types (whether
using DiffServ on an alternative mechanism). using Diffserv or an alternative mechanism).
o Any data link layer issues, and any cross-layer issues, including o Any data link-layer issues, and any cross-layer issues, including
whether NHDP link quality was used, and how. whether and how Neighborhood Discovery Protocol (NHDP) link
quality was used.
o Transport and higher layer issues observed, if any. o Transport- and higher-layer issues observed, if any.
o Resource requirements observed from running the protocol, o Resource requirements observed from running the protocol,
including processing, storage, and bandwidth. including processing, storage, and bandwidth.
o Network performance, including packet delivery results. o Network performance, including packet delivery results.
o Any other implementation issues. o Any other implementation issues.
The first bullet in the latter list applies to unextended [RFC7181] The first bullet in the list directly above applies to unextended
as well as this extension, and potentially to other MANET routing OLSRv2 [RFC7181] as well as with this extension, and potentially to
protocols. This may also allow experimentation with link metric other MANET routing protocols. This specification also allows
types that are not compromises to handle multiple traffic types. experimentation with link metric types that are not compromises for
handling multiple traffic types.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This specification uses the terminology of [RFC5444], [RFC6130] and This specification uses the terminology of [RFC5444], [RFC6130], and
[RFC7181], which is to be interpreted as described in those [RFC7181], which is to be interpreted as described in those
specifications. specifications.
Additionally, this specification uses the following terminology: Additionally, this specification uses the following terminology:
Router - A MANET router that implements [RFC7181]. Router - A MANET router that implements [RFC7181].
MT-OLSRv2 - The protocol defined in this specification as an MT-OLSRv2 - The protocol defined in this specification as an
extension to [RFC7181]. extension to OLSRv2 [RFC7181].
This specification introduces the notation map[A -> B] to represent This specification introduces the notation map[A -> B] to represent
an associative mapping. The domain of this mapping (A) is, in this an associative mapping. The domain of this mapping (A) is, in this
specification, always a set of link metric types that the router specification, always a set of link metric types that the router
supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as
defined in Section 5. The codomain of this mapping (B) is a set of defined in Section 5. The codomain of this mapping (B) is a set of
all possible values of an appropriate type, in this specification all possible values of an appropriate type. In this specification,
this type is always one of: this type is always one of:
o boolean (true or false), o boolean (true or false),
o willingness (a 4 bit unsigned integer from 0 to 15); 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 number of hops (an 8-bit unsigned integer from 0 to 255), or
o link metric (either a representable link metric value, as o link metric (either a representable link metric value, as
described in [RFC7181], or UNKNOWN_METRIC). described in [RFC7181], or UNKNOWN_METRIC).
3. Applicability Statement 3. Applicability Statement
The protocol described in this specification is applicable to a MANET The protocol described in this specification is applicable to a MANET
for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3),
but in which multiple topologies are maintained, each characterized but in which multiple topologies are maintained, each characterized
by a different choice of link metric type. It is assumed, but by a different choice of link metric type. It is assumed, but
outside the scope of this specification, that the network layer is outside the scope of this specification, that the network layer is
able to choose which topology to use for each packet, for example able to choose which topology to use for each packet, for example,
using the DiffServ Code Point (DSCP) defined in [RFC2474]. This using the Diffserv Code Point (DSCP) defined in [RFC2474]. This
selection of topology MUST be consistent, that is each router selection of topology MUST be consistent; that is, each router
receiving a packet must make the same choice of link metric type, in 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 order that each packet uses a single topology. This is necessary to
avoid the possibility of a packet "looping" in the network. avoid the possibility of a packet "looping" in the network.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The purpose of this specification is to extend OLSRv2 [RFC7181] so as The purpose of this specification is to extend OLSRv2 [RFC7181] so as
to enable a router to establish and maintain multiple routing to enable a router to establish and maintain multiple routing
topologies in a MANET, each topology associated with a link metric 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 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 these topologies, and each router will maintain a Routing Set for
each topology that it forms part of, allowing separate routing of each topology that it forms part of, allowing separate routing of
packets for each topology. packets for each topology.
MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be
created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 created containing both routers that implement MT-OLSRv2 (MT-OLSRv2
routers) and routers that do not implement MT-OLSRv2, and may be routers) and routers that do not implement MT-OLSRv2 and may be
unaware of its existence (non-MT-OLSRv2 routers). MANETs may also 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 created that are known to contain only MT-OLSRv2 routers. In both
cases, but especially the former, management may be required to cases, but especially where a MANET contains both MT-OLSRv2 routers
ensure that the MANET will function as required, and does not, for and non-MT-OLSRv2 routers, management may be required to ensure that
example, unnecessarily fragment. (Such issues already arise in an 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-based MANET using multiple interfaces.)
OLSRv2 is an extension of NHDP [RFC6130]. However the extension in OLSRv2 is an extension of NHDP [RFC6130]. However, the extension in
this specification does not modify NHDP, it only modifies Protocol this specification does not modify NHDP, it only modifies Protocol
Sets that are specific to OLSRv2, or elements in Protocol Tuples that 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. were added by OLSRv2 and that are neither included in nor used by
In addition it does not use or modify the link quality mechanism in NHDP. In addition it does not use or modify the link quality
[RFC6130]. mechanism in [RFC6130].
Each router implementing this specification selects a set of link Each router implementing this specification selects a set of link
metric types for each of its OLSRv2 interfaces. If all routers in metric types for each of its OLSRv2 interfaces. If all routers in
the MANET implement MT-OLSRv2, then there are no restrictions within the MANET implement MT-OLSRv2, then there are no restrictions within
this specification on how these sets of link metrics are selected. this specification on how these sets of link metrics are selected.
(However the issues described in the preceding paragraph still (However, the issues described in the preceding paragraph still
apply.) However in MANETs containing non-MT-OLSRv2 routers, the apply.) On the other hand, in MANETs containing non-MT-OLSRv2
single link metric used by these non-MT-OLSRv2 routers must be routers, the single link metric used by these non-MT-OLSRv2 routers
included in the set of link metrics for each OLSRv2 interface of an must be included in the set of link metrics for each OLSRv2 interface
MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non- of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a
MT-OLSRv2 router in the MANET. non-MT-OLSRv2 router in the MANET.
Each router then determines an incoming link metric for each link Each router then determines an incoming link metric for each link
metric type selected for each of its OLSRv2 interfaces. These link metric type selected for each of its OLSRv2 interfaces. These link
metrics are distributed using link metric TLVs contained in all HELLO metrics are distributed using link metric TLVs contained in all HELLO
messages sent on OLSRv2 interfaces, and in all TC messages. Both messages sent on OLSRv2 interfaces and in all TC messages. Unless
HELLO and TC messages generated by an MT-OLSRv2 router (other than using only the single metric type used by non-MT-OLSRv2 routers, both
one using only the single metric type used by non-MT-OLSRv2 routers) HELLO and TC messages generated by an MT-OLSRv2 router include an
include an MPR_TYPES Message TLV that indicates that this is an MT- MPR_TYPES Message TLV that indicates that this is an MT-OLSRv2 router
OLSRv2 router and which metric types it supports (on the sending and which metric types it supports (on the sending OLSRv2 interface
OLSRv2 interface for a HELLO message). for a HELLO message).
In addition to link and neighbor metric values for each link metric An MT-OLSRv2 router maintains, for each supported neighbour metric
type, router MPR (multipoint relay) and MPR selector status, and type and for each symmetric 1-hop neighbor, the following:
advertised neighbor status, is maintained per supported neighbor
metric type, for each symmetric 1-hop neighbor. Each router may o link and neighbour metric values,
choose a different willingness to be a routing MPR for each link
metric type that it supports. 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.
A network using MT-OLSRv2 will usually require greater management A network using MT-OLSRv2 will usually require greater management
than one using unmodified OLSRv2. In particular, the use of multiple than one using unmodified OLSRv2. In particular, the use of multiple
metric types across the MANET must be managed, by administrative metric types across the MANET must be managed, by administrative
configuration or otherwise. As also for other decisions that may be configuration or otherwise. As also for other decisions that may be
made when using OLSRv2, a bad collective choice of metric type use made when using OLSRv2, a bad collective choice of metric type use
will make the MANET anywhere from inefficient to non-functional, so will make the MANET anywhere from inefficient to nonfunctional, so
care will be needed in selecting supported link metric types across care will be needed in selecting supported link metric types across
the MANET. the MANET.
The meanings of link metric types are at the discretion of 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 operator. They could be used, for example, to represent packets of
different types, packets in streams of different rates, or packets different types, packets in streams of different rates, or packets
with different trust requirements. Note that packets will generally with different trust requirements. Note that packets will generally
not be delivered to routers that do not support that link metric 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 type, and the MANET, and the packets sent in it, will need to be
managed accordingly (especially if containing any non-MT-OLSRv2 managed accordingly (especially if the MANET contains any
routers). non-MT-OLSRv2 routers).
5. Parameters 5. Parameters
The parameters used in [RFC7181], including from its normative The parameters used in [RFC7181], and in its normative references,
references, are used in this specification with the following are used in this specification with the following changes.
changes.
Each OLSRv2 interface will support a number of link metric types, Each OLSRv2 interface will support a number of link metric types,
corresponding to Type Extensions of the LINK_METRIC TLV defined in corresponding to Type Extensions of the LINK_METRIC TLV defined in
[RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers
that do not implement MT-OLSRv2, and used with that definition in that do not implement MT-OLSRv2, and used with that definition in
this specification, is replaced in routers implementing MT-OLSRv2 by this specification, is replaced in routers implementing MT-OLSRv2 by
an interface parameter array IFACE_METRIC_TYPES and a router an interface parameter array IFACE_METRIC_TYPES and a router
parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 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 a link metric type (i.e., a type extension used by the LINK_METRIC
TLV [RFC7181]). TLV [RFC7181]).
The interface parameter array IFACE_METRIC_TYPES contains the link The interface parameter array IFACE_METRIC_TYPES contains the link
metric types supported on that OLSRv2 interface. The router metric types supported on that OLSRv2 interface. The router
parameter array ROUTER_METRIC_TYPES is the union of all of the parameter array ROUTER_METRIC_TYPES is the union of all of the
IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.
If in a given deployment there may be any routers that do not If in a given deployment there might be routers that do not implement
implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST first include MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as
LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate its first element, so that the OLSRv2 interface can communicate with
with any routers that do not implement MT-OLSRv2. In that case, those routers. In that case, ROUTER_METRIC_TYPES MUST also include
ROUTER_METRIC_TYPES MUST also first include LINK_METRIC_TYPE. LINK_METRIC_TYPE as its first element.
In addition, the router parameter WILL_ROUTING is extended to an In addition, the router parameter WILL_ROUTING is extended to an
array of values, one each for each link metric type in the router array of values, one each for each link metric type in the router
parameter list ROUTER_METRIC_TYPES. parameter list ROUTER_METRIC_TYPES.
6. Information Bases 6. Information Bases
The Information Bases specified in [RFC7181], which extend those The Information Bases specified in [RFC7181], which extend those
specified in in [RFC6130], are further extended in this specified in [RFC6130], are further extended in this specification.
specification. With the exception of the Routing Set, the extensions With the exception of the Routing Set, the extensions in this
in this specification are the replacement of single values (boolean, specification are the replacement of single values (boolean,
willingness, number of hops, or link metric) from [RFC7181] with willingness, number of hops, or link metric) from [RFC7181] with
elements representing multiple values (associative mappings from a elements representing multiple values (associative mappings from a
set of metric types to their corresponding values). The following set of metric types to their corresponding values). The following
subsections detail these extensions. subsections detail these extensions.
Note that, as in [RFC7181], an implementation is free to organize its 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 internal data in any manner it chooses; it needs only to behave as if
it were organized as described in [RFC7181] and this specification. it were organized as described in [RFC7181] and this specification.
6.1. Local Attached Network Set 6.1. Local Attached Network Set
Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of
hops]. hops].
Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
skipping to change at page 11, line 37 skipping to change at page 11, line 38
The presence of this TLV in a message is used to indicate that the 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 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, MPR_WILLING TLV is used to indicate that the router supports OLSRv2,
as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has 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 been defined with the same Type as the MPR_WILLING TLV, but with Type
Extension = 1. Extension = 1.
This TLV may take a Value field of any size. Each octet in its Value 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 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 any OLSRv2 interface, when included in a TC message, or on the OLSRv2
interface on which an including HELLO message is sent. These octets interface on which a HELLO message including this TLV is sent. These
MAY be in any order, except that if there may be any routers in the octets MAY be in any order, but if there might be routers in the
MANET not implementing MT-OLSRv2, then the first octet MUST be MANET that do not implement MT-OLSRv2, then the first octet MUST be
LINK_METRIC_TYPE. LINK_METRIC_TYPE.
7.1.2. MPR_WILLING TLV 7.1.2. MPR_WILLING TLV
The MPR_WILLING TLV, which is used in HELLO messages, is specified in The MPR_WILLING TLV, which is used in HELLO messages, is specified in
[RFC7181], and extended in this specification as enabled by [RFC7181], and extended in this specification as enabled by
[RFC7188]. [RFC7188].
The interpretation of this TLV, specified by [RFC7181], and which The interpretation of this TLV, which is specified by [RFC7181] and
uses all of its single octet Value field, is unchanged. That uses all of its single-octet Value field, is unchanged. That
interpretation uses bits 0-3 of its Value field to specify its interpretation uses bits 0-3 of its Value field to specify its
willingness to be a flooding TLV, and bits 4-7 of its Value field to 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 be a routing TLV. Those latter bits are, when using this
specification, interpreted as its willingness to be a routing TLV specification, interpreted as its willingness to be a routing TLV
using the link metric type LINK_METRIC_TYPE. using the link metric type LINK_METRIC_TYPE.
The extended use of this message TLV, as defined by this The extended use of this message TLV, as defined by this
specification, defines additional 4 bit sub-fields of the Value specification, defines additional 4-bit sub-fields of the Value
field, starting with bits 4-7 of the first octet and continuing with 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 bits 0-3 of the second octet, to represent willingness to be a
routing MPR using the link metric types specified in this OLSRv2 routing MPR using the link metric types specified in this OLSRv2
interface's IFACE_METRIC_TYPES parameter, ordered as reported in the interface's IFACE_METRIC_TYPES parameter, ordered as reported in the
included MPR_TYPES Message TLV. Note that this means that the link included MPR_TYPES Message TLV. Note that this means that, if there
metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the might be any non-MT-OLSRv2 routers, then the link metric type
first octet. (If there is no such TLV included, then the router does LINK_METRIC_TYPE will continue to occupy bits 4-7 of the first octet.
not support MT-OLSRv2, and only the first octet of the Value field (If there is no such TLV included, then the router does not support
will be used.) 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 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 IFACE_METRIC_TYPES parameter is even, then there will be an unused
bit sub-field in bits 4-7 of the last octet of a full sized Value 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 field. These bits will not be used; they SHOULD all be cleared ('0')
('0'). on transmission and MUST be ignored on receipt.
If the Value field in an MPR_WILLING TLV is shorter than its full 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., length, then, as specified in [RFC7188], missing Value octets, i.e.,
missing willingness values, are considered as zero, i.e., as missing willingness values, are considered as zero (WILL_NEVER).
WILL_NEVER. This is the correct behavior. (In particular it means This is the correct behavior. (In particular, it means that an
that an OLSRv2 router that is not implementing MT-OLSRv2 will not act OLSRv2 router that is not implementing MT-OLSRv2 will not act as a
as a routing MPR for any link metric that it does not recognize.) routing MPR for any link metric that it does not recognize.)
7.2. Address Block TLVs 7.2. Address Block TLVs
New Type Extensions are defined for the LINK_METRIC TLV defined in 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, [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV,
both defined in [RFC7181], are extended, as enabled by [RFC7188]. both defined in [RFC7181], are extended, as enabled by [RFC7188].
7.2.1. LINK_METRIC TLV 7.2.1. LINK_METRIC TLV
The LINK_METRIC TLV is used in HELLO messages and TC messages. This The LINK_METRIC TLV is used in HELLO messages and TC messages. This
TLV is unchanged from the definition in [RFC7181]. TLV is unchanged from the definition in [RFC7181].
Only a single Type Extension was specified by [RFC7181] (link metric Only a single Type Extension was specified by [RFC7181] -- 0 for
type) 0 as defined by administrative action. This specification "Link metric meaning as assigned by administrative action". This
extends this range to 0-7. This specification will work with any specification extends it to the range 0-7. This specification will
combination of Type Extensions both within and without that range work with any combination of Type Extensions both within and outside
(assuming that the latter are defined as specified in [RFC7181]). that range (assuming that the latter are defined as specified in
[RFC7181]).
7.2.2. MPR TLV 7.2.2. MPR TLV
The MPR TLV is used in HELLO messages, and indicates that an address 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 with which it is associated is of a symmetric 1-hop neighbor that has
been selected as an MPR. been selected as an MPR.
The Value field of this address block TLV is, in [RFC7181], defined 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] 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) redefines this Value field to be a bitfield where bit 7 (the least
denotes flooding status, bit 6 denotes routing MPR status, and bits significant bit) denotes flooding status, bit 6 denotes routing MPR
5-0 are unallocated (respecting the semantics of the bits/values 1, 2 status, and bits 5-0 are unallocated (respecting the semantics of the
and 3 from [RFC7181]). bits/values 1, 2, and 3 from [RFC7181]).
This specification, as enabled by [RFC7188], extends the MPR TLV to This specification, as enabled by [RFC7188], extends the MPR TLV to
have a variable-length Value field. For interoperability with a have a variable-length Value field. Bits are allocated in increasing
router not implementing MT-OLSRv2, the two least significant bits of significance within as many octets as are required. These bits
the first octet in the Value field of this TLV MUST be the TLV Value specify, in order, that:
of the MPR TLV, generated according to [RFC7181].
Subsequent bits (in increasing significance within an octet, then o The neighbor with that network address has been selected as
continuing with the least significant bit in the next octet, if flooding MPR (1 bit).
required) in the TLV Value field indicate which link metric types,
for which the corresponding address is selected as a routing MPR, o The neighbor with that network address has been selected as
link metric types (including the first) being indicated in, and used routing MPR for each link metric type (1 bit each), in the same
in the same order as, the Value field of an MPR_TYPES Message TLV, order as indicated in the Value field of an MPR_TYPES Message TLV.
excluding the link metric type LINK_METRIC_TYPE, which already
occupies the second bit. 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 7.2.3. GATEWAY TLV
The GATEWAY TLV is used in TC messages to indicate that a network The GATEWAY TLV is used in TC messages to indicate that a network
address is of an attached network. address is of an attached network.
The Value field of this address block TLV is, in [RFC7181] defined to 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 be one octet long, containing the number of hops to that attached
network. network.
This specification, as enabled by [RFC7181], allows the extension the This specification, as enabled by [RFC7188], allows the extension of
GATEWAY TLV to have a variable-length Value field when the number of the GATEWAY TLV to have a variable-length Value field when the number
hops to each attached network is different for different link metric of hops to each attached network is different for different link
types. For interoperability with a router not implementing MT- metric types. For interoperability with a router not implementing
OLSRv2, the first octet in the Value field of this TLV MUST be the 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]. TLV Value of the GATEWAY TLV generated according to [RFC7181].
Any subsequent octets in the TLV Value field indicate the number of Any subsequent octets in the TLV Value field indicate the number of
hops to the attached network for each other link metric type, link hops to the attached network for each other link metric type. Link
metric types (including the first) being indicated in the Value field metric types (including the first) are ordered as indicated in the
of an MPR_TYPES Message TLV. Value field of an MPR_TYPES Message TLV.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Type | Value | | Type | Value |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| GATEWAY | Number of hops to attached network for each link metric | | GATEWAY | Number of hops to attached network for each link metric |
| | type. | | | type. |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
Table 1: GATEWAY TLV definition Table 1: GATEWAY TLV Definition
8. HELLO Messages 8. HELLO Messages
The following changes are made to the generation and processing of The following changes are made to the generation and processing of
HELLO messages compared to that described in [RFC7181] by routers HELLO messages compared to the description in [RFC7181] for routers
that implement MT-OLSRv2. that implement MT-OLSRv2.
8.1. HELLO Message Generation 8.1. HELLO Message Generation
A generated HELLO message to be sent on an OLSRv2 interface (whose A generated HELLO message to be sent on an OLSRv2 interface (whose
IFACE_METRIC_TYPES parameter will be that used) is extended by: IFACE_METRIC_TYPES parameter will be that used) is extended by:
o Adding an MPR_TYPES Message TLV. The Value octets will be the 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 link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted
if the only link metric type included would be LINK_METRIC_TYPE. if the only link metric type included would be LINK_METRIC_TYPE.
o Extending the MPR_WILLING Message TLV Value field to report the o Extending the MPR_WILLING Message TLV Value field to report the
willingness values from the WILL_ROUTING parameter list that willingness values from the WILL_ROUTING parameter list that
correspond to the link metric types in IFACE_METRIC_LIST, in the correspond to the link metric types in IFACE_METRIC_LIST, in the
same order as reported in the MPR_TYPES TLV, each value (also same order as reported in the MPR_TYPES TLV, each value (also
including one representing WILL_FLOODING) occupying 4 bits. including one representing WILL_FLOODING) occupying 4 bits.
o Including LINK_METRIC Address Block TLVs that report all values in 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 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 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
being the link metric type, and otherwise following the rules for being the link metric type, and otherwise following the rules for
such inclusions specified in [RFC7181]. such inclusions specified in [RFC7181].
o Including MPR Address Block TLVs such that for each link metric o Including MPR Address Block TLVs such that for each link metric
type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, 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 the indicated addresses MUST be of the MPRs in an MPR set as
specified for a single link metric type in [RFC7181]. specified for a single link metric type in [RFC7181].
8.2. HELLO Message Processing 8.2. HELLO Message Processing
On receipt of a HELLO message on an OLSRv2 interface, a router On receipt of a HELLO message on an OLSRv2 interface, a router
implementing MT-OLSRv2 MUST, in addition to the processing described implementing MT-OLSRv2 MUST do the following, in addition to the
in [RFC7181]: processing described in [RFC7181]:
1. If in this deployment there may be any routers that do not 1. If in this deployment there might be routers that do not
implement MT-OLSRv2, the HELLO message contains an MPR_TYPES implement MT-OLSRv2, the HELLO message contains an MPR_TYPES
Message TLV, and the first link metric type that it reports is Message TLV, and the first link metric type that it reports is
not LINK_METRIC_TYPE, then the HELLO message MUST be silently not LINK_METRIC_TYPE, then the HELLO message MUST be silently
discarded. discarded.
2. Determine the list of link metric types supported by the sending 2. Determine the list of link metric types supported by the sending
router on its corresponding OLSRv2 interface, either from an router on its corresponding OLSRv2 interface, either from an
MPR_TYPES Message TLV or, if not present, the single link metric MPR_TYPES Message TLV (if present) or from the single link metric
type LINK_METRIC_TYPE. type LINK_METRIC_TYPE.
3. For those link metric types supported by both routers, set the 3. For all link metric types reported and supported by the receiving
appropriate L_out_metric, N_in_metric, N_out_metric, router, set the appropriate L_out_metric, N_in_metric,
N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and N_out_metric, N_will_routing, N_mpr_selector, N_advertised,
N2_out_metric values as described for single such elements in N2_in_metric, and N2_out_metric elements using the rules for
setting the single elements of those types specified in
[RFC7181]. [RFC7181].
4. For any other metric types supported by the receiving router only 4. For any other metric types supported by the receiving router only
(i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set
the elements listed in the previous point to their default the elements listed in the previous point to their default
values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or
false. false.
9. TC Messages 9. TC Messages
The following changes are made to the generation and processing of TC The following changes are made to the generation and processing of TC
messages compared to that described in [RFC7181] by routers that messages compared to that described in [RFC7181] by routers that
implement MT-OLSRv2. implement MT-OLSRv2.
9.1. TC Message Generation 9.1. TC Message Generation
A generated TC message is extended by: A generated TC message is extended by:
o Adding an MPR_TYPES TLV. The value octets will be the link metric 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 types in ROUTER_METRIC_TYPES. This TLV MAY be omitted if the only
link metric type included would be LINK_METRIC_TYPE. link metric type included would be LINK_METRIC_TYPE.
o Including LINK_METRIC TLVs that report all values of N_out_metric 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 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
being the link metric type, and otherwise following the rules for being the link metric type, and otherwise following the rules for
such inclusions specified in [RFC7181]. such inclusions specified in [RFC7181].
o When not all the same, including a number of hops per reported (in o Including a number of hops per reported (in an MPR_TYPES Message
an MPR_TYPES Message TLV) link metric type in the Value field of TLV) link metric type in the Value field of each GATEWAY TLV
each GATEWAY TLV included, in the same order as reported in the included, in the same order as reported in the MPR_TYPES TLV.
MPR_TYPES TLV.
9.2. TC Message Processing 9.2. TC Message Processing
On receipt of a TC message, a router implementing this extension On receipt of a TC message, a router implementing this extension MUST
MUST, in addition to the processing specified in [RFC7181]: do the following, in addition to the processing specified in
[RFC7181]:
o If in this deployment there may be any routers that do not o If in this deployment there might be routers that do not implement
implement MT-OLSRv2, the TC message contains an MPR_TYPES Message MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and
TLV, and the first link metric type that it reports is not the first link metric type that it reports is not
LINK_METRIC_TYPE, then the TC message MUST be silently discarded. LINK_METRIC_TYPE, then the TC message MUST be silently discarded.
o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric o For all link metric types reported and supported by the receiving
elements using the rules for setting the single elements of those router, set the appropriate TR_metric, TA_metric, AN_dist, and
types specified in [RFC7181]. 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 o For any other metric types supported by the receiving router that
do not have an advertised outgoing neighbor metric of that type, do not have an advertised outgoing neighbor metric of that type,
set the corresponding elements of TR_metric, TA_metric and set the corresponding elements of TR_metric, TA_metric, and
AN_metric to UNKNOWN_METRIC. (The corresponding element of AN_metric to UNKNOWN_METRIC. (The corresponding element of
AN_dist may be set to any value.) AN_dist may be set to any value.)
10. MPR Calculation 10. MPR Calculation
Routing MPRs are calculated for each link metric type in Routing MPRs are calculated for each link metric type in
ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2
interfaces that do not support that link metric type are not interfaces that do not support that link metric type are not
considered. The determined status (routing MPR or not routing MPR) considered. The determined status (routing MPR or not routing MPR)
for each link metric type is recorded in the relevant element of for each link metric type is recorded in the relevant element of
N_routing_mpr. N_routing_mpr.
Each router may make its own decision as to whether or not to use a 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 link metric, or link metrics, for flooding MPR calculation. If using
which and how. This decision MUST be made in a manner that ensures link metric(s), each router decides which one(s) and how they are
that flooded messages will reach the same symmetric 2-hop neighbors used. These decisions MUST be made in a manner that ensures that
as would be the case for a router not supporting MT-OLSRv2. 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 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 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 types that are in the router's corresponding IFACE_METRIC_TYPES;
nevertheless that 2-Hop Tuple MUST be considered when determining nevertheless, that 2-Hop Tuple MUST be considered when determining
flooding MPRs. flooding MPRs.
11. Routing Set Calculation 11. Routing Set Calculation
A Routing Set is calculated for each link metric type in A Routing Set is calculated for each link metric type in
ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 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 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 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 metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for
the calculation. the calculation.
12. Management Considerations 12. Management Considerations
MT-OLSRv2 may require greater management than unextended OLSRv2. In MT-OLSRv2 may require greater management than unextended OLSRv2. In
particular a MANET using MT-OLSRv2 requires the following management particular, a MANET using MT-OLSRv2 requires the following management
considerations: considerations:
o Deciding which link metric, and hence which Routing Set to use, o Deciding which link metric, and hence which Routing Set to use,
for received packets, hence how to use the Routing Sets to for received packets, hence how to use the Routing Sets to
configure the network layer (IP). All routers MUST make the same configure the network layer (IP). All routers MUST make the same
decision for the same packet. An obvious approach is to map each decision for the same packet. An obvious approach is to map each
DiffServ Code Point (DSCP) [RFC2474] to a single link metric. DSCP [RFC2474] to a single link metric. (This may be a many-to-
(This may be a many to one mapping.) one mapping.)
o Selecting which link metrics to support on each OLSRv2 interface o Selecting which link metrics to support on each OLSRv2 interface
and implementing that decision. (Different interfaces may have and implementing that decision. (Different interfaces may have
different physical and data link layer properties, and this may different physical and data link-layer properties, and this may
inform the selection of link metrics to support, and their inform the selection of link metrics to support, and their
values.) If the MANET may contain non-MT-OLSRv2 routers, which is values.) If the MANET might contain non-MT-OLSRv2 routers, which
also subject to management, then the rules for link metric are also subject to management, then the rules in this
assignment to OLSRv2 interfaces in this specification for that specification for link metric assignment to OLSRv2 interfaces for
case MUST be followed. that case MUST be followed.
o Ensuring that the MANET is sufficiently connected, by ensuring o Ensuring that the MANET is sufficiently connected, by ensuring
that, for example, sufficiently many routers implement each metric that, for example, sufficiently many routers implement each metric
type required (this being easier in, for example, a denser type required. (This is easier in, for example, a denser network.)
network). Note that if there is any possibility that there are Note that if there is any possibility that there are routers not
any routers not implementing MT-OLSRv2, then the MANET will be implementing MT-OLSRv2, then the MANET will be connected, to the
connected, to the maximum extent possible, using the link metric maximum extent possible, using the link metric type
type LINK_METRIC_TYPE, but this will only serve to deliver packets LINK_METRIC_TYPE, but this will only serve to deliver packets that
that use that link metric type. use that link metric type.
o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets 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. 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 However, if that were to happen, then such packets will be routed
until either they reach their destination, or they reach an MT- until either they reach their destination or they reach an
OLSRv2 router. In the latter case the packet will then either be MT-OLSRv2 router. In the latter case, the packet then either will
dropped (if that MT-OLSRv2 router is not part of that topology, or be dropped (if that MT-OLSRv2 router is not part of that topology,
is not aware of the destination within that topology) or will be or is not aware of the destination within that topology) or will
routed by that topology to the destination. Such a packet will be routed by that topology to the destination. Such a packet will
not loop. not loop.
o If a packet is created for a destination that is not part of the 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 corresponding topology, then it may or may not be delivered (if
originating router is a non-MT-OLSRv2 router) or will not be the originating router is a non-MT-OLSRv2 router) or will not be
transmitted (if the originating router is an MT-OLSRv2 router). sent (if the originating router is an MT-OLSRv2 router). Routers
Routers SHOULD be managed so that this does not occur. 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 13. IANA Considerations
This specification adds one new Message TLV, allocated as a new Type This specification adds one new Message TLV, allocated as a new Type
Extension to an existing Message TLV, using a new name. It also Extension to an existing Message TLV, using a new name. It also
modifies the Value field of an existing Message TLV, and of an modifies the Value field of an existing Message TLV and that of an
existing Address Block TLV. Finally, this specification makes existing Address Block TLV. Finally, this specification makes
additional allocations from the LINK_METRIC Address Block TLV Type additional allocations from the LINK_METRIC Address Block TLV Type
registry. registry.
13.1. Expert Review: Evaluation Guidelines 13.1. Expert Review: Evaluation Guidelines
For the registry where an Expert Review is required, the designated For the registry where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444] and [RFC7631]. consideration as are specified by [RFC5444] and [RFC7631].
13.2. Message TLV Types 13.2. Message TLV Types
This specification modifies the Message TLV Type 7, replacing Table 4 This specification modifies the Message TLV Type 7, replacing Table 4
of [RFC7631] by Table 2, changing the description of the Type of [RFC7631] by Table 2, changing the description of the Type
Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each 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 of these TLVs MUST NOT be included more than once in a Message TLV
Block. Block.
+-----------+-------------+-------------------------+---------------+ +-----------+-------------+-------------------------+---------------+
| Type | Name | Description | Reference | | Type | Name | Description | Reference |
| Extension | | | | | Extension | | | |
+-----------+-------------+-------------------------+---------------+ +-----------+-------------+-------------------------+---------------+
| 0 | MPR_WILLING | First (most | [RFC7181] | | 0 | MPR_WILLING | First (most | [RFC7181] |
| | | significant) half octet | [RFC7631] | | | | significant) half-octet | [RFC7631] |
| | | of Value field | This | | | | of Value field | RFC 7722 |
| | | specifies the | specification | | | | specifies the | |
| | | originating router's | | | | | originating router's | |
| | | willingness to act as a | | | | | willingness to act as a | |
| | | flooding MPR; | | | | | flooding MPR; | |
| | | subsequent half octets | | | | | subsequent half-octets | |
| | | specify the originating | | | | | specify the originating | |
| | | router's willingness to | | | | | router's willingness to | |
| | | act as a routing MPR, | | | | | act as a routing MPR, | |
| | | either for the link | | | | | either for the link | |
| | | metric types reported | | | | | metric types reported | |
| | | in an MPR_TYPES TLV (in | | | | | in an MPR_TYPES TLV (in | |
| | | the same order), or (if | | | | | the same order), or (if | |
| | | no MPR_TYPES TLV is | | | | | no MPR_TYPES TLV is | |
| | | present) for the single | | | | | present) for the single | |
| | | administratively agreed | | | | | administratively agreed | |
| | | link metric type | | | | | link metric type | |
| 1 | MPR_TYPES | The link metric types | This | | 1 | MPR_TYPES | The link metric types | RFC 7722 |
| | | supported on this | specification | | | | supported on this | |
| | | OLSRv2 interface of | | | | | OLSRv2 interface of | |
| | | this router (one octet | | | | | this router (one octet | |
| | | each). | | | | | each). | |
| 2-223 | | Unassigned | | | 2-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC7181] | | 224-255 | | Reserved for | [RFC7181] |
| | | Experimental Use | | | | | Experimental Use | |
+-----------+-------------+-------------------------+---------------+ +-----------+-------------+-------------------------+---------------+
Table 2: Type 7 Message TLV Type Extensions Table 2: Type 7 Message TLV Type Extensions
13.3. Address Block TLV Types 13.3. Address Block TLV Types
Table 7 of [RFC7188] is replaced by Table 3. Table 7 of [RFC7188] is replaced by Table 3.
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
| Bit | Value | Name | Description | | Bit | Value | Name | Description |
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
| First | First | Flooding | If set then the neighbor with that | | First | First | Flooding | If set, then the neighbor with that |
| octet | octet | | network address has been selected as | | octet | octet | | network address has been selected as |
| bit 7 | 0x01 | | flooding MPR | | bit 7 | 0x01 | | flooding MPR |
| From | From | Routing | If set then the neighbor with that | | From | From | Routing | If set, then the neighbor with that |
| first | first | | network address has been selected as | | first | first | | network address has been selected as |
| octet | octet | | routing MPR, either for the link | | octet | octet | | routing MPR, either for the link |
| bit 6 | 0x02 | | metric types reported in an MPR_TYPES | | bit 6 | 0x02 | | metric types reported in an MPR_TYPES |
| | | | TLV (in the same order), or (if no | | | | | TLV (in the same order), or (if no |
| | | | MPR_TYPES TLV is present) then (first | | | | | MPR_TYPES TLV is present) then (first |
| | | | octet bit 6, value 0x02) for the | | | | | octet bit 6, value 0x02) for the |
| | | | single administratively agreed link | | | | | single administratively agreed link |
| | | | metric type | | | | | metric type |
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
Table 3: MPR TLV Bit Values Table 3: MPR TLV Bit Values
Table 14 of [RFC7631] is replaced by Table 4. The only changes are Table 14 of [RFC7631] is replaced by Table 4. The only changes are
to the Description and the References for the GATEWAY TLV. to the Description and the References for the GATEWAY TLV.
+-----------+---------+-----------------------------+---------------+ +-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References | | Type | Name | Description | References |
| Extension | | | | | Extension | | | |
+-----------+---------+-----------------------------+---------------+ +-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] | | 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | This | | | | network address is reached | RFC 7722 |
| | | via a gateway on the | specification | | | | via a gateway on the | |
| | | originating router. The | | | | | originating router. The | |
| | | number of hops is indicated | | | | | number of hops is indicated | |
| | | by the Value field, one | | | | | by the Value field, one | |
| | | octet per link metric type | | | | | octet per link metric type | |
| | | reported in an MPR_TYPES | | | | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | | | | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | | | | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | | | | | Message TLV is present) | |
| | | using a single octet | | | | | using a single octet | |
| 1-223 | | Unassigned | | | 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC7631] | | 224-255 | | Reserved for Experimental | [RFC7631] |
| | | Use | | | | | Use | |
+-----------+---------+-----------------------------+---------------+ +-----------+---------+-----------------------------+---------------+
Table 4: Type 10 Address Block TLV Type Extensions Table 4: Type 10 Address Block TLV Type Extensions
Table 13 of [RFC7181] is replaced by Table 5. The only change is to Table 13 of [RFC7181] is replaced by Table 5. The only change is
allocate 8 Type Extensions as assigned by administrative action, in that 8 Type Extensions are allocated as assigned by administrative
order to support administratively determined multi-topologies. action, in order to support administratively determined multi-
topologies.
+-------------+------+-----------+-------------------+--------------+ +-------------+------+-----------+-------------------+--------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+ +-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | 7 | 0-7 | Link metric | | | LINK_METRIC | 7 | 0-7 | Link metric | |
| | | | meaning assigned | | | | | | meaning assigned | |
| | | | by administrative | | | | | | by administrative | |
| | | | action. | | | | | | action. | |
| LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert |
skipping to change at page 21, line 32 skipping to change at page 21, line 37
This extension to OLSRv2 allows a router to support more than one This extension to OLSRv2 allows a router to support more than one
link metric type for each link advertised in HELLO and TC messages, link metric type for each link advertised in HELLO and TC messages,
and for routers to support different sets of types. Link metric and for routers to support different sets of types. Link metric
values of additional types are reported by the inclusion of values of additional types are reported by the inclusion of
additional TLVs in the messages sent by a router, which will report additional TLVs in the messages sent by a router, which will report
known values of all supported types. known values of all supported types.
HELLO and TC message processing is then extended simply to record, HELLO and TC message processing is then extended simply to record,
for each supported type, all of the received link metric values for for each supported type, all of the received link metric values for
each link. Protocol internal processing (specifically MPR set and each link. Protocol-internal processing (specifically, MPR set and
shortest path calculations) then operate as specified in [RFC7181] shortest path calculations) then operates as specified in [RFC7181]
for each link metric type that the router supports. for each link metric type that the router supports.
Consequently the security considerations, including the security Consequently, the security considerations, including the security
architecture and the mandatory security mechanisms, from [RFC7181] architecture and the mandatory security mechanisms, from [RFC7181]
are directly applicable to MT-OLSRv2. are directly applicable to MT-OLSRv2.
Furthermore, this extension does not introduce any additional Furthermore, this extension does not introduce any additional
vulnerabilities over those of [RFC7181], because each link metric vulnerabilities beyond those of [RFC7181], because each link metric
type is used independently, and each one could have been the single type is used independently, and each one could have been the single
link metric type supported by an implementation of [RFC7181] link metric type supported by an implementation of [RFC7181]
receiving the same information, as received information of an receiving the same information, as received information of an
unsupported type is ignored by all routers. unsupported type is ignored by all routers.
15. Acknowledgments 15. References
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.
16. References
16.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
February 2009. Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
<http://www.rfc-editor.org/info/rfc5444>.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. 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, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014. 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 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol version 2 (OLSRv2) and MANET Neighborhood Protocol Version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7188, Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
April 2014. DOI 10.17487/RFC7188, April 2014,
<http://www.rfc-editor.org/info/rfc7188>.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad
Generalized Packet/Message Format", RFC 7631, Hoc Network (MANET) Generalized Packet/Message Format",
January 2015. RFC 7631, DOI 10.17487/RFC7631, September 2015,
<http://www.rfc-editor.org/info/rfc7631>.
16.2. Informative References 15.2. Informative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501,
DOI 10.17487/RFC2501, January 1999,
<http://www.rfc-editor.org/info/rfc2501>.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link
Routing Protocol", RFC 3626, October 2003. 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. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007. 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 Authors' Addresses
Christopher Dearlove Christopher Dearlove
BAE Systems Applied Intelligence Laboratories BAE Systems Applied Intelligence Laboratories
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
 End of changes. 104 change blocks. 
295 lines changed or deleted 326 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/