draft-ietf-manet-olsrv2-multipath-14.txt   draft-ietf-manet-olsrv2-multipath-15.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 23, 2017 University of Nantes Expires: November 25, 2017 University of Nantes
May 22, 2017 May 24, 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-14 draft-ietf-manet-olsrv2-multipath-15
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 for Mobile Ad Hoc Networks (MANETs). Considering the disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the
characteristics of MANETs, especially the dynamic network topology, characteristics of MANETs, especially the dynamic network topology,
using multiple paths can increase aggregated throughput and improve using multiple paths can increase aggregated throughput and improve
the reliability by avoiding single route failures. The the reliability by avoiding single route failures. The
interoperability with OLSRv2 is retained. interoperability with OLSRv2 is retained.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 23, 2017. This Internet-Draft will expire on November 25, 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 39 skipping to change at page 2, line 39
8.2. HELLO and TC Message Processing . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . 19
10.2. Multipath extension based on olsrd . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . 24 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)
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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
interoperability with OLSRv2 routers. Other than the basic rules interoperability with OLSRv2 routers. Other than the basic rules
defined in the following parts of this document, optimal choices defined in the following parts of this document, optimal choices
of routers to put in the loose source routing header can be of routers to put in the loose source routing header can be
further studied. further studied.
o Different path-selection schedulers. By default, round-robin o Different path-selection schedulers. Depending on the application
scheduling is used to select a path to be used for datagrams. In type and transport layer type, either per-flow scheduler or per-
some scenarios, weighted scheduling can be considered: for datagram scheduler is applied. By default, the traffic load
example, the paths with lower metrics (i.e., higher quality) can should be equally distributed in multiple paths. In some
transfer more datagrams compared to paths with higher metrics. scenarios, weighted scheduling can be considered: for example, the
paths with lower metrics (i.e., higher quality) can transfer more
datagrams or flows compared to paths with higher metrics.
o The impacts of the delay variation due to multipath routing. o The impacts of the delay variation due to multipath routing.
[RFC2991] brings out some concerns of multipath routing, [RFC2991] brings out some concerns of multipath routing,
especially variable latencies. Although current experiment especially variable latencies when per-datagram scheduling is
results show that multipath routing can reduce the jitter in applied. Although current experiment results show that multipath
dynamic scenarios, some transport protocols or applications may be routing can reduce the jitter in dynamic scenarios, some transport
sensitive to the datagram re-ordering. protocols or applications may be 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 Section 8.5.2 default Multipath Dijkstra algorithm introduced in Section 8.5.2
of this specification. of this specification.
skipping to change at page 8, line 9 skipping to change at page 8, line 11
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.
The datagram is forwarded based on source routing. When there is a The datagram is forwarded based on source routing. When there is a
datagram to be sent to a destination, the source router acquires a datagram to be sent to a destination, the source router acquires a
path from the Multipath Routing Set (MAY be round-robin, or other path from the Multipath Routing Set. The path information is stored
scheduling algorithms). The path information is stored in the in the datagram header using the source routing header.
datagram header using the source routing header.
5. Parameters and Constants 5. Parameters and Constants
In addition to the parameters and constants defined in [RFC7181], In addition to the parameters and constants defined in [RFC7181],
this specification uses the parameters and constants described in this specification uses the parameters and constants described in
this section. this section.
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.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
is forwarded following the OLSRv2 Routing Process. is forwarded following the OLSRv2 Routing Process.
If no matching Multipath Routing Tuple is found and the Multipath If no matching Multipath Routing Tuple is found and the Multipath
Routing Set is maintained reactively, the multipath algorithm defined Routing Set is maintained reactively, the multipath algorithm defined
in Section 8.5 is invoked, to calculate the Multipath Routing Tuple in Section 8.5 is invoked, to calculate the Multipath Routing Tuple
to the destination. If the calculation does not return any Multipath to the destination. If the calculation does not return any Multipath
Routing Tuple, the following steps are aborted and the datagram is Routing Tuple, the following steps are aborted and the datagram is
forwarded following the OLSRv2 Routing Process. forwarded following the OLSRv2 Routing Process.
If a matching Multipath Routing Tuple is obtained, the Path Tuples of If a matching Multipath Routing Tuple is obtained, the Path Tuples of
the Multipath Routing Tuple are applied to the datagrams using round- the Multipath Routing Tuple are applied to the datagrams using either
robin scheduling. For example, there are 2 path Tuples (Path-1, per-flow scheduling or per-datagram scheduling, depending on the
Path-2) for destination router D. A series of datagrams (Packet-1, transport layer protocol and the application used. By default, per-
Packet-2, Packet-3, ... etc.) are to be sent router D. Path-1 is then flow scheduling is used, especially for the transport protocols that
chosen for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc. are sensitive to reordering, such as TCP. The path selection
Other path scheduling mechanisms are also possible and will not decision is made on the first datagram and all subsequent datagrams
impact the interoperability of different implementations. of the same flow use the same path. If the path is detected broken
before the flow is closed, another path with the most similar metric
is used. Per-datagram scheduling is recommended if the traffic is
insensitive to reordering such as non-reliable transmission of media
traffic, or when erasure coding is applied. In such case, each
datagram selects its paths independently.
By default, the traffic load should be equally distributed in
multiple paths. Other path scheduling mechanisms (e.g., assigning
more traffic over better paths) are also possible and will not impact
the interoperability of different implementations.
The addresses in PT_address[1, ..., n-1] of the chosen Path Tuple are The addresses in PT_address[1, ..., n-1] of the chosen Path Tuple are
thus added to the datagram header as the source routing header. For thus added to the datagram header as the source routing header. For
IPv6 networks, strict source routing is used, thus all the IPv6 networks, strict source routing is used, thus all the
intermediate routers in the path are stored in the source routing intermediate routers in the path are stored in the source routing
header following the format defined in section 3 of [RFC6554] with header following the format defined in section 3 of [RFC6554] with
Routing Type set to 3. Routing Type set to 3.
For IPv4 networks, loose source routing is used, with the following For IPv4 networks, loose source routing is used, with the following
rules: rules:
 End of changes. 9 change blocks. 
25 lines changed or deleted 37 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/