Internet DRAFT - draft-dearlove-manet-olsrv2-multitopology
draft-dearlove-manet-olsrv2-multitopology
Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC
Intended status: Experimental T. Clausen
Expires: June 23, 2014 LIX, Ecole Polytechnique
December 20, 2013
Multi-Topology Extension for the Optimized Link State Routing Protocol
version 2 (OLSRv2)
draft-dearlove-manet-olsrv2-multitopology-02
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Dearlove & Clausen Expires June 23, 2014 [Page 1]
Internet-Draft Multi-Topology OLSRv2 December 2013
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 6
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 6
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 6
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 7
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 7
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 7
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 7
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 8
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 8
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 8
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 9
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 9
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 9
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 10
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 11
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 11
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 12
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 12
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 12
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 13
12. Management Considerations . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 14
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 16
14. Security Considerations . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
16.1. Normative References . . . . . . . . . . . . . . . . . . . 17
16.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Dearlove & Clausen Expires June 23, 2014 [Page 2]
Internet-Draft Multi-Topology OLSRv2 December 2013
1. Introduction
The Optimized Link State Routing Protocol, version 2 [OLSRv2] is a
proactive link state routing protocol designed for use in mobile ad
hoc networks (MANETs) [RFC2501]. One of the significant improvements
of OLSRv2 over its Experimental precursor [RFC3626] is the ability of
OLSRv2 to route over other than minimum hop routes, using a link
metric.
A limitation that remains in OLSRv2 is that it uses a single link
metric type for all routes. However in some MANETs it would be
desirable to be able to use alternative metrics for different packet
routing. This specification describes an extension to OLSRv2, that
is designed to permit this, while maintaining maximal
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.
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
[OLSRv2], which is to be interpreted as described in those
specifications.
Additionally, this specification uses the following terminology:
Router - A MANET router that implements [OLSRv2].
MT-OLSRv2 - The protocol defined in this specification as an
extension to [OLSRv2].
This specification introduces the notation map[range -> type] to
represent an associative map from elements of the range, which in
this specification is always a set of link metric types that the
router supports (either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as
defined in Section 5), to a type, which may be a boolean, a
willingness (a 4 bit unsigned integer from 0 to 15), a number of hops
Dearlove & Clausen Expires June 23, 2014 [Page 3]
Internet-Draft Multi-Topology OLSRv2 December 2013
(an 8 bit unsigned integer value from 0 to 255), or a metric-value
(either a representable link metric value, as described in [OLSRv2],
or UNKNOWN_METRIC).
3. Applicability Statement
The protocol described in this specification is applicable to a MANET
for which OLSRv2 is otherwise applicable (see [OLSRv2]), 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].
4. Protocol Overview and Functioning
The purpose of this specification is to extend [OLSRv2] 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.
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 on how
these sets of link metrics are selected. However there may be
deployments where routers, that do not implement MT-OLSRv2 (non-MT-
OLSRv2 routers), are to participate in a MANET with MT-OLSRv2
routers. In this case, 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 thatEmay 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.
In addition to link and neighbor metric values for each link metric
type, router MPR (multipoint relay) and MPR selector status, and
advertised neighbor status, is maintained per supported neighbor
metric type for each symmetric 1-hop neighbor. Each router may
choose a different willingness to be a routing MPR for each link
metric type that it supports.
Dearlove & Clausen Expires June 23, 2014 [Page 4]
Internet-Draft Multi-Topology OLSRv2 December 2013
More so than OLSRv2, the use of multiple metric types across the
MANET must be managed, by administrative configuration or otherwise.
Similarly to other decisions that may be made using OLSRv2, a bad
collective choice will make the MANET anywhere from inefficient to
non-functional, so care will be needed in selecting supported link
metric types across the MANET.
5. Parameters
The parameters used in [OLSRv2], including from its normative
references, are used in this specification with the following
changes.
Each OLSRv2 interface will support a number of link metric types,
corresponding to Type Extensions of the LINK_METRIC TLV defined in
[OLSRv2]. 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 [OLSRv2]).
The interface parameter array IFACE_METRIC_TYPES contains the link
metric types supported on that OLSRv2 interface. The router
parameter array ROUTER_METRIC_TYPES is the union of all of the
IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.
If in a given deployment there may be any routers that do not
implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include
LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate
with any routers that do not implement MT-OLSRv2. In that case,
ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE.
In addition, the router parameter WILL_ROUTING is extended to an
array of values, one each for each link metric type in the router
parameter list ROUTER_METRIC_TYPES.
6. Information Bases
The Information Bases specified in [OLSRv2], which extend those
specified in in [RFC6130], are further extended in this
specification. With the exception of the Routing Set, the extensions
in this specification are the replacement of single values (boolean,
willingness, number of hops, or link-metric) from [OLSRv2] with
elements representing multiple values (associative maps from a set of
Dearlove & Clausen Expires June 23, 2014 [Page 5]
Internet-Draft Multi-Topology OLSRv2 December 2013
metric types to their corresponding values). The following
subsections detail these extensions.
Note that, as in [OLSRv2], an implementation is free to organize its
internal data in any manner it chooses, it needs only to behave as if
it were organized as described in [OLSRv2] 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 [OLSRv2].
6.3. 2-Hop Sets
Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link-
metric].
Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link-
metric].
6.4. Neighbor Set
Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link-
metric].
Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link-
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].
Dearlove & Clausen Expires June 23, 2014 [Page 6]
Internet-Draft Multi-Topology OLSRv2 December 2013
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 value from this map is used, Router Topology Tuples
whose corresponding value of 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 value from this map is used, Routable Address Topology
Tuples whose corresponding value of 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 value from this map is used, Attached Network Tuples
whose corresponding value of 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.
Dearlove & Clausen Expires June 23, 2014 [Page 7]
Internet-Draft Multi-Topology OLSRv2 December 2013
7. TLVs
This specification makes the following additions and extensions to
the TLVs defined in [OLSRv2].
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 HELLO messages, and may be used in TC
messages. A message MUST NOT contain more than one MPR_TYPES TLV.
The presence of this TLV in a HELLO 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 [OLSRv2]. For this reason, the MPR_TYPES TLV
has been defined with the same Type as the MPR_WILLING TLV, but with
Type Extension == 1. (The different symbolic name is used for
convenience, any reference to a MPR_TYPES TLV means to this TLV, with
this Type and Type Extension.)
This TLV may take a Value field of any size. Each octet in its Value
field will contain a link metric type that is supported for the
OLSRv2 interface over which the HELLO message containing this TLV is
sent. These octets MAY be in any order, except that if there may be
any routers in the MANET not implementing MT-OLSRv2, then the first
octet MUST be LINK_METRIC_TYPE.
7.1.2. MPR_WILLING TLV
The MPR_WILLING TLV, which is used in HELLO messages, is specified in
[OLSRv2], and extended in this specification as enabled by
[TLV-Extensions].
The interpretation of this TLV, specified by [OLSRv2], and which uses
all of its single octet Value field, is unchanged. That
interpretation uses bits 0-3 of its Value field to specify its
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
Dearlove & Clausen Expires June 23, 2014 [Page 8]
Internet-Draft Multi-Topology OLSRv2 December 2013
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. (If there is no such TLV included,
then the router does not support MT-OLSRv2, and only the first octet
of the Value field will be used.)
If the number of link metric types in this OLSRv2 interface's
IFACE_METRIC_TYPES parameter is even, then there will be an unused 4
bit sub-field in bits 4-7 of the last octet of a full sized Value
field. These bits will not be used, they SHOULD all be cleared
('0').
If the Value field in an MPR_WILLING TLV is shorter than its full
length, then, as specified in [TLV-Extensions], missing Value octets,
i.e., missing willingness values, are considered as zero, i.e., as
WILL_NEVER. This is the correct behaviour. (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 recognise.)
7.2. Address Block TLVs
New Type Extensions are defined for the LINK_METRIC TLV defined in
[OLSRv2], and the Value fields of the MPR TLV and the GATEWAY TLV,
both defined in [OLSRv2], are extended, as enabled by
[TLV-Extensions].
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 [OLSRv2].
Only a single Type Extension was specified by [OLSRv2] (link metric
type) 0 as defined by administrative action. This specification
extends this range, it is suggested either to 0-7 or to 0-15. This
specification will work with any combination of Type Extensions both
within and without that range (assuming that the latter are defined
as specified in [OLSRv2]).
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 [OLSRv2], defined to
be one octet long, with the values 1, 2 and 3 defined.
[TLV-Extensions] redefines this Value field to be a bitfield where
Dearlove & Clausen Expires June 23, 2014 [Page 9]
Internet-Draft Multi-Topology OLSRv2 December 2013
bit 7 (the lsb) denotes flooding status, bit 6 denotes routing MPR
status, and bits 5-0 are unallocated (respecting the semantics of the
bits/values 1, 2 and 3 from [OLSRv2]).
This specification, as enabled by [TLV-Extensions], extends the MPR
TLV to have a variable-length Value field. For interoperability with
a router not implementing MT-OLSRv2, the two least significant bits
of the first octet in the Value field of this TLV MUST be the TLV
Value of the MPR TLV, generated according to [OLSRv2].
Subsequent bits (in increasing significance within an octet, then
continuing with the least significant bit in the next octet, if
required) in the TLV Value field indicate which link metric types,
for which the corresponding address is selected as a routing MPR,
link metric types (including the first) being indicated in the Value
field of an MPR_TYPES Message TLV.
7.2.3. GATEWAY TLV
The GATEWAY TLV is used in TC messages to indicate that a network
address is of an attached network.
The Value field of this address block TLV is, in [OLSRv2] defined to
be one octet long, containing the number of hops to that attached
network.
This specification, as enabled by [TLV-Extensions], allows the
extension the GATEWAY TLV to have a variable-length Value field when
the number of hops to each attached network is different for
different link metric types. For interoperability with a router not
implementing MT-OLSRv2, the first octet in the Value field of this
TLV MUST be the TLV Value of the GATEWAY TLV generated according to
[OLSRv2].
Any subsequent octets in the TLV Value field indicate the number of
hops to the attached network for each other link metric type, link
metric types (including the first) being indicated in the Value field
of an MPR_TYPES Message TLV.
+---------+---------------------------------------------------------+
| Type | Value |
+---------+---------------------------------------------------------+
| GATEWAY | Number of hops to attached network for each link metric |
| | type. |
+---------+---------------------------------------------------------+
Table 1: GATEWAY TLV definition
Dearlove & Clausen Expires June 23, 2014 [Page 10]
Internet-Draft Multi-Topology OLSRv2 December 2013
8. HELLO Messages
The following changes are made to the generation and processing of
HELLO messages compared to that described in [OLSRv2] by routers that
implement MT-OLSRv2.
8.1. HELLO Message Generation
A generated HELLO message to be sent on an OLSRv2 interface is
extended by:
o Adding an MPR_TYPES TLV. The value octets will be the link metric
types in IFACE_METRIC_TYPES.
o Extending the MPR_WILLING 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 TLVs that report all values of L_in_metric,
L_out_metric, N_in_metric and N_out_metric that are not equal to
UNKNOWN_METRIC, with the TLV Type Extension being the link metric
type, and otherwise following the rules for such inclusions
specified in [OLSRv2].
o Including MPR TLVs such that for each link metric type in
IFACE_METRIC_TYPES, and for the choice of flooding MPRs, these
MUST be an MPR set as specified for a single link metric type in
[OLSRv2].
8.2. HELLO Message Processing
On receipt of a HELLO message, a router implementing MT-OLSRv2 MUST,
in addition to the processing described in [OLSRv2]:
1. Determine the list of link metric types supported by the sending
router on the relevant OLSRv2 interface, either from an MPR_TYPES
TLV or, if not present, the type LINK_METRIC_TYPE supported by a
router not implementing the extension described in this
specification.
2. For those link metric types supported by both routers, set the
appropriate L_out_metric, N_in_metric, N_out_metric,
N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and
N2_out_metric values as described for the single such elements in
[OLSRv2].
Dearlove & Clausen Expires June 23, 2014 [Page 11]
Internet-Draft Multi-Topology OLSRv2 December 2013
3. For any other metric types supported by the receiving router
only, set those elements to their default value: 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 [OLSRv2] by routers that
implement MT-OLSRv2.
9.1. TC Message Generation
A generated TC message is extended by:
o If any GATEWAY TLVs are included requiring more than one number of
hops value, then adding an MPR_TYPES TLV with Value octets being
the link metric types in ROUTER_METRIC_TYPES.
o Including LINK_METRIC TLVs that report all values of N_out_metric
that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
being the link metric type, and otherwise following the rules for
such inclusions specified in [OLSRv2].
o When not all the same, including a number of hops per reported (in
an MPR_TYPES Messsage TLV) link metric type in the Value field of
each GATEWAY TLV included.
9.2. TC Message Processing
On receipt of a TC message, a router implementing this extension
MUST, in addition to the processing specified in [OLSRv2]:
o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric
elements using the rules for setting the single elements of those
types specified in [OLSRv2].
o For any other metric types supported by the receiving router that
do not have an advertised outgoing neighbor metric of that type,
set the corresponding elements of TR_metric, TA_metric and
AN_metric to UNKNOWN_METRIC. (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
Dearlove & Clausen Expires June 23, 2014 [Page 12]
Internet-Draft Multi-Topology OLSRv2 December 2013
interfaces that do not support that link metric type are not
considered. The determined status (routing MPR or not routing MPR)
for each link metric type is recorded in the relevant element of
N_routing_mpr.
Each router may make its own decision as to whether or not to use a
link metric, or link metrics, for flooding MPR calculation, and if so
which and how. This decision MUST be made in a manner that ensures
that flooded messages will reach the same symmetric 2-hop neighbors
as would be the case for a router not supporting MT-OLSRv2.
Note that it is possible that a 2-Hop Tuple in the Information Base
for a given OLSRv2 interface does not support any of the link metric
types that are in the router's corresponding IFACE_METRIC_TYPES, but
nevertheless that 2-Hop Tuple MUST be considered when determining
flooding MPRs.
11. Routing Set Calculation
A Routing Set is calculated for each link metric type in
ROUTER_METRIC_TYPES. The calculation may be as for [OLSRv2], except
that where an element is now represented by a map, the value from the
map for the selected link metric type is used. Where this is a link
metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for
the calculation.
12. Management Considerations
MT-OLSRv2 may require greater management than unextended OLSRv2. In
particular MT-OLSRv2 requires the following management
considerations:
o Selecting which link metrics to support on each OLSRv2 interface
and implementing that decision. (Different interfaces may have
different physical and data link layer properties, and this may
inform the selection of link metrics to support, and their
values.)
o Ensuring that the MANET is sufficiently connected. Note that if
there is any possibility that there are any routers not
implementing MT-OLSRv2, then the MANET will be connected, to the
maximum extent possible, using the link metric type
LINK_METRIC_TYPE.
o Deciding which link metric, and hence which Routing Set to use,
for received packets, hence how to use the Routing Sets to
Dearlove & Clausen Expires June 23, 2014 [Page 13]
Internet-Draft Multi-Topology OLSRv2 December 2013
configure the network layer (IP). An obvious approach is to map
each DiffServ Code Point (DSCP) [RFC2474] to a single link metric.
(This may be a many to one mapping.)
o Note that there could be cases where a router that is not
implementing MT-OLSRv2 is the source or destination of an IP
packet that is mapped to a link metric that is not the link metric
LINK_METRIC_TYPE used by that router.
o If such a router is the source, then routing may work if the first
router implementing MT-OLSRv2 to receive the packet supports the
appropriate link metric type. At worst the packet will be
dropped, it will not loop.
o If such a router is the destination, then the packet will never
reach its destination, as the source will not have a suitable
routing table entry for the destination. Network management may
be required to ensure that the MANET still functions in these
cases.
13. IANA Considerations
This specification adds one new Message TLV, allocated as a new Type
Extension to an existing Message TLV, using a new name. It also
modifies the Value field of an existing Message TLV, and of an
existing Address Block TLV.
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].
13.2. Message TLV Types
This specification replaces Table 11 of [OLSRv2]. That specified a
Message MPR Type described as MPR_WILLING, for which only Type
Extension 0 was defined. This specification reserves that name
MPR_WILLING for Type Extension 0, defines a new Type Extension 1,
with a new name MPR_TYPES, and leaves the remaining Type Extensions
of this TLV Type unnamed. It also changes the Value field
specification of the MPR_WILLING TLV.
Note: The Type number TBD2 will be replaced by the value assigned by
IANA when [OLSRv2] is published as an RFC, and this note will be
removed.
Dearlove & Clausen Expires June 23, 2014 [Page 14]
Internet-Draft Multi-Topology OLSRv2 December 2013
Specifications of these TLVs are in Table 2. Each of these TLVs MUST
NOT be included more than once in a Message TLV Block.
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+---------------------+------------+
| MPR_WILLING | TBD2 | 0 | Bits 0-3 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a flooding MPR. | |
| | | | Each following 4 | |
| | | | bit subfield (using | |
| | | | bits 0-3 of an | |
| | | | octet before bits | |
| | | | 4-7) specifies the | |
| | | | originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a routing MPR | |
| | | | for a link metric, | |
| | | | either a single | |
| | | | such field (bits | |
| | | | 4-7) when no | |
| | | | MPR_TYPES Message | |
| | | | TLV is present, or | |
| | | | one subfield per | |
| | | | type reported in an | |
| | | | MPR_TYPES Message | |
| | | | TLV Value field (in | |
| | | | the same order). | |
| MPR_TYPES | TBD2 | 1 | The link metric | |
| | | | types supported on | |
| | | | this OLSRv2 | |
| | | | interface of this | |
| | | | router (one octet | |
| | | | each). | |
| Unnamed | TBD2 | 2-255 | Unassigned. | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 2: Message TLV Type assignment: MPR_WILLING and MPR_TYPES
Dearlove & Clausen Expires June 23, 2014 [Page 15]
Internet-Draft Multi-Topology OLSRv2 December 2013
13.3. Address Block TLV Types
Table 16 of [OLSRv2] is replaced by Table 3. Note that the only
change is to the description of the Value field.
Note: The Type number TBD7 will be replaced by the value assigned by
IANA when [OLSRv2] is published as an RFC, and this note will be
removed.
+---------+------+-----------+-------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | Policy |
+---------+------+-----------+-------------------------+------------+
| GATEWAY | TBD7 | 0 | Specifies that a given | |
| | | | network address is | |
| | | | reached via a gateway | |
| | | | on the originating | |
| | | | router. The number of | |
| | | | hops is indicated by | |
| | | | the Value field, either | |
| | | | using a single octet | |
| | | | (if no MPR_TYPES | |
| | | | Message TLV is present) | |
| | | | or one octet per type | |
| | | | reported in an | |
| | | | MPR_TYPES Message TLV | |
| | | | (in the same order). | |
| GATEWAY | TBD7 | 1-255 | | Expert |
| | | | | Review |
+---------+------+-----------+-------------------------+------------+
Table 3: Address Block TLV Type assignment: GATEWAY
14. Security Considerations
TBD.
15. Acknowledgments
TBD.
16. References
Dearlove & Clausen Expires June 23, 2014 [Page 16]
Internet-Draft Multi-Topology OLSRv2 December 2013
16.1. Normative References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-19, March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444,
February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[TLV-Extensions]
Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol version 2 (OLSRv2) and MANET Neighborhood
Disovery Protocol (NHDP) Extension TLVs", work in
progress draft-ietf-manet-nhdp-olsrv2-tlv-extensions-00,
September 2013.
16.2. Informative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003.
Dearlove & Clausen Expires June 23, 2014 [Page 17]
Internet-Draft Multi-Topology OLSRv2 December 2013
Authors' Addresses
Christopher Dearlove
BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen
LIX, Ecole Polytechnique
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Dearlove & Clausen Expires June 23, 2014 [Page 18]
