1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
|
<pre>Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7466 BAE Systems ATC
Updates: <a href="./rfc6130">6130</a>, <a href="./rfc7181">7181</a> T. Clausen
Category: Standards Track LIX, Ecole Polytechnique
ISSN: 2070-1721 March 2015
<span class="h1">An Optimization for the Mobile Ad Hoc Network (MANET)</span>
<span class="h1">Neighborhood Discovery Protocol (NHDP)</span>
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 <a href="./rfc6130">RFC 6130</a> "Mobile Ad Hoc Network (MANET)
Neighborhood Discovery Protocol (NHDP)" and <a href="./rfc7181">RFC 7181</a> "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".
<span class="grey">Dearlove & Clausen Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7466">http://www.rfc-editor.org/info/rfc7466</a>.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Applicability Statement .........................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Changes to NHDP .................................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Interface Information Bases ................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. HELLO Message Processing ...................................<a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Information Base Changes ...................................<a href="#page-5">5</a>
<a href="#section-4.4">4.4</a>. Constraints ................................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Changes to OLSRv2 ...............................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-7.2">7.2</a>. Informative References .....................................<a href="#page-8">8</a>
Acknowledgements ...................................................<a href="#page-9">9</a>
Authors' Addresses .................................................<a href="#page-9">9</a>
<span class="grey">Dearlove & Clausen Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="#section-14">Section 14</a> of the MANET Neighborhood Discovery Protocol (NHDP)
[<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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, [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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.
[<a id="ref-RFC6130">RFC6130</a>] collects not only 1-hop neighbor information, but also
information about symmetric 2-hop neighbors. However, [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]
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 [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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 [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>], in
particular [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]. However, the impact on [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] 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 [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]).
This specification therefore updates [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>].
<span class="grey">Dearlove & Clausen Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
This update to [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] does not change the definition of a
symmetric 2-hop neighbor but adds new state information to each 2-Hop
Tuple of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]. 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 [<a href="#ref-NHDP-MIB">NHDP-MIB</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
Additionally, this document uses the terminology of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and
[<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Applicability Statement</span>
This specification updates [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]. 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 [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>].
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 [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]. This could have been
avoided had instead [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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 [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] are not independent of
the implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] that they use, it is useful to
indicate the direct impact on [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>].
A router that implements the optimization described in this
specification will interoperate successfully with routers that
implement [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] but do not implement this optimization.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Changes to NHDP</span>
The following changes are made to [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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.
<span class="grey">Dearlove & Clausen Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Interface Information Bases</span>
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.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. HELLO Message Processing</span>
In <a href="./rfc6130#section-12.6">Section 12.6 of [RFC6130]</a>, 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 [<a href="#ref-Err4276" title="Errata ID 4276">Err4276</a>].)
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Information Base Changes</span>
In <a href="#section-13">Section 13</a>, 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 <a href="#section-13.2">Section 13.2</a> 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 <a href="#section-13.2">Section 13.2</a> MUST be performed before the
actions specified in <a href="#section-13.3">Section 13.3</a> are performed for that Link Tuple.
<span class="grey">Dearlove & Clausen Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
In <a href="./rfc6130#section-13.2">Section 13.2 of [RFC6130]</a>, 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 <a href="./rfc6130#section-13.2">Section 13.2 of [RFC6130]</a>, remove point 1 and renumber point
2 as point 1.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Constraints</span>
In <a href="./rfc6130#appendix-B">Appendix B of [RFC6130]</a>, 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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Changes to OLSRv2</span>
If the implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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 [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]; in particular,
no changes are required to [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>].
<span class="grey">Dearlove & Clausen Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
However, if instead the implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] makes all 2-Hop
Tuples visible, including those with N2_lost = true, then protocols
using [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] MUST ignore such 2-Hop Tuples.
For [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>], 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 [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]:
o In <a href="./rfc7181#section-17.6">Section 17.6 of [RFC7181]</a>, 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 <a href="#section-18.4">Section 18.4</a>), or the change is to or from
UNKNOWN_METRIC.
o In <a href="./rfc7181#section-17.6">Section 17.6 of [RFC7181]</a>, 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 <a href="./rfc7181#section-17.7">Section 17.7 of [RFC7181]</a>, in the fifth bullet point, add "and
N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o In <a href="./rfc7181#section-18.4">Section 18.4 of [RFC7181]</a>, in the third bullet point, add ",
N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o In <a href="./rfc7181#section-18.5">Section 18.5 of [RFC7181]</a>, in the third bullet point, add ",
N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".
<span class="grey">Dearlove & Clausen Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
o In <a href="./rfc7181#section-19.1">Section 19.1 of [RFC7181]</a>, in the final main bullet point
(marked as "(OPTIONAL)"), add "and N2_lost = false" after
"N2_out_metric != UNKNOWN_METRIC".
o In <a href="./rfc7181#appendix-C.7">Appendix C.7 of [RFC7181]</a>, in point 1, add "and N2_lost =
false" after "N2_out_metric != UNKNOWN_METRIC".
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The update to [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] 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 [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] or
of any other protocol that uses it, such as [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC6130">RFC6130</a>] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
<a href="./rfc6130">RFC 6130</a>, April 2011,
<<a href="http://www.rfc-editor.org/info/rfc6130">http://www.rfc-editor.org/info/rfc6130</a>>.
[<a id="ref-RFC7181">RFC7181</a>] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", <a href="./rfc7181">RFC</a>
<a href="./rfc7181">7181</a>, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7181">http://www.rfc-editor.org/info/rfc7181</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-Err4276">Err4276</a>] RFC Errata, Errata ID 4276, <a href="./rfc6130">RFC 6130</a>.
[<a id="ref-NHDP-MIB">NHDP-MIB</a>]
Herberg, U., Cole, R., Chakeres, I., and T. Clausen,
"Definition of Managed Objects for the Neighborhood
Discovery Protocol", Work in Progress, <a href="./draft-ietf-manet-rfc6779bis">draft-ietf-manet-</a>
<a href="./draft-ietf-manet-rfc6779bis">rfc6779bis</a>, August 2014.
<span class="grey">Dearlove & Clausen Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7466">RFC 7466</a> NHDP Optimization March 2015</span>
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: <a href="http://www.baesystems.com/">http://www.baesystems.com/</a>
Thomas Heide Clausen
LIX, Ecole Polytechnique
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: <a href="http://www.ThomasClausen.org/">http://www.ThomasClausen.org/</a>
Dearlove & Clausen Standards Track [Page 9]
</pre>
|
