doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7466.txt b/doc/rfc/rfc7466.txt
new file mode 100644
index 0000000..ffb84fe
--- /dev/null
+++ b/doc/rfc/rfc7466.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Dearlove
+Request for Comments: 7466                               BAE Systems ATC
+Updates: 6130, 7181                                           T. Clausen
+Category: Standards Track                       LIX, Ecole Polytechnique
+ISSN: 2070-1721                                               March 2015
+
+
+         An 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 updates RFC 6130 "Mobile Ad Hoc Network (MANET)
+   Neighborhood Discovery Protocol (NHDP)" and RFC 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 2015
+
+
+Status 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 in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://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 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
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................4
+   3. Applicability Statement .........................................4
+   4. Changes to NHDP .................................................4
+      4.1. Interface Information Bases ................................5
+      4.2. HELLO Message Processing ...................................5
+      4.3. Information Base Changes ...................................5
+      4.4. Constraints ................................................6
+   5. Changes to OLSRv2 ...............................................6
+   6. Security Considerations .........................................8
+   7. References ......................................................8
+      7.1. Normative References .......................................8
+      7.2. Informative References .....................................8
+   Acknowledgements ...................................................9
+   Authors' Addresses .................................................9
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 2]
+
+RFC 7466                    NHDP Optimization                 March 2015
+
+
+1.  Introduction
+
+   Section 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 2015
+
+
+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 = 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
+
+   In Section 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
+
+   In Section 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 in Section 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 in Section 13.2 MUST be performed before the
+   actions specified in Section 13.3 are performed for that Link Tuple.
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 5]
+
+RFC 7466                    NHDP Optimization                 March 2015
+
+
+   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 1 and renumber point
+   2 as point 1.
+
+4.4.  Constraints
+
+   In Appendix 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  In Section 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 (see Section 18.4), or the change is to or from
+         UNKNOWN_METRIC.
+
+   o  In Section 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  In Section 17.7 of [RFC7181], in the fifth bullet point, add "and
+      N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
+
+   o  In Section 18.4 of [RFC7181], in the third bullet point, add ",
+      N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
+
+   o  In Section 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  In Section 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  In Appendix 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.  References
+
+7.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", RFC
+              7181, 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 2015
+
+
+Acknowledgements
+
+   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]
+