draft-ietf-manet-olsrv2-multipath-13.txt   draft-ietf-manet-olsrv2-multipath-14.txt 
Network Working Group J. Yi Network Working Group J. Yi
Internet-Draft Ecole Polytechnique Internet-Draft Ecole Polytechnique
Intended status: Experimental B. Parrein Intended status: Experimental B. Parrein
Expires: November 11, 2017 University of Nantes Expires: November 23, 2017 University of Nantes
May 10, 2017 May 22, 2017
Multipath Extension for the Optimized Link State Routing Protocol Multipath Extension for the Optimized Link State Routing Protocol
version 2 (OLSRv2) version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multipath-13 draft-ietf-manet-olsrv2-multipath-14
Abstract Abstract
This document specifies a multipath extension for the Optimized Link This document specifies a multipath extension for the Optimized Link
State Routing Protocol version 2 (OLSRv2) to discover multiple State Routing Protocol version 2 (OLSRv2) to discover multiple
disjoint paths, so as to improve reliability of the OLSRv2 protocol. disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the
The interoperability with OLSRv2 is retained. characteristics of MANETs, especially the dynamic network topology,
using multiple paths can increase aggregated throughput and improve
the reliability by avoiding single route failures. The
interoperability with OLSRv2 is retained.
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 November 11, 2017. This Internet-Draft will expire on November 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Experiments to Be Conducted . . . . . . . . 3 1.1. Motivation and Experiments to Be Conducted . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Parameters and Constants . . . . . . . . . . . . . . . . . . . 8 5. Parameters and Constants . . . . . . . . . . . . . . . . . . . 8
5.1. Router Parameters . . . . . . . . . . . . . . . . . . . . 8 5.1. Router Parameters . . . . . . . . . . . . . . . . . . . . 8
6. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 8 6. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 9
6.1. HELLO and TC messages . . . . . . . . . . . . . . . . . . 9 6.1. HELLO and TC messages . . . . . . . . . . . . . . . . . . 9
6.1.1. SOURCE_ROUTE TLV . . . . . . . . . . . . . . . . . . . 9 6.1.1. SOURCE_ROUTE TLV . . . . . . . . . . . . . . . . . . . 9
6.2. Datagram . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Datagram . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Source Routing Header in IPv4 . . . . . . . . . . . . 9 6.2.1. Source Routing Header in IPv4 . . . . . . . . . . . . 9
6.2.2. Source Routing Header in IPv6 . . . . . . . . . . . . 9 6.2.2. Source Routing Header in IPv6 . . . . . . . . . . . . 10
7. Information Bases . . . . . . . . . . . . . . . . . . . . . . 10 7. Information Bases . . . . . . . . . . . . . . . . . . . . . . 10
7.1. SR-OLSRv2 Router Set . . . . . . . . . . . . . . . . . . . 10 7.1. SR-OLSRv2 Router Set . . . . . . . . . . . . . . . . . . . 10
7.2. Multipath Routing Set . . . . . . . . . . . . . . . . . . 10 7.2. Multipath Routing Set . . . . . . . . . . . . . . . . . . 10
8. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11 8. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. HELLO and TC Message Generation . . . . . . . . . . . . . 11 8.1. HELLO and TC Message Generation . . . . . . . . . . . . . 11
8.2. HELLO and TC Message Processing . . . . . . . . . . . . . 11 8.2. HELLO and TC Message Processing . . . . . . . . . . . . . 12
8.3. MPR Selection . . . . . . . . . . . . . . . . . . . . . . 12 8.3. MPR Selection . . . . . . . . . . . . . . . . . . . . . . 12
8.4. Datagram Processing at the MP-OLSRv2 Originator . . . . . 12 8.4. Datagram Processing at the MP-OLSRv2 Originator . . . . . 12
8.5. Multipath Calculation . . . . . . . . . . . . . . . . . . 14 8.5. Multipath Calculation . . . . . . . . . . . . . . . . . . 14
8.5.1. Requirements of Multipath Calculation . . . . . . . . 14 8.5.1. Requirements of Multipath Calculation . . . . . . . . 14
8.5.2. Multipath Dijkstra Algorithm . . . . . . . . . . . . . 15 8.5.2. Multipath Dijkstra Algorithm . . . . . . . . . . . . . 15
8.6. Multipath Routing Set Updates . . . . . . . . . . . . . . 16 8.6. Multipath Routing Set Updates . . . . . . . . . . . . . . 16
8.7. Datagram Forwarding . . . . . . . . . . . . . . . . . . . 16 8.7. Datagram Forwarding . . . . . . . . . . . . . . . . . . . 17
9. Configuration Parameters . . . . . . . . . . . . . . . . . . . 17 9. Configuration Parameters . . . . . . . . . . . . . . . . . . . 17
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
10.1. Multipath extension based on nOLSRv2 . . . . . . . . . . . 18 10.1. Multipath extension based on nOLSRv2 . . . . . . . . . . . 18
10.2. Multipath extension based on olsrd . . . . . . . . . . . . 18 10.2. Multipath extension based on olsrd . . . . . . . . . . . . 19
10.3. Multipath extension based on umOLSR . . . . . . . . . . . 19 10.3. Multipath extension based on umOLSR . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. Message TLV Types . . . . . . . . . . . . . . . . . . . . 20 12.1. Message TLV Types . . . . . . . . . . . . . . . . . . . . 20
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Multipath Dijkstra Algorithm . . . . . . 23 Appendix A. Examples of Multipath Dijkstra Algorithm . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol version 2 (OLSRv2) The Optimized Link State Routing Protocol version 2 (OLSRv2)
[RFC7181] is a proactive link state protocol designed for use in [RFC7181] is a proactive link state protocol designed for use in
mobile ad hoc networks (MANETs). It generates routing messages mobile ad hoc networks (MANETs). It generates routing messages
periodically to create and maintain a Routing Set, which contains periodically to create and maintain a Routing Set, which contains
routing information to all the possible destinations in the routing routing information to all the possible destinations in the routing
domain. For each destination, there exists a unique Routing Tuple, domain. For each destination, there exists a unique Routing Tuple,
skipping to change at page 3, line 49 skipping to change at page 3, line 49
aggregated throughput. aggregated throughput.
o Some scenarios may require some routers must (or must not) be o Some scenarios may require some routers must (or must not) be
used. used.
o Having control of the paths at the source benefits the load o Having control of the paths at the source benefits the load
balancing and traffic engineering. balancing and traffic engineering.
o An application of this extension is in combination with Forward o An application of this extension is in combination with Forward
Error Correction (FEC) coding applied across packets (erasure Error Correction (FEC) coding applied across packets (erasure
coding) [WPMC11]. Because the packet drop is normally bursty in a coding) [WPMC11]. Because the packet drops are normally bursty in
path (for example, due to route failure), erasure coding is less a path (for example, due to route failure), erasure coding is less
effective in single path routing protocols. By providing multiple effective in single path routing protocols. By providing multiple
disjoint paths, the application of erasure coding with multipath disjoint paths, the application of erasure coding with multipath
protocol is more resilient to routing failures. protocol is more resilient to routing failures.
While in existing deployments, running code and simulations have While in existing deployments, running code and simulations have
proven the interest of multipath extension for OLSRv2 in certain proven the interest of multipath extension for OLSRv2 in certain
networks, more experiments and experiences are still needed to networks, more experiments and experiences are still needed to
understand the effects of the protocol. The multipath extension for understand the effects of the protocol specified in this experimental
OLSRv2 is expected to be revised and improved to the Standards Track document. The multipath extension for OLSRv2 is expected to be
once sufficient operational experience is obtained. Other than revised documented as a Standard Track document once sufficient
general experiences including the protocol specification and operational experience is obtained. Other than general experiences,
interoperability with base OLSRv2 implementations, the experiences in including the protocol specification and interoperability with base
the following aspects are highly appreciated: OLSRv2 implementations, experiences in the following aspects are
highly appreciated:
o Optimal values for the number of multiple paths (NUMBER_OF_PATHS, o Optimal values for the number of multiple paths (NUMBER_OF_PATHS,
Section 5) to be used. This depends on the network topology and Section 5) to be used. This depends on the network topology and
router density. router density.
o Optimal values used in the metric functions. Metric functions are o Optimal values used in the metric functions. Metric functions are
applied to increase the metric of used links and nodes so as to applied to increase the metric of used links and nodes so as to
obtain disjoint paths. What kind of disjointness is desired obtain disjoint paths. What kind of disjointness is desired
(node-disjoint or link-disjoint) may depend on the layer 2 (node-disjoint or link-disjoint) may depend on the layer 2
protocol used, and can be achieved by applying different sets of protocol used, and can be achieved by applying different sets of
metric functions. metric functions.
o Use of different metric types. This multipath extension can be o Use of different metric types. This multipath extension can be
used with metric types that meet the requirement of OLSRv2, such used with metric types that meet the requirement of OLSRv2, such
as [RFC7779]. The metric type used has also impact to the choice as [RFC7779]. The metric type used has also impact to the choice
of metric functions as indicated in the previous bullet point. of metric functions as indicated in the previous bullet point.
o The impact of partial topology information to multipath o The impact of partial topology information to multipath
calculation. OLSRv2 maintains a partial topology information base calculation. OLSRv2 maintains a partial topology information base
to reduce protocol overhead. Although with existing experience, to reduce protocol overhead. Experience has shown that multiple
multiple paths can be obtained even with such partial information, paths can be obtained even with such partial information, however,
the calculation might be impacted, depending on the Multi-Point depending on the Multi-Point Relay (MPR) selection algorithm used,
Relay (MPR) selection algorithm used. the disjointness of the multiple paths might be impacted depending
on the Multi-Point Relay (MPR) selection algorithm used.
o Use of IPv6 loose source routing. In the current specification, o Use of IPv6 loose source routing. In the current specification,
only strict source routing is used for IPv6 based on [RFC6554]. only strict source routing is used for IPv6 based on [RFC6554].
In [I-D.ietf-6man-segment-routing-header], the use of the loose In [I-D.ietf-6man-segment-routing-header], the use of the loose
source routing is also proposed in IPv6. In scenarios where the source routing is also proposed in IPv6. In scenarios where the
length of the source routing header is critical, the loose source length of the source routing header is critical, the loose source
routing can be considered. routing can be considered.
o Optimal choice of "key" routers for loose source routing. In some o Optimal choice of "key" routers for loose source routing. In some
cases, loose source routing is used to reduce overhead or for cases, loose source routing is used to reduce overhead or for
skipping to change at page 5, line 24 skipping to change at page 5, line 26
results show that multipath routing can reduce the jitter in results show that multipath routing can reduce the jitter in
dynamic scenarios, some transport protocols or applications may be dynamic scenarios, some transport protocols or applications may be
sensitive to the datagram re-ordering. sensitive to the datagram re-ordering.
o The disjoint multipath protocol has interesting application with o The disjoint multipath protocol has interesting application with
erasure coding, especially for services like video/audio streaming erasure coding, especially for services like video/audio streaming
[WPMC11]. The combination of erasure coding mechanisms and this [WPMC11]. The combination of erasure coding mechanisms and this
extension is thus encouraged. extension is thus encouraged.
o Different algorithms to obtain multiple paths, other than the o Different algorithms to obtain multiple paths, other than the
default Multipath Dijkstra algorithm introduced in this default Multipath Dijkstra algorithm introduced in Section 8.5.2
specification. of this specification.
o The use of multi-topology information. By using [RFC7722], o The use of multi-topology information. By using [RFC7722],
multiple topologies using different metric types can be obtained. multiple topologies using different metric types can be obtained.
Although there is no work defining how this extension can make use Although there is no work defining how this extension can make use
of the multi-topology information base yet, it is encouraged to of the multi-topology information base yet, it is encouraged to
experiment with the use of multiple metrics for building multiple experiment with the use of multiple metrics for building multiple
paths. paths.
Comments are solicited and should be addressed to the MANET working
group's mailing list at manet@ietf.org and/or the authors."
2. Terminology 2. Terminology
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 document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
[RFC6130], [RFC7181]. Additionally, it defines the following [RFC6130], [RFC7181]. Additionally, it defines the following
terminology: terminology:
OLSRv2 Routing Process - A routing process based on [RFC7181], OLSRv2 Routing Process - A routing process based on [RFC7181],
without multipath extension specified in this document. without multipath extension specified in this document.
MP-OLSRv2 Routing Process - A multipath routing process based on MP-OLSRv2 Routing Process - A multipath routing process based on
this specification as an extension to [RFC7181]. this specification as an extension to [RFC7181].
SR-OLSRv2 Routing Process - A OLSRv2 Routing Process that supports SR-OLSRv2 Routing Process - A OLSRv2 Routing Process that supports
source routing, or an MP-OLSRv2 Routing Process. source routing (SR), or an MP-OLSRv2 Routing Process.
3. Applicability Statement 3. Applicability Statement
As an extension of OLSRv2, this specification is applicable to MANETs As an extension of OLSRv2, this specification is applicable to MANETs
for which OLSRv2 is applicable (see [RFC7181]). It can operate on for which OLSRv2 is applicable (see [RFC7181]). It can operate on
single or multiple interfaces to discover multiple disjoint paths single or multiple interfaces to discover multiple disjoint paths
from a source router to a destination router. MP-OLSRv2 is designed from a source router to a destination router. MP-OLSRv2 is designed
for networks with dynamic topology by avoiding single route failure. for networks with dynamic topology to avoid single route failure. It
It can also provide higher aggregated throughput and load balancing. can also provide higher aggregated throughput and load balancing.
In a router supporting MP-OLSRv2, MP-OLSRv2 does not necessarily In a router supporting MP-OLSRv2, MP-OLSRv2 does not necessarily
replace OLSRv2 completely. The extension can be applied for certain replace OLSRv2 completely. The extension can be applied for certain
applications that are suitable for multipath routing (mainly video or applications that are suitable for multipath routing (mainly video or
audio streams), based on information such as a DiffServ codepoint audio streams), based on information such as a DiffServ codepoint
[RFC2474]. [RFC2474].
Compared to OLSRv2, this extension does not introduce any new message Compared to OLSRv2, this extension does not introduce any new message
type. A new Message TLV Type is introduced to identify the routers type. A new Message TLV Type is introduced to identify the routers
that support forwarding based on source routing header. It is that support forwarding based on source routing header. It is
interoperable with OLSRv2 implementations that do not have this interoperable with OLSRv2 implementations that do not have this
extension: as the MP-OLSRv2 uses source routing, in IPv4 networks the extension: as the MP-OLSRv2 uses source routing, in IPv4 networks the
interoperability is achieved by using the loose source routing interoperability is achieved using loose source routing headers; in
header; in IPv6 networks, it is achieved by eliminating routers that IPv6 networks, it is achieved by eliminating routers that do not
do not support IPv6 strict source routing. support IPv6 strict source routing.
MP-OLSRv2 supports two different, but interoperable multipath MP-OLSRv2 supports two different, but interoperable multipath
calculation approaches: proactive and reactive. In the proactive calculation approaches: proactive and reactive. In the proactive
calculation, the paths to all the destinations are calculated before calculation, the paths to all the destinations are calculated before
needed. In the reactive calculation, only the paths to desired needed. In the reactive calculation, only the paths to desired
destination(s) are calculated on demand. The proactive approach destination(s) are calculated on demand. The proactive approach
requires more computational resources than the reactive one. The requires more computational resources than the reactive one. The
reactive approach requires the IP forwarding plane to trigger the reactive approach requires the IP forwarding plane to trigger the
multipath calculation. multipath calculation.
skipping to change at page 7, line 19 skipping to change at page 7, line 22
o Identify all the reachable routers in the network. o Identify all the reachable routers in the network.
o Identify a sufficient subset of links in the networks, so that o Identify a sufficient subset of links in the networks, so that
routes can be calculated to all reachable destinations. routes can be calculated to all reachable destinations.
o Provide a Routing Set containing the shortest routes from this o Provide a Routing Set containing the shortest routes from this
router to all destinations. router to all destinations.
In addition, the MP-OLSRv2 Routing Process identifies the routers In addition, the MP-OLSRv2 Routing Process identifies the routers
that support source routing by adding a new Message TLV in HELLO and that support source routing by adding a new Message TLV in HELLO and
TC messages. Based on the above information acquired, every MP- Topology Control (TC) messages. Based on the above information
OLSRv2 Routing Process is aware of a reduced topology map of the acquired, every MP-OLSRv2 Routing Process is aware of a reduced
network and the routers supporting source routing. topology map of the network and the routers supporting source
routing.
A Multipath Routing Set containing the multipath information is A Multipath Routing Set containing the multipath information is
maintained. It may either be proactively calculated or reactively maintained. It may either be proactively calculated or reactively
calculated: calculated:
o In the proactive approach, multiple paths to all possible o In the proactive approach, multiple paths to all possible
destinations are calculated and updated based on control message destinations are calculated and updated based on control message
exchange. The routes are thus available before they are actually exchange. The routes are thus available before they are actually
needed. needed.
o In the reactive approach, a multipath algorithm is invoked on o In the reactive approach, a multipath algorithm is invoked on
demand, i.e., only when there is a datagram to be sent from the demand, i.e., only when there is a datagram to be sent from the
source to the destination, and there is no available Routing Tuple source to the destination, and there is no available Routing Tuple
in the Multipath Routing Set. This requires the IP forwarding in the Multipath Routing Set. This requires the IP forwarding
information base to trigger the multipath calculation specified in information base to trigger the multipath calculation specified in
Section 8.5 when no Multipath Routing Tuple is available. The Section 8.5 when no Multipath Routing Tuple is available. The
reactive operation is local in the router and no additional reactive operation is local to the router and no additional
routing control messages exchange is required. When the paths are routing control messages exchange is required. When the paths are
being calculated, the datagrams SHOULD be buffered unless the being calculated, the datagrams SHOULD be buffered unless the
router does not have enough memory. router does not have enough memory.
Routers in the same network may choose either proactive or reactive Routers in the same network may choose either proactive or reactive
multipath calculation independently according to their computation multipath calculation independently according to their computation
resources. The Multipath Dijkstra algorithm (defined in Section 8.5) resources. The Multipath Dijkstra algorithm (defined in Section 8.5)
is introduced as the default algorithm to generate multiple disjoint is introduced as the default algorithm to generate multiple disjoint
paths from a source to a destination, and such information is kept in paths from a source to a destination, and such information is kept in
the Multipath Routing Set. the Multipath Routing Set.
skipping to change at page 8, line 22 skipping to change at page 8, line 28
5.1. Router Parameters 5.1. Router Parameters
NUMBER_OF_PATHS The number of paths desired by the router. NUMBER_OF_PATHS The number of paths desired by the router.
MAX_SRC_HOPS The maximum number of hops allowed to be put in the MAX_SRC_HOPS The maximum number of hops allowed to be put in the
source routing header. A value set zero means there is no source routing header. A value set zero means there is no
limitation on the maximum number of hops. In an IPv6 network, it limitation on the maximum number of hops. In an IPv6 network, it
MUST be set to 0 because [RFC6554] supports only strict source MUST be set to 0 because [RFC6554] supports only strict source
routing. All the intermediate routers MUST be included in the routing. All the intermediate routers MUST be included in the
source routing header, which makes the number of hops to be kept a source routing header, which a various number of hops. In an IPv4
variable. In an IPv4 network, it MUST be strictly less than 11 network, it MUST be strictly less than 11 and greater than 0 due
and greater than 0 due to the length limit of the IPv4 header. to the length limit of the IPv4 header.
CUTOFF_RATIO The ratio that defines the maximum metric of a path CUTOFF_RATIO The ratio that defines the maximum metric of a path
compared to the shortest path kept in the OLSRv2 Routing Set. For compared to the shortest path kept in the OLSRv2 Routing Set. For
example, the metric to a destination is R_metric based on the example, the metric to a destination is R_metric based on the
Routing Set. Then the maximum metric allowed for a path is Routing Set. Then the maximum metric allowed for a path is
CUTOFF_RATIO * R_metric. CUTOFF_RATIO MUST be greater than or CUTOFF_RATIO * R_metric. CUTOFF_RATIO MUST be greater than or
equal to 1. Note that setting the value to 1 means looking for equal to 1. Setting the number low makes it less likely that
equal length paths, which may not be possible in some networks. additional paths will be found -- for example, setting it to 1
will only consider equal length paths.
SR_TC_INTERVAL The maximum time between the transmission of two SR_TC_INTERVAL The maximum time between the transmission of two
successive TC messages by an MP-OLSRv2 Routing Process. successive TC messages by an MP-OLSRv2 Routing Process.
SR_HOLD_TIME The minimum value in the TLV with Type = VALIDITY_TIME SR_HOLD_TIME The minimum value in the TLV with Type = VALIDITY_TIME
included in TC messages generated based on SR_TC_INTERVAL. included in TC messages generated based on SR_TC_INTERVAL.
6. Packets and Messages 6. Packets and Messages
This extension employs the routing control messages HELLO and TC This extension employs the routing control messages HELLO and TC
skipping to change at page 10, line 26 skipping to change at page 10, line 35
The SR-OLSRv2 Router Set records the routers that support source- The SR-OLSRv2 Router Set records the routers that support source-
route forwarding. This includes routers that run the MP-OLSRv2 route forwarding. This includes routers that run the MP-OLSRv2
Routing Process or the OLSRv2 Routing Process with source-route Routing Process or the OLSRv2 Routing Process with source-route
forwarding support. The set consists of SR-OLSRv2 Router Tuples: forwarding support. The set consists of SR-OLSRv2 Router Tuples:
(SR_addr, SR_time) (SR_addr, SR_time)
where: where:
SR_addr - is the original address of the router that supports SR_addr - is the originator address of the router that supports
source-route forwarding; source-route forwarding;
SR_time - is the time until which the SR-OLSRv2 Router Tuple is SR_time - is the time until which the SR-OLSRv2 Router Tuple is
considered valid. considered valid.
7.2. Multipath Routing Set 7.2. Multipath Routing Set
The Multipath Routing Set records the full path information of The Multipath Routing Set records the full path information of
different paths to the destination. It consists of Multipath Routing different paths to the destination. It consists of Multipath Routing
Tuples: Tuples:
skipping to change at page 11, line 27 skipping to change at page 11, line 39
retains the basic routing control packets formats and processing of retains the basic routing control packets formats and processing of
OLSRv2 to obtain the topology information of the network. The main OLSRv2 to obtain the topology information of the network. The main
differences from the OLSRv2 Routing Process are the datagram differences from the OLSRv2 Routing Process are the datagram
processing at the source router and datagram forwarding. processing at the source router and datagram forwarding.
8.1. HELLO and TC Message Generation 8.1. HELLO and TC Message Generation
HELLO messages are generated according to Section 15.1 of [RFC7181], HELLO messages are generated according to Section 15.1 of [RFC7181],
plus a single message TLV with Type := SOURCE_ROUTE included. plus a single message TLV with Type := SOURCE_ROUTE included.
TC message are generated according to Section 16.1 of [RFC7181] plus TC messages are generated according to Section 16.1 of [RFC7181] plus
a single message TLV with Type := SOURCE_ROUTE included. At least a single message TLV with Type := SOURCE_ROUTE included.
one TC message MUST be generated by an MP-OLSRv2 Routing Process
during the SR_TC_INTERVAL (Section 5), which is greater than
TC_INTERVAL.
TC message generation based on SR_TC_INTERVAL does not replace the For the routers that do not generate TC messages according to
ordinary TC message generation specified in [RFC7181] and MUST NOT [RFC7181], at least one TC message MUST be generated by an MP-OLSRv2
carry any advertised neighbor addresses. This is due to the fact Routing Process during the SR_TC_INTERVAL (Section 5), which MUST be
that not all routers will generate TC messages based on OLSRv2. The greater than or equal to TC_INTERVAL. Those TC messages MUST NOT
TC generation based on SR_TC_INTERVAL serves for those routers to carry any advertised neighbor addresses. This serves for those
advertise the SOURCE_ROUTE TLV so that the other routers can be aware routers to advertise the SOURCE_ROUTE TLV so that the other routers
of the source-route enabled routers so as to be used as destinations can be aware of the source-route enabled routers so as to be used as
of multipath routing. The validity time associated with the destinations of multipath routing. The validity time associated with
VALIDITY_TIME TLV in such TC messages equals SR_HOLD_TIME, which MUST the VALIDITY_TIME TLV in such TC messages equals SR_HOLD_TIME, which
be greater than the SR_TC_INTERVAL. MUST be greater than the SR_TC_INTERVAL. If the TC message carries
an optional INTERVAL_TIME TLV, it MUST have a value encoding the
SR_TC_INTERVAL.
8.2. HELLO and TC Message Processing 8.2. HELLO and TC Message Processing
HELLO and TC messages are processed according to section 15.3 and HELLO and TC messages are processed according to section 15.3 and
16.3 of [RFC7181]. 16.3 of [RFC7181].
In addition to the reasons specified in [RFC7181] for discarding a In addition to the reasons specified in [RFC7181] for discarding a
HELLO message or a TC message on reception, a HELLO or TC message HELLO message or a TC message on reception, a HELLO or TC message
received MUST be discarded if it has more than one Message TLV with received MUST be discarded if it has more than one Message TLV with
Type = SOURCE_ROUTE. Type = SOURCE_ROUTE.
For every HELLO or TC message received, if there is a Message TLV For every HELLO or TC message received, if there is a Message TLV
with Type := SOURCE_ROUTE, create or update (if the Tuple exists with Type := SOURCE_ROUTE, create or update (if the Tuple exists
already) the SR-OLSR Router Tuple with already) the SR-OLSR Router Tuple with
o SR_addr := originator address of the HELLO or TC message o SR_addr := originator address of the HELLO or TC message
o SR_time := current_time + validity time of the TC or HELLO message o SR_time := current_time + validity time of the TC or HELLO message
defined in [RFC7181], unless the existing SR_time is greater than defined in [RFC7181].
the newly calculated the SR_time.
8.3. MPR Selection 8.3. MPR Selection
Each MP-OLSRv2 Routing Process selects routing MPRs and flooding MPRs Each MP-OLSRv2 Routing Process selects routing MPRs and flooding MPRs
following Section 18 of [RFC7181]. In a mixed network with OLSRv2- following Section 18 of [RFC7181]. In a mixed network with OLSRv2-
only routers, the following considerations apply when calculating only routers, the following considerations apply when calculating
MPRs: MPRs:
o MP-OLSRv2 routers SHOULD be preferred as routing MPRs to increase o MP-OLSRv2 routers SHOULD be preferred as routing MPRs to increase
the possibility of finding disjoint paths using MP-OLSRv2 routers. the possibility of finding disjoint paths using MP-OLSRv2 routers.
skipping to change at page 13, line 51 skipping to change at page 14, line 12
path. Depending on the size of the routing domain, the MTU should be path. Depending on the size of the routing domain, the MTU should be
at least 1280 + 40 (for the outer IP header) + 16 * diameter of the at least 1280 + 40 (for the outer IP header) + 16 * diameter of the
network in number of hops (for the source routing header). If the network in number of hops (for the source routing header). If the
links in the network have different MTU sizes, by using technologies links in the network have different MTU sizes, by using technologies
like Path MTU Discovery, the routers are able to be aware of the MTU like Path MTU Discovery, the routers are able to be aware of the MTU
along the path. The size of the datagram plus the size of IP headers along the path. The size of the datagram plus the size of IP headers
(including the source routing header) should not exceed the minimum (including the source routing header) should not exceed the minimum
MTU along the path, otherwise, the source routing should not be used. MTU along the path, otherwise, the source routing should not be used.
If the destination of the datagrams is out the MP-OLSRv2 routing If the destination of the datagrams is out the MP-OLSRv2 routing
domain, the datagram must be source route to the gateway between the domain, the datagram must be source routed to the gateway between the
MP-OLSRv2 routing domain and the rest of the Internet. The gateway MP-OLSRv2 routing domain and the rest of the Internet. The gateway
MUST remove the source routing header before forwarding the datagram MUST remove the source routing header before forwarding the datagram
to the rest of the Internet. to the rest of the Internet.
8.5. Multipath Calculation 8.5. Multipath Calculation
8.5.1. Requirements of Multipath Calculation 8.5.1. Requirements of Multipath Calculation
The Multipath Routing Set maintains the information of multiple paths The Multipath Routing Set maintains the information of multiple paths
to the destination. The Path Tuples of the Multipath Routing Set to the destination. The Path Tuples of the Multipath Routing Set
skipping to change at page 17, line 25 skipping to change at page 17, line 35
parallel paths used in datagram forwarding. Setting it to one parallel paths used in datagram forwarding. Setting it to one
makes the specification identical to OLSRv2. Setting it to too makes the specification identical to OLSRv2. Setting it to too
large values may lead to unnecessary computational overhead and large values may lead to unnecessary computational overhead and
inferior paths. inferior paths.
o MAX_SRC_HOPS := 10, for IPv4 networks. For IPv6 networks, it MUST o MAX_SRC_HOPS := 10, for IPv4 networks. For IPv6 networks, it MUST
be set to 0, i.e., no constraint on maximum number of hops. be set to 0, i.e., no constraint on maximum number of hops.
o CUTOFF_RATIO := 1.5. It MUST be greater or equal than 1. o CUTOFF_RATIO := 1.5. It MUST be greater or equal than 1.
o SR_TC_INTERVAL := 10 x TC_INTERVAL. It SHOULD be significantly o SR_TC_INTERVAL := 10 x TC_INTERVAL. It MUST be greater than or
greater than TC_INTERVAL to reduce unnecessary TC message equal to TC_INTERVAL. It SHOULD be significantly greater than
generations. TC_INTERVAL to reduce unnecessary TC message generations.
o SR_HOLD_TIME := 32 x TC_INTERVAL. It MUST be greater than o SR_HOLD_TIME := 3 x SR_TC_INTERVAL. It MUST be greater than
SR_TC_INTERVAL. It SHOULD be greater than 30 x TC_INTERVAL. SR_TC_INTERVAL and SHOULD allow for a small number of lost
messages.
If Multipath Dijkstra Algorithm is applied: If Multipath Dijkstra Algorithm is applied:
o fp(c) := 4*c, where c is the original metric of the link. o fp(c) := 4*c, where c is the original metric of the link.
o fe(c) := 2*c, where c is the original metric of the link. o fe(c) := 2*c, where c is the original metric of the link.
The setting of metric functions fp and fc defines the preference of The setting of metric functions fp and fc defines the preference of
obtained multiple disjoint paths. If id is the identity function, obtained multiple disjoint paths. If id is the identity function,
i.e., fp(c)=c, 3 cases are possible: i.e., fp(c)=c, 3 cases are possible:
skipping to change at page 20, line 34 skipping to change at page 20, line 45
calculation is finished, the datagrams are forwarded and the buffer calculation is finished, the datagrams are forwarded and the buffer
goes back to empty. goes back to empty.
12. IANA Considerations 12. IANA Considerations
This section adds one new Message TLV, allocated as a new Type This section adds one new Message TLV, allocated as a new Type
Extension to an existing Message TLV. Extension to an existing Message TLV.
12.1. Message TLV Types 12.1. Message TLV Types
This specification updates the Message Type 7 by adding the new Type This specification updates the IANA registry "Message TLV Types" --
Extension SOURCE_ROUTE, as illustrated in Table 1. Message Type 7 by adding the new Type Extension SOURCE_ROUTE, as
illustrated in Table 1.
+-----------+--------------+------------------------+---------------+ +-----------+--------------+------------------------+---------------+
| Type | Name | Description | Reference | | Type | Name | Description | Reference |
| Extension | | | | | Extension | | | |
+-----------+--------------+------------------------+---------------+ +-----------+--------------+------------------------+---------------+
| TBD | SOURCE_ROUTE | Indicates that the | This | | TBD | SOURCE_ROUTE | Indicates that the | This |
| | | originator of the | specification | | | | originator of the | specification |
| | | message supports | | | | | message supports | |
| | | source route | | | | | source route | |
| | | forwarding. No value. | | | | | forwarding. No value. | |
 End of changes. 30 change blocks. 
67 lines changed or deleted 77 lines changed or added

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