Mobile Ad hoc Networking (MANET) C. Dearlove Internet-Draft BAE Systems ATC Updates: RFC 6130 February 14, 2014 (if approved) Intended status: Standards Track Expires: August 18, 2014 An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) draft-dearlove-manet-nhdp-optimization-00 Abstract This specification updates the MANET Neighborhood Discovery Protocol (NHDP) to ensure greater robustness of 2-hop neighbor information when using link quality information. This specification also updates the Optimized Link State Routing Protocol (OLSRv2). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Dearlove Expires August 18, 2014 [Page 1] Internet-Draft NHDP Optimization February 2014 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 4. Changes to NHDP . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Interface Information Bases . . . . . . . . . . . . . . . . 4 4.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 4 4.3. Information Base Changes . . . . . . . . . . . . . . . . . 5 4.4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Changes to OLSRv2 . . . . . . . . . . . . . . . . . . . . . . . 6 6. MIB Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Dearlove Expires August 18, 2014 [Page 2] Internet-Draft NHDP Optimization February 2014 1. Introduction The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] contains a mechanism known as "link quality" that allows a router using the protocol to disallow the consideration of some of its 1-hop neighbors. This lasts as long as the quality of the link from that 1-hop neighbor falls below an acceptable link quality threshold. A feature of this mechanism is that while the link quality remains too low, the link information, established by the exchange of HELLO messages, is retained. Thus if the link quality goes back above the required threshold (note that a hysteresis mechanism means that two thresholds are used) then the link is immediately reestablished and will be immediately available for use. [RFC6130] collects not just 1-hop neighbor information, but also information about symmetric 2-hop neighbors. However [RFC6130] specifies that if a 1-hop neighbor is considered no longer symmetric then the corresponding 2-Hop Tuples that record the 2-hop neighbor information are removed, without a retention mechanism for a (possibly temporary) loss due to link quality. This means that if there is a short period in which link quality is too low, then when the link quality is reestablished, all 1-hop neighbor information is immediately available for use again. But for the corresponding symmetric 2-hop neighbor information, this must wait until the next corresponding HELLO message to restore this information. This is not necessary, and this specification describes how [RFC6130] can be updated to avoid this. This update is strictly optional, and routers that do and do not implement it can interwork entirely successfully (as they also can with different link quality specifications). In addition, by a suitable interpretation, this change can be invisible to any other protocols using [RFC6130], in particular [OLSRv2]. However the impact on [OLSRv2] when not so handled is also described, owing to the existence of implementations of that protocol that are not modularly separated from [RFC6130]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses the terminology of [RFC6130] and Dearlove Expires August 18, 2014 [Page 3] Internet-Draft NHDP Optimization February 2014 [OLSRv2]. 3. Applicability Statement This specification updates [RFC6130]. As such it is applicable to all implementations of this protocol. The optimization presented in this specification is simply permissive, it allows an additional optimization, and there is no requirement for any implementation to include it. However inclusion of this optimization is advised, it can, in some cases, enable formation of a more stable network. This specification also updates [OLSRv2]. This could be avoided by simply noting that this specification describes how the updates to [RFC6130] may be handled so as to be invisible to any other protocol using it. However as it is known that some implementations of [OLSRv2] are not independent of the implementation of [RFC6130] that they use, it is useful to indicate the direct impact on [OLSRv2]. A router that implements the optimization described in this specification will interoperate successfully with routers not implementing this optimization. 4. Changes to NHDP The following changes are made to [RFC6130] if using this specification. Note that while this specification is OPTIONAL, if any of these changes are made then all of these changes MUST be made. 4.1. Interface Information Bases The 2-Hop Set is modified by adding this additional element to each 2-Hop Tuple: N2_lost is a boolean flag, which indicates the state of the corresponding Link Tuple. If L_status = SYMMETRIC (and thus L_lost = false), then N2_lost = false. If L_SYM_time has not expired, and L_lost = false (and hence L_status = LOST), then N2_lost = true. In all other cases, including other cases with L_status = LOST, there will be no such 2-Hop Tuples. 4.2. HELLO Message Processing In Section 12.6 of [RFC6130] make the following changes: Dearlove Expires August 18, 2014 [Page 4] Internet-Draft NHDP Optimization February 2014 o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not expired". o When creating a 2-Hop Tuple, set N2_lost := L_lost. 4.3. Information Base Changes In Section 13, replace the second bullet point by: o A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time expires, or the Link Tuple is removed. In this case, the actions specified in Section 13.2 are performed. and replace the paragraph after the bullet points by: If a Link Tuple is removed, or if L_HEARD_time expires and either L_status changes from SYMMETRIC or L_SYM_time expires, then the actions specified in Section 13.2 MUST be performed before the actions specified in Section 13.3 are performed for that Link Tuple. In Section 13.2 of [RFC6130], add the following, before all other text: For each Link Tuple that has L_SYM_time not expired: 1. If L_SYM_time then expires, or if the Link Tuple is removed: 1. Remove each 2-Hop Tuple for the same MANET interface with: + N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list. 2. If L_status then changes from SYMMETRIC to LOST because L_lost is set to true: 1. For each 2-Hop Tuple for the same MANET interface with: + N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list; set N2_lost := true. Also in Section 13.2 of [RFC6130], remove point 2, renumbering point 2 as point 1. Dearlove Expires August 18, 2014 [Page 5] Internet-Draft NHDP Optimization February 2014 4.4. Constraints In Appendix B, under "In each 2-Hop Tuple:" change the first bullet point to: o There MUST be a Link Tuple associated with the same MANET interface with: * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND * L_SYM_time not expired; AND * L_lost = N2_lost. 5. Changes to OLSRv2 If the implementation of [RFC6130] conceals from any protocol using it the existence of all 2-Hop Tuples with N2_lost = true, then no changes are required to any protocol using [RFC6130], in particular no changes are required to [OLSRv2]. However if instead the implementation of [RFC6130] makes all 2-Hop Tuples visible, including those with N2_lost = true, then protocols using [RFC6130] MUST ignore such 2-Hop Tuples. For OLSRv2 this means behaving as if all of the following changes were to be made to [OLSRv2]: o In Section 17.6 of [OLSRv2], point 1, replace the final two bullet points with: * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost = false is added or removed, OR; * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost changed, OR; * The N2_out_metric of any 2-Hop Tuple with N2_lost = false changes, and either the flooding MPR selection process uses metric values (see Section 18.4) or the change is to or from UNKNOWN_METRIC. o In Section 17.6 of [OLSRv2], point 3, replace the final two bullet points with: * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = false is added or removed, OR; Dearlove Expires August 18, 2014 [Page 6] Internet-Draft NHDP Optimization February 2014 * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost changed, OR; * The N2_in_metric of any 2-Hop Tuple with N2_lost = false changes. o In Section 17.7 of [OLSRv2], in the fifth bullet point, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". o In Section 18.4 of [OLSRv2], in the third bullet point, add ", N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". o In Section 18.5 of [OLSRv2], in the third bullet point, add ", N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC". o In Section 19.1 of [OLSRv2], in the final main bullet point (marked as "(OPTIONAL)"), add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". o In Appendix C.7 of [OLSRv2], in point 1, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 6. MIB Considerations TBD. 7. IANA Considerations This document has no actions for IANA. [This section may be removed by the RFC Editor.] 8. Security Considerations The update to [RFC6130] enables the retention and reuse of some information collected by that protocol, for only the duration that it could have been used in any case. As such, this protocol introduces no new security considerations to an implementation of [RFC6130] or of any other protocol that uses it, such as [OLSRv2]. 9. Acknowledgments The author would like to thank Liz Cullen (BAE Systems) for first illustrating the issue addressed in this specification. Dearlove Expires August 18, 2014 [Page 7] Internet-Draft NHDP Optimization February 2014 10. References [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", work in progress draft-ietf-manet-olsrv2-19, March 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. Author's Address Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom Phone: +44 1245 242194 Email: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ Dearlove Expires August 18, 2014 [Page 8]