draft-ietf-manet-olsrv2-multitopology-06.txt   draft-ietf-manet-olsrv2-multitopology-07.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC Internet-Draft BAE Systems Applied Intelligence
Updates: 7188, [tlv-naming] T. Clausen Updates: 7188, 7631 Laboratories
(if approved) LIX, Ecole Polytechnique (if approved) T. Clausen
Intended status: Experimental July 6, 2015 Intended status: Experimental LIX, Ecole Polytechnique
Expires: January 7, 2016 Expires: March 31, 2016 September 28, 2015
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-06 draft-ietf-manet-olsrv2-multitopology-07
Abstract Abstract
This specification describes an extension to the Optimized Link State This specification describes an extension to the Optimized Link State
Routing Protocol version 2 (OLSRv2) to support multiple routing Routing Protocol version 2 (OLSRv2) to support multiple routing
topologies, while retaining interoperability with OLSRv2 routers that topologies, while retaining interoperability with OLSRv2 routers that
do not implement this extension. do not implement this extension.
This specification updates RFC 7188 and [tlv-naming] by modifying and This specification updates RFCs 7188 and 7631 by modifying and
extending TLV registries and descriptions. extending TLV registries and descriptions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 7, 2016. This Internet-Draft will expire on March 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Experimentation . . . . . . . . . . . . . . 4 1.1. Motivation and Experimentation . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 8 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 9
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 9
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 9 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 10
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 9 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 10
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 10 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 10
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 10 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 11
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 10 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 11
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 11 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 11
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 12 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 12
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 12 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 12
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 13 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 13
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 13 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 14
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 14 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 14
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 15 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 15
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 15 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 16
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 15 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 16
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 16 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 16
12. Management Considerations . . . . . . . . . . . . . . . . . . 16 12. Management Considerations . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 17 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 18 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . . 21 16.1. Normative References . . . . . . . . . . . . . . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . . 21 16.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol, version 2 [RFC7181] The Optimized Link State Routing Protocol, version 2 [RFC7181]
(OLSRv2) is a proactive link state routing protocol designed for use (OLSRv2) is a proactive link state routing protocol designed for use
in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant
improvements of OLSRv2 over its Experimental precursor [RFC3626] is improvements of OLSRv2 over its Experimental precursor [RFC3626] is
the ability of OLSRv2 to route over other than minimum hop routes, the ability of OLSRv2 to route over other than minimum hop routes,
using a link metric. using a link metric.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
Multi-topology routing is a natural extension to a link state routing Multi-topology routing is a natural extension to a link state routing
protocol, as for example to OSPF (see [RFC4915]). However multi- protocol, as for example to OSPF (see [RFC4915]). However multi-
topology routing for OLSRv2 does not yet benefit from extensive topology routing for OLSRv2 does not yet benefit from extensive
operational, or even experimental, experience. This specification is operational, or even experimental, experience. This specification is
published to facilitate collecting such experience, with the intent published to facilitate collecting such experience, with the intent
that once suitable experimental evidence has been collected, an that once suitable experimental evidence has been collected, an
OLSRv2 Multi-Topology Routing Extension will be proposed for OLSRv2 Multi-Topology Routing Extension will be proposed for
advancement onto Standards Track. advancement onto Standards Track.
While general experiences with this protocol extension, including Any experiments using this protocol extension are encouraged.
interoperability of implementations, are encouraged, specific Reports from such experiments planned with pre-specified objectives
information would be particularly appreciated on the following areas: and scenarios (including link, position and mobility information) are
particularly encouraged. Results from such experiments, documenting
the following, are of particular importance:
o Operation in a network that contains both routers implementing o Operation in networks that contain both routers implementing this
this extension, and routers implementing only [RFC7181], in extension, and routers implementing only [RFC7181], in particular
particular are there any unexpected interactions that can break are there any unexpected interactions that can break the network?
the network?
o Operation in networks with dynamic topologies, both due to
mobility and due to link metric changes for reasons other than
mobility.
o Operation in realistic deployments, and details thereof, including o Operation in realistic deployments, and details thereof, including
in particular indicating how many concurrent topologies were in particular indicating how many concurrent topologies were
required. required.
A broader issue that applies to unextended [RFC7181] as well as this o Behavior of routing sets, including measures of successful route
extension (and potentially to other MANET routing protocols) is which establishment.
link metric types are useful in a MANET, and how to establish the
metrics to associate with a given link. While this issue is not only In addition, reports from experiments covering the following are also
related to this extension, the ability for an OLSRv2 network to of value:
maintain different concurrent link metrics may facilitate both
experiments with different link metric types, ways to measure them, o Which link metric types were useful, and how the metrics to
etc. and may also allow experimentation with link metric types that associate with a given link were established.
are not compromises to handle multiple traffic types.
o How packet types were associated with link metric types (whether
using DiffServ on an alternative mechanism).
o Any data link layer issues, and any cross-layer issues, including
whether NHDP link quality was used, and how.
o Transport and higher layer issues observed, if any.
o Resource requirements observed from running the protocol,
including processing, storage, and bandwidth.
o Network performance, including packet delivery results.
o Any other implementation issues.
The first bullet in the latter list applies to unextended [RFC7181]
as well as this extension, and potentially to other MANET routing
protocols. This may also allow experimentation with link metric
types that are not compromises to handle multiple traffic types.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This specification uses the terminology of [RFC5444], [RFC6130] and This specification uses the terminology of [RFC5444], [RFC6130] and
[RFC7181], which is to be interpreted as described in those [RFC7181], which is to be interpreted as described in those
skipping to change at page 6, line 21 skipping to change at page 6, line 43
outside the scope of this specification, that the network layer is outside the scope of this specification, that the network layer is
able to choose which topology to use for each packet, for example able to choose which topology to use for each packet, for example
using the DiffServ Code Point (DSCP) defined in [RFC2474]. This using the DiffServ Code Point (DSCP) defined in [RFC2474]. This
selection of topology MUST be consistent, that is each router selection of topology MUST be consistent, that is each router
receiving a packet must make the same choice of link metric type, in receiving a packet must make the same choice of link metric type, in
order that each packet uses a single topology. This is necessary to order that each packet uses a single topology. This is necessary to
avoid the possibility of a packet "looping" in the network. avoid the possibility of a packet "looping" in the network.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The purpose of this specification is to extend [RFC7181] so as to The purpose of this specification is to extend OLSRv2 [RFC7181] so as
enable a router to establish and maintain multiple routing topologies to enable a router to establish and maintain multiple routing
in a MANET, each topology associated with a link metric type. topologies in a MANET, each topology associated with a link metric
Routers in the MANET may each form part of some or all of these type. Routers in the MANET may each form part of some or all of
topologies, and each router will maintain a Routing Set for each these topologies, and each router will maintain a Routing Set for
topology that it forms part of, allowing separate routing of packets each topology that it forms part of, allowing separate routing of
for each topology. packets for each topology.
MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be
created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 created containing both routers that implement MT-OLSRv2 (MT-OLSRv2
routers) and routers that do not implement MT-OLSRv2, and may be routers) and routers that do not implement MT-OLSRv2, and may be
unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be
created that are known to contain only MT-OLSRv2 routers. In both created that are known to contain only MT-OLSRv2 routers. In both
cases, but especially the former, management may be required to cases, but especially the former, management may be required to
ensure that the MANET will function as required, and does not, for ensure that the MANET will function as required, and does not, for
example, unnecessarily fragment. (Such issues already arise in an example, unnecessarily fragment. (Such issues already arise in an
OLSRv2-based MANET using multiple interfaces.) OLSRv2-based MANET using multiple interfaces.)
OLSRv2 is an extension of NHDP [RFC6130]. However the extension in
this specification does not modify NHDP, it only modifies Protocol
Sets that are specific to OLSRv2, or elements in Protocol Tuples that
were added by OLSRv2 and which are not included in nor used by NHDP.
In addition it does not use or modify the link quality mechanism in
[RFC6130].
Each router implementing this specification selects a set of link Each router implementing this specification selects a set of link
metric types for each of its OLSRv2 interfaces. If all routers in metric types for each of its OLSRv2 interfaces. If all routers in
the MANET implement MT-OLSRv2, then there are no restrictions within the MANET implement MT-OLSRv2, then there are no restrictions within
this specification on how these sets of link metrics are selected. this specification on how these sets of link metrics are selected.
(However the issues described in the preceding paragraph still (However the issues described in the preceding paragraph still
apply.) However in MANETs containing non-MT-OLSRv2 routers, the apply.) However in MANETs containing non-MT-OLSRv2 routers, the
single link metric used by these non-MT-OLSRv2 routers must be single link metric used by these non-MT-OLSRv2 routers must be
included in the set of link metrics for each OLSRv2 interface of an included in the set of link metrics for each OLSRv2 interface of an
MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non- MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-
MT-OLSRv2 router in the MANET. MT-OLSRv2 router in the MANET.
skipping to change at page 7, line 29 skipping to change at page 8, line 11
A network using MT-OLSRv2 will usually require greater management A network using MT-OLSRv2 will usually require greater management
than one using unmodified OLSRv2. In particular, the use of multiple than one using unmodified OLSRv2. In particular, the use of multiple
metric types across the MANET must be managed, by administrative metric types across the MANET must be managed, by administrative
configuration or otherwise. As also for other decisions that may be configuration or otherwise. As also for other decisions that may be
made when using OLSRv2, a bad collective choice of metric type use made when using OLSRv2, a bad collective choice of metric type use
will make the MANET anywhere from inefficient to non-functional, so will make the MANET anywhere from inefficient to non-functional, so
care will be needed in selecting supported link metric types across care will be needed in selecting supported link metric types across
the MANET. the MANET.
The meanings of link metric types are at the discretion of the MANET The meanings of link metric types are at the discretion of the MANET
operator, they could be be used, for example, to represent packets of operator, they could be used, for example, to represent packets of
different types, packets in streams of different rates, or packets different types, packets in streams of different rates, or packets
with different trust requirements. Note that packets will generally with different trust requirements. Note that packets will generally
not be delivered to routers that do not support that link metric not be delivered to routers that do not support that link metric
type, and the MANET, and the packets sent in it, will need to be type, and the MANET, and the packets sent in it, will need to be
managed accordingly (especially if containing any non-MT-OLSRv2 managed accordingly (especially if containing any non-MT-OLSRv2
routers). routers).
5. Parameters 5. Parameters
The parameters used in [RFC7181], including from its normative The parameters used in [RFC7181], including from its normative
skipping to change at page 14, line 25 skipping to change at page 15, line 5
type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs,
the indicated addresses MUST be of the MPRs in an MPR set as the indicated addresses MUST be of the MPRs in an MPR set as
specified for a single link metric type in [RFC7181]. specified for a single link metric type in [RFC7181].
8.2. HELLO Message Processing 8.2. HELLO Message Processing
On receipt of a HELLO message on an OLSRv2 interface, a router On receipt of a HELLO message on an OLSRv2 interface, a router
implementing MT-OLSRv2 MUST, in addition to the processing described implementing MT-OLSRv2 MUST, in addition to the processing described
in [RFC7181]: in [RFC7181]:
1. Determine the list of link metric types supported by the sending 1. If in this deployment there may be any routers that do not
implement MT-OLSRv2, the HELLO message contains an MPR_TYPES
Message TLV, and the first link metric type that it reports is
not LINK_METRIC_TYPE, then the HELLO message MUST be silently
discarded.
2. Determine the list of link metric types supported by the sending
router on its corresponding OLSRv2 interface, either from an router on its corresponding OLSRv2 interface, either from an
MPR_TYPES Message TLV or, if not present, the single link metric MPR_TYPES Message TLV or, if not present, the single link metric
type LINK_METRIC_TYPE. type LINK_METRIC_TYPE.
2. For those link metric types supported by both routers, set the 3. 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 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 only 4. For any other metric types supported by the receiving router only
(i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set
the elements listed in the previous point to their default the elements listed in the previous point to their default
values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or
false. false.
9. TC Messages 9. TC Messages
The following changes are made to the generation and processing of TC The following changes are made to the generation and processing of TC
messages compared to that described in [RFC7181] by routers that messages compared to that described in [RFC7181] by routers that
implement MT-OLSRv2. implement MT-OLSRv2.
skipping to change at page 15, line 28 skipping to change at page 16, line 10
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, in the same order as reported in the each GATEWAY TLV included, in the same order as reported in the
MPR_TYPES TLV. MPR_TYPES TLV.
9.2. TC Message Processing 9.2. TC Message Processing
On receipt of a TC message, a router implementing this extension On receipt of a TC message, a router implementing this extension
MUST, in addition to the processing specified in [RFC7181]: MUST, in addition to the processing specified in [RFC7181]:
o If in this deployment there may be any routers that do not
implement MT-OLSRv2, the TC message contains an MPR_TYPES Message
TLV, and the first link metric type that it reports is not
LINK_METRIC_TYPE, then the TC message MUST be silently discarded.
o 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].
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.)
skipping to change at page 17, line 30 skipping to change at page 18, line 17
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.
This specification assumes that the TLV renaming specified in
[tlv-naming] has been carried out.
13.1. Expert Review: Evaluation Guidelines 13.1. Expert Review: Evaluation Guidelines
For the registry where an Expert Review is required, the designated For the registry where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444] and [tlv-naming]. consideration as are specified by [RFC5444] and [RFC7631].
13.2. Message TLV Types 13.2. Message TLV Types
This specification modifies the Message TLV Type 7, replacing Table 4 This specification modifies the Message TLV Type 7, replacing Table 4
of [tlv-naming] by Table 2, changing the description of the Type of [RFC7631] by Table 2, changing the description of the Type
Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each
of these TLVs MUST NOT be included more than once in a Message TLV of these TLVs MUST NOT be included more than once in a Message TLV
Block. Block.
+-----------+-------------+-------------------------+---------------+ +-----------+-------------+-------------------------+---------------+
| Type | Name | Description | Reference | | Type | Name | Description | Reference |
| Extension | | | | | Extension | | | |
+-----------+-------------+-------------------------+---------------+ +-----------+-------------+-------------------------+---------------+
| 0 | MPR_WILLING | First (most | [RFC7181] | | 0 | MPR_WILLING | First (most | [RFC7181] |
| | | significant) half octet | [tlv-naming] | | | | significant) half octet | [RFC7631] |
| | | of Value field | This | | | | of Value field | This |
| | | specifies the | specification | | | | specifies the | specification |
| | | originating router's | | | | | originating router's | |
| | | willingness to act as a | | | | | willingness to act as a | |
| | | flooding MPR; | | | | | flooding MPR; | |
| | | subsequent half octets | | | | | subsequent half octets | |
| | | specify the originating | | | | | specify the originating | |
| | | router's willingness to | | | | | router's willingness to | |
| | | act as a routing MPR, | | | | | act as a routing MPR, | |
| | | either for the link | | | | | either for the link | |
skipping to change at page 19, line 24 skipping to change at page 20, line 24
| bit 6 | 0x02 | | metric types reported in an MPR_TYPES | | bit 6 | 0x02 | | metric types reported in an MPR_TYPES |
| | | | TLV (in the same order), or (if no | | | | | TLV (in the same order), or (if no |
| | | | MPR_TYPES TLV is present) then (first | | | | | MPR_TYPES TLV is present) then (first |
| | | | octet bit 6, value 0x02) for the | | | | | octet bit 6, value 0x02) for the |
| | | | single administratively agreed link | | | | | single administratively agreed link |
| | | | metric type | | | | | metric type |
+-------+-------+----------+----------------------------------------+ +-------+-------+----------+----------------------------------------+
Table 3: MPR TLV Bit Values Table 3: MPR TLV Bit Values
Table 14 of [tlv-naming] is replaced by Table 4. The only changes Table 14 of [RFC7631] is replaced by Table 4. The only changes are
are to the Description and the References for the GATEWAY TLV. to the Description and the References for the GATEWAY TLV.
+-----------+---------+-----------------------------+---------------+ +-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References | | Type | Name | Description | References |
| Extension | | | | | Extension | | | |
+-----------+---------+-----------------------------+---------------+ +-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] | | 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | This | | | | network address is reached | This |
| | | via a gateway on the | specification | | | | via a gateway on the | specification |
| | | originating router. The | | | | | originating router. The | |
| | | number of hops is indicated | | | | | number of hops is indicated | |
| | | by the Value field, one | | | | | by the Value field, one | |
| | | octet per link metric type | | | | | octet per link metric type | |
| | | reported in an MPR_TYPES | | | | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | | | | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | | | | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | | | | | Message TLV is present) | |
| | | using a single octet | | | | | using a single octet | |
| 1-223 | | Unassigned | | | 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [tlv-naming] | | 224-255 | | Reserved for Experimental | [RFC7631] |
| | | Use | | | | | Use | |
+-----------+---------+-----------------------------+---------------+ +-----------+---------+-----------------------------+---------------+
Table 4: Type 10 Address Block TLV Type Extensions Table 4: Type 10 Address Block TLV Type Extensions
Table 13 of [RFC7181] is replaced by Table 5. The only change is to Table 13 of [RFC7181] is replaced by Table 5. The only change is to
allocate 8 Type Extensions as assigned by administrative action, in allocate 8 Type Extensions as assigned by administrative action, in
order to support administratively determined multi-topologies. order to support administratively determined multi-topologies.
+-------------+------+-----------+-------------------+--------------+ +-------------+------+-----------+-------------------+--------------+
skipping to change at page 20, line 50 skipping to change at page 21, line 50
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
The authors would like to thank (in alphabetical order): Juliusz The authors would like to thank (in alphabetical order): Juliusz
Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems) Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems),
and Henning Rogge (FGAN) for discussions and suggestions. Susan Hares (Huawei) 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,
skipping to change at page 21, line 30 skipping to change at page 22, line 31
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
RFC 7181, April 2014. RFC 7181, April 2014.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol version 2 (OLSRv2) and MANET Neighborhood Protocol version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7188, Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
April 2014. April 2014.
[tlv-naming] [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET
Dearlove, C. and T. Clausen, "TLV Naming in the MANET Generalized Packet/Message Format", RFC 7631,
Generalized Packet/Message Format", Work In January 2015.
Progress draft-ietf-manet-tlv-naming-00.txt, January 2015.
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
skipping to change at page 22, line 9 skipping to change at page 23, line 9
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007. RFC 4915, June 2007.
Authors' Addresses Authors' Addresses
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Applied Intelligence Laboratories
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
 End of changes. 31 change blocks. 
78 lines changed or deleted 117 lines changed or added

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