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
Jitter Considerations in Mobile Ad Hoc Networks (MANETs)
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.
この文書は、送信衝突の確率を低減するために、モバイルアドホックネットワーク（MANET）ルーティングプロトコルで制御トラフィック伝送の（ランダムに変更するタイミング）ジッタための推奨事項を提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Applicability Statement .........................................4
4. Protocol Overview and Functioning ...............................4
5. Jitter ..........................................................5
5.1. Periodic Message Generation ................................5
5.2. Externally Triggered Message Generation ....................6
5.3. Message Forwarding .........................................7
5.4. Maximum Jitter Determination ...............................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Acknowledgements ......................................11
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.
この文書は、ヘルプが必要とされる場合を考慮し、それを提供するために、ジッタ（ランダムに変化するタイミング）を使用するための推奨事項を提供します。なお、ここで説明される技法は、ワイヤレスネットワークのために設計されたIPプロトコルによって、または下層機構と組み合わせてのいずれかで実施することができる可能性があります。
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.
2つのノードが同時に同じタイプの定期的なメッセージを含むパケットを生成する場合、および典型的であるように、それらが同じメッセージの間隔を使用している場合、これらのメッセージのすべてのさらなる送信は、このようにも同じであろう - 定期的にメッセージをスケジュール時間。以下のメカニズムは、この可能性が発生しますことに注意してください。
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.
イベントトリガメッセージ - ノードは、それらの状況の変化に応答した場合、その近傍における特定の変化を、即時メッセージ生成および送信して、その後、同じ変化に応答する2つの近くのノードが同時にメッセージを送信します。
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.
フォワーディング - ノード前方彼らは、他のノードから受信したメッセージの場合は、近くのノードは、一般的に同じメッセージを受信して転送します。転送がすぐに実行された場合、結果として得られるパケットの送信は、互いに干渉することができます。
A possible solution to these problems is to employ jitter, a deliberate random variation in timing. Such jitter is employed in e.g., [2], [3], and [4], 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.
これらの問題に対する可能な解決策は、ジッタ、タイミングの意図的なランダムばらつきを採用することです。そのようなジッタは、例えばで使用される、[2]、[3]、[4]、定期的なメッセージの送信間隔は、送信機を非同期化することにより、伝送媒体の過負荷を避けるために境界付け、小さなランダム量だけ低減されました同様に受信機。この文書では、説明し、上記の機能を特に参照して、衝突を回避する目的で、モバイルアドホックネットワーク（MANET）内のパケット伝送を制御するためにジッタを印加するための推奨事項を提供します。
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 RFC2119 [1].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますRFC2119 [1]に記載のように解釈されます。
Additionally, this document uses the following terminology:
また、このドキュメントは次の用語を使用します。
Node - A MANET router that implements a message sending protocol.
ノード - メッセージ送信プロトコルを実装MANETルータ。
MANET interface - A network device participating in a MANET. A node may have one or more MANET interfaces.
MANETインタフェース - MANETに参加するネットワーク装置。ノードは、1つのまたは複数のMANETインタフェースを有していてもよいです。
Message - An entity carrying protocol information intended for exchange between nodes. Messages are transmitted over MANET interfaces embedded in packets.
メッセージ - ノード間の交換のために意図エンティティ搬送プロトコル情報。メッセージは、パケットに埋め込まれたMANETインタフェースを介して送信されます。
Packet - An entity embedding zero or more messages for transmission over a MANET interface of the node.
パケット - ノードのMANETインタフェースを介して送信するためのゼロまたはそれ以上のメッセージを埋め込むエンティティ。
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.
送信 - ノードのMANETインタフェースを介して送信されるパケット。変速機は、生成されたメッセージまたは転送されるメッセージのいずれかが原因であることができます。
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.
世代 - ノードの一つ以上のMANETインタフェースを介した送信のために新しいメッセージ（なく受信され転送されたメッセージ）の作成。典型的には、ノードは、メッセージスケジュール（周期的またはその他）または状況の変化に対する応答として基づいてメッセージを生成します。
Forwarding - Retransmission of a received message (whether modified or unchanged) over one or more MANET interfaces of the node.
転送 - （修飾または変化しないかどうか）、受信したメッセージの再送をノードの一つ以上のMANETインタフェース上。
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 another, closely located, node that should receive and decode these packets instead fails to do so, and loses one or more of the packets.
衝突 - 干渉の特定のインスタンス、二つ以上のノードは、これらを受信してデコードする必要があり、別の、近接ノードこと（同一の周波数及び/又は符号化で）同時に同じ信号空間内にパケットを送信しますパケットは代わりにこれを行うに失敗し、パケットの1つまたはそれ以上を失います。
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 [5] employ scheduled messages, where reactive MANET routing protocols such as [6] employ event-triggered messages, and where both employ message forwarding.
本書で説明されたメカニズムのいずれか、制御メッセージ送信、または制御メッセージの転送をトリガし、これは、異なるノードによる同時送信が望ましくない、そのような周期的な制御メッセージの送信などのメカニズムを含有する任意のMANETプロトコルの制御メッセージに適用可能です同時送信が可能性を高める、あるいはそれが発生したときに1が繰り返されることになり。これは特に、[5]採用スケジュールメッセージ、例えば[6]イベントトリガメッセージを用いるような反応性MANETルーティングプロトコル、およびここで、メッセージ転送を採用両方として積極的なMANETルーティングプロトコルの無線ネットワークでブロードキャスト送信を使用してプロトコルに適用されます。
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.
この文書に記載されたアプローチは、衝突の低減を達成するために、タイミングのランダムな変動を使用します。ノードIDに基づいて、例えば、疑似ランダム変化を使用して代替案を考えることができるが、この文書によって議論されていません。
Any protocol based on [7] and using the message forwarding mechanism facilitated by that structure is a particular candidate for application of at least some of these mechanisms.
任意のプロトコル[7]に基づいており、その構造によって促進メッセージ転送メカニズムを使用して、これらのメカニズムのうちの少なくともいくつかの適用のための特定の候補です。
The document has been generalized from the jitter mechanism used in the proactive MANET routing protocol OLSR (the Optimized Link State Routing Protocol) [5].
文書は、積極的なMANETルーティングプロトコルOLSR（最適化リンク状態ルーティング・プロトコル）で使用されるジッタ機構から一般化されている[5]。
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.
この文書では、MANETルーティングプロトコルによって使用されることができるメッセージの送信（再送）するための推奨事項を提供します。それは無線インタフェース上で動作周期またはトリガメッセージスケジュールを採用し、他のプロトコルでも使用することができます。 2つ（またはそれ以上）の隣接ノードからそのような同時メッセージ送信を使用すると、遅延、パケット損失、および他の問題を引き起こす可能性があります。ここで概説としてジッタを使用して任意のプロトコルは、相互運用性のために必要である限りにおいて、その正確な使用方法を指定する必要があります。
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.
最大ノード自治のMANET特性を保持しながら、同時送信からMANETのノードを防止するために、ジッタとして知られているノードによってパケットの伝送時間のランダム化は、使用されるべきです。この問題のさまざまな側面を標的三のジッタメカニズムは、継続するのを防止する、それが発生した場合、同時送信の可能性を低減する目的で、採用すべきであり。
Three cases exist:
3つのケースが存在します。
o Periodic message generation;
O定期メッセージ生成。
o Externally triggered message generation;
O外部トリガメッセージ生成。
o Message forwarding.
Oメッセージの転送。
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.
これらの場合の各々は、それが導入最大タイミング変動を、パラメータ、示さMAXJITTERを使用します。これらのケースの複数のプロトコルで使用される場合、それは同じまたは各ケースのMAXJITTERの異なる値を使用することができます。それはまた、メッセージの種類に応じてMAXJITTERの同じ又は異なる値を使用してもよく、異なる状況下で - 特に、（例えばメッセージ間隔のような）他のパラメータが変化した場合。
Issues relating to the value of MAXJITTER are considered in Section 5.4.
MAXJITTERの値に関連する問題は、5.4節において検討されています。
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.
ノードは、定期的にメッセージを生成する場合、2つの連続したメッセージは、明確に定義された間隔によって分離され、MESSAGE_INTERVALが示さ。ノードは、異なるメッセージタイプ、または（例えば、混雑を避けるために送信をバックオフのような）異なる状況において、例えば、複数のそのような間隔を維持することができます。ジッタはランダムな値である - （ジッターMESSAGE_INTERVAL）、ジッタは、同じタイプのメッセージの連続送信の間の遅延が等しくなるように、ランダムな量だけ、この遅延を低減することによって適用されるべきです。
Subtraction of the random value from the message interval ensures that the message interval never exceeds MESSAGE_INTERVAL, and does 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.
メッセージ間隔からランダムな値の減算は、メッセージ間隔がMESSAGE_INTERVALを超えないことを保証し、そして悪タイムアウトやメッセージの到着遅延または到着の失敗に基づくことができる他のメカニズムに影響を与えません。前回の送信時にメッセージの送信時間を基づかによってではなく、固定されたクロックジッタにより、ノードは完全に繰り返し衝突の彼らの可能性を最小にする、非同期になる可能性があります。外部トリガメッセージ生成及び再スケジューリングと組み合わせた場合に特に有用です。
The jitter value SHOULD be generated uniformly in an interval between zero and MAXJITTER.
ジッタ値がゼロと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 Section 5.4.
ノードが独自MESSAGE_INTERVAL値を知っているであろうと、容易に任意MAXJITTER値は5.4で満たす条件を使用することを保証することができることに留意されたいです。
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 Section 5.1.
内部または外部の条件またはイベントは、ノードによってメッセージの生成をトリガすることができます。プロトコルに依存して、この状態は、単一のメッセージ（を含むが、肯定応答メッセージ、これらに限定されない）、新しい定期的なメッセージスケジュールの開始、または既存の定期的なメッセージの再スケジュールの生成をトリガすることができます。外部トリガメッセージ間の衝突は、複数のノードが同じイベントに応答する可能性がある場合は、より可能性が行われます。この可能性を低減するために、外部トリガメッセージは、ランダムな持続時間によってそれを遅らせることによってジッターされるべきです。適切な場合には、内部トリガメッセージもそうジッタしているかもしれません。この遅延はゼロとMAXJITTERの間隔で一様に生成されるべきです。定期的に送信されたメッセージが再スケジュールされている場合、これはセクション5.1で説明したように処理した後続のメッセージを用いて、この遅延時間に基づくべきです。
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).
メッセージがトリガされたとき、それらはまた、定期的に送信されるか否か、プロトコルは同じタイプのメッセージとの間の最小間隔を課すことが、MESSAGE_MIN_INTERVALで示さ。そのような間隔が必要とされない場合には、MESSAGE_MIN_INTERVALはゼロであると考えられます。 MESSAGE_MIN_INTERVALが非ゼロである場合、また、この間隔は、ジッタによって減少させることができるようにすることが適切です。 （ - ジッタMESSAGE_MIN_INTERVAL）メッセージが送信されるときにこのように、次のメッセージが時間後に許可されます。このジッタはゼロとMAXJITTER（定期的なメッセージの送信に適したMAXJITTERの値を使用して）の間隔で一様に生成されるべきです。
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) >
定義されたMESSAGE_MIN_INTERVALを持つように直観に反する見える、まだこれはジッタによって減らすことができる可能性があります。 MESSAGE_INTERVAL、MAXJITTERとMESSAGE_MIN_INTERVAL設定定期的なメッセージ、のためのように（MESSAGE_INTERVAL-MAXJITTER）>
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.
MESSAGE_MIN_INTERVALは、少なくともMESSAGE_MIN_INTERVALは、2つの後続のメッセージの送信の間の経過でしょう保証するであろう。トリガーメッセージで高度に動的なネットワークでは、しかし、外部の状況は、外部トリガを効果的にメッセージが送信されるときの「デフォルト」間隔としてMESSAGE_INTERVALの役割を担うMESSAGE_MIN_INTERVAL作り、MESSAGE_MIN_INTERVALより頻繁であるようであるかもしれません。従って、この高度に動的な場合に同期を回避するために、ジッタはMESSAGE_MIN_INTERVALに適用すべきです。また、これは、ジッタを用いた場合であっても、同じMESSAGE_INTERVALにMESSAGE_MIN_INTERVALを可能にします。
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).
トリガメッセージは、ジッタによって遅延された場合、ノードは、トリガメッセージの生成を延期するかもしれません。待っている間にノードが同じタイプのメッセージを生成するようにトリガされた場合、それは単一のメッセージを生成することができます。しかし、ノードは、それがトリガされるメッセージを生成し、別のトリガを受信した場合、そのメッセージを送信するために待っている間に、次に取るべき適切なアクションは、（典型的には、以前のメッセージを破棄するか、またはその両方を送信するために、可能性のタイミングを変更するプロトコル特異的です）メッセージの順序を維持します。
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.
ノードがメッセージを転送する場合には、ランダムな持続時間によってそれを遅らせることによってジッターされるべきです。この遅延はゼロと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.
定期的に生成し、外部トリガメッセージの例とは異なり、ノードは自動的に有効であることが知られているMAXJITTERの値を選択する必要があるMESSAGE_INTERVALのメッセージ発信者の値が、認識していません。これは、（次の関連メッセージではなく、最後のメッセージからの時間までの時間）をMESSAGE_INTERVALのメッセージに含めることであってもよい、MESSAGE_INTERVALの値（又は最小値）のような従来の合意を必要とする、または任意の他のプロトコルであってもよいです受信したメッセージの時間に基づいてMESSAGE_INTERVALの値の推定を含むことができる特定の機構。
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 [5] and protocols using the full functionality of [7], messages are transmitted hop-by-hop in
[7]、メッセージは、ホップバイホップで送信されるの完全な機能を使用して、多くの[5]を含む場合、およびプロトコルに
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.
潜在的にマルチメッセージパケット、およびそれらのメッセージの一部またはすべてを転送する必要があるかもしれません。効率のために、これは単一のパケットにする必要があり、したがって単一のパケットで受信されたすべてのメッセージの転送ジッタが同じでなければなりません。 （これはまた、MAXJITTERの単一の値がこの場合に使用されることを必要とする。）、これは意図した均一な分布を有するために、すべてのメッセージのための単一のランダムジッタを選択する必要があります。それは不均一な分布と減少平均値と、ジッタを発生ように、これらのジッタ値の最小を使用する各メッセージにランダムジッタを与えるために適切ではありません。
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 [7]. 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.
また、プロトコルは、[7]でサポートされているように、制御メッセージは、ローカルに生成された制御メッセージ（定期的に生成またはトリガ）で、またおそらくは、組み合わされる異なるパケットで受信可能にすることができます。しかし、この場合には、ジッタの目的は、単一の転送時間としてこれらのイベントのために独立してスケジュールされた時間のいずれかを選択することによって達成されます。これは、すべての制約を達成するための最も早い時間でなければならないことがあります。メッセージを組み合わせることなしに、送信はとにかく、この時点での原因になるからです。
In considering how the maximum jitter (one or more instances of parameter MAXJITTER) may be determined, the following points may be noted:
最大ジッタ（パラメータMAXJITTERの1つまたは複数のインスタンス）を決定することができる方法を検討では、以下の点が指摘されてもよいです。
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ジッタが同時送信の問題を解決することができるが、（特に遅延の）タイミングの変更が導入さは、そうでなければ、典型的には、よく設計されたプロトコルにマイナスの影響を与えることになります。したがって、MAXJITTERは常に許容可能なその意図を達成するための条件として、最小化されなければなりません。
o When messages are periodically generated, all of the following that are relevant apply to each instance of MAXJITTER:
メッセージが定期的に生成されている場合は、O、関連する以下の全てはMAXJITTERの各インスタンスに適用されます。
* it MUST NOT be negative;
*それは負にすることはできません。
* it MUST NOT be greater than MESSAGE_INTERVAL/2;
*それはMESSAGE_INTERVAL / 2以下でなければなりません。
* it SHOULD NOT be greater than MESSAGE_INTERVAL/4.
*それはMESSAGE_INTERVAL / 4よりも大きくすべきではありません。
o If MESSAGE_MIN_INTERVAL > 0, then:
O MESSAGE_MIN_INTERVAL> 0の場合、次のようになります。
* MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;
* MAXJITTERはMESSAGE_MIN_INTERVALより大きくてはいけません。
* MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.
* MAXJITTERはMESSAGE_MIN_INTERVAL / 2より大きくすべきではありません。
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と同様に決定媒体アクセス制御および下部層に依存するジッタを使用するか否かなど、MAXJITTERパラメータの選択は、これらの機構に適切であるべきです。例えば、MAXJITTER（例えば、より大きい桁）任意の媒体アクセス制御フレーム期間より著しく大きくなければなりません。
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、大きなジッタ、衝突の可能性が大きい場合、すなわち、MAXJITTERの増加値は、適切です。これは特に重要に対する（の正方形）の干渉範囲ではなく、有用な信号の範囲であるの増加ノード密度、の場合です。
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.
最大累積遅延が制限されるように、転送メッセージはまた、ホップネットワーク直径まで、アカウントにメッセージを順次転送されてもよいこと回数の期待数を取ることができるときにO MAXJITTERの選択は、使用しました。
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.
送信時間の予測、および選択的スケジューリングジャミング送信を介して機能するプロトコルと、それによって意図的干渉がプロトコルメッセージに一致させることができるという点で、これらの勧告によってランダムなタイミングの導入は、このようなプロトコルにいくつかのセキュリティ上の利点を提供することができるしかしを指摘することができますトランスミッション、より難しいです。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[2]モイ、J.、 "OSPFデータベースオーバーフロー"、RFC 1765、1995年3月。
[3] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1768, March 1995.
[3]マーロー、D.、1995年3月、RFC 1768 "CLNPマルチキャスティングのためのグループの拡張機能をホストします"。
[4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[4] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[5] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[5]クラウゼン、T.、エド。、およびP.ジャケ、エド。、 "最適化されたリンクステートルーティングプロトコル（OLSR）"、RFC 3626、2003年10月。
[6] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[6]パーキンス、C.、ベルディング・ロイヤー、E.、およびS.ダス、 "アドホックオンデマンド距離ベクトル（AODV）ルーティング"、RFC 3561、2003年7月。
[7] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", Work in Progress.
[7] Clausenの、T.、Dearlove、C.、ディーン、J.、およびC. Adjih、 "一般MANETパケット/メッセージ形式"、ProgressのWork。
Appendix A. Acknowledgements
付録A.謝辞
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 [5], introduced the concept of jitter on control traffic, which was tested thoroughly by Gitte Hansen and Lars Christensen (then, both Aalborg University).
著者は、この文書に保持する概念を開発およびテストにおける彼らの貢献と議論のために、特にジョーMackerとジャスティン・ディーン（両方NRL）、MANETワーキンググループとOLSRv2デザインチームに感謝、そしてアラン・カレン（BAEシステムズう）この仕様の彼の慎重な検討のために。 OLSRv1は、[5]で指定されるように、Gitteハンセンとラース・クリステンセン（そして、両方のオールボー大学）で徹底的にテストされた、制御トラフィックのジッタの概念が導入されました。
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique, France
トーマス・ハイデクラウゼンLIX、エコール・ポリテクニック、フランス
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/
電話：+33 6 6058 9349 Eメール：T.Clausen@computer.org URI：http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre
クリストファーDearlove BAEシステムズ先端技術センター
Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/
電話：+44 1245 242194 Eメール：chris.dearlove@baesystems.com URI：http://www.baesystems.com/
Brian Adamson U.S. Naval Research Laboratory
ブライアン・アダムソン米国海軍研究所
Phone: +1 202 404 1194 EMail: adamson@itd.nrl.navy.mil URI: http://www.nrl.navy.mil/
電話：+1 202 404 1194 Eメール：URI adamson@itd.nrl.navy.mil：http://www.nrl.navy.mil/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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 BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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 http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。