Movatterモバイル変換

Internet Engineering Task Force (IETF)                       C. DearloveRequest for Comments: 7466                               BAE Systems ATCUpdates:6130,7181                                           T. ClausenCategory: Standards Track                       LIX, Ecole PolytechniqueISSN: 2070-1721                                               March 2015An Optimization for the Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP)Abstract   The link quality mechanism of the Mobile Ad Hoc Network (MANET)   Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop   neighbors if the measured link quality from that 1-hop neighbor is   below an acceptable threshold while still retaining the corresponding   link information as acquired from the HELLO message exchange.  This   allows immediate reinstatement of the 1-hop neighbor if the link   quality later improves sufficiently.   NHDP also collects information about symmetric 2-hop neighbors.   However, it specifies that if a link from a symmetric 1-hop neighbor   ceases being symmetric, including while "ignored" (as described   above), then corresponding symmetric 2-hop neighbors are removed.   This may lead to symmetric 2-hop neighborhood information being   permanently removed (until further HELLO messages are received) if   the link quality of a symmetric 1-hop neighbor drops below the   acceptable threshold, even if only for a moment.   This specification updatesRFC 6130 "Mobile Ad Hoc Network (MANET)   Neighborhood Discovery Protocol (NHDP)" andRFC 7181 "The Optimized   Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an   option, retaining, but ignoring, symmetric 2-hop information when the   link quality from the corresponding 1-hop neighbor drops below the   acceptable threshold.  This allows immediate reinstatement of the   symmetric 2-hop neighbor if the link quality later improves   sufficiently, thus making the symmetric 2-hop neighborhood more   "robust".Dearlove & Clausen           Standards Track                    [Page 1]

RFC 7466                    NHDP Optimization                 March 2015Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7466.Copyright Notice   Copyright (c) 2015 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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   described in the Simplified BSD License.Table of Contents1. Introduction ....................................................32. Terminology .....................................................43. Applicability Statement .........................................44. Changes to NHDP .................................................44.1. Interface Information Bases ................................54.2. HELLO Message Processing ...................................54.3. Information Base Changes ...................................54.4. Constraints ................................................65. Changes to OLSRv2 ...............................................66. Security Considerations .........................................87. References ......................................................87.1. Normative References .......................................87.2. Informative References .....................................8   Acknowledgements ...................................................9   Authors' Addresses .................................................9Dearlove & Clausen           Standards Track                    [Page 2]

RFC 7466                    NHDP Optimization                 March 20151.  IntroductionSection 14 of the MANET Neighborhood Discovery Protocol (NHDP)   [RFC6130] contains a link admission mechanism known as "link quality"   that allows a router using that protocol to "take considerations   other than message exchange into account for determining when a link   is and is not a candidate for being considered as HEARD or   SYMMETRIC."  Specifically, [RFC6130] permits a router to disallow   consideration of some of its 1-hop neighbors for as long as the   quality of the link from that 1-hop neighbor is 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 later goes above   the required threshold (note that a hysteresis mechanism means that   two thresholds are used), then the link is immediately established   and will be immediately available for use.   [RFC6130] collects not only 1-hop neighbor information, but also   information about symmetric 2-hop neighbors.  However, [RFC6130]   specifies that if a 1-hop neighbor was, but no longer is, considered   symmetric, then the corresponding 2-Hop Tuples that may have been   recorded for that 2-hop neighbor are to be 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 re-established all 1-hop   neighbor information is immediately available for use again.   However, the corresponding symmetric 2-hop neighbor information has   been removed and is not available for use until restored by receipt   of the next corresponding HELLO message.   This specification describes how [RFC6130] can be modified to avoid   this situation by retaining (but not using) 2-hop information,   similar to what is done with 1-hop information.  This modification 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   (that ignored 2-Hop Tuples are not externally advertised), this   change can be invisible to any other protocols using [RFC6130], in   particular [RFC7181].  However, the impact on [RFC7181] when 2-Hop   Tuples are not so handled is also described (owing to the existence   of implementations of that protocol that are not modularly separated   from [RFC6130]).   This specification therefore updates [RFC6130] and [RFC7181].Dearlove & Clausen           Standards Track                    [Page 3]

RFC 7466                    NHDP Optimization                 March 2015   This update to [RFC6130] does not change the definition of a   symmetric 2-hop neighbor but adds new state information to each 2-Hop   Tuple of [RFC6130].  This is to retain some 2-hop neighbor   information while recording it as currently not to be used.  The new   state information and retained 2-Hop Tuples are reflected in the   corresponding tables of the updated NHDP-MIB module [NHDP-MIB].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   [RFC7181].3.  Applicability Statement   This specification updates [RFC6130].  The optimization presented in   this specification is simply permissive, as it allows retaining   information that otherwise would have been removed but does not use   that information except when it could have been used by [RFC6130].   This can, in some cases, ensure that the symmetric 2-hop neighborhood   is more robust against temporary link quality changes and   consequently yields a more stable network.  The only other   consequence of this optimization is that state for some otherwise   expired 2-Hop Tuples may be maintained for longer.   This specification also updates [RFC7181].  This could have been   avoided had instead [RFC6130] been updated so as to make the changes   to it invisible to any other protocol using it.  However, as it is   known that some implementations of [RFC7181] are not independent of   the implementation of [RFC6130] that they use, it is useful to   indicate the direct impact on [RFC7181].   A router that implements the optimization described in this   specification will interoperate successfully with routers that   implement [RFC6130] but do not implement 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.Dearlove & Clausen           Standards Track                    [Page 4]

RFC 7466                    NHDP Optimization                 March 20154.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 = true (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   InSection 12.6 of [RFC6130], make the following changes:   o  In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not      expired".   o  In point 2, point 1, point 1, under "then create a 2-Hop Tuple      with:", add a second bullet point "N2_lost: = L_lost".  (Note that      "2-Hop Neighbor Tuple" has been corrected here to "2-Hop Tuple"      per [Err4276].)4.3.  Information Base Changes   InSection 13, replace the second bullet point with:   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 inSection 13.2 are performed.   Replace the paragraph after the bullet points with:   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 inSection 13.2 MUST be performed before the   actions specified inSection 13.3 are performed for that Link Tuple.Dearlove & Clausen           Standards Track                    [Page 5]

RFC 7466                    NHDP Optimization                 March 2015   InSection 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, inSection 13.2 of [RFC6130], remove point 1 and renumber point   2 as point 1.4.4.  Constraints   InAppendix B of [RFC6130], 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 [RFC7181].Dearlove & Clausen           Standards Track                    [Page 6]

RFC 7466                    NHDP Optimization                 March 2015   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 [RFC7181], given that this protocol uses 2-hop information for   Multipoint Relay (MPR) Set and Routing Set calculation but does not   include that information in control traffic, this means that an   implementation must be behaving (i) as if a 2-Hop Tuple only exists   if N2_lost=false and (ii) as if a change of N2_lost (from false to   true, or true to false) corresponds to a 2-Hop Tuple appearing or   being removed.  Specifically, this means behaving as if all of the   following changes were to be made to [RFC7181]:   o  InSection 17.6 of [RFC7181], 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 (seeSection 18.4), or the change is to or from         UNKNOWN_METRIC.   o  InSection 17.6 of [RFC7181], 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      *  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  InSection 17.7 of [RFC7181], in the fifth bullet point, add "and      N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".   o  InSection 18.4 of [RFC7181], in the third bullet point, add ",      N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".   o  InSection 18.5 of [RFC7181], in the third bullet point, add ",      N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".Dearlove & Clausen           Standards Track                    [Page 7]

RFC 7466                    NHDP Optimization                 March 2015   o  InSection 19.1 of [RFC7181], in the final main bullet point      (marked as "(OPTIONAL)"), add "and N2_lost = false" after      "N2_out_metric != UNKNOWN_METRIC".   o  InAppendix C.7 of [RFC7181], in point 1, add "and N2_lost =      false" after "N2_out_metric != UNKNOWN_METRIC".6.  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 [RFC7181].7.  References7.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997,              <http://www.rfc-editor.org/info/rfc2119>.   [RFC6130]  Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc              Network (MANET) Neighborhood Discovery Protocol (NHDP)",RFC 6130, April 2011,              <http://www.rfc-editor.org/info/rfc6130>.   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,              "The Optimized Link State Routing Protocol Version 2",RFC7181, April 2014,              <http://www.rfc-editor.org/info/rfc7181>.7.2.  Informative References   [Err4276]  RFC Errata, Errata ID 4276,RFC 6130.   [NHDP-MIB]              Herberg, U., Cole, R., Chakeres, I., and T. Clausen,              "Definition of Managed Objects for the Neighborhood              Discovery Protocol", Work in Progress,draft-ietf-manet-rfc6779bis, August 2014.Dearlove & Clausen           Standards Track                    [Page 8]

RFC 7466                    NHDP Optimization                 March 2015Acknowledgements   The authors would like to thank Liz Cullen (BAE Systems) for first   illustrating the issue addressed in this specification.Authors' Addresses   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/   Thomas Heide Clausen   LIX, Ecole Polytechnique   Phone: +33 6 6058 9349   EMail: T.Clausen@computer.org   URI:http://www.ThomasClausen.org/Dearlove & Clausen           Standards Track                    [Page 9]