Network Working Group B. Aboba, Ed.
Request for Comments: 4907 Internet Architecture Board
Category: Informational IAB
June 2007
Architectural Implications of Link Indications
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.
リンク指示は、リンクの状態に関するより高いレイヤにリンク層によって提供される情報を表します。このドキュメントはインターネットアーキテクチャ内でリンク指摘の役割について説明します。リンク指摘の賢明な使用は、パフォーマンス上の利点を提供することができるが、不適切な使用は、堅牢性とパフォーマンスの両方を低下させることができます。この文書は、現在の提案をまとめたアーキテクチャの問題について説明し、リンク指摘の適切かつ不適切な使用例を提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements ...............................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................5
1.4. Layered Indication Model ...................................7
2. Architectural Considerations ...................................14
2.1. Model Validation ..........................................15
2.2. Clear Definitions .........................................16
2.3. Robustness ................................................17
2.4. Congestion Control ........................................20
2.5. Effectiveness .............................................21
2.6. Interoperability ..........................................22
2.7. Race Conditions ...........................................22
2.8. Layer Compression .........................................25
2.9. Transport of Link Indications .............................26
3. Future Work ....................................................27
4. Security Considerations ........................................28
4.1. Spoofing ..................................................28
4.2. Indication Validation .....................................29
4.3. Denial of Service .........................................30
5. References .....................................................31
5.1. Normative References ......................................31
5.2. Informative References ....................................31
6. Acknowledgments ................................................40
Appendix A. Literature Review .....................................41
A.1. Link Layer .................................................41
A.2. Internet Layer .............................................53
A.3. Transport Layer ............................................55
A.4. Application Layer ..........................................60
Appendix B. IAB Members ...........................................60
A link indication represents information provided by the link layer to higher layers regarding the state of the link. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance.
リンク指示は、リンクの状態に関するより高いレイヤにリンク層によって提供される情報を表します。リンク指摘の賢明な使用は、パフォーマンス上の利点を提供することができるが、不適切な使用は、堅牢性とパフォーマンスの両方を低下させることができます。
This document summarizes the current understanding of the role of link indications within the Internet architecture, and provides advice to document authors about the appropriate use of link indications within the Internet, transport, and application layers.
このドキュメントはインターネットアーキテクチャ内でリンク指摘の役割の現在の理解を要約し、そしてインターネット、輸送、およびアプリケーション層内のリンク指摘の適切な使用に関する文書の作成者へのアドバイスを提供します。
Section 1 describes the history of link indication usage within the Internet architecture and provides a model for the utilization of link indications. Section 2 describes the architectural considerations and provides advice to document authors. Section 3 describes recommendations and future work. Appendix A summarizes the literature on link indications, focusing largely on wireless Local Area Networks (WLANs).
第1節は、インターネットアーキテクチャ内のリンク指示用法の歴史を説明し、リンク指摘を利用するためのモデルを提供します。第2節では、アーキテクチャの考慮事項について説明し、文書の作成者へのアドバイスを提供します。第3節ではお薦めや今後の作業について説明します。付録Aは、ワイヤレスローカルエリアネットワーク（WLAN）に大きく焦点を当て、リンク指摘に関する文献をまとめました。
The key words "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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Access Point (AP) A station that provides access to the fixed network (e.g., an 802.11 Distribution System), via the wireless medium (WM) for associated stations.
アクセスポイント（AP）は、関連する局に対する無線媒体（WM）を介して、固定ネットワーク（例えば、802.11ディストリビューションシステム）へのアクセスを提供するステーション。
Asymmetric A link with transmission characteristics that are different depending upon the relative position or design characteristics of the transmitter and the receiver is said to be asymmetric. For instance, the range of one transmitter may be much higher than the range of another transmitter on the same medium.
送信機と受信機の相対的な位置または設計特性に応じて異なる透過特性を有する非対称リンクが非対称であると言われます。例えば、一つの送信機の範囲は、同じ媒体上の他の送信機の範囲よりもはるかに高くてもよいです。
Beacon A control message broadcast by a station (typically an Access Point), informing stations in the neighborhood of its continuing presence, possibly along with additional status or configuration information.
ビーコン制御メッセージは、おそらく追加の状態や設定情報と共に、その継続的な存在の近傍における局に知らせる、ステーション（典型的にはアクセスポイント）によってブロードキャスト。
Binding Update (BU) A message indicating a mobile node's current mobility binding, and in particular its Care-of Address.
モバイルノードの現在のモビリティバインディングを示すメッセージ、および特にその気付アドレス（BY）バインディングアップデート。
Correspondent Node A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary.
コレスは、移動ノードが通信しているピア・ノードをノード。コレスポンデントノードは、モバイルまたは固定のいずれであってもよいです。
Link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below the Internet Protocol (IP).
ノードはリンク層で通信を行う通信設備または媒体のリンク、すなわち、直ちにインターネットプロトコル（IP）の下の層。
Link Down An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating data frames; transient periods of high frame loss are not sufficient.
インタフェースは、もはやデータフレームを通信することが可能であることに関連した状態の変化を意味するリンク層により提供されるイベントをリンクダウン。高フレーム損失の過渡期間は十分ではありません。
Link Indication Information provided by the link layer to higher layers regarding the state of the link.
リンクの状態に関する上位層へのリンク層によって提供されるリンクの表示情報。
Link Layer Conceptual layer of control or processing logic that is responsible for maintaining control of the link. The link layer functions provide an interface between the higher-layer logic and the link. The link layer is the layer immediately below the Internet Protocol (IP).
コントロールまたはリンクの制御を維持する責任がある処理ロジックのリンク層の概念層。リンク層の機能は上位層の論理とリンクとの間のインタフェースを提供します。リンク層は、すぐに、インターネットプロトコル（IP）の下の層です。
Link Up An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating data frames.
インターフェースは、データフレームを通信することが可能になっに関連する状態変化を意味するリンク層により提供されるイベントをリンクアップ。
Maximum Segment Size (MSS) The maximum payload size available to the transport layer.
最大セグメントサイズ（MSS）輸送層に使用可能な最大ペイロードサイズ。
Maximum Transmission Unit (MTU) The size in octets of the largest IP packet, including the IP header and payload, that can be transmitted on a link or path.
リンクまたはパス上で送信することができる最大転送単位（MTU）IPヘッダ及びペイロードを含む最大IPパケットのオクテットでサイズ、。
Mobile Node A node that can change its point of attachment from one link to another, while still being reachable via its home address.
モバイルノードはまだそのホームアドレス経由で到達可能でありながら、別のリンクから接続点を変更することができますノード。
Operable Address A static or dynamically assigned address that has not been relinquished and has not expired.
操作可能なアドレス放棄されておらず、有効期限が切れていない、静的または動的に割り当てられたアドレス。
Point of Attachment The endpoint on the link to which the host is currently connected.
結合点ホストが現在接続しているリンク上のエンドポイント。
Routable Address Any IP address for which routers will forward packets. This includes private addresses as specified in "Address Allocation for Private Internets" [RFC1918].
ルーティング可能なルータがパケットを転送するための任意のIPアドレス。 「個人的なインターネットのための配分」[RFC1918]で指定されたように、これはプライベートアドレスを含んでいます。
Station (STA) Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).
ステーション（STA）、無線媒体（WM）にIEEE 802.11準拠の媒体アクセス制御（MAC）及び物理層（PHY）インターフェースを含む任意のデバイス。
Strong End System Model The Strong End System model emphasizes the host/router distinction, tending to model a multi-homed host as a set of logical hosts within the same physical host. In the Strong End System model, addresses refer to an interface, rather than to the host to which they attach. As a result, packets sent on an outgoing interface have a source address configured on that interface, and incoming packets whose destination address does not correspond to the physical interface through which it is received are silently discarded.
強いエンドシステムモデルは、強力なエンドシステムモデルは、同一の物理ホスト内の論理ホストのセットとしてマルチホームホストをモデル化する傾向、ホスト/ルータの区別を強調しています。強力なエンドシステムモデルでは、アドレスはインタフェースにはなく、彼らは添付先のホストを参照してください。その結果、発信インターフェイス上で送信されるパケットは、そのインターフェイス上で設定されたソースアドレスを有し、宛先アドレスがそれを受信し、それを通して物理インターフェースに対応していない着信パケットは、黙って破棄されます。
Weak End System Model In the Weak End System model, addresses refer to a host. As a result, packets sent on an outgoing interface need not necessarily have a source address configured on that interface, and incoming packets whose destination address does not correspond to the physical interface through which it is received are accepted.
弱いエンドシステムモデルに弱いエンドシステムモデル、アドレスがホストを参照してください。その結果、発信インターフェイス上で送信されたパケットは、必ずしも、そのインターフェイス上で設定されたソースアドレスを有する必要はなく、宛先アドレスがそれを受信し、それを通して物理インターフェースに対応していない着信パケットは受け入れられます。
The use of link indications within the Internet architecture has a long history. In response to an attempt to send to a host that was off-line, the ARPANET link layer protocol provided a "Destination Dead" indication, described in "Fault Isolation and Recovery" [RFC816]. The ARPANET packet radio experiment [PRNET] incorporated frame loss in the calculation of routing metrics, a precursor to more recent link-aware routing metrics such as Expected Transmission Count (ETX), described in "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX].
インターネットアーキテクチャ内のリンク表示の使用は長い歴史を持っています。オフラインであったホストに送信しようとする試みに応答して、ARPANETリンク層プロトコルは、[RFC816「障害分離および回復」に記載された「宛先デッド」の表示を、提供しました。 ARPANETパケット無線実験[PRNET]ルーティングメトリックの計算に組み込まれたフレーム損失、このようなマルチホップのためのハイスループットパスメトリック」で説明予想伝送カウント（ETX）、などの前駆体より最近のリンク対応ルーティング・メトリック無線ルーティング」[ETX]。
"Routing Information Protocol" [RFC1058] defined RIP, which is descended from the Xerox Network Systems (XNS) Routing Information Protocol. "The OSPF Specification" [RFC1131] defined Open Shortest Path First, which uses Link State Advertisements (LSAs) in order to flood information relating to link status within an OSPF area. [RFC2328] defines version 2 of OSPF. While these and other routing protocols can utilize "Link Up" and "Link Down" indications provided by those links that support them, they also can detect link loss based on loss of routing packets. As noted in "Requirements for IP Version 4 Routers" [RFC1812]:
ゼロックスネットワークシステム（XNS）ルーティング情報プロトコルの子孫は「ルーティング情報プロトコル」[RFC1058]に定義RIP、。 「OSPF仕様」[RFC1131]はOSPFエリア内のリンク状態に関する情報をフラッディングするために、リンクステートアドバタイズメント（LSA）を使用する、最初のオープン最短パスを定義しました。 [RFC2328]はOSPFバージョン2を定義します。これらおよび他のルーティングプロトコルは、「リンクアップ」とそれらをサポートするそれらのリンクが提供する「リンクダウン」表示を利用することができますが、彼らはまた、ルーティングパケットの損失に基づいて、リンクの損失を検出することができます。 [RFC1812]「IPバージョン4つのルータのための要件」で説明したように：
It is crucial that routers have workable mechanisms for determining that their network connections are functioning properly. Failure to detect link loss, or failure to take the proper actions when a problem is detected, can lead to black holes.
ルータがネットワーク接続が正常に機能していることを決定するための実行可能なメカニズムを持っていることが重要です。リンク損失、または問題が検出されたときに、ブラックホールにつながることができ、適切な行動を取るために障害を検出に失敗します。
Attempts have also been made to define link indications other than "Link Up" and "Link Down". "Dynamically Switched Link Control Protocol" [RFC1307] defines an experimental protocol for control of links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring Down", and "Bring Up" states.
試みも、「リンクアップ」と「リンクダウン」以外のリンク表示を定義するために行われています。 [RFC1307]は、「ダウン」、「アップカミング」、「アップ」を取り入れ、リンクの制御のための実験的なプロトコルを定義し、「動的リンク制御プロトコルを交換」、「ゴーイング・ダウン」、「ダウンさせる」、および状態を「育てます」。
"A Generalized Model for Link Layer Triggers" [GenTrig] defines "generic triggers", including "Link Up", "Link Down", "Link Going Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger Rollback", and "Better Signal Quality AP Available". IEEE 802.21 [IEEE-802.21] defines a Media Independent Handover Event Service (MIH-ES) that provides event reporting relating to link characteristics, link status, and link quality. Events defined include "Link Down", "Link Up", "Link Going Down", "Link Signal Strength", and "Link Signal/Noise Ratio".
「リンクレイヤトリガのための一般化モデル」[GenTrig]「リンクアップ」を含む「一般的なトリガーを」、定義し、「リンクダウン」、「リンクがダウンして行く」、「リンクは上がって」、「リンク品質十字架しきい値」、「トリガーロールバック」、および 『利用可能なより良い信号品質AP』。 IEEE 802.21は、[IEEE-802.21]の特性をリンクする関連イベントのレポート、リンクステータス、およびリンク品質を提供メディア独立ハンドオーバイベントサービス（MIH-ES）を定義します。定義されたイベントは、「リンクダウン」、「リンクアップ」、「リンクのダウン」、「リンク信号強度」、および「リンク信号/雑音比」が含まれます。
Under ideal conditions, links in the "up" state experience low frame loss in both directions and are immediately ready to send and receive data frames; links in the "down" state are unsuitable for sending and receiving data frames in either direction.
理想的な条件の下では、両方の方向に「アップ」状態での経験、低フレーム損失のリンクとは、送信したデータフレームを受信する、すぐに準備ができています。 「ダウン」の状態のリンクはどちらかの方向にデータフレームを送受信するには適していません。
Unfortunately, links frequently exhibit non-ideal behavior. Wired links may fail in half-duplex mode, or exhibit partial impairment resulting in intermediate loss rates. Wireless links may exhibit asymmetry, intermittent frame loss, or rapid changes in throughput due to interference or signal fading. In both wired and wireless links, the link state may rapidly flap between the "up" and "down" states. This real-world behavior presents challenges to the integration of link indications with the Internet, transport, and application layers.
残念ながら、リンクは頻繁に非理想的な挙動を示します。有線リンクは、半二重モードで失敗する、または中間損失率が得られ、部分的障害を示すことができます。無線リンクは、干渉またはフェージング信号にアシンメトリ、間欠フレーム損失、またはスループットの急激な変化を示すことができます。有線と無線の両方のリンクでは、リンク状態が急速に「アップ」および「ダウン」状態の間でフラップしてもよいです。この現実世界の振る舞いインターネット、輸送、およびアプリケーションレイヤとのリンク指摘の統合への課題を提示します。
A layered indication model is shown in Figure 1 that includes both internally generated link indications (such as link state and rate) and indications arising from external interactions such as path change detection. In this model, it is assumed that the link layer provides indications to higher layers primarily in the form of abstract indications that are link-technology agnostic.
層状表示モデルは、内部で生成されたリンク（例えば、リンク状態と速度のような）指示とそのような経路変更検出などの外部の相互作用に起因する指示の両方を含むことが図1に示されています。このモデルでは、リンク層は、主にとらわれない、リンク技術です抽象的な徴候の形で上位層への表示を提供するものとします。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | |
Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! |
| ! ^ ^ |
| Connection Management ! ! Teardown |
Transport | ! ! |
Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+
| ! ! |
| ! ! |
| ^ ! |
| Transport Parameter Estimation ! |
|(MSS, RTT, RTO, cwnd, bw, ssthresh)! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ ^ ^ !
! ! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! Incoming !MIP ! ! ! |
| ! ! Interface !BU ! ! ! |
| ! ! Change !Receipt! ! ! |
| ! ^ ^ ^ ! ^ |
Internet | ! ! Mobility ! ! ! ! |
Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! Outgoing ! Path ! ! ! |
| ! ! Interface ! Change! ! ! |
| ^ ^ Change ^ ^ ! ^ |
| ! ! ! ! |
| ! Routing ! ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! v ! IP |
| ! ! Path ! Address |
| ! IP Configuration ^ Info ^ Config/ |
| ! ! Cache Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! !
! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! |
Link | ^ ^ |
Layer | Rate, FER, Link |
| Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model
図1.レイヤーの表示モデル
One of the functions of the Internet layer is to shield higher layers from the specifics of link behavior. As a result, the Internet layer validates and filters link indications and selects outgoing and incoming interfaces based on routing metrics.
インターネット層の機能の一つは、リンク動作の詳細から上位層を保護することです。その結果、インターネット層は、検証とフィルタが適応をリンクとルーティングメトリックに基づいて、送信および受信インターフェイスを選択します。
The Internet layer composes its routing table based on information available from local interfaces as well as potentially by taking into account information provided by routers. This enables the state of the local routing table to reflect link conditions on both local and remote links. For example, prefixes to be added or removed from the routing table may be determined from Dynamic Host Configuration Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements [RFC1256][RFC2461], redirect messages, or route updates incorporating information on the state of links multiple hops away.
インターネット層は、アカウントにルータによって提供される情報をとることによって、潜在的にローカルインタフェースから利用可能な情報に基づいてルーティングテーブルを構成するだけでなく、。これは、ローカルとリモートの両方のリンク上のリンク状態を反映するために、ローカルルーティングテーブルの状態を可能にします。たとえば、接頭辞を追加するか、動的ホスト構成プロトコル（DHCP）[RFC2131]、[RFC3315]、ルータ広告[RFC1256]、[RFC2461]から決定することができるルーティングテーブルから削除に関する情報を組み込んだメッセージ、またはルート更新をリダイレクトリンク複数の状態が離れてホップ。
As described in "Packetization Layer Path MTU Discovery" [RFC4821], the Internet layer may maintain a path information cache, enabling sharing of Path MTU information between concurrent or subsequent connections. The shared cache is accessed and updated by packetization protocols implementing packetization layer Path MTU Discovery.
「パケット化層のパスMTUディスカバリ」[RFC4821]に記載されているように、インターネット層は、同時または後続の接続との間の経路MTU情報の共有を可能にする、経路情報キャッシュを維持することができます。共有キャッシュにアクセスし、パケットレイヤパスMTUディスカバリを実装するパケット化プロトコルによって更新されます。
The Internet layer also utilizes link indications in order to optimize aspects of Internet Protocol (IP) configuration and mobility. After receipt of a "Link Up" indication, hosts validate potential IP configurations by Detecting Network Attachment (DNA) [RFC4436]. Once the IP configuration is confirmed, it may be determined that an address change has occurred. However, "Link Up" indications may not necessarily result in a change to Internet layer configuration.
インターネット層は、インターネットプロトコル（IP）の構成とモビリティの側面を最適化するために、リンク指摘を利用しています。 「リンクアップ」指示を受信した後、ホストはネットワークアタッチメント（DNA）[RFC4436]を検出することにより、潜在的なIP構成を検証します。 IPの設定が確認されると、アドレスの変更が発生したと判断することができます。しかし、「リンクアップ」表示は、必ずしもインターネット層の構成に変化をもたらさないかもしれません。
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of a "Link Up" indication, potential IP configurations are validated using a bidirectional reachability test. In "Detecting Network Attachment in IPv6 Networks (DNAv6)" [DNAv6], IP configuration is validated using reachability detection and Router Solicitation/Advertisement.
「IPv4の検出ネットワーク接続」[RFC4436]において、「リンクアップ」指示を受信した後、潜在的なIP構成は、双方向到達可能性テストを使用して検証されます。 「IPv6のネットワーク（DNAv6）で検出ネットワーク接続」に[DNAv6]、IP構成は到達可能性検出およびルータ要請/広告を使用して検証されます。
The routing sub-layer may utilize link indications in order to enable more rapid response to changes in link state and effective throughput. Link rate is often used in computing routing metrics. However, in wired networks the transmission rate may be negotiated in order to enhance energy efficiency [EfficientEthernet]. In wireless networks, the negotiated rate and Frame Error Rate (FER) may change with link conditions so that effective throughput may vary on a packet-by-packet basis. In such situations, routing metrics may also exhibit rapid variation.
ルーティングサブレイヤは、リンク状態と実効スループットの変化に対するより迅速な応答を可能にするためにリンク適応を利用することができます。リンク速度は、多くの場合、ルーティングメトリックを計算する際に使用されています。しかし、有線ネットワークにおける伝送速度は、エネルギー効率[EfficientEthernet]を増強するために交渉されてもよいです。実効スループットは、パケットごとに変化し得るように無線ネットワークでは、ネゴシエートされたレートとフレームエラーレート（FER）は、リンク条件によって変化することができます。このような状況では、ルーティングメトリックはまた、急速な変化を示すことができます。
Routing metrics incorporating link indications such as Link Up/Down and effective throughput enable routers to take link conditions into account for the purposes of route selection. If a link experiences decreased rate or high frame loss, the route metric will increase for the prefixes that it serves, encouraging use of alternate paths if available. When the link condition improves, the route metric will decrease, encouraging use of the link.
リンクなどのリンクアップ/ダウンなどの適応症と効果的なスループットを取り入れたルーティングメトリックは、経路選択の目的のために、アカウントにリンク状態を取るためにルータを有効にします。リンク経験レートまたは高いフレーム損失を減少させた場合は、ルートメトリックは、利用可能な場合に代替パスの使用を奨励し、それが機能するプレフィックスのために増加します。リンク状態が改善すると、ルートのメトリックは、リンクの使用を奨励し、減少します。
Within Weak End System implementations, changes in routing metrics and link state may result in a change in the outgoing interface for one or more transport connections. Routes may also be added or withdrawn, resulting in loss or gain of peer connectivity. However, link indications such as changes in transmission rate or frame loss do not necessarily result in a change of outgoing interface.
弱いエンドシステムの実装内で、ルーティングメトリックとリンク状態の変化は、一の以上のトランスポート接続のための発信インタフェースの変化をもたらすことができます。ルートは、ピア接続の損失又は利得をもたらす、追加または引き出すことができます。しかしながら、このような伝送速度またはフレーム損失の変化のようなリンク適応は、必ずしも発信インターフェースの変化をもたらしません。
The Internet layer may also become aware of path changes by other mechanisms, such as receipt of updates from a routing protocol, receipt of a Router Advertisement, dead gateway detection [RFC816] or network unreachability detection [RFC2461], ICMP redirects, or a change in the IPv4 TTL (Time to Live)/IPv6 Hop Limit of received packets. A change in the outgoing interface may in turn influence the mobility sub-layer, causing a change in the incoming interface. The mobility sub-layer may also become aware of a change in the incoming interface of a peer (via receipt of a Mobile IP Binding Update [RFC3775]).
インターネット層はまた、ルーティングプロトコルからの更新を受信すると、ルータ広告を受信し、停止ゲートウェイ検出[RFC816]またはネットワーク到達不能検出[RFC2461]、ICMPリダイレクト、または変更のような他のメカニズムによって経路変更に気付くことができますIPv4のTTL（生存時間）/受信パケットのIPv6のホップ限界です。発信インターフェースの変化は、今度は、着信インタフェースの変化を引き起こし、モビリティ副層に影響を及ぼし得ます。モビリティサブ層は、（モバイルIPバインディング更新[RFC3775]の受信を介して）ピアの着信インターフェイスの変化に気づくことができます。
The transport layer processes received link indications differently for the purposes of transport parameter estimation and connection management.
トランスポート層プロセスが輸送パラメータ推定と接続管理の目的のために、異なるリンク指摘を受けました。
For the purposes of parameter estimation, the transport layer is primarily interested in path properties that impact performance, and where link indications may be determined to be relevant to path properties they may be utilized directly. Link indications such as "Link Up"/"Link Down" or changes in rate, delay, and frame loss may prove relevant. This will not always be the case, however; where the bandwidth of the bottleneck on the end-to-end path is already much lower than the transmission rate, an increase in transmission rate may not materially affect path properties. As described in Appendix A.3, the algorithms for utilizing link layer indications to improve transport parameter estimates are still under development.
パラメータ推定の目的のために、トランスポート層は、衝撃性能路特性に主に関心がある、リンク適応は、それらが直接利用してもよい路特性に関連すると決定され得ます。率、遅延、フレーム損失のリンクなど、「リンクアップ」/「リンクダウン」などの表示や変更は、関連する証明することができます。これは、常にしかし、そうではありません。エンドツーエンドパス上のボトルネックの帯域が既に伝送レートよりはるかに低い場合、伝送速度の増加は著しく路特性に影響を与えないかもしれません。付録A.3で説明したように、トランスポート・パラメータ推定値を改善するために、リンク層の適応症を利用するためのアルゴリズムはまだ開発中です。
Strict layering considerations do not apply in transport path parameter estimation in order to enable the transport layer to make use of all available information. For example, the transport layer may determine that a link indication came from a link forming part of a path of one or more connections. In this case, it may utilize the receipt of a "Link Down" indication followed by a subsequent "Link Up" indication to infer the possibility of non-congestive packet loss during the period between the indications, even if the IP configuration does not change as a result, so that no Internet layer indication would be sent.
厳格な階層化の考慮事項は、利用可能なすべての情報を利用するために、トランスポート層を有効にするために、搬送路パラメータ推定には適用されません。例えば、トランスポートレイヤは、リンク表示は、1つのまたは複数の接続の経路の一部を構成するリンクから来たと判断してもよいです。この場合、IP構成が変更されない場合でも、適応症の間の期間中に非うっ血パケット損失の可能性を推測するために、後続の「リンクアップ」表示に続いて、「リンクダウン」指示の受信を利用することができます結果として、そのように何のインターネット層の表示が送信されないであろう。
The transport layer may also find Internet layer indications useful for path parameter estimation. For example, path change indications can be used as a signal to reset path parameter estimates. Where there is no default route, loss of segments sent to a destination lacking a prefix in the local routing table may be assumed to be due to causes other than congestion, regardless of the reason for the removal (either because local link conditions caused it to be removed or because the route was withdrawn by a remote router).
トランスポート層は、パスパラメータ推定のための便利なインターネット層の指摘を見つけることができます。例えば、経路変更指示は、パスパラメータ推定値をリセットするための信号として使用することができます。デフォルトルートが存在しない場合、ローカルルーティングテーブル内のプレフィクスを欠いている宛先に送信セグメントの損失にかかわらず、除去のための理由の（ローカルリンク状態がそれを引き起こしたいずれかのため、輻輳以外の原因によるものと仮定することができますルートがリモートルータによって引き出されたため）を除去又はれます。
For the purposes of connection management, layering considerations are important. The transport layer may tear down a connection based on Internet layer indications (such as a endpoint address changes), but does not take link indications into account. Just as a "Link Up" event may not result in a configuration change, and a configuration change may not result in connection teardown, the transport layer does not tear down connections on receipt of a "Link Down" indication, regardless of the cause. Where the "Link Down" indication results from frame loss rather than an explicit exchange, the indication may be transient, to be soon followed by a "Link Up" indication.
接続管理の目的のためには、レイヤーの考慮が重要です。トランスポート層は、（エンドポイントアドレスの変更など）は、インターネット層の指摘に基づいて接続を切断するが、アカウントにリンク指摘を取ることはありません。 「リンクアップ」イベントは、設定の変更を伴うないこと、および構成変更が接続ティアダウンにはならないことと同じように、トランスポート層は、原因にかかわらず、「リンクダウン」指示の受信の接続を切断しません。フレームの損失ではなく、明示的な交流から「リンクダウン」表示の結果は、表示が一過性でもある場合、すぐに「リンクアップ」表示を続けることにします。
Even where the "Link Down" indication results from an explicit exchange such as receipt of a Point-to-Point Protocol (PPP) Link Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or Deauthenticate frame, an alternative point of attachment may be available, allowing connectivity to be quickly restored. As a result, robustness is best achieved by allowing connections to remain up until an endpoint address changes, or the connection is torn down due to lack of response to repeated retransmission attempts.
例えばよいポイントツーポイントプロトコル（PPP）リンク制御プロトコル（LCP）-terminate又はIEEE 802.11解離または認証解除フレーム、アタッチメントの別のポイントの受信などの明示的な交換からもここで「リンクダウン」指示結果接続が迅速に復元することができ、利用可能です。その結果、ロバスト性は、最良の接続は、エンドポイントアドレスの変更まで残るようにすることによって達成される、又は接続が繰り返しによる再送信の試行に応答の欠如のために解体されます。
For the purposes of connection management, the transport layer is cautious with the use of Internet layer indications. Changes in the routing table are not relevant for the purposes of connection management, since it is desirable for connections to remain up during transitory routing flaps. However, the transport layer may tear down transport connections due to invalidation of a connection endpoint IP address. Where the connection has been established based on a Mobile
接続管理の目的のために、トランスポート層はインターネット層の指摘を使用して慎重です。接続が一時的なルーティングフラップの間にアップしたまますることが望ましいので、ルーティングテーブルの変更は、接続管理の目的のためには関係ありません。しかし、トランスポート層は、接続エンドポイントのIPアドレスの無効化に伴う交通機関の接続を切断します。接続はモバイルに基づいて確立された場合
IP home address, a change in the Care-of Address need not result in connection teardown, since the configuration change is masked by the mobility functionality within the Internet layer, and is therefore transparent to the transport layer.
IPホームアドレス、気付アドレスの変更は、接続ティアダウンにつながる必要はありません、設定の変更以来、インターネット層内のモビリティ機能によりマスクされ、したがって、トランスポート層に透過的です。
"Requirements for Internet Hosts -- Communication Layers" [RFC1122], Section 2.4, requires Destination Unreachable, Source Quench, Echo Reply, Timestamp Reply, and Time Exceeded ICMP messages to be passed up to the transport layer. [RFC1122], Section 4.2.3.9, requires Transmission Control Protocol (TCP) to react to an Internet Control Message Protocol (ICMP) Source Quench by slowing transmission.
「インターネットホストのための要件 - 通信層」[RFC1122]、2.4節では、トランスポート層まで渡されるICMPメッセージ宛先到達不能、元抑制、エコー応答、タイムスタンプ応答、および時間超過が必要です。 [RFC1122]、セクション4.2.3.9は、送信を遅らせることにより、インターネット制御メッセージプロトコル（ICMP）ソースクエンチ反応する伝送制御プロトコル（TCP）を必要とします。
[RFC1122], Section 4.2.3.9, distinguishes between ICMP messages indicating soft error conditions, which must not cause TCP to abort a connection, and hard error conditions, which should cause an abort. ICMP messages indicating soft error conditions include Destination Unreachable codes 0 (Net), 1 (Host), and 5 (Source Route Failed), which may result from routing transients; Time Exceeded; and Parameter Problem. ICMP messages indicating hard error conditions include Destination Unreachable codes 2 (Protocol Unreachable), 3 (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment Was Set). Since hosts implementing classical ICMP-based Path MTU Discovery [RFC1191] use Destination Unreachable code 4, they do not treat this as a hard error condition. Hosts implementing "Path MTU Discovery for IP version 6" [RFC1981] utilize ICMPv6 Packet Too Big messages. As noted in "TCP Problems with Path MTU Discovery" [RFC2923], classical Path MTU Discovery is vulnerable to failure if ICMP messages are not delivered or processed. In order to address this problem, "Packetization Layer Path MTU Discovery" [RFC4821] does depend on the delivery of ICMP messages.
[RFC1122]、セクション4.2.3.9は、アボートを起こす必要があるTCPは接続を中止させてはならないソフトエラー条件、およびハードエラー条件を示すICMPメッセージを区別します。ソフトエラー状態を示すICMPメッセージは、過渡のルーティングに起因し得る宛先到達不能コード0（NET）、1（ホスト）、および5（ソースルート失敗）、が挙げられます。時間超過。パラメタ問題。ハードエラー状態を示すICMPメッセージは、宛先到達不能コード2（プロトコル到達不能）、3（ポート到達不能）、および4（断片化必要とフラグメントが設定されたしないでください）が含まれます。ホストは、古典的なICMPベースのパスMTUディスカバリ[RFC1191]宛先到達不能コード4を使用し導入して以来、彼らはハードエラー条件としてこれを扱いません。 「IPバージョン6のパスMTUディスカバリー」を実施するホスト[RFC1981]のICMPv6パケットにあまりにも大きなメッセージを利用しています。 [RFC2923]「パスMTUディスカバリーとTCPの問題」で述べたようにICMPメッセージが配信または処理されていない場合は、クラシカルなパスMTUディスカバリは、障害に対して脆弱です。この問題に対処するために、「パケット化レイヤのパスMTUディスカバリ」[RFC4821] ICMPメッセージの配信に依存しません。
"Fault Isolation and Recovery" [RFC816], Section 6, states:
"障害分離と回復" [RFC816]、第6節では、状態：
It is not obvious, when error messages such as ICMP Destination Unreachable arrive, whether TCP should abandon the connection. The reason that error messages are difficult to interpret is that, as discussed above, after a failure of a gateway or network, there is a transient period during which the gateways may have incorrect information, so that irrelevant or incorrect error messages may sometimes return. An isolated ICMP Destination Unreachable may arrive at a host, for example, if a packet is sent during the period when the gateways are trying to find a new route. To abandon a TCP connection based on such a message arriving would be to ignore the valuable feature of the Internet that for many internal failures it reconstructs its function without any disruption of the end points.
このようICMP宛先到達不能などのエラーメッセージが到着したとき、それはTCPのコネクションを放棄すべきかどうか、明らかではありません。そのエラーメッセージが解釈するのが困難である理由は、上述したように、ゲートウェイまたはネットワークの障害が発生した後、無関係な又は誤ったエラーメッセージが時々返すことができるように、ゲートウェイは、誤った情報を有していてもよく、その間の過渡期間が存在する、ということです。パケットはゲートウェイが新しいルートを見つけようとしている期間中に送信された場合に孤立ICMP宛先到達不能は、例えば、ホストに到着する可能性があります。多くの内部障害のために、エンドポイントのいずれか中断することなく、その機能を再構築し、インターネットの貴重な機能を無視するだろう到着し、このようなメッセージに基づいてTCPコネクションを放棄します。
"Requirements for IP Version 4 Routers" [RFC1812], Section 4.3.3.3, states that "Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion", indicating that routers should not originate them. In general, since the transport layer is able to determine an appropriate (and conservative) response to congestion based on packet loss or explicit congestion notification, ICMP Source Quench indications are not needed, and the sending of additional Source Quench packets during periods of congestion may be detrimental.
[RFC1812]、セクション4.3.3.3、「IPバージョン4つのルータのための要件は、」ルータがそれらを発信べきではないことを示し、「研究は元抑制はネットワーク帯域幅を消費することを示唆しているようだが、渋滞に無効（不当な）解毒剤である」と述べています。トランスポート層は、パケット損失または明示的輻輳通知に基づいて渋滞に適切な（及び保守的）応答を決定することができるので、一般的に、ICMP Sourceは、指示が必要とされないクエンチし、輻輳の期間中に追加のソースクエンチパケットを送信してもよいです有害です。
"ICMP attacks against TCP" [Gont] argues that accepting ICMP messages based on a correct four-tuple without additional security checks is ill-advised. For example, an attacker forging an ICMP hard error message can cause one or more transport connections to abort. The authors discuss a number of precautions, including mechanisms for validating ICMP messages and ignoring or delaying response to hard error messages under various conditions. They also recommend that hosts ignore ICMP Source Quench messages.
「TCPに対するICMP攻撃」[Gont]は追加のセキュリティチェックなしで正しい4組に基づいてICMPメッセージを受け入れることは無分別であると主張しています。たとえば、ICMPハードエラーメッセージを鍛造攻撃者は、一の以上のトランスポート接続を中止することがあります。著者は、ICMPメッセージを検証して無視したり、様々な条件の下でハードエラーメッセージへの応答を遅延させるためのメカニズムを含む、予防措置の数を、議論します。彼らはまた、ホストがICMPソースクエンチメッセージを無視することをお勧めします。
The transport layer may also provide information to the link layer. For example, the transport layer may wish to control the maximum number of times that a link layer frame may be retransmitted, so that the link layer does not continue to retransmit after a transport layer timeout. In IEEE 802.11, this can be achieved by adjusting the Management Information Base (MIB) [IEEE-802.11] variables dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default: 4), which control the maximum number of retries for frames shorter and longer in length than dot11RTSThreshold, respectively. However, since these variables control link behavior as a whole they cannot be used to separately adjust behavior on a per-transport connection basis. In situations where the link layer retransmission timeout is of the same order as the path round-trip timeout, link layer control may not be possible at all.
トランスポート層は、リンク層に情報を提供することができます。例えば、トランスポート層は、リンク層、トランスポート層のタイムアウト後に再送し続けないように、リンク層フレームを再送信することができる最大回数を制御することを望むかもしれません。そしてdot11LongRetryLimit（デフォルト：4）で短く、より長いフレームの再試行の最大数を制御：IEEE 802.11は、これは[IEEE-802.11]変数dot11ShortRetryLimit（7デフォルト）管理情報ベース（MIB）を調整することによって達成することができますそれぞれdot11RTSThreshold、より長さ。しかし、全体としてこれらの変数の制御リンクの挙動ので、別々にあたり輸送の接続に基づき行動を調整するために使用することはできません。リンクレイヤ再送タイムアウトがパス往復タイムアウトと同じオーダーである状況では、リンク層制御は全く可能ではないかもしれません。
The transport layer provides indications to the application layer by propagating Internet layer indications (such as IP address configuration and changes), as well as providing its own indications, such as connection teardown.
トランスポート層（例えばIPアドレスの設定や変更など）は、インターネット層指示を伝播、並びに接続ティアダウンのような、独自の指標を提供することによって、アプリケーション層への表示を提供します。
Since applications can typically obtain the information they need more reliably from the Internet and transport layers, they will typically not need to utilize link indications. A "Link Up" indication implies that the link is capable of communicating IP packets, but does not indicate that it has been configured; applications should use an Internet layer "IP Address Configured" event instead. "Link Down" indications are typically not useful to applications, since they can be rapidly followed by a "Link Up" indication; applications should respond to transport layer teardown indications instead. Similarly, changes in the transmission rate may not be relevant to applications if the bottleneck bandwidth on the path does not change; the transport layer is best equipped to determine this. As a result, Figure 1 does not show link indications being provided directly to applications.
アプリケーションは通常、彼らはインターネット層とトランスポート層からより確実に必要な情報を得ることができるので、彼らは通常、リンク指摘を利用する必要はありません。 「リンクアップ」表示は、リンクがIPパケットを通信することが可能であるが、それが構成されていることを示していないことを意味します。アプリケーションでは、代わりにインターネット層「で構成されているIPアドレス」イベントを使用する必要があります。彼らは急速に「リンクアップ」表示を続けることができますので、「リンクダウン」表示は、通常のアプリケーションに有用ではありません。アプリケーションではなく、層のティアダウン兆候を輸送するために応答する必要があります。経路上のボトルネック帯域幅が変化しない場合は同様に、伝送速度の変化は、アプリケーションに関連しないかもしれません。輸送層は、最良これを決定するために装備されています。結果として、図1は、アプリケーションに直接提供されるリンク適応を示していません。
The complexity of real-world link behavior poses a challenge to the integration of link indications within the Internet architecture. While the literature provides persuasive evidence of the utility of link indications, difficulties can arise in making effective use of them. To avoid these issues, the following architectural principles are suggested and discussed in more detail in the sections that follow:
現実世界のリンクの挙動の複雑さは、インターネットアーキテクチャ内のリンク指摘の統合への挑戦を提起します。文献は、リンク表示の有用性の説得力のある証拠を提供していますが、難しさはそれらの有効活用に発生する可能性があります。これらの問題を回避するには、次の建築の原則が提案され、次のセクションで詳しく説明されています。
(1) Proposals should avoid use of simplified link models in circumstances where they do not apply (Section 2.1).
（1）提案は、彼らが（2.1節）を適用していない状況では簡略化されたリンクモデルの使用を避けるべきです。
(2) Link indications should be clearly defined, so that it is understood when they are generated on different link layers (Section 2.2).
それは理解されるように、それらは、異なるリンク層（第2.2節）に生成されたとき（2）リンク表示は明確に定義されなければなりません。
(3) Proposals must demonstrate robustness against spurious link indications (Section 2.3).
（3）提案は偽のリンク表示（2.3節）に対するロバスト性を示さなければなりません。
(4) Upper layers should utilize a timely recovery step so as to limit the potential damage from link indications determined to be invalid after they have been acted on (Section 2.3.2).
彼らは（2.3.2）に作用された後に無効であると決定されたリンク指摘からの潜在的な損傷を制限するように（4）上位層は、タイムリーな回収工程を利用すべきです。
(5) Proposals must demonstrate that effective congestion control is maintained (Section 2.4).
（5）提案は、効果的な輻輳制御（セクション2.4）に維持されることを実証しなければなりません。
(6) Proposals must demonstrate the effectiveness of proposed optimizations (Section 2.5).
（6）提案は、提案された最適化（2.5節）の有効性を実証しなければなりません。
(7) Link indications should not be required by upper layers, in order to maintain link independence (Section 2.6).
（7）リンク表示は、リンクの独立性（2.6節）を維持するために、上位層により要求されるべきではありません。
(8) Proposals should avoid race conditions, which can occur where link indications are utilized directly by multiple layers of the stack (Section 2.7).
（8）提案は、リンク表示がスタック（セクション2.7）の複数の層によって直接利用される場合に起こり得る、競合状態を避けるべきです。
(9) Proposals should avoid inconsistencies between link and routing layer metrics (Section 2.7.3).
（9）提案は、リンクとルーティング層メトリクス（セクション2.7.3）との間の不整合を避けるべきです。
(10) Overhead reduction schemes must avoid compromising interoperability and introducing link layer dependencies into the Internet and transport layers (Section 2.8).
（10）オーバーヘッド削減スキームは、相互運用性を損なうとインターネット層とトランスポート層（2.8節）へのリンク層の依存関係を導入することを避けなければなりません。
(11) Proposals for transport of link indications beyond the local host need to carefully consider the layering, security, and transport implications (Section 2.9).
ローカルホストを超えたリンク指摘の輸送のための（11）提案は慎重にレイヤ化、セキュリティ、および輸送への影響（2.9節）を考慮する必要があります。
Proposals should avoid the use of link models in circumstances where they do not apply.
提案は、彼らが適用されない状況で、リンクモデルの使用を避けるべきです。
In "The mistaken axioms of wireless-network research" [Kotz], the authors conclude that mistaken assumptions relating to link behavior may lead to the design of network protocols that may not work in practice. For example, the authors note that the three-dimensional nature of wireless propagation can result in large signal strength changes over short distances. This can result in rapid changes in link indications such as rate, frame loss, and signal strength.
「ワイヤレス・ネットワーク研究の誤解公理」で[Kotz]は、作者はリンクの動作に関する誤解仮定が実際に動作しない場合がありますネットワークプロトコルの設計につながる可能性があると結論します。例えば、著者らは、無線伝搬の三次元的性質は、短い距離にわたって大きな信号強度の変化をもたらすことができることに注意してください。これは、レート、フレーム損失、及び信号強度などのリンク適応の急激な変化をもたらすことができます。
In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], the authors provide examples of modeling mistakes and examples of how to improve modeling of link characteristics. To accompany the paper, the authors provide simulation scenarios in ns-2.
[GurtovFloyd]「トランスポートプロトコルのためのモデリングワイヤレスリンク」で、著者はモデリングミスやリンク特性のモデリングを改善する方法の例の例を提供しています。紙に同行するために、著者は、NS-2のシミュレーションシナリオを提供します。
In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], documents that describe capabilities that are dependent on link indications should explicitly articulate the assumptions of the link model and describe the circumstances in which they apply.
で説明した落とし穴を避けるために[Kotz] [GurtovFloyd]、リンク適応に依存している機能について説明した文書は、明示的にリンクモデルの仮定を明確にし、それらが適用される状況を説明しなければなりません。
Generic "trigger" models may include implicit assumptions that may prove invalid in outdoor or mesh wireless LAN deployments. For example, two-state Markov models assume that the link is either in a state experiencing low frame loss ("up") or in a state where few frames are successfully delivered ("down"). In these models, symmetry is also typically assumed, so that the link is either "up" in both directions or "down" in both directions. In situations where intermediate loss rates are experienced, these assumptions may be invalid.
一般的な「トリガー」のモデルには、屋外で無効な証明や無線LANの導入をメッシュも暗黙の仮定を含んでいてもよいです。例えば、二状態マルコフモデルは、リンク（「アップ」）、低フレーム損失を経験した状態で、またはいくつかのフレームが正常に配信された状態（「ダウン」）のいずれかであると仮定する。リンクは、両方の方向または両方の方向に「ダウン」の「アップ」のどちらかになるように、これらのモデルでは、対称性はまた、典型的には、想定されます。中間損失率が経験している状況では、これらの仮定は無効である可能性があります。
As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev], signal strength data is noisy and sometimes inconsistent, so that it needs to be filtered in order to avoid erratic results. Given this, link indications based on raw signal strength data may be unreliable. In order to avoid problems, it is best to combine signal strength data with other techniques. For example, in developing a "Going Down" indication for use with [IEEE-802.21] it would be advisable to
「IEEE 802.11のためのハイブリッドレート制御」[Haratcherev]で述べたように、それが不安定な結果を回避するために濾過される必要があるように、信号強度データは、騒々しい、時には矛盾しています。この与えられた、生の信号強度データに基づいて、リンク表示は信頼できないかもしれません。問題を回避するためには、他の技術と信号強度データを組み合わせることが最善です。たとえば、[IEEE-802.21]で使用するための「ゴーイング・ダウン」表示を開発する際にそれがすることをお勧めだろう
validate filtered signal strength measurements with other indications of link loss such as lack of Beacon reception.
このようなビーコン受信の欠如などのリンク損失の他の徴候とフィルタリングされた信号強度測定値を検証します。
Link indications should be clearly defined, so that it is understood when they are generated on different link layers. For example, considerable work has been required in order to come up with the definitions of "Link Up" and "Link Down", and to define when these indications are sent on various link layers.
それらは異なるリンクレイヤ上で生成されたときにそれが理解されているように、リンク表示は明確に定義する必要があります。例えば、かなりの作業が「リンクアップ」と「リンクダウン」の定義を考え出すと、これらの表示は、さまざまなリンクレイヤに送信されるときに定義するために必要とされていました。
Link indication definitions should heed the following advice:
リンク指示の定義は、以下のアドバイスに耳を傾ける必要があります。
(1) Do not assume symmetric link performance or frame loss that is either low ("up") or high ("down").
（1）のいずれか低い（「アップ」）または高（「ダウン」）である対称リンク性能やフレーム損失を前提としないでください。
In wired networks, links in the "up" state typically experience
low frame loss in both directions and are ready to send and
receive data frames; links in the "down" state are unsuitable
for sending and receiving data frames in either direction.
Therefore, a link providing a "Link Up" indication will
typically experience low frame loss in both directions, and high
frame loss in any direction can only be experienced after a link
provides a "Link Down" indication. However, these assumptions
may not hold true for wireless LAN networks. Asymmetry is
typically less of a problem for cellular networks where
propagation occurs over longer distances, multi-path effects may
be less severe, and the base station can transmit at much higher
power than mobile stations while utilizing a more sensitive
antenna.
Specifications utilizing a "Link Up" indication should not assume that receipt of this indication means that the link is experiencing symmetric link conditions or low frame loss in either direction. In general, a "Link Up" event should not be sent due to transient changes in link conditions, but only due to a change in link layer state. It is best to assume that a "Link Up" event may not be sent in a timely way. Large handoff latencies can result in a delay in the generation of a "Link Up" event as movement to an alternative point of attachment is delayed.
「リンクアップ」表示を活用仕様は、この表示の領収書は、リンクが対称リンク状態またはいずれかの方向に低フレームロスが発生していることを意味仮定するべきではありません。一般的には、「リンクアップ」イベントはだけによるリンク層の状態の変化に、リンク条件に過渡的変化に起因して送信されるべきではありません。これは、「リンクアップ」イベントは、タイムリーな方法で送信されない場合があることを前提とするのが最善です。添付ファイルの代替位置への移動が遅れたとして大きなハンドオフの待ち時間は、「リンクアップ」イベントが発生するの遅れにつながることができます。
(2) Consider the sensitivity of link indications to transient link conditions. Due to common effects such as multi-path interference, signal strength and signal to noise ratio (SNR) may vary rapidly over a short distance, causing erratic behavior of link indications based on unfiltered measurements. As noted in [Haratcherev], signal strength may prove most useful when
（2）過渡リンク状態へのリンク表示の感度を考慮してください。このようなマルチパス干渉などの一般的な効果のために、信号対雑音比（SNR）、信号強度と信号がフィルタリングされていない測定値に基づいてリンク適応の不安定な挙動を引き起こす、短い距離で急速に変化してもよいです。 【Haratcherev]で述べたように、信号強度は、場合に最も有用であることを証明することができます
utilized in combination with other measurements, such as frame
loss.
(3) Where possible, design link indications with built-in damping. By design, the "Link Up" and "Link Down" events relate to changes in the state of the link layer that make it able and unable to communicate IP packets. These changes are generated either by the link layer state machine based on link layer exchanges (e.g., completion of the IEEE 802.11i four-way handshake for "Link Up", or receipt of a PPP LCP-Terminate for "Link Down") or by protracted frame loss, so that the link layer concludes that the link is no longer usable. As a result, these link indications are typically less sensitive to changes in transient link conditions.
（3）内蔵の減衰と可能であれば、デザインリンク指摘を。設計により、「リンクアップ」と「リンクダウン」イベントは、IPパケットを通信することができるとできない作るリンク層の状態の変化に関連しています。これらの変更は、リンク層の交換（例えば、「リンクアップ」のためのIEEE 802.11iの4ウェイハンドシェイクの完了、またはPPP LCP-終了「リンクダウン」のための領収書）に基づいて、いずれかのリンク層ステートマシンによって生成されていますかリンク層は、リンクがもはや利用可能であると結論付けていないようで、フレーム損失を長期化。その結果、これらのリンクの表示は、通常、過渡リンク条件の変化に対して敏感です。
(4) Do not assume that a "Link Down" event will be sent at all, or that, if sent, it will be received in a timely way. A good link layer implementation will both rapidly detect connectivity failure (such as by tracking missing Beacons) while sending a "Link Down" event only when it concludes the link is unusable, not due to transient frame loss.
（4）「リンクダウン」イベントがまったく送信されます、または送信された場合には、それはタイムリーな方法で受信されることを前提としないでください。それは、リンクが一時フレーム損失によるものではない、使用不可能であると結論する場合にのみ、「リンクダウン」イベントを送信している間の良好なリンク層の実装は両方急速に（例えば欠けているビーコンを追跡することなどによって）接続障害を検出します。
However, existing wireless LAN implementations often do not do a good job of detecting link failure. During a lengthy detection phase, a "Link Down" event is not sent by the link layer, yet IP packets cannot be transmitted or received on the link. Initiation of a scan may be delayed so that the station cannot find another point of attachment. This can result in inappropriate backoff of retransmission timers within the transport layer, among other problems. This is not as much of a problem for cellular networks that utilize transmit power adjustment.
しかし、既存の無線LANの実装は、多くの場合、リンク障害を検出するのは良い仕事をしません。長い検出フェーズでは、「リンクダウン」イベントはリンクレイヤによって送信されていない、まだIPパケットは、リンク上で送信または受信することができません。ステーションは、アタッチメントの別のポイントを見つけることができないように、スキャンの開始を遅延させることができます。これは、他の問題のうち、トランスポート層、内再送タイマーの不適切なバックオフをもたらすことができます。これは、電力調整を送信活用携帯電話ネットワークのための問題の限りではありません。
Link indication proposals must demonstrate robustness against misleading indications. Elements to consider include:
リンク指示提案は誤解を招くような適応症に対するロバスト性を示さなければなりません。考慮すべき要素が含まれます：
Implementation variation Recovery from invalid indications Damping and hysteresis
無効なダンピング適応症およびヒステリシスから実装変動回復
Variations in link layer implementations may have a substantial impact on the behavior of link indications. These variations need to be taken into account in evaluating the performance of proposals. For example, radio propagation and implementation differences can impact the reliability of link indications.
リンクレイヤ実装の変化は、リンク適応の挙動に実質的な影響を有していてもよいです。これらの変化は、提案のパフォーマンスを評価する際に考慮される必要があります。例えば、電波伝搬と実装の違いは、リンク適応の信頼性に影響を与えることができます。
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], the authors analyze the cause of frame loss in a 38-node urban multi-hop IEEE 802.11 ad-hoc network. In most cases, links that are very bad in one direction tend to be bad in both directions, and links that are very good in one direction tend to be good in both directions. However, 30 percent of links exhibited loss rates differing substantially in each direction.
「802.11bのメッシュネットワークからのリンク・レベルの測定」[Aguayo]において、著者らは、38ノード都市マルチホップIEEE 802.11アドホックネットワークにおけるフレームロスの原因を分析します。ほとんどの場合、一つの方向に非常に悪いのリンクは両方向に悪い傾向にあり、かつ一方向に非常に優れているリンクは、両方向に良い傾向にあります。ただし、リンクの30パーセントは、各方向に、実質的に異なる損失率を示しました。
As described in [Aguayo], wireless LAN links often exhibit loss rates intermediate between "up" (low loss) and "down" (high loss) states, as well as substantial asymmetry. As a result, receipt of a "Link Up" indication may not necessarily indicate bidirectional reachability, since it could have been generated after exchange of small frames at low rates, which might not imply bidirectional connectivity for large frames exchanged at higher rates.
[Aguayo]で説明したように、無線LANのリンクは、多くの場合、（低損失）と「ダウン」（高損失）の状態だけでなく、かなりの非対称性「アップ」の間の中間の損失速度を示します。それは大きなフレームは、より高いレートで交換のための双方向の接続性を意味するものではないかもしれません低料金で小さなフレームの交換の後に生成されている可能性があるため、結果として、「リンクアップ」指示の受信は、必ずしも、双方向の到達可能性を示さないかもしれません。
Where multi-path interference or hidden nodes are encountered, signal strength may vary widely over a short distance. Several techniques may be used to reduce potential disruptions. Multiple transmitting and receiving antennas may be used to reduce multi-path effects; transmission rate adaptation can be used to find a more satisfactory transmission rate; transmit power adjustment can be used to improve signal quality and reduce interference; Request-to-Send/Clear-to-Send (RTS/CTS) signaling can be used to reduce hidden node problems. These techniques may not be completely effective, so that high frame loss may be encountered, causing the link to cycle between "up" and "down" states.
マルチパス干渉や隠れノードが発生した場合、信号強度は、短い距離にわたって広範囲に変化し得ます。いくつかの技術は、潜在的な混乱を軽減するために使用することができます。複数の送信および受信アンテナは、マルチパスの影響を低減するために使用されてもよいです。伝送レート適応は、より良好な伝送レートを見つけるために使用することができます。送信電力調整は、信号品質を改善し、干渉を低減するために使用することができます。送信要求/クリア・ツー・送信（RTS / CTS）シグナル伝達は、隠れ端末問題を軽減するために使用することができます。高フレーム損失が「アップ」及び「ダウン」状態との間のサイクルへのリンクを引き起こし、遭遇し得るように、これらの技術は、完全に有効ではないかもしれません。
To improve robustness against spurious link indications, it is recommended that upper layers treat the indication as a "hint" (advisory in nature), rather than a "trigger" dictating a particular action. Upper layers may then attempt to validate the hint.
スプリアスリンク適応に対するロバスト性を向上させるためには、上位層は「ヒント」（本質的に顧問）はなく、特定のアクションを指示「トリガー」として表示を治療することをお勧めします。上位層は、ヒントを検証しようとすることができます。
In [RFC4436], "Link Up" indications are rate limited, and IP configuration is confirmed using bidirectional reachability tests carried out coincident with a request for configuration via DHCP. As a result, bidirectional reachability is confirmed prior to activation of an IP configuration. However, where a link exhibits an intermediate loss rate, demonstration of bidirectional reachability may not necessarily indicate that the link is suitable for carrying IP data packets.
[RFC4436]で、「リンクアップ」表示はレートが制限され、およびIPの設定はDHCP経由で設定の要求と一致して行う双方向到達可能性テストを使用して確認されました。その結果、双方向の到達可能性は、前のIP構成の活性化に確認されました。しかしながら、リンクが中間損失率を示す場合、双方向到達可能性の実証は、必ずしもリンクがIPデータパケットを搬送するのに適していることを示すかもしれません。
Another example of validation occurs in IPv4 Link-Local address configuration [RFC3927]. Prior to configuration of an IPv4 Link-Local address, it is necessary to run a claim-and-defend protocol. Since a host needs to be present to defend its address against another claimant, and address conflicts are relatively likely, a host returning from sleep mode or receiving a "Link Up" indication could encounter an address conflict were it to utilize a formerly configured IPv4 Link-Local address without rerunning claim and defend.
検証の別の例は、IPv4リンクローカルアドレスの設定[RFC3927]で発生します。 IPv4のリンクローカルアドレスの設定の前に、請求-と-守るプロトコルを実行する必要があります。ホストが別の請求者に対して、そのアドレスを守るために存在する必要があり、アドレスの競合が比較的可能性がありますので、ホストスリープモードからの復帰または「リンクアップ」指示を受け取るには、アドレスの競合が発生する可能性があり、それは、以前設定されたIPv4リンクを利用していました請求および弁護を再実行せずに-localアドレス。
In some situations, improper use of link indications can result in operational malfunctions. It is recommended that upper layers utilize a timely recovery step so as to limit the potential damage from link indications determined to be invalid after they have been acted on.
いくつかの状況では、リンク表示の不適切な使用は、製品の動作不良が発生することができます。彼らが行動してきた後に無効であると判断リンク指摘からの潜在的な損傷を制限するように上位層は、タイムリーな回収工程を利用することをお勧めします。
In Detecting Network Attachment in IPv4 (DNAv4) [RFC4436], reachability tests are carried out coincident with a request for configuration via DHCP. Therefore, if the bidirectional reachability test times out, the host can still obtain an IP configuration via DHCP, and if that fails, the host can still continue to use an existing valid address if it has one.
IPv4の（DNAv4）[RFC4436]にネットワーク接続を検出する際に、到達可能性テストは、DHCPを介して設定するための要求と一致して行われます。双方向到達可能性テストがタイムアウトする場合はそのため、ホストがまだDHCP経由でIP設定を取得することができ、それが失敗した場合、ホストはまだそれが1を持っている場合は、既存の有効なアドレスを使用し続けることができます。
Where a proposal involves recovery at the transport layer, the recovered transport parameters (such as the Maximum Segment Size (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth (bw), congestion window (cwnd), etc.) should be demonstrated to remain valid. Congestion window validation is discussed in "TCP Congestion Window Validation" [RFC2861].
提案はトランスポート層での回復を必要とする場合、このような最大セグメントサイズ（MSS）、ラウンドトリップ時間（RTT）、再送信タイムアウト（RTO）、帯域幅（BW）、輻輳ウィンドウ（CWND）として復元輸送パラメータ（など）、有効なままに立証されなければなりません。輻輳ウィンドウ検証は、「TCP輻輳ウィンドウ検証」[RFC2861]で議論されています。
Where timely recovery is not supported, unexpected consequences may result. As described in [RFC3927], early IPv4 Link-Local implementations would wait five minutes before attempting to obtain a routable address after assigning an IPv4 Link-Local address. In one implementation, it was observed that where mobile hosts changed their point of attachment more frequently than every five minutes, they would never obtain a routable address. The problem was caused by an invalid link indication (signaling of "Link Up" prior to completion of link layer authentication), resulting in an initial failure to obtain a routable address using DHCP. As a result, [RFC3927] recommends against modification of the maximum retransmission timeout (64 seconds) provided in [RFC2131].
タイムリーな回復がサポートされていない場合は、予期しない結果が生じる可能性があります。 [RFC3927]で説明したように、早期のIPv4リンクローカルの実装は、IPv4リンクローカルアドレスを割り当てた後、ルーティング可能なアドレスを取得しようとする前に5分間待機していました。一の実装では、それは、モバイルホストは5分ごとよりも頻繁に添付ファイルの彼らのポイントを変更した場合、彼らはルーティング可能なアドレスを取得することはないことが観察されました。この問題は、DHCPを使用して、ルーティング可能なアドレスを取得する初期不良が生じる、無効リンク指示（前リンク層認証の完了に「リンクアップ」の信号）によって引き起こされました。結果として、[RFC3927]は、[RFC2131]に提供される最大再送タイムアウト時間（64秒）の変形に対してお勧めします。
Damping and hysteresis can be utilized to limit damage from unstable link indications. This may include damping unstable indications or placing constraints on the frequency of link indication-induced actions within a time period.
ダンピングとヒステリシスが不安定なリンク指摘から損傷を制限するために利用することができます。これは、不安定な表示を減衰又は時間内にリンク指示誘発性行動の頻度に制約を配置することを含むことができます。
While [Aguayo] found that frame loss was relatively stable for stationary stations, obstacles to radio propagation and multi-path interference can result in rapid changes in signal strength for a mobile station. As a result, it is possible for mobile stations to encounter rapid changes in link characteristics, including changes in transmission rate, throughput, frame loss, and even "Link Up"/"Link Down" indications.
[Aguayo]フレーム損失が固定局のために比較的安定であることがわかったが、電波伝搬及びマルチパス干渉への障害は、移動局に対する信号強度の急激な変化をもたらすことができます。移動局が伝送速度、スループット、フレーム損失、さらには「リンクアップ」/「リンクダウン」の適応症での変更を含むリンク特性の急激な変化に遭遇する結果として、それが可能です。
Where link-aware routing metrics are implemented, this can result in rapid metric changes, potentially resulting in frequent changes in the outgoing interface for Weak End System implementations. As a result, it may be necessary to introduce route flap dampening.
リンクアウェアルーティングメトリックが実現されるだけで、これは潜在的に弱いエンドシステムの実装のための発信インタフェースが頻繁に変化をもたらす、急速メトリック変化をもたらすことができます。その結果、ルートフラップダンプニングを導入する必要があるかもしれません。
However, the benefits of damping need to be weighed against the additional latency that can be introduced. For example, in order to filter out spurious "Link Down" indications, these indications may be delayed until it can be determined that a "Link Up" indication will not follow shortly thereafter. However, in situations where multiple Beacons are missed such a delay may not be needed, since there is no evidence of a suitable point of attachment in the vicinity.
しかし、減衰の利点を導入することができる追加のレイテンシと比較検討する必要があります。 「リンクアップ」表示はその後まもなく従わないと判断できるまで、例えば、偽の「リンクダウン」の表示をフィルタリングするために、これらの表示が遅れる場合があります。近傍のアタッチメントの適切な点の証拠がないので、複数のビーコンが失われる状況では、このような遅延は、必要とされなくてもよいです。
In some cases, it is desirable to ignore link indications entirely. Since it is possible for a host to transition from an ad-hoc network to a network with centralized address management, a host receiving a "Link Up" indication cannot necessarily conclude that it is appropriate to configure an IPv4 Link-Local address prior to determining whether a DHCP server is available [RFC3927] or an operable configuration is valid [RFC4436].
いくつかのケースでは、完全にリンク指摘を無視することが望ましいです。ホストが集中アドレス管理をネットワークにアドホックネットワークから移行することが可能であるため、「リンクアップ」指示を受信するホストは、必ずしも前決定へのIPv4リンクローカルアドレスを設定することが適切であると結論づけることはできませんDHCPサーバが利用可能であるかどうかを[RFC3927]または操作可能な構成が有効[RFC4436]です。
As noted in Section 1.4, the transport layer does not utilize "Link Up" and "Link Down" indications for the purposes of connection management.
第1.4節で述べたように、トランスポート層は、接続管理の目的のために「リンクアップ」と「リンクダウン」表示を利用していません。
Link indication proposals must demonstrate that effective congestion control is maintained [RFC2914]. One or more of the following techniques may be utilized:
リンク指示提案は、効果的な輻輳制御は[RFC2914]を維持していることを示さなければなりません。以下の技術の1つまたは複数を利用することができます。
Rate limiting. Packets generated based on receipt of link indications can be rate limited (e.g., a limit of one packet per end-to-end path RTO).
レート制限。パケットは、リンク指示の受信に基づいて生成されたレート制限され（例えば、エンドツーエンドパスRTOあたり1つのパケットの限界）であってもよいです。
Utilization of upper-layer indications. Applications should depend on upper-layer indications such as IP address configuration/change notification, rather than utilizing link indications such as "Link Up".
上位層の適応症の利用。アプリケーションは、むしろ、そのような「リンクアップ」などのリンク指摘を利用するよりも、そのようなIPアドレスの設定/変更通知などの上位層の適応症に依存しなければなりません。
Keepalives. In order to improve robustness against spurious link indications, an application keepalive or transport layer indication (such as connection teardown) can be used instead of consuming "Link Down" indications.
キープアライブ。スプリアスリンク適応に対するロバスト性を向上させるために、（例えば接続のティアダウンのような）アプリケーションキープアライブまたはトランスポート層の指示ではなく、「リンクダウン」指示を消費するのに用いることができます。
Conservation of resources. Proposals must demonstrate that they are not vulnerable to congestive collapse.
資源の保全。提案は、彼らがうっ血性崩壊に対して脆弱ではないことを証明しなければなりません。
As noted in "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust], decreasing transmission rate in response to frame loss increases contention, potentially leading to congestive collapse. To avoid this, the link layer needs to distinguish frame loss due to congestion from loss due to channel conditions. Only frame loss due to deterioration in channel conditions can be used as a basis for decreasing transmission rate.
「802.11無線ネットワークのロバスト速度適応」で述べたように、[ロバスト]、損失フレームに応答して伝送速度を減少させると、潜在的にうっ血性崩壊につながる、競合を増加させます。これを避けるために、リンク層は、チャネル条件に損失から渋滞によるフレームの損失を区別する必要があります。チャネル状態の劣化によるフレーム損失のみが伝送速度を減少させるための基礎として使用することができます。
Consider a proposal where a "Link Up" indication is used by a host to trigger retransmission of the last previously sent packet, in order to enable ACK reception prior to expiration of the host's retransmission timer. On a rapidly moving mobile node where "Link Up" indications follow in rapid succession, this could result in a burst of retransmitted packets, violating the principle of "conservation of packets".
「リンクアップ」表示を前に、ホストの再送タイマの満了にACKの受信を可能にするために、最後の前に送られたパケットの再送信をトリガするためにホストによって使用されている提案を考えてみましょう。 「リンクアップ」表示が矢継ぎ早に従って急速に移動する移動ノードでは、これは「パケットの保全」の原則に違反し、再送パケットのバーストにつながる可能性があります。
At the application layer, link indications have been utilized by applications such as Presence [RFC2778] in order to optimize registration and user interface update operations. For example, implementations may attempt presence registration on receipt of a "Link Up" indication, and presence de-registration by a surrogate receiving a "Link Down" indication. Presence implementations using "Link Up"/"Link Down" indications this way violate the principle of "conservation of packets" since link indications can be generated on a time scale less than the end-to-end path RTO. The problem is magnified since for each presence update, notifications can be delivered to many watchers. In addition, use of a "Link Up" indication in this manner is unwise since the interface may not yet even have an operable Internet layer configuration. Instead, an "IP address configured" indication may be utilized.
アプリケーション層で、リンク適応は、登録とユーザインターフェース更新動作を最適化するために、このようなプレゼンス[RFC2778]などのアプリケーションによって利用されてきました。例えば、実装は、「リンクダウン」指示を受信サロゲートによって「リンクアップ」指示の受信にプレゼンス登録及びプレゼンス登録解除を試みることができます。 「リンクアップ」/「リンクダウン」の適応症この方法を使用してプレゼンス実装はリンク表示は、エンドツーエンドのパスRTOよりも短い時間スケールで発生することができるので、「パケットの保全」の原則に違反します。各プレゼンス更新のために、通知は多くのウォッチャーに配信することができますので、問題が拡大しています。インタフェースがまだであっても動作可能なインターネット層構成を有していなくてもよいので、また、このように「リンクアップ」表示を使用することは賢明ではありません。代わりに、「IPアドレス構成」表示が利用されてもよいです。
Proposals must demonstrate the effectiveness of proposed optimizations. Since optimizations typically increase complexity, substantial performance improvement is required in order to make a compelling case.
提案は、提案された最適化の有効性を実証しなければなりません。最適化は、典型的には、複雑さを増大させるため、実質的な性能向上が説得力のあるケースを作るために必要とされます。
In the face of unreliable link indications, effectiveness may depend on the penalty for false positives and false negatives. In the case of DNAv4 [RFC4436], the benefits of successful optimization are modest, but the penalty for being unable to confirm an operable configuration is a lengthy timeout. As a result, the recommended strategy is to test multiple potential configurations in parallel in addition to attempting configuration via DHCP. This virtually guarantees that DNAv4 will always result in performance equal to or better than use of DHCP alone.
信頼できないリンク指摘の顔には、有効性が偽陽性と偽陰性のペナルティに依存してもよいです。 DNAv4 [RFC4436]の場合には、成功した最適化の利点は控えめであるが、操作可能な設定を確認することができないことに対するペナルティは、長いタイムアウトです。その結果、推奨戦略は、DHCPを介して設定を開始することに加えて、並列に複数の潜在的な構成をテストすることです。これは事実上、DNAv4はいつもと同じ単独DHCPの使用よりも優れた性能をもたらすことを保証します。
While link indications can be utilized where available, they should not be required by upper layers, in order to maintain link layer independence. For example, if information on supported prefixes is provided at the link layer, hosts not understanding those hints must still be able to obtain an IP address.
リンク表示が可能な場合に利用することができるが、それらは、リンク層の独立性を維持するために、上位層により要求されるべきではありません。たとえば、サポートプレフィックスに関する情報はリンク層で提供されている場合、これらのヒントを理解していないホストはまだIPアドレスを取得できなければなりません。
Where link indications are proposed to optimize Internet layer configuration, proposals must demonstrate that they do not compromise robustness by interfering with address assignment or routing protocol behavior, making address collisions more likely, or compromising Duplicate Address Detection (DAD) [RFC4429].
リンク表示がインターネット層構成を最適化するために提案されている場合は、提案は、彼らは、アドレス割り当てまたはルーティングプロトコルの動作に干渉アドレスの衝突可能性が高くなって、または重複を検出（DAD）[RFC4429]をアドレス妥協することにより、堅牢性を損なわないことを証明しなければなりません。
To avoid compromising interoperability in the pursuit of performance optimization, proposals must demonstrate that interoperability remains possible (potentially with degraded performance) even if one or more participants do not implement the proposal.
パフォーマンスの最適化を追求し、相互運用性を損なうことを避けるために、提案は相互運用性は、1つまたは複数の参加者が提案を実装していない場合でも、（潜在的に低下した性能で）可能性が残っていることを証明しなければなりません。
Link indication proposals should avoid race conditions, which can occur where link indications are utilized directly by multiple layers of the stack.
リンク指示提案は、リンク表示がスタックの複数の層によって直接利用される場合に発生することができます競合状態を避ける必要があります。
Link indications are useful for optimization of Internet Protocol layer addressing and configuration as well as routing. Although "The BU-trigger method for improving TCP performance over Mobile IPv6" [Kim] describes situations in which link indications are first processed by the Internet Protocol layer (e.g., MIPv6) before being utilized by the transport layer, for the purposes of parameter estimation, it may be desirable for the transport layer to utilize link indications directly.
リンク表示はインターネットプロトコルアドレス層や構成の最適化だけでなく、ルーティングのために便利です。 [金]「モバイルIPv6上のTCPの性能を改善するためのBUトリガ方法は、」パラメータの目的のためのリンク適応が最初のトランスポート層が利用される前に、インターネットプロトコル層（例えば、MIPv6の）により処理される状況を説明したがトランスポート層は、直接リンク指摘を利用するための推定は、それが望ましいことがあります。
In situations where the Weak End System model is implemented, a change of outgoing interface may occur at the same time the transport layer is modifying transport parameters based on other link indications. As a result, transport behavior may differ depending on the order in which the link indications are processed.
弱いエンドシステムモデルが実装されている状況では、発信インターフェースの変化は、トランスポート層は、他のリンクの指示に基づいて、トランスポートパラメータを変更すると同時に起こり得ます。その結果、搬送動作は、リンク表示が処理される順序に応じて異なっていてもよいです。
Where a multi-homed host experiences increasing frame loss or decreased rate on one of its interfaces, a routing metric taking these effects into account will increase, potentially causing a change in the outgoing interface for one or more transport connections. This may trigger Mobile IP signaling so as to cause a change in the incoming path as well. As a result, the transport parameters estimated for the original outgoing and incoming paths (congestion state, Maximum Segment Size (MSS) derived from the link maximum transmission unit (MTU) or Path MTU) may no longer be valid for the new outgoing and incoming paths.
そのインターフェイスのいずれかにフレーム消失又は減少率を増加させるマルチホームホスト経験が、増加するアカウントにこれらの効果を取るメトリックルーティングここで、潜在的に一つまたは複数のトランスポート接続のための発信インタフェースの変化を引き起こします。同様に、受信パスの変化を生じさせるようにこれは、モバイルIPシグナリングをトリガすることができます。結果として、元の送信および受信パスの推定されたトランスポートパラメータ（リンクの最大伝送単位（MTU）またはパスMTUに由来輻輳状態、最大セグメントサイズ（MSS））は、もはや新しい送信および受信のために有効でないかもしれませんパス。
To avoid race conditions, the following measures are recommended:
競合状態を避けるために、次の対策を推奨します。
Path change re-estimation Layering Metric consistency
パス変更再推定重ねるメトリックの整合性
When the Internet layer detects a path change, such as a major change in transmission rate, a change in the outgoing or incoming interface of the host or the incoming interface of a peer, or perhaps even a substantial change in the IPv4 TTL/IPv6 Hop Limit of received packets, it may be worth considering whether to reset transport parameters (RTT, RTO, cwnd, bw, MSS) to their initial values so as to allow them to be re-estimated. This ensures that estimates based on the former path do not persist after they have become invalid. Appendix A.3 summarizes the research on this topic.
インターネット層は、伝送速度の大きな変化、IPv4のTTL / IPv6のホップでホストまたはピアの着信インターフェイス、またはおそらく実質的な変化の発信または着信インターフェイスの変化としての経路の変更を検出した場合受信パケットの限界、それはそれらを再推定することが可能となるようにそれらの初期値にトランスポートパラメータ（RTT、RTO、CWND、BW、MSS）をリセットするかどうかを検討する価値であってもよいです。これは、彼らが無効になった後に元のパスに基づいて推定値は維持されないことを保証します。付録A.3は、このトピックに関する研究をまとめたものです。
Another technique to avoid race conditions is to rely on layering to damp transient link indications and provide greater link layer independence.
競合状態を避けるために別の技術は、過渡リンク指摘を減衰し、より大きなリンク層の独立性を提供するために、階層化に依存することです。
The Internet layer is responsible for routing as well as IP configuration and mobility, providing higher layers with an abstraction that is independent of link layer technologies.
インターネット層は、IPの構成や可動性だけでなく、ルーティングリンク層技術とは独立した抽象化して、より高い層を提供する責任があります。
In general, it is advisable for applications to utilize indications from the Internet or transport layers rather than consuming link indications directly.
一般的に、それはむしろ直接リンク指摘を消費するよりも、インターネットや輸送層からの指摘を利用するアプリケーションにお勧めです。
Proposals should avoid inconsistencies between link and routing layer metrics. Without careful design, potential differences between link indications used in routing and those used in roaming and/or link enablement can result in instability, particularly in multi-homed hosts.
提案は、リンクとルーティング層メトリクス間の不整合を避ける必要があります。慎重に設計することなく、リンクルーティングに使用される適応症及びローミングおよび/またはリンクの有効化に使用されるものとの間の電位差は、特に、マルチホームホストでは、不安定になることができます。
Once a link is in the "up" state, its effectiveness in transmission of data packets can be used to determine an appropriate routing metric. In situations where the transmission time represents a large portion of the total transit time, minimizing total transmission time is equivalent to maximizing effective throughput. "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX] describes a proposed routing metric based on the Expected Transmission Count (ETX). The authors demonstrate that ETX, based on link layer frame loss rates (prior to retransmission), enables the selection of routes maximizing effective throughput. Where the transmission rate is constant, the expected transmission time is proportional to ETX, so that minimizing ETX also minimizes expected transmission time.
リンクが「アップ」状態になると、データパケットの伝送におけるその有効性は、適切なルーティングメトリックを決定するために用いることができます。伝送時間は、総走行時間の大部分を表す状況では、総伝送時間を最小化する効果的なスループットを最大化することと等価です。 「マルチホップ無線ルーティングのためのハイスループットパスメトリック」[ETX]は予想伝送カウント（ETX）に基づいて提案されたルーティング・メトリックを記述する。著者らは、ETXは、リンク層フレーム損失率（前の再送に）に基づいて、効果的なスループットを最大化する経路の選択を可能にすることを実証しています。伝送速度が一定である最小化ETXはまた、予想伝送時間を最小限に抑えるように、予想伝送時間は、ETXに比例します。
However, where the transmission rate may vary, ETX may not represent a good estimate of the estimated transmission time. In "Routing in multi-radio, multi-hop wireless mesh networks" [ETX-Rate], the authors define a new metric called Expected Transmission Time (ETT). This is described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S is the size of the probe packet and B is the bandwidth of the link as measured by a packet pair [Morgan]. However, ETT assumes that the loss fraction of small probe frames sent at 1 Mbps data rate is indicative of the loss fraction of larger data frames at higher rates, which tends to underestimate the ETT at higher rates, where frame loss typically increases. In "A Radio Aware Routing Protocol for Wireless Mesh Networks" [ETX-Radio], the authors refine the ETT metric further by estimating the loss fraction as a function of transmission rate.
しかし、伝送レートが変化してもよい場合、ETXは、送信予定時刻の良好な推定値を表していてもよいです。 「マルチ無線、マルチホップ無線メッシュネットワークにおけるルーティング」[ETX-レート]では、著者は、送信時間（ETT）の予想と呼ばれる新しいメトリックを定義します。これは、Sは、プローブパケットのサイズであり、Bは、パケットペア[モーガン]によって測定されるように、リンクの帯域幅であるETT = ETX * S / B以降「ETX調整帯域幅」と記載されています。しかし、ETTは、1Mbpsのデータレートで送信された小さなプローブ用フレームの損失率がフレーム損失は、典型的には増加より高いレートにてETTを過小評価する傾向がより高い速度でより大きなデータフレームの損失割合の指標であることを前提としています。 「無線メッシュネットワークのための無線アウェアルーティングプロトコル」[ETX-ラジオ]において、著者らは、伝送レートの関数としての損失の割合を推定することにより、ETTメトリックさらにを絞り込みます。
However, prior to sending data packets over the link, the appropriate routing metric may not easily be predicted. As noted in [Shortest], a link that can successfully transmit the short frames utilized for control, management, or routing may not necessarily be able to reliably transport larger data packets.
しかし、リンクを介してデータパケットを送信する前に、適切なルーティングメトリックは、容易に予測することはできません。 [最短]で述べたように、正常に制御、管理、またはルーティングのために利用ショートフレームを送信することができるリンクが必ずしも確実に大きなデータパケットを移送することができないかもしれません。
Therefore, it may be necessary to utilize alternative metrics (such as signal strength or Access Point load) in order to assist in attachment/handoff decisions. However, unless the new interface is the preferred route for one or more destination prefixes, a Weak End System implementation will not use the new interface for outgoing traffic. Where "idle timeout" functionality is implemented, the unused interface will be brought down, only to be brought up again by the link enablement algorithm.
したがって、取り付け/ハンドオフ決定を補助するために、（例えば、信号強度またはアクセスポイントの負荷のような）別のメトリックを利用する必要があるかもしれません。新しいインターフェイスは、1つのまたは複数の宛先プレフィックスのための好ましい経路である場合を除きしかし、弱いエンドシステムの実装では、発信トラフィック用の新しいインターフェイスを使用することはありません。 「アイドルタイムアウト」機能が実装されている場合は、未使用のインターフェイスは、リンクのみ有効化アルゴリズムによって再び育てなければ、倒されます。
Within the link layer, metrics such as signal strength and frame loss may be used to determine the transmission rate, as well as to determine when to select an alternative point of attachment. In order to enable stations to roam prior to encountering packet loss, studies such as "An experimental study of IEEE 802.11b handover performance and its effect on voice traffic" [Vatn] have suggested using signal strength as a mechanism to more rapidly detect loss of connectivity, rather than frame loss, as suggested in "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time" [Velayos].
リンク層内に、そのような信号強度とフレームの損失などのメトリックは、伝送速度を決定するために、ならびに添付の別のポイントを選択するかを決定するために使用することができます。前パケット損失が発生するローミングするステーションを可能にするために、そのような「IEEE 802.11bのハンドオーバ性能と音声トラフィックへの影響の実験的研究」[VATN]などの研究では、より迅速に損失を検出するための機構として信号強度を使用して提案しています「IEEE 802.11bのMACレイヤハンドオーバ時間を短縮する技術」[ベラヨス]で提案されているようではなく、フレーム損失よりも接続性、。
[Aguayo] notes that signal strength and distance are not good predictors of frame loss or throughput, due to the potential effects of multi-path interference. As a result, a link brought up due to good signal strength may subsequently exhibit significant frame loss and a low throughput. Similarly, an Access Point (AP) demonstrating low utilization may not necessarily be the best choice, since utilization may be low due to hardware or software problems. "OSPF Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link-utilization-based routing metrics have a history of instability.
[Aguayo]強度と距離信号のノートは、マルチパス干渉の潜在的影響に起因するフレーム損失やスループットの良好な予測因子は、ではありません。その結果、リンクはその後、大きなフレームの損失と低いスループットを示すことができるため、良好な信号強度を育てました。利用率は、ハードウェアまたはソフトウェアの問題に起因する低いかもしれないので、同様に、低利用率を実証したアクセスポイント（AP）は、必ずしも、最良の選択ではないかもしれません。 「OSPF最適化されたマルチパス（OSPF-OMP）は、」[Villamizar]リンク利用率ベースのルーティングメトリックは、不安定性の歴史を持っていることを指摘します。
In many situations, the exchanges required for a host to complete a handoff and reestablish connectivity are considerable, leading to proposals to combine exchanges occurring within multiple layers in order to reduce overhead. While overhead reduction is a laudable goal, proposals need to avoid compromising interoperability and introducing link layer dependencies into the Internet and transport layers.
多くの状況では、ハンドオフを完了し、接続を再確立するためにホストに必要な交換は、オーバーヘッドを削減するために、複数の層内で発生した交流を組み合わせることが提案につながる、かなりあります。オーバーヘッドの削減は称賛に値する目標ですが、提案は、相互運用性を損なうとインターネット層とトランスポート層へのリンク層の依存関係を導入しないようにする必要があります。
Exchanges required for handoff and connectivity reestablishment may include link layer scanning, authentication, and association establishment; Internet layer configuration, routing, and mobility exchanges; transport layer retransmission and recovery; security association reestablishment; application protocol re-authentication and re-registration exchanges, etc.
ハンドオフと接続再確立のために必要な交換は、リンク層スキャニング、認証、アソシエーションの確立を含むことができます。インターネット層構成、ルーティング、およびモビリティ交換機。トランスポート層の再送と回復。セキュリティアソシエーション再確立。アプリケーションプロトコルの再認証および再登録の交換、等
Several proposals involve combining exchanges within the link layer. For example, in [EAPIKEv2], a link layer Extensible Authentication Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP address assignment, potentially bypassing Internet layer configuration. Within [PEAP], it is proposed that a link layer EAP exchange be used for the purpose of carrying Mobile IPv6 Binding Updates. [MIPEAP] proposes that EAP exchanges be used for configuration of Mobile IPv6. Where link, Internet, or transport layer mechanisms are combined, hosts need to maintain backward compatibility to permit operation on networks where compression schemes are not available.
いくつかの提案は、リンク層内の交流を組み合わせることを含みます。例えば、[EAPIKEv2]で、リンクレイヤ拡張認証プロトコル（EAP）[RFC3748]交換は、潜在的にインターネット層構成をバイパスして、IPアドレスの割り当てのために使用することができます。 [PEAP]内には、リンク層EAP交換がモバイルIPv6バインディング更新を運ぶ目的のために使用することが提案されています。 【MIPEAP] EAP交換は、モバイルIPv6の構成のために使用することが提案されています。リンク、インターネット、またはトランスポート層のメカニズムが組み合わされている場合、ホストは、圧縮方式が利用できないネットワーク上での動作を可能にするために、下位互換性を維持する必要があります。
Layer compression schemes may also negatively impact robustness. For example, in order to optimize IP address assignment, it has been proposed that prefixes be advertised at the link layer, such as within the 802.11 Beacon and Probe Response frames. However, [IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be assigned dynamically, so that prefix(es) advertised within the Beacon and/or Probe Response may not correspond to the prefix(es) configured by the Internet layer after the host completes link layer authentication. Were the host to handle IP configuration at the link layer rather than within the Internet layer, the host might be unable to communicate due to assignment of the wrong IP address.
層の圧縮方式にもマイナスの堅牢性に影響を与える可能性があります。例えば、IPアドレスの割り当てを最適化するためには、プレフィクスは、802.11ビーコンおよびプローブ応答フレーム内のように、リンク層でアドバタイズすることが提案されています。しかし、[IEEE-802.1X]ビーコンおよび/またはプローブ応答内に広告さ接頭語（ES）は、インターネット層で構成プレフィックス（ES）に対応しないように、動的に割り当てられる仮想LAN識別子（VLANID）を可能にホストの後に、リンク層認証を完了します。リンク層ではなく、インターネット層内のIP設定を処理するためのホストだった、ホストが原因間違ったIPアドレスの割り当てと通信できないことがあります。
Proposals for the transport of link indications need to carefully consider the layering, security, and transport implications.
リンク指摘の輸送のための提案は、慎重にレイヤ化、セキュリティ、および輸送への影響を考慮する必要があります。
As noted earlier, the transport layer may take the state of the local routing table into account in improving the quality of transport parameter estimates. While absence of positive feedback that the path is sending data end-to-end must be heeded, where a route that had previously been absent is recovered, this may be used to trigger congestion control probing. While this enables transported link indications that affect the local routing table to improve the quality of transport parameter estimates, security and interoperability considerations relating to routing protocols still apply.
先に述べたように、トランスポート層は、トランスポートパラメータ推定値の品質を改善する上で考慮ローカルルーティングテーブルの状態をとることができます。経路はエンドツーエンドのデータを送信していることを正のフィードバックの欠如が留意されなければならないが、以前に不在であったルートが回収される場合、これはプロービング輻輳制御をトリガーするために使用することができます。これは、トランスポートパラメータ推定値の品質を改善するために、ローカルルーティングテーブルに影響を与える輸送リンクの表示を可能にしながら、ルーティングプロトコルに関連するセキュリティと相互運用性の考慮が適用されます。
Proposals involving transport of link indications need to demonstrate the following:
リンク指摘の輸送を伴う提案は、次のことを実証する必要があります。
(a) Superiority to implicit signals. In general, implicit signals are preferred to explicit transport of link indications since they do not require participation in the routing mesh, add no new packets in times of network distress, operate more reliably in the presence of middle boxes such as NA(P)Ts, are more likely to be backward compatible, and are less likely to result in security vulnerabilities. As a result, explicit signaling proposals must prove that implicit signals are inadequate.
暗黙的な信号の（a）の優位。それらは、ルーティングメッシュの参加を必要とするネットワーク苦痛の時代に新たなパケットを追加しない、そのようなNA（P）TSと中央ボックスの存在下で、より確実に動作しないので、一般的に、暗黙的な信号は、リンク適応の明示的な輸送に好ましいです、下位互換性がある可能性が高い、とセキュリティの脆弱性につながる可能性が低いです。その結果、明示的なシグナリングの提案は、暗黙的な信号が不十分であることを証明しなければなりません。
(b) Mitigation of security vulnerabilities. Transported link indications should not introduce new security vulnerabilities. Link indications that result in modifications to the local routing table represent a routing protocol, so that the vulnerabilities associated with unsecured routing protocols apply, including spoofing by off-link attackers. While mechanisms such as "SEcure Neighbor Discovery (SEND)" [RFC3971] may enable authentication and integrity protection of router-originated messages, protecting against forgery of transported link indications, they are not yet widely deployed.
（b）は、セキュリティの脆弱性の軽減を。輸送リンク表示は、新たなセキュリティの脆弱性を導入してはなりません。保護されていないルーティングプロトコルに関連した脆弱性は、オフリンク攻撃者によってスプーフィングなど、適用するようにローカルルーティングテーブルに変更を生じるリンク適応は、ルーティングプロトコルを表します。そのような「セキュア近隣探索（SEND）」[RFC3971]などのメカニズムが輸送リンク表示の偽造に対する保護、ルータから発信されたメッセージの認証と完全性保護を可能にするかもしれないが、彼らはまだ広く展開されていません。
(c) Validation of transported indications. Even if a transported link indication can be integrity protected and authenticated, if the indication is sent by a host off the local link, it may not be clear that the sender is on the actual path in use, or which transport connection(s) the indication relates to. Proposals need to describe how the receiving host can validate the transported link indication.
搬送指示の（C）の検証。搬送リンク指示が完全性を保護し、認証することができれば表示はローカルリンクオフホストによって送信される場合、送信者が使用中の実際のパス上にあることは明らかではないかもしれない、またはそのトランスポート接続（S）指示がに関する。提案は受信ホストが運ばリンク表示を検証する方法について説明する必要があります。
(d) Mapping of Identifiers. When link indications are transported, it is generally for the purposes of providing information about Internet, transport, or application layer operations at a remote element. However, application layer sessions or transport connections may not be visible to the remote element due to factors such as load sharing between links, or use of IPsec, tunneling protocols, or nested headers. As a result, proposals need to demonstrate how the link indication can be mapped to the relevant higher-layer state. For example, on receipt of a link indication, the transport layer will need to identify the set of transport sessions (source address, destination address, source port, destination port, transport) that are affected. If a presence server is receiving remote indications of "Link Up"/"Link Down" status for a particular Media Access Control (MAC) address, the presence server will need to associate that MAC address with the identity of the user (pres:user@example.com) to whom that link status change is relevant.
（D）識別子のマッピング。リンク表示が搬送される場合には、遠隔構成要素、インターネット、輸送、またはアプリケーション層の動作についての情報を提供する目的のために一般的です。しかしながら、アプリケーション層のセッションまたは輸送の接続は、そのようなリンク、またはIPsecの、トンネリングプロトコル、またはネストされたヘッダの使用の間に負荷分散などの要因に遠隔素子には見えないかもしれません。その結果、提案は、リンク表示は、関連する上位レイヤの状態にマッピングすることができる方法を実証する必要があります。例えば、リンク指示を受信すると、トランスポート層は、影響を受けるトランスポートセッション（ソースアドレス、宛先アドレス、送信元ポート、宛先ポート、トランスポート）のセットを識別するために必要であろう。ユーザー：プレゼンスサーバは、特定のメディアアクセス制御（MAC）アドレスのために「リンクアップ」/「リンクダウン」状態のリモート表示を受信している場合は、プレゼンスサーバは、MACは、ユーザー（PRESのアイデンティティと取り組むことを関連付ける必要があります@ example.com）誰にそのリンクステータス変更が関連しています。
Further work is needed in order to understand how link indications can be utilized by the Internet, transport, and application layers.
さらなる研究は、リンク表示は、インターネットが利用することができる方法を理解するために、輸送、およびアプリケーション層で必要とされます。
More work is needed to understand the connection between link indications and routing metrics. For example, the introduction of block ACKs (supported in [IEEE-802.11e]) complicates the relationship between effective throughput and frame loss, which may necessitate the development of revised routing metrics for ad-hoc networks. More work is also needed to reconcile handoff metrics (e.g., signal strength and link utilization) with routing metrics based on link indications (e.g., frame error rate and negotiated rate).
より多くの作業がリンクの表示およびルーティングメトリックとの間の接続を理解するために必要とされます。例えば、ブロックのACK（[IEEE-802.11eの]でサポートされている）の導入は、アドホックネットワークのための改訂ルーティング・メトリックの開発を必要とすることができる、効果的なスループット及びフレーム損失との関係を複雑にします。より多くの仕事はまた、リンク適応（例えば、フレームエラーレートとネゴシエートレート）に基づいて、ルーティング・メトリックとハンドオフ指標（例えば、信号強度、リンクの利用率）を調整するために必要とされます。
A better understanding of the use of physical and link layer metrics in rate negotiation is required. For example, recent work [Robust][CARA] has suggested that frame loss due to contention (which would be exacerbated by rate reduction) can be distinguished from loss due to channel conditions (which may be improved via rate reduction).
レート交渉における物理およびリンクレイヤメトリックの使用のより良い理解が必要です。例えば、[ロバスト]最近の研究は、[CARA]（速度低下によって悪化される）による競合のフレーム損失が原因（速度低下を介して改善することができる）は、チャネル条件に損失から区別することができることを示唆しています。
At the transport layer, more work is needed to determine the appropriate reaction to Internet layer indications such as routing table and path changes. More work is also needed in utilization of link layer indications in transport parameter estimation, including rate changes, "Link Up"/"Link Down" indications, link layer retransmissions, and frame loss of various types (due to contention or channel conditions).
トランスポート層で、より多くの仕事は、ルーティングテーブルとパスの変更などのインターネット層の適応症に適切な反応を決定するために必要とされます。より多くの仕事は、レートの変動、「リンクアップ」/「リンクダウン」の適応症、リンク層再送信、および様々な種類のフレームロス（競合によりまたはチャネル条件）を含め、輸送パラメータ推定にリンクレイヤ指摘の利用に必要とされています。
More work is also needed to determine how link layers may utilize information from the transport layer. For example, it is undesirable for a link layer to retransmit so aggressively that the link layer round-trip time approaches that of the end-to-end transport connection. Instead, it may make sense to do downward rate adjustment so as to decrease frame loss and improve latency. Also, in some cases, the transport layer may not require heroic efforts to avoid frame loss; timely delivery may be preferred instead.
より多くの仕事はまた、リンク層、トランスポート層からの情報を利用することができる方法を決定するために必要とされます。例えば、それは、リンク層の往復時間は、エンドツーエンドのトランスポート接続のものに近づけるように積極的に再送信するためのリンク層のために望ましくありません。フレーム損失を減少させ、レイテンシを改善するために代わりに、下向きにレート調整を行うために意味をなすことができます。また、いくつかのケースでは、トランスポート層は、フレームの損失を回避するために英雄的な努力を必要としないかもしれません。タイムリーな配信ではなく、好ましいかもしれません。
Proposals for the utilization of link indications may introduce new security vulnerabilities. These include:
リンク指摘を利用するための提案は、新たなセキュリティの脆弱性を導入することができます。これらは、次のとおりです。
Spoofing Indication validation Denial of service
サービスのなりすまし表示検証拒否
Where link layer control frames are unprotected, they may be spoofed by an attacker. For example, PPP does not protect LCP frames such as LCP-Terminate, and [IEEE-802.11] does not protect management frames such as Associate/Reassociate, Disassociate, or Deauthenticate.
リンク層制御フレームが保護されていない場合、それらは攻撃者によって偽装されていてもよいです。例えば、PPPは、LCP-終了としてLCPフレームを保護しない、および[IEEE-802.11]そのような関連付け/再関連付け、解離、または認証解除などの管理フレームを保護しません。
Spoofing of link layer control traffic may enable attackers to exploit weaknesses in link indication proposals. For example, proposals that do not implement congestion avoidance can enable attackers to mount denial-of-service attacks.
リンク層制御トラフィックのスプーフィングは、リンク指示提案の弱点を悪用する攻撃を可能にします。例えば、輻輳回避を実装していない提案は、サービス拒否攻撃をマウントするために、攻撃者を有効にすることができます。
However, even where the link layer incorporates security, attacks may still be possible if the security model is not consistent. For example, wireless LANs implementing [IEEE-802.11i] do not enable
セキュリティモデルが一貫していない場合は、リンク層は、セキュリティを組み込んだ場合でも、攻撃はまだ可能かもしれません。たとえば、[IEEE-802.11i規格]を実装する無線LANが有効にしないでください
stations to send or receive IP packets on the link until completion of an authenticated key exchange protocol known as the "4-way handshake". As a result, a link implementing [IEEE-802.11i] cannot be considered usable at the Internet layer ("Link Up") until completion of the authenticated key exchange.
「4ウェイハンドシェイク」として知られている認証された鍵交換プロトコルが完了するまでのリンク上でIPパケットを送受信するステーション。結果として、[IEEE-802.11i規格]を実装するリンクは、認証鍵交換が完了するまでインターネット層（「リンクアップ」）で使用可能と考えることができません。
However, while [IEEE-802.11i] requires sending of authenticated frames in order to obtain a "Link Up" indication, it does not support management frame authentication. This weakness can be exploited by attackers to enable denial-of-service attacks on stations attached to distant Access Points (APs).
しかし、一方で[IEEE-802.11i規格]は、「リンクアップ」表示を得るために、認証されたフレームの送信を必要とし、それは管理フレームの認証をサポートしていません。この弱点は、遠くのアクセスポイント（AP）に添付ステーション上のサービス拒否攻撃を可能にするために、攻撃者によって悪用される可能性があります。
In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends a Reassociation Response. At that point, the AP sends a spoofed frame with the station's source address to a multicast address, thereby causing switches within the Distribution System (DS) to learn the station's MAC address. While this enables forwarding of frames to the station at the new point of attachment, it also permits an attacker to disassociate a station located anywhere within the ESS, by sending an unauthenticated Reassociation Request frame.
[IEEE-802.11F]では、「リンクアップ」はAPが再アソシエーション応答を送信するときに発生すると考えられています。その時点で、APは、それによって、分配システム（DS）内のスイッチは、ステーションのMACアドレスを学習させ、マルチキャストアドレスにステーションの送信元アドレスを偽装されたフレームを送信します。これは新しい接続点におけるステーションにフレームの転送を可能にしながら、それはまた、認証されていない再結合要請フレームを送信することによって、ESS内の任意の場所に位置するステーションの関連付けを解除する攻撃を可能にします。
"Fault Isolation and Recovery" [RFC816], Section 3, describes how hosts interact with routers for the purpose of fault recovery:
「障害分離と回復」[RFC816]、第3節では、ホストが障害回復のために、ルータと対話する方法について説明します。
Since the gateways always attempt to have a consistent and correct model of the internetwork topology, the host strategy for fault recovery is very simple. Whenever the host feels that something is wrong, it asks the gateway for advice, and, assuming the advice is forthcoming, it believes the advice completely. The advice will be wrong only during the transient period of negotiation, which immediately follows an outage, but will otherwise be reliably correct.
ゲートウェイは、常にインターネットワークトポロジの整合性と正しいモデルを持ってしようとしているので、障害回復のためのホスト戦略は非常に簡単です。ホストは、何かが間違っていることを感じているときはいつでも、それは完全にアドバイスを信じて、アドバイスが迫っていると仮定すると、アドバイスのためのゲートウェイを要求し、。アドバイスはすぐに停止し、次の交渉の過渡期間中に間違っているだろうが、そうでない場合は、確実に正しいだろう。
In fact, it is never necessary for a host to explicitly ask a gateway for advice, because the gateway will provide it as appropriate. When a host sends a datagram to some distant net, the host should be prepared to receive back either of two advisory messages which the gateway may send. The ICMP "redirect" message indicates that the gateway to which the host sent the datagram is no longer the best gateway to reach the net in question. The gateway will have forwarded the datagram, but the host should revise its routing table to have a different immediate address for this net. The ICMP "destination unreachable" message indicates that as a result of an outage, it is currently impossible to reach the addressed net or host in any manner. On receipt of this message, a host can either abandon the connection immediately without any further retransmission, or resend slowly to see if the fault is corrected in reasonable time.
ゲートウェイは適切にそれを提供するので、ホストは明示的に、アドバイスのためのゲートウェイを依頼するために実際には、それが必要になることはありません。ホストは、いくつかの遠くのネットにデータグラムを送信すると、ホストは、ゲートウェイが送信することが2つの顧問のいずれかのメッセージをバック受け取ることを準備する必要があります。 ICMPメッセージを「リダイレクト」ホストがデータグラムを送ったようにゲートウェイは、もはや問題ではネットに到達するための最良のゲートウェイであることを示していません。ゲートウェイは、データグラムを転送していますが、ホストは、このネットの異なる即時アドレスを持っているために、そのルーティングテーブルを修正する必要があります。 ICMP「宛先到達不能」メッセージが停電の結果として、どのような方法で対処ネットまたはホストに到達するために、現在は不可能であることを示しています。このメッセージを受信すると、ホストは、いずれかの任意のさらなる再送信せずにすぐに接続を放棄する、または障害が妥当な時間で修正されたかどうかを確認するために、ゆっくりと再送信することができます。
Given today's security environment, it is inadvisable for hosts to act on indications provided by routers without careful consideration. As noted in "ICMP attacks against TCP" [Gont], existing ICMP error messages may be exploited by attackers in order to abort connections in progress, prevent setup of new connections, or reduce throughput of ongoing connections. Similar attacks may also be launched against the Internet layer via forging of ICMP redirects.
今日の安全保障環境を考えると、ホストは慎重に検討することなく、ルータが提供する兆候に基づいて行動するためにはお勧めできません。 「TCPに対するICMP攻撃」[Gont]で述べたように、既存のICMPエラーメッセージは、進行中の接続を中止し、新しい接続のセットアップを防止するため、または進行中の接続のスループットを低下させるためには、攻撃者によって悪用されることがあります。同様の攻撃は、ICMPリダイレクトの鍛造を経由してインターネット層に対して実行することができます。
Proposals for transported link indications need to demonstrate that they will not add a new set of similar vulnerabilities. Since transported link indications are typically unauthenticated, hosts receiving them may not be able to determine whether they are authentic, or even plausible.
輸送リンク適応のための提案は、彼らが同様の脆弱性の新しいセットを追加しないことを証明する必要があります。搬送リンク適応は、典型的には未認証であるので、それらを受信したホストは、それらが本物の、あるいは妥当であるかどうかを決定することができないかもしれません。
Where link indication proposals may respond to unauthenticated link layer frames, they should utilize upper-layer security mechanisms, where possible. For example, even though a host might utilize an unauthenticated link layer control frame to conclude that a link has become operational, it can use SEND [RFC3971] or authenticated DHCP [RFC3118] in order to obtain secure Internet layer configuration.
リンク指示提案が認証されていないリンク層フレームに応答することができる場合、それらは、可能な上位層のセキュリティメカニズムを利用する必要があります。例えば、ホストは、リンクが操作可能になったと判断し、認証されていないリンク層制御フレームを利用可能性があるにもかかわらず、それは安全なインターネット層構成を得るために、SEND [RFC3971]または認証されたDHCP [RFC3118]を使用することができます。
Link indication proposals need to be particularly careful to avoid enabling denial-of-service attacks that can be mounted at a distance. While wireless links are naturally vulnerable to interference, such attacks can only be perpetrated by an attacker capable of establishing radio contact with the target network. However, attacks that can be mounted from a distance, either by an attacker on another point of attachment within the same network or by an off-link attacker, expand the level of vulnerability.
リンク指示提案は、距離に取り付けることができるサービス拒否攻撃を有効に避けるために特に注意する必要があります。無線リンクが干渉に自然に脆弱であるが、このような攻撃は、ターゲット・ネットワークとの無線接続を確立することができる攻撃者により犯さすることができます。しかし、距離から、いずれかのアタッチメントの別の点に攻撃者が同じネットワーク内またはオフリンク攻撃者によって装着することができる攻撃は、脆弱性のレベルを展開します。
The transport of link indications can increase risk by enabling vulnerabilities exploitable only by attackers on the local link to be executed across the Internet. Similarly, by integrating link indications with upper layers, proposals may enable a spoofed link layer frame to consume more resources on the host than might otherwise be the case. As a result, while it is important for upper layers to validate link indications, they should not expend excessive resources in doing so.
リンク指摘の輸送は、インターネットを介して実行されるように、ローカルリンク上の唯一の攻撃者によって悪用可能な脆弱性を可能にすることによって、リスクを増大させることができます。同様に、上位層とのリンクの表示を統合することにより、提案は、他の場合であるかもしれないよりも、ホスト上で多くのリソースを消費する偽装リンク層フレームを可能にすることができます。上位層は、リンク表示を検証することが重要である一方、その結果、彼らはそうすることで、過剰なリソースを費やすべきではありません。
Congestion control is not only a transport issue, it is also a security issue. In order to not provide leverage to an attacker, a single forged link layer frame should not elicit a magnified response from one or more hosts, by generating either multiple responses or a single larger response. For example, proposals should not enable multiple hosts to respond to a frame with a multicast destination address.
輻輳制御は、それはまた、セキュリティ上の問題であるだけでなく、輸送の問題です。攻撃者にレバレッジを提供しないために、単一鍛造リンク層フレームは、複数の応答または単一のより大きな応答のいずれかを生成することによって、一つ以上のホストから拡大応答を誘発してはなりません。例えば、提案は、マルチキャスト宛先アドレスを持つフレームに対応するために複数のホストを有効にしないでください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July 1982.
[RFC816]クラーク、D.、 "障害分離と回復"、RFC 816、1982年7月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]ヘドリック、C.、 "ルーティング情報プロトコル"、RFC 1058、1988年6月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October 1989.
[RFC1131]モイ、J.、 "OSPF仕様"、RFC 1131、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]デアリング、S.、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link Control Protocol", RFC 1307, March 1992.
[RFC1307]ヤング、J.およびA.ニコルソンは、1992年3月、RFC 1307 "動的リンク制御プロトコルをスイッチ"。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、D.、およびE.リアデ、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, June 1996.
[RFC1981]マッキャン、J.、デアリング、S.とJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年6月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]ハンドレー、M.、Padhye、J.、およびS.フロイド、 "TCP輻輳ウィンドウ検証"、RFC 2861、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP 41, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、RFC 2914、BCP 41、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol" RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV.パクソン、「ストリーム制御伝送プロトコル」RFC 2960、2000年10月。
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.とB. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366] Fairhurst、G.とL.ウッド、BCP 62、RFC 3366、2002年8月 "リンク自動再送要求（ARQ）にデザイナーをリンクするためのアドバイス"。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[RFC3921]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"、RFC 3921、2004年10月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of Link-Local IPv4 Addresses", RFC 3927, May 2005.
[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "リンクローカルIPv4アドレスの動的構成"、RFC 3927、2005年5月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]ムーア、N.、 "IPv6の楽観重複アドレス検出（DAD）"、RFC 4429、2006年4月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、カールソン、J.、およびS.チェシャー、 "IPv4の（DNAv4）で検出ネットワーク接続"、RFC 4436、2006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[Alimian] Alimian, A., "Roaming Interval Measurements", 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 802.11 submission (work in progress), March 2004.
[Alimian] Alimian、A.、 "ローミング間隔の測定"、11-04-0378-00ローミング-間隔-measurements.ppt、IEEE 802.11提出（作業中）、2004年3月。
[Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G., and R. Morris, "Link-level Measurements from an 802.11b Mesh Network", SIGCOMM '04, September 2004, Portland, Oregon.
[Aguayo] Aguayo、D.、Bicket、J.、ビスワス、S.、ジャド、G.、およびR.モリス、 "802.11bのメッシュネットワークからのリンク・レベルの測定"、SIGCOMM '04、2004年9月、ポートランド、オレゴン。
[Bakshi] Bakshi, B., Krishna, P., Vadiya, N., and D.Pradhan, "Improving Performance of TCP over Wireless Networks", Proceedings of the 1997 International Conference on Distributed Computer Systems, Baltimore, May 1997.
[バクシ]バクシ、B.、クリシュナ、P.、Vadiya、N.、およびD.Pradhan、「ワイヤレスネットワーク上のTCPのパフォーマンスの向上」、分散コンピュータシステム、ボルチモア、1997年5月に1997国際会議の議事録。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2007.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2007年3月に作業。
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses from Wireless Losses Using Interarrival Times at the Receiver", Proceedings of the IEEE Symposium on Application-Specific Systems and Software Engineering and Technology, Richardson, TX, Mar 1999.
[Biaz] Biaz、S.およびN. Vaidya、「レシーバーの間時間を使用してワイヤレスの損失と区別輻輳損失」、IEEEシンポジウムアプリケーション固有のシステム上およびソフトウェア工学と技術、リチャードソン、テキサス州、1999年3月。
[CARA] Kim, J., Kim, S., and S. Choi, "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs", Korean Institute of Communication Sciences (KICS) Journal, Feb. 2006
、コミュニケーション科学の韓国研究所（KICS）誌、2006年2月： "IEEE 802.11 WLANの衝突-AwareのレートアダプテーションCARA" [CARA]キム、J.、キム、S.、およびS.チェ、
[Chandran] Chandran, K., Raghunathan, S., Venkatesan, S., and R. Prakash, "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc Wireless Networks", Proceedings of the 18th International Conference on Distributed Computing Systems (ICDCS), Amsterdam, May 1998.
「アドホック無線ネットワークにおけるTCPのパフォーマンスを向上させるためのフィードバックに基づく方式」[チャンドラン]チャンドラン、K.、Raghunathan、S.、Venkatesan、S.、およびR.プラカシュ、分散コンピューティング第18回国際会議の議事録システムズ（ICDCS）、アムステルダム、1998年5月。
[DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6 (DNAv6)", Work in Progress, March 2007.
[DNAv6]ナラヤナン、S.、 "IPv6の（DNAv6）におけるネットワーク接続検出"、進歩、2007年3月に作業。
[E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-Up' Notification", Work in Progress, October 2003.
[E2ELinkup]ドーキンス、S.とC.ウィリアムズ、「エンドツーエンド、暗黙の 『リンクアップ』通知」、進歩、2003年10月に作業。
[EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP IKEv2 Method", Work in Progress, March 2007.
[EAPIKEv2] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、大場、Y.、およびF. Bersani、 "EAP IKEv2の方法"、進歩、2007年3月に作業。
[Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis of the Error Characteristics of an In-Building Wireless Network", SIGCOMM '96, August 1996, Stanford, CA.
[エックハルト]エックハルト、D.とP. Steenkiste、「建物内ワイヤレスネットワークの誤差特性の測定と分析」、SIGCOMM '96、1996年8月、スタンフォード大学、カリフォルニア
[Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion Control for Mobility", Technical Report CR-2005- 213838, NASA Glenn Research Center, July 2005.
[エディ]エディ、W.およびY.スワミ、「モビリティの適応エンドホスト輻輳制御」、技術報告書CR-2005〜213838、NASAグレンリサーチセンター、2005年7月。
[EfficientEthernet] Gunaratne, C. and K. Christensen, "Ethernet Adaptive Link Rate: System Design and Performance Evaluation", Proceedings of the IEEE Conference on Local Computer Networks, pp. 28-35, November 2006.
[EfficientEthernet] Gunaratne、C.およびK.クリステンセン、「イーサネット適応リンクレート：システム設計と性能評価」、ローカルコンピュータネットワーク上のIEEE会議議事録、頁28〜35、2006年11月。。
[Eggert] Eggert, L., Schuetz, S., and S. Schmid, "TCP Extensions for Immediate Retransmissions", Work in Progress, June 2005.
[エッゲルト]エッゲルト、L.、Schuetz、S.、およびS.シュミッド、 "即時再送信のためのTCP拡張機能"、進歩、2005年6月での作業。
[Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive Transport-Layer Interfaces", MobiArch '06, San Francisco, CA.
[Eggert2]エッゲルト、L.およびW.エディ、「より表現トランスポート・レイヤ・インタフェースに向けて」、MobiArch '06、サンフランシスコ、カリフォルニア
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", Proceedings of the 9th ACM International Conference on Mobile Computing and Networking (MobiCom '03), San Diego, California, September 2003.
[ETX]ダグラス・SJ・デ・クート、ダニエルAguayo、ジョンBicket、ロバートモリス、「マルチホップ無線ルーティングのためのハイスループットパスメトリック」、モバイルコンピューティングとネットワーキングの第9回ACM国際会議（モビコム'03）の議事録、サンディエゴ、カリフォルニア州、2003年9月。
[ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi-radio, multi-hop wireless mesh networks", Proceedings of ACM MobiCom Conference, September 2003.
[ETXレート] Padhye、J.、Draves、R.及びB. Zill、「マルチ無線、マルチホップ無線メッシュネットワークにおけるルーティング」、ACMモビコム会議2003年9月の議事録。
[ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M., and M. Srivastava, "A Radio Aware Routing Protocol for Wireless Mesh Networks", UCLA Computer Science Department, Los Angeles, CA.
[ETX-ラジオ] Kulkarniさん、G.、ナンダン、A.、Gerla、M.、およびM. Srivastava氏、 "無線メッシュネットワークのための無線対応のルーティングプロトコル"、UCLAコンピュータサイエンス学部、ロサンゼルス、CA。
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer Triggers", submission to IEEE 802.21 (work in progress), March 2004, available at: <http://www.ieee802.org/handoff/march04_meeting_docs/ Generalized_triggers-02.pdf>.
[GenTrig]グプタ、V.およびD.ジョンストン、で入手可能な「リンクレイヤトリガのための一般化モデル」、IEEE 802.21（作業中）に提出、2004年3月、<http://www.ieee802.org/handoff / march04_meeting_docs / Generalized_triggers-02.pdf>。
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over Wireless Links", Proceedings of TENCON'98, pages 332-335. IEEE, December 1998.
[ゴエル] Goelさん、S.およびD. Sanghi、 "ワイヤレスリンク上でTCPのパフォーマンスの向上"、TENCON'98の議事録、ページ332から335。 IEEE、1998年12月。
[Gont] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[Gont] Gont、F.、 "TCPに対するICMP攻撃"、進歩、2006年10月に作業。
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers on Performance of TCP-Friendly Rate Control", to appear in ACM MCCR, 2004.
[Gurtov] Gurtov、A.とJ. Korhonen、 "TCPフレンドリーレート制御の性能に垂直ハンドオーバの効果は"、ACM MCCR、2004年に登場します。
[GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for Transport Protocols", Computer Communications Review (CCR) 34, 2 (2003).
[GurtovFloyd] Gurtov、A.とS.フロイド、 "トランスポートプロトコルのためのモデリングワイヤレスリンク"、コンピュータコミュニケーションレビュー（CCR）34、2（2003）。
[Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K., and H. Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04, October 1, 2004, Philadelphia, Pennsylvania, USA.
[Haratcherev] Haratcherev、I.、Lagendijk、R.、Langendoen、K.、およびH. SIPS、 "IEEE 802.11のためのハイブリッドレート制御"、MobiWac '04、2004年10月1日、フィラデルフィア、ペンシルベニア州、USA。
[Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation for IEEE 802.11", Ph.D. Thesis, Technical University of Delft, Netherlands, ISBN-10:90-9020513-6, ISBN-13:978-90-9020513-7, March 2006.
【Haratcherev2] Haratcherev、I.、 "IEEE 802.11のアプリケーション指向のリンクアダプテーション"、博士論文、デルフト、オランダの工科大学、ISBN-10：90-9020513-6、ISBN-13：978-90-9020513-7、2006年3月。
[HMP] Lee, S., Cho, J., and A. Campbell, "Hotspot Mitigation Protocol (HMP)", Work in Progress, October 2003.
[HMP]リー、S.、チョー、J.、およびA.キャンベル、 "ホットスポット緩和プロトコル（HMP）"、進歩、2003年10月に作業。
[Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance over Mobile Ad Hoc Networks", Proceedings of the Fifth International Conference on Mobile Computing and Networking, pages 219-230. ACM/IEEE, Seattle, August 1999.
[オランダ]オランダ、G.およびN. Vaidya、「アドホックネットワーク上のTCPの性能の分析」、モバイルコンピューティングとネットワーキング、ページ219-230の第5回国際会議の議事録。 ACM / IEEE、シアトル、1999年8月。
[Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S., and C. Diot, "Analysis of link failures in an IP backbone", Proc. of ACM Sigcomm Internet Measurement Workshop, November, 2002.
【Iannaccone] Iannaccone、G.、Chuah、C.、モルティエ、R.、バタチャリヤ、S.、およびC. Diot、 "IPバックボーンにおけるリンク障害の分析"、PROC。 ACM SIGCOMMインターネット測定ワークショップ、11月、2002年。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
電気電子学会、「地方とメトロポリタンエリアネットワーク：ポートベースのネットワークアクセスコントロール」の[IEEE-802.1X]研究所、IEEE標準802.1X、2004年12月。
[IEEE-802.11] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE-802.11]電気電子技術者協会、 "無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、IEEE規格802.11、2003年。
[IEEE-802.11e] Institute of Electrical and Electronics Engineers, "Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements", IEEE 802.11e, November 2005.
[IEEE-802.11eの]電気電子技術者協会、「標準システム間のテレコミュニケーションと情報交換のために - LAN / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様 - 改正8 ：媒体アクセス制御サービス強化の（MAC）品質」、IEEE 802.11eの、2005年11月。
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now deprecated).
電気電子技術者の[IEEE-802.11F]研究所、IEEE 802.11F、2003年6月（「IEEE試用は、IEEE 802.11動作をサポート物流システム間インターアクセスポイントプロトコル経由でマルチベンダーアクセスポイントの相互運用性のための練習を推奨」今）は非推奨。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i, July 2004.
電気電子技術者の[IEEE-802.11i規格]研究所、「電気通信及びシステム間情報交換のための標準への補足 - LAN / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：セキュリティ強化」、IEEE 802.11i規格、2004年7月のための仕様。
[IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft Amendment to Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 7: Radio Resource Management", IEEE 802.11k/D7.0, January 2007.
電気電子技術者の[IEEE-802.11k]研究所、「電気通信及びシステム間情報交換への改正案 - LAN / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様 - 修正7：無線リソース管理」、IEEE 802.11k / D7.0、2007年1月。
[IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 21: Media Independent Handover", IEEE 802.21D0, June 2005.
[IEEE-802.21]電気電子技術者協会、「電気通信のためのドラフト標準およびシステム間の情報交換 - LAN / MAN具体的な要件 - パート21：メディア独立ハンドオーバ」、IEEE 802.21D0、2005年6月。
[Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High-Performance Wireless LAN for the Unlicensed Band", Bell Labs Technical Journal, Summer 1997.
[Kamerman] Kamerman、A.、およびL. Monteban、 "のWaveLAN II：ライセンスのないバンドのための高性能無線LAN"、ベル研究所テクニカルジャーナル、夏1997。
[Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger method for improving TCP performance over Mobile IPv6", Work in Progress, August 2004.
[キム]キム、K.、公園、Y.、ソ、K.、およびY.パーク、 "モバイルIPv6上のTCP性能を向上させるためのBU-トリガ方式"、進歩、2004年8月での作業。
[Kotz] Kotz, D., Newport, C., and C. Elliot, "The mistaken axioms of wireless-network research", Dartmouth College Computer Science Technical Report TR2003-467, July 2003.
[Kotz] Kotz、D.、ニューポート、C.、およびC.エリオット、「ワイヤレス・ネットワーク研究の誤公理」、ダートマス大学コンピュータサイエンステクニカルレポートTR2003-467、2003年7月。
[Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and M. Allman, "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks", Computer Networks, 46 (3), October 2004.
【クリシュナン]クリシュナン、R.、Sterbenz、J.、エディ、W.、ヤマウズラ、C.、およびM.オールマン、 "エラープローン無線及び衛星ネットワークのための明示的なトランスポート・エラー通知（ETEN）"、コンピュータネットワーク、46 （3）、2004年10月。
[Lacage] Lacage, M., Manshaei, M., and T. Turletti, "IEEE 802.11 Rate Adaptation: A Practical Approach", MSWiM '04, October 4-6, 2004, Venezia, Italy.
[Lacage] Lacage、M.、Manshaei、M.、およびT. Turletti、 "IEEE 802.11レート適応：実践的アプローチ"、MSWiM '04、10月4-6、2004、ヴェネツィア、イタリア。
[Lee] Park, S., Lee, M., and J. Korhonen, "Link Characteristics Information for Mobile IP", Work in Progress, January 2007.
[リー]パーク、S.、リー、M.、およびJ. Korhonen、 "モバイルIPのためのリンク特性情報"、進歩、2007年1月の作業。
[Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for TCP/IP over GSM", Proceedings of IEEE Infocom '99, March 1999.
[ルートヴィヒ]ルートヴィヒ、R.とB. Rathonyi、 "GSM上のTCP / IPのためのリンク層の機能強化"、IEEEインフォコム'99、1999年3月の議事。
[MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J., and M. Laurent-Maknavicius, "MIPv6 Authorization and Configuration based on EAP", Work in Progress, October 2006.
[MIPEAP] Giaretta、C.、Guardini、I.、DEMARIA、E.、Bournelle、J.、およびM.ローランMaknavicius、 "MIPv6の認可および構成のEAPに基づいて" 進歩、2006年10月に作業。
[Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, University of Maryland Department of Computer Science, September 2002.
[ミシュラ]ミトラ、A.、新、M.、およびW. Arbaugh、CS-TR-4395 "IEEE 802.11 MACレイヤハンドオフプロセスの実証分析"、コンピュータサイエンス、2002年9月のメリーランド大学の学科。
[Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control - Buffer Requirements and Overload Performance", Technical Memorandum, AT&T Bell Laboratories, October 1994.
[モーガン]モルガン、S.とS. Keshav、「パケットペアレート制御 - バッファ要件と過負荷性能」、技術的な覚書、AT＆Tベル研究所、1994年10月。
[Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 with 802.11", Work in Progress, March 2004.
[ムン]ムン、Y.、およびJ.パーク、「802.11とモバイルIPv4のレイヤ2ハンドオフ」、進歩、2004年3月に作業。
[ONOE] Onoe Rate Control, <http://madwifi.org/browser/trunk/ath_rate/onoe>.
[尾上]尾上レート制御、<http://madwifi.org/browser/trunk/ath_rate/onoe>。
[Park] Park, S., Njedjou, E., and N. Montavont, "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example", Work in Progress, July 2004.
[公園]公園、S.、Njedjou、E.、およびN. Montavont、 "L2トリガー最適化モバイルIPv6垂直ハンドオーバ：802.11 / GPRS例"、進歩、2004年7月ワーク。
[Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for IEEE802.11 WLAN via received signal strength measurement", IEEE International Conference on Communications, 2003 (ICC '03), volume 2, pages 1108- 1113, Anchorage, Alaska, USA, May 2003.
【パボン]パボン、J.及びS.チェ、「受信信号強度測定を介してIEEE802.11 WLANのためのリンク適応戦略」、通信に関するIEEE国際会議、2003年（ICC '03）、第2巻、ページ1108- 1113アンカレッジ、アラスカ、アメリカ、2003年5月。
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[PEAP] Palekar、A.、サイモン、D.、Salowey、J.、周、H.、ゾルン、G.、およびS. Josefsson氏、 "保護されたEAPプロトコル（PEAP）バージョン2"、進行中で働いて2004年10月。
[PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network protocols", Proceedings of the IEEE, 75(1), January 1987.
【PRNET] Jubin、J.およびJ. Tornow、 "DARPAパケット無線ネットワークプロトコル"、IEEE会報、75（1）、1987年1月。
[Qiao] Qiao D., Choi, S., Jain, A., and Kang G. Shin, "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11 a/h", in Proc. ACM MobiCom'03, San Diego, CA, September 2003.
【橋】橋D.、チェ、S.、ジェイン、A.、およびカンG.新：PROCで、「守銭奴IEEE 802.11 /時間の最適低エネルギー伝送戦略」。 ACM MobiCom'03、サンディエゴ、CA、2003年9月。
[RBAR] Holland, G., Vaidya, N., and P. Bahl, "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks", Proceedings ACM MOBICOM, July 2001.
[RBAR]オランダ、G.、Vaidya、N.、およびP. BAHL、 "マルチホップ無線ネットワークのためのレート適応型MACプロトコル"、議事ACM MOBICOM、2001年7月。
[Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks", Proceedings of the IEEE InfoCon 2005, March 2005.
[ラマニ]ラマニ、I.およびS.サベージ、 "SyncScan：802.11インフラストラクチャネットワークのための実用的な高速ハンドオフ"、IEEE InfoCon 2005、2005年3月の議事。
[Robust] Wong, S., Yang, H ., Lu, S., and V. Bharghavan, "Robust Rate Adaptation for 802.11 Wireless Networks", ACM MobiCom'06, Los Angeles, CA, September 2006.
[堅牢]ウォン、S.、ヤン、H。、呂、S.、およびV. Bharghavan、 "802.11ワイヤレスネットワークのための堅牢なレート適応"、ACM MobiCom'06、ロサンゼルス、CA、2006年9月。
[SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks", MIT Master's Thesis, 2005.
[SampleRateの] Bicket、J.、 "ワイヤレスネットワークのビットレートの選択"、MIT修士論文、2005。
[Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation for Disconnecting Networks", ACM SIGCOMM Computer Communication Review, 33(5), October 2003.
[スコット]スコット、J.、MAPP、G.、 "ネットワークの接続を解除するためのリンク層ベースのTCPの最適化"、ACM SIGCOMMコンピュータコミュニケーションレビュー、33（5）、2003年10月。
[Schuetz] Schutz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol Enhancements for Intermittently Connected Hosts", ACM SIGCOMM Computer Communications Review, Volume 35, Number 2, July 2005.
【Schuetz]シュッツ、S.、Eggertの、L.、シュミット、S.、およびM.ブルンナー、 "断続的に接続されたホストのためのプロトコルの拡張"、ACM SIGCOMMコンピュータコミュニケーションレビュー、35巻、2号、2005年7月。
[Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers and Robert Morris, "Performance of Multihop Wireless Networks: Shortest Path is Not Enough", Proceedings of the First Workshop on Hot Topics in Networking (HotNets-I), Princeton, New Jersey, October 2002.
[最短]ダグラス・SJ・デ・クート、ダニエルAguayo、ベンジャミン・A.チェンバースとロバート・モリス、：ネットワーキング（HotNets-I）、プリンストンのホットな話題に最初のワークショップの議事録、「マルチホップ無線ネットワークのパフォーマンスは、最短経路が十分ではありません」 、ニュージャージー州、2002年10月。
[TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework and Requirements for TRIGTRAN", Work in Progress, August 2003.
[TRIGTRAN]ドーキンス、S.、ウィリアムズ、C.、およびA. Yegin、 "フレームワークとTRIGTRANための要件"、進歩、2003年8月の作業。
[Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover performance and its effect on voice traffic", TRITA-IMIT-TSLAB R 03:01, KTH Royal Institute of Technology, Stockholm, Sweden, July 2003.
[VATN] VATN、J.、 "実験的なIEEE 802.11bのハンドオーバー性能の研究および音声トラフィックに及ぼす影響"、TRITA-IMIT-TSLAB R 3時01分、テクノロジー、ストックホルム、スウェーデン、2003年7月のKTH王立研究所。
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH Royal Institute of Technology, Stockholm, Sweden, April 2003.
[ベラヨス]ベラヨス、H.およびG.カールソン、 "IEEE 802.11bのMACレイヤハンドオーバ時間を短縮する技術"、TRITA-IMIT-LCN R 3時02分、テクノロジー、ストックホルムの王立研究所KTH、スウェーデン、2003年4月。
[Vertical] Zhang, Q., Guo, C., Guo, Z., and W. Zhu, "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN", IEEE Communications Magazine, November 2003.
[縦]チャン、Q.、郭、C.、郭、Z.、およびW.朱、 "WWANとWLAN間の垂直ハンドオフのための効率的なモビリティ・マネジメント"、IEEE通信誌、2003年11月。
[Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", Work in Progress, February 1999.
[Villamizar] Villamizar、C.、 "OSPF最適化されたマルチパス（OSPF-OMP）"、進歩、1999年2月での作業。
[Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links", Ph.D. thesis, University of California at San Diego, 1999.
[Xylomenos] Xylomenos、G.、「マルチサービス・リンク・レイヤ：無線リンクを介してインターネットのパフォーマンスの向上へのアプローチ」、博士論文、サンディエゴ、1999年にカリフォルニア大学。
[Yegin] Yegin, A., "Link-layer Triggers Protocol", Work in Progress, June 2002.
[Yegin] Yegin、A.、 "リンク層のトリガプロトコル"、進歩、2002年6月での作業。
The authors would like to acknowledge James Kempf, Phil Roberts, Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy, and Janne Peisa for contributions to this document.
作者はこのドキュメントへの貢献のためにジェームス・ケンプ、フィル・ロバーツ、Gorry Fairhurst、ジョンWroclawski、アーロンフォーク、サリー・フロイド、ペッカSavola、ペッカNikander、デーブターラー、ヨーゲッシュスワミ、ウェズリーエディ、およびヤンネPeisaを確認したいと思います。
Appendix A. Literature Review
付録A.文学レビュー
This appendix summarizes the literature with respect to link indications on wireless local area networks.
この付録では、ワイヤレスローカルエリアネットワーク上の表示をリンクさせるに関して文献をまとめました。
A.1. Link Layer
A.1。リンク層
The characteristics of wireless links have been found to vary considerably depending on the environment.
無線リンクの特性は環境によってかなり変化することが分かってきました。
In "Performance of Multihop Wireless Networks: Shortest Path is Not Enough" [Shortest], the authors studied the performance of both an indoor and outdoor mesh network. By measuring inter-node throughput, the best path between nodes was computed. The throughput of the best path was compared with the throughput of the shortest path computed based on a hop-count metric. In almost all cases, the shortest path route offered considerably lower throughput than the best path.
「マルチホップ無線ネットワークのパフォーマンス：最短経路が十分ではありません」で[最短]、著者は、屋内と屋外メッシュネットワークの両方のパフォーマンスを研究しました。ノード間のスループットを測定することにより、ノード間の最適パスを算出しました。最良のパスのスループットはホップカウントメトリックに基づいて計算最短経路のスループットと比較しました。ほとんどの場合、最短パス経路が最適経路よりもかなり低いスループットを提供しました。
In examining link behavior, the authors found that rather than exhibiting a bi-modal distribution between "up" (low loss rate) and "down" (high loss rate), many links exhibited intermediate loss rates. Asymmetry was also common, with 30 percent of links demonstrating substantial differences in the loss rates in each direction. As a result, on wireless networks the measured throughput can differ substantially from the negotiated rate due to retransmissions, and successful delivery of routing packets is not necessarily an indication that the link is useful for delivery of data.
著者はそれを発見したのではなく二峰「アップ」の間に分布（低損失率）と「ダウン」（高損失率）を示すリンクの挙動を調べるには、多くのリンクは、中間損失率を示しました。非対称性は、各方向における損失率の大幅な違いを実証するリンクの30パーセントで、また一般的でした。その結果、無線ネットワーク上で測定されたスループットが原因再送にネゴシエートされた速度と実質的に異なることができ、およびルーティングパケットの成功の送達は、必ずしもリンクは、データの送達に有用であることの指標ではありません。
In "Measurement and Analysis of the Error Characteristics of an In-Building Wireless Network" [Eckhardt], the authors characterize the performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in Infrastructure mode on the Carnegie Mellon campus. In this study, very low frame loss was experienced. As a result, links could be assumed to operate either very well or not at all.
[エックハルト]「では、ビルワイヤレスネットワークの誤差特性の測定と分析」では、著者はカーネギーメロンキャンパスでインフラストラクチャモードで動作しているAT＆TではないWavelan 2 Mbpsの建物内WLANのパフォーマンスを特徴づけます。本研究では、非常に低いフレームの損失を経験しました。その結果、リンクはまったくのいずれかの非常にうまくかないで動作するものとすることができます。
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], the authors analyze the causes of frame loss in a 38-node urban multi-hop 802.11 ad-hoc network. In most cases, links that are very bad in one direction tend to be bad in both directions, and links that are very good in one direction tend to be good in both directions. However, 30 percent of links exhibited loss rates differing substantially in each direction.
[Aguayo「802.11bのメッシュネットワークからのリンク・レベルの測定」において、著者らは、38ノード都市マルチホップ802.11アドホックネットワークにおけるフレームロスの原因を分析します。ほとんどの場合、一つの方向に非常に悪いのリンクは両方向に悪い傾向にあり、かつ一方向に非常に優れているリンクは、両方向に良い傾向にあります。ただし、リンクの30パーセントは、各方向に、実質的に異なる損失率を示しました。
Signal to noise ratio (SNR) and distance showed little value in predicting loss rates, and rather than exhibiting a step-function transition between "up" (low loss) or "down" (high loss) states, inter-node loss rates varied widely, demonstrating a nearly uniform distribution over the range at the lower rates. The authors attribute the observed effects to multi-path fading, rather than attenuation or interference.
信号対雑音比（SNR）と距離（低損失）または「ダウン」変化（高損失）状態、ノード間の損失率損失率を予測する際に少し値を示し、そしてよりもむしろ「アップ」の間にステップ関数遷移を示します広く、より低いレートで範囲にわたってほぼ均一な分布を示します。著者らは、マルチパスフェージングではなく、減衰または干渉に観察された効果を属性。
The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of link conditions observed in practice. While for indoor infrastructure networks site surveys and careful measurement can assist in promoting ideal behavior, in ad-hoc/mesh networks node mobility and external factors such as weather may not be easily controlled.
[Aguayo] [エックハルト]のとの調査結果は、実際に観測されたリンク条件の多様性を示しています。屋内インフラストラクチャネットワークサイトの調査やアドホック/メッシュネットワークノードの移動や天候などの外的要因で、理想的な行動を促すのに役立つことができます慎重に測定するために容易に制御することはないかもしれないが。
Considerable diversity in behavior is also observed due to implementation effects. "Techniques to reduce IEEE 802.11b MAC layer handover time" [Velayos] measured handover times for a stationary STA after the AP was turned off. This study divided handover times into detection (determination of disconnection from the existing point of attachment), search (discovery of alternative attachment points), and execution (connection to an alternative point of attachment) phases. These measurements indicated that the duration of the detection phase (the largest component of handoff delay) is determined by the number of non-acknowledged frames triggering the search phase and delays due to precursors such as RTS/CTS and rate adaptation.
行動にかなりの多様性は、実装の影響により観察されます。 「IEEE 802.11bのMACレイヤハンドオーバ時間を短縮する技術」[ベラヨス】固定STAについて測定ハンドオーバ時間をAPがオフになった後。この研究は、検出（アタッチメントの既存のポイントからの切断の決意）、検索（別の接続点の発見）、および実行（アタッチメントの別のポイントへの接続）相にハンドオーバ時間を分割します。これらの測定は、検出段階（ハンドオフ遅延の最大成分）の持続時間がこのようなRTS / CTSおよびレート適応等の前駆体に探索位相と遅延をトリガー非確認応答フレームの数によって決定されることを示しました。
Detection behavior varied widely between implementations. For example, network interface cards (NICs) designed for desktops attempted more retransmissions prior to triggering search as compared with laptop designs, since they assumed that the AP was always in range, regardless of whether the Beacon was received.
検出動作は、実装の間で大きく変化しました。彼らはAPに関係なくビーコンが受信されたかどうかの、範囲内に常にあったと仮定するので、例えば、デスクトップ用に設計されたネットワーク・インタフェース・カード（NIC）は、前にラップトップの設計と比較して、検索をトリガする複数の再送信を試みました。
The study recommends that the duration of the detection phase be reduced by initiating the search phase as soon as collisions can be excluded as the cause of non-acknowledged transmissions; the authors recommend three consecutive transmission failures as the cutoff. This approach is both quicker and more immune to multi-path interference than monitoring of the SNR. Where the STA is not sending or receiving frames, it is recommended that Beacon reception be tracked in order to detect disconnection, and that Beacon spacing be reduced to 60 ms in order to reduce detection times. In order to compensate for more frequent triggering of the search phase, the authors recommend algorithms for wait time reduction, as well as interleaving of search and data frame transmission.
研究では、検出フェーズの期間は、すぐに衝突が非を認め送信の原因として除外することができるように、検索フェーズを開始することによって減少することをお勧めします。著者は、カットオフとして3つの連続送信失敗をお勧めします。このアプローチは、両方のより迅速かつ免疫SNRの監視よりもマルチパス干渉です。 STAがフレームを送信または受信していない場合、ビーコン受信が切断を検出するために追跡されることが推奨され、そのビーコン間隔は、検出時間を短縮するために、60ミリ秒に減少させること。探索フェーズのより頻繁にトリガを補償するために、著者らは、待ち時間の低減、ならびに検索とデータフレーム送信のインターリービングのためのアルゴリズムをお勧めします。
"An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" [Mishra] investigates handoff latencies obtained with three mobile STA implementations communicating with two APs. The study found that there is a large variation in handoff latency among STA and AP implementations and that implementations utilize different message sequences. For example, one STA sends a Reassociation Request prior to authentication, which results in receipt of a Deauthenticate message. The study divided handoff latency into discovery, authentication, and reassociation exchanges, concluding that the discovery phase was the dominant component of handoff delay. Latency in the detection phase was not investigated.
「IEEE 802.11 MACレイヤハンドオフプロセスの実証分析は、」[ミシュラ]を調査は2つのAPと通信する3つのモバイルSTA実装を用いて得られた待ち時間をハンドオフ。研究では、STAとAPの実装間及び実装が異なるメッセージシーケンスを利用するハンドオフ待ち時間に大きなばらつきがあることを見出しました。例えば、1つのSTAは、認証解除メッセージを受信し、その結果、認証の前に再関連付け要求を送信します。研究は、発見フェーズは、ハンドオフ遅延の支配的な成分であったと結論づけ、発見、認証、および再アソシエーション交換にハンドオフ遅延を分割します。検出フェーズにおけるレイテンシは調査しませんでした。
"SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" [Ramani] weighs the pros and cons of active versus passive scanning. The authors point out the advantages of timed Beacon reception, which had previously been incorporated into [IEEE-802.11k]. Timed Beacon reception allows the station to continually keep up to date on the signal to noise ratio of neighboring APs, allowing handoff to occur earlier. Since the station does not need to wait for initial and subsequent responses to a broadcast Probe Response (MinChannelTime and MaxChannelTime, respectively), performance is comparable to what is achievable with 802.11k Neighbor Reports and unicast Probe Requests.
「SyncScan：802.11インフラストラクチャネットワークのための実用的な高速ハンドオフ」[ラマニ]はパッシブスキャン対アクティブの長所と短所を重量を量ります。著者らは以前に、[IEEE-802.11k]に組み込まれた時限ビーコン受信の利点を指摘しています。時限ビーコン受信局が絶えずハンドオフが早く発生することができ、隣接APの信号対雑音比に最新に保つことを可能にします。ステーションは、ブロードキャストプローブ応答（MinChannelTimeそれぞれMaxChannelTime、）への初期とその後の応答を待つ必要がないので、パフォーマンスは802.11kネイバーレポートおよびユニキャストプローブ要求で達成可能であるものに匹敵します。
The authors measured the channel switching delay, the time it takes to switch to a new frequency and begin receiving frames. Measurements ranged from 5 ms to 19 ms per channel; where timed Beacon reception or interleaved active scanning is used, switching time contributes significantly to overall handoff latency. The authors propose deployment of APs with Beacons synchronized via Network Time Protocol (NTP) [RFC1305], enabling a driver implementing SyncScan to work with legacy APs without requiring implementation of new protocols. The authors measured the distribution of inter-arrival times for stations implementing SyncScan, with excellent results.
著者は、チャンネル切り替え遅延、それは新しい周波数に切り替えてフレームの受信を開始するのにかかる時間を測定しました。測定は、5ミリ秒からチャネル当たり19ミリ秒の範囲でした。時限ビーコン受信又はインタリーブアクティブスキャンが使用される場合、スイッチング時間は、全体的なハンドオフ遅延に大きく寄与する。著者はSyncScanが新しいプロトコルの実装を必要とせずに、レガシーのAPで動作するように実装するドライバを有効にする、ネットワークタイムプロトコル（NTP）[RFC1305]を経由して同期ビーコンとAPの展開を提案します。著者は、優れた結果で、SyncScanを実装するステーションの間の到着時間の分布を測定しました。
"Roaming Interval Measurements" [Alimian] presents data on the behavior of stationary STAs after the AP signal has been shut off. This study highlighted implementation differences in rate adaptation as well as detection, scanning, and handoff. As in [Velayos], performance varied widely between implementations, from half an order of magnitude variation in rate adaptation to an order of magnitude difference in detection times, two orders of magnitude in scanning, and one and a half orders of magnitude in handoff times.
AP信号が遮断された後[Alimian】固定STAの挙動に関する提示データ「間隔測定ローミング」。この研究は、レート適応での実装の違いだけでなく、検出、スキャン、およびハンドオフを強調しました。 【ベラヨス]のように、性能は、レート適応における振幅変化の半分のオーダーの検出時間の大きさの差、走査中の二桁、ハンドオフ時間の大きさの半分のオーダーの順序に、実装の間で大きく変化しました。
"An experimental study of IEEE 802.11b handoff performance and its effect on voice traffic" [Vatn] describes handover behavior observed when the signal from the AP is gradually attenuated, which is more representative of field experience than the shutoff techniques used in [Velayos]. Stations were configured to initiate handover when signal strength dipped below a threshold, rather than purely based on frame loss, so that they could begin handover while still connected to the current AP. It was noted that stations continued to receive data frames during the search phase. Station-initiated
「実験のIEEE 802.11bのハンドオフ性能の研究および音声トラフィックへの影響」[VATN]は[ベラヨス]で使用される遮断技術より現場での経験のより代表的であるAPからの信号が徐々に減衰されたときに観察されたハンドオーバの動作を説明。信号強度が閾値を下回ったときに、まだ現在のAPに接続している間、彼らは、ハンドオーバを開始することができるようにステーションは、純粋にフレーム損失に基づくのではなく、ハンドオーバを開始するように構成しました。これは、ステーションが検索フェーズ中にデータフレームを受信し続けていることを指摘しました。駅-開始
Disassociation and pre-authentication were not observed in this study.
解離と事前認証は、この研究では観察されませんでした。
A.1.1. Link Indications
A.1.1。リンク適応症
Within a link layer, the definition of "Link Up" and "Link Down" may vary according to the deployment scenario. For example, within PPP [RFC1661], either peer may send an LCP-Terminate frame in order to terminate the PPP link layer, and a link may only be assumed to be usable for sending network protocol packets once Network Control Protocol (NCP) negotiation has completed for that protocol.
リンク層の中で、「リンクアップ」と「リンクダウン」の定義は、展開シナリオに応じて異なる場合があります。例えば、PPP [RFC1661]の中、いずれかのピアは、PPPリンク層を終端するためにLCP-終了フレームを送信することができ、リンクは、ネットワーク制御プロトコル（NCP）のネゴシエーション後、ネットワーク・プロトコル・パケットを送信するために使用可能であると仮定することができますそのプロトコルのために完了しました。
Unlike PPP, IEEE 802 does not include facilities for network layer configuration, and the definition of "Link Up" and "Link Down" varies by implementation. Empirical evidence suggests that the definition of "Link Up" and "Link Down" may depend on whether the station is mobile or stationary, whether infrastructure or ad-hoc mode is in use, and whether security and Inter-Access Point Protocol (IAPP) is implemented.
PPPとは異なり、IEEE 802は、ネットワーク層の構成のための施設、および「リンクアップ」と「リンクダウン」の実装によって異なりますの定義が含まれていません。実証的証拠は、「リンクアップ」と「リンクダウン」の定義は、インフラストラクチャまたはアドホックモードを使用している、セキュリティとアクセスポイント間プロトコル（IAPP）かどうかを、局が移動または静止しているかどうかに依存することを示唆しています実装されています。
Where a STA encounters a series of consecutive non-acknowledged frames while having missed one or more Beacons, the most likely cause is that the station has moved out of range of the AP. As a result, [Velayos] recommends that the station begin the search phase after collisions can be ruled out; since this approach does not take rate adaptation into account, it may be somewhat aggressive. Only when no alternative workable rate or point of attachment is found is a "Link Down" indication returned.
STAは、1つまたは複数のビーコンを逃した一方、連続した非承認された一連のフレームに遭遇した場合は、最も可能性の高い原因は、ステーションがAPの範囲外に移動したということです。結果として、[ベラヨス】衝突を排除することができた後にステーションは、探索フェーズを開始することをお勧めします。このアプローチは、アカウントにレート適応になりませんので、多少積極的かもしれません。添付ファイルのない代替実行可能なレートまたはポイントが見つからない場合にのみ、「リンクダウン」表示が返されます。
In a stationary point-to-point installation, the most likely cause of an outage is that the link has become impaired, and alternative points of attachment may not be available. As a result, implementations configured to operate in this mode tend to be more persistent. For example, within 802.11 the short interframe space (SIFS) interval may be increased and MIB variables relating to timeouts (such as dot11AuthenticationResponseTimeout, dot11AssociationResponseTimeout, dot11ShortRetryLimit, and dot11LongRetryLimit) may be set to larger values. In addition, a "Link Down" indication may be returned later.
固定ポイントツーポイントのインストールでは、停電の最も可能性の高い原因は、リンクが障害となっており、アタッチメントの別のポイントが利用できない場合があることです。結果として、このモードで動作するように構成された実装は、より持続的である傾向があります。例えば、802.11内短いフレーム間スペース（SIFS）間隔を増加させることができ、（例えばdot11AuthenticationResponseTimeout、dot11AssociationResponseTimeout、dot11ShortRetryLimit、及びdot11LongRetryLimitなど）タイムアウトに関連するMIB変数は、より大きな値に設定してもよいです。また、「リンクダウン」表示は、後に返されることがあります。
In IEEE 802.11 ad-hoc mode with no security, reception of data frames is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a result, reception of data frames is enabled at any time, and no explicit "Link Up" indication exists.
セキュリティなしでIEEE 802.11アドホックモードでは、データ・フレームの受信が状態1（「未認証」と「関連付けられていない」）で有効になっています。その結果、データフレームの受信はいつでも使用可能にし、明示的な「リンクアップ」表示が存在しません。
In Infrastructure mode, IEEE 802.11-2003 enables reception of data frames only in State 3 ("Authenticated" and "Associated"). As a result, a transition to State 3 (e.g., completion of a successful
インフラストラクチャモードでは、IEEE 802.11から2003は、状態3（「認証」と「関連」）におけるデータフレームの受信を可能にします。その結果、状態3（例えば、成功の完了に遷移として
Association or Reassociation exchange) enables sending and receiving of network protocol packets and a transition from State 3 to State 2 (reception of a "Disassociate" frame) or State 1 (reception of a "Deauthenticate" frame) disables sending and receiving of network protocol packets. As a result, IEEE 802.11 stations typically signal "Link Up" on receipt of a successful Association/Reassociation Response.
アソシエーションまたは再アソシエーションの交換）を送信し、ネットワーク・プロトコル・パケットの受信及び状態2（「解離」フレームの受信）又は状態1への状態3からの遷移（「認証解除」フレームの受信）を送信し、ネットワークプロトコルの受信有効または無効にしますパケット。その結果、IEEE 802.11ステーションは、一般的に成功した協会/再アソシエーション応答の領収書に「リンクアップ」を知らせます。
As described within [IEEE-802.11F], after sending a Reassociation Response, an Access Point will send a frame with the station's source address to a multicast destination. This causes switches within the Distribution System (DS) to update their learning tables, readying the DS to forward frames to the station at its new point of attachment. Were the AP to not send this "spoofed" frame, the station's location would not be updated within the distribution system until it sends its first frame at the new location. Thus, the purpose of spoofing is to equalize uplink and downlink handover times. This enables an attacker to deny service to authenticated and associated stations by spoofing a Reassociation Request using the victim's MAC address, from anywhere within the ESS. Without spoofing, such an attack would only be able to disassociate stations on the AP to which the Reassociation Request was sent.
[IEEE-802.11F]内に記載されているように、再アソシエーション応答を送信した後、アクセスポイントは、マルチキャスト宛先にステーションの送信元アドレスを持つフレームを送信します。これは、添付ファイルの新時点でステーションにフレームを転送するためにDSを準備を進め、彼らの学習テーブルを更新するために、ディストリビューション・システム（DS）内のスイッチが発生します。 APは、この「なりすましの」フレームを送信しないようにした、新しい場所にその最初のフレームを送信するまで、駅の位置は、配信システム内で更新されることはありません。従って、スプーフィングの目的は、アップリンクとダウンリンクハンドオーバ時間を等しくすることです。これはどこでもESS内から、被害者のMACアドレスを使用して再アソシエーション要求をスプーフィングによって認証および関連ステーションへのサービスを拒否するように、攻撃者を可能にします。なりすましがなければ、このような攻撃は、唯一の再アソシエーション要求が送信されたAP上のステーションの関連付けを解除することができるだろう。
The signaling of "Link Down" is considerably more complex. Even though a transition to State 2 or State 1 results in the station being unable to send or receive IP packets, this does not necessarily imply that such a transition should be considered a "Link Down" indication. In an infrastructure network, a station may have a choice of multiple Access Points offering connection to the same network. In such an environment, a station that is unable to reach State 3 with one Access Point may instead choose to attach to another Access Point. Rather than registering a "Link Down" indication with each move, the station may instead register a series of "Link Up" indications.
「リンクダウン」のシグナリングはかなり複雑です。偶数ステーションにおける状態2又は状態1つの結果への遷移は、IPパケットを送信または受信することができないが、これは必ずしもそのような遷移は「リンクダウン」指示と見なされるべきであることを意味するものではありません。インフラストラクチャネットワークでは、ステーションは同じネットワークへの接続を提供する複数のアクセスポイントの選択を有することができます。このような環境では、1アクセスポイントと状態3に到達することができない駅ではなく、別のアクセスポイントに接続することもできます。むしろそれぞれの動きに「リンクダウン」表示を登録するよりも、駅ではなく、「リンクアップ」の適応症のシリーズを登録することもできます。
In [IEEE-802.11i], forwarding of frames from the station to the distribution system is only feasible after the completion of the 4-way handshake and group-key handshake, so that entering State 3 is no longer sufficient. This has resulted in several observed problems. For example, where a "Link Up" indication is triggered on the station by receipt of an Association/Reassociation Response, DHCP [RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may be triggered prior to when the link is usable by the Internet layer, resulting in configuration delays or failures. Similarly, transport layer connections will encounter packet loss, resulting in back-off of retransmission timers.
状態3を入力すると、もはや十分ではないように、[IEEE-802.11i規格]において、分配システムへステーションからフレームの転送は、4ウェイハンドシェイクおよびグループキーハンドシェイクが完了した後にのみ可能です。これは、いくつかの観測された問題をもたらしました。例えば、ここで、「リンクアップ」表示がリンクによって使用可能である場合前にトリガされてもよいアソシエーション/再アソシエーション応答、DHCP [RFC2131]またはルータ要請/ルータ広告（RS / RA）の受信によってステーションにトリガされますインターネット層、コンフィギュレーションの遅延や障害が生じ。同様に、トランスポート層接続は、再送タイマーのバックオフで、その結果、パケット損失が発生します。
A.1.2. Smart Link Layer Proposals
A.1.2。スマートリンクレイヤ提案
In order to improve link layer performance, several studies have investigated "smart link layer" proposals.
リンク層の性能を向上させるためには、いくつかの研究は、「スマートリンク層」の提案を検討しました。
"Advice to link designers on link Automatic Repeat reQuest (ARQ)" [RFC3366] provides advice to the designers of digital communication equipment and link-layer protocols employing link-layer Automatic Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, timers, persistency in retransmission, and the challenges that arise from sharing links between multiple flows and from different transport requirements.
「リンク自動再送要求（ARQ）にデザイナーをリンクする情報は、」[RFC3366]はIPのリンク・レイヤ自動再送要求（ARQ）技術を用いたデジタル通信機器とリンク層プロトコルの設計者に助言を提供します。これは、ARQ、タイマ、再送時の持続性、および複数のフロー間および異なるトランスポート要件からリンクを共有するから発生する課題の使用について説明します。
In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the authors describe how the Global System for Mobile Communications (GSM)-reliable and unreliable link layer modes can be simultaneously utilized without higher layer control. Where a reliable link layer protocol is required (where reliable transports such TCP and Stream Control Transmission Protocol (SCTP) [RFC2960] are used), the Radio Link Protocol (RLP) can be engaged; with delay-sensitive applications such as those based on UDP, the transparent mode (no RLP) can be used. The authors also describe how PPP negotiation can be optimized over high-latency GSM links using "Quickstart-PPP".
【ルートヴィヒ「GSM上のTCP / IPのためのリンク層の機能強化」において、著者らは、モバイル通信用グローバルシステム（GSM）-reliableと信頼性のないリンクレイヤモードが同時に上位層制御することなく利用することができる方法を記載しています。 （信頼性のあるトランスポートTCPやストリーム制御伝送プロトコル（SCTP）[RFC2960]を使用する場合）、無線リンクプロトコル（RLP）を係合させることができる信頼性の高いリンク層プロトコルが要求されます。そのようなUDPに基づくもののような遅延に敏感なアプリケーションでは、トランスペアレントモード（NO RLP）を使用することができます。著者らはまた、PPPネゴシエーションが、「クイックスタート-PPP」を使用して高レイテンシのGSMリンクの最適化を図ることができる方法について説明します。
In "Link Layer Based TCP Optimisation for Disconnecting Networks" [Scott], the authors describe performance problems that occur with reliable transport protocols facing periodic network disconnections, such as those due to signal fading or handoff. The authors define a disconnection as a period of connectivity loss that exceeds a retransmission timeout, but is shorter than the connection lifetime. One issue is that link-unaware senders continue to back off during periods of disconnection. The authors suggest that a link-aware reliable transport implementation halt retransmission after receiving a "Link Down" indication. Another issue is that on reconnection the lengthened retransmission times cause delays in utilizing the link.
「ネットワークを切断するためのリンク層ベースのTCPの最適化」[スコット]では、著者は、このようなフェージングやハンドオフ信号に起因するものと、定期的なネットワークの切断を、直面する信頼性の高いトランスポートプロトコルで発生するパフォーマンスの問題について説明します。著者は、再送タイムアウトを超えた接続性の損失の期間として切断を定義しますが、接続の寿命よりも短くなっています。 1つの問題は、リンクを知らない送信者は、切断の期間中に後退し続けることです。著者は、「リンクダウン」指示を受信した後、そのリンクを意識した信頼性の高いトランスポート実装停止再送を示唆しています。もう一つの問題は、再接続に長く再送回数は、リンクを利用する際の遅延を引き起こすということです。
To improve performance, a "smart link layer" is proposed, which stores the first packet that was not successfully transmitted on a connection, then retransmits it upon receipt of a "Link Up" indication. Since a disconnection can result in hosts experiencing different network conditions upon reconnection, the authors do not advocate bypassing slow start or attempting to raise the congestion window. Where IPsec is used and connections cannot be differentiated because transport headers are not visible, the first untransmitted packet for a given sender and destination IP address can be retransmitted. In addition to looking at retransmission of a single packet per connection, the authors also examined other schemes such as retransmission of multiple packets and simulated duplicate reception of single or multiple packets (known as rereception).
その後、「リンクアップ」指示の受信時に、それを再送信する、パフォーマンス、成功した接続上で送信されなかった最初のパケットを保存する「スマートリンク層」が提案されているが、改善するため。切断は再接続時に異なるネットワーク状態を経験するホストになることがあるので、著者は、スロースタートを迂回したり輻輳ウィンドウを高めるためにしようと主張していません。 IPsecが使用され、転送ヘッダが表示されていないため、接続は区別することができない場合、所与の送信元および宛先IPアドレスの最初の未送信パケットを再送することができます。接続ごとに単一のパケットの再送を見ることに加えて、著者はまた、複数のパケットの再送と（rereceptionとしても知られる）、単一または複数のパケットのシミュレートされた重複受信のような他の方式を検討しました。
In general, retransmission schemes were superior to rereception schemes, since rereception cannot stimulate fast retransmit after a timeout. Retransmission of multiple packets did not appreciably improve performance over retransmission of a single packet. Since the focus of the research was on disconnection rather than just lossy channels, a two-state Markov model was used, with the "up" state representing no loss, and the "down" state representing 100 percent loss.
rereceptionタイムアウト後に高速再送信を刺激することはできませんので、一般的には、再送スキームは、スキームをrereceptionよりも優れていました。複数のパケットの再送信はかなり単一パケットの再送を超えるパフォーマンスを改善しませんでした。研究の焦点は、切断だけではなく、損失性のチャネルであったので、二状態マルコフモデルは、損失を表すない状態、及び100％の損失を表す「ダウン」状態「アップ」で、使用されました。
In "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links" [Xylomenos], the authors use ns-2 to simulate the performance of various link layer recovery schemes (raw link without retransmission, go back N, XOR-based FEC, selective repeat, Karn's RLP, out-of-sequence RLP, and Berkeley Snoop) in stand-alone file transfer, Web browsing, and continuous media distribution. While selective repeat and Karn's RLP provide the highest throughput for file transfer and Web browsing scenarios, continuous media distribution requires a combination of low delay and low loss and the out-of-sequence RLP performed best in this scenario. Since the results indicate that no single link layer recovery scheme is optimal for all applications, the authors propose that the link layer implement multiple recovery schemes. Simulations of the multi-service architecture showed that the combination of a low-error rate recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme for UDP traffic (such as out-of-sequence RLP) provides for good performance in all scenarios. The authors then describe how a multi-service link layer can be integrated with Differentiated Services.
「マルチサービス・リンク・レイヤ：無線リンク上でインターネットパフォーマンスの向上へのアプローチ」で[Xylomenos]、著者は、再送信せずに生のリンク（各種リンク層の回復スキームのパフォーマンスをシミュレートするために、NS-2を使用し、Nを戻って、XORベースFEC、選択再送、カーンのRLP、アウトオブシーケンスRLP、およびスタンドアロンのファイル転送、Webブラウジング、および継続的なメディア配信中バークレースヌープ）。選択再送とカーンのRLPは、ファイル転送やWeb閲覧のシナリオのための最高のスループットを提供しているが、継続的なメディア配信は、低遅延、低損失の組み合わせを必要とし、アウトオブシーケンスRLPは、このシナリオで最もよく行わ。結果は、単一のリンク層の回復方式は、すべてのアプリケーションに最適でないことを示しているので、著者は、リンク層は、複数のリカバリスキームを実装することを提案します。マルチサービス・アーキテクチャのシミュレーションは、（カーンのRLPなど）TCP用の低エラーレートの回復スキームと（例えばシーケンス外のRLPなど）UDPトラフィックの低遅延化方式の組み合わせが良好なパフォーマンスを提供していることを示しましたすべてのシナリオインチ著者は、その後、マルチサービス・リンク層は、差別化サービスと統合することができる方法について説明します。
In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed Band" [Kamerman], the authors propose an open-loop rate adaptation algorithm known as Automatic Rate Fallback (ARF). In ARF, the sender adjusts the rate upwards after a fixed number of successful transmissions, and adjusts the rate downwards after one or two consecutive failures. If after an upwards rate adjustment the transmission fails, the rate is immediately readjusted downwards.
「のWaveLAN-II：ライセンスのないバンドのための高性能無線LAN」で[Kamerman]、作者は自動レートフォールバック（ARF）として知られているオープン・ループレート適応アルゴリズムを提案します。 ARFでは、送信者が上向きに成功送信の固定数の後にレートを調整し、下向きに1つのまたは2回連続して失敗した後にレートを調整します。送信が失敗した上向きレート調整後の場合、レートはすぐに下向きに再調整されます。
In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks" [RBAR], the authors propose a closed-loop rate adaptation approach that requires incompatible changes to the IEEE 802.11 MAC. In order to enable the sender to better determine the transmission rate, the receiver determines the packet length and signal to noise ratio (SNR) of a received RTS frame and calculates the corresponding rate based on a theoretical channel model, rather than channel usage statistics. The recommended rate is sent back in the CTS frame. This allows the rate (and potentially the transmit power) to be optimized on each transmission, albeit at the cost of requiring RTS/CTS for every frame transmission.
「マルチホップ無線ネットワークのためのレート適応型MACプロトコル」[RBAR]では、作者はIEEE 802.11 MACに互換性のない変更を必要とする閉ループレート適応アプローチを提案します。より良好な伝送速度を決定するために、送信者を可能にするために、受信機は、受信したRTSフレームの信号対雑音比（SNR）にパケット長と信号を決定し、対応する理論的なチャネルモデルに基づくレートではなく、チャネルの使用状況の統計を計算します。推奨レートは、CTSフレームに送り返されます。これは、速度（および潜在的に送信電力が）すべてのフレーム送信のためにRTS / CTSを必要とするコストではあるが、各伝送に最適化することができます。
In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11 a/h" [Qiao], the authors propose a scheme for optimizing transmit power. The proposal mandates the use of RTS/CTS in order to deal with hidden nodes, requiring that CTS and ACK frames be sent at full power. The authors utilize a theoretical channel model rather than one based on channel usage statistics.
「守銭奴：最適な低エネルギー伝送戦略IEEE 802.11 /時間」で[橋]、著者らは、送信電力を最適化するための方式を提案します。提案は、CTS及びACKフレームがフルパワーで送信されることを必要と隠れノードに対処するために、RTS / CTSを使用することを義務付け。著者は、理論的なチャネルモデルではなく、チャネル使用統計に基づいて1つを利用します。
In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage], the authors distinguish between low-latency implementations, which enable per-packet rate decisions, and high-latency implementations, which do not. The former implementations typically include dedicated CPUs in their design, enabling them to meet real-time requirements. The latter implementations are typically based on highly integrated designs in which the upper MAC is implemented on the host. As a result, due to operating system latencies the information required to make per-packet rate decisions may not be available in time.
「IEEE 802.11レート適応：実践的アプローチ」で[Lacage]、筆者はそうではない、パケットごとのレートの決定を可能にする低レイテンシの実装、及び高遅延の実装、区別します。かつての実装は、通常、彼らのデザインで、専用のCPUを含めたリアルタイムの要件を満たすためにそれらを可能にします。後者の実施態様は、典型的には、上側のMACがホスト上に実装された高度に統合された設計に基づいています。その結果、オペレーティングシステムに起因するには、パケットごとのレートの決定を行うために必要な情報が時間内に使用できない場合がありレイテンシ。
The authors propose an Adaptive ARF (AARF) algorithm for use with low-latency implementations. This enables rapid downward rate negotiation on failure to receive an ACK, while increasing the number of successful transmissions required for upward rate negotiation. The AARF algorithm is therefore highly stable in situations where channel properties are changing slowly, but slow to adapt upwards when channel conditions improve. In order to test the algorithm, the authors utilized ns-2 simulations as well as implementing a version of AARF adapted to a high-latency implementation, the AR 5212 chipset. The Multiband Atheros Driver for WiFi (MadWiFi) driver enables a fixed schedule of rates and retries to be provided when a frame is queued for transmission. The adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR), requests only one transmission at each of three rates, the last of which is the minimum available rate. This enables adaptation to short-term fluctuations in the channel with minimal latency. The AMRR algorithm provides performance considerably better than the existing MadWifi driver.
著者らは、低遅延の実装で使用するための適応ARF（AARF）アルゴリズムを提案します。上向きのレート交渉のために必要な成功した送信の数を増やしながらこれは、ACKを受信するために失敗した場合に迅速な下向きのレート交渉を可能にします。 AARFアルゴリズムは、チャネル特性がゆっくりと変化している状況で、したがって非常に安定であるが、チャネル状態が改善する場合に上方に適応するのが遅いです。アルゴリズムをテストするために、著者ら利用NS-2シミュレーションならびにAARFのバージョンを実装する高レイテンシ実装、AR 5212チップセットに適合しました。マルチバンドAtherosの無線LAN用のドライバ（MadWiFi）ドライバは、フレームが送信のためにキューに入れられたときに速度及びリトライの固定スケジュールを提供することを可能にします。適応マルチレートリトライ（AMRR）として知られている適合アルゴリズム、最小の利用可能なレートで最後た3つの速度の各々で要求だけ送信を。これは、最小限の待ち時間とチャネルの短期的な変動への適応を可能にします。 AMRRアルゴリズムは、既存のMadWifiドライバよりもかなり優れたパフォーマンスを提供します。
In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength Measurement" [Pavon], the authors propose an algorithm by which a STA adjusts the transmission rate based on a comparison of the received signal strength (RSS) from the AP with dynamically estimated threshold values for each transmission rate. Upon reception of a frame, the STA updates the average RSS, and on transmission the STA selects a rate and adjusts the RSS threshold values based on whether or not the transmission is successful. In order to validate the algorithm, the authors utilized an OPNET simulation without interference, and an ideal curve of bit error rate (BER) vs. signal to noise ratio (SNR) was assumed. Not surprisingly, the simulation results closely matched the maximum throughput achievable for a given signal to noise ratio, based on the ideal BER vs. SNR curve.
「受信信号強度測定を介して、IEEE 802.11 WLANのためのリンク適応戦略」[パボン]において、著者らは、STAが動的に推定とAPからの受信信号強度（RSS）の比較に基づいて、送信レートを調整することにより、アルゴリズムを提案します各伝送速度の閾値。フレームを受信すると、STAは、RSSの平均値を更新し、送信にSTAは、レートを選択し、送信が成功したか否かに基づいて、RSS閾値を調整します。アルゴリズムを検証するために、著者らは、推定された信号対雑音比（SNR）対干渉なしOPNETシミュレーション、およびビット誤り率（BER）の理想的な曲線を利用しました。驚くことではないが、シミュレーションの結果は、密接にSNR曲線対理想BERに基づいて、ノイズ比に対して所定の信号のための達成可能な最大スループットを一致しました。
In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors describe a hybrid technique utilizing Signal Strength Indication (SSI) data to constrain the potential rates selected by statistics-based automatic rate control. Statistics-based rate control techniques include:
「IEEE 802.11のためのハイブリッドレート制御」[Haratcherev]において、著者らは、統計ベースの自動速度制御により選択された潜在的な速度を制約するために信号強度表示（SSI）のデータを利用したハイブリッド技術を記載しています。統計ベースのレート制御技術は、次のとおりです。
Maximum Throughput
最大スループット
This technique, which was chosen as the statistics-based technique in the hybrid scheme, sends a fraction of data at adjacent rates in order to estimate which rate provides the maximum throughput. Since accurate estimation of throughput requires a minimum number of frames to be sent at each rate, and only a fraction of frames are utilized for this purpose, this technique adapts more slowly at lower rates; with 802.11b rates, the adaptation time scale is typically on the order of a second. Depending on how many rates are tested, this technique can enable adaptation beyond adjacent rates. However, where maximum rate and low frame loss are already being encountered, this technique results in lower throughput.
ハイブリッド方式で統計ベースの技術として選択されたこの技術は、最大スループットを提供するレート推定するために、隣接するレートでデータの一部を送信します。スループットの正確な推定は、それぞれのレートで送信されるフレームの最小数を必要とし、フレームの一部のみがこの目的のために利用され、この技術は、より低い速度でよりゆっくりと適応するため、 802.11bのレートで、適応時間スケールは、第二のオーダーです。テストされているどのように多くの割合に応じて、この技術は、隣接する速度を超えた適応を可能にすることができます。最大レートと低フレーム損失が既に遭遇している場合しかし、この技術は低いスループットをもたらします。
Frame Error Rate (FER) Control
フレーム誤り率（FER）コントロール
This technique estimates the FER, attempting to keep it between a lower limit (if FER moves below, increase rate) and upper limit (if FER moves above, decrease rate). Since this technique can utilize all the transmitted data, it can respond faster than maximum throughput techniques. However, there is a tradeoff of reaction time versus FER estimation accuracy; at lower rates either reaction times slow or FER estimation accuracy will suffer. Since this technique only measures the FER at the current rate, it can only enable adaptation to adjacent rates.
この技術は、下限値（FERは以下移動した場合、速度を増加させる）と上限値（FERは、上記移動した場合、速度を低下させる）の間それを維持しようとし、FERを推定します。この技術は、すべての送信されたデータを利用することができるので、最大スループット技術よりも速く応答することができます。しかしながら、FERの推定精度に対する反応時間のトレードオフがあります。低いレートのいずれかの反応時間で、低速またはFER推定精度が低下します。この技術は、現在のレートでFERを測定するので、それだけで、隣接金利への適応を可能にすることができます。
Retry-based
再試行ベース
This technique modifies FER control techniques by enabling rapid downward rate adaptation after a number (5-10) of unsuccessful retransmissions. Since fewer packets are required, the sensitivity of reaction time to rate is reduced. However, upward rate adaptation proceeds more slowly since it is based on a collection of FER data. This technique is limited to adaptation to adjacent rates, and it has the disadvantage of potentially worsening frame loss due to contention.
この技術は、失敗した再送信の数（5-10）の後に急速下方レート適応を可能にすることによって、FER制御技術を変更します。少数のパケットが必要とされているので、速度と反応時間の感度が低減されます。それはFERデータの収集に基づいているので、上向きのレート適応は、よりゆっくりと進行します。この技術は、隣接速度への適応に限定されず、それは潜在的に競合によるフレーム損失を悪化させるという欠点を有しています。
While statistics-based techniques are robust against short-lived link quality changes, they do not respond quickly to long-lived changes. By constraining the rate selected by statistics-based techniques based on ACK SSI versus rate data (not theoretical curves), more rapid link adaptation was enabled. In order to ensure rapid adaptation during rapidly varying conditions, the rate constraints are tightened when the SSI values are changing rapidly, encouraging rate transitions. The authors validated their algorithms by implementing a driver for the Atheros AR5000 chipset, and then testing its response to insertion and removal from a microwave oven acting as a Faraday cage. The hybrid algorithm dropped many fewer packets than the maximum throughput technique by itself.
統計ベースの技術は短命リンク品質の変化に対して頑健であるが、それらは長寿命の変化に迅速に対応していません。速度データ（ない理論曲線）対ACK SSIに基づいた統計ベースの技術によって選択されたレートを制約することによって、より迅速なリンク適合を可能にしました。急速に変化する条件時の迅速な適応を確実にするためには、レート制約はSSI値は、レートの移行を奨励し、急速に変化している時に締められています。著者らは、AtherosのAR5000チップセット用のドライバを実装し、次にファラデーケージとして働く電子レンジからの挿入および除去に対するその応答を試験することにより、それらのアルゴリズムを検証しました。ハイブリッドアルゴリズムは、それ自体で最大スループット技術より多くの、より少ないパケットを落としました。
In order to estimate the SSI of data at the receiver, the ACK SSI was used. This approach does not require the receiver to provide the sender with the received power, so that it can be implemented without changing the IEEE 802.11 MAC. Calibration of the rate versus ACK SSI curves does not require a symmetric channel, but it does require that channel properties in both directions vary in a proportional way and that the ACK transmit power remains constant. The authors checked the proportionality assumption and found that the SSI of received data correlated highly (74%) with the SSI of received ACKs. Low pass filtering and monotonicity constraints were applied to remove noise in the rate versus SSI curves. The resulting hybrid rate adaptation algorithm demonstrated the ability to respond to rapid deterioration (and improvement) in channel properties, since it is not restricted to moving to adjacent rates.
受信機でのデータのSSIを推定するために、ACK SSIを使用しました。このアプローチは、IEEE 802.11 MACを変更することなく実現することができるように、受信電力と送信者を提供するために受信機を必要としません。 ACK SSI曲線対速度のキャリブレーションは、対称チャネルを必要としないが、それは、両方向にそのチャネル特性が比例ように変化し、ACKの送信電力が一定である必要はありません。著者らは、比例仮定を確認し、受信したACKのSSIと高度に相関受信データのSSI（74％）が見つかりました。ローパスフィルタリングと単調性制約がSSI曲線対速度のノイズを除去するために適用しました。得られたハイブリッドレート適応アルゴリズムは、それが隣接速度に移動するに限定されるものではないので、チャネル特性の急激な低下（改善）に応答する能力を実証しました。
In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs" [CARA], the authors propose Collision-Aware Rate Adaptation (CARA). This involves utilization of Clear Channel Assessment (CCA) along with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS) mechanism to differentiate losses caused by frame collisions from losses caused by channel conditions. Rather than decreasing rate as the result of frame loss due to collisions, which leads to increased contention, CARA selectively enables RTS/CTS (e.g., after a frame loss), reducing the likelihood of frame loss due to hidden stations. CARA can also utilize CCA to determine whether a collision has occurred after a transmission; however, since CCA may not detect a significant fraction of all collisions (particularly when transmitting at low rate), its use is optional. As compared with ARF, in simulations the authors show large improvements in aggregate throughput due to addition of adaptive RTS/CTS, and additional modest improvements with the additional help of CCA.
では：[CARA] "CARA IEEE 802.11 WLANの衝突を意識レートアダプテーション"、著者は衝突-Awareのレートアダプテーション（CARA）を提案します。これは、チャネル条件による損失からフレームの衝突による損失を区別するための送信要求/クリア・ツー・センド（RTS / CTS）メカニズムの適応と一緒にクリアチャネルアセスメント（CCA）の利用を必要とします。むしろ増加競合につながるによる衝突にフレーム消失の結果としての速度を減少させるよりも、CARAは選択により隠されたステーションにフレーム損失の可能性を低減する、（フレーム損失の後、例えば、）RTS / CTSを可能にします。 CARAはまた、衝突が送信後に発生したか否かを決定するためにCCAを利用することができます。しかしながら、CCA以降のすべての衝突のかなりの部分（特に低レートで送信）検出されないことがあり、その使用は任意です。 ARFと比較して、シミュレーションで著者が原因適応RTS / CTS、およびCCAの追加の助けを借りて、追加のささやかな改善のほかに総スループットの大幅な改善を示します。
In "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust], the authors implemented the ARF, AARF, and SampleRate [SampleRate] algorithms on a programmable Access Point platform, and experimentally examined the performance of these algorithms as well as the ONOE [ONOE] algorithm implemented in MadWiFi. Based on their experiments, the authors critically examine the assumptions underlying existing rate negotiation algorithms:
「802.11ワイヤレスネットワークのための堅牢なレートアダプテーション」で[堅牢]は、著者は、プログラム可能なアクセスポイントのプラットフォーム上でARF、AARF、およびSampleRateの[SampleRateの]アルゴリズムを実装し、実験的にこれらのアルゴリズムの性能だけでなく、尾上[尾上を検討しました】アルゴリズムはMadWiFiに実装します。彼らの実験に基づいて、著者は批判的に既存のレート交渉アルゴリズムの基礎となる仮定を調べます。
Decrease transmission rate upon severe frame loss Where severe frame loss is due to channel conditions, rate reduction can improve throughput. However, where frame loss is due to contention (such as from hidden stations), reducing transmission rate increases congestion, lowering throughput and potentially leading to congestive collapse. Instead, the authors propose adaptive enabling of RTS/CTS so as to reduce contention due to hidden stations. Once RTS/CTS is enabled, remaining losses are more likely to be due to channel conditions, providing more reliable guidance on increasing or decreasing transmission rate.
重度のフレーム損失がチャネル状態に起因する重篤なフレーム損失時の伝送速度を減少、速度低下、スループットを向上させることができます。しかし、ここでフレーム損失が、スループットを低下させ、潜在的にうっ血性崩壊につながる、伝送レートが増加輻輳を低減する、（例えば、隠れた局からのような）の競合に起因するものです。隠れた所に競合を減少させるようにする代わりに、著者は、RTS / CTSの有効化適応を提案します。 RTS / CTSを有効にすると、残りの損失が増加したり、伝送速度を低下させる上で、より信頼性の高いガイダンスを提供する、チャネル条件が原因である可能性が高いです。
Use probe frames to assess possible new rates Probe frames reliably estimate frame loss at a given rate unless the sample size is sufficient and the probe frames are of comparable length to data frames. The authors argue that rate adaptation schemes such as SampleRate are too sensitive to loss of probe packets. In order to satisfy sample size constraints, a significant number of probe frames are required. This can increase frame loss if the probed rate is too high, and can lower throughput if the probed rate is too low. Instead, the authors propose assessment of the channel condition by tracking the frame loss ratio within a window of 5 to 40 frames.
プローブがサンプルサイズが十分であり、プローブ用フレームは、データフレームに匹敵する長さのものでない限り、確実に所定の速度でフレーム損失を推定フレーム可能新しい率を評価するために、プローブ用フレームを使用します。著者は、このようなのSampleRateなどのレート適応方式は、プローブパケットの損失にあまりにも敏感であることを主張しています。サンプルサイズの制約を満たすために、プローブ用フレームの有意な数が必要です。これは、探査率が高すぎる場合、フレーム損失を増加させることができ、かつ探査率が低すぎる場合のスループットを下げることができます。その代わりに、著者らは、5〜40フレームのウィンドウ内でフレーム損失率を追跡することによって、チャネル状態の評価を提案します。
Use consecutive transmission successes/losses to increase/decrease rate The authors argue that consecutive successes or losses are not a reliable basis for rate increases or decreases; greater sample size is needed.
著者は連続成功または損失は、速度が増加または減少のための信頼できる根拠はないと主張している率減少/増加する連続送信成功/損失を使用します。より大きなサンプルサイズが必要とされています。
Use PHY metrics like SNR to infer new transmission rate The authors argue that received signal to noise ratio (SNR) routinely varies 5 dB per packet and that variations of 10-14 dB are common. As a result, rate decisions based on SNR or signal strength can cause transmission rate to vary rapidly. The authors question the value of such rapid variation, since studies such as [Aguayo] show little correlation between SNR and frame loss probability. As a result, the authors argue that neither received signal strength indication (RSSI) nor background energy level can be used to distinguish losses due to contention from those due to channel conditions. While multi-path interference can simultaneously result in high signal strength and frame loss, the relationship between low signal strength and high frame loss is stronger. Therefore, transmission rate decreases due to low received signal strength probably do reflect sudden worsening in channel conditions, although sudden increases may not necessarily indicate that channel conditions have improved.
著者らは雑音比（SNR）、受信した信号が定期パケットあたり5 dBに変化することが10〜14デシベル変動が一般的であると主張している新たな伝送レートを推定するSNRのようなPHYメトリックを使用。結果として、SNRあるいは信号強度に基づいて、レートの決定は、伝送速度が急激に変化させることができます。このような[Aguayo]などの研究がSNRとフレーム損失確率の間にはほとんど相関関係を示すため著者らは、このような急速な変化の値を問います。その結果、著者らは、バックグラウンドエネルギーレベルは、チャネル条件に起因するものとの競合による損失を区別するために使用され得ることも、受信信号強度表示（RSSI）も主張します。マルチパス干渉が同時に高い信号強度とフレーム損失をもたらすことができるが、低い信号強度と高フレーム損失との関係が強いです。したがって、伝送速度が突然増加は必ずしも条件が改善されたそのチャネルを示さないかもしれないが、おそらく、チャネル状態の悪化突然反映しない低い受信信号強度に起因して低下します。
Long-term smoothened operation produces best average performance The authors present evidence that frame losses more than 150 ms apart are uncorrelated. Therefore, collection of statistical data over intervals of 1 second or greater reduces responsiveness, but does not improve the quality of transmission rate decisions. Rather, the authors argue that a sampling period of 100 ms provides the best average performance. Such small sampling periods also argue against use of probes, since probe packets can only represent a fraction of all data frames and probes collected more than 150 ms apart may not provide reliable information on channel conditions.
長期平滑化操作は、最高の平均パフォーマンス著者フレーム損失は150以上のミリ秒離れて無相関であることが、本証拠を生成します。そのため、1秒以上の間隔で統計的データの収集は、応答性を減少させますが、伝送速度の決定の品質を向上させるものではありません。むしろ、著者は、100ミリ秒のサンプリング周期が最高の平均パフォーマンスを提供することを主張しています。そのような小さなサンプリング周期は、チャネル条件に関する信頼できる情報を提供しないかもしれないプローブパケットのみが150以上のミリ秒離れて収集されたすべてのデータ・フレームおよびプローブの画分を表すことができるので、プローブの使用に対して主張しています。
Based on these flaws, the authors propose the Robust Rate Adaptation Algorithm (RRAA). RRAA utilizes only the frame loss ratio at the current transmission rate to determine whether to increase or decrease the transmission rate; PHY layer information or probe packets are not used. Each transmission rate is associated with an estimation window, a maximum tolerable loss threshold (MTL) and an opportunistic rate increase threshold (ORI). If the loss ratio is larger than the MTL, the transmission rate is decreased, and if it is smaller than the ORI, transmission rate is increased; otherwise transmission rate remains the same. The thresholds are selected in order to maximize throughput. Although RRAA only allows movement between adjacent transmission rates, the algorithm does not require collection of an entire estimation window prior to increasing or decreasing transmission rates; if additional data collection would not change the decision, the change is made immediately.
これらの欠陥に基づいて、著者は、堅牢なレート適応アルゴリズム（RRAA）を提案します。 RRAAは、伝送速度を増加または減少させるかどうかを決定するために、現在の伝送速度でのみフレーム損失率を利用します。 PHYレイヤ情報やプローブパケットが使用されていません。各伝送レートを予測窓、最大許容損失閾値（MTL）及び日和見レート増加閾値（ORI）と関連しています。損失率がMTLよりも大きい場合、伝送速度が低下し、それがORIよりも小さい場合には、伝送速度が増加します。それ以外の場合は、伝送速度は同じまま。しきい値は、スループットを最大にするために選択されています。 RRAAのみ隣接する伝送レートとの間の移動を可能にするが、このアルゴリズムは、従来の伝送速度を増加または減少に全体予測窓の収集を必要としません。追加のデータ収集が決定を変更しないならば、変更はすぐに行われます。
The authors validate the RRAA algorithm using experiments and field trials; the results indicate that RRAA without adaptive RTS/CTS outperforms the ARF, AARF, and Sample Rate algorithms. This occurs because RRAA is not as sensitive to transient frame loss and does not use probing, enabling it to more frequently utilize higher transmission rates. Where there are no hidden stations, turning on adaptive RTS/CTS reduces performance by at most a few percent. However, where there is substantial contention from hidden stations, adaptive RTS/CTS provides large performance gains, due to reduction in frame loss that enables selection of a higher transmission rate.
著者は、実験や実地試験を使用してRRAAアルゴリズムを検証します。結果はRRAAが適応RTSなし/ CTSは、ARF、AARF、およびサンプルレートアルゴリズムよりも優れていることを示しています。 RRAAが一時フレームの損失に敏感ではなく、より頻繁に、より高い伝送速度を利用することを可能に、プロービング使用していないために発生します。隠れステーションが存在しない場合には、適応RTS / CTSをオンにすると、せいぜい数パーセントによってパフォーマンスが低下します。隠れ局から実質的な競合がある場合しかし、適応RTS / CTSは、より高い伝送レートの選択を可能にするフレーム損失の低減に、大きなパフォーマンスの向上を提供します。
In "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN" [Vertical], the authors propose use of signal strength and link utilization in order to optimize vertical handoff. WLAN to WWAN handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a threshold (S1), Fast Fourier Transform (FFT)-based decay detection is undertaken to determine if the signal is likely to continue to decay. If so, then handoff to the WWAN is initiated when the signal falls below the minimum acceptable level (S2). WWAN to WLAN handoff is driven by both PHY and MAC characteristics of the IEEE 802.11 target network. At the PHY layer, characteristics such as SSI are examined to determine if the signal strength is greater than a minimum value (S3). At the MAC layer, the IEEE 802.11 Network Allocation Vector (NAV) occupation is examined in order to estimate the maximum available bandwidth and mean access delay. Note that depending on the value of S3, it is possible for the negotiated rate to be less than the available bandwidth. In order to prevent premature handoff between WLAN and WWAN, S1 and S2 are separated by 6 dB; in order to prevent oscillation between WLAN and WWAN media, S3 needs to be greater than S1 by an appropriate margin.
「WWANとWLAN間の垂直ハンドオフのための効率的なモビリティ・マネジメント」[縦]では、著者は、垂直ハンドオフを最適化するために、信号強度およびリンク利用率の使用を提案しています。 WWANハンドオフへのWLANは、SSIの崩壊によって駆動されます。 IEEE 802.11 SSIが閾値（S1）を下回った場合、高速フーリエ変換（FFT）を崩壊検出をベース信号が減衰し続ける可能性があるかどうかを決定するために行われます。もしそうであれば、信号が最小許容レベル（S2）を下回った場合、その後、WWANへのハンドオフが開始されます。 WLANハンドオフWWANはIEEE 802.11ターゲットネットワークの両方PHY及びMAC特性によって駆動されます。 PHY層では、そのようなSSIなどの特性は、信号強度が最小値（S3）よりも大きいか否かを決定するために検査されます。 MAC層では、IEEE 802.11ネットワークアロケーションベクトル（NAV）職業は、最大利用可能な帯域幅を推定し、アクセス遅延を意味するために検査されます。ネゴシエートされたレートは、利用可能な帯域幅未満であるためにS3の値に応じて、それが可能であることに留意されたいです。 WLANとWWAN間の時期尚早のハンドオフを防止するために、S1及びS2は6dBだけ分離されています。 WLANとWWAN媒体との間の振動を防止するために、S3は、適切なマージンによってS1よりも大きくする必要があります。
A.2. Internet Layer
A.2。インターネット層
Within the Internet layer, proposals have been made for utilizing link indications to optimize IP configuration, to improve the usefulness of routing metrics, and to optimize aspects of Mobile IP handoff.
インターネット層の中で、提案はルーティングメトリックの有用性を改善するために、モバイルIPハンドオフの側面を最適化するために、IPの設定を最適化するために、リンク指摘を利用するために行われています。
In "Analysis of link failures in an IP backbone" [Iannaccone], the authors investigate link failures in Sprint's IP backbone. They identify the causes of convergence delay, including delays in detection of whether an interface is down or up. While it is fastest for a router to utilize link indications if available, there are situations in which it is necessary to depend on loss of routing packets to determine the state of the link. Once the link state has been determined, a delay may occur within the routing protocol in order to dampen link flaps. Finally, another delay may be introduced in propagating the link state change, in order to rate limit link state advertisements, and guard against instability.
「IPバックボーンでリンク障害の分析」[Iannaccone]では、著者はSprint社のIPバックボーンでリンク障害を調査します。彼らは、インターフェイスがダウンまたはアップしているかどうかの検出の遅れを含む、収束遅延の原因を特定します。それが利用可能な場合、リンク適応を利用するルータの最速であるが、リンクの状態を決定するためにルーティング・パケットの損失に依存することが必要である状況があります。リンク状態が決定されると、遅延は、リンクフラップを減衰するために、ルーティングプロトコル内で発生してもよいです。最後に、別の遅延は限界リンク状態広告を評価し、そして不安定性を防ぐために、リンク状態の変化を伝播に導入することができます。
"Bidirectional Forwarding Detection" [BFD] notes that link layers may provide only limited failure indications, and that relatively slow "Hello" mechanisms are used in routing protocols to detect failures when no link layer indications are available. This results in failure detection times of the order of a second, which is too long for some applications. The authors describe a mechanism that can be used for liveness detection over any media, enabling rapid detection of failures in the path between adjacent forwarding engines. A path is declared operational when bidirectional reachability has been confirmed.
「双方向フォワーディング検出」[BFD]は、そのリンク層は限ら故障表示を提供することができるノート、その比較的遅い「こんにちは」のメカニズムにはリンクレイヤ指標が利用可能でない場合に故障を検出するために、ルーティングプロトコルで使用されます。これは、いくつかのアプリケーションのために長すぎる二、程度の障害検出時間になります。著者らは、隣接する転送エンジンとの間の経路の障害の迅速な検出を可能にする、任意の媒体上にライブネス検出のために使用することができる機構を記載しています。双方向の到達性が確認されたときにパスが運用宣言されています。
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host that has moved to a new point of attachment utilizes a bidirectional reachability test in parallel with DHCP [RFC2131] to rapidly reconfirm an operable configuration.
「IPv4の検出ネットワークアタッチメント（DNA）」[RFC4436]で、新しい接続点に移動したホストがDHCPと並列に急速に動作可能な構成を再確認するために[RFC2131]を双方向到達可能性テストを利用します。
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example" [Park], the authors propose that the mobile node send a router solicitation on receipt of a "Link Up" indication in order to provide lower handoff latency than would be possible using generic movement detection [RFC3775]. The authors also suggest immediate invalidation of the Care-of Address (CoA) on receipt of a "Link Down" indication. However, this is problematic where a "Link Down" indication can be followed by a "Link Up" indication without a resulting change in IP configuration, as described in [RFC4436].
「L2トリガーの最適化されたモバイルIPv6の垂直ハンドオーバ：802.11 / GPRS例」では、[パーク]、筆者は、モバイルノードがなりよりも低いハンドオフ遅延を提供するために、「リンクアップ」指示の受信にルータ要請を送信することを提案します可能な汎用的な動き検出[RFC3775]を使用して。著者はまた、「リンクダウン」指示の受信に気付アドレス（CoA）の即時無効化を示唆しています。 [RFC4436]に記載されているようしかし、これは問題である「リンクダウン」指示は、IP構成の結果として生じる変更することなく、「リンクアップ」表示が続くことができます。
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors suggest that MIPv4 Registration messages be carried within Information Elements of IEEE 802.11 Association/Reassociation frames, in order to minimize handoff delays. This requires modification to the mobile node as well as 802.11 APs. However, prior to detecting network attachment, it is difficult for the mobile node to determine whether or not the new point of attachment represents a change of network. For example, even where a station remains within the same ESS, it is possible that the network will change. Where no change of network results, sending a MIPv4 Registration message with each Association/Reassociation is unnecessary. Where a change of network results, it is typically not possible for the mobile node to anticipate its new CoA at Association/Reassociation; for example, a DHCP server may assign a CoA not previously given to the mobile node. When dynamic VLAN assignment is used, the VLAN assignment is not even determined until IEEE 802.1X authentication has completed, which is after Association/Reassociation in [IEEE-802.11i].
[ムン]「802.11とモバイルIPv4のレイヤ2ハンドオフ」では、著者はMIPv4の登録メッセージは、ハンドオフ遅延を最小限に抑えるために、IEEE 802.11協会/再アソシエーションフレームの情報要素の中に運ばれることを示唆しています。これは、モバイルノードと同様に802.11 APに変更する必要があります。モバイルノードが新しい接続点は、ネットワークの変化を表しているか否かを判定するためしかし、ネットワーク接続を検出する前に、それが困難です。例えば、ステーションが同じESS内に留まる場合でも、ネットワークが変更されることが可能です。どこにネットワーク結果の変更は、各協会/再アソシエーションとのMIPv4登録メッセージを送信することは不要ではありません。モバイルノードは協会/再アソシエーションでその新しいCoAを予測するためのネットワーク結果の変化は、それが一般的に不可能な場合。例えば、DHCPサーバは、以前にモバイルノードに与えられていないCoAを割り当てることができます。ダイナミックVLAN割り当てが使用されるときIEEE 802.1X認証が完了するまで、VLAN割り当てが偶数でアソシエーション/再アソシエーション[IEEE-802.11i規格]の後であり、決定されません。
In "Link Characteristics Information for Mobile IP" [Lee], link characteristics are included in registration/Binding Update messages sent by the mobile node to the home agent and correspondent node. Where the mobile node is acting as a receiver, this allows the correspondent node to adjust its transport parameters window more rapidly than might otherwise be possible. Link characteristics that may be communicated include the link type (e.g., 802.11b, CDMA (Code Division Multiple Access), GPRS (General Packet Radio Service), etc.) and link bandwidth. While the document suggests that the correspondent node should adjust its sending rate based on the advertised link bandwidth, this may not be wise in some circumstances. For example, where the mobile node link is not the bottleneck, adjusting the sending rate based on the link bandwidth could cause congestion. Also, where the transmission rate changes frequently, sending registration messages on each transmission rate change could by itself consume significant bandwidth. Even where the advertised link characteristics indicate the need for a smaller congestion window, it may be non-trivial to adjust the sending rates of individual connections where there are multiple connections open between a mobile node and correspondent node. A more conservative approach would be to trigger parameter re-estimation and slow start based on the receipt of a registration message or Binding Update.
「モバイルIPのためのリンク特性情報」[リー]で、リンクの特性は、ホームエージェントとコレスポンデントノードにモバイルノードによって送信される登録/バインディング更新メッセージに含まれています。モバイルノードが受信機として動作している場合、これは、コレスポンデントノードは、より迅速にそうでないことができるかもしれないよりもその輸送パラメータウィンドウを調整することができます。通信することができるリンクの特性、リンクのタイプ（例えば、802.11、CDMA（符号分割多元接続）、GPRS（汎用パケット無線サービス）等）、リンク帯域幅を含みます。文書は、コレスポンデントノードが広告を出してリンク帯域幅に基づいて、送信レートを調整すべきであることを示唆しているが、これはいくつかの状況では賢明ではないかもしれません。モバイルノードのリンクがボトルネックにならない場合の例については、輻輳が発生する可能性があり、リンク帯域幅に基づいて、送信レートを調整。また、どこの伝送レートの変動、頻繁に、各伝送速度の変化に登録メッセージを送信することは、それ自体で大きな帯域幅を消費することができます。アドバタイズリンク特性が小さい輻輳ウィンドウの必要性を示す場合でも、モバイルノードとコレスポンデントノードとの間のオープン複数の接続が存在する個々の接続の送信レートを調整するために非自明であってもよいです。より保守的なアプローチは、登録メッセージ又はバインディング更新の受信に基づいてパラメータを再推定し、スロースタートをトリガするであろう。
In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that Mobile Ad-hoc NETwork (MANET) routing protocols have a tendency to concentrate traffic since they utilize shortest-path metrics and allow nodes to respond to route queries with cached routes. The authors propose that nodes participating in an ad-hoc wireless mesh monitor local conditions such as MAC delay, buffer consumption, and packet loss. Where congestion is detected, this is communicated to neighboring nodes via an IP option. In response to moderate congestion, nodes suppress route requests; where major congestion is detected, nodes rate control transport connections flowing through them. The authors argue that for ad-hoc networks, throttling by intermediate nodes is more effective than end-to-end congestion control mechanisms.
「ホットスポット緩和プロトコル（HMP）」[HMP]では、彼らが最短パスメトリックを利用して、ノードがキャッシュされて、ルートクエリに応答できるようにするため、モバイルアドホックネットワーク（MANET）のルーティングプロトコルは、トラフィックが集中する傾向があることに留意されたいですルート。著者らは、アドホック無線メッシュに参加しているノードは、MAC遅延、バッファ消費、及びパケット損失等の現地の状況を監視することを提案します。輻輳が検出される場合、これはIPオプションを介して隣接ノードに通信されます。中程度の混雑に応答して、ノードがルート要求を抑制する。主要な輻輳が検出された場合、それらを介して流れる速度制御交通機関の接続ノード。著者らは、アドホックネットワークのため、中間ノードによって絞りは、エンドツーエンドの輻輳制御メカニズムよりも効果的であると主張しています。
A.3. Transport Layer
A.3。トランスポート層
Within the transport layer, proposals have focused on countering the effects of handoff-induced packet loss and non-congestive loss caused by lossy wireless links.
トランスポート層の中で、提案はハンドオフによって誘発されるパケット損失や損失の多い無線リンクによって引き起こされる非うっ血性損失の影響に対処に焦点を当てています。
Where a mobile host moves to a new network, the transport parameters (including the RTT, RTO, and congestion window) may no longer be valid. Where the path change occurs on the sender (e.g., change in outgoing or incoming interface), the sender can reset its congestion window and parameter estimates. However, where it occurs on the receiver, the sender may not be aware of the path change.
モバイルホストが新しいネットワークに移動した場合、（RTT、RTO、および輻輳ウィンドウを含む）のトランスポートパラメータは、もはや有効ではないかもしれません。経路変更が送信者（発信または着信インターフェイスで例えば、変化）で発生した場合、送信者は、その混雑ウィンドウ及びパラメータ推定値をリセットすることができます。しかし、それは受信機で発生した場合は、送信者は、パスの変更を認識できない場合があります。
In "The BU-trigger method for improving TCP performance over Mobile IPv6" [Kim], the authors note that handoff-related packet loss is interpreted as congestion by the transport layer. In the case where the correspondent node is sending to the mobile node, it is proposed that receipt of a Binding Update by the correspondent node be used as a signal to the transport layer to adjust cwnd and ssthresh values, which may have been reduced due to handoff-induced packet loss. The authors recommend that cwnd and ssthresh be recovered to pre-timeout values, regardless of whether the link parameters have changed. The paper does not discuss the behavior of a mobile node sending a Binding Update, in the case where the mobile node is sending to the correspondent node.
[金]「モバイルIPv6上のTCPの性能を改善するためのBUトリガ方式」において、著者らは、ハンドオフに関連するパケット損失は、トランスポート層によって輻輳と解釈されることに注意してください。コレスポンデント・ノードは、モバイルノードに送信された場合には、通信相手ノードによってバインディング更新の受信をするために低減されていてもよいCWNDおよびSSTHRESHの値を調整するためのトランスポート層への信号として使用することが提案されていますハンドオフ誘発性のパケット損失。著者は、CWNDとSSTHRESHは関係なく、リンクパラメータが変更されたかどうかの、値がタイムアウト事前に回収されることをお勧めします。紙は、モバイルノードがコレスポンデントノードに送信された場合には、バインディングアップデートを送信するモバイルノードの動作については説明しません。
In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate Control" [Gurtov], the authors examine the effect of explicit handover notifications on TCP-friendly rate control (TFRC). Where explicit handover notification includes information on the loss rate and throughput of the new link, this can be used to instantaneously change the transmission rate of the sender. The authors also found that resetting the TFRC receiver state after handover enabled parameter estimates to adjust more quickly.
[Gurtov]「TCPフレンドリーレート制御の性能に垂直ハンドオーバの影響」で、著者は、TCPフレンドリーなレート制御（TFRC）の明示的なハンドオーバーの通知の効果を調べます。明示的ハンドオーバ通知は新しいリンクの損失率とスループットに関する情報を含む場合、これは瞬時に送信者の伝送速度を変更するために使用することができます。著者らはまた、ハンドオーバ有効パラメータ推定値の後にTFRCの受信状態をリセットすると、より迅速に調整することがわかりました。
In "Adapting End Host Congestion Control for Mobility" [Eddy], the authors note that while MIPv6 with route optimization allows a receiver to communicate a subnet change to the sender via a Binding Update, this is not available within MIPv4. To provide a communication vehicle that can be universally employed, the authors propose a TCP option that allows a connection endpoint to inform a peer of a subnet change. The document does not advocate utilization of "Link Up" or "Link Down" events since these events are not necessarily indicative of subnet change. On detection of subnet change, it is advocated that the congestion window be reset to INIT_WINDOW and that transport parameters be re-estimated. The authors argue that recovery from slow start results in higher throughput both when the subnet change results in lower bottleneck bandwidth as well as when bottleneck bandwidth increases.
「モビリティする適応型エンドホスト輻輳制御」[エディ]では、著者は、ルート最適化とMIPv6の受信機がバインディングアップデートを経由して送信者にサブネット変更を通信することができますが、これはMIPv4の内で利用できないことに注意してください。普遍的に使用することができる通信車両を提供するために、著者は、接続エンドポイントは、サブネット変更のピアに通知することを可能にするTCPオプションを提案します。これらのイベントは、必ずしもサブネット変更を示すものではありませんので、文書は「リンクアップ」または「リンクダウン」イベントの活用を提唱していません。サブネット変更を検出すると、輻輳ウィンドウがINIT_WINDOWと輸送パラメータを再推定することにリセットすることを提唱しています。著者は、両方の時にサブネット変更低い結果にボトルネック帯域内だけでなく、ボトルネック帯域が増加し、より高いスループットでのスロースタートの結果から、その回復を主張しています。
In "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN" [Vertical], the authors propose a "Virtual Connectivity Manager", which utilizes local connection translation (LCT) and a subscription/notification service supporting simultaneous movement in order to enable end-to-end mobility and maintain TCP throughput during vertical handovers.
[縦]「WWANとWLAN間の垂直ハンドオフのための効率的なモビリティ・マネジメント」では、著者は、ローカル接続変換（LCT）とエンドを有効にするために同時移動をサポートするサブスクリプション/通知サービスを利用して「仮想接続マネージャ」を提案しますエンドツーエンドのモビリティと垂直ハンドオーバ時のTCPスループットを維持します。
In an early version of "Datagram Congestion Control Protocol (DCCP)" [RFC4340], a "Reset Congestion State" option was proposed in Section 11. This option was removed in part because the use conditions were not fully understood:
「データグラム輻輳制御プロトコル（DCCP）」[RFC4340]の初期バージョンでは、「輻輳状態をリセット」オプションは、使用条件を十分に理解されていなかったため、このオプションは部分的に除去されたセクション11に提案されました。
An HC-Receiver sends the Reset Congestion State option to its sender to force the sender to reset its congestion state -- that is, to "slow start", as if the connection were beginning again. ... The Reset Congestion State option is reserved for the very few cases when an endpoint knows that the congestion properties of a path have changed. Currently, this reduces to mobility: a DCCP endpoint on a mobile host MUST send Reset Congestion State to its peer after the mobile host changes address or path.
HC-レシーバは、その輻輳状態をリセットするために、送信者を強制的にその送信者にリセット輻輳状態オプションを送ります - 接続が再び始めていたかのように、「スロースタート」に、です。エンドポイントは、パスの混雑プロパティが変更されていることを知っているとき...リセット輻輳状態のオプションは非常に少数の例のために予約されています。現在、これはモビリティに削減：モバイルホスト上のDCCP終点はモバイルホストの変更アドレスまたはパスした後、そのピアにリセット輻輳状態を送らなければなりません。
"Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses optimizations to recover earlier from a retransmission timeout incurred during a period in which an interface or intervening link was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup] describes methods by which a TCP implementation that has backed off its retransmission timer due to frame loss on a remote link can learn that the link has once again become operational. This enables retransmission to be attempted prior to expiration of the backed-off retransmission timer.
「フレームワークとTRIGTRANための要件は、」[TRIGTRAN]インターフェイスまたは介在リンクがダウンしている期間中に発生した再送タイムアウトから早く回復するために最適化について論じています。 「エンド・ツー・エンドの、暗黙の 『リンクアップ』の通知は、」[E2ELinkup]によるリモートリンク上のフレーム損失にその再送タイマーをオフに裏打ちされたTCP実装はリンクが再び操作可能になったことを学ぶことができる方法を説明し。これは、従来バックオフ再送タイマの満了に試みたことが再送信を可能にします。
"Link-layer Triggers Protocol" [Yegin] describes transport issues arising from lack of host awareness of link conditions on downstream Access Points and routers. Transport of link layer triggers is proposed to address the issue.
「リンク層のトリガプロトコル」[Yegin]は、下流アクセスポイントとルータのリンク状態のホスト意識の欠如に起因する輸送の問題について説明します。リンク層トリガの輸送は問題に対処することが提案されています。
"TCP Extensions for Immediate Retransmissions" [Eggert] describes how a transport layer implementation may utilize existing "end-to-end connectivity restored" indications. It is proposed that in addition to regularly scheduled retransmissions that retransmission be attempted by the transport layer on receipt of an indication that connectivity to a peer node may have been restored. End-to-end connectivity restoration indications include "Link Up", confirmation of first-hop router reachability, confirmation of Internet layer configuration, and receipt of other traffic from the peer.
「即時再送信のためのTCP拡張」[エッゲルト]トランスポート層の実装は、既存の表示を「エンド・ツー・エンドの接続が復元」利用することができる方法を説明します。それに加えて定期的にピア・ノードへの接続が復元されていてもよいという指示を受信すると、トランスポート層によって試行さ再送再送をスケジュールすることが提案されます。エンドツーエンドの接続の回復兆候は、「リンクアップ」、ファーストホップルータの到達可能性、インターネット層構成の確認、およびピアから他のトラフィックの受信の確認が含まれます。
In "Discriminating Congestion Losses from Wireless Losses Using Interarrival Times at the Receiver" [Biaz], the authors propose a scheme for differentiating congestive losses from wireless transmission losses based on inter-arrival times. Where the loss is due to wireless transmission rather than congestion, congestive backoff and cwnd adjustment is omitted. However, the scheme appears to assume equal spacing between packets, which is not realistic in an environment exhibiting link layer frame loss. The scheme is shown to function well only when the wireless link is the bottleneck, which is often the case with cellular networks, but not with IEEE 802.11 deployment scenarios such as home or hotspot use.
「レシーバーの間時間を使用してワイヤレスの損失と区別混雑損失」[Biaz]では、著者は、到着時間に基づいて無線伝送損失からうっ血性の損失を区別するための手法を提案します。損失は、無線伝送ではなく、混雑によるものである場合、うっ血性バックオフおよびCWND調整が省略されています。しかし、この方式は、リンク層フレームの損失を示す環境では現実的ではないパケット間の等しい間隔を想定するように見えます。スキームは、無線リンクは、自宅やホットスポットなどの使用IEEE 802.11展開シナリオではないことが多い携帯電話ネットワークの場合ですが、ボトルネック、あるときだけうまく機能することが示されています。
In "Improving Performance of TCP over Wireless Networks" [Bakshi], the authors focus on the performance of TCP over wireless networks with burst losses. The authors simulate performance of TCP Tahoe within ns-2, utilizing a two-state Markov model, representing "good" and "bad" states. Where the receiver is connected over a wireless link, the authors simulate the effect of an Explicit Bad State Notification (EBSN) sent by an Access Point unable to reach the receiver. In response to an EBSN, it is advocated that the existing retransmission timer be canceled and replaced by a new dynamically estimated timeout, rather than being backed off. In the simulations, EBSN prevents unnecessary timeouts, decreasing RTT variance and improving throughput.
[バクシ]を「無線ネットワーク上でTCPのパフォーマンスの向上」では、著者はバースト損失で無線ネットワーク上のTCPのパフォーマンスに焦点を当てます。著者は、「良い」と「悪い」状態を表す、2状態マルコフモデルを利用し、NS-2の中にTCPタホのパフォーマンスをシミュレートします。受信機は、無線リンクを介して接続されている場合、著者は、受信機に到達することができない、アクセスポイントによって送信された明示的な悪い状態通知（EBSN）の効果をシミュレートします。 EBSNに応じて、既存の再送タイマは、むしろ後退しているよりも、新しい動的推定タイムアウトによりキャンセルと交換することを提唱しています。シミュレーションでは、EBSNは不要タイムアウト、RTTの変動を減少させ、スループットを向上させることを防止します。
In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc Wireless Networks" [Chandran], the authors proposed an explicit Route Failure Notification (RFN), allowing the sender to stop its retransmission timers when the receiver becomes unreachable. On route reestablishment, a Route Reestablishment Notification (RRN) is sent, unfreezing the timer. Simulations indicate that the scheme significantly improves throughput and reduces unnecessary retransmissions.
「アドホック無線ネットワークにおけるTCPのパフォーマンスを向上させるためのフィードバックに基づく方式」[チャンドラン]では、著者は、受信機が到達不能になった場合、送信者はその再送タイマーを停止することができ、明示的経路障害通知（RFN）を提案しました。ルート再構築には、ルート再確立通知（RRN）は、タイマーを解凍、送信されます。シミュレーションは、スキームが大幅にスループットを向上させ、不要な再送を減らすことを示しています。
In "Analysis of TCP Performance over Mobile Ad Hoc Networks" [Holland], the authors explore how explicit link failure notification (ELFN) can improve the performance of TCP in mobile ad hoc networks. ELFN informs the TCP sender about link and route failures so that it need not treat the ensuing packet loss as due to congestion. Using an ns-2 simulation of TCP Reno over 802.11 with routing provided by the Dynamic Source Routing (DSR) protocol, it is demonstrated that TCP performance falls considerably short of expected throughput based on the percentage of the time that the network is partitioned. A portion of the problem was attributed to the inability of the routing protocol to quickly recognize and purge stale routes, leading to excessive link failures; performance improved dramatically when route caching was turned off. Interactions between the route request and transport retransmission timers were also noted. Where the route request timer is too large, new routes cannot be supplied in time to prevent the transport timer from expiring, and where the route request timer is too small, network congestion may result.
「アドホックネットワーク上のTCPパフォーマンスの分析」[オランダ]では、著者は、リンク障害通知（ELFN）は、モバイルアドホックネットワークにおけるTCPのパフォーマンスを向上させることができますどのように明示的に探ります。それは輻輳が原因として、その後のパケット損失を扱う必要がないようにELFNは、リンクやルートの障害についてのTCPの送信者に通知します。ダイナミックソースルーティング（DSR）プロトコルによって提供されるルーティングと802.11でTCPリノのNS-2シミュレーションを用いて、TCP性能はネットワークが区画されている時間の割合に基づいて予期されるスループットの大幅に下回ることが実証されています。問題の一部は、過剰なリンク障害につながる、迅速古いルートを認識してパージするルーティングプロトコルのできないことに起因していました。ルートキャッシュがオフになったときのパフォーマンスが飛躍的に向上しました。ルート要求及び輸送再送タイマーの間の相互作用も認められました。ルート要求タイマが大きすぎる場合、新しいルートが期限切れからトランスポート・タイマを防止するための時間で供給することができず、経路要求タイマが小さすぎる場合、ネットワーク輻輳が生じ得ます。
For their implementation of ELFN, the authors piggybacked additional information (sender and receiver addresses and ports, the TCP sequence number) on an existing "route failure" notice to enable the sender to identify the affected connection. Where a TCP receives an ELFN, it disables the retransmission timer and enters "stand-by" mode, where packets are sent at periodic intervals to determine if the route has been reestablished. If an acknowledgment is received, then the retransmission timers are restored. Simulations show that performance is sensitive to the probe interval, with intervals of 30 seconds or greater giving worse performance than TCP Reno. The effect of resetting the congestion window and RTO values was also investigated. In the study, resetting the congestion window to one did not have much of an effect on throughput, since the bandwidth/delay of the network was only a few packets. However, resetting the RTO to a high initial value (6 seconds) did have a substantial detrimental effect, particularly at high speed. In terms of the probe packet sent, the simulations showed little difference between sending the first packet in the congestion window, or retransmitting the packet with the lowest sequence number among those signaled as lost via the ELFNs.
ELFNのそれらの実装のために、著者らは、影響を受けた接続を識別するために、送信者を有効にするために既存の「ルート失敗」通知に付加情報（送信者と受信者のアドレスとポート、TCPシーケンス番号）をピギーバック。 TCPはELFNを受信する場合、それは再送タイマを無効にし、「スタンドバイ」パケットを定期的に送信されますモード、ルートが再確立されているかどうかを判断するために入ります。肯定応答が受信された場合、再送信タイマーが復元されています。シミュレーションは、パフォーマンスがTCPリノよりも悪いパフォーマンスを与えて、30秒以上の間隔で、プローブ間隔に敏感であることを示しています。輻輳ウィンドウとRTO値をリセットする効果も調べました。ネットワークの帯域幅/遅延はわずか数のパケットだったので研究では、1に輻輳ウィンドウをリセットすると、スループットへの影響の多くを持っていませんでした。しかし、高い初期値（6秒）にRTOをリセットすると、特に高速で、実質的に有害な影響を持っていました。送信されたプローブパケットの観点から、シミュレーションは、輻輳ウィンドウ内の最初のパケットを送信する、またはELFNsを介して失われたとしてシグナリングのうち最も低いシーケンス番号を持つパケットを再送ほとんど差が認められました。
In "Improving TCP Performance over Wireless Links" [Goel], the authors propose use of an ICMP-DEFER message, sent by a wireless Access Point on failure of a transmission attempt. After exhaustion of retransmission attempts, an ICMP-RETRANSMIT message is sent. On receipt of an ICMP-DEFER message, the expiry of the retransmission timer is postponed by the current RTO estimate. On receipt of an ICMP-RETRANSMIT message, the segment is retransmitted. On retransmission, the congestion window is not reduced; when coming out of fast recovery, the congestion window is reset to its value prior to fast retransmission and fast recovery. Using a two-state Markov model, simulated using ns-2, the authors show that the scheme improves throughput.
[Goelさん]「ワイヤレスリンク上でTCPのパフォーマンスの向上」では、著者は送信試行の失敗に無線アクセスポイントによって送信されたICMP-DEFERメッセージの使用を提案しています。再送試行の枯渇後、ICMP-再送信メッセージが送信されます。 ICMP-DEFERメッセージの受信時に、再送タイマーの満了は、現在のRTO推定値によって延期されます。 ICMP-再送メッセージの受信時に、セグメントが再送信されます。再送信では、輻輳ウィンドウが低下することはありません。高速リカバリから出てきたときに、輻輳ウィンドウの前に高速再送信および高速リカバリにその値にリセットされます。 NS-2を使用してシミュレート、2状態マルコフモデルを用いて、著者は、スキームは、スループットを改善することを示しています。
In "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks" [Krishnan], the authors examine the use of explicit transport error notification (ETEN) to aid TCP in distinguishing congestive losses from those due to corruption. Both per-packet and cumulative ETEN mechanisms were simulated in ns-2, using both TCP Reno and TCP SACK over a wide range of bit error rates and traffic conditions. While per-packet ETEN mechanisms provided substantial gains in TCP goodput without congestion, where congestion was also present, the gains were not significant. Cumulative ETEN mechanisms did not perform as well in the study. The authors point out that ETEN faces significant deployment barriers since it can create new security vulnerabilities and requires implementations to obtain reliable information from the headers of corrupt packets.
「エラーが発生しやすい無線および衛星ネットワークのための明示的な輸送エラー通知（ETEN）」[クリシュナン]では、著者は腐敗によるものとは区別うっ血性損失にTCPを支援するための明示的な輸送エラー通知（ETEN）の使用を検討します。パケット当たりの累積ETENメカニズム両方のビット誤り率と交通状況の広い範囲にわたってTCPリノとTCP SACKの両方を使用して、NS-2でシミュレートしました。パケットごとのETENメカニズムは混雑も存在していた渋滞なしTCPのグッドプットにかなりの利益を提供したが、利益は有意ではなかったです。累積ETENメカニズムは研究中にも実行されませんでした。著者はETENは、それが新たなセキュリティ上の脆弱性を作成することができますので、重要な展開の障壁に直面し、破損したパケットのヘッダから信頼できる情報を得るための実装が必要であることを指摘しています。
In "Towards More Expressive Transport-Layer Interfaces" [Eggert2], the authors propose extensions to existing network/transport and transport/application interfaces to improve the performance of the transport layer in the face of changes in path characteristics varying more quickly than the round-trip time.
【Eggert2「より表現トランスポート・レイヤ・インターフェイスに向けて」において、著者らはラウンドよりも早く変化路特性の変化に直面して輸送層の性能を向上させるために、既存のネットワーク/トランスポートおよびトランスポート/アプリケーション・インタフェースへの拡張を提案します-旅行の時間。
In "Protocol Enhancements for Intermittently Connected Hosts" [Schuetz], the authors note that intermittent connectivity can lead to poor performance and connectivity failures. To address these problems, the authors combine the use of the Host Identity Protocol (HIP) [RFC4423] with a TCP User Timeout Option and TCP Retransmission trigger, demonstrating significant improvement.
「断続的に接続されたホストのプロトコルの拡張」[Schuetz]では、著者は、断続的な接続は、パフォーマンスの低下や接続の障害につながることに注意してください。これらの問題に対処するために、著者は有意な改善を実証し、TCPユーザのタイムアウト・オプションとTCP再送トリガとホスト識別プロトコル（HIP）の使用[RFC4423]を組み合わせています。
A.4. Application Layer
A.4。アプリケーション層
In "Application-oriented Link Adaptation for IEEE 802.11" [Haratcherev2], rate information generated by a link layer utilizing improved rate adaptation algorithms is provided to a video application, and used for codec adaptation. Coupling the link and application layers results in major improvements in the Peak Signal to Noise Ratio (PSNR). Since this approach assumes that the link represents the path bottleneck bandwidth, it is not universally applicable to use over the Internet.
「IEEE 802.11のアプリケーション指向のリンクアダプテーション」で[Haratcherev2]、改良されたレート適応アルゴリズムを利用して、リンク層によって生成されたレート情報は、ビデオ・アプリケーションに提供され、コーデックの適応のために使用しました。リンク層とアプリケーション層を結合することはピーク信号対雑音比（PSNR）の大幅な改善につながります。このアプローチは、リンクはパスのボトルネック帯域を表していることを前提としていますので、インターネット上で使用するために普遍的に適用可能ではありません。
At the application layer, the usage of "Link Down" indications has been proposed to augment presence systems. In such systems, client devices periodically refresh their presence state using application layer protocols such as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) [RFC3428] or Extensible Messaging and Presence Protocol (XMPP) [RFC3921]. If the client should become disconnected, their unavailability will not be detected until the presence status times out, which can take many minutes. However, if a link goes down, and a disconnect indication can be sent to the presence server (presumably by the Access Point, which remains connected), the status of the user's communication application can be updated nearly instantaneously.
アプリケーション層では、「リンクダウン」表示の使用方法は、プレゼンスシステムを強化することが提案されています。このようなシステムでは、クライアント・デバイスは、定期的に、このようなインスタントメッセージングのためのSIPとプレゼンス活用エクステンション（SIMPLE）[RFC3428]または拡張メッセージングおよびプレゼンスプロトコル（XMPP）[RFC3921]などのアプリケーション層プロトコルを使用してプレゼンス状態を更新します。クライアントが切断される必要がある場合は、その利用できないことは、多くの分を取ることができて、プレゼンスステータス倍まで検出されません。リンクがダウンし、切断指示が（おそらく接続されたままアクセスポイントによって）プレゼンスサーバに送信することができますしかし、もし、ユーザの通信アプリケーションの状態は、ほぼ瞬時に更新することができます。
Appendix B. IAB Members at the Time of This Writing
この記事の執筆時点では、付録B. IABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナードAbobaロア・アンダーソン、ブライアン・カーペンターレスリーDaigle氏エルウィン・デイビスケビン秋オラフKolkmanカーティスLindqvistデビッド・マイヤーデヴィッドオランエリックレスコラデーブターラーLixiaチャン
Author's Address
著者のアドレス
Bernard Aboba, Ed. Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAboba、エド。マイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
IAB
栄光
EMail: iab@iab.org URI: http://www.iab.org/
電子メール：iab@iab.org URI：http://www.iab.org/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。