draft-ietf-manet-olsrv2-multipath-07.txt   draft-ietf-manet-olsrv2-multipath-08.txt 
Network Working Group J. Yi Network Working Group J. Yi
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Experimental B. Parrein Intended status: Experimental B. Parrein
Expires: July 23, 2016 University of Nantes Expires: October 29, 2016 University of Nantes
January 20, 2016 April 27, 2016
Multi-path Extension for the Optimized Link State Routing Protocol Multi-path Extension for the Optimized Link State Routing Protocol
version 2 (OLSRv2) version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multipath-07 draft-ietf-manet-olsrv2-multipath-08
Abstract Abstract
This document specifies a multi-path extension for the Optimized Link This document specifies a multi-path 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, so as to improve reliability of the OLSRv2 protocol.
The interoperability with OLSRv2 is retained. The interoperability with OLSRv2 is retained.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 23, 2016. This Internet-Draft will expire on October 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 37 skipping to change at page 2, line 37
8.3. MPR Selection . . . . . . . . . . . . . . . . . . . . . . 10 8.3. MPR Selection . . . . . . . . . . . . . . . . . . . . . . 10
8.4. Datagram Processing at the MP-OLSRv2 Originator . . . . . 11 8.4. Datagram Processing at the MP-OLSRv2 Originator . . . . . 11
8.5. Multi-path Calculation . . . . . . . . . . . . . . . . . . 11 8.5. Multi-path Calculation . . . . . . . . . . . . . . . . . . 11
8.5.1. Requirements of Multi-path Calculation . . . . . . . . 11 8.5.1. Requirements of Multi-path Calculation . . . . . . . . 11
8.5.2. Multi-path Dijkstra Algorithm . . . . . . . . . . . . 12 8.5.2. Multi-path Dijkstra Algorithm . . . . . . . . . . . . 12
8.6. Datagram Forwarding . . . . . . . . . . . . . . . . . . . 13 8.6. Datagram Forwarding . . . . . . . . . . . . . . . . . . . 13
9. Configuration Parameters . . . . . . . . . . . . . . . . . . . 13 9. Configuration Parameters . . . . . . . . . . . . . . . . . . . 13
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
10.1. Multi-path extension based on nOLSRv2 . . . . . . . . . . 15 10.1. Multi-path extension based on nOLSRv2 . . . . . . . . . . 15
10.2. Multi-path extension based on olsrd . . . . . . . . . . . 15 10.2. Multi-path extension based on olsrd . . . . . . . . . . . 15
10.3. Multi-path extension based on umOLSR . . . . . . . . . . . 15 10.3. Multi-path extension based on umOLSR . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. Expert Review: Evaluation Guidlines . . . . . . . . . . . 16 12.1. Expert Review: Evaluation Guidlines . . . . . . . . . . . 17
12.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17 12.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Multi-path Dijkstra Algorithm . . . . . . 19 Appendix A. Examples of Multi-path Dijkstra Algorithm . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 12, line 17 skipping to change at page 12, line 17
path Routing Tuple to a desired destination to obtain the multiple path Routing Tuple to a desired destination to obtain the multiple
paths. For each path to a destination, the algorithm must provide: paths. For each path to a destination, the algorithm must provide:
o The metric of the path to the destination, o The metric of the path to the destination,
o The list of intermediate routers on the path. o The list of intermediate routers on the path.
For IPv6 networks, as strict source routing is used, only the routers For IPv6 networks, as strict source routing is used, only the routers
that exist in SR-OLSRv2 Router Set are considered in the path that exist in SR-OLSRv2 Router Set are considered in the path
calculation, i.e., only the source-routing supported routers can calculation, i.e., only the source-routing supported routers can
exist in the path. After the calculation of multiple paths, the exist in the path.
metric of the shortest path (denoted c) to the destination is
compared to the R_metric of the OLSRv2 Routing Tuple ([RFC7181]) to After the calculation of multiple paths, the metric of paths (denoted
the same destination. If the metric c is greater than R_metric * c_i for path i) to the destination is compared to the R_metric of the
CUTOFF_RATIO, the multipath routing SHOULD NOT be used, and the OLSRv2 Routing Tuple ([RFC7181]) to the same destination. If the
router SHOULD fall back to OLSRv2 Routing Process. This can happen metric c_i is greater than R_metric * CUTOFF_RATIO, the corresponding
if there are too much OLSRv2-only routers in the network, and path i SHOULD NOT be used. If less than 2 paths are found with
requiring multipath routing brutally may result in inferior paths. metrics less than R_metric * CUTOFF_RATIO, the router SHOULD fall
back to OLSRv2 Routing Process without using multipath routing. This
can happen if there are too much OLSRv2-only routers in the network,
and requiring multipath routing brutally may result in inferior
paths.
By invoking the multi-path algorithm, NUMBER_OF_PATHS paths are By invoking the multi-path algorithm, NUMBER_OF_PATHS paths are
obtained and added to the Multi-path Routing Set, by creating a obtained and added to the Multi-path Routing Set, by creating a
Multi-path Routing Tuple with: Multi-path Routing Tuple with:
o MR_dest_addr := destination of the datagram o MR_dest_addr := destination of the datagram
o A MP_path_set with calculated Path Tuples. Each Path Tuple o A MP_path_set with calculated Path Tuples. Each Path Tuple
corresponds to a path obtained in Multi-path Dijkstra algorithm, corresponds to a path obtained in Multi-path Dijkstra algorithm,
with PT_metric := metric of the calculated path and with PT_metric := metric of the calculated path and
skipping to change at page 20, line 17 skipping to change at page 20, line 23
/ / \ \ / / \ \
S (2) (1) D S (2) (1) D
\ / \ / \ / \ /
(1) / \ / (2) (1) / \ / (2)
B----(3)----C B----(3)----C
Figure 1 Figure 1
The capital letters are name of routers. An arbitrary metric with The capital letters are name of routers. An arbitrary metric with
value between 1 and 3 is used. The initial metrics of all the links value between 1 and 3 is used. The initial metrics of all the links
are indicated in the parenthesis. The incremental functions fp and are indicated in the parenthesis. The incremental functions fp(c)=4c
fe are defined as fp(c)=4c and fe(c)=2c in this example. Two paths and fe(c)=2c are used in this example. Two paths from router S to
from router S to router D are demanded. router D are demanded.
On the first run of the Dijkstra algorithm, the shortest path S->A->D On the first run of the Dijkstra algorithm, the shortest path S->A->D
with metric 3 is obtained. with metric 3 is obtained.
The incremental function fp is applied to increase the metric of the The incremental function fp is applied to increase the metric of the
link S-A and A-D. fe is applied to increase the metric of the link link S-A and A-D. fe is applied to increase the metric of the link
A-B and A-C. Figure 2 shows the link metrics after the punishment. A-B and A-C. Figure 2 shows the link metrics after the punishment.
.-----A-----(8) .-----A-----(8)
(4) / \ \ (4) / \ \
 End of changes. 8 change blocks. 
18 lines changed or deleted 22 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/