draft-ietf-manet-olsrv2-multitopology-02.txt   draft-ietf-manet-olsrv2-multitopology-03.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: December 27, 2014 LIX, Ecole Polytechnique Expires: January 5, 2015 LIX, Ecole Polytechnique
June 25, 2014 July 4, 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-02 draft-ietf-manet-olsrv2-multitopology-03
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 December 27, 2014. This Internet-Draft will expire on January 5, 2015.
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 14 skipping to change at page 2, line 14
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Experimentation . . . . . . . . . . . . . . 3 1.1. Motivation and Experimentation . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 6 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 7 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 7
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 7
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 7
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 8 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 8
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 8 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 8
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 8 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 8
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 8 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 9
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 9 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 9
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 9 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 9
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 10 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 10
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 10 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 10
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 10 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 11
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 11 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 11
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 12 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 12
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 12 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 12
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 13 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 13
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 13 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 13
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 13 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 14
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 14 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 14
12. Management Considerations . . . . . . . . . . . . . . . . . . 14 12. Management Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 15 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 16
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 15 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 16
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 16 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
16.2. Informative References . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol, version 2 [RFC7181] The Optimized Link State Routing Protocol, version 2 [RFC7181]
(OLSRv2) is a proactive link state routing protocol designed for use (OLSRv2) is a proactive link state routing protocol designed for use
in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant
improvements of OLSRv2 over its Experimental precursor [RFC3626] is improvements of OLSRv2 over its Experimental precursor [RFC3626] is
the ability of OLSRv2 to route over other than minimum hop routes, the ability of OLSRv2 to route over other than minimum hop routes,
using a link 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 route packets using more than one link metric type.
routing. This specification describes an extension to OLSRv2, that This specification describes an extension to OLSRv2 that is designed
is designed to permit this, while maintaining maximal to permit this, while maintaining maximal interoperability with
interoperability with OLSRv2 routers not implementing this extension. OLSRv2 routers not implementing this extension.
The purpose of OLSRv2 can be described as to create and maintain a The purpose of OLSRv2 can be described as to create and maintain a
Routing Set, which contains all the necessary information to populate Routing Set, which contains all the necessary information to populate
an IP routing table. In a similar way, the role of this extension an IP routing table. In a similar way, the role of this extension
can be described as to create and maintain multiple Routing Sets, one can be described as to create and maintain multiple Routing Sets, one
for each link metric type supported by the router maintaining the for each link metric type supported by the router maintaining the
sets. sets.
1.1. Motivation and Experimentation 1.1. Motivation and Experimentation
skipping to change at page 5, line 13 skipping to change at page 5, line 13
described in [RFC7181], or UNKNOWN_METRIC). described in [RFC7181], or UNKNOWN_METRIC).
3. Applicability Statement 3. Applicability Statement
The protocol described in this specification is applicable to a MANET The protocol described in this specification is applicable to a MANET
for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3),
but in which multiple topologies are maintained, each characterized but in which multiple topologies are maintained, each characterized
by a different choice of link metric type. It is assumed, but by a different choice of link metric type. It is assumed, but
outside the scope of this specification, that the network layer is outside the scope of this specification, that the network layer is
able to choose which topology to use for each packet, for example able to choose which topology to use for each packet, for example
using the DiffServ Code Point (DSCP) defined in [RFC2474]. using the DiffServ Code Point (DSCP) defined in [RFC2474]. This
selection of topology must be consistent, that is each router
receiving a packet must make the same choice of link metric type, in
order that each packet uses a single topology. This is necessary to
avoid the possibility of a packet "looping" in the network.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The purpose of this specification is to extend [RFC7181] 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.
routers. In this case, the single link metric used by these non-MT- In this case, the single link metric used by these non-MT-OLSRv2
OLSRv2 routers must be included in the set of link metrics for each routers must be included in the set of link metrics for each OLSRv2
OLSRv2 interface of an MT-OLSRv2 router that may be heard on an interface of an MT-OLSRv2 router that may be heard on an OLSRv2
OLSRv2 interface of a non-MT-OLSRv2 router in the MANET. 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. Both
HELLO and TC messages generated by an MT-OLSRv2 router (other than
one using only the single metric type used by non-MT-OLSRv2 routers)
include an MPR_TYPES Message TLV that indicates that this is an MT-
OLSRv2 router and which metric types it supports (on the sending
OLSRv2 interface for a HELLO message).
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
metric type for each symmetric 1-hop neighbor. Each router may metric type, for each symmetric 1-hop neighbor. Each router may
choose a different willingness to be a routing MPR for each link choose a different willingness to be a routing MPR for each link
metric type that it supports. metric type that it supports.
More so than OLSRv2, the use of multiple metric types across the A network using MT-OLSRv2 will usually require greater management
MANET must be managed, by administrative configuration or otherwise. than one using unmodified OLSRv2. In particular, the use of multiple
Similarly to other decisions that may be made using OLSRv2, a bad metric types across the MANET must be managed, by administrative
collective choice will make the MANET anywhere from inefficient to configuration or otherwise. As also for other decisions that may be
non-functional, so care will be needed in selecting supported link made when using OLSRv2, a bad collective choice of metric type use
metric types across the MANET. 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 5. Parameters
The parameters used in [RFC7181], 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
[RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers
skipping to change at page 6, line 44 skipping to change at page 7, line 11
In addition, the router parameter WILL_ROUTING is extended to an In addition, the router parameter WILL_ROUTING is extended to an
array of values, one each for each link metric type in the router array of values, one each for each link metric type in the router
parameter list ROUTER_METRIC_TYPES. parameter list ROUTER_METRIC_TYPES.
6. Information Bases 6. Information Bases
The Information Bases specified in [RFC7181], which extend those The Information Bases specified in [RFC7181], which extend those
specified in in [RFC6130], are further extended in this specified in 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 [RFC7181] with willingness, number of hops, or link metric) from [RFC7181] with
elements representing multiple values (associative mappings from a elements representing multiple values (associative mappings from a
set of metric types to their corresponding values). The following set of metric types to their corresponding values). The following
subsections detail these extensions. subsections detail these extensions.
Note that, as in [RFC7181], an implementation is free to organize its Note that, as in [RFC7181], an implementation is free to organize its
internal data in any manner it chooses, it needs only to behave as if internal data in any manner it chooses, it needs only to behave as if
it were organized as described in [RFC7181] and this specification. it were organized as described in [RFC7181] and this specification.
6.1. Local Attached Network Set 6.1. Local Attached Network Set
skipping to change at page 9, line 12 skipping to change at page 9, line 23
This specification makes the following additions and extensions to This specification makes the following additions and extensions to
the TLVs defined in [RFC7181]. 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 both HELLO messages sent over OLSRv2
messages. A message MUST NOT contain more than one MPR_TYPES TLV. interfaces and 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 presence of this TLV in a message is used to indicate that the
the router supports MT-OLSRv2, in the same way that the presence of router supports MT-OLSRv2, in the same way that the presence of the
the MPR_WILLING TLV is used to indicate that the router supports MPR_WILLING TLV is used to indicate that the router supports OLSRv2,
OLSRv2, as specified in [RFC7181]. For this reason, the MPR_TYPES as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has
TLV has been defined with the same Type as the MPR_WILLING TLV, but been defined with the same Type as the MPR_WILLING TLV, but with Type
with Type Extension == 1. (The different symbolic name is used for 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, either on
OLSRv2 interface over which the HELLO message containing this TLV is any OLSRv2 interface, when included in a TC message, or on the OLSRv2
sent. These octets MAY be in any order, except that if there may be interface on which an including HELLO message is sent. These octets
any routers in the MANET not implementing MT-OLSRv2, then the first MAY be in any order, except that if there may be any routers in the
octet MUST be LINK_METRIC_TYPE. MANET not implementing MT-OLSRv2, then the first 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
[RFC7181], and extended in this specification as enabled by [RFC7181], and extended in this specification as enabled by
[RFC7188]. [RFC7188].
The interpretation of this TLV, specified by [RFC7181], and which The interpretation of this TLV, specified by [RFC7181], and which
uses all of its single octet Value field, is unchanged. That uses all of its single octet Value field, is unchanged. That
interpretation uses bits 0-3 of its Value field to specify its interpretation uses bits 0-3 of its Value field to specify its
skipping to change at page 10, line 32 skipping to change at page 10, line 47
[RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV,
both defined in [RFC7181], are extended, as enabled by [RFC7188]. both defined in [RFC7181], are extended, as enabled by [RFC7188].
7.2.1. LINK_METRIC TLV 7.2.1. LINK_METRIC TLV
The LINK_METRIC TLV is used in HELLO messages and TC messages. This The LINK_METRIC TLV is used in HELLO messages and TC messages. This
TLV is unchanged from the definition in [RFC7181]. TLV is unchanged from the definition in [RFC7181].
Only a single Type Extension was specified by [RFC7181] (link metric Only a single Type Extension was specified by [RFC7181] (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 to 0-7. This specification will work with any
specification will work with any combination of Type Extensions both combination of Type Extensions both within and without that range
within and without that range (assuming that the latter are defined (assuming that the latter are defined as specified in [RFC7181]).
as specified in [RFC7181]).
7.2.2. MPR TLV 7.2.2. MPR TLV
The MPR TLV is used in HELLO messages, and indicates that an address The MPR TLV is used in HELLO messages, and indicates that an address
with which it is associated is of a symmetric 1-hop neighbor that has with which it is associated is of a symmetric 1-hop neighbor that has
been selected as an MPR. been selected as an MPR.
The Value field of this address block TLV is, in [RFC7181], defined The Value field of this address block TLV is, in [RFC7181], defined
to be one octet long, with the values 1, 2 and 3 defined. [RFC7188] to be one octet long, with the values 1, 2 and 3 defined. [RFC7188]
redefines this Value field to be a bitfield where bit 7 (the lsb) redefines this Value field to be a bitfield where bit 7 (the lsb)
skipping to change at page 11, line 12 skipping to change at page 11, line 28
This specification, as enabled by [RFC7188], extends the MPR TLV to This specification, as enabled by [RFC7188], extends the MPR TLV to
have a variable-length Value field. For interoperability with a have a variable-length Value field. For interoperability with a
router not implementing MT-OLSRv2, the two least significant bits of 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 the first octet in the Value field of this TLV MUST be the TLV Value
of the MPR TLV, generated according to [RFC7181]. 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, and used
field of an MPR_TYPES Message TLV. in the same order as, the Value 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 [RFC7181] 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.
skipping to change at page 12, line 7 skipping to change at page 12, line 22
Table 1: GATEWAY TLV definition Table 1: GATEWAY TLV definition
8. HELLO Messages 8. HELLO Messages
The following changes are made to the generation and processing of The following changes are made to the generation and processing of
HELLO messages compared to that described in [RFC7181] by routers HELLO messages compared to that described in [RFC7181] by routers
that implement MT-OLSRv2. that implement MT-OLSRv2.
8.1. HELLO Message Generation 8.1. HELLO Message Generation
A generated HELLO message to be sent on an OLSRv2 interface is A generated HELLO message to be sent on an OLSRv2 interface (whose
extended by: IFACE_METRIC_TYPES parameter will be that used) is extended by:
o Adding an MPR_TYPES TLV. The value octets will be the link metric o Adding an MPR_TYPES Message TLV. The Value octets will be the
types in IFACE_METRIC_TYPES. link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted
if the only link metric type included would be LINK_METRIC_TYPE.
o Extending the MPR_WILLING TLV Value field to report the o Extending the MPR_WILLING Message TLV Value field to report the
willingness values from the WILL_ROUTING parameter list that willingness values from the WILL_ROUTING parameter list that
correspond to the link metric types in IFACE_METRIC_LIST, in the correspond to the link metric types in IFACE_METRIC_LIST, in the
same order as reported in the MPR_TYPES TLV, each value (also same order as reported in the MPR_TYPES TLV, each value (also
including one representing WILL_FLOODING) occupying 4 bits. including one representing WILL_FLOODING) occupying 4 bits.
o Including LINK_METRIC TLVs that report all values of L_in_metric, o Including LINK_METRIC Address Block TLVs that report all values in
L_out_metric, N_in_metric and N_out_metric that are not equal to L_in_metric, L_out_metric, N_in_metric and N_out_metric elements
UNKNOWN_METRIC, with the TLV Type Extension being the link metric that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
type, and otherwise following the rules for such inclusions being the link metric type, and otherwise following the rules for
specified in [OLSRv2]. such inclusions specified in [OLSRv2].
o Including MPR TLVs such that for each link metric type in o Including MPR Address Block TLVs such that for each link metric
IFACE_METRIC_TYPES, and for the choice of flooding MPRs, these type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs,
MUST be an MPR set as specified for a single link metric type in the indicated addresses MUST be of the MPRs in an MPR set as
[RFC7181]. specified for a single link metric type in [RFC7181].
8.2. HELLO Message Processing 8.2. HELLO Message Processing
On receipt of a HELLO message, a router implementing MT-OLSRv2 MUST, On receipt of a HELLO message on an OLSRv2 interface, a router
in addition to the processing described in [RFC7181]: implementing MT-OLSRv2 MUST, 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 its corresponding OLSRv2 interface, either from an
TLV or, if not present, the type LINK_METRIC_TYPE supported by a MPR_TYPES Message TLV or, if not present, the single link metric
router not implementing the extension described in this type LINK_METRIC_TYPE.
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 single such elements in
[RFC7181]. [RFC7181].
3. For any other metric types supported by the receiving router 3. For any other metric types supported by the receiving router only
only, set those elements to their default value: UNKNOWN_METRIC, (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set
WILL_NEVER (not WILL_DEFAULT), or false. the elements listed in the previous point to their default
values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or
false.
9. TC Messages 9. TC Messages
The following changes are made to the generation and processing of TC The following changes are made to the generation and processing of TC
messages compared to that described in [RFC7181] by routers that messages compared to that described in [RFC7181] by routers that
implement MT-OLSRv2. implement MT-OLSRv2.
9.1. TC Message Generation 9.1. TC Message Generation
A generated TC message is extended by: A generated TC message is extended by:
o If any GATEWAY TLVs are included requiring more than one number of o Adding an MPR_TYPES TLV. The value octets will be the link metric
hops value, then adding an MPR_TYPES TLV with Value octets being types in ROUTER_METRIC_TYPES. This MAY be omitted if the only
the link metric types in ROUTER_METRIC_TYPES. link metric type included would be LINK_METRIC_TYPE.
o Including LINK_METRIC TLVs that report all values of N_out_metric o Including LINK_METRIC TLVs that report all values of N_out_metric
that are not equal to UNKNOWN_METRIC, with the TLV Type Extension that are not equal to UNKNOWN_METRIC, with the TLV Type Extension
being the link metric type, and otherwise following the rules for being the link metric type, and otherwise following the rules for
such inclusions specified in [RFC7181]. such inclusions specified in [RFC7181].
o When not all the same, including a number of hops per reported (in o When not all the same, including a number of hops per reported (in
an MPR_TYPES Message 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, in the same order as reported in the
MPR_TYPES TLV.
9.2. TC Message Processing 9.2. TC Message Processing
On receipt of a TC message, a router implementing this extension On receipt of a TC message, a router implementing this extension
MUST, in addition to the processing specified in [RFC7181]: 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 [RFC7181]. types specified in [RFC7181].
skipping to change at page 14, line 46 skipping to change at page 15, line 19
values.) values.)
o Ensuring that the MANET is sufficiently connected. Note that if o Ensuring that the MANET is sufficiently connected. Note that if
there is any possibility that there are any routers not there is any possibility that there are any routers not
implementing MT-OLSRv2, then the MANET will be connected, to the implementing MT-OLSRv2, then the MANET will be connected, to the
maximum extent possible, using the link metric type maximum extent possible, using the link metric type
LINK_METRIC_TYPE. LINK_METRIC_TYPE.
o Deciding which link metric, and hence which Routing Set to use, o Deciding which link metric, and hence which Routing Set to use,
for received packets, hence how to use the Routing Sets to for received packets, hence how to use the Routing Sets to
configure the network layer (IP). An obvious approach is to map configure the network layer (IP). All routers must make the same
each DiffServ Code Point (DSCP) [RFC2474] to a single link metric. decision for the same packet. 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.) (This may be a many to one mapping.)
o Note that there could be cases where a router that is not o Note that there could be cases where a router that is not
implementing MT-OLSRv2 is the source or destination of an IP 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 packet that is mapped to a link metric that is not the link metric
LINK_METRIC_TYPE used by that router. LINK_METRIC_TYPE used by that router.
o If such a router is the source, then routing may work if the first * If such a router is the source, then routing may work if the
router implementing MT-OLSRv2 to receive the packet supports the first router implementing MT-OLSRv2 to receive the packet
appropriate link metric type. At worst the packet will be supports the appropriate link metric type. At worst the packet
dropped, it will not loop. will be dropped, it will not loop.
o If such a router is the destination, then the packet will never * If such a router is the destination, then the packet will never
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
be required to ensure that the MANET still functions in these may be required to ensure that the MANET still functions in
cases. these 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. Finally, this specification makes existing Address Block TLV. Finally, this specification makes
additional allocations from the LINK_METRIC Address Block TLV Type additional allocations from the LINK_METRIC Address Block TLV Type
registry. registry.
skipping to change at page 18, line 33 skipping to change at page 19, line 33
Furthermore, this extension does not introduce any additional Furthermore, this extension does not introduce any additional
vulnerabilities over those of [RFC7181], because each link metric vulnerabilities over those of [RFC7181], because each link metric
type is used independently, and each one could have been the single type is used independently, and each one could have been the single
link metric type supported by an implementation of [RFC7181] link metric type supported by an implementation of [RFC7181]
receiving the same information, as received information of an receiving the same information, as received information of an
unsupported type is ignored by all routers. unsupported type is ignored by all routers.
15. Acknowledgments 15. Acknowledgments
TBD. The authors would like to thank (in alphabetical order): Juliusz
Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems)
and Henning Rogge (FGAN) for discussions and suggestions.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, 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,
 End of changes. 36 change blocks. 
98 lines changed or deleted 117 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/