draft-ietf-manet-olsrv2-multitopology-00.txt   draft-ietf-manet-olsrv2-multitopology-01.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC Internet-Draft BAE Systems ATC
Intended status: Experimental T. Clausen Intended status: Experimental T. Clausen
Expires: August 14, 2014 LIX, Ecole Polytechnique Expires: December 25, 2014 LIX, Ecole Polytechnique
February 10, 2014 June 23, 2014
Multi-Topology Extension for the Optimized Link State Routing Protocol Multi-Topology Extension for the Optimized Link State Routing Protocol
version 2 (OLSRv2) version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multitopology-00 draft-ietf-manet-olsrv2-multitopology-01
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.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014. This Internet-Draft will expire on December 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 5 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 6 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 6
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 6
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 6 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 6
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 7 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 7
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 7 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 7
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 7 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 7
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 7 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 8
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 8
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 8 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 8
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 8 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 8
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 9 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 9
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 9 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 9
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 9 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 10
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 10 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 10
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 11 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 11
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 11 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 11
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 12 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 12
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 12 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 12
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 12 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 13
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 13 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 13
12. Management Considerations . . . . . . . . . . . . . . . . . . 13 12. Management Considerations . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 14 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 15
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 16 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 16
14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
16.1. Normative References . . . . . . . . . . . . . . . . . . . 17 16.1. Normative References . . . . . . . . . . . . . . . . . . . 18
16.2. Informative References . . . . . . . . . . . . . . . . . . 17 16.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol, version 2 [OLSRv2] is a The Optimized Link State Routing Protocol, version 2 [RFC7181]
proactive link state routing protocol designed for use in mobile ad (OLSRv2) is a proactive link state routing protocol designed for use
hoc networks (MANETs) [RFC2501]. One of the significant improvements in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant
of OLSRv2 over its Experimental precursor [RFC3626] is the ability of improvements of OLSRv2 over its Experimental precursor [RFC3626] is
OLSRv2 to route over other than minimum hop routes, using a link the ability of OLSRv2 to route over other than minimum hop routes,
metric. using a link metric.
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 use alternative metrics for different packet desirable to be able to use alternative metrics for different packet
routing. This specification describes an extension to OLSRv2, that routing. This specification describes an extension to OLSRv2, that
is designed to permit this, while maintaining maximal is designed to permit this, while maintaining maximal
interoperability with OLSRv2 routers not implementing this extension. interoperability 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
skipping to change at page 3, line 36 skipping to change at page 3, line 36
sets. sets.
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
[OLSRv2], 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 [OLSRv2]. 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 [OLSRv2]. extension to [RFC7181].
This specification introduces the notation map[range -> type] to This specification introduces the notation map[A -> B] to represent
represent an associative map from elements of the range, which in an associative mapping. The domain of this mapping (A) is, in this
this specification is always a set of link metric types that the specification, always a set of link metric types that the router
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), to a type, which may be a boolean, a defined in Section 5. The codomain of this mapping (B) is a set of
willingness (a 4 bit unsigned integer from 0 to 15), a number of hops all possible values of an appropriate type, in this specification
(an 8 bit unsigned integer value from 0 to 255), or a metric-value this type is always one of:
(either a representable link metric value, as described in [OLSRv2],
or UNKNOWN_METRIC). o boolean (true or false),
o willingness (a 4 bit unsigned integer from 0 to 15);
o number of hops (an 8 bit unsigned integer from 0 to 255), or
o link metric (either a representable link metric value, as
described in [RFC7181], or UNKNOWN_METRIC).
3. Applicability Statement 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 [OLSRv2]), but in which for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3),
multiple topologies are maintained, each characterized by a different but in which multiple topologies are maintained, each characterized
choice of link metric type. It is assumed, but outside the scope of by a different choice of link metric type. It is assumed, but
this specification, that the network layer is able to choose which outside the scope of this specification, that the network layer is
topology to use for each packet, for example using the DiffServ Code able to choose which topology to use for each packet, for example
Point (DSCP) defined in [RFC2474]. using the DiffServ Code Point (DSCP) defined in [RFC2474].
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The purpose of this specification is to extend [OLSRv2] so as to The purpose of this specification is to extend [RFC7181] so as to
enable a router to establish and maintain multiple routing topologies enable a router to establish and maintain multiple routing topologies
in a MANET, each topology associated with a link metric type. 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 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 topologies, and each router will maintain a Routing Set for each
topology that it forms part of, allowing separate routing of packets topology that it forms part of, allowing separate routing of packets
for each topology. for each topology.
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 on how the MANET implement MT-OLSRv2, then there are no restrictions on how
these sets of link metrics are selected. However there may be these sets of link metrics are selected. However there may be
deployments where routers, that do not implement MT-OLSRv2 (non-MT- deployments where routers, that do not implement MT-OLSRv2 (non-MT-
OLSRv2 routers), are to participate in a MANET with MT-OLSRv2 OLSRv2 routers), are to participate in a MANET with MT-OLSRv2
routers. In this case, the single link metric used by these non-MT- 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 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 an MT-OLSRv2 router that may be heard on an
OLSRv2 interface of a non-MT-OLSRv2 router in the MANET. OLSRv2 interface of a 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. messages sent on OLSRv2 interfaces, and in all TC messages.
In addition to link and neighbor metric values for each link metric In addition to link and neighbor metric values for each link metric
type, router MPR (multipoint relay) and MPR selector status, and type, router MPR (multipoint relay) and MPR selector status, and
advertised neighbor status, is maintained per supported neighbor advertised neighbor status, is maintained per supported neighbor
skipping to change at page 5, line 14 skipping to change at page 5, line 21
More so than OLSRv2, the use of multiple metric types across the More so than OLSRv2, the use of multiple metric types across the
MANET must be managed, by administrative configuration or otherwise. MANET must be managed, by administrative configuration or otherwise.
Similarly to other decisions that may be made using OLSRv2, a bad Similarly to other decisions that may be made using OLSRv2, a bad
collective choice will make the MANET anywhere from inefficient to collective choice will make the MANET anywhere from inefficient to
non-functional, so care will be needed in selecting supported link non-functional, so care will be needed in selecting supported link
metric types across the MANET. metric types across the MANET.
5. Parameters 5. Parameters
The parameters used in [OLSRv2], including from its normative The parameters used in [RFC7181], including from its normative
references, are used in this specification with the following references, 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
[OLSRv2]. 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 [OLSRv2]). 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 may be any routers that do not
implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include
LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate
with any routers that do not implement MT-OLSRv2. In that case, with any routers that do not implement MT-OLSRv2. In that case,
ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE. ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE.
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 [OLSRv2], which extend those The Information Bases specified in [RFC7181], which extend those
specified in in [RFC6130], are further extended in this specified in in [RFC6130], are further extended in this
specification. With the exception of the Routing Set, the extensions specification. With the exception of the Routing Set, the extensions
in this specification are the replacement of single values (boolean, in this specification are the replacement of single values (boolean,
willingness, number of hops, or link-metric) from [OLSRv2] with willingness, number of hops, or link-metric) from [RFC7181] with
elements representing multiple values (associative maps from a set of elements representing multiple values (associative mappings from a
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 [OLSRv2], 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 [OLSRv2] 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].
6.2. Link Sets 6.2. Link Sets
Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link- Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link
metric]. metric].
Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link- Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link
metric]. metric].
The elements of L_in_metric MUST be set following the same rules that 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]. apply to the setting of the single element L_in_metric in [RFC7181].
6.3. 2-Hop Sets 6.3. 2-Hop Sets
Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
6.4. Neighbor Set 6.4. Neighbor Set
Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES ->
willingness]. willingness].
Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES ->
boolean]. boolean].
Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES ->
boolean]. boolean].
Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> Each element N_advertised becomes a map[ROUTER_METRIC_TYPES ->
boolean]. boolean].
6.5. Router Topology Set 6.5. Router Topology Set
Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
Note that some values of TR_metric may now take the value Note that some values of TR_metric may now take the value
UNKNOWN_METRIC. When used to construct a Routing Set, where just the UNKNOWN_METRIC. When used to construct a Routing Set, where just the
corresponding value from this map is used, Router Topology Tuples corresponding link metric value from this mapping is used, Router
whose corresponding value of TR_metric is UNKNOWN_METRIC are ignored. Topology Tuples whose corresponding value from TR_metric is
UNKNOWN_METRIC are ignored.
6.6. Routable Address Topology Set 6.6. Routable Address Topology Set
Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
Note that some values of TA_metric may now take the value Note that some values of TA_metric may now take the value
UNKNOWN_METRIC. When used to construct a Routing Set, where just the UNKNOWN_METRIC. When used to construct a Routing Set, where just the
corresponding value from this map is used, Routable Address Topology corresponding link metric value from this mapping is used, Routable
Tuples whose corresponding value of TA_metric is UNKNOWN_METRIC are Address Topology Tuples whose corresponding value from TA_metric is
ignored. UNKNOWN_METRIC are ignored.
6.7. Attached Network Set 6.7. Attached Network Set
Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of
hops]. hops].
Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link- Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link
metric]. metric].
Note that some values of AN_metric may now take the value Note that some values of AN_metric may now take the value
UNKNOWN_METRIC. When used to construct a Routing Set, where just the UNKNOWN_METRIC. When used to construct a Routing Set, where just the
corresponding value from this map is used, Attached Network Tuples corresponding link metric value from this mapping is used, Attached
whose corresponding value of AN_metric is UNKNOWN_METRIC are ignored. Network Tuples whose corresponding value from AN_metric is
UNKNOWN_METRIC are ignored.
6.8. Routing Sets 6.8. Routing Sets
There is a separate Routing Set for each link metric type in There is a separate Routing Set for each link metric type in
ROUTER_METRIC_TYPES. ROUTER_METRIC_TYPES.
7. TLVs 7. TLVs
This specification makes the following additions and extensions to This specification makes the following additions and extensions to
the TLVs defined in [OLSRv2]. the TLVs defined in [RFC7181].
7.1. Message TLVs 7.1. Message TLVs
One new Message TLV is defined in this specification, and one One new Message TLV is defined in this specification, and one
existing Message TLV is extended by this specification. existing Message TLV is extended by this specification.
7.1.1. MPR_TYPES TLV 7.1.1. MPR_TYPES TLV
The MPR_TYPES TLV is used in HELLO messages, and may be used in TC 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. 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 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 router supports MT-OLSRv2, in the same way that the presence of
the MPR_WILLING TLV is used to indicate that the router supports the MPR_WILLING TLV is used to indicate that the router supports
OLSRv2, as specified in [OLSRv2]. For this reason, the MPR_TYPES TLV OLSRv2, as specified in [RFC7181]. For this reason, the MPR_TYPES
has been defined with the same Type as the MPR_WILLING TLV, but with TLV has been defined with the same Type as the MPR_WILLING TLV, but
Type Extension == 1. (The different symbolic name is used for with Type Extension == 1. (The different symbolic name is used for
convenience, any reference to a MPR_TYPES TLV means to this TLV, with convenience, any reference to a MPR_TYPES TLV means to this TLV, with
this Type and Type Extension.) this Type and Type Extension.)
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 for the field will contain a link metric type that is supported for the
OLSRv2 interface over which the HELLO message containing this TLV is 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 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 any routers in the MANET not implementing MT-OLSRv2, then the first
octet MUST be LINK_METRIC_TYPE. octet MUST be 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
[OLSRv2], and extended in this specification as enabled by [RFC7181], and extended in this specification as enabled by
[TLV-Extensions]. [RFC7188].
The interpretation of this TLV, specified by [OLSRv2], and which uses The interpretation of this TLV, specified by [RFC7181], and which
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
skipping to change at page 9, line 18 skipping to change at page 9, line 26
then the router does not support MT-OLSRv2, and only the first octet then the router does not support MT-OLSRv2, and only the first octet
of the Value field will be used.) 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 4
bit sub-field in bits 4-7 of the last octet of a full sized Value 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').
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 [TLV-Extensions], missing Value octets, length, then, as specified in [RFC7188], missing Value octets, i.e.,
i.e., missing willingness values, are considered as zero, i.e., as missing willingness values, are considered as zero, i.e., as
WILL_NEVER. This is the correct behaviour. (In particular it means WILL_NEVER. This is the correct behavior. (In particular it means
that an OLSRv2 router that is not implementing MT-OLSRv2 will not act 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.) as a 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
[OLSRv2], 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 [OLSRv2], are extended, as enabled by both defined in [RFC7181], are extended, as enabled by [RFC7188].
[TLV-Extensions].
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 [OLSRv2]. TLV is unchanged from the definition in [RFC7181].
Only a single Type Extension was specified by [OLSRv2] (link metric Only a single Type Extension was specified by [RFC7181] (link metric
type) 0 as defined by administrative action. This specification type) 0 as defined by administrative action. This specification
extends this range, it is suggested either to 0-7 or to 0-15. This 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 specification will work with any combination of Type Extensions both
within and without that range (assuming that the latter are defined within and without that range (assuming that the latter are defined
as specified in [OLSRv2]). 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 [OLSRv2], defined to The Value field of this address block TLV is, in [RFC7181], defined
be one octet long, with the values 1, 2 and 3 defined. to be one octet long, with the values 1, 2 and 3 defined. [RFC7188]
[TLV-Extensions] redefines this Value field to be a bitfield where redefines this Value field to be a bitfield where bit 7 (the lsb)
bit 7 (the lsb) denotes flooding status, bit 6 denotes routing MPR denotes flooding status, bit 6 denotes routing MPR status, and bits
status, and bits 5-0 are unallocated (respecting the semantics of the 5-0 are unallocated (respecting the semantics of the bits/values 1, 2
bits/values 1, 2 and 3 from [OLSRv2]). and 3 from [RFC7181]).
This specification, as enabled by [TLV-Extensions], extends the MPR This specification, as enabled by [RFC7188], extends the MPR TLV to
TLV to have a variable-length Value field. For interoperability with have a variable-length Value field. For interoperability with a
a router not implementing MT-OLSRv2, the two least significant bits router not implementing MT-OLSRv2, the two least significant bits of
of the first octet in the Value field of this TLV MUST be the TLV the first octet in the Value field of this TLV MUST be the TLV Value
Value of the MPR TLV, generated according to [OLSRv2]. of the MPR TLV, generated according to [RFC7181].
Subsequent bits (in increasing significance within an octet, then Subsequent bits (in increasing significance within an octet, then
continuing with the least significant bit in the next octet, if continuing with the least significant bit in the next octet, if
required) in the TLV Value field indicate which link metric types, required) in the TLV Value field indicate which link metric types,
for which the corresponding address is selected as a routing MPR, for which the corresponding address is selected as a routing MPR,
link metric types (including the first) being indicated in the Value link metric types (including the first) being indicated in the Value
field of an MPR_TYPES Message TLV. field of an MPR_TYPES Message TLV.
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 [OLSRv2] defined to The Value field of this address block TLV is, in [RFC7181] defined to
be one octet long, containing the number of hops to that attached be one octet long, containing the number of hops to that attached
network. network.
This specification, as enabled by [TLV-Extensions], allows the This specification, as enabled by [RFC7181], allows the extension the
extension the GATEWAY TLV to have a variable-length Value field when GATEWAY TLV to have a variable-length Value field when the number of
the number of hops to each attached network is different for hops to each attached network is different for different link metric
different link metric types. For interoperability with a router not types. For interoperability with a router not implementing MT-
implementing MT-OLSRv2, the first octet in the Value field of this OLSRv2, the first octet in the Value field of this TLV MUST be the
TLV MUST be the TLV Value of the GATEWAY TLV generated according to TLV Value of the GATEWAY TLV generated according to [RFC7181].
[OLSRv2].
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) being indicated in the Value field
of an MPR_TYPES Message TLV. 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 [OLSRv2] by routers that HELLO messages compared to that described in [RFC7181] by routers
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 is A generated HELLO message to be sent on an OLSRv2 interface is
extended by: 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 IFACE_METRIC_TYPES. types in IFACE_METRIC_TYPES.
o Extending the MPR_WILLING TLV Value field to report the o Extending the MPR_WILLING TLV Value field to report the
skipping to change at page 11, line 34 skipping to change at page 11, line 43
o Including LINK_METRIC TLVs that report all values of L_in_metric, 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 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 UNKNOWN_METRIC, with the TLV Type Extension being the link metric
type, and otherwise following the rules for such inclusions type, and otherwise following the rules for such inclusions
specified in [OLSRv2]. specified in [OLSRv2].
o Including MPR TLVs such that for each link metric type in o Including MPR TLVs such that for each link metric type in
IFACE_METRIC_TYPES, and for the choice of flooding MPRs, these 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 MUST be an MPR set as specified for a single link metric type in
[OLSRv2]. [RFC7181].
8.2. HELLO Message Processing 8.2. HELLO Message Processing
On receipt of a HELLO message, a router implementing MT-OLSRv2 MUST, On receipt of a HELLO message, a router implementing MT-OLSRv2 MUST,
in addition to the processing described in [OLSRv2]: in addition to the processing described in [RFC7181]:
1. Determine the list of link metric types supported by the sending 1. Determine the list of link metric types supported by the sending
router on the relevant OLSRv2 interface, either from an MPR_TYPES router on the relevant OLSRv2 interface, either from an MPR_TYPES
TLV or, if not present, the type LINK_METRIC_TYPE supported by a TLV or, if not present, the type LINK_METRIC_TYPE supported by a
router not implementing the extension described in this router not implementing the extension described in this
specification. specification.
2. For those link metric types supported by both routers, set the 2. For those link metric types supported by both routers, set the
appropriate L_out_metric, N_in_metric, N_out_metric, appropriate L_out_metric, N_in_metric, N_out_metric,
N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and
N2_out_metric values as described for the single such elements in N2_out_metric values as described for the single such elements in
[OLSRv2]. [RFC7181].
3. For any other metric types supported by the receiving router 3. For any other metric types supported by the receiving router
only, set those elements to their default value: UNKNOWN_METRIC, only, set those elements to their default value: UNKNOWN_METRIC,
WILL_NEVER (not WILL_DEFAULT), or false. WILL_NEVER (not WILL_DEFAULT), or 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 [OLSRv2] 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 If any GATEWAY TLVs are included requiring more than one number of 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 hops value, then adding an MPR_TYPES TLV with Value octets being
the link metric types in ROUTER_METRIC_TYPES. the link metric types in ROUTER_METRIC_TYPES.
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 [OLSRv2]. such inclusions specified in [RFC7181].
o When not all the same, including a number of hops per reported (in 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 an MPR_TYPES Message TLV) link metric type in the Value field of
each GATEWAY TLV included. each GATEWAY TLV included.
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, in addition to the processing specified in [OLSRv2]: MUST, in addition to the processing specified in [RFC7181]:
o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric
elements using the rules for setting the single elements of those elements using the rules for setting the single elements of those
types specified in [OLSRv2]. 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
skipping to change at page 13, line 24 skipping to change at page 13, line 35
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, but
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 [OLSRv2], 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 MT-OLSRv2 requires the following management particular MT-OLSRv2 requires the following management
considerations: considerations:
skipping to change at page 14, line 29 skipping to change at page 14, line 40
reach its destination, as the source will not have a suitable reach its destination, as the source will not have a suitable
routing table entry for the destination. Network management may routing table entry for the destination. Network management may
be required to ensure that the MANET still functions in these be required to ensure that the MANET still functions in these
cases. cases.
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 of an
existing Address Block TLV. existing Address Block TLV. Finally, this specification makes
additional allocations from the LINK_METRIC Address Block TLV Type
registry.
13.1. Expert Review: Evaluation Guidelines 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]. consideration as are specified by [RFC5444].
13.2. Message TLV Types 13.2. Message TLV Types
This specification replaces Table 11 of [OLSRv2]. That specified a This specification replaces Table 11 of [RFC7181]. That specified a
Message MPR Type described as MPR_WILLING, for which only Type Message MPR Type described as MPR_WILLING, for which only Type
Extension 0 was defined. This specification reserves that name Extension 0 was defined. This specification reserves that name
MPR_WILLING for Type Extension 0, defines a new Type Extension 1, MPR_WILLING for Type Extension 0, defines a new Type Extension 1,
with a new name MPR_TYPES, and leaves the remaining Type Extensions with a new name MPR_TYPES, and leaves the remaining Type Extensions
of this TLV Type unnamed. It also changes the Value field of this TLV Type unnamed. It also changes the Value field
specification of the MPR_WILLING TLV. 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.
Specifications of these TLVs are in Table 2. Each of these TLVs MUST Specifications of these TLVs are in Table 2. Each of these TLVs MUST
NOT be included more than once in a Message TLV Block. NOT be included more than once in a Message TLV Block.
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
| MPR_WILLING | TBD2 | 0 | Bits 0-3 specify | | | MPR_WILLING | 7 | 0 | Bits 0-3 specify | |
| | | | the originating | | | | | | the originating | |
| | | | router's | | | | | | router's | |
| | | | willingness to act | | | | | | willingness to act | |
| | | | as a flooding MPR. | | | | | | as a flooding MPR. | |
| | | | Each following 4 | | | | | | Each following 4 | |
| | | | bit subfield (using | | | | | | bit subfield (using | |
| | | | bits 0-3 of an | | | | | | bits 0-3 of an | |
| | | | octet before bits | | | | | | octet before bits | |
| | | | 4-7) specifies the | | | | | | 4-7) specifies the | |
| | | | originating | | | | | | originating | |
skipping to change at page 15, line 37 skipping to change at page 16, line 34
| | | | either a single | | | | | | either a single | |
| | | | such field (bits | | | | | | such field (bits | |
| | | | 4-7) when no | | | | | | 4-7) when no | |
| | | | MPR_TYPES Message | | | | | | MPR_TYPES Message | |
| | | | TLV is present, or | | | | | | TLV is present, or | |
| | | | one subfield per | | | | | | one subfield per | |
| | | | type reported in an | | | | | | type reported in an | |
| | | | MPR_TYPES Message | | | | | | MPR_TYPES Message | |
| | | | TLV Value field (in | | | | | | TLV Value field (in | |
| | | | the same order). | | | | | | the same order). | |
| MPR_TYPES | TBD2 | 1 | The link metric | | | MPR_TYPES | 7 | 1 | The link metric | |
| | | | types supported on | | | | | | types supported on | |
| | | | this OLSRv2 | | | | | | this OLSRv2 | |
| | | | interface of this | | | | | | interface of this | |
| | | | router (one octet | | | | | | router (one octet | |
| | | | each). | | | | | | each). | |
| Unnamed | TBD2 | 2-255 | Unassigned. | Expert | | Unnamed | 7 | 2-255 | Unassigned. | Expert |
| | | | | Review | | | | | | Review |
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
Table 2: Message TLV Type assignment: MPR_WILLING and MPR_TYPES Table 2: Message TLV Type assignment: MPR_WILLING and MPR_TYPES
13.3. Address Block TLV Types 13.3. Address Block TLV Types
Table 16 of [OLSRv2] is replaced by Table 3. Note that the only Table 16 of [RFC7181] is replaced by Table 3. Note that the only
change is to the description of the Value field. 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 | | Name | Type | Type | Description | Allocation |
| | | extension | | Policy | | | | extension | | Policy |
+---------+------+-----------+-------------------------+------------+ +---------+------+-----------+-------------------------+------------+
| GATEWAY | TBD7 | 0 | Specifies that a given | | | GATEWAY | 10 | 0 | Specifies that a given | |
| | | | network address is | | | | | | network address is | |
| | | | reached via a gateway | | | | | | reached via a gateway | |
| | | | on the originating | | | | | | on the originating | |
| | | | router. The number of | | | | | | router. The number of | |
| | | | hops is indicated by | | | | | | hops is indicated by | |
| | | | the Value field, either | | | | | | the Value field, either | |
| | | | using a single octet | | | | | | using a single octet | |
| | | | (if no MPR_TYPES | | | | | | (if no MPR_TYPES | |
| | | | Message TLV is present) | | | | | | Message TLV is present) | |
| | | | or one octet per type | | | | | | or one octet per type | |
| | | | reported in an | | | | | | reported in an | |
| | | | MPR_TYPES Message TLV | | | | | | MPR_TYPES Message TLV | |
| | | | (in the same order). | | | | | | (in the same order). | |
| GATEWAY | TBD7 | 1-255 | | Expert | | GATEWAY | 10 | 1-255 | | Expert |
| | | | | Review | | | | | | Review |
+---------+------+-----------+-------------------------+------------+ +---------+------+-----------+-------------------------+------------+
Table 3: Address Block TLV Type assignment: GATEWAY Table 3: Address Block TLV Type assignment: GATEWAY
Table 13 of [RFC7181] is replaced by Table 4. Note that the only
change is to allocate 8 Type Extensions as assigned by administrative
action, in order to support administratively determined multi-
topologies.
+-------------+------+-----------+-------------------+--------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | 7 | 0-7 | Link metric | |
| | | | meaning assigned | |
| | | | by administrative | |
| | | | action. | |
| LINK_METRIC | 7 | 8-223 | Unassigned. | Expert |
| | | | | Review |
| LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental |
| | | | | Use |
+-------------+------+-----------+-------------------+--------------+
Table 4: Address Block TLV Type assignment: LINK_METRIC
14. Security Considerations 14. Security Considerations
TBD. This extension to OLSRv2 allows a router to support more than one
link metric type for each link advertised in HELLO and TC messages,
and for routers to support different sets of types. Link metric
values of additional types are reported by the inclusion of
additional TLVs in the messages sent by a router, which will report
known values of all supported types.
HELLO and TC message processing is then extended simply to record,
for each supported type, all of the received link metric values for
each link. Protocol internal processing (specifically MPR set and
shortest path calculations) then operate as specified in [RFC7181]
for each link metric type that the router supports.
Consequently the security considerations, including the security
architecture and the mandatory security mechanisms, from [RFC7181]
are directly applicable to MT-OLSRv2.
Furthermore, this extension does not introduce any additional
vulnerabilities over those of [RFC7181], because each link metric
type is used independently, and each one could have been the single
link metric type supported by an implementation of [RFC7181]
receiving the same information, as received information of an
unsupported type is ignored by all routers.
15. Acknowledgments 15. Acknowledgments
TBD. TBD.
16. References 16. References
16.1. Normative References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 16.1. Normative References
"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 [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, March 1997.
[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 MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[TLV-Extensions] [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
Dearlove, C. and T. Clausen, "Optimized Link State Routing "The Optimized Link State Routing Protocol version 2",
RFC 7181, April 2014.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol version 2 (OLSRv2) and MANET Neighborhood Protocol version 2 (OLSRv2) and MANET Neighborhood
Disovery Protocol (NHDP) Extension TLVs", work in Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
progress draft-ietf-manet-nhdp-olsrv2-tlv-extensions-00, April 2014.
September 2013.
16.2. Informative References 16.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. December 1998.
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
 End of changes. 78 change blocks. 
142 lines changed or deleted 185 lines changed or added

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