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
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Network Working Group T. Clausen
Request for Comments: 5148 LIX, Ecole Polytechnique, France
Category: Informational C. Dearlove
BAE Systems Advanced Technology Centre
B. Adamson
U.S. Naval Research Laboratory
February 2008
<span class="h1">Jitter Considerations in Mobile Ad Hoc Networks (MANETs)</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document provides recommendations for jittering (randomly
modifying timing) of control traffic transmissions in Mobile Ad hoc
NETwork (MANET) routing protocols to reduce the probability of
transmission collisions.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Applicability Statement .........................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Protocol Overview and Functioning ...............................<a href="#page-4">4</a>
<a href="#section-5">5</a>. Jitter ..........................................................<a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. Periodic Message Generation ................................<a href="#page-5">5</a>
<a href="#section-5.2">5.2</a>. Externally Triggered Message Generation ....................<a href="#page-6">6</a>
<a href="#section-5.3">5.3</a>. Message Forwarding .........................................<a href="#page-7">7</a>
<a href="#section-5.4">5.4</a>. Maximum Jitter Determination ...............................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-10">10</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-10">10</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgements ......................................<a href="#page-11">11</a>
<span class="grey">Clausen, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In a wireless network, simultaneous packet transmission by nearby
nodes is often undesirable. This is because any resulting collision
between these packets may cause a receiving node to fail to receive
some or all of these packets. This is a physical problem, which
occurs before packets can be inserted into the receiver queue.
Depending on the characteristics of the medium access control and
other lower layer mechanisms, in particular whether retransmission of
unacknowledged packets is supported, this may cause at best increased
delay, and at worst complete packet loss. In some instances, these
problems can be solved in these lower layers, but in other instances,
some help at the network and higher layers is necessary.
This document considers the case when that help is required, and
provides recommendations for using jitter (randomly varying timing)
to provide it. It is possible that the techniques described here
could be implemented either by IP protocols designed for wireless
networks or in conjunction with lower-layer mechanisms.
The problems of simultaneous packet transmissions are amplified if
any of the following features are present in a protocol:
Regularly scheduled messages - If two nodes generate packets
containing regularly scheduled messages of the same type at the
same time, and if, as is typical, they are using the same message
interval, all further transmissions of these messages will thus
also be at the same time. Note that the following mechanisms may
make this a likely occurrence.
Event-triggered messages - If nodes respond to changes in their
circumstances, in particular changes in their neighborhood, with
an immediate message generation and transmission, then two nearby
nodes that respond to the same change will transmit messages
simultaneously.
Schedule reset - When a node sends an event-triggered message of a
type that is usually regularly scheduled, then there is no
apparent reason why it should not restart its corresponding
message schedule. This may result in nodes responding to the same
change also sending future messages simultaneously.
Forwarding - If nodes forward messages they receive from other nodes,
then nearby nodes will commonly receive and forward the same
message. If forwarding is performed immediately, then the
resulting packet transmissions may interfere with each other.
<span class="grey">Clausen, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
A possible solution to these problems is to employ jitter, a
deliberate random variation in timing. Such jitter is employed in
e.g., [<a href="#ref-2" title=""OSPF Database Overflow"">2</a>], [<a href="#ref-3" title=""Host Group Extensions for CLNP Multicasting"">3</a>], and [<a href="#ref-4" title=""A Border Gateway Protocol 4 (BGP-4)"">4</a>], in which transmission intervals for
regularly scheduled messages are reduced by a small, bounded and
random amount in order to desynchronize transmitters and thereby
avoid overloading the transmission medium as well as receivers. This
document discusses and provides recommendations for applying jitter
to control packet transmissions in Mobile Ad hoc NETworks (MANETs),
with the purpose of avoiding collisions, with particular reference to
the features listed above.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
Additionally, this document uses the following terminology:
Node - A MANET router that implements a message sending protocol.
MANET interface - A network device participating in a MANET. A node
may have one or more MANET interfaces.
Message - An entity carrying protocol information intended for
exchange between nodes. Messages are transmitted over MANET
interfaces embedded in packets.
Packet - An entity embedding zero or more messages for transmission
over a MANET interface of the node.
Transmission - A packet being sent over a MANET interface of the
node. A transmission can be due to either a message being
generated or a message being forwarded.
Generation - Creation of a new message (rather than a received and
forwarded message) for transmission over one or more MANET
interfaces of the node. Typically, a node will generate messages
based on a message schedule (periodic or otherwise) or as a
response to changes in circumstances.
Forwarding - Retransmission of a received message (whether modified
or unchanged) over one or more MANET interfaces of the node.
Collision - A specific instance of interference, where two or more
nodes transmit a packet at the same time and within the same
signal space (at the same frequency and/or encoding) such that
<span class="grey">Clausen, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
another, closely located, node that should receive and decode
these packets instead fails to do so, and loses one or more of the
packets.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Applicability Statement</span>
The mechanisms described in this document are applicable to the
control messages of any MANET protocol in which simultaneous
transmissions by different nodes are undesirable, and that contains
mechanisms, such as periodic control message transmission, triggered
control message transmission, or control message forwarding, which
either make a simultaneous transmission more likely, or cause one to
be repeated when it occurs. This particularly applies to protocols
using broadcast transmissions in wireless networks, where proactive
MANET routing protocols such as [<a href="#ref-5" title=""Optimized Link State Routing Protocol (OLSR)"">5</a>] employ scheduled messages, where
reactive MANET routing protocols such as [<a href="#ref-6" title=""Ad hoc On-Demand Distance Vector (AODV) Routing"">6</a>] employ event-triggered
messages, and where both employ message forwarding.
These mechanisms are intended for application where the underlying
medium access control and lower layers do not provide effective
mechanisms to avoid such collisions. Where these layers do provide
effective mechanisms, the recommendations of this document are not
needed.
The approach described in this document uses random variations in
timing to achieve a reduction in collisions. Alternatives using, for
example, pseudo-random variation based on node identity, may be
considered, but are not discussed by this document.
Any protocol based on [<a href="#ref-7" title=""Generalized MANET Packet/Message Format"">7</a>] and using the message forwarding mechanism
facilitated by that structure is a particular candidate for
application of at least some of these mechanisms.
The document has been generalized from the jitter mechanism used in
the proactive MANET routing protocol OLSR (the Optimized Link State
Routing Protocol) [<a href="#ref-5" title=""Optimized Link State Routing Protocol (OLSR)"">5</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Overview and Functioning</span>
This document provides recommendations for message transmission (and
retransmission) that may be used by MANET routing protocols. It may
also be used by other protocols that employ a periodic or triggered
message schedule running over wireless interfaces. Using such
simultaneous message transmissions from two (or more) adjacent nodes
may cause delays, packet losses, and other problems. Any protocol
using jitter as outlined here must specify its precise usage insofar
as is necessary for interoperability.
<span class="grey">Clausen, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Jitter</span>
In order to prevent nodes in a MANET from simultaneous transmission,
whilst retaining the MANET characteristic of maximum node autonomy, a
randomization of the transmission time of packets by nodes, known as
jitter, SHOULD be employed. Three jitter mechanisms, which target
different aspects of this problem, SHOULD be employed, with the aim
of reducing the likelihood of simultaneous transmission, and, if it
occurs, preventing it from continuing.
Three cases exist:
o Periodic message generation;
o Externally triggered message generation;
o Message forwarding.
For the first of these cases, jitter is used to reduce the interval
between successive message transmission by a random amount; for the
latter two cases, jitter is used to delay a message being generated
or forwarded by a random amount.
Each of these cases uses a parameter, denoted MAXJITTER, for the
maximum timing variation that it introduces. If more than one of
these cases is used by a protocol, it MAY use the same or a different
value of MAXJITTER for each case. It also MAY use the same or
different values of MAXJITTER according to message type, and under
different circumstances -- in particular if other parameters (such as
message interval) vary.
Issues relating to the value of MAXJITTER are considered in <a href="#section-5.4">Section</a>
<a href="#section-5.4">5.4</a>.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Periodic Message Generation</span>
When a node generates a message periodically, two successive messages
will be separated by a well-defined interval, denoted
MESSAGE_INTERVAL. A node MAY maintain more than one such interval,
e.g., for different message types or in different circumstances (such
as backing off transmissions to avoid congestion). Jitter SHOULD be
applied by reducing this delay by a random amount, so that the delay
between consecutive transmissions of messages of the same type is
equal to (MESSAGE_INTERVAL - jitter), where jitter is the random
value.
Subtraction of the random value from the message interval ensures
that the message interval never exceeds MESSAGE_INTERVAL, and does
<span class="grey">Clausen, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
not adversely affect timeouts or other mechanisms that may be based
on message late arrival or failure to arrive. By basing the message
transmission time on the previous transmission time, rather than by
jittering a fixed clock, nodes can become completely desynchronized,
which minimizes their probability of repeated collisions. This is
particularly useful when combined with externally triggered message
generation and rescheduling.
The jitter value SHOULD be generated uniformly in an interval between
zero and MAXJITTER.
Note that a node will know its own MESSAGE_INTERVAL value and can
readily ensure that any MAXJITTER value used satisfies the conditions
in <a href="#section-5.4">Section 5.4</a>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Externally Triggered Message Generation</span>
An internal or external condition or event may trigger message
generation by a node. Depending upon the protocol, this condition
may trigger generation of a single message (including, but not
limited to, an acknowledgement message), initiation of a new periodic
message schedule, or rescheduling of existing periodic messaging.
Collision between externally triggered messages is made more likely
if more than one node is likely to respond to the same event. To
reduce this likelihood, an externally triggered message SHOULD be
jittered by delaying it by a random duration; an internally triggered
message MAY also be so jittered if appropriate. This delay SHOULD be
generated uniformly in an interval between zero and MAXJITTER. If
periodically transmitted messages are rescheduled, then this SHOULD
be based on this delayed time, with subsequent messages treated as
described in <a href="#section-5.1">Section 5.1</a>.
When messages are triggered, whether or not they are also
periodically transmitted, a protocol MAY impose a minimum interval
between messages of the same type, denoted MESSAGE_MIN_INTERVAL. In
the case that such an interval is not required, MESSAGE_MIN_INTERVAL
is considered to be zero. When MESSAGE_MIN_INTERVAL is non-zero, it
is however appropriate to also allow this interval to be reduced by
jitter. Thus, when a message is transmitted, the next message is
allowed after a time (MESSAGE_MIN_INTERVAL - jitter). This jitter
SHOULD be generated uniformly in an interval between zero and
MAXJITTER (using a value of MAXJITTER appropriate to periodic message
transmission).
It might appear counterintuitive to have a defined
MESSAGE_MIN_INTERVAL, yet allow this to be reduced by jittering. For
periodic messages, setting MESSAGE_INTERVAL, MAXJITTER and
MESSAGE_MIN_INTERVAL such that (MESSAGE_INTERVAL-MAXJITTER) >
<span class="grey">Clausen, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
MESSAGE_MIN_INTERVAL would ensure at least MESSAGE_MIN_INTERVAL would
elapse between two subsequent message transmissions. In a highly
dynamic network with triggered messages, however, external
circumstances might be such that external triggers are more frequent
than MESSAGE_MIN_INTERVAL, effectively making MESSAGE_MIN_INTERVAL
take the role of MESSAGE_INTERVAL as the "default" interval at which
messages are transmitted. Thus, in order to avoid synchronization in
this highly dynamic case, jittering SHOULD be applied to
MESSAGE_MIN_INTERVAL. This also permits MESSAGE_MIN_INTERVAL to
equal MESSAGE_INTERVAL, even when jitter is used.
When a triggered message is delayed by jitter, the node MAY also
postpone generation of the triggered message. If a node is then
triggered to generate a message of the same type while waiting, it
can generate a single message. If however the node generates a
message when it is triggered, and then receives a another trigger
while waiting to send that message, then the appropriate action to
take is protocol specific (typically to discard the earlier message
or to transmit both, possibly modifying timing to maintain message
order).
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Message Forwarding</span>
When a node forwards a message, it SHOULD be jittered by delaying it
by a random duration. This delay SHOULD be generated uniformly in an
interval between zero and MAXJITTER.
Unlike the cases of periodically generated and externally triggered
messages, a node is not automatically aware of the message
originator's value of MESSAGE_INTERVAL, which is required to select a
value of MAXJITTER that is known to be valid. This may require prior
agreement as to the value (or minimum value) of MESSAGE_INTERVAL, may
be by inclusion in the message of MESSAGE_INTERVAL (the time until
the next relevant message, rather than the time since the last
message) or be by any other protocol specific mechanism, which may
include estimation of the value of MESSAGE_INTERVAL based on received
message times.
For several possible reasons (differing parameters, message
rescheduling, extreme random values), a node may receive a message
while still waiting to forward an earlier message of the same type
originating from the same node. This is possible without jitter, but
may occur more often with it. The appropriate action to take is
protocol-specific (typically, to discard the earlier message or to
forward both, possibly modifying timing to maintain message order).
In many cases, including [<a href="#ref-5" title=""Optimized Link State Routing Protocol (OLSR)"">5</a>] and protocols using the full
functionality of [<a href="#ref-7" title=""Generalized MANET Packet/Message Format"">7</a>], messages are transmitted hop-by-hop in
<span class="grey">Clausen, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
potentially multi-message packets, and some or all of those messages
may need to be forwarded. For efficiency, this SHOULD be in a single
packet, and hence the forwarding jitter of all messages received in a
single packet SHOULD be the same. (This also requires that a single
value of MAXJITTER is used in this case.) For this to have the
intended uniform distribution, it is necessary to choose a single
random jitter for all messages. It is not appropriate to give each
message a random jitter and then to use the smallest of these jitter
values, as that produces a jitter with a non-uniform distribution and
a reduced mean value.
In addition, the protocol MAY permit control messages received in
different packets to be combined, possibly also with locally
generated control messages (periodically generated or triggered), as
supported by [<a href="#ref-7" title=""Generalized MANET Packet/Message Format"">7</a>]. However, in this case, the purpose of the jitter
will be accomplished by choosing any of the independently scheduled
times for these events as the single forwarding time; this may have
to be the earliest time to achieve all constraints. This is because
without combining messages, a transmission would be due at this time
anyway.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Maximum Jitter Determination</span>
In considering how the maximum jitter (one or more instances of
parameter MAXJITTER) may be determined, the following points may be
noted:
o While jitter may resolve the problem of simultaneous
transmissions, the timing changes (in particular the delays) it
introduces will otherwise typically have a negative impact on a
well-designed protocol. Thus, MAXJITTER SHOULD always be
minimized, subject to acceptably achieving its intent.
o When messages are periodically generated, all of the following
that are relevant apply to each instance of MAXJITTER:
* it MUST NOT be negative;
* it MUST NOT be greater than MESSAGE_INTERVAL/2;
* it SHOULD NOT be greater than MESSAGE_INTERVAL/4.
o If MESSAGE_MIN_INTERVAL > 0, then:
* MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;
* MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.
<span class="grey">Clausen, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
o As well as the decision as to whether to use jitter being
dependent on the medium access control and lower layers, the
selection of the MAXJITTER parameter SHOULD be appropriate to
those mechanisms. For example, MAXJITTER should be significantly
greater than (e.g., an order of magnitude greater than) any medium
access control frame period.
o As jitter is intended to reduce collisions, greater jitter, i.e.,
an increased value of MAXJITTER, is appropriate when the chance of
collisions is greater. This is particularly the case with
increased node density, which is significant relative to (the
square of) the interference range rather than useful signal range.
o The choice of MAXJITTER used when forwarding messages MAY also
take into account the expected number of times that the message
may be sequentially forwarded, up to the network diameter in hops,
so that the maximum accumulated delay is bounded.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document provides recommendations for mechanisms to be used in
protocols; full security considerations are to be provided by those
protocols, rather than in this document.
It may however be noted that introduction of random timing by these
recommendations may provide some security advantage to such a
protocol in that it makes the prediction of transmission times, and
thereby intentional interference with a protocol functioning through
selectively scheduling jamming transmissions to coincide with
protocol message transmissions, more difficult.
<span class="grey">Clausen, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
<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-1">1</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.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-2">2</a>] Moy, J., "OSPF Database Overflow", <a href="./rfc1765">RFC 1765</a>, March 1995.
[<a id="ref-3">3</a>] Marlow, D., "Host Group Extensions for CLNP Multicasting", <a href="./rfc1768">RFC</a>
<a href="./rfc1768">1768</a>, March 1995.
[<a id="ref-4">4</a>] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>, January 2006.
[<a id="ref-5">5</a>] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State
Routing Protocol (OLSR)", <a href="./rfc3626">RFC 3626</a>, October 2003.
[<a id="ref-6">6</a>] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", <a href="./rfc3561">RFC 3561</a>, July 2003.
[<a id="ref-7">7</a>] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
MANET Packet/Message Format", Work in Progress.
<span class="grey">Clausen, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgements</span>
The authors would like to acknowledge the MANET working group and the
OLSRv2 Design team, in particular Joe Macker and Justin Dean (both
NRL), for their contributions and discussions in developing and
testing the concepts retained in this document, and Alan Cullen (BAE
Systems) for his careful review of this specification. OLSRv1, as
specified in [<a href="#ref-5" title=""Optimized Link State Routing Protocol (OLSR)"">5</a>], introduced the concept of jitter on control
traffic, which was tested thoroughly by Gitte Hansen and Lars
Christensen (then, both Aalborg University).
Authors' Addresses
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: <a href="http://www.ThomasClausen.org/">http://www.ThomasClausen.org/</a>
Christopher Dearlove
BAE Systems Advanced Technology Centre
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: <a href="http://www.baesystems.com/">http://www.baesystems.com/</a>
Brian Adamson
U.S. Naval Research Laboratory
Phone: +1 202 404 1194
EMail: adamson@itd.nrl.navy.mil
URI: <a href="http://www.nrl.navy.mil/">http://www.nrl.navy.mil/</a>
<span class="grey">Clausen, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5148">RFC 5148</a> Jitter February 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Clausen, et al. Informational [Page 12]
</pre>
|
