draft-ietf-manet-jitter-03.txt   draft-ietf-manet-jitter-04.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: May 19, 2008 BAE Systems Advanced Technology Expires: June 6, 2008 BAE Systems Advanced Technology
Centre Centre
B. Adamson B. Adamson
U.S. Naval Research Laboratory U.S. Naval Research Laboratory
November 16, 2007 December 4, 2007
Jitter considerations in Mobile Ad Hoc Networks (MANETs) Jitter considerations in Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-jitter-03 draft-ietf-manet-jitter-04
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 May 19, 2008. This Internet-Draft will expire on June 6, 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 Mobile Ad hoc modifying timing) of control traffic transmissions in Mobile Ad hoc
NETwork (MANET) routing protocols to reduce the probability of NETwork (MANET) routing protocols to reduce the probability of
skipping to change at page 3, line 8 skipping to change at page 3, line 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 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 often undesirable as, depending on the medium access control nodes is often undesirable. This is because any resulting collision
and other lower layer mechanisms, the interference between these between these packets may cause a receiving node to fail to receive
transmissions may cause at best increased delay, and at worst some or all of these packets. This is a physical problem, which
complete packet loss. In some instances these problems can be solved occurs before packets can be inserted into the receiver queue.
in these lower layers, but in other instances some help at the Depending on the characteristics of the medium access control and
network and higher layers is necessary. This document considers the other lower layer mechanisms, in particular whether retransmission of
case when that help is required, and provides recommendations for unacknowledged packets is supported, this may cause at best increased
using jitter (randomly varying timing) to provide it. It is possible delay, and at worst complete packet loss. In some instances these
that the techniques described here could be implemented either by IP problems can be solved in these lower layers, but in other instances
protocols designed for wireless networks or in conjunction with some help at the network and higher layers is necessary.
lower-layer mechanisms.
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. Note that the following mechanisms may also be at the same time. Note that the following mechanisms may
make this a likely occurrence. make this a likely occurrence.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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.
The document has been generalized from the jitter mechanism used in The document has been generalized from the jitter mechanism used in
the proactive MANET routing protocol OLSR (The Optimized Link State the proactive MANET routing protocol OLSR (The Optimized Link State
Routing Protocol) [5]. Routing Protocol) [5].
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This document does not specify a protocol, nor does it mandate This document provides recommendations for message transmission (and
specific node or protocol behavior. Rather, it outlines mechanisms retransmission) which may be used by MANET routing protocols. It may
for message transmission (and retransmission) applicable in MANET also be used by other protocols that employ a periodic or triggered
routing protocols and other protocols employing a periodic or message schedule running over wireless interfaces. Using such
triggered message schedule and running over wireless interfaces where protocols simultaneous transmissions from two (or more) adjacent
simultaneous transmissions from two (or more) adjacent nodes causes nodes may cause delays, packet losses and other problems. Any
delays, packet losses and other problems. Any protocol using jitter protocol using jitter as outlined here must specify its precise usage
as outlined here must specify its precise usage insofar as is 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, SHOULD be employed. Three jitter mechanisms, which target jitter, SHOULD be employed. Three jitter mechanisms, which target
different aspects of this problem, SHOULD be employed, with the aim different aspects of this problem, SHOULD be employed, with the aim
of 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.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
reduce this likelihood, an externally-triggered message SHOULD be reduce this likelihood, an externally-triggered message SHOULD be
jittered by delaying it by a random duration; an internally triggered jittered by delaying it by a random duration; an internally triggered
message MAY also be so jittered if appropriate. This delay SHOULD be message MAY also be so jittered if appropriate. This delay SHOULD be
generated uniformly in an interval between zero and MAXJITTER. If generated uniformly in an interval between zero and MAXJITTER. If
periodically transmitted messages are rescheduled, then this SHOULD periodically transmitted messages are rescheduled, then this SHOULD
be based on this delayed time, with subsequent messages treated as be based on this delayed time, with subsequent messages treated as
described in Section 5.1. 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. 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 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. Thus 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). This 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).
It might appear counterintuitive to have a defined It might appear counterintuitive to have a defined
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
skipping to change at page 11, line 42 skipping to change at page 11, line 44
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; a value * it SHOULD NOT be greater than MESSAGE_INTERVAL/4.
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. 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. 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, which is significant relative to (the increased node density, which is significant relative to (the
square of) the interference range rather than useful signal range. square of) the interference range rather than 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,
in order that the maximum accumulated delay is bounded.
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 provides recommendations for mechanisms to be used in This document provides recommendations for mechanisms to be used in
protocols; full security considerations are to be provided by those protocols; full security considerations are to be provided by those
protocols, rather than in this document. protocols, rather than in this document.
skipping to change at page 17, line 24 skipping to change at page 17, line 24
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
U.S. Naval Research Laboratory U.S. Naval Research Laboratory
Phone: +01 202-404-1194 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. 12 change blocks. 
32 lines changed or deleted 40 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/