[要約] 要約：RFC 5148は、モバイルアドホックネットワーク（MANET）におけるジッターの考慮事項について説明しています。 目的：このRFCの目的は、MANETにおけるジッターの影響を理解し、ネットワークパフォーマンスの向上と信頼性の確保に役立つガイドラインを提供することです。
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]で採用されています。これらのメッセージは、送信機を非同期化し、それによって伝送媒体の過負荷を避けるために、定期的にスケジュールされたメッセージの伝送間隔が小さく、境界のあるランダムな量によって削減されます。レシーバーと同様に。このドキュメントでは、上記の機能を特に参照して、衝突を回避する目的で、モバイルアドホックネットワーク（MANETS）のパケット送信を制御するためにジッターを適用するための推奨事項について説明し、提供します。
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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" optional "は、RFC2119 [1]に記載されているように解釈されます。
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.
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.
生成 - ノードの1つ以上のMANETインターフェイスを介して送信するための新しいメッセージ（受信および転送されたメッセージではなく）の作成。通常、ノードは、メッセージスケジュール（定期的またはその他）に基づいて、または状況の変化への応答としてメッセージを生成します。
Forwarding - Retransmission of a received message (whether modified or unchanged) over one or more MANET interfaces of the node.
転送 - ノードの1つまたは複数の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.
衝突 - 干渉の特定のインスタンス。2つ以上のノードがパケットを同時に、同じ信号空間内（同じ周波数および/またはエンコード）内で送信して、これらを受信およびデコードする別の密接に位置するノードを代わりに、パケットはそうしなかったため、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プロトコルの制御メッセージに適用できます。同時トランスミッションをより可能にするか、それが発生したときに繰り返される可能性が高くなります。これは特に、[5]などのプロアクティブな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.
このドキュメントで説明されているアプローチでは、タイミングのランダムなバリエーションを使用して、衝突の減少を達成します。たとえば、ノードのアイデンティティに基づいた擬似ランダム変動を使用する代替案は考慮される場合がありますが、このドキュメントでは説明されていません。
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].
このドキュメントは、プロアクティブマネルーティングプロトコル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.
マネのノードが同時伝送を防ぐためには、最大ノードの自律性のマネ特性を保持しながら、ジッターとして知られるノードによるパケットの送信時間のランダム化を使用する必要があります。この問題のさまざまな側面を対象とする3つのジッターメカニズムを採用する必要があります。同時伝送の可能性を減らし、それが発生した場合、継続を防ぐことを目的としています。
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.
これらのケースの最初では、ジッターを使用して、連続したメッセージ伝送間の間隔をランダムな量だけ削減します。後者の2つのケースでは、ジッターを使用して、生成または転送されるメッセージをランダムな量で遅らせます。
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 -jitter）に等しくなります。ここで、ジッターはランダム値です。
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 -jitter）。このジッターは、ゼロと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 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.
Mession_min_intervalを定義していることは直感に反するように見えるかもしれませんが、これを不安にすることで減らすことができます。定期的なメッセージの場合、message_interval、maxjitter、message_min_intervalの設定（message_interval-maxjitter）> message_min_intervalは、少なくともmessage_min_intervalが2つの後続のメッセージ送信の間で経過するようにします。ただし、トリガーされたメッセージを備えた非常に動的なネットワークでは、外部の状況は、外部トリガーがmessage_min_intervalよりも頻繁であるようにする可能性があります。したがって、この非常に動的なケースでの同期を回避するために、Jitteringをmessage_min_intervalに適用する必要があります。これにより、Jitterが使用されている場合でも、message_min_intervalがmessage_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 Originatorの値を自動的に認識しません。これには、message_intervalの値（または最小値）に関する事前の合意が必要になる場合があります。メッセージ_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 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.
[5]や[7]の完全な機能を使用したプロトコルを含む多くの場合、メッセージは潜在的にマルチメッサージパケットにホップバイホップで送信され、それらのメッセージの一部またはすべてを転送する必要がある場合があります。効率のために、これは単一のパケットにある必要があります。したがって、単一のパケットで受信したすべてのメッセージの転送ジッターは同じである必要があります。（これには、この場合、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は、中程度のアクセス制御フレーム期間よりも（たとえば、1桁以上の大きさよりも大きい）必要があります。
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 ジッターは衝突を減らすことを目的としているため、より大きなジッター、つまり、衝突の可能性が大きいときにマキシッターの価値の増加が適切です。これは、特にノード密度が増加している場合に当てはまります。これは、有用な信号範囲ではなく干渉範囲に比べて重要です。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[2] Moy、J。、「OSPFデータベースオーバーフロー」、RFC 1765、1995年3月。
[3] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1768, March 1995.
[3] Marlow、D。、「CLNPマルチキャストのホストグループ拡張」、RFC 1768、1995年3月。
[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.、ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 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] Clausen、T.、ed。、およびP. Jacquet、ed。、「最適化されたリンク状態ルーティングプロトコル（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] Perkins、C.、Belding-Royer、E。、およびS. Das、「アドホックオンデマンド距離ベクトル（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.、Dean、J。、およびC. Adjih、「一般化されたManetパケット/メッセージ形式」、作業中。
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).
著者は、このドキュメントに保持されている概念の開発とテストに関する貢献と議論について、MANETワーキンググループとOLSRV2デザインチーム、特にJoe MackerとJustin Dean（両方のNRL）を認めたいと考えています。）この仕様を慎重に検討するため。[5]で指定されているように、OLSRV1は、Gitte HansenとLars Christensen（その後、Aalborg University）によって徹底的にテストされたコントロールトラフィックに関するジッターの概念を導入しました。
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique, France
トーマス・ハイデ・クラウセン・リックス、エコール・ポリテクニック、フランス
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre
クリストファー・ディアローブ・ベイ・システムズアドバンステクノロジーセンター
Phone: +44 1245 242194
EMail: 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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。