draft-ietf-manet-nhdp-optimization-04.txt   rfc7466.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Internet Engineering Task Force (IETF) C. Dearlove
Internet-Draft BAE Systems ATC Request for Comments: 7466 BAE Systems ATC
Updates: 6130, 7181 T. Clausen Updates: 6130, 7181 T. Clausen
(if approved) LIX, Ecole Polytechnique Category: Standards Track LIX, Ecole Polytechnique
Intended status: Standards Track January 23, 2015 ISSN: 2070-1721 March 2015
Expires: July 27, 2015
An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) An Optimization for the Mobile Ad Hoc Network (MANET)
draft-ietf-manet-nhdp-optimization-04 Neighborhood Discovery Protocol (NHDP)
Abstract Abstract
The link quality mechanism of the MANET Neighborhood Discovery The link quality mechanism of the Mobile Ad Hoc Network (MANET)
Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop
measured link quality from that 1-hop neighbor is below an acceptable neighbors if the measured link quality from that 1-hop neighbor is
threshold, while still retaining the corresponding link information below an acceptable threshold while still retaining the corresponding
as acquired from HELLO message exchange. This allows immediate link information as acquired from the HELLO message exchange. This
reinstatement of the 1-hop neighbor if the link quality later allows immediate reinstatement of the 1-hop neighbor if the link
improves sufficiently. quality later improves sufficiently.
NHDP also collects information about symmetric 2-hop neighbors. NHDP also collects information about symmetric 2-hop neighbors.
However it specifies that if a link from a symmetric 1-hop neighbor However, it specifies that if a link from a symmetric 1-hop neighbor
ceases being symmetric, including while "ignored" as described above, ceases being symmetric, including while "ignored" (as described
then corresponding symmetric 2-hop neighbors are removed. This may above), then corresponding symmetric 2-hop neighbors are removed.
lead to symmetric 2-hop neighborhood information being permanently This may lead to symmetric 2-hop neighborhood information being
removed (until further HELLO messages are received) if the link permanently removed (until further HELLO messages are received) if
quality of a symmetric 1-hop neighbor drops below the acceptable the link quality of a symmetric 1-hop neighbor drops below the
threshold, even if only for a moment. acceptable threshold, even if only for a moment.
This specification updates RFC6130 "Mobile Ad Hoc Network (MANET) This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET)
Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized
Link State Routing Protocol version 2 (OLSRv2)" to permit, as an Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an
option, retaining, but ignoring, symmetric 2-hop information when the option, retaining, but ignoring, symmetric 2-hop information when the
link quality from the corresponding 1-hop neighbor drops below the link quality from the corresponding 1-hop neighbor drops below the
acceptable threshold. This allows immediate reinstatement of the acceptable threshold. This allows immediate reinstatement of the
symmetric 2-hop neighbor if the link quality later improves symmetric 2-hop neighbor if the link quality later improves
sufficiently, thus making the symmetric 2-hop neighborhood more sufficiently, thus making the symmetric 2-hop neighborhood more
"robust". "robust".
Status of this Memo 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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 27, 2015. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement .........................................4
4. Changes to NHDP . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Changes to NHDP .................................................4
4.1. Interface Information Bases . . . . . . . . . . . . . . . . 6 4.1. Interface Information Bases ................................5
4.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 6 4.2. HELLO Message Processing ...................................5
4.3. Information Base Changes . . . . . . . . . . . . . . . . . 6 4.3. Information Base Changes ...................................5
4.4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Constraints ................................................6
5. Changes to OLSRv2 . . . . . . . . . . . . . . . . . . . . . . . 7 5. Changes to OLSRv2 ...............................................6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations .........................................8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. References ......................................................8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References .......................................8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References .....................................8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 Acknowledgements ...................................................9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses .................................................9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], Section Section 14 of the MANET Neighborhood Discovery Protocol (NHDP)
14, contains a link admission mechanism known as "link quality" that [RFC6130] contains a link admission mechanism known as "link quality"
allows a router using that protocol to "take considerations other that allows a router using that protocol to "take considerations
than message exchange into account for determining when a link is and other than message exchange into account for determining when a link
is not a candidate for being considered as HEARD or SYMMETRIC". is and is not a candidate for being considered as HEARD or
Specifically, [RFC6130] permits a router to disallow consideration of SYMMETRIC." Specifically, [RFC6130] permits a router to disallow
some of its 1-hop neighbors, for as long as the quality of the link consideration of some of its 1-hop neighbors for as long as the
from that 1-hop neighbor is below an acceptable link quality quality of the link from that 1-hop neighbor is below an acceptable
threshold. link quality threshold.
A feature of this mechanism is that while the link quality remains A feature of this mechanism is that while the link quality remains
too low, the link information, established by the exchange of HELLO too low, the link information, established by the exchange of HELLO
messages, is retained. Thus if the link quality later goes above the messages, is retained. Thus, if the link quality later goes above
required threshold (note that a hysteresis mechanism means that two the required threshold (note that a hysteresis mechanism means that
thresholds are used) then the link is immediately established and two thresholds are used), then the link is immediately established
will be immediately available for use. and will be immediately available for use.
[RFC6130] collects not just 1-hop neighbor information, but also [RFC6130] collects not only 1-hop neighbor information, but also
information about symmetric 2-hop neighbors. However [RFC6130] information about symmetric 2-hop neighbors. However, [RFC6130]
specifies that if a 1-hop neighbor was, but no longer is, considered specifies that if a 1-hop neighbor was, but no longer is, considered
symmetric, then the corresponding 2-Hop Tuples that may have been symmetric, then the corresponding 2-Hop Tuples that may have been
recorded for that 2-hop neighbor, are to be removed, without a recorded for that 2-hop neighbor are to be removed without a
retention mechanism for a (possibly temporary) loss due to link retention mechanism for a (possibly temporary) loss due to link
quality. quality.
This means that if there is a short period in which link quality is 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 too low, then when the link quality is re-established all 1-hop
neighbor information is immediately available for use again. neighbor information is immediately available for use again.
However, the corresponding symmetric 2-hop neighbor information has However, the corresponding symmetric 2-hop neighbor information has
been removed, and is not available for use until restored by receipt been removed and is not available for use until restored by receipt
of the next corresponding HELLO message. of the next corresponding HELLO message.
This specification describes how [RFC6130] can be modified to avoid This specification describes how [RFC6130] can be modified to avoid
this situation, by retaining (but not using) 2-hop information, this situation by retaining (but not using) 2-hop information,
similar to what is done with 1-hop information. This modification is similar to what is done with 1-hop information. This modification is
strictly optional, and routers that do and do not implement it can strictly optional, and routers that do and do not implement it can
interwork entirely successfully (as they also can with different link interwork entirely successfully (as they also can with different link
quality specifications). In addition, by a suitable interpretation quality specifications). In addition, by a suitable interpretation
(that ignored 2-Hop Tuples are not externally advertised), this (that ignored 2-Hop Tuples are not externally advertised), this
change can be invisible to any other protocols using [RFC6130], in change can be invisible to any other protocols using [RFC6130], in
particular [RFC7181]. However the impact on [RFC7181] when 2-Hop particular [RFC7181]. However, the impact on [RFC7181] when 2-Hop
Tuples are not so handled is also described, in particular owing to Tuples are not so handled is also described (owing to the existence
the existence of implementations of that protocol that are not of implementations of that protocol that are not modularly separated
modularly separated from [RFC6130]. from [RFC6130]).
This specification therefore updates [RFC6130] and [RFC7181]. This specification therefore updates [RFC6130] and [RFC7181].
This update to [RFC6130] does not change the definition of a This update to [RFC6130] does not change the definition of a
symmetric 2-hop neighbor, but adds new state information to each symmetric 2-hop neighbor but adds new state information to each 2-Hop
2-Hop Tuple of [RFC6130]. This is to retain some 2-hop neighbor Tuple of [RFC6130]. This is to retain some 2-hop neighbor
information, while recording it as currently not to be used. The new information while recording it as currently not to be used. The new
state information and retained 2-Hop Tuples are reflected in the state information and retained 2-Hop Tuples are reflected in the
corresponding tables of the updated NHDP-MIB module [RFC6779bis]. corresponding tables of the updated NHDP-MIB module [NHDP-MIB].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the terminology of [RFC6130] and Additionally, this document uses the terminology of [RFC6130] and
[RFC7181]. [RFC7181].
3. Applicability Statement 3. Applicability Statement
This specification updates [RFC6130]. The optimization presented in This specification updates [RFC6130]. The optimization presented in
this specification is simply permissive, as it allows retaining this specification is simply permissive, as it allows retaining
information which otherwise would have been removed, but does not use information that otherwise would have been removed but does not use
that information except when it could have been used by [RFC6130]. that information except when it could have been used by [RFC6130].
This can, in some cases, ensure that the symmetric 2-hop neighborhood This can, in some cases, ensure that the symmetric 2-hop neighborhood
is more robust against temporary link quality changes, and is more robust against temporary link quality changes and
consequently yield a more stable network. The only other consequence consequently yields a more stable network. The only other
of this optimization is that state for some otherwise expired 2-Hop consequence of this optimization is that state for some otherwise
Tuples may be maintained for longer. expired 2-Hop Tuples may be maintained for longer.
This specification also updates [RFC7181]. This could have been This specification also updates [RFC7181]. This could have been
avoided by this specification describing how the updates to [RFC6130] avoided had instead [RFC6130] been updated so as to make the changes
may be handled so as to be invisible to any other protocol using it. to it invisible to any other protocol using it. However, as it is
However, as it is known that some implementations of [RFC7181] are known that some implementations of [RFC7181] are not independent of
not independent of the implementation of [RFC6130] that they use, it the implementation of [RFC6130] that they use, it is useful to
is useful to indicate the direct impact on [RFC7181]. indicate the direct impact on [RFC7181].
A router that implements the optimization described in this A router that implements the optimization described in this
specification will interoperate successfully with routers that specification will interoperate successfully with routers that
implement [RFC6130], but do not implement this optimization. implement [RFC6130] but do not implement this optimization.
4. Changes to NHDP 4. Changes to NHDP
The following changes are made to [RFC6130] if using this The following changes are made to [RFC6130] if using this
specification. Note that while this specification is OPTIONAL, if specification. Note that while this specification is OPTIONAL, if
any of these changes are made then all of these changes MUST be made. any of these changes are made, then all of these changes MUST be
made.
4.1. Interface Information Bases 4.1. Interface Information Bases
The 2-Hop Set is modified by adding this additional element to each The 2-Hop Set is modified by adding this additional element to each
2-Hop Tuple: 2-Hop Tuple:
N2_lost is a boolean flag, which indicates the state of the N2_lost is a boolean flag, which indicates the state of the
corresponding Link Tuple. If L_status = SYMMETRIC (and thus corresponding Link Tuple. If L_status = SYMMETRIC (and thus
L_lost = false), then N2_lost = false. If L_SYM_time has not L_lost = false), then N2_lost = false. If L_SYM_time has not
expired, and L_lost = true (and hence L_status = LOST), then expired, and L_lost = true (and hence L_status = LOST), then
N2_lost = true. N2_lost = true.
In all other cases, including other cases with L_status = LOST, there In all other cases, including other cases with L_status = LOST, there
will be no such 2-Hop Tuples. will be no such 2-Hop Tuples.
4.2. HELLO Message Processing 4.2. HELLO Message Processing
In Section 12.6 of [RFC6130] make the following changes: In Section 12.6 of [RFC6130], make the following changes:
o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not
expired". expired".
o When creating a 2-Hop Tuple, set N2_lost := L_lost. 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 4.3. Information Base Changes
In Section 13, replace the second bullet point by: In Section 13, replace the second bullet point with:
o A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time 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 expires, or the Link Tuple is removed. In this case, the actions
specified in Section 13.2 are performed. specified in Section 13.2 are performed.
and replace the paragraph after the bullet points by: Replace the paragraph after the bullet points with:
If a Link Tuple is removed, or if L_HEARD_time expires and either 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 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.2 MUST be performed before the
actions specified in Section 13.3 are performed for that Link Tuple. actions specified in Section 13.3 are performed for that Link Tuple.
In Section 13.2 of [RFC6130], add the following, before all other In Section 13.2 of [RFC6130], add the following before all other
text: text:
For each Link Tuple that has L_SYM_time not expired: 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. 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: 1. Remove each 2-Hop Tuple for the same MANET interface with:
+ N2_neighbor_iface_addr_list contains one or more network + N2_neighbor_iface_addr_list contains one or more network
addresses in L_neighbor_iface_addr_list. addresses in L_neighbor_iface_addr_list.
skipping to change at page 7, line 20 skipping to change at page 6, line 27
2. If L_status then changes from SYMMETRIC to LOST because L_lost is 2. If L_status then changes from SYMMETRIC to LOST because L_lost is
set to true: set to true:
1. For each 2-Hop Tuple for the same MANET interface with: 1. For each 2-Hop Tuple for the same MANET interface with:
+ N2_neighbor_iface_addr_list contains one or more network + N2_neighbor_iface_addr_list contains one or more network
addresses in L_neighbor_iface_addr_list; addresses in L_neighbor_iface_addr_list;
set N2_lost := true. set N2_lost := true.
Also in Section 13.2 of [RFC6130], remove point 2, renumbering point Also, in Section 13.2 of [RFC6130], remove point 1 and renumber point
2 as point 1. 2 as point 1.
4.4. Constraints 4.4. Constraints
In Appendix B, under "In each 2-Hop Tuple:" change the first bullet In Appendix B of [RFC6130], under "In each 2-Hop Tuple:", change the
point to: first bullet point to:
o There MUST be a Link Tuple associated with the same MANET o There MUST be a Link Tuple associated with the same MANET
interface with: interface with:
* L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_SYM_time not expired; AND * L_SYM_time not expired; AND
* L_lost = N2_lost. * L_lost = N2_lost.
5. Changes to OLSRv2 5. Changes to OLSRv2
If the implementation of [RFC6130] conceals from any protocol using If the implementation of [RFC6130] conceals from any protocol using
it the existence of all 2-Hop Tuples with N2_lost = true, then no it the existence of all 2-Hop Tuples with N2_lost = true, then no
changes are required to any protocol using [RFC6130], in particular changes are required to any protocol using [RFC6130]; in particular,
no changes are required to [RFC7181]. no changes are required to [RFC7181].
However if instead the implementation of [RFC6130] makes all 2-Hop However, if instead the implementation of [RFC6130] makes all 2-Hop
Tuples visible, including those with N2_lost = true, then protocols Tuples visible, including those with N2_lost = true, then protocols
using [RFC6130] MUST ignore such 2-Hop Tuples. using [RFC6130] MUST ignore such 2-Hop Tuples.
For [RFC7181], given that this protocol uses 2-hop information for For [RFC7181], given that this protocol uses 2-hop information for
MPR Set and Routing Set calculation, but not includes that Multipoint Relay (MPR) Set and Routing Set calculation but does not
information in control traffic, this means that an implementation include that information in control traffic, this means that an
must be (i) behaving as if a 2-Hop Tuple only exists if implementation must be behaving (i) as if a 2-Hop Tuple only exists
N2_lost=false, and (ii) as if a change of N2_lost (from false to 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 true, or true to false) corresponds to a 2-Hop Tuple appearing or
being removed. Specifically, this means behaving as if all of the being removed. Specifically, this means behaving as if all of the
following changes were to be made to [RFC7181]: following changes were to be made to [RFC7181]:
o In Section 17.6 of [RFC7181], point 1, replace the final two o In Section 17.6 of [RFC7181], point 1, replace the final two
bullet points with: bullet points with:
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost
= false is added or removed, OR; = false is added or removed; OR
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost
changed, OR; changed; OR
* The N2_out_metric of any 2-Hop Tuple with N2_lost = false * The N2_out_metric of any 2-Hop Tuple with N2_lost = false
changes, and either the flooding MPR selection process uses changes, and either the flooding MPR selection process uses
metric values (see Section 18.4) or the change is to or from metric values (see Section 18.4), or the change is to or from
UNKNOWN_METRIC. UNKNOWN_METRIC.
o In Section 17.6 of [RFC7181], point 3, replace the final two o In Section 17.6 of [RFC7181], point 3, replace the final two
bullet points with: bullet points with:
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost =
false is added or removed, OR; false is added or removed; OR
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost
changed, OR; changed; OR
* The N2_in_metric of any 2-Hop Tuple with N2_lost = false * The N2_in_metric of any 2-Hop Tuple with N2_lost = false
changes. changes.
o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and
N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o In Section 18.4 of [RFC7181], in the third bullet point, add ", o In Section 18.4 of [RFC7181], in the third bullet point, add ",
N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o In Section 18.5 of [RFC7181], in the third bullet point, add ", o In Section 18.5 of [RFC7181], in the third bullet point, add ",
N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC". N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".
o In Section 19.1 of [RFC7181], in the final main bullet point o In Section 19.1 of [RFC7181], in the final main bullet point
(marked as "(OPTIONAL)"), add "and N2_lost = false" after (marked as "(OPTIONAL)"), add "and N2_lost = false" after
"N2_out_metric != UNKNOWN_METRIC". "N2_out_metric != UNKNOWN_METRIC".
o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost =
false" after "N2_out_metric != UNKNOWN_METRIC". false" after "N2_out_metric != UNKNOWN_METRIC".
6. IANA Considerations 6. Security Considerations
This document has no actions for IANA.
[This section may be removed by the RFC Editor.]
7. Security Considerations
The update to [RFC6130] enables the retention and reuse of some The update to [RFC6130] enables the retention and reuse of some
information collected by that protocol, for only the duration that it information collected by that protocol, for only the duration that it
could have been used in any case. As such, this protocol introduces could have been used in any case. As such, this protocol introduces
no new security considerations to an implementation of [RFC6130] or no new security considerations to an implementation of [RFC6130] or
of any other protocol that uses it, such as [RFC7181]. of any other protocol that uses it, such as [RFC7181].
8. Acknowledgments 7. References
The authors would like to thank Liz Cullen (BAE Systems) for first
illustrating the issue addressed in this specification.
9. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011,
<http://www.rfc-editor.org/info/rfc6130>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol Version 2", RFC
RFC 7181, April 2014. 7181, April 2014,
<http://www.rfc-editor.org/info/rfc7181>.
9.2. Informative References 7.2. Informative References
[RFC6779bis] [Err4276] RFC Errata, Errata ID 4276, RFC 6130.
[NHDP-MIB]
Herberg, U., Cole, R., Chakeres, I., and T. Clausen, Herberg, U., Cole, R., Chakeres, I., and T. Clausen,
"Definition of Managed Objects for the Neighborhood "Definition of Managed Objects for the Neighborhood
Discovery Protocol", draft-ietf-manet-rfc6779bis (work in Discovery Protocol", Work in Progress, draft-ietf-manet-
progress), August 2014. rfc6779bis, August 2014.
Acknowledgements
The authors would like to thank Liz Cullen (BAE Systems) for first
illustrating the issue addressed in this specification.
Authors' Addresses Authors' Addresses
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
 End of changes. 53 change blocks. 
136 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/