draft-ietf-manet-olsrv2-multitopology-04.txt   draft-ietf-manet-olsrv2-multitopology-05.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 Updates: 7181, 7188, XXXX T. Clausen
Expires: January 22, 2015 LIX, Ecole Polytechnique (if approved) LIX, Ecole Polytechnique
July 21, 2014 Intended status: Experimental February 20, 2015
Expires: August 24, 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-04 draft-ietf-manet-olsrv2-multitopology-05
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 7181 by creating an interoperable
extension to it. This specification updates RFC 7188 and RFC XXXX by
modifying and 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 22, 2015. This Internet-Draft will expire on August 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Experimentation . . . . . . . . . . . . . . 3 1.1. Motivation and Experimentation . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 7 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 7 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 8
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 8 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 9
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 8 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 9
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 8 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 9
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 9 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 10
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 9 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 10
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 9 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 10
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 10 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 11
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 10 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 11
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 11 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 11 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 12
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 12 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 12 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 13
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 12 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 13
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 13 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 14
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 13 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 14
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 14 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 15
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 14 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 15
12. Management Considerations . . . . . . . . . . . . . . . . . . 14 12. Management Considerations . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 16 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 17
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 16 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 17 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 6, line 40 skipping to change at page 7, line 40
parameter array ROUTER_METRIC_TYPES. Each element in these arrays is parameter array ROUTER_METRIC_TYPES. Each element in these arrays is
a link metric type (i.e., a type extension used by the LINK_METRIC a link metric type (i.e., a type extension used by the LINK_METRIC
TLV [RFC7181]). TLV [RFC7181]).
The interface parameter array IFACE_METRIC_TYPES contains the link The interface parameter array IFACE_METRIC_TYPES contains the link
metric types supported on that OLSRv2 interface. The router metric types supported on that OLSRv2 interface. The router
parameter array ROUTER_METRIC_TYPES is the union of all of the parameter array ROUTER_METRIC_TYPES is the union of all of the
IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.
If in a given deployment there may be any routers that do not If in a given deployment there may be any routers that do not
implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST first 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 first 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 [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
skipping to change at page 9, line 32 skipping to change at page 10, line 32
The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2
interfaces and TC messages. A message MUST NOT contain more than one interfaces and TC messages. A message MUST NOT contain more than one
MPR_TYPES TLV. MPR_TYPES TLV.
The presence of this TLV in a message is used to indicate that the The presence of this TLV in a message is used to indicate that the
router supports MT-OLSRv2, in the same way that the presence of the router supports MT-OLSRv2, in the same way that the presence of the
MPR_WILLING TLV is used to indicate that the router supports OLSRv2, MPR_WILLING TLV is used to indicate that the router supports OLSRv2,
as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has
been defined with the same Type as the MPR_WILLING TLV, but with Type been defined with the same Type as the MPR_WILLING TLV, but with Type
Extension == 1. (The different symbolic name is used for Extension = 1.
convenience, any reference to a MPR_TYPES TLV means to this TLV, with
this Type and Type Extension.)
This TLV may take a Value field of any size. Each octet in its Value This TLV may take a Value field of any size. Each octet in its Value
field will contain a link metric type that is supported, either on field will contain a link metric type that is supported, either on
any OLSRv2 interface, when included in a TC message, or on the OLSRv2 any OLSRv2 interface, when included in a TC message, or on the OLSRv2
interface on which an including HELLO message is sent. These octets interface on which an including HELLO message is sent. These octets
MAY be in any order, except that if there may be any routers in the MAY be in any order, except that if there may be any routers in the
MANET not implementing MT-OLSRv2, then the first octet MUST be MANET not implementing MT-OLSRv2, then the first octet MUST be
LINK_METRIC_TYPE. LINK_METRIC_TYPE.
7.1.2. MPR_WILLING TLV 7.1.2. MPR_WILLING TLV
skipping to change at page 10, line 17 skipping to change at page 11, line 15
be a routing TLV. Those latter bits are, when using this be a routing TLV. Those latter bits are, when using this
specification, interpreted as its willingness to be a routing TLV specification, interpreted as its willingness to be a routing TLV
using the link metric type LINK_METRIC_TYPE. using the link metric type LINK_METRIC_TYPE.
The extended use of this message TLV, as defined by this The extended use of this message TLV, as defined by this
specification, defines additional 4 bit sub-fields of the Value specification, defines additional 4 bit sub-fields of the Value
field, starting with bits 4-7 of the first octet and continuing with field, starting with bits 4-7 of the first octet and continuing with
bits 0-3 of the second octet, to represent willingness to be a bits 0-3 of the second octet, to represent willingness to be a
routing MPR using the link metric types specified in this OLSRv2 routing MPR using the link metric types specified in this OLSRv2
interface's IFACE_METRIC_TYPES parameter, ordered as reported in the interface's IFACE_METRIC_TYPES parameter, ordered as reported in the
included MPR_TYPES Message TLV. (If there is no such TLV included, included MPR_TYPES Message TLV. Note that this means that the
then the router does not support MT-OLSRv2, and only the first octet willingness to be a routing MPR for the topology indicated by
of the Value field will be used.) the link metric type LINK_METRIC_TYPE will continue to occupy bits
4-7 of the first octet. (If there is no such TLV included, then the
router does not support MT-OLSRv2, and only the first octet of the
Value field will be used.)
If the number of link metric types in this OLSRv2 interface's 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 [RFC7188], missing Value octets, i.e., length, then, as specified in [RFC7188], missing Value octets, i.e.,
missing willingness values, are considered as zero, i.e., as missing willingness values, are considered as zero, i.e., as
skipping to change at page 11, line 29 skipping to change at page 12, line 29
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, and used link metric types (including the first) being indicated in, and used
in the same order as, the Value field of an MPR_TYPES Message TLV. in the same order as, the Value field of an MPR_TYPES Message TLV,
excluding the link metric type LINK_METRIC_TYPE, which already
occupies the second bit.
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 16, line 5 skipping to change at page 16, line 49
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]. consideration as are specified by [RFC5444] and [tlv-naming].
13.2. Message TLV Types 13.2. Message TLV Types
This specification replaces Table 11 of [RFC7181]. That specified a This specification modifies the Message TLV Type 7, replacing Table 4
Message MPR Type described as MPR_WILLING, for which only Type of [tlv-naming] by Table 2, changing the description of the Type
Extension 0 was defined. This specification reserves that name Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each
MPR_WILLING for Type Extension 0, defines a new Type Extension 1, of these TLVs MUST NOT be included more than once in a Message TLV
with a new name MPR_TYPES, and leaves the remaining Type Extensions Block.
of this TLV Type unnamed. It also changes the Value field
specification of the MPR_WILLING TLV.
Specifications of these TLVs are in Table 2. Each of these TLVs MUST
NOT be included more than once in a Message TLV Block.
+-------------+------+-----------+---------------------+------------+ +-----------+-------------+-------------------------+---------------+
| Name | Type | Type | Description | Allocation | | Type | Name | Description | Reference |
| | | Extension | | Policy | | Extension | | | |
+-------------+------+-----------+---------------------+------------+ +-----------+-------------+-------------------------+---------------+
| MPR_WILLING | 7 | 0 | Bits 0-3 specify | | | 0 | MPR_WILLING | First (most | [RFC7181] |
| | | | the originating | | | | | significant) half octet | [tlv-naming] |
| | | | router's | | | | | of Value field | This |
| | | | willingness to act | | | | | specifies the | specification |
| | | | as a flooding MPR. | | | | | originating router's | |
| | | | Each following 4 | | | | | willingness to act as a | |
| | | | bit subfield (using | | | | | flooding MPR; | |
| | | | bits 0-3 of an | | | | | subsequent half octets | |
| | | | octet before bits | | | | | specify the originating | |
| | | | 4-7) specifies the | | | | | router's willingness to | |
| | | | originating | | | | | act as a routing MPR, | |
| | | | router's | | | | | either for the link | |
| | | | willingness to act | | | | | metric types reported | |
| | | | as a routing MPR | | | | | in an MPR_TYPES TLV (in | |
| | | | for a link metric, | | | | | the same order), or (if | |
| | | | either a single | | | | | no MPR_TYPES TLV is | |
| | | | such field (bits | | | | | present) for the single | |
| | | | 4-7) when no | | | | | administratively agreed | |
| | | | MPR_TYPES Message | | | | | link metric type | |
| | | | TLV is present, or | | | 1 | MPR_TYPES | The link metric types | This |
| | | | one subfield per | | | | | supported on this | specification |
| | | | type reported in an | | | | | OLSRv2 interface of | |
| | | | MPR_TYPES Message | | | | | this router (one octet | |
| | | | TLV Value field (in | | | | | each). | |
| | | | the same order). | | | 2-223 | | Unassigned | |
| MPR_TYPES | 7 | 1 | The link metric | | | 224-255 | | Reserved for | [RFC7181] |
| | | | types supported on | | | | | Experimental Use | |
| | | | this OLSRv2 | | +-----------+-------------+-------------------------+---------------+
| | | | interface of this | |
| | | | router (one octet | |
| | | | each). | |
| Unnamed | 7 | 2-255 | Unassigned. | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 2: Message TLV Type assignment: MPR_WILLING and MPR_TYPES Table 2: Type 7 Message TLV Type Extensions
13.3. Address Block TLV Types 13.3. Address Block TLV Types
Table 16 of [RFC7181] is replaced by Table 3. Note that the only Table 7 of [RFC7188] is replaced by Table 3.
change is to the description of the Value field.
+---------+------+-----------+-------------------------+------------+ +-------+-------+----------+----------------------------------------+
| Name | Type | Type | Description | Allocation | | Bit | Value | Name | Description |
| | | extension | | Policy | +-------+-------+----------+----------------------------------------+
+---------+------+-----------+-------------------------+------------+ | First | First | Flooding | If set then the neighbor with that |
| GATEWAY | 10 | 0 | Specifies that a given | | | octet | octet | | network address has been selected as |
| | | | network address is | | | bit 7 | 0x01 | | flooding MPR |
| | | | reached via a gateway | | | From | From | Routing | If set then the neighbor with that |
| | | | on the originating | | | first | first | | network address has been selected as |
| | | | router. The number of | | | octet | octet | | routing MPR, either for the link |
| | | | hops is indicated by | | | bit 6 | 0x02 | | metric types reported in an MPR_TYPES |
| | | | the Value field, either | | | | | | TLV (in the same order), or (if no |
| | | | using a single octet | | | | | | MPR_TYPES TLV is present) then (first |
| | | | (if no MPR_TYPES | | | | | | octet bit 6, value 0x02) for the |
| | | | Message TLV is present) | | | | | | single administratively agreed link |
| | | | or one octet per type | | | | | | metric type |
| | | | reported in an | | +-------+-------+----------+----------------------------------------+
| | | | MPR_TYPES Message TLV | |
| | | | (in the same order). | |
| GATEWAY | 10 | 1-255 | | Expert |
| | | | | Review |
+---------+------+-----------+-------------------------+------------+
Table 3: Address Block TLV Type assignment: GATEWAY Table 3: MPR TLV Bit Values
Table 13 of [RFC7181] is replaced by Table 4. Note that the only Table 14 of [tlv-naming] is replaced by Table 4. The only changes
change is to allocate 8 Type Extensions as assigned by administrative are to the Description and the References for the GATEWAY TLV.
action, in order to support administratively determined multi-
topologies. +-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References |
| Extension | | | |
+-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | This |
| | | via a gateway on the | specification |
| | | originating router. The | |
| | | number of hops is indicated | |
| | | by the Value field, one | |
| | | octet per link metric type | |
| | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | |
| | | using a single octet | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [tlv-naming] |
| | | Use | |
+-----------+---------+-----------------------------+---------------+
Table 4: Type 10 Address Block TLV Type Extensions
Table 13 of [RFC7181] is replaced by Table 5. 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 | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+ +-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | 7 | 0-7 | Link metric | | | LINK_METRIC | 7 | 0-7 | Link metric | |
| | | | meaning assigned | | | | | | meaning assigned | |
| | | | by administrative | | | | | | by administrative | |
| | | | action. | | | | | | action. | |
| LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert |
| | | | | Review | | | | | | Review |
| LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental | | LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental |
| | | | | Use | | | | | | Use |
+-------------+------+-----------+-------------------+--------------+ +-------------+------+-----------+-------------------+--------------+
Table 4: Address Block TLV Type assignment: LINK_METRIC Table 5: Address Block TLV Type assignment: LINK_METRIC
14. Security Considerations 14. Security Considerations
This extension to OLSRv2 allows a router to support more than one This extension to OLSRv2 allows a router to support more than one
link metric type for each link advertised in HELLO and TC messages, link metric type for each link advertised in HELLO and TC messages,
and for routers to support different sets of types. Link metric and for routers to support different sets of types. Link metric
values of additional types are reported by the inclusion of values of additional types are reported by the inclusion of
additional TLVs in the messages sent by a router, which will report additional TLVs in the messages sent by a router, which will report
known values of all supported types. known values of all supported types.
skipping to change at page 20, line 14 skipping to change at page 20, line 35
[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]
Dearlove, C. and T. Clausen, "TLV Naming in the MANET
Generalized Packet/Message Format", Work In
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
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
 End of changes. 24 change blocks. 
134 lines changed or deleted 158 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/