draft-ietf-manet-olsrv2-multitopology-05.txt   draft-ietf-manet-olsrv2-multitopology-06.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
Updates: 7181, 7188, XXXX T. Clausen Updates: 7188, [tlv-naming] T. Clausen
(if approved) LIX, Ecole Polytechnique (if approved) LIX, Ecole Polytechnique
Intended status: Experimental February 20, 2015 Intended status: Experimental July 6, 2015
Expires: August 24, 2015 Expires: January 7, 2016
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-05 draft-ietf-manet-olsrv2-multitopology-06
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 This specification updates RFC 7188 and [tlv-naming] by modifying and
extension to it. This specification updates RFC 7188 and RFC XXXX by extending TLV registries and descriptions.
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 August 24, 2015. This Internet-Draft will expire on January 7, 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 16 skipping to change at page 3, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 8 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 8
6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 9
6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 9 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 9
6.6. Routable Address Topology Set . . . . . . . . . . . . . . 9 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 9
6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 9 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 10
6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 10 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 10
7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 10 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 10
7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 10 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 11
7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 11 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 12
7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 11 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 12
7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 12 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 13
8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 13 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 13
8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 13 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 14
9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 14 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 15
9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 14 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 15
10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 15 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 15
11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 15 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 16
12. Management Considerations . . . . . . . . . . . . . . . . . . 15 12. Management Considerations . . . . . . . . . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 17 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 17
13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17
13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 18 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21
16.2. Informative References . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 route packets using more than one link metric type. desirable to be able to route packets using more than one link metric
This specification describes an extension to OLSRv2 that is designed type. This specification describes an extension to OLSRv2 that is
to permit this, while maintaining maximal interoperability with designed to permit this, while maintaining maximal interoperability
OLSRv2 routers not implementing this extension. with OLSRv2 routers not implementing this extension.
The purpose of OLSRv2 can be described as to create and maintain a The purpose of OLSRv2 can be described as to create and maintain a
Routing Set, which contains all the necessary information to populate Routing Set, which contains all the necessary information to populate
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
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 in a reasonable period of time after the acceptance of this that once suitable experimental evidence has been collected, an
specification as an Experimental RFC (as soon as possible after OLSRv2 Multi-Topology Routing Extension will be proposed for
experimental evidence is collected), an OLSRv2 Multi-Topology Routing advancement onto Standards Track.
Extension will be proposed for advancement onto Standards Track.
While general experiences with this protocol extension, including While general experiences with this protocol extension, including
interoperability of implementations, are encouraged, specific interoperability of implementations, are encouraged, specific
information would be particularly appreciated on the following areas: information would be particularly appreciated on the following areas:
o Operation in a network that contains both routers implementing o Operation in a network that contains both routers implementing
this extension, and routers implementing only [RFC7181], in this extension, and routers implementing only [RFC7181], in
particular are there any unexpected interactions that can break particular are there any unexpected interactions that can break
the network? the network?
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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]. 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 [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.
MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be
created containing both routers that implement MT-OLSRv2 (MT-OLSRv2
routers) and routers that do not implement MT-OLSRv2, and may 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
cases, but especially the former, management may be required to
ensure that the MANET will function as required, and does not, for
example, unnecessarily fragment. (Such issues already arise in an
OLSRv2-based MANET using multiple interfaces.)
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 within
these sets of link metrics are selected. However there may be this specification on how these sets of link metrics are selected.
deployments where routers that do not implement MT-OLSRv2 (non-MT- (However the issues described in the preceding paragraph still
OLSRv2 routers) are to participate in a MANET with MT-OLSRv2 routers. apply.) However in MANETs containing non-MT-OLSRv2 routers, the
In this case, the single link metric used by these non-MT-OLSRv2 single link metric used by these non-MT-OLSRv2 routers must be
routers must be included in the set of link metrics for each OLSRv2 included in the set of link metrics for each OLSRv2 interface of an
interface of an MT-OLSRv2 router that may be heard on an OLSRv2 MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-
interface of a non-MT-OLSRv2 router in the MANET. 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. Both messages sent on OLSRv2 interfaces, and in all TC messages. Both
HELLO and TC messages generated by an MT-OLSRv2 router (other than 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) 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- 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 router and which metric types it supports (on the sending
OLSRv2 interface for a HELLO message). OLSRv2 interface for a HELLO message).
skipping to change at page 7, line 18 skipping to change at page 7, line 28
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
operator, they could be be used, for example, to represent packets of
different types, packets in streams of different rates, or packets
with different trust requirements. Note that packets will generally
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
managed accordingly (especially if containing any non-MT-OLSRv2
routers).
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
that do not implement MT-OLSRv2, and used with that definition in that do not implement MT-OLSRv2, and used with that definition in
skipping to change at page 11, line 15 skipping to change at page 11, line 33
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. Note that this means that the included MPR_TYPES Message TLV. Note that this means that the link
willingness to be a routing MPR for the topology indicated by metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the
the link metric type LINK_METRIC_TYPE will continue to occupy bits first octet. (If there is no such TLV included, then the router does
4-7 of the first octet. (If there is no such TLV included, then the not support MT-OLSRv2, and only the first octet of the Value field
router does not support MT-OLSRv2, and only the first octet of the will be used.)
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 15, line 48 skipping to change at page 16, line 23
A Routing Set is calculated for each link metric type in A Routing Set is calculated for each link metric type in
ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except
that where an element is now represented by a map, the value from the that where an element is now represented by a map, the value from the
map for the selected link metric type is used. Where this is a link map for the selected link metric type is used. Where this is a link
metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for
the calculation. the calculation.
12. Management Considerations 12. Management Considerations
MT-OLSRv2 may require greater management than unextended OLSRv2. In MT-OLSRv2 may require greater management than unextended OLSRv2. In
particular MT-OLSRv2 requires the following management particular a MANET using MT-OLSRv2 requires the following management
considerations: considerations:
o Selecting which link metrics to support on each OLSRv2 interface
and implementing that decision. (Different interfaces may have
different physical and data link layer properties, and this may
inform the selection of link metrics to support, and their
values.)
o Ensuring that the MANET is sufficiently connected. Note that if
there is any possibility that there are any routers not
implementing MT-OLSRv2, then the MANET will be connected, to the
maximum extent possible, using the link metric type
LINK_METRIC_TYPE.
o Deciding which link metric, and hence which Routing Set to use, 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). All routers must make the same configure the network layer (IP). All routers MUST make the same
decision for the same packet. An obvious approach is to map each decision for the same packet. An obvious approach is to map each
DiffServ Code Point (DSCP) [RFC2474] to a single link metric. 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 Selecting which link metrics to support on each OLSRv2 interface
implementing MT-OLSRv2 is the source or destination of an IP and implementing that decision. (Different interfaces may have
packet that is mapped to a link metric that is not the link metric different physical and data link layer properties, and this may
LINK_METRIC_TYPE used by that router. inform the selection of link metrics to support, and their
values.) If the MANET may contain non-MT-OLSRv2 routers, which is
also subject to management, then the rules for link metric
assignment to OLSRv2 interfaces in this specification for that
case MUST be followed.
* If such a router is the source, then routing may work if the o Ensuring that the MANET is sufficiently connected, by ensuring
first router implementing MT-OLSRv2 to receive the packet that, for example, sufficiently many routers implement each metric
supports the appropriate link metric type. At worst the packet type required (this being easier in, for example, a denser
will be dropped, it will not loop. network). Note that if there is any possibility that there are
any routers not implementing MT-OLSRv2, then the MANET will be
connected, to the maximum extent possible, using the link metric
type LINK_METRIC_TYPE, but this will only serve to deliver packets
that use that link metric type.
* If such a router is the destination, then the packet will never o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets
reach its destination, as the source will not have a suitable that will be routed by a topology that they are not part of.
routing table entry for the destination. Network management However if they were to do so then such packets will be routed
may be required to ensure that the MANET still functions in until either they reach their destination, or they reach an MT-
these cases. OLSRv2 router. In the latter case the packet will then either be
dropped (if that MT-OLSRv2 router is not part of that topology, or
is not aware of the destination within that topology) or will be
routed by that topology to the destination. Such a packet will
not loop.
o If a packet is created for a destination that is not part of the
corresponding topology then it may or may not be delivered (if the
originating router is a non-MT-OLSRv2 router) or will not be
transmitted (if the originating router is an MT-OLSRv2 router).
Routers SHOULD be managed so that this does not occur.
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.
 End of changes. 27 change blocks. 
76 lines changed or deleted 98 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/