draft-ietf-manet-jitter-02.txt   draft-ietf-manet-jitter-03.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Informational C. Dearlove Intended status: Informational C. Dearlove
Expires: February 25, 2008 BAE Systems Advanced Technology Expires: May 19, 2008 BAE Systems Advanced Technology
Centre Centre
B. Adamson B. Adamson
Naval Research Laboratory U.S. Naval Research Laboratory
August 24, 2007 November 16, 2007
Jitter considerations in MANETs Jitter considerations in Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-jitter-02 draft-ietf-manet-jitter-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2008. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides recommendations for jittering (randomly This document provides recommendations for jittering (randomly
modifying timing) of control traffic transmissions in MANET routing modifying timing) of control traffic transmissions in Mobile Ad hoc
protocols to reduce the probability of packet collisions. NETwork (MANET) routing protocols to reduce the probability of
transmission collisions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Periodic Message Generation . . . . . . . . . . . . . . . 7 5.1. Periodic Message Generation . . . . . . . . . . . . . . . 8
5.2. Externally Triggered Message Generation . . . . . . . . . 8 5.2. Externally-Triggered Message Generation . . . . . . . . . 9
5.3. Message Forwarding . . . . . . . . . . . . . . . . . . . . 9 5.3. Message Forwarding . . . . . . . . . . . . . . . . . . . . 10
5.4. Maximum Jitter Determination . . . . . . . . . . . . . . . 10 5.4. Maximum Jitter Determination . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
In a wireless network, simultaneous packet transmission by nearby In a wireless network, simultaneous packet transmission by nearby
nodes is undesirable as, depending on the medium access control and nodes is often undesirable as, depending on the medium access control
other lower layer mechanisms, the interference between these and other lower layer mechanisms, the interference between these
transmissions may cause at best increased delay, and at worst transmissions may cause at best increased delay, and at worst
complete packet loss. 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 The problems of simultaneous packet transmissions are amplified if
any of the following features are present in a protocol: any of the following features are present in a protocol:
Regularly scheduled messages - If two nodes generate packets Regularly scheduled messages - If two nodes generate packets
containing regularly scheduled messages of the same type at the containing regularly scheduled messages of the same type at the
same time, and if, as is typical, they are using the same message same time, and if, as is typical, they are using the same message
interval, all further transmissions of these messages will thus interval, all further transmissions of these messages will thus
also be at the same time. 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 Event-triggered messages - If nodes respond to changes in their
circumstances, in particular changes in their neighborhood, with circumstances, in particular changes in their neighborhood, with
an immediate message generation and transmission, then two nearby an immediate message generation and transmission, then two nearby
nodes which respond to the same change will transmit messages nodes which respond to the same change will transmit messages
simultaneously. simultaneously.
Schedule reset - When a node sends an event-triggered message of a Schedule reset - When a node sends an event-triggered message of a
type which is usually regularly scheduled, then there is no type which is usually regularly scheduled, then there is no
apparent reason why it should not restart its corresponding apparent reason why it should not restart its corresponding
message schedule. This may result in nodes responding to the same message schedule. This may result in nodes responding to the same
change also sending future messages simultaneously. change also sending future messages simultaneously.
Forwarding - If nodes forward messages they receive from other Forwarding - If nodes forward messages they receive from other
nodes, then nearby nodes will commonly receive and forward the nodes, then nearby nodes will commonly receive and forward the
same message. If forwarding is performed immediately then the same message. If forwarding is performed immediately then the
resulting packet transmissions may interfere with each other. resulting packet transmissions may interfere with each other.
A possible solution to these problems is to employ jitter, a A possible solution to these problems is to employ jitter, a
deliberate random variation in timing. Such jitter is employed in deliberate random variation in timing. Such jitter is employed in
e.g. [2], [3] and [4], in which transmission intervals are reduced by e.g. [2], [3] and [4], in which transmission intervals for regularly
a small, bounded and random percentage in order to desynchronize scheduled messages are reduced by a small, bounded and random amount
transmitters and thereby avoid overloading the transmission medium as in order to desynchronize transmitters and thereby avoid overloading
well as receivers. This document discusses applying jitter to packet the transmission medium as well as receivers. This document
transmissions in Mobile Ad hoc NETworks (MANETs), with the purpose of discusses and provides recommendations for applying jitter to control
avoiding collisions, with particular reference to the features listed packet transmissions in Mobile Ad hoc NETworks (MANETs), with the
above. purpose of avoiding collisions, with particular reference to the
features listed above.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1]. document are to be interpreted as described in RFC2119 [1].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Node - A MANET router which implements a message sending protocol. Node - A MANET router which implements a message sending protocol.
skipping to change at page 4, line 29 skipping to change at page 5, line 29
exchange between nodes. Messages are transmitted over MANET exchange between nodes. Messages are transmitted over MANET
interfaces embedded in packets. interfaces embedded in packets.
Packet - An entity embedding zero or more messages for transmission Packet - An entity embedding zero or more messages for transmission
over a MANET interface of the node. over a MANET interface of the node.
Transmission - A packet being sent over a MANET interface of the Transmission - A packet being sent over a MANET interface of the
node. A transmission can be due to either a message being node. A transmission can be due to either a message being
generated or a message being forwarded. generated or a message being forwarded.
Generation - Creation of a new message for transmission over one or Generation - Creation of a new message (rather than a received and
more MANET interfaces of the node. Typically, a node will forwarded message) for transmission over one or more MANET
generate messages based on a message schedule (periodic or interfaces of the node. Typically, a node will generate messages
otherwise) or as a response to changes in circumstances. based on a message schedule (periodic or otherwise) or as a
response to changes in circumstances.
Forwarding - Retransmission of a received message over one or more Forwarding - Retransmission of a received message (whether modified
MANET interfaces of the node. or unchanged) over one or more MANET interfaces of the node.
Collision - A specific instance of interference, where two or more Collision - A specific instance of interference, where two or more
nodes transmit a packet at the same time and within the same nodes transmit a packet at the same time and within the same
signal space (at the same frequency and/or encoding) such that signal space (at the same frequency and/or encoding) such that
another, closely located, node which should receive and decode another, closely located, node which should receive and decode
these packets instead fails to do so, and loses one or more of the these packets instead fails to do so, and loses one or more of the
packets. packets.
3. Applicability Statement 3. Applicability Statement
The mechanisms described in this document are applicable to any MANET The mechanisms described in this document are applicable to the
protocol in which simultaneous transmissions by different nodes are control messages of any MANET protocol in which simultaneous
undesirable and which contains mechanisms, such as periodic message transmissions by different nodes are undesirable, and which contains
transmission, triggered message transmission, or message forwarding, mechanisms, such as periodic control message transmission, triggered
which either make the simultaneous transmission more likely, or cause control message transmission, or control message forwarding, which
it to be repeated when it occurs. This particularly applies to either make a simultaneous transmission more likely, or cause one to
protocols using broadcast transmissions in wireless networks, where be repeated when it occurs. This particularly applies to protocols
proactive MANET routing protocols such as [5] employ scheduled using broadcast transmissions in wireless networks, where proactive
messages, where reactive MANET routing protocols such as [6] employ MANET routing protocols such as [5] employ scheduled messages, where
event-triggered messages, and where both employ message forwarding. reactive MANET routing protocols such as [6] employ event-triggered
messages, and where both employ message forwarding.
These mechanisms are intended for application where the underlying These mechanisms are intended for application where the underlying
medium access control and lower layers do not provide effective medium access control and lower layers do not provide effective
mechanisms to avoid such collisions. Where these layers do provide mechanisms to avoid such collisions. Where these layers do provide
effective mechanisms, the approach of this document is not needed. effective mechanisms, the recommendations of this document are not
needed.
The approach described in this document uses random variations in The approach described in this document uses random variations in
timing to achieve a reduction in collisions. Alternatives using, for timing to achieve a reduction in collisions. Alternatives using, for
example, pseudo-random variation based on node identity, may be example, pseudo-random variation based on node identity, may be
considered, but are not discussed by this document. considered, but are not discussed by this document.
Any protocol based on [7] and using the message forwarding mechanism Any protocol based on [7] and using the message forwarding mechanism
facilitated by that structure is a particular candidate for facilitated by that structure is a particular candidate for
application of at least some of these mechanisms. application of at least some of these mechanisms.
skipping to change at page 7, line 10 skipping to change at page 8, line 10
simultaneous transmissions from two (or more) adjacent nodes causes simultaneous transmissions from two (or more) adjacent nodes causes
delays, packet losses and other problems. Any protocol using jitter delays, packet losses and other problems. Any protocol using jitter
as outlined here must specify its precise usage insofar as is as outlined here must specify its precise usage insofar as is
necessary for interoperability. necessary for interoperability.
5. Jitter 5. Jitter
In order to prevent nodes in a MANET from simultaneous transmission, In order to prevent nodes in a MANET from simultaneous transmission,
whilst retaining the MANET characteristic of maximum node autonomy, a whilst retaining the MANET characteristic of maximum node autonomy, a
randomization of the transmission time of packets by nodes, known as randomization of the transmission time of packets by nodes, known as
jitter, MAY be employed. Three jitter mechanisms, which target jitter, SHOULD be employed. Three jitter mechanisms, which target
different aspects of this problem, MAY be employed, with the aim of different aspects of this problem, SHOULD be employed, with the aim
reducing the likelihood of simultaneous transmission, and, if it of reducing the likelihood of simultaneous transmission, and, if it
occurs, preventing it from continuing. occurs, preventing it from continuing.
Three cases exist: Three cases exist:
o Periodic message generation; o Periodic message generation;
o Externally triggered message generation; o Externally-triggered message generation;
o Message forwarding. 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 Each of these cases uses a parameter, denoted MAXJITTER, for the
maximum timing variation that it introduces. If more than one of 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 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 value of MAXJITTER for each case. It also MAY use the same or
different values of MAXJITTER according to message type, and under different values of MAXJITTER according to message type, and under
different circumstances - in particular if other parameters (such as different circumstances - in particular if other parameters (such as
message interval) vary. message interval) vary.
Issues relating to the value of MAXJITTER are considered in Issues relating to the value of MAXJITTER are considered in
Section 5.4. Section 5.4.
5.1. Periodic Message Generation 5.1. Periodic Message Generation
When a node generates a message periodically, two successive messages When a node generates a message periodically, two successive messages
will be separated by a well-defined interval, denoted will be separated by a well-defined interval, denoted
MESSAGE_INTERVAL. A node MAY maintain more than one such interval, MESSAGE_INTERVAL. A node MAY maintain more than one such interval,
e.g. for different message types or in different circumstances (such e.g. for different message types or in different circumstances (such
as backing off transmissions to avoid congestion). Jitter MAY be as backing off transmissions to avoid congestion). Jitter SHOULD be
applied by reducing this delay by a random amount, so that the delay applied by reducing this delay by a random amount, so that the delay
between consecutive transmissions of messages of the same type is between consecutive transmissions of messages of the same type is
equal to (MESSAGE_INTERVAL - jitter), where jitter is the random equal to (MESSAGE_INTERVAL - jitter), where jitter is the random
value. value.
Subtraction of the random value from the message interval ensures Subtraction of the random value from the message interval ensures
that the message interval never exceeds MESSAGE_INTERVAL, and does that the message interval never exceeds MESSAGE_INTERVAL, and does
not adversely affect timeouts or other mechanisms which may be based not adversely affect timeouts or other mechanisms which may be based
on message late arrival or failure to arrive. By basing the message on message late arrival or failure to arrive. By basing the message
transmission time on the previous transmission time, rather than by transmission time on the previous transmission time, rather than by
jittering a fixed clock, nodes can become completely desynchronized, jittering a fixed clock, nodes can become completely desynchronized,
which minimizes their probability of repeated collisions. This is which minimizes their probability of repeated collisions. This is
particularly useful when combined with externally triggered message particularly useful when combined with externally-triggered message
generation and rescheduling. generation and rescheduling.
The jitter value SHOULD be taken from a uniform distribution between The jitter value SHOULD be generated uniformly in an interval between
zero and MAXJITTER. zero and MAXJITTER.
Note that a node will know its own MESSAGE_INTERVAL value and can Note that a node will know its own MESSAGE_INTERVAL value and can
readily ensure that any MAXJITTER value used satisfies the conditions readily ensure that any MAXJITTER value used satisfies the conditions
in Section 5.4. in Section 5.4.
5.2. Externally Triggered Message Generation 5.2. Externally-Triggered Message Generation
An internal or external condition or event MAY trigger message An internal or external condition or event may trigger message
generation by a node. Depending upon the protocol, this condition generation by a node. Depending upon the protocol, this condition
MAY trigger generation of a single message, initiation of a new may trigger generation of a single message (including, but not
periodic message schedule, or rescheduling of existing periodic limited to, an acknowledgement message), initiation of a new periodic
messaging. Collision between externally triggered messages is made message schedule, or rescheduling of existing periodic messaging.
more likely if more than one node is likely to respond to the same Collision between externally-triggered messages is made more likely
event. To reduce this likelihood, an externally triggered message if more than one node is likely to respond to the same event. To
MAY be jittered by delaying it by a random duration; an internally reduce this likelihood, an externally-triggered message SHOULD be
triggered message MAY also be so jittered if appropriate. This delay jittered by delaying it by a random duration; an internally triggered
SHOULD be generated uniformly in an interval between zero and message MAY also be so jittered if appropriate. This delay SHOULD be
MAXJITTER. If periodically transmitted messages are rescheduled, generated uniformly in an interval between zero and MAXJITTER. If
then this SHOULD be based on this delayed time, with subsequent periodically transmitted messages are rescheduled, then this SHOULD
messages treated as described in Section 5.1. be based on this delayed time, with subsequent messages treated as
described in Section 5.1.
When messages are triggered, whether or not they are also When messages are triggered, whether or not they are also
periodically transmitted, a protocol MAY impose a minimum interval periodically transmitted, a protocol MAY impose a minimum interval
between messages of the same type, denoted MESSAGE_MIN_INTERVAL. It between messages of the same type, denoted MESSAGE_MIN_INTERVAL. It
is however appropriate to also allow this interval to be reduced by is however appropriate to also allow this interval to be reduced by
jitter, so that when a message is transmitted the next message is jitter, so that when a message is transmitted the next message is
allowed after a time (MESSAGE_MIN_INTERVAL - jitter), where jitter allowed after a time (MESSAGE_MIN_INTERVAL - jitter), where jitter
SHOULD be generated uniformly in an interval between zero and SHOULD be generated uniformly in an interval between zero and
MAXJITTER (using a value of MAXJITTER appropriate to periodic message MAXJITTER (using a value of MAXJITTER appropriate to periodic message
transmission). transmission).
skipping to change at page 8, line 51 skipping to change at page 10, line 9
MESSAGE_MIN_INTERVAL, yet allow this to be reduced by jittering. For MESSAGE_MIN_INTERVAL, yet allow this to be reduced by jittering. For
periodic messages, setting MESSAGE_INTERVAL, MAXJITTER and periodic messages, setting MESSAGE_INTERVAL, MAXJITTER and
MESSAGE_MIN_INTERVAL such that (MESSAGE_INTERVAL-MAXJITTER) > MESSAGE_MIN_INTERVAL such that (MESSAGE_INTERVAL-MAXJITTER) >
MESSAGE_MIN_INTERVAL would ensure at least MESSAGE_MIN_INTERVAL would MESSAGE_MIN_INTERVAL would ensure at least MESSAGE_MIN_INTERVAL would
elapse between two subsequent message transmissions. In a highly elapse between two subsequent message transmissions. In a highly
dynamic network with triggered messages, however, external dynamic network with triggered messages, however, external
circumstances might be such that external triggers are more frequent circumstances might be such that external triggers are more frequent
than MESSAGE_MIN_INTERVAL, effectively making MESSAGE_MIN_INTERVAL than MESSAGE_MIN_INTERVAL, effectively making MESSAGE_MIN_INTERVAL
take the role of MESSAGE_INTERVAL as the "default" interval at which take the role of MESSAGE_INTERVAL as the "default" interval at which
messages are transmitted. Thus, in order to avoid synchronization messages are transmitted. Thus, in order to avoid synchronization
also in this highly dynamic case, jitterering should be applied to also in this highly dynamic case, jittering SHOULD be applied to
MESSAGE_MIN_INTERVAL. This also permits MESSAGE_MIN_INTERVAL to MESSAGE_MIN_INTERVAL. This also permits MESSAGE_MIN_INTERVAL to
equal MESSAGE_INTERVAL even when jitter is used. equal MESSAGE_INTERVAL even when jitter is used.
When a triggered message is delayed by jitter, the node MAY also When a triggered message is delayed by jitter, the node MAY also
postpone generation of the triggered message. If a node is then postpone generation of the triggered message. If a node is then
triggered to generate a message of the same type while waiting, it triggered to generate a message of the same type while waiting, it
can generate a single message. If however the node generates a can generate a single message. If however the node generates a
message when it is triggered, and then receives a another trigger message when it is triggered, and then receives a another trigger
while waiting to send that message then the appropriate action to while waiting to send that message then the appropriate action to
take is protocol specific (typically to discard the earlier message take is protocol specific (typically to discard the earlier message
or to transmit both, possibly modifying timing to maintain message or to transmit both, possibly modifying timing to maintain message
order). order).
5.3. Message Forwarding 5.3. Message Forwarding
When a node forwards a message, it may be jittered by delaying it by When a node forwards a message, it SHOULD be jittered by delaying it
a random duration. This delay SHOULD be generated uniformly in an by a random duration. This delay SHOULD be generated uniformly in an
interval between zero and MAXJITTER. interval between zero and MAXJITTER.
Unlike the cases of periodically generated and externally triggered Unlike the cases of periodically generated and externally-triggered
messages, a node is not automatically aware of the message messages, a node is not automatically aware of the message
originator's value of MESSAGE_INTERVAL, which is required to select a originator's value of MESSAGE_INTERVAL, which is required to select a
value of MAXJITTER which is known to be valid. This may require value of MAXJITTER which is known to be valid. This may require
prior agreement as to the value (or minimum value) of prior agreement as to the value (or minimum value) of
MESSAGE_INTERVAL, may be by inclusion in the message of MESSAGE_INTERVAL, may be by inclusion in the message of
MESSAGE_INTERVAL (the time until the next relevant message, rather MESSAGE_INTERVAL (the time until the next relevant message, rather
than the time since the last message) or be by any other protocol than the time since the last message) or be by any other protocol
specific mechanism, which may include estimation of the value of specific mechanism, which may include estimation of the value of
MESSAGE_INTERVAL based on received message times. MESSAGE_INTERVAL based on received message times.
For several possible reasons (differing parameters, message For several possible reasons (differing parameters, message
rescheduling, extreme random values) a node may receive a message rescheduling, extreme random values) a node may receive a message
while still waiting to forward an earlier message of the same type while still waiting to forward an earlier message of the same type
originating from the same node. This is possible without jitter, but originating from the same node. This is possible without jitter, but
may occur more often with it. The appropriate action to take is may occur more often with it. The appropriate action to take is
protocol specific (typically to discard the earlier message or to protocol specific (typically to discard the earlier message or to
forward both, possible modifying timing to maintain message order). forward both, possible modifying timing to maintain message order).
In many cases, including [5] and protocols using the full In many cases, including [5] and protocols using the full
functionality of [7], messages are transmitted hop by hop in functionality of [7], messages are transmitted hop-by-hop in
potentially multi-message packets, and some or all of those messages potentially multi-message packets, and some or all of those messages
may need to be forwarded. For efficiency this should be in a single 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 packet, and hence the forwarding jitter of all messages received in a
single packet should be the same. (This also requires that a single 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 value of MAXJITTER is used in this case.) For this to have the
intended uniform distribution it is necessary to choose a single intended uniform distribution it is necessary to choose a single
random jitter for all messages. It is not appropriate to give each 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 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 values, as that produces a jitter with a non-uniform distribution and
a reduced mean value. a reduced mean value.
In addition, the protocol may permit messages received in different In addition, the protocol MAY permit control messages received in
packets to be combined, possibly also with locally generated messages different packets to be combined, possibly also with locally
(periodically generated or triggered). However in this case the generated control messages (periodically generated or triggered), as
purpose of the jitter will be accomplished by choosing any of the supported by [7]. However in this case the purpose of the jitter
independently scheduled times for these events as the single will be accomplished by choosing any of the independently scheduled
forwarding time; this may have to be the earliest time to achieve all times for these events as the single forwarding time; this may have
constraints. This is because without combining messages, a to be the earliest time to achieve all constraints. This is because
transmission was due at this time anyway. without combining messages, a transmission was due at this time
anyway.
5.4. Maximum Jitter Determination 5.4. Maximum Jitter Determination
In considering how the maximum jitter (one or more instances of In considering how the maximum jitter (one or more instances of
parameter MAXJITTER) may be determined, the following points may be parameter MAXJITTER) may be determined, the following points may be
noted: noted:
o While jitter may resolve the problem of simultaneous o While jitter may resolve the problem of simultaneous
transmissions, the timing changes (in particular the delays) it transmissions, the timing changes (in particular the delays) it
introduces will otherwise typically have a negative impact on a introduces will otherwise typically have a negative impact on a
well-designed protocol. Thus MAXJITTER should always be well-designed protocol. Thus MAXJITTER SHOULD always be
minimized, subject to acceptably achieving its intent. minimized, subject to acceptably achieving its intent.
o When messages are periodically generated, all of the following o When messages are periodically generated, all of the following
that are relevant apply to each instance of MAXJITTER: that are relevant apply to each instance of MAXJITTER:
* it MUST NOT be negative; * it MUST NOT be negative;
* it MUST NOT be greater than MESSAGE_INTERVAL/2; * it MUST NOT be greater than MESSAGE_INTERVAL/2;
* it SHOULD be significantly less than MESSAGE_INTERVAL; * it SHOULD be significantly less than MESSAGE_INTERVAL; a value
not greater than MESSAGE_INTERVAL/4 is RECOMMENDED.
o If MESSAGE_MIN_INTERVAL > 0, then: o If MESSAGE_MIN_INTERVAL > 0, then:
* MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL; * MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;
* MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2. * MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.
o As well as the decision as to whether to use jitter being o As well as the decision as to whether to use jitter being
dependent on the medium access control and lower layers, the dependent on the medium access control and lower layers, the
selection of the MAXJITTER parameter should be appropriate to selection of the MAXJITTER parameter SHOULD be appropriate to
those mechanisms. those mechanisms.
o As jitter is intended to reduce collisions, greater jitter, i.e. o As jitter is intended to reduce collisions, greater jitter, i.e.
an increased value of MAXJITTER, is appropriate when the chance of an increased value of MAXJITTER, is appropriate when the chance of
collisions is greater. This is particularly the case with collisions is greater. This is particularly the case with
increased node density, where node density should be considered increased node density, which is significant relative to (the
relative to (the square of) the interference range rather than square of) the interference range rather than useful signal range.
useful signal range.
o The choice of MAXJITTER used when forwarding messages may also o The choice of MAXJITTER used when forwarding messages MAY also
take into account the expected number of times that the message take into account the expected number of times that the message
may be sequentially forwarded, up to the network diameter in hops. may be sequentially forwarded, up to the network diameter in hops.
6. IANA Considerations 6. IANA Considerations
This document presents no IANA considerations. This document presents no IANA considerations.
7. Security Considerations 7. Security Considerations
This document does not specify any security considerations. 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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
8.2. Informative References 8.2. Informative References
[2] Moy, J., "OSPF Database Overflow", RFC 1768, March 1995. [2] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[3] Marlow, D., "Host Group Extensions for CLNP Multicasting", [3] Marlow, D., "Host Group Extensions for CLNP Multicasting",
RFC 1768, March 1995. RFC 1768, March 1995.
[4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 [4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006. (BGP-4)", RFC 4271, January 2006.
[5] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [5] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
[6] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand [6] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC 3561, July 2003. Distance Vector (AODV) Routing", RFC 3561, July 2003.
[7] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized [7] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
MANET Packet/Message Format", Work In MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-07.txt, June 2007. Progress draft-ietf-manet-packetbb-11.txt, November 2007.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to acknowledge the MANET working group and the The authors would like to acknowledge the MANET working group and the
OLSRv2 Design team, in particular Joe Macker and Justin Dean (both OLSRv2 Design team, in particular Joe Macker and Justin Dean (both
NRL), for their contributions and discussions in developing and NRL), for their contributions and discussions in developing and
testing the concepts retained in this document, and Alan Cullen (BAE testing the concepts retained in this document, and Alan Cullen (BAE
Systems) for his careful review of this specification. OLSRv1, as Systems) for his careful review of this specification. OLSRv1, as
specified in [5], introduced the concept of jitter on control specified in [5], introduced the concept of jitter on control
traffic, which was tested thoroughly by Gitte Hansen and Lars traffic, which was tested thoroughly by Gitte Hansen and Lars
skipping to change at page 16, line 22 skipping to change at page 17, line 22
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
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/
Brian Adamson Brian Adamson
Naval Research Laboratory U.S. Naval Research Laboratory
Phone: +01 202-404-1194
Email: adamson@itd.nrl.navy.mil Email: adamson@itd.nrl.navy.mil
URI: http://www.nrl.navy.mil/ URI: http://www.nrl.navy.mil/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 40 change blocks. 
98 lines changed or deleted 128 lines changed or added

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