Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multipath-10
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8218.
|
|
|---|---|---|---|
| Authors | Jiazi Yi , Benoit Parrein | ||
| Last updated | 2016-07-05 | ||
| Replaces | draft-yi-manet-olsrv2-multipath | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
(of
-12)
by Zhen Cao
Ready w/issues
GENART Last Call review
(of
-12)
by Peter Yee
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8218 (Experimental) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-manet-olsrv2-multipath-10
## What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard. This is a normative WG document, and this is the proper type. ## The IESG approval announcement includes a Document Announcement Write-Up. ### Technical Summary: This document defines a poll-based HTTP transport for SETs (security events) which are specified in RFC 8417. The document defines transport using HTTP POST and TLS, as well as optional assurance for such delivery. ### Working Group Summary There is WG consensus for publishing this document, and no ocntroversy. ### Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Implementations: Microsoft has the protocol running in production. No noteworthy reviews, and no special expertise required, beyond the working group's core expertise. ## Personnel Yaron Sheffer is the document shepherd. Ben Kaduk is the responsible AD. ## Briefly describe the review of this document that was performed by the Document Shepherd. I reviewed this document again and my comments were fully addressed by a new revision. I believe the document is now ready for publication. ## Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have such concerns. ## Do portions of the document need review from a particular or from broader perspective? No such reviews. ## Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? The document is ready and the protocol addresses a real need expressed by WG constituents. It should be noted that the WG consciously decided to publish two alternative transports for SETs using HTTP Push and Poll, and this is one of them. ## Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. ## Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures. ## How solid is the WG consensus behind this document? Full consensus, though this is a relatively small community. ## Has anyone threatened an appeal or otherwise indicated extreme discontent? No. ## Identify any ID nits the Document Shepherd has found in this document. I have checked for I-D nits and no such nits remain, other than a reference to an obsolete RFC (TLS 1.2, RFC 5246Implementation experience and test data can be found at [ADHOC11] and [GIIS14]. 10.3. Multi-path extension based on umOLSR The implementation is conducted by University of Nantes, France, and is based on um-olsr implementation (http://masimum.inf.um.es/fjrm/development/um-olsr/). The code is available at https://github.com/yijiazi/mpolsr_ns2 and http://jiaziyi.com/index.php/research-projects/mp-olsr under GNU GPL license. The implementation is for network simulation for NS2 network simulator. All the specification is implemented in this implementation. Implementation experience and test data can be found at [WCNC08]. 11. Security Considerations As an extension of [RFC7181], the security considerations and security architecture illustrated in [RFC7181] are applicable to this MP-OLSRv2 specification. The implementations without security mechanisms are vulnerable to threats discussed in [I-D.ietf-manet-olsrv2-sec-threats]. In a mixed network with OLSRv2-only routers, a compromised router can add SOURCE_ROUTE TLVs in its TC and HELLO messages, which will make other MP-OLSR Routing Process believes that it supports source routing. This will increase the the possibility of being chosen as MPRs and be put into the source routing header. The former will make it possible to manipulate the flooding of TC messages and the latter will make the datagram pass through the compromised router. As [RFC7181], a conformant implementation of MP-OLSRv2 MUST, at minimum, implement the security mechanisms specified in [RFC7183] to provide integrity and replay protection of routing control messages. Compared to OLSRv2, the use of source routing header in this specification introduces vulnerabilities related to source routing attacks, which include bypassing filtering devices, bandwidth exhaustion of certain routers, etc. Those attacks are discussed in Section 5.1 of [RFC6554] and [RFC5095]. The influence is limited to the OLSRv2/MP-OLSRv2 routing domain, because the source routing header is used only in the current routing domain. Yi & Parrein Expires January 6, 2017 [Page 18] Internet-Draft Multi-Path OLSRv2 July 2016 12. IANA Considerations This section adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV. 12.1. Expert Review: Evaluation Guidelines For the registry where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444]. 12.2. Message TLV Types This specification updates the Message Type 7 by adding the new Type Extension SOURCE_ROUTE, as illustrated in Table 1. +-----------+--------------+------------------------+---------------+ | Type | Name | Description | Reference | | Extension | | | | +-----------+--------------+------------------------+---------------+ | TBD | SOURCE_ROUTE | Indicates the | This | | | | originator of the | specification | | | | message supports | | | | | source route | | | | | forwarding. No value. | | +-----------+--------------+------------------------+---------------+ Table 1: SOURCE_ROUTE type for RFC 5444 Type 7 Message TLV Type Extensions 12.3. Routing Type This specification uses the experimental value 254 of the IPv6 Routing Type as specified in [RFC5871] for IPv6 source routing. 13. Acknowledgments The authors would like to thank Sylvain David, Asmaa Adnane, Eddy Cizeron, Salima Hamma, Pascal Lesage and Xavier Lecourtier for their efforts in developing, implementing and testing the specification. The authors also appreciate valuable discussions with Thomas Clausen, Ulrich Herberg, Justin Dean, Geoff Ladwig, Henning Rogge , Marcus Barkowsky and Christopher Dearlove. 14. References Yi & Parrein Expires January 6, 2017 [Page 19] Internet-Draft Multi-Path OLSRv2 July 2016 14.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <http://www.rfc-editor.org/info/rfc5444>. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>. [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <http://www.rfc-editor.org/info/rfc6554>. [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>. [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <http://www.rfc-editor.org/info/rfc7183>. 14.2. Informative References [ADHOC11] Yi, J., Adnane, A-H., David, S., and B. Parrein, "Multipath optimized link state routing for mobile ad hoc networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011. [GIIS14] Macedo, R., Melo, R., Santos, A., and M. Nogueria, "Experimental performance comparison of single-path and multipath routing in VANETs", In Global Information Yi & Parrein Expires January 6, 2017 [Page 20] Internet-Draft Multi-Path OLSRv2 July 2016 Infrastructure and Networking Symposium (GIIS), 2014 , vol. 1, no. 6, pp. 15-19, 2014. [I-D.ietf-manet-olsrv2-sec-threats] Clausen, T., Herberg, U., and J. Yi, "Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2)", draft-ietf-manet-olsrv2-sec-threats-02 (work in progress), May 2016. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>. [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, DOI 10.17487/ RFC2501, January 1999, <http://www.rfc-editor.org/info/rfc2501>. [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/ RFC2991, November 2000, <http://www.rfc-editor.org/info/rfc2991>. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <http://www.rfc-editor.org/info/rfc5095>. [RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, May 2010, <http://www.rfc-editor.org/info/rfc5871>. [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, <http://www.rfc-editor.org/info/rfc6982>. [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015, <http://www.rfc-editor.org/info/rfc7722>. Yi & Parrein Expires January 6, 2017 [Page 21] Internet-Draft Multi-Path OLSRv2 July 2016 [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)", RFC 7779, DOI 10.17487/ RFC7779, April 2016, <http://www.rfc-editor.org/info/rfc7779>. [WCNC08] Yi, J., Cizeron, E., Hamma, S., and B. Parrein, "Simulation and performance analysis of MP-OLSR for mobile ad hoc networks", In Proceeding of IEEE Wireless Communications and Networking Conference, 2008. Appendix A. Examples of Multi-path Dijkstra Algorithm This appendix gives two examples of multi-path Dijkstra algorithm. A network topology is depicted in Figure 2. .-----A-----(2) (1) / \ \ / / \ \ S (2) (1) D \ / \ / (1) / \ / (2) B----(3)----C Figure 2 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 are indicated in the parenthesis. The incremental functions fp(c)=4c and fe(c)=2c are used in this example. Two paths from router S to router D are demanded. On the first run of the Dijkstra algorithm, the shortest path S->A->D with metric 3 is obtained. 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 A-B and A-C. Figure 3 shows the link metrics after the punishment. Yi & Parrein Expires January 6, 2017 [Page 22] Internet-Draft Multi-Path OLSRv2 July 2016 .-----A-----(8) (4) / \ \ / / \ \ S (4) (2) D \ / \ / (1) / \ / (2) B----(3)----C Figure 3 On the second run of the Dijkstra algorithm, the second path S->B->C->D with metric 6 is obtained. As mentioned in Section 8.5, the Multi-path Dijkstra Algorithm does not guarantee strict disjoint path to avoid choosing inferior paths. For example, given the topology in Figure 4, two paths from node S to D are desired. On the top of the figure, there is a high cost path between S and D. If a algorithm tries to obtain strict disjoint paths, the two paths obtained will be S--B--D and S--(high cost path)--D, which are extremely unbalanced. It is undesired because it will cause huge delay variance between the paths. By using the Multi-path Dijkstra algorithm, which is based on the punishing scheme, S--B--D and S--B--C--D will be obtained. --high cost path- / \ / \ S----B--------------D \ / \---C-----/ Figure 4 Yi & Parrein Expires January 6, 2017 [Page 23] Internet-Draft Multi-Path OLSRv2 July 2016 Authors' Addresses Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex, France Phone: +33 (0) 1 77 57 80 85 Email: jiazi@jiaziyi.com URI: http://www.jiaziyi.com/ Benoit Parrein University of Nantes IRCCyN lab - IVC team Polytech Nantes, rue Christian Pauc, BP50609 44306 Nantes cedex 3 France Phone: +33 (0) 2 40 68 30 50 Email: Benoit.Parrein@polytech.univ-nantes.fr URI: http://www.irccyn.ec-nantes.fr/~parrein Yi & Parrein Expires January 6, 2017 [Page 24]