RFC4907 日本語訳
4907 Architectural Implications of Link Indications. B. Aboba, Ed.. June 2007. (Format: TXT=160604 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba, Ed.
Request for Comments: 4907 Internet Architecture Board
Category: Informational IAB
June 2007
ワーキンググループB.Aboba、エドをネットワークでつないでください。コメントのために以下を要求してください。 4907年のインターネット・アーキテクチャ委員会カテゴリ: 情報のIAB2007年6月
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).
IETFが信じる著作権(C)(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.
リンク指示はリンクレイヤでリンクの状態に関して、より高い層に提供された情報を表します。 このドキュメントはインターネットアーキテクチャの中でリンク指摘の役割について説明します。 リンク指摘の賢明な使用が性能利益を提供できる間、誤用は丈夫さと性能の両方を下げることができます。 このドキュメントは、現在の提案をまとめて、構造的な問題について説明して、リンク指摘の適切で不適当な用途に関する例を提供します。
IAB Informational [Page 1] RFC 4907 Link Indications June 2007
IABの情報[1ページ]のRFC4907は指摘2007年6月にリンクします。
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
1. 序論…3 1.1. 要件…3 1.2. 用語…3 1.3. 概要…5 1.4. 指示モデルを層にします…7 2. 建築問題…14 2.1. 合法化をモデル化してください…15 2.2. 定義をクリアしてください…16 2.3. 丈夫さ…17 2.4. 混雑コントロール…20 2.5. 有効性…21 2.6. 相互運用性…22 2.7. 競合条件…22 2.8. 圧縮を層にしてください…25 2.9. リンク指摘の輸送…26 3. 今後の仕事…27 4. セキュリティ問題…28 4.1. だまします…28 4.2. 指示合法化…29 4.3. サービス妨害…30 5. 参照…31 5.1. 標準の参照…31 5.2. 有益な参照…31 6. 承認…40 付録A.文献レビュー…41 A.1。 層をリンクしてください…41 A.2。 インターネット層…53 A.3。 層を輸送してください…55 A.4。 アプリケーション層…60 付録B.IABメンバー…60
IAB Informational [Page 2] RFC 4907 Link Indications June 2007
IABの情報[2ページ]のRFC4907は指摘2007年6月にリンクします。
1. Introduction
1. 序論
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は推薦と今後の活動について説明します。 ワイヤレスのローカル・エリア・ネットワーク(WLANs)に主に焦点を合わせて、付録Aはリンク指摘のときに文学をまとめます。
1.1. Requirements
1.1. 要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
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.
関連ステーションへのワイヤレスの媒体(WM)で固定ネットワーク(例えば、802.11Distribution System)へのアクセスを提供するPoint(AP)Aステーションにアクセスしてください。
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.
相対的な位置によって、異なったトランスミッションの特性か送信機のデザインの特性と受信機との非対称のAリンクは非対称であると言われています。 例えば、1個の送信機の範囲は同じ媒体の上の別の送信機の範囲よりはるかに高いかもしれません。
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.
標識Aコントロールメッセージはステーション(通常Access Point)のそばで放送されました、継続する存在について近所のステーションに知らせて、ことによると追加状態か設定情報と共に。
IAB Informational [Page 3] RFC 4907 Link Indications June 2007
IABの情報[3ページ]のRFC4907は指摘2007年6月にリンクします。
Binding Update (BU)
A message indicating a mobile node's current mobility binding,
and in particular its Care-of Address.
Update(BU)Aを縛って、事項を縛って事項におけるモバイルノードの現在の移動性を示しながら通信してください、それ、Care、-、Address。
Correspondent Node
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
モバイルノードが交信している通信員Node A同輩ノード。 通信員ノードは、モバイルである、または静止しているかもしれません。
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).
A通信機器かノードがリンクレイヤで交信できる媒体をリンクしてください、すなわち、インターネットプロトコル(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.
もうデータフレームをコミュニケートできないインタフェースに関連している州の変化を意味するリンクレイヤで提供されたDown Anイベントをリンクしてください。 高いフレームの損失の一時的な一区切りは十分ではありません。
Link Indication
Information provided by the link layer to higher layers
regarding the state of the link.
リンクレイヤでリンクの状態に関して、より高い層に提供されたIndication情報をリンクしてください。
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).
リンクのコントロールを維持するのに原因となるコントロールか処理論理のLayer Conceptual層をリンクしてください。 リンクレイヤ機能は、より高い層の論理とリンクとのインタフェースを提供します。 リンクレイヤはインターネットプロトコル(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.
データフレームをコミュニケートできるようになるインタフェースに関連している州の変化を意味するリンクレイヤで提供されたUp Anイベントをリンクしてください。
Maximum Segment Size (MSS)
The maximum payload size available to the transport layer.
輸送に有効な最大積載量サイズの最大のSegment Size(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.
最大のTransmission Unit、(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.
ホームアドレスでまだ届いている間に別のものへの1個のリンクから接着点を変えることができるモバイルNode Aノード。
IAB Informational [Page 4] RFC 4907 Link Indications June 2007
IABの情報[4ページ]のRFC4907は指摘2007年6月にリンクします。
Operable Address
A static or dynamically assigned address that has not been
relinquished and has not expired.
操作できるAddress A静電気かそれが持っているダイナミックに割り当てられたアドレスが、放棄されないで、また期限が切れていません。
Point of Attachment
The endpoint on the link to which the host is currently
connected.
Attachmentを指してください。ホストが現在接続されるリンクの上の終点。
Routable Address
Any IP address for which routers will forward packets. This
includes private addresses as specified in "Address Allocation
for Private Internets" [RFC1918].
ルータがパケットを進めるRoutable Address Any 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).
IEEE802.11conformant媒体アクセス制御(MAC)を含むどんなデバイスと物理的な層(PHY)もワイヤレスの媒体(WM)に連結する駅(STA)。
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.
Strong End Systemがモデル化する強いEnd System Modelはホスト/ルータ区別を強調します、aをモデル化する傾向があるのでマルチ、家へ帰り、1セットの論理的なホストとして、同じ物理ホストの中で接待します。 Strong End Systemモデルでは、アドレスはそれらが付くホストにというよりむしろインタフェースを述べます。 その結果、そのインタフェースで外向的なインタフェースで送られたパケットでソースアドレスを構成します、そして、送付先アドレスがそれが受け取られている物理インターフェースに一致していない入って来るパケットは静かに捨てられます。
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.
弱いEnd System Model In Weak End Systemはモデル化して、アドレスはホストについて言及します。 その結果、パケットは、必ずそのインタフェースで外向的なインタフェースでソースアドレスを構成しなければならないというわけではないのを転送しました、そして、送付先アドレスがそれが受け取られている物理インターフェースに一致していない入って来るパケットを受け入れます。
1.3. Overview
1.3. 概要
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].
インターネットアーキテクチャの中のリンク指摘の使用は伝統があります。 オフラインであるホストに発信する試みに対応して、アルパネットリンクレイヤプロトコルは「欠点分離と回復」[RFC816]で説明された「目的地死者」指示を提供しました。 アルパネットパケットラジオ実験[PRNET]は測定基準(Expected Transmission Countなどの、より最近のリンク意識しているルーティング測定基準(ETX)への先駆)が「マルチホップワイヤレスルート設定における、メートル法の高生産性経路」[ETX]で説明したルーティングの計算におけるフレームの損失を取り入れました。
IAB Informational [Page 5] RFC 4907 Link Indications June 2007
IABの情報[5ページ]のRFC4907は指摘2007年6月にリンクします。
"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]:
「ルーティング情報プロトコル」[RFC1058]はRIPを定義しました。(ゼロックスNetwork Systems(XNS)ルーティング情報プロトコルはRIPに離されます)。 「OSPF Specification」[RFC1131]はオープンShortest Path Firstを定義しました。(Shortest Path Firstは、OSPF領域の中でリンク状態に関連する情報をあふれさせるのに、Link州Advertisements(LSAs)を使用します)。 [RFC2328]はOSPFのバージョン2を定義します。 また、それらをサポートするそれらのリンクによって提供された指摘がプロトコルが利用できるこれらと他のルーティングに「リンクし」て、「リンクされる」間、彼らはルーティングパケットの損失に基づくリンクの損失を検出できます。 「IPバージョン4ルータのための要件」[RFC1812]に述べられるように:
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.
また、「リンク」と「リンク下である」を除いたリンク指摘を定義するのを試みをしました。 「ダイナミックに、」 Switched Link Controlプロトコル[RFC1307]はリンクのコントロールのために実験プロトコルを定義します、“Down"を組み込んで、「上に来ます」、と“Up"、「低下」であることが「降ろし」て、「持って来ること」は述べます。
"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".
「Link Layer TriggersのためのGeneralized Model」[GenTrig]は「ジェネリック引き金」を定義します、「リンク」、「リンク下である」、「落ちるリンク」、「上がるリンク」、「リンク品質は敷居に交差している」、「引き金のロールバック」、および「利用可能なより良い信号品質AP」を含んでいて。 IEEE802.21[IEEE-802.21]はリンクの特性、リンク状態、およびリンク品質に関連すると報告するイベントを提供するメディア無党派Handover Event Service(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.
理想的な状態の下では、“up"状態のリンクは、データフレームを両方の方向の低いフレームの損失を経験して、送って、すぐに、受け取る準備ができています。 送受信データフレームに、“down"状態のリンクはどちらかの方向に不適当です。
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.
残念ながら、リンクは頻繁に非理想的な振舞いを示します。 Wiredリンクは、半二重モードに失敗するか、または中間的損失率をもたらす部分的な損傷を示すかもしれません。 ワイヤレスのリンクは干渉か信号の色あせのため非対称、間欠フレームの損失、またはスループットにおける急激な変化を示すかもしれません。 ワイヤードなものと同様にワイヤレスのリンクでは、リンク状態は“up"と“down"州の間で急速にばたつくかもしれません。 振舞いが提示するこの本当の世界はインターネット、輸送、および応用層でリンク指摘の統合に挑戦します。
IAB Informational [Page 6] RFC 4907 Link Indications June 2007
IABの情報[6ページ]のRFC4907は指摘2007年6月にリンクします。
1.4. Layered Indication Model
1.4. 層にされた指示モデル
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にそれがリンク指摘(リンク状態やレートなどの)と経路変化検出などの外部の相互作用から起こる指摘であると内部的に生成された両方を含んでいるのが示されます。 このモデルでは、リンクレイヤが主としてリンク技術不可知論者である抽象的な指摘の形の、より高い層に指摘を供給すると思われます。
IAB Informational [Page 7] RFC 4907 Link Indications June 2007
IABの情報[7ページ]のRFC4907は指摘2007年6月にリンクします。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++++++++++アプリケーション| | 層| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+ | ! ! ! | | ! ^ ^ | | 接続管理!分解| 輸送| ! ! | 層+++++++++++++++、-、-、++、-、-、++++++| ! ! | | ! ! | | ^ ! | | 輸送パラメータ推定!| |(MSS、RTT、RTO、cwnd、bw、ssthresh!) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ ^ ^ ^ ^ ^ ! ! ! ! ! ! ! +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ | ! ! 入来!MIP!| | ! ! インタフェース!BU!| | ! ! 変化!領収書! ! ! | | ! ^ ^ ^ ! ^ | インターネット| ! ! 移動性!| 層の+!、-、+、-、-、+++++、-、-、+++、-、-、+、-、-、++、-、-、++++++| ! ! 外向的である、経路!| | ! ! インタフェース!変化してください! ! ! | | ^ ^^ ^!^を変えてください。| | ! ! ! ! | | ! ルート設定!| +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ | ! ! v!IP| | ! ! 経路!アドレス| | ! IP構成^インフォメーション^コンフィグ/| | ! ! キャッシュ変化| +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ | ! ! | リンク| ^ ^ | 層| レート、FERはリンクします。| | /への遅れはダウンします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model
図1。 層にされた指示モデル
IAB Informational [Page 8] RFC 4907 Link Indications June 2007
IABの情報[8ページ]のRFC4907は指摘2007年6月にリンクします。
1.4.1. Internet Layer
1.4.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.
インターネット層の関数の1つはリンクの振舞いの詳細から、より高い層を保護することです。 その結果、インターネット層は、リンク指摘を有効にして、フィルターにかけて、ルーティング測定基準に基づく送受信のインタフェースを選択します。
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.
インターネット層はルータによって提供された情報を考慮に入れることによって局所界面から利用可能な情報に潜在的に基づく経路指定テーブルを構成します。 これは、地方の経路指定テーブルの州が地方のものと同様にリモートなリンクにリンク状態を反映するのを可能にします。 例えば、経路指定テーブルから加えられるべきであるか、または取り除かれるべき接頭語は倍数が遠くを飛び越すリンクの状態の情報を取り入れるDynamic Host Configuration Protocol(DHCP)[RFC2131][RFC3315]、Router Advertisements[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.
「Packetization層の経路MTU発見」[RFC4821]で説明されるように、インターネット層は経路情報キャッシュを維持するかもしれません、同時発生の、または、その後の接続の間のPath MTU情報の共有を可能にして。 packetization層のPath MTUがディスカバリーであると実装するpacketizationプロトコルは、共有されたキャッシュにアクセスして、アップデートします。
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)構成と移動性の局面を最適化するのにリンク指摘を利用します。 「結び付いてください」という指示の領収書の後に、Detecting Network Attachment(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構成は、可到達性検出とRouter Solicitation/広告を使用することで有効にされます。
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
ルーティング副層は、リンク状態の変化への、より急速な応答と有効なスループットを可能にするのにリンク指摘を利用するかもしれません。 リンクレートはルーティング測定基準を計算する際にしばしば使用されます。 しかしながら、有線ネットワークでは、通信速度は、エネルギー効率[EfficientEthernet]を高めるために交渉されるかもしれません。 ワイヤレス・ネットワークでは、交渉されたレートとFrame Error Rate(FER)は変化するかもしれません。
IAB Informational [Page 9] RFC 4907 Link Indications June 2007
IABの情報[9ページ]のRFC4907は指摘2007年6月にリンクします。
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.
したがって、リンク状態がそんなに効果的である場合、スループットはパケットごとのベースで異なるかもしれません。 また、そのような状況で、ルーティング測定基準は急速な変化を示すかもしれません。
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.
Link Up/下であるのや有効なスループットなどのリンクしるしを取り入れるルート設定測定基準は、ルータがルート選択の目的のためにリンク状態を考慮に入れるのを可能にします。 リンクであるなら、経験は、それが役立つ接頭語のために増加して、利用可能であるなら代替パスの使用を奨励しながら、メートル法でレートか高いフレームの損失、ルートを減少させました。 リンク状態が向上するとき、リンクの使用を奨励して、メートル法の意志が減少させるルートです。
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.
Weak End System実装の中では、ルーティング測定基準とリンク状態の変化は1人以上の輸送の接続のための外向的なインタフェースの変化をもたらすかもしれません。 また、同輩の接続性の損失か獲得をもたらして、ルートは、加えられるか、または引っ込められるかもしれません。 しかしながら、通信速度における変化かフレームの損失などのリンクしるしは必ず外向的なインタフェースの変化をもたらすというわけではありません。
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]).
また、インターネット層は他のメカニズムで経路変化を意識するようになるかもしれません、ルーティング・プロトコルからのアップデートの領収書、Router Advertisementの領収書、検出[RFC816]かネットワーク「非-可到達性」検出[RFC2461]、ICMPが向け直す停止ゲートウェイ、または容認されたパケットのIPv4 TTL(Liveへの時間)/IPv6 Hop Limitにおける変化などのように。 入って来るインタフェースの変化を引き起こす場合、外向的なインタフェースの変化は順番に移動性副層に影響を及ぼすかもしれません。 また、移動性副層は同輩(モバイルIP Binding Update[RFC3775]の領収書を通した)の入って来るインタフェースの変化を意識するようになるかもしれません。
1.4.2. Transport Layer
1.4.2. トランスポート層
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.
パラメータ推定の目的のために、トランスポート層は性能に影響を与えてください。そうすれば、リンク指摘が経路の特性に関連していることを決定しているかもしれないところでそれらが直接利用されてもよいことに経路の特性に主として興味を持っています。 「リンク」/「リンクDown」やレート、遅れ、およびフレームの損失における変化などのリンクしるしは関連していると判明するかもしれません。 しかしながら、これはいつもそうになるというわけではないでしょう。 終わりから端への経路におけるボトルネックの帯域幅が通信速度よりはるかに既に低いところでは、通信速度の増加は物質的に経路の特性に影響しないかもしれません。 Appendix A.3で説明されるように、輸送パラメータ推計を改良するのにリンクレイヤ指摘を利用するためのアルゴリズムはまだ開発中です。
IAB Informational [Page 10] RFC 4907 Link Indications June 2007
IABの情報[10ページ]のRFC4907は指摘2007年6月にリンクします。
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.
Pointからポイントへのプロトコル(PPP)の領収書などの明白な交換からの「リンク下である」指示結果が(LCP)が終えるControlプロトコル、IEEE802.11DisassociateまたはDeauthenticateフレームをリンクさえするところで、付属の代替のポイントは利用可能であるかもしれません、接続性がすぐに回復するのを許容して。 その結果、接続が終点アドレスまで変化を上がり続けるのを許容することによって、丈夫さを最もよく達成するか、または無反応のため繰り返された「再-トランスミッション」試みまで接続を取りこわします。
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アドレスについて輸送の接続を取りこわすかもしれません。 接続がモバイルに基づいて確立されたところ
IAB Informational [Page 11] RFC 4907 Link Indications June 2007
IABの情報[11ページ]のRFC4907は指摘2007年6月にリンクします。
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ホームアドレス、aが中で変化する、Care、-、Addressは接続分解をもたらす必要はありません、構成変更が、インターネット層の中の移動性の機能性によってマスクをかけられて、したがって、トランスポート層に透明です。
"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.
「インターネットHostsのための要件--」 [RFC1122](セクション2.4)が、Destination Unreachable、Source Quench、Echo Reply、Timestamp Reply、およびTime Exceeded ICMPメッセージが渡されるのを必要とするコミュニケーションLayersはトランスポート層へ上昇します。 [RFC1122]、セクション4.2 .3 .9 通信制御プロトコル(TCP)がトランスミッションを遅くすることによってインターネット・コントロール・メッセージ・プロトコル(ICMP)ソースQuenchに反応するのが必要です。
[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メッセージがDestination Unreachableコード0(ネット)、1(接待する)、および5(ソースRoute Failed)を含んでいます。(5はルーティング過渡現象から生じるかもしれません)。 超えられていた時間。 そして、パラメタ問題。 困難なエラー条件を示すICMPメッセージがDestination Unreachableコード2(プロトコルUnreachable)、3(ポートUnreachable)、および4(Fragment Was Setではなく、必要である断片化とドン)を含んでいます。 古典的なICMPベースのPath MTUディスカバリー[RFC1191]を実行するホストがDestination Unreachableコード4を使用するので、彼らは困難なエラー条件としてこれを扱いません。 ホスト、実行して、「IPバージョン6インチ[RFC1981]がICMPv6 Packet Too Bigを利用するので、経路MTUディスカバリーは通信します」。 「経路MTU発見に関するTCP問題」[RFC2923]で注意されるように、ICMPメッセージを送りもしませんし、処理もしないなら、古典的なPath MTUディスカバリーは失敗に傷つきやすいです。 このその問題を訴えるために、「Packetization層の経路MTU発見」[RFC4821]はICMPメッセージの配送によります。
"Fault Isolation and Recovery" [RFC816], Section 6, states:
「欠点IsolationとRecovery」[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.
TCPが接続を捨てるはずであるか否かに関係なく、ICMP Destination Unreachableなどのエラーメッセージが到着するとき、それは明白ではありません。 エラーメッセージは解釈するのが難しい理由がゲートウェイには不正確な情報があるかもしれない一時的な期間があります、無関係の、または、不正確なエラーメッセージが時々戻ることができるようにゲートウェイかネットワークの失敗の後に上で議論するようにことです。 例えば、ゲートウェイが新しいルートを見つけようとしている期間、パケットを送るなら、孤立しているICMP Destination Unreachableはホストに到着するかもしれません。 到着がインターネットの貴重な特徴を無視するだろうことであるという多くの内部の失敗のために、終わりの少しも分裂なしで機能を再建するくらいのメッセージに基づくTCP接続を捨てるのは指します。
IAB Informational [Page 12] RFC 4907 Link Indications June 2007
IABの情報[12ページ]のRFC4907は指摘2007年6月にリンクします。
"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.
「IPバージョン4Routersのための要件、」 [RFC1812]、.3、「研究はSource Quenchがネットワーク回線容量を消費しますが、混雑への効果がなくて(不公平)の解毒剤であると示唆するために見える」そのルータを示す州がそうするべきでないセクション4.3.3、それらを溯源してください。 一般に、トランスポート層がパケット損失か明白な混雑通知に基づく混雑への適切で(保守的な人)の応答を決定できるので、ICMP Source Quench指摘は必要ではありません、そして、混雑の期間の追加Source Quenchパケットの発信は有害であるかもしれません。
"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]は、追加セキュリティチェックなしで正しい4tupleに基づくICMPメッセージを受け入れるのがあさはかであると主張します。 例えば、ICMPの確実なエラーメッセージを作り出す攻撃者は1人以上の輸送の接続を中止にならせることができます。 作者は多くの注意について議論します、確実なエラーメッセージへの応答をICMPメッセージを有効にするためにメカニズムを含んで、無視するか、または様々な条件のもとで遅らせて。 また、彼らは、ホストがICMP Source Quenchメッセージを無視することを勧めます。
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.
また、トランスポート層は情報をリンクレイヤに供給するかもしれません。 例えば、トランスポート層はリンクレイヤフレームが再送されるかもしれないという回の最大数を制御したがっているかもしれません、リンクレイヤが、トランスポート層タイムアウトの後に再送し続けないように。 IEEE802.11では、Management Information基地(MIB)[IEEE-802.11]の変数のdot11ShortRetryLimit(デフォルト: 7)とdot11LongRetryLimit(デフォルト: 4)を調整することによって、それぞれこれを達成できます。(dot11LongRetryLimitはdot11RTSThresholdより長さのさらに不足し長いフレームのための再試行の最大数を制御します)。 しかしながら、これらの変数が全体でリンクの振舞いを制御するので、別々に1輸送あたり1個の接続ベースで振舞いを調整するのにそれらを使用できません。 リンクレイヤ再送タイムアウトが経路の往復のタイムアウトとして同次のものである状況で、リンクレイヤコントロールは全く可能でないかもしれません。
1.4.3. Application Layer
1.4.3. 応用層
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
アプリケーションが彼らがインターネットとトランスポート層から、より確かに必要とする情報を通常得ることができるので、それらはリンク指摘を通常利用する必要はないでしょう。 「結び付いてください」という指示は、リンクがIPパケットをコミュニケートできるのを含意しますが、それが構成されたのを示しません。 アプリケーションは代わりにインターネット層「構成されたIPアドレス」出来事を使用するべきです。 「リンクDown」指摘は役に立った状態で通常そうしていません。
IAB Informational [Page 13] RFC 4907 Link Indications June 2007
IABの情報[13ページ]のRFC4907は指摘2007年6月にリンクします。
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.
「結び付いてください」という指示があとに続いていて、そうすることができて以来のアプリケーションは急速にそうです。 アプリケーションは、代わりに層の分解指摘を輸送するために反応するべきです。 同様に、経路におけるボトルネック帯域幅が変化しないなら、通信速度における変化はアプリケーションに関連していないかもしれません。 これを決定するためにトランスポート層を最もよく備えています。 その結果、図1は、リンク指摘が直接アプリケーションに提供されるのを示しません。
2. Architectural Considerations
2. 建築問題
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).
(4) 上側の層は、それらが影響された後に無効であることを決定しているリンク指摘(セクション2.3.2)から可能性のあるダメージを制限するのにタイムリーな回復ステップを利用するはずです。
(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)の間で矛盾を避けるべきです。
IAB Informational [Page 14] RFC 4907 Link Indications June 2007
IABの情報[14ページ]のRFC4907は指摘2007年6月にリンクします。
(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)を考える必要があります。
2.1. Model Validation
2.1. モデル検証
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.
「ワイヤレス・ネットワーク研究の間違われた原理」[コッツ]では、作者は、リンクの振舞いに関連する誤った仮説が実際には働かないかもしれないネットワーク・プロトコルのデザインにつながるかもしれないと結論を下します。 例えば、作者は、無線の伝播の立体的な本質が大きい信号強度変化を短距離の上もたらすことができることに注意します。 これはレートや、フレームの損失や、信号強度などのリンクしるしにおける急激な変化をもたらすことができます。
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]、作者はモデル誤りに関する例とどうリンクの特性のモデルを改良するかに関する例を提供します。 紙に伴うために、作者はナノ秒-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.
[コッツ][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展開で無効であると判明するかもしれない暗黙の仮定を入れるかもしれません。 例えば、2州のマルコフモデルは、リンクが低いフレームの損失を経験する州(“up")かわずかなフレームが首尾よく届けられる州(“down")にあると仮定します。 また、これらのモデルでは、対称は通常想定されます、リンクが両方の方向への“up"か両方の方向への“down"のどちらかであるように。 中間的損失率が経験豊富である状況で、これらの仮定は無効であるかもしれません。
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
「IEEE802.11のためのハイブリッド速度制御」[Haratcherev]で注意されるように、信号強度データは、騒がしくて、時々矛盾しています、不安定な結果を避けるためにフィルターにかけられるのが必要であるように。 これを考えて、生の信号強度データに基づくリンク指摘は頼り無いかもしれません。 問題を避けるために、信号強度データを他のテクニックに結合するのは最も良いです。 例えば、指示は[IEEE-802.21]との使用のために開発中であるのにそれが賢明である「低下」です。
IAB Informational [Page 15] RFC 4907 Link Indications June 2007
IABの情報[15ページ]のRFC4907は指摘2007年6月にリンクします。
validate filtered signal strength measurements with other indications of link loss such as lack of Beacon reception.
Beaconレセプションの不足などのリンクの損失の他のしるしを伴うフィルターにかけることの信号強度測定値を有効にしてください。
2.2. Clear Definitions
2.2. 明確な定義
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) 低いか(“up")、または高い左右対称のリンク性能かフレームの損失(“down")を仮定しないでください。
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.
有線ネットワークでは、“up"状態のリンクは、データフレームを低いフレームの損失を両方の方向に通常経験して、送って、受け取る準備ができています。 送受信データフレームに、“down"状態のリンクはどちらかの方向に不適当です。 したがって、「結び付いてください」という指示が指示とどんな方向への高いフレームの損失の両方でも通常低いフレームの損失になる場合にだけ、リンクが「リンク下である」指示を提供した後にリンクを経験できます。 しかしながら、これらの仮定は無線LANネットワークに当てはまらないかもしれません。 非対称が、より敏感なアンテナを利用している間、通常伝播が、より長い距離にわたって起こって、マルチ経路効果がそれほど厳しくないかもしれなく、基地局がはるかに高いパワーで伝わることができるセルラー・ネットワークのための問題より移動局にあります。
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) 一時的なリンク状態とリンク指摘の感度を考えてください。 マルチ経路干渉などの一般的な効果のため、信号強度とSN比(SNR)は急速に短距離の上異なるかもしれません、非濾過の測定値に基づくリンク指摘の一貫性のない行動を引き起こして。 信号強度が[Haratcherev]に述べられるように最も役に立つと判明するかもしれない、いつ
IAB Informational [Page 16] RFC 4907 Link Indications June 2007
IABの情報[16ページ]のRFC4907は指摘2007年6月にリンクします。
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終わっているaの受領)に基づくリンクレイヤ州のマシンか延長されたフレームの損失で発生します、リンクレイヤが、リンクがもう使用可能でないと結論を下すように。 その結果、これらのリンク指摘は一時的なリンク状態における変化に通常敏感ではありません。
(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) 「リンク下である」出来事を全く送るか、または送るとタイムリーな方法でそれを受け取ると仮定しないでください。 それが、リンクが当然であるのではなく、一時的なフレームの損失に使用不可能であると結論づける場合にだけ、良いリンクレイヤ実現は「リンク下である」出来事を送る間、ともに、急速に、接続性失敗(なくなったBeaconsを追跡などなどの)を検出するでしょう。
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パケットを伝えることができませんし、受け取ることができません。 スキャンの開始は、ステーションが別の接着点を見つけることができないように、遅れるかもしれません。 それが利用するセルラー・ネットワークがパワー調整を伝えるので、これは大した問題として. これがないことにおける他の問題の中のトランスポート層の中で再送信タイマーの不適当なbackoffをもたらすことができます。
2.3. Robustness
2.3. 丈夫さ
Link indication proposals must demonstrate robustness against misleading indications. Elements to consider include:
提案が紛らわしい指摘に対して丈夫さを示さなければならないという指示をリンクしてください。 考える要素は:
Implementation variation
Recovery from invalid indications
Damping and hysteresis
無効の指摘Dampingからの実現変化Recoveryとヒステリシス
2.3.1. Implementation Variation
2.3.1. 実現変化
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.
リンクレイヤ実現の変化はリンク指摘の振舞いにかなりの影響力を持っているかもしれません。 これらの変化は、提案の性能を評価する際に考慮に入れられる必要があります。 例えば、ラジオ伝播と実現差はリンク指摘の信頼性に影響を与えることができます。
IAB Informational [Page 17] RFC 4907 Link Indications June 2007
IABの情報[17ページ]のRFC4907は指摘2007年6月にリンクします。
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ノードの都市のマルチホップIEEE802.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リンクはしばしば“up"(低い損失)と“down"(高い損失)州の間で中間的な損失率を示します、かなりの非対称と同様に。 その結果、「結び付いてください」という指示の領収書は必ず双方向の可到達性を示すかもしれないというわけではありません、小さいフレームの交換の後に低率(より高いレートで交換された大きいフレームに双方向の接続性を含意しないかもしれない)で発生したかもしれないので。
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)シグナリングを使用できます。これらのテクニックは完全に効果的であるかもしれないというわけではありません、高いフレームの損失が遭遇できるように、リンクが“up"と“down"州の間を循環することを引き起こして。
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
合法化に関する別の例はIPv4 Link-ローカルアドレス構成[RFC3927]で現れます。 IPv4 Linkローカルアドレスの構成の前に、aを走らせるのがプロトコルを要求して、防御するのが必要です。 ホストが、別の主張者に対してアドレスを防御するために存在している必要があって、アドレス闘争は比較的傾向があるので、スリープモードから戻るか、または「結び付いてください」という指示を受けるホストは傾向があることができました。
IAB Informational [Page 18] RFC 4907 Link Indications June 2007
IABの情報[18ページ]のRFC4907は指摘2007年6月にリンクします。
encounter an address conflict were it to utilize a formerly configured IPv4 Link-Local address without rerunning claim and defend.
クレームを再放送しないで以前構成されたIPv4 Link-ローカルアドレスを利用して、防御するつもりであったなら、アドレス闘争に遭遇してください。
2.3.2. Recovery from Invalid Indications
2.3.2. 無効の指摘からの回復
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]のDetecting Network Attachmentでは、可到達性テストは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].
提案がトランスポート層で回復にかかわるところでは、回復している輸送パラメタ(Maximum Segment Size(MSS)、RoundTrip Time(RTT)、Retransmission TimeOut(RTO)、Bandwidth(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 Link地方の実現はIPv4 Link-ローカルアドレスを割り当てた後に発送可能アドレスを得るのを試みる前に、5分間待つでしょう。 1つの実現では、モバイルホストが5分毎より頻繁に彼らの接着点を変えたところで彼らが発送可能アドレスを決して得ないのが観測されました。 無効のリンク指示(リンクレイヤの完成の前に「結び付いてください」という認証のシグナリング)で問題は引き起こされました、DHCPを使用することで発送可能アドレスを得るために初期故障となって。 その結果、[RFC3927]は、最大の再送タイムアウトの変更に対して(64秒)が[RFC2131]に提供されたことを勧めます。
2.3.3. Damping and Hysteresis
2.3.3. 湿気とヒステリシス
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.
不安定なリンク指摘からの損害を制限するのに湿気とヒステリシスを利用できます。 これが、不安定な指摘をじめじめとするのを含むかもしれませんか、またはリンクの頻度における置く規制は期間以内の動作を指示で引き起こしました。
IAB Informational [Page 19] RFC 4907 Link Indications June 2007
IABの情報[19ページ]のRFC4907は指摘2007年6月にリンクします。
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]が、静止したステーションにおいて、フレームの損失が比較的安定しているのがわかっていた間、ラジオ伝播とマルチ経路干渉への障害は移動局への信号強度における急激な変化をもたらすことができます。 その結果、移動局がリンクの特性における急激な変化に遭遇するのは、可能です、通信速度、スループット、フレームの損失、および同等の「リンク」/「リンクDown」指摘における変化を含んでいて。
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.
リンク意識しているルーティング測定基準が実行されるところでは、これは急速なメートル法の変化をもたらすことができます、潜在的にWeak End System実現のための外向的なインタフェースの頻繁な変化をもたらして。 その結果、ルートフラップの湿りを導入するのが必要であるかもしれません。
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.
しかしながら、湿気の利益は、導入できる追加潜在に比較考量される必要があります。 例えば、「リンクはダウンする」という偽りの指摘を無視するために、「結び付いてください」という指示がその後まもなく続かないことを決定できるまで、これらの指摘は遅れるかもしれません。 しかしながら、複数のBeaconsがいなくて寂しい状況で、そのような遅れは必要でないかもしれません、適当な接着点の証拠が全くその付近にないので。
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].
いくつかの場合、リンク指摘を完全に無視するのは望ましいです。 ホストにとって、それが集結されたアドレス管理による臨時のネットワークからネットワークまでの変遷に可能であるので、「結び付いてください」という指示を受けるホストは、DHCPサーバが利用可能な[RFC3927]かそれとも手術可能な構成であるかを決定する前にIPv4 Link-ローカルアドレスを構成するのが有効であることが[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に述べられるように、トランスポート層は接続管理の目的のための「リンク」と「リンク下である」指摘を利用しません。
2.4. Congestion Control
2.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アドレス構成/変更届出書などの上側の層のしるしによるべきです。
IAB Informational [Page 20] RFC 4907 Link Indications June 2007
IABの情報[20ページ]のRFC4907は指摘2007年6月にリンクします。
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.
Keepalives。 偽りのリンク指摘に対して丈夫さを改良するために、「リンクはダウンする」という指摘を消費することの代わりにアプリケーションkeepaliveかトランスポート層指示(接続分解などの)を使用できます。
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.
応用層では、リンク指摘は、登録とユーザーインタフェースアップデート操作を最適化するのにPresence[RFC2778]などのアプリケーションで利用されました。 例えば、実装は、「リンク上」指示を受け取り次第存在登録を試みて、「リンク下である」指示を受ける代理で存在反-登録を試みるかもしれません。 このように「リンク」/「リンクDown」指摘を使用する存在実装は終わりから端への経路RTOほどタイムスケールでリンク指摘を生成することができて以来の「パケットの保護」の原則に違反しません。 問題は、多くのウォッチャーにそれぞれの存在アップデートにおいて通知を提供できるので、拡大されます。 さらに、インタフェースには手術可能なインターネット層の構成がまだしさえしないかもしれないので、「結び付いてください」という指示の使用はこの様に賢明ではありません。 代わりに、「構成されたIPアドレス」指示は利用されるかもしれません。
2.5. Effectiveness
2.5. 有効性
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.
提案は提案された最適化の有効性を示さなければなりません。 最適化が複雑さを通常増強するので、かなりの性能改良が何とかしなければならない事例を作るのに必要です。
IAB Informational [Page 21] RFC 4907 Link Indications June 2007
IABの情報[21ページ]のRFC4907は指摘2007年6月にリンクします。
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で、等しいか使用より良い性能だけをもたらすのを保証します。
2.6. Interoperability
2.6. 相互運用性
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].
リンク指摘がインターネット層の構成を最適化するために提案されるところでは、提案は、アドレス課題かルーティング・プロトコルの振舞いを妨げることによって丈夫さに感染しないのを示さなければなりません、おそらく、アドレス衝突をするか、またはDuplicate Address Detection(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人以上の関係者が提案を実装しないでも。
2.7. Race Conditions
2.7. 競合条件
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
Weak End Systemモデルが実装される状況で、外向的なインタフェースの変化はトランスポート層が他のリンクに基づく輸送パラメタを変更する同時代に起こるかもしれません。
IAB Informational [Page 22] RFC 4907 Link Indications June 2007
IABの情報[22ページ]のRFC4907は指摘2007年6月にリンクします。
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.
どこ、マルチ、家へ帰り、増加するというホスト経験はインタフェースの1つで損失か減少しているレートを縁どっています、aがアカウントへのこれらの効果が増強するメートル法の取りを発送して、1人以上の輸送の接続のために潜在的に外向的なインタフェースの変化を引き起こして。 これは、また、入って来る経路の変化を引き起こすためにモバイルIPシグナリングの引き金となるかもしれません。 その結果、新しい送受信の経路には、元の送受信の経路(混雑状態、リンクマキシマム・トランスミッション・ユニット(MTU)から得られたMaximum Segment Size(MSS)またはPath MTU)に見積もられていた輸送パラメタはもう有効でないかもしれません。
To avoid race conditions, the following measures are recommended:
競合条件を避けるために、以下の測定はお勧めです:
Path change re-estimation
Layering
Metric consistency
経路変化再見積りLayering Metricの一貫性
2.7.1. Path Change Re-estimation
2.7.1. 経路変化再見積り
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 Hop Limitにおける大きな変化さえ検出して、それらが再見積もられているのを許容するために、輸送パラメタ(RTT、RTO、cwnd、bw、MSS)を彼らの初期の値にリセットするかどうか考える価値があるかもしれません。 これは、無効になった後に前の経路に基づく見積りが持続しないのを確実にします。 付録A.3はこの話題の研究をまとめます。
2.7.2. Layering
2.7.2. レイヤリング
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.
一般に、アプリケーションが直接リンク指摘を消費するよりインターネットかトランスポート層から指摘をむしろ利用するのは、賢明です。
IAB Informational [Page 23] RFC 4907 Link Indications June 2007
IABの情報[23ページ]のRFC4907は指摘2007年6月にリンクします。
2.7.3. Metric Consistency
2.7.3. メートル法の一貫性
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.
リンクが“up"状態にいったんあると、メートル法で適切なルーティングを決定するのにデータ・パケットのトランスミッションにおける有効性を使用できます。 トランスミッション時間が総トランジット時間の大半を表す状況で、総トランスミッション時間を最小にするのは有効なスループットを最大にするのに同等です。 「Multi-ホップWirelessルート設定のためのHigh-スループットPath Metric」[ETX]はExpected Transmission Count(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-レート]では、作者は新しいメートル法の呼ばれたExpected Transmission Time(ETT)を定義します。 これはETTがSが徹底的調査パケットのサイズであり、パケット組[モーガン]によって測定されるようにBがリンクの帯域幅であるETX*S/Bと等しい時から「帯域幅の調整されたETX」として記述されています。 しかしながら、ETTは、1つのMbpsデータ信号速度で送られた小さい徹底的調査フレームの損失部分が、より高いレートにおける、より大きいデータフレームの損失部分を暗示していると仮定します。(部分は、より高いレートにおける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
したがって、代替の測定基準(信号強度かAccess Point荷重などの)を利用するのが、付属/移管決定を助けるのに必要であるかもしれません。 しかしながら、新しいインタフェースが1つ以上の目的地接頭語のための都合のよいルートでないなら、Weak End System実装は外向的なトラフィックに新しいインタフェースを使用しないでしょう。 「アイドルタイムアウト」の機能性が実装されるところ
IAB Informational [Page 24] RFC 4907 Link Indications June 2007
IABの情報[24ページ]のRFC4907は指摘2007年6月にリンクします。
unused interface will be brought down, only to be brought up again by the link enablement algorithm.
未使用のインタフェースは降ろされるでしょうが、再びリンク権能割賦アルゴリズムで持って来られます。
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層の引き渡し時間を短縮するテクニック」[Velayos]で示されるように。
[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]は、信号強度と距離がフレームの損失かスループットの良い予言者でないことに注意します、マルチ経路干渉の潜在的効果のため。 その結果、良い信号強度のため持って来られたリンクは次に、重要なフレームの損失と少ないスループットを示すかもしれません。 同様に、Access Pointの(AP)示すことの低い利用は必ず最も良い選択であるかもしれないというわけではありません、利用がハードウェアかソフトウェアの問題のために低いかもしれないので。「OSPFは多重通路(OSPF-OMP)を最適化したこと」が[Villamizar]、リンクの利用ベースのルーティング測定基準には不安定性の歴史があることに注意します。
2.8. Layer Compression
2.8. 層の圧縮
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
いくつかの提案が、リンクレイヤの中で交換を結合することを伴います。 例えば、[EAPIKEv2]ではリンクレイヤ拡張認証プロトコル(EAP)[RFC3748]交換はIPアドレス課題の目的に使用されるかもしれません、インターネット層の構成を潜在的に迂回させて。 [PEAP]の中では、リンクレイヤEAP交換がモバイルIPv6 Binding Updatesを運ぶ目的に使用されるよう提案されます。 [MIPEAP]は、EAP交換がモバイルIPv6の構成に使用されるよう提案します。 どこ、リンク、インターネット、または輸送
IAB Informational [Page 25] RFC 4907 Link Indications June 2007
IABの情報[25ページ]のRFC4907は指摘2007年6月にリンクします。
layer mechanisms are combined, hosts need to maintain backward compatibility to permit operation on networks where compression schemes are not available.
層のメカニズムが結合されている、ホストは圧縮技術が利用可能でないネットワークで操作を可能にするために後方の互換性を維持する必要があります。
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.11BeaconやProbe Responseフレームなどのように。 しかしながら、[IEEE-802.1X]は、バーチャルLAN Identifier(VLANID)がダイナミックに割り当てられるのを可能にします、Beacon、そして/または、Probe Responseの中に広告に掲載された接頭語(es)がホストがリンクレイヤ認証を終了した後にインターネット層によって構成された接頭語(es)と食い違うことができるように。 ホストは、間違ったIPアドレスの課題のためホストがインターネット層の中でというよりむしろリンクレイヤでIP構成を扱うことになっていたと伝えることができないかもしれません。
2.9. Transport of Link Indications
2.9. リンク指摘の輸送
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)tなどの中央箱があるときより確かに作動してください、そして、以下はセキュリティの脆弱性をもたらしそうですか? その結果、明白なシグナリング提案は、内在している信号が不十分であると立証しなければなりません。
(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
(b) セキュリティの脆弱性の緩和。 輸送されたリンク指摘は新しいセキュリティの脆弱性を導入するべきではありません。 地方の経路指定テーブルへの変更をもたらすリンク指摘がルーティング・プロトコルを表して、そうはそれです。
IAB Informational [Page 26] RFC 4907 Link Indications June 2007
IABの情報[26ページ]のRFC4907は指摘2007年6月にリンクします。
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.
オフリンク攻撃者でだますのを含んでいて、非機密保護しているルーティング・プロトコルに関連している脆弱性は適用されます。 「安全な隣人発見(発信します)」[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) 輸送された指摘の合法化。 輸送されたリンク指示が指示がホストによって地方のリンクから送られるなら、保護されて、認証された保全であるかもしれなくても、使用中の実際の経路かそれとも指示がどの輸送接続に関連するかに関して送付者がいるのは、明確でないかもしれません。 提案は、受信ホストがどう輸送されたリンク指示を有効にすることができるかを説明する必要があります。
(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の使用のためにリモート要素に目に見えないかもしれません、プロトコル、または入れ子にされたヘッダーにトンネルを堀って。 その結果、提案は、どう関連より高い層の状態にリンク指示を写像できるかを示す必要があります。 例えば、リンク指示を受け取り次第、トランスポート層は、影響を受ける輸送セッション(アドレスの出典を明示してください、送付先アドレス、ソースポート、仕向港、輸送)のセットを特定する必要があるでしょう。 存在サーバが特定のメディアAccess Control(MAC)アドレスのために「リンク」/「リンクDown」状態のリモートしるしを受けていると、存在サーバは、そのリンク状態変化が関連しているユーザ(pres: user@example.com )のアイデンティティにそのMACアドレスを関連づける必要があるでしょう。
3. Future Work
3. 今後の活動
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).
より多くの仕事が、リンク指摘とルーティング測定基準との関係を理解するのに必要です。 例えば、ブロックACKs([IEEE-802.11e]では、サポートされる)の導入は有効なスループットとフレームの損失との関係を複雑にします。(損失は臨時のネットワークのための改訂されたルーティング測定基準の開発を必要とするかもしれません)。 また、より多くの仕事が、リンク指摘(例えば、フレーム誤り率と交渉されたレート)に基づくルーティング測定基準に移管測定基準(例えば、信号強度とリンク利用)を和解させるのに必要です。
IAB Informational [Page 27] RFC 4907 Link Indications June 2007
IABの情報[27ページ]のRFC4907は指摘2007年6月にリンクします。
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).
レート交渉における物理的、そして、リンクレイヤ測定基準の使用の、より良い理解が必要です。 例えば、近作[強健な][キャラ]は、チャンネル条件(レート減少を通して改良されるかもしれない)による損失と主張(レート減少で悪化させられる)によるフレームの損失を区別できるのを示しました。
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).
トランスポート層では、より多くの仕事が、経路指定テーブルや経路変化などのインターネット層のしるしへの適切な反応を決定するのに必要です。 また、より多くの仕事が輸送パラメータ推定における、リンクレイヤ指摘の利用で必要です、様々なタイプ(主張かチャンネル状態による)のレート変化、「リンク」/「リンクDown」指摘、リンクレイヤ「再-トランスミッション」、およびフレームの損失を含んでいて。
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.
また、より多くの仕事が、リンクレイヤがどのようにトランスポート層からの情報を利用するかもしれないかを決定するのに必要です。 例えば、リンクレイヤがリンクレイヤの往復の時間が終わりから終わりとの輸送接続のものにアプローチするほど積極的に再送されるのは、望ましくありません。 代わりに、それはフレームの損失を減少させて、潜在を改良するために下向きの料金の調整をする意味になるかもしれません。 また、いくつかの場合、トランスポート層はフレームの損失を避けるために英雄の取り組みを必要としないかもしれません。 タイムリーな配送は代わりに好まれるかもしれません。
4. Security Considerations
4. セキュリティ問題
Proposals for the utilization of link indications may introduce new security vulnerabilities. These include:
リンク指摘の利用のための提案は新しいセキュリティの脆弱性を導入するかもしれません。 これらは:
Spoofing
Indication validation
Denial of service
Indication合法化がサービスのDenialであると偽造します。
4.1. Spoofing
4.1. スプーフィング
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]はAssociate/Reassociate、Disassociate、またはDeauthenticateなどの管理フレームを保護しません。
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
IAB Informational [Page 28] RFC 4907 Link Indications June 2007
IABの情報[28ページ]のRFC4907は指摘2007年6月にリンクします。
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.
リンクの上に認証されたキーの完成までIPパケットを送るか、または受けるステーションは「4ウェイ握手」として知られているプロトコルを交換します。 その結果、インターネット層(「リンクする」)で認証された主要な交換の完成まで使用可能であると[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]が、「結び付いてください」という指示を得るために認証されたフレームを発信させるのを必要としている間、それは、管理がフレーム認証であるとサポートしません。 攻撃者は、遠方のAccess Points(APs)に付けられたステーションでサービス不能攻撃を可能にするためにこの弱点を開発できます。
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がReassociation Responseを送るとき、「リンク」が起こると考えられます。 その時、APはステーションのソースアドレスがある偽造しているフレームをマルチキャストアドレスに送ります、その結果、Distribution System(DS)の中のスイッチがステーションのMACアドレスを学ぶことを引き起こします。 これは新しい接着点のステーションにフレームの推進を可能にしますが、また、攻撃者がESSの中でどこでも位置したステーションを分離することを許可します、unauthenticated Reassociation Requestフレームを送ることによって。
4.2. Indication Validation
4.2. 指示合法化
"Fault Isolation and Recovery" [RFC816], Section 3, describes how hosts interact with routers for the purpose of fault recovery:
「欠点Isolationと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
事実上、ホストがアドバイスを求めて明らかにゲートウェイを尋ねるのは決して必要ではありません、ゲートウェイが適宜それを提供するので。 ホストが何らかの遠方のネットにデータグラムを送るとき、ホストはゲートウェイが送るかもしれない2つの顧問メッセージを受信し返す用意ができているべきです。 ICMPの「再直接」のメッセージは、問題のネットに達するようにホストがデータグラムを送ったゲートウェイがもう最も良いゲートウェイでないことを示します。 ゲートウェイはデータグラムを進めてしまうでしょうが、ホストは、このネットのための異なった即値アドレスを持つために経路指定テーブルを改訂するべきです。 ICMPの「目的地手の届かない」メッセージは、供給停止の結果、扱われたネットかホストに届くのが現在不可能であることを示します。
IAB Informational [Page 29] RFC 4907 Link Indications June 2007
IABの情報[29ページ]のRFC4907は指摘2007年6月にリンクします。
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.
どんな方法でも。 このメッセージを受け取り次第、ホストは、すぐ少しも一層の「再-トランスミッション」なしで接続を捨てるか、または欠点が妥当な時間で修正されるかどうかを見るのをゆっくり再送できます。
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]を使用できます。
4.3. Denial of Service
4.3. サービス妨害
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
輻輳制御が輸送問題であるだけではない、また、それは安全保障問題です。 てこの作用を攻撃者に供給しないように、単一の偽造リンクレイヤフレームは拡大された応答を引き出すはずがありません。
IAB Informational [Page 30] RFC 4907 Link Indications June 2007
IABの情報[30ページ]のRFC4907は指摘2007年6月にリンクします。
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.
どちらかを生成するのによる1人以上のホスト、複数の応答またはただ一つの、より大きい応答から。 例えば、提案は、複数のホストがマルチキャスト送付先アドレスでフレームに応じるのを可能にするべきではありません。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
5.2. Informative References
5.2. 有益な参照
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816,
July 1982.
[RFC816] クラークと、D.と、「欠点分離と回復」、RFC816、7月1982日
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1058] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、1988年6月。
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
1989.
[RFC1131] Moy、J.、「OSPF仕様」、RFC1131、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC
1256, September 1991.
[RFC1256] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
Control Protocol", RFC 1307, March 1992.
[RFC1307] ヤングとJ.とA.ニコルソン、「ダイナミックに切り換えられたリンク制御プロトコル」、RFC1307、1992年3月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[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.、deグルート、D.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
IAB Informational [Page 31] RFC 4907 Link Indications June 2007
IABの情報[31ページ]のRFC4907は指摘2007年6月にリンクします。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, June 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年6月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、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)のための隣人発見」、RFC2461、1998年12月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February
2000.
2000年2月の[RFC2778]日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC2861] ハンドレーとM.とPadhye、J.とS.フロイド、「TCP混雑窓の合法化」、RFC2861、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
BCP 41, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、RFC2914、BCP41、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、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.パクソン、「ストリーム制御伝動プロトコル」RFC2960、2000年10月。
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3118] DromsとR.とB.Arbaugh、「DHCPメッセージのための認証」、RFC3118、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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.Wood、「リンクAutomatic Repeat reQuest(ARQ)にデザイナーをリンクするというアドバイス」BCP62、RFC3366(2002年8月)。
[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、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
IAB Informational [Page 32] RFC 4907 Link Indications June 2007
IABの情報[32ページ]のRFC4907は指摘2007年6月にリンクします。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence
protocol (XMPP): Instant Messaging and Presence", RFC
3921, October 2004.
[RFC3921] サンアンドレ、P.、「広げることができるMessagingとPresenceは以下について議定書の中で述べ(XMPP)」。 「インスタントメッセージングと存在」、RFC3921、10月2004日
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of Link-Local IPv4 Addresses", RFC 3927,
May 2005.
[RFC3927]チェーシャー州(S.、Aboba、B.、およびE.Guttman、「リンクローカルのIPv4アドレスの動的設定」、RFC3927)は、2005がそうするかもしれません。
[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、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4423] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)のアーキテクチャ」、RFC4423)は2006がそうするかもしれません。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection
(DAD) for IPv6", RFC 4429, April 2006.
[RFC4429] ムーア、N.、「IPv6"、RFC4429、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)でネットワーク付属を見つけます」、RFC4436、2006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
MTU Discovery", RFC 4821, March 2007.
[RFC4821] マシスとM.とJ.ヘフナー、「Packetization層の経路MTU発見」、RFC4821、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、IEEE802.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月、ポートランド、オレゴン'。
IAB Informational [Page 33] RFC 4907 Link Indications June 2007
IABの情報[33ページ]のRFC4907は指摘2007年6月にリンクします。
[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年の国際会議の議事)は、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、「ワイヤレスの損失と受信機でInterarrival回を使用することで混雑の損失を区別します」、アプリケーション特有のシステムとソフトウェア工学と技術、リチャードソン、テキサス(1999年3月)におけるIEEEシンポジウムの議事。
[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
[キャラ]キム、J.、キム、S.、およびS.チェ、「キャラ:」 「IEEE802.11WLANsへの衝突意識しているレート適合」、コミュニケーション科学(KICS)ジャーナル、2006年2月の韓国の研究所
[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.
[Chandran]Chandran(K.、Raghunathan、S.、Venkatesan、S.、およびR.プラカシュ、「臨時のワイヤレス・ネットワークでTCP性能を向上させることのフィードバックベースの体系」、分散コンピューティングシステム(ICDCS)、アムステルダムにおける第18国際会議の議事)は1998がそうするかもしれません。
[DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6
(DNAv6)", Work in Progress, March 2007.
[DNAv6] 「IPv6(DNAv6)でネットワーク付属を見つけ」て、ナラヤナン、S.は進歩、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.ベルサニ、「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.
SIGCOMM厳かな1996 96年の間の[エッカード]エッカード、D.、P.Steenkiste、および「コネビルワイヤレス・ネットワークの誤りの特性の測定と分析」、スタンフォード(カリフォルニア)。
[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月)。
IAB Informational [Page 34] RFC 4907 Link Indications June 2007
IABの情報[34ページ]のRFC4907は指摘2007年6月にリンクします。
[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.クリステンセン、「イーサネットの適応型のリンクは評価します」。 「システムDesignとパフォーマンスEvaluation」、LocalコンピュータNetworks、ページのIEEEコンファレンスのProceedings 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.シュミッド、「即座のRetransmissionsのための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]ダグラス・S.J.DeコウトとダニエルAguayoとジョンBicketとロバート・モリスと「マルチホップワイヤレスルート設定における、メートル法の高生産性経路」とモバイル・コンピューティングにおける第9ACM国際会議の議事と2003'年9月に(MobiCom'03)、サンディエゴ(カリフォルニア)をネットワークでつなぐこと。
[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 MobiComコンファレンスのProceedings、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コンピュータ理学部、ロサンゼルス、カリフォルニア。
[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.ジョンストン、「リンクレイヤ引き金のための一般化されたモデル」、2004年3月に利用可能なIEEE802.21(処理中の作業)への服従 _02.pdfの引き金となっているdocs/一般化された_>に会う<http://www.ieee802.org/移管/march04_。
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance
over Wireless Links", Proceedings of TENCON'98, pages
332-335. IEEE, December 1998.
TENCON98年、332-335ページの[ゴエル]ゴエルとS.とD.Sanghi、「ワイヤレスのリンクの上のTCP性能を向上させます」、Proceedings。 1998年12月のIEEE。
[Gont] Gont, F., "ICMP attacks against TCP", Work in
Progress, October 2006.
[Gont] Gont、F.、「TCPに対するICMP攻撃」、Progress、2006年10月のWork。
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical
Handovers on Performance of TCP-Friendly Rate
Control", to appear in ACM MCCR, 2004.
[Gurtov] ACM MCCR、2004で見えるGurtov、A.とJ.Korhonen、「TCPに優しい速度制御のパフォーマンスへの垂直な身柄の引き渡しの効果。」
IAB Informational [Page 35] RFC 4907 Link Indications June 2007
IABの情報[35ページ]のRFC4907は指摘2007年6月にリンクします。
[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.一口、「IEEE802.11のためのハイブリッド速度制御」MobiWac'04、2004年10月1日、フィラデルフィア(ペンシルバニア)、米国、'
[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.、「IEEE802.11へのアプリケーション指向のリンク適合」、博士Thesis、デルフト(オランダ)ISBN-10の技術的な大学: 90-9020513-6、ISBN13: 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.とキャンベル、「ホットスポット緩和プロトコル(HMP)」が進行中で扱うA.、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パフォーマンスの分析」、モバイルComputingとNetworking(219-230ページ)の上の黙秘権の国際コンファレンスのProceedings。 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.とBhattacharyya、S.とC.Diot、「IPバックボーンにおける、リンクの故障の分析」Proc ACM SigcommインターネットMeasurement Workshop、2002年11月について。
[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/男性決められた一定の要求)は11を分けます」。 ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様--修正8: 「媒体アクセス制御(MAC)サービスの質増進」、IEEE 802.11e、2005年11月。
IAB Informational [Page 36] RFC 4907 Link Indications June 2007
IABの情報[36ページ]のRFC4907は指摘2007年6月にリンクします。
[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]の米国電気電子技術者学会、「Inter-アクセスPointプロトコルAcross Distribution Systems Supporting IEEE802.11Operationを通したMulti-ベンダーAccess Point InteroperabilityのためのRecommended PracticeをIEEE Trial使用してください」、IEEE802.11F、2003(現在推奨しない)年6月。
[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/男性決められた一定の要求--パート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/男性決められた一定の要求)は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/男性決められた一定の要求--パート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.、Park、Y.、Suh、K.、およびY.Park、「2004年8月にモバイルIPv6"、ProgressのWorkの上のTCP性能を向上させるためのBU引き金のメソッド。」
[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.
[コッツ]コッツ、D.、ニューポート、C.、およびC.エリオット、「ワイヤレス・ネットワーク研究の間違われた原理」、ダートマス大学コンピュータScience Technical Report 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月)。
IAB Informational [Page 37] RFC 4907 Link Indications June 2007
IABの情報[37ページ]のRFC4907は指摘2007年6月にリンクします。
[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、「IEEE802.11は適合を評定します」。 「実践的なアプローチ」、MSWiM'04、2004年10月4日〜6日、ヴェネツィア、イタリア、'
[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 Infocom'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.、グァルディーニ、I.、Demaria、E.、Bournelle、J.、およびM.ローラン-Maknavicius、「MIPv6 AuthorizationとConfigurationはEAPを基礎づけました」、ProgressのWork、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.
[Mishra] ミトラ、A.、向こうずね、M.、およびW.Arbaugh、「IEEE802.11MAC層の移管プロセスの実証的分析」、Cs-TR-4395、メリーランドコンピュータサイエンス学部大学(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.
「802.11があるモバイルIPv4のための層の2移管」という[マン]マン、Y.、およびJ.公園は進歩、2004年3月に働いています。
[ONOE] Onoe Rate Control,
<http://madwifi.org/browser/trunk/ath_rate/onoe>.
[尾上]尾上の速度制御、<http://madwifi.org/ブラウザ/トランク/ath_レート/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.
Communications、2003(ICC'03)、2、1108- 1113ページのボリューム(アンカレッジ(アラスカ)(米国)2003'年5月)に関する[パボン]パボンとJ.とS.チェ、「容認された信号強度測定を通したIEEE802.11 WLANのためのリンク適合戦略」、IEEEの国際コンファレンス。
[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月に働いてください。」
IAB Informational [Page 38] RFC 4907 Link Indications June 2007
IABの情報[38ページ]のRFC4907は指摘2007年6月にリンクします。
[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月のProceedings。
[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.
[Qiao]Qiao D.、チェ、S.、ジャイナ教徒、A.、およびカンG.がよじ登る、「守銭奴:」 Procの「/hあたりIEEE802.11のためのOptimal Low-エネルギーTransmission Strategy。」 サンディエゴ(カリフォルニア)2003'年9月のACM MobiCom'03。
[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.
[Ramani] Ramani、I.、およびS.サヴェージ、「SyncScan:」 「802.11のインフラストラクチャネットワークのための実用的な速い移管」、IEEE InfoCon2005、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)、Lu、S.、およびV.Bharghavan、「802.11のワイヤレス・ネットワークへの体力を要しているレート適合」ACM MobiCom'06、ロサンゼルス(カリフォルニア)(2006'年9月)。
[SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks",
MIT Master's Thesis, 2005.
[SampleRate] Bicket、J.、「Wirelessネットワークにおけるビット伝送速度Selection」、MasterのMIT Thesis、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.とエッゲルトとL.とシュミッド、S.とM.ブルンナー、「断続的に接続されたホストのためのプロトコル増進」ACM SIGCOMMコンピュータコミュニケーションは再検討されます、第35巻、No.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.
[最も短い]のダグラス・S.J.Deコウト、ダニエルAguayo、ベンジャミンA.判事室、およびロバート・モリス、「マルチホップ無線電信のパフォーマンスは以下をネットワークでつなぎます」。 「最も短いPathはNot Enoughです」、Networking(HotNets-I)のHot Topicsの上のFirst WorkshopのProceedings、プリンストン(ニュージャージー)2002年10月。
[TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework
and Requirements for TRIGTRAN", Work in Progress,
August 2003.
[TRIGTRAN] ダウキンズ、S.、ウィリアムズ、C.、および「TRIGTRANのための枠組みと要件」というYeginが進歩、2003年8月に働かせるA.。
[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 R03:01、KTHのロイヤル工科大学(ストックホルム(スウェーデン)2003年7月)。
IAB Informational [Page 39] RFC 4907 Link Indications June 2007
IABの情報[39ページ]のRFC4907は指摘2007年6月にリンクします。
[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.
[Velayos] Velayos、H.とG.カールソン、「IEEE 802.11b MAC層の引き渡し時間を短縮するテクニック」TRITA-IMIT-LCN R03: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.
C.、「OSPFは多重通路(OSPF-OMP)を最適化した」という[Villamizar]Villamizarは進歩、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.、「マルチサービスリンクは層にします」。 「Wirelessリンクスの上のEnhancingインターネットパフォーマンスへのApproach」、博士論文、カリフォルニア大学サンディエゴ校、1999。
[Yegin] Yegin, A., "Link-layer Triggers Protocol", Work in
Progress, June 2002.
A.、「リンクレイヤはプロトコルの引き金となる」という[Yegin]Yeginは進歩、2002年6月に働いています。
6. Acknowledgments
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.
作者はこのドキュメントへの貢献のためにジェームス・ケンフ、フィル・ロバーツ、ゴーリーFairhurst、ジョンWroclawski、アーロン・フォーク、サリー・フロイド、ペッカSavola、ペッカNikander、デーヴThaler、Yogesh Swami、ウエスリーEddy、およびヤンネPeisaを承認したがっています。
IAB Informational [Page 40] RFC 4907 Link Indications June 2007
IABの情報[40ページ]のRFC4907は指摘2007年6月にリンクします。
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.
「マルチホップ無線電信のパフォーマンスは以下をネットワークでつなぐところ」で 「最も短いPathはNot Enough[最も短い]である」、作者が屋内の、そして、野外のメッシュがネットワークでつなぐ両方の性能を研究しました。 節間スループットを測定することによって、ノードの間の最も良い経路は計算されました。 最も良い経路に関するスループットはホップカウントに基づいてメートル法で計算される最短パスに関するスループットにたとえられました。 ほとんどすべての場合、最短パスルートは最も良い経路よりかなり少ないスループットを提供しました。
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.
リンクの振舞いを調べる際に、作者は、“up"(低損失率)と“down"(高い損失率)の間の二つのモードの分配を示すよりむしろ、多くのリンクが中間的損失率を示したのがわかりました。 また、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.
「ビルのワイヤレス・ネットワークの誤りの特性の測定と分析」[エッカード]では、作者はカーネギーメロンキャンパスでInfrastructureモードにおける、ビルでのAT&T Wavelan2Mbps 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.
「802.11b網目状ネットワークからのリンク・レベル測定値」[Aguayo]では、作者は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
SN比(SNR)と距離は、“up"(低い損失)か“down"(高い損失)州、aを示して、広く変えられた節間損失率がほとんど制服であることを間に階段関数変遷を示すより損失率を予測して、むしろ値にほとんど示しませんでした。
IAB Informational [Page 41] RFC 4907 Link Indications June 2007
IABの情報[41ページ]のRFC4907は指摘2007年6月にリンクします。
distribution over the range at the lower rates. The authors attribute the observed effects to multi-path fading, rather than attenuation or interference.
低料金における範囲の上の分配。 作者は減衰か干渉よりむしろマルチ経路の色あせへの観測された効果を結果と考えます。
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.
また、振舞いにおけるかなりの多様性が実現効果のため観測されます。 APがオフにされた後に「IEEE 802.11b MAC層の引き渡し時間を短縮するテクニック」[Velayos]は静止したSTAのために引き渡し時間を測定しました。 この研究は引き渡し時間を検出(付属の既存のポイントからの断線の決断)、検索(代替の付着点の発見)、および実行(付属の代替のポイントとの接続)フェーズに分割しました。 これらの測定値は、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.
検出の振舞いは実現の間でばらつきが大きかったです。 例えば、ラップトップデザインと比べて検索の引き金となる前にデスクトップに設計されたネットワーク・インターフェース・カード(NICs)は、より多くの「再-トランスミッション」を試みました、APがいつも範囲にあったと仮定したので、Beaconを受け取ったかどうかにかかわらず。
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が発信しないところでは、フレーム搬入して、Beaconレセプションが断線を検出するために追跡されて、Beaconスペースが60msに変えられるのは、検出時間を減少させるためにお勧めです。 検索フェーズについて、より頻繁な引き金となることを補うために、作者は待ち時間の減少のためのアルゴリズム、および検索とデータフレーム送信のインターリービングを推薦します。
"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
「IEEE802.11MAC Layer Handoff ProcessのEmpirical Analysis」[Mishra]は3つの可動のSTA実現が2APsとコミュニケートしている状態で得られた移管潜在を調査します。 研究によって、STAとAP実現の中に移管潜在の大きい変化があって、実現が異なったメッセージ系列を利用するのがわかりました。 例えば、1STAがReassociation Requestを優先的に送ります。
IAB Informational [Page 42] RFC 4907 Link Indications June 2007
IABの情報[42ページ]のRFC4907は指摘2007年6月にリンクします。
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.
認証に。(それは、Deauthenticateメッセージを受け取って結果として生じます)。 研究は移管潜在を発見、認証、および「再-協会」交換に分割しました、発見フェーズが移管遅れの優位なコンポーネントであったと結論を下して。 検出フェーズにおける潜在は調査されませんでした。
"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.11Infrastructure Networksのための実用的なFast Handoff」[Ramani]は受動態に対して活発なスキャンの賛否両論を熟慮します。 作者は調節されたBeaconレセプションの利点を指摘します。(以前に、[IEEE-802.11k]にレセプションを組み入れてありました)。 調節されたBeaconレセプションで、移管が、より早く起こるのを許容して、ステーションは絶えず隣接しているAPsのSN比で最新の状態で維持されます。 ステーションが放送Probe Response(それぞれMinChannelTimeとMaxChannelTime)への初期の、そして、その後の応答を待つ必要はないので、性能は802.11k Neighbor ReportsとユニキャストProbe Requestsと共に達成可能なことに匹敵しています。
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.
作者はチャンネル切り換え遅れ(わざわざ新しい頻度に切り替わって、それがフレーム搬入し始める)を測定しました。 測定値はチャンネル単位で5msから19msまで及びました。 調節されたBeaconレセプションかはさみ込まれた活発なスキャンが使用されているところでは、切換え時間は総合的な移管潜在にかなり貢献します。 作者はNetwork Timeプロトコル(NTP)[RFC1305]でBeaconsが連動しているAPsの展開を提案します、SyncScanを実行するドライバーが遺産APsと共に新しいプロトコルの実現を必要としないで働いているのを可能にして。 作者は優秀な成績がある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信号を止めてある後に「ローミングInterval Measurements」[Alimian]は静止したSTAsの動きに関するデータを提示します。 この研究は検出、スキャン、および移管と同様にレート適合の実現差を目立たせました。 [Velayos]のように、性能は、桁の変化が半分からの実現の間で検出時間、スキャンにおける2桁の桁の差へのレート適合でばらつきが大きく、移管時代に1.5桁がばらつきが大きかったです。
"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からの信号([Velayos]で使用される遮断のテクニックより実地経験を代表している)が徐々に減衰しているとき振舞いが観測した引き渡しについて説明します。 駅は純粋にフレームの損失に基づいているよりむしろ敷居より下であるまで浸された状態で信号強度であることの引き渡しを開始するために構成されました、まだ現在のAPに接続されている間、引き渡しを始めることができるように。 ステーションが、検索段階の間、データフレームを受け取り続けていたことに注意されました。 駅によって開始されています。
IAB Informational [Page 43] RFC 4907 Link Indications June 2007
IABの情報[43ページ]のRFC4907は指摘2007年6月にリンクします。
Disassociation and pre-authentication were not observed in this study.
Disassociationとプレ認証はこの研究で観測されませんでした。
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終わっているフレームを送るかもしれません、そして、リンクが一度交渉がそのプロトコルのために完成したNetwork Controlプロトコル(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と異なって、IEEE802はネットワーク層構成のための施設を含まないで、「リンク」と「リンク下である」の定義は実現で異なります。 実証的証拠は、「リンク」と「リンク下である」の定義がステーションが可動であるか静止しているかによるかもしれないのを示します、インフラストラクチャかアドホック・モードが使用中であり、セキュリティとInter-アクセスPointプロトコル(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が1Beaconsがいなくて寂しい間、一連の連続した非承認されたフレームに遭遇するところでは、最もありそうな原因はステーションがAPの範囲から引っ越したということです。 その結果、[Velayos]は、衝突を除外されたことができた後にステーションが検索フェーズを始めることを勧めます。 このアプローチがレート適合を考慮に入れないので、それはいくらか攻撃的であるかもしれません。 どんな代替の実行可能なレートも接着点も見つけないときだけ、「リンク下である」指示を返します。
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.
セキュリティのないIEEE802.11アドホック・モードで、データフレームのレセプションは州1("Unauthenticated"と"Unassociated")で可能にされます。 その結果、データフレームのレセプションはいつでも可能にされます、そして、「結び付いてください」というどんな明白な指示も存在していません。
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
Infrastructureモードで、IEEE802.11-2003は州3だけ(「認証され」て、「関連づけられる」)のデータフレームのレセプションを可能にします。 結果、州3への変遷、(例えば、aうまくいくことの完成
IAB Informational [Page 44] RFC 4907 Link Indications June 2007
IABの情報[44ページ]のRFC4907は指摘2007年6月にリンクします。
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.
協会かReassociation交換) ネットワーク・プロトコルパケットを発信して、受信する("Deauthenticate"フレームのレセプション)が無能にする州3から州2(「分離してください」というフレームのレセプション)か州1でネットワーク・プロトコルパケットと変遷の送受信を可能にします。 その結果、ステーションが通常合図するIEEE802.11はうまくいっているAssociation/Reassociation Responseを受け取り次第「結び付きます」。
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.
Reassociation Responseを送った後に[IEEE-802.11F]以内で説明されるように、Access Pointはステーションのソースアドレスがあるフレームをマルチキャストの目的地に送るでしょう。 これで、Distribution System(DS)の中のスイッチは彼らの学習テーブルをアップデートします、新しい接着点のステーションにフレームを送るためにDSを準備して。 APがこの「だまされた」フレームを送らないなら、新しい位置の最初のフレームを送るまで、流通制度の中でステーションの位置をアップデートしないでしょうに。 したがって、スプーフィングの目的はアップリンクとダウンリンク引き渡し回数を均等化することです。 これは、攻撃者が犠牲者のMACアドレスを使用することでReassociation Requestをだますことによって認証されて関連しているステーションに対するサービスを否定するのを可能にします、ESSの中でどこでも、から。 スプーフィングがなければ、そのような攻撃はReassociation Requestが送られた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パケットを送るか、または受けることができないステーションを、もたらしますが、これは、そのような変遷が「リンク下である」指示であると考えられるべきであるのを必ず含意するというわけではありません。 インフラストラクチャネットワークでは、ステーションは複数のAccess Pointsが同じネットワークに接続を提供することの選択を持っているかもしれません。 そのような環境で、1Access Pointと共に州3に達することができないステーションは、代わりに別のAccess Pointに付くのを選ぶかもしれません。 「リンク下である」指示を各移動に登録するよりむしろ、ステーションは代わりに「結び付いてください」という一連の指摘を登録するかもしれません。
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.
単に[IEEE-802.11i]では、フレームのステーションから流通制度までの推進は4ウェイ握手とグループ主要な握手の完成の後に可能です、州3に入るのがもう十分でないように。 これはいくつかの観測された問題をもたらしました。例えば、「結び付いてください」という指示がステーションでAssociation/Reassociation Responseの領収書で引き起こされるところでDHCP[RFC2131]かRouter Solicitation/ルータAdvertisement(RS/RA)がリンクがインターネット層で使用可能である時の前に引き起こされるかもしれません、構成遅れか失敗をもたらして。 同様に、トランスポート層接続がパケット損失、結果になることに遭遇する、逆、-、再送信タイマー。
IAB Informational [Page 45] RFC 4907 Link Indications June 2007
IABの情報[45ページ]のRFC4907は指摘2007年6月にリンクします。
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.
「リンクAutomatic Repeat reQuest(ARQ)にデザイナーをリンクするというアドバイス」[RFC3366]はIPにリンクレイヤAutomatic Repeat reQuest(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)の信頼できて頼り無いリンクレイヤモードをどう利用できるかを説明します。 信頼できるリンクレイヤプロトコルが必要であるところでは(そのような信頼できる輸送TCPとStream Control Transmissionプロトコル(SCTP)[RFC2960]が使用されているところ)、Radio Linkプロトコル(RLP)は従事できます。 UDPに基づくものなどの遅れ敏感なアプリケーションと共に、透過モード(RLPがない)を使用できます。 また、作者は高潜在GSMリンクの上に「Quickstart-ppp」を使用することでどうPPP交渉を最適化できるかを説明します。
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
性能を向上させるために、「賢いリンクレイヤ」(首尾よく接続に伝えられないで、次に「結び付いてください」という指示を受け取り次第それを再送する最初のパケットを格納する)は提案されます。 断線が再接続に関する異なったネットワーク状態を経験するホストをもたらすことができるので、作者は、遅れた出発を迂回させるか、または混雑ウィンドウを上げるのを試みると提唱しません。 IPsecが使用されていて、接続を微分できないところに、輸送ヘッダーが目に見えないので、与えられた送付者と送付先IPアドレスのための最初の「非-伝え」られたパケットを再送できます。 1接続あたり1つの単一のパケット、また、調べられた作者の「再-トランスミッション」を見ることに加えて、他はそのようなものを計画します。
IAB Informational [Page 46] RFC 4907 Link Indications June 2007
IABの情報[46ページ]のRFC4907は指摘2007年6月にリンクします。
as retransmission of multiple packets and simulated duplicate reception of single or multiple packets (known as 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.
一般に、「再-トランスミッション」計画は「再-レセプション」計画より優れて、「再-レセプション」が速く刺激となることができないので、タイムアウトの後に再送してください。 複数のパケットのRetransmissionは単一のパケットの「再-トランスミッション」の上の性能をかなり向上させませんでした。 まさしく損失性チャンネルよりむしろ断線には研究の焦点があったので、2州のマルコフモデルは使用されました、“up"州が損失を全く表していなくて、“down"州が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.
「マルチサービスリンクは以下を層にするところ」で 「Wirelessリンクスの上のEnhancingインターネットパフォーマンスへのApproach」[Xylomenos]、作者は、スタンドアロンのファイル転送、ウェブブラウジング、および連続したメディア分配における、様々なリンクレイヤ回復計画(「再-トランスミッション」のない生のリンク、順調な逆N、XORベースのFEC、選択している反復、KarnのRLP、順序が狂ってRLP、およびバークレースヌープ)の性能をシミュレートするのにナノ秒-2を使用します。 選択している反復とKarnのRLPはファイル転送とウェブブラウジングシナリオのための最も高いスループットを提供しますが、連続したメディア分配は低い遅れと低い損失の組み合わせを必要とします、そして、系列で出ているRLPはこのシナリオでよく振る舞いました。 結果が、すべてのアプリケーションには、どんなただ一つのリンクレイヤ回復計画も最適でないことを示すので、作者は、リンクレイヤが複数の回復計画を実行するよう提案します。 マルチサービス構造のシミュレーションは、TCPの低誤り率回復計画(KarnのRLPなどの)とUDP交通の低い遅れ計画(順序が狂ってRLPなどの)の組み合わせがすべてのシナリオにおける望ましい市場成果に備えるのを示しました。 そして、作者はどうマルチサービスリンクレイヤを統合できるかをDifferentiated Servicesに説明します。
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:」 「Unlicensed BandのためのHigh-パフォーマンスWireless LAN」[Kamerman]、作者はAutomatic Rate Fallback(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
「マルチホップワイヤレス・ネットワークのためのレート適応型のMACプロトコル」[RBAR]で、作者はIEEE802.11MACへの非互換な変化を必要とする閉ループレート適合アプローチを提案します。 送付者が通信速度をより決定するのを可能にするために、受信機は、容認されたRTSフレームのパケット長とSN比(SNR)を測定して、チャンネル用法統計よりむしろ理論的チャンネルモデルに基づく対応するレートについて計算します。 お勧めのレートはCTSフレームで返送されます。 これは許容します。
IAB Informational [Page 47] RFC 4907 Link Indications June 2007
IABの情報[47ページ]のRFC4907は指摘2007年6月にリンクします。
rate (and potentially the transmit power) to be optimized on each transmission, albeit at the cost of requiring RTS/CTS for every frame transmission.
伝わってください。レート、(潜在的に、パワー) 各トランスミッションあらゆるフレームトランスミッションのために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.
中、「守銭奴:」 「/hあたりIEEE802.11のためのOptimal Low-エネルギーTransmission Strategy」[Qiao]、最適化がパワーを伝えるので、作者は計画を提案します。 提案は隠されたノードに対処するためにRTS/CTSの使用を強制します、CTSとACKフレームが全力で送られるのが必要であることで。 作者はチャンネル用法統計に基づいて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.
中では、「IEEE802.11は適合を評定します」。 (それは、そうしません)。「Practical Approach」[Lacage]、作者は低遅延実現と高潜在実現を見分けます。(実現は1パケットあたりのレート決定を可能にします)。 彼らがリアルタイムの必要条件を満たすのを可能にして、前の実現はそれらのデザインに専用CPUを通常含んでいます。 後者の実現は上側のMACがホストの上で実行される高集積度なデザインに通常基づいています。 その結果、オペレーティングシステム潜在のために、1パケットあたりのレート決定をするのに必要である情報は時間内に、利用可能でないかもしれません。
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.
作者は低遅延実現で使用のためのAdaptive ARF(AARF)アルゴリズムを提案します。 これは上向きのレート交渉に必要であるうまくいっているトランスミッションの数を増加させている間、ACKを受け取らないことの急速な下向きのレート交渉を可能にします。 したがって、AARFアルゴリズムはチャンネル資産がゆっくり変化するところで状況で非常に安定していますが、上向きに適合するには、チャンネル状態が向上したら、遅くなってください。 アルゴリズムをテストするために、作者はナノ秒-2つのシミュレーションをAARFのバージョンを実行するのが高潜在実現(5212年のARチップセット)に順応したのと同じくらいよく利用しました。 フレームがトランスミッションのために列に並ばせられるとき、WiFi(MadWiFi)ドライバーのためのMultiband Atheros Driverは、レートと再試行に関する固定した予定が提供されるのを可能にします。 Adaptive Multi Rate Retry(AMRR)として知られている適合しているアルゴリズムはそれぞれの3つのレートで1個のトランスミッションだけを要求します。その最終は最小の有効なレートです。 これは最小量の潜在があるチャンネルで一時的な変動への適合を可能にします。 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
「Received Signal Strength Measurementを通したIEEE802.11WLANのためのリンクAdaptation Strategy」[パボン]では、作者はSTAが各通信速度のためにダイナミックに見積もられている閾値でAPから容認された信号強度(RSS)の比較に基づく通信速度を調整するアルゴリズムを提案します。 フレームのレセプションでは、STAが平均したRSSをアップデートして、トランスミッションのときに、STAはレートを選択して、トランスミッションがうまくいっているかどうか基づくRSS閾値を調整します。 アルゴリズムを有効にするために、作者はOPNETを利用しました。
IAB Informational [Page 48] RFC 4907 Link Indications June 2007
IABの情報[48ページ]のRFC4907は指摘2007年6月にリンクします。
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.
干渉のないシミュレーション、およびSN比(SNR)に従ったビット誤り率(BER)の理想的なカーブはそうでした。想定にされる。 当然ながら、シミュレーションの結果は密接に与えられたSN比に、達成可能な最大のスループットに合っていました、理想的なBER対SNRカーブに基づいて。
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:
「IEEE802.11のためのハイブリッド速度制御」[Haratcherev]では、作者は統計ベースの自動速度制御で選択された潜在的レートを抑制するのにSignal Strength Indication(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レートと共に、通常、1秒の注文には適合タイムスケールがあります。 いくつのレートがテストされるかによって、このテクニックは適合を隣接しているレートを超えたところまで可能にすることができます。 しかしながら、最高率と低いフレームの損失が既に遭遇しているところでは、このテクニックは低いスループットをもたらします。
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データの収集に基づいているので、よりゆっくり続きます。 このテクニックは隣接しているレートへの適合に制限されます、そして、それには、潜在的に主張によるフレームの損失を悪化させる不都合があります。
IAB Informational [Page 49] RFC 4907 Link Indications June 2007
IABの情報[49ページ]のRFC4907は指摘2007年6月にリンクします。
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は使用されました。 このアプローチは受信電力を送付者に提供するために受信機を必要としません、IEEE802.11MACを変えないでそれを実行できるように。 レート対ACK SSIカーブの較正は左右対称のチャンネルを必要としませんが、それは、両方の方向へのチャンネルの特性が比例している方法で異なって、ACKがパワー残り定数を伝えるのを必要とします。 作者は、比例性仮定をチェックして、受信データのSSIが容認されたACKsの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.
中、「キャラ:」 「IEEE802.11WLANsのための衝突意識しているRate Adaptation」[キャラ]、作者はCollision意識しているRate Adaptation(キャラ)を提案します。 これは、チャンネル状態によって引き起こされた損失とフレーム衝突で引き起こされた損失を区別するために送るために発信するRequest/明確な(RTS/CTS)メカニズムの適合に伴うClear Channel Assessment(CCA)の利用にかかわります。 衝突による増加する主張に通じるフレームの損失の結果としての低下率よりむしろ、キャラは選択的に、RTS/CTS(例えば、フレームの損失の後の)を有効にします、隠されたステーションによるフレームの損失の見込みを減少させて。 また、キャラは衝突がトランスミッションの後に起こったかどうか決定するのに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
そして「802.11のワイヤレス・ネットワークへの体力を要しているレート適合」[強健な]では作者がプログラマブルAccess PointプラットホームでARF、AARF、およびSampleRate[SampleRate]アルゴリズムを実行した。
IAB Informational [Page 50] RFC 4907 Link Indications June 2007
IABの情報[50ページ]のRFC4907は指摘2007年6月にリンクします。
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:
実験的に、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.
厳しいフレーム損失Where厳しいフレームの損失での減少通信速度はチャンネル状態のためであり、レート減少はスループットを改良できます。 しかしながら、フレームの損失が主張(隠されたステーションなどの)のためにあるところで通信速度を減少させると、混雑は増加します、スループットを下げて、潜在的に充血性の崩壊に通じて。 代わりに、作者は、隠されたステーションによる主張を抑えるために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.
サンプルサイズが十分であり、徹底的調査フレームがデータフレームへの匹敵する長さのものでないなら徹底的調査フレームを使用して、Probeフレームが与えられたレートにフレームの損失を確かに見積もる可能な新しいレートを算定してください。 作者は、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
SNRのようなPHY測定基準を使用して、作者が(SNR)がきまりきって1パケットあたり5dB変えるその容認されたSN比に論争する新しい通信速度であって、10-14dBの変化が一般的であると推論してください。 その結果、SNRか信号強度に基づくレート決定で、通信速度は急速に異なることができます。 作者はそのような急速な変化の値に質問します、[Aguayo]などの研究がほとんどSNRとフレーム呼損率の間の相関関係を示さないので。 その結果、作者は、チャンネル状態のためそれらと主張による損失を区別するのに容認された信号強度指示(RSSI)もバックグラウンドエネルギーレベルも使用できないと主張します。 干渉が同時に低く高い信号強度とフレームの損失、関係に結果になることができるマルチ経路である間、合図してください。
IAB Informational [Page 51] RFC 4907 Link Indications June 2007
IABの情報[51ページ]のRFC4907は指摘2007年6月にリンクします。
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.
強さと高いフレームの損失は、より強いです。 したがって、低容認された信号強度による通信速度減少はたぶんチャンネル状態における突然の悪化を反映します、急増は、チャンネル状態が向上したのを必ず示すかもしれないというわけではありませんが。
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.
長期のsmoothened操作は作者が非相関がフレームの損失150以上ms離れてあるという証拠を提示する最も良い平均した性能を製作します。 したがって、1秒以上の間隔にわたる統計データの収集は、反応性を減少させますが、通信速度決定の品質を改良しません。 むしろ、作者は、100msのサンプリング周期が最も良い平均した性能を提供すると主張します。 期間がまた徹底的調査パケットがすべてのデータフレームの部分を表すことができるだけであって、探測装置が離れて150以上msを集めて以来の徹底的調査の使用に対して論争するそのような小標本はチャンネル条件に関する信頼できる情報を提供しないかもしれません。
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.
これらの欠点に基づいて、作者はRobust Rate Adaptation Algorithm(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アルゴリズムを有効にします。 結果は、適応型のRTS/CTSのないRRAAがARF、AARF、およびSample Rateアルゴリズムより優れているのを示します。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
「WWANとWLANの間の垂直な移管のための効率的な移動性管理」[垂直な]では、作者は、信号強度の使用を提案して、垂直な移管を最適化するために利用をリンクします。 WWANへのWLAN
IAB Informational [Page 52] RFC 4907 Link Indications June 2007
IABの情報[52ページ]のRFC4907は指摘2007年6月にリンクします。
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.
移管はSSI腐敗によって追い立てられます。 IEEE802.11SSIが敷居(S1)の下に落下するとき、高速フーリエ変換の(FFT)ベースの腐敗検出は、信号が腐食するのが継続的でありそうであるかどうか決定するために引き受けられます。 そうだとすれば、そして、信号が最小の合格水準(S2)の下に落ちるとき、WWANへの移管は開始されます。 WLAN移管へのWWANはPHYとIEEE802.11目標ネットワークのMACの特性の両方によって動かされます。 PHY層では、SSIなどの特性は、信号強度が最小値(S3)より大きいかどうか決定するために調べられます。 MAC層では、IEEE802.11Network Allocation Vector(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]で、作者はスプリントの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.
「双方向のForwarding Detection」[BFD]は、リンクレイヤが限られた失敗指摘だけを提供するかもしれなくて、「こんにちは」という比較的遅いメカニズムがどんなリンクレイヤ指摘も利用可能でないときに、失敗を検出するのにルーティング・プロトコルに使用されることに注意します。 これはいくつかのアプリケーションには、長過ぎる1秒の注文の失敗検出倍をもたらします。 作者はどんなメディアの上の活性検出に使用できるメカニズムについて説明します、隣接している推進エンジンの間の経路での失敗の急速な検出を可能にして。 双方向の可到達性が確認されたとき、経路は操作上であると宣言されます。
IAB Informational [Page 53] RFC 4907 Link Indications June 2007
IABの情報[53ページ]のRFC4907は指摘2007年6月にリンクします。
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"[RFC4436]でネットワーク付属(DNA)を見つけて、新しい接着点に移ったホストは急速に手術可能な構成を再確認するのに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 Example」[駐車する]、作者は、可動のノードが「リンク上」指示を受け取り次第一般的な動き検出[RFC3775]を使用することで可能であるだろうより低い移管潜在を提供するためにルータ懇願を送るよう提案します。 また、作者が即座の無効にするのを勧める、Care、-、Address(CoA)はaを受け取り次第指示を「下にリンクします」。 しかしながら、これは「結び付いてください」という指示がIP構成における結果として起こる変化なしで「リンク下である」指示のあとに続くことができるところで問題が多いです、[RFC4436]で説明されるように。
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 RegistrationメッセージがIEEEのInformation Elementsの中で伝えられることを提案します。移管遅れを最小にする802.11個のAssociation/Reassociationフレーム。 これは802.11APsと同様に可動のノードへの変更を必要とします。 しかしながら、ネットワーク付属を見つける前に、可動のノードが、新しい接着点がネットワークの変化を表すかどうか決定するのは、難しいです。 例えば、ステーションが同じESSに残りさえするところで、ネットワークが変化するのは、可能です。 ネットワークの変化が全く結果として生じないところでは、各Association/ReassociationがあるMIPv4 Registrationメッセージを送るのは不要です。 ネットワークの変化が結果として生じるところでは、可動のノードがAssociation/Reassociationで新しいCoAを予期するのは、通常可能ではありません。 例えば、DHCPサーバは以前に可動のノードに与えられなかったCoAを割り当てるかもしれません。 使用される、ダイナミックなVLAN課題、VLAN課題がそうでないときに、IEEE 802.1X認証がそうするまで決定して、完成していて、[IEEE-802.11i]のAssociation/Reassociationの後に、どれがありますか?
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
「モバイルIPのためのリンク特性の情報」[リー]では、リンクの特性は可動のノードによって家のエージェントと通信員ノードに送られた登録/拘束力があるUpdateメッセージに含まれています。 可動のノードが受信機として機能しているところでは、これで、通信員ノードはそうでなければ、可能であるかもしれないより急速に輸送パラメタウィンドウを調整できます。 伝えられるかもしれないリンクの特性は、リンク型(例えば、802.11b、CDMA(符号分割多重アクセス方式)、GPRS(汎用パケット無線システム)など)を含んで、帯域幅をリンクします。 ドキュメントが、通信員ノードが広告を出しているリンク帯域幅に基づく送付レートを調整するはずであると示唆する間、これはいくつかの事情で賢明でないかもしれません。 例えば、可動のノードリンクがボトルネックでないところでリンク帯域幅に基づく送付レートを調整すると、混雑は引き起こされる場合がありました。 また、各通信速度に関する登録メッセージを通信速度が頻繁に変化するところに送ります。
IAB Informational [Page 54] RFC 4907 Link Indications June 2007
IABの情報[54ページ]のRFC4907は指摘2007年6月にリンクします。
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.
変化自体は重要な帯域幅を消費するかもしれません。 広告を出しているリンクの特性が、より小さい混雑ウィンドウの必要性を示しさえするところで、可動のノードと通信員ノードの間でオープンな複数の接続があるところで個々の接続の送付速度を調整するのは重要であるかもしれません。 より保守的なアプローチはパラメタ再見積りと登録メッセージかBinding Updateの領収書に基づく遅れた出発の引き金となるだろうことです。
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]で、モバイルAd-hoc NETwork(マネ)ルーティング・プロトコルには最短パス測定基準を利用するので交通を集結して、キャッシュされたルートによる質問を発送するためにノードが応じるのを許容する傾向があることに注意されます。 作者は、臨時の無線電信に参加するノードが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-引き金の方法、作者は移管関連のパケット損失が混雑としてトランスポート層によって解釈されることに注意するところ」で。 通信員ノードが可動のノードに発信する場合では、通信員ノードによるBinding Updateの領収書が移管で誘発されたパケット損失のため減少したかもしれないcwndとssthresh値を調整するのに信号としてトランスポート層に使用されるよう提案されます。 作者は、リンクパラメータが変化したかどうかにかかわらずcwndとssthreshがプレタイムアウト値に回収されることを勧めます。 論文はBinding Updateを送る可動のノードの動きについて議論しません、可動のノードが通信員ノードに発信する場合で。
IAB Informational [Page 55] RFC 4907 Link Indications June 2007
IABの情報[55ページ]のRFC4907は指摘2007年6月にリンクします。
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.
「TCPに優しい速度制御のパフォーマンスへの垂直な身柄の引き渡しの効果」[Gurtov]では、作者は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が受信機にBinding Updateを通して送付者へのサブネット変化を伝えさせますが、これが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の間の垂直な移管のための効率的な移動性管理」[垂直な]では、作者は「事実上の接続性マネージャ」を提案します。(それは、終わりから終わりへの移動性を可能にして、垂直な身柄の引き渡しの間、TCPスループットを維持するために同時の運動を支持する市内接続翻訳(LCT)と購読/通知サービスを利用します)。
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-受信機はReset Congestion州オプションを送付者に送ります、まるで接続がやり直しているかのように。 ... 終点が、経路の混雑資産が変化したのを知っているとき、Reset Congestion州オプションはほんのわずかなケースのために控えられます。 現在、これは移動性に減少します: モバイルホストがアドレスか経路を変えた後にモバイルホストの上のDCCP終点は同輩への州をReset Congestionに送らなければなりません。
IAB Informational [Page 56] RFC 4907 Link Indications June 2007
IABの情報[56ページ]のRFC4907は指摘2007年6月にリンクします。
"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のための枠組みとRequirements」[TRIGTRAN]は、より早くインタフェースか介入しているリンクが下がっていた期間、被られた再送タイムアウトから回復するために最適化について議論します。 「終わらせる終わり、Implicit'上にリンクする'Notification」はフレームの損失のためリモートリンクに再送信タイマーを戻したTCP実現がリンクがもう一度操作上になったことを学ぶことができる方法を説明します[E2ELinkup]。 これは、「再-トランスミッション」が引き返している再送信タイマーの満了の前に試みられるのを可能にします。
"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.
「リンクレイヤTriggersプロトコル」[Yegin]は川下のAccess Pointsとルータに関するリンク状態のホスト認識の不足から起こる輸送問題について説明します。 リンクレイヤ引き金の輸送は、問題を記述するために提案されます。
"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.
「Immediate RetransmissionsのためのTCP Extensions」[エッゲルト]はトランスポート層実現がどう「終わりから終わりへの回復する接続性」既存の指摘を利用するかもしれないかを説明します。 定期的に予定されている「再-トランスミッション」に加えたその「再-トランスミッション」が同輩ノードへの接続性が回復したかもしれないという指示を受け取り次第トランスポート層によって試みられるよう提案されます。 終わりから終わりへの接続性回復指摘は同輩から「リンク」、最初に、ホップルータの可到達性の確認、インターネット層の構成、および他の交通の領収書の確認を含んでいます。
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.
「無線の損失と受信機でInterarrival回を使用することで混雑の損失を区別する」[Biaz]では、作者は相互到着時間に基づいて放送の損失と充血性の損失を区別することの計画を提案します。 損失が混雑、充血性のbackoff、および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
「ワイヤレス・ネットワークの上のTCPの性能を向上させる」[バクシ]では、作者はワイヤレス・ネットワークの上で炸裂の損失でTCPの性能に焦点を合わせます。 「良く」て「悪い」州を代表して、2州のマルコフモデルを利用して、作者はナノ秒-2の中でTCPタホの性能をシミュレートします。 州Notification(EBSN)は受信機に達することができないAccess Pointで発信しました。受信機が無線のリンクの上に接続されるところと、作者は、取り消された状態でEBSNに対応してそれが提唱されるという既存の再送信タイマーがあるExplicit Badの効果をシミュレートして、ダイナミックにaを新しく取り替えました。
IAB Informational [Page 57] RFC 4907 Link Indications June 2007
IABの情報[57ページ]のRFC4907は指摘2007年6月にリンクします。
estimated timeout, rather than being backed off. In the simulations, EBSN prevents unnecessary timeouts, decreasing RTT variance and improving throughput.
引き返すよりむしろおよそタイムアウト。 シミュレーションで、RTT変化を減少させて、スループットを改良して、EBSNは不要なタイムアウトを防ぎます。
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性能を向上させることのフィードバックベースの計画」[Chandran]では、作者は明白なRoute Failure Notification(RFN)を提案しました、受信機が手が届かなくなるとき、送付者が再送信タイマーを止めるのを許容して。 ルート再建に、タイマの凍結を解除して、Route Reestablishment Notification(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送付者に知らせるので、それは混雑のように続くパケット損失を扱う必要はありません。 Dynamic Sourceルート設定(DSR)プロトコルでルーティングを提供している802.11以上のTCPリノのナノ秒-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
彼らのELFN、背負われた作者の実現に関しては、既存の「ルートの故障」に関する追加情報(送付者と受信機アドレスとポート、TCP一連番号)に、送付者が影響を受ける接続を特定するのを可能にするために気付きます。 TCPがELFNを受けるところに、それは、再送信タイマーを損傷して、「予備」モードを入れます。そこでは、パケットが、ルートが回復したかどうか決定するために周期的な間隔で、送られます。 承認が受け取られているなら、再送信タイマーは返されます。 シミュレーションは、性能が徹底的調査間隔に敏感であることを示します、30秒以上の間隔がTCPリノより悪い性能を与えていて。 また、混雑ウィンドウとRTO値をリセットするという効果は調査されました。 研究では、混雑ウィンドウを1つにリセットするのはスループットへの効果の多くを持っていませんでした、ネットワークの帯域幅/遅れがほんのいくつかのパケットであったので。 しかしながら、高い初期の値(6秒)にRTOをリセットするのにおいて、かなりの有害な影響がありました、特に高速で。 送られた徹底的調査パケットに関して、シミュレーションは少しの違いを示しました。
IAB Informational [Page 58] RFC 4907 Link Indications June 2007
IABの情報[58ページ]のRFC4907は指摘2007年6月にリンクします。
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.
混雑ウィンドウで最初のパケットを送るか、または最も低い一連番号が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.
「無線のリンクの上のTCP性能を向上させる」[ゴエル]では、作者はトランスミッション試みの失敗で無線のAccess Pointによって送られたICMP-DEFERメッセージの使用を提案します。 「再-トランスミッション」試みの疲労困憊の後に、ICMP-RETRANSMITメッセージを送ります。 ICMP-DEFERメッセージを受け取り次第、再送信タイマーの満期は現在のRTO見積りで延期されます。 ICMP-RETRANSMITメッセージを受け取り次第、セグメントは再送されます。 「再-トランスミッション」では、混雑ウィンドウは減少しません。 速い回復から出て来るとき、混雑ウィンドウは速い「再-トランスミッション」と速い回復の前に値にリセットされます。 ナノ秒-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メカニズムの両方がナノ秒-2でシミュレートされました、さまざまなビット誤り率と交通状況の上でTCPリノとTCP SACKの両方を使用して。 1パケットあたりのETENメカニズムは混雑のないまた、混雑も存在していたTCP goodputの相当な利益を提供しましたが、利得は重要ではありませんでした。 また、累積している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 User Timeout OptionとTCP Retransmission引き金によるHost Identityプロトコル(HIP)[RFC4423]の使用を結合します、かなりの改善を示して。
IAB Informational [Page 59] RFC 4907 Link Indications June 2007
IABの情報[59ページ]のRFC4907は指摘2007年6月にリンクします。
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.
「IEEE802.11へのアプリケーション指向のリンク適合」[Haratcherev2]では、改良されたレート適合アルゴリズムを利用するリンクレイヤで発生するレート情報は、ビデオ・アプリケーションに提供されて、コーデック適合に使用されます。 リンクと応用層を結合すると、全面的な改良はNoise Ratio(PSNR)へのPeak Signalでもたらされます。 このアプローチが、リンクが経路ボトルネック帯域幅を表すと仮定するので、それはインターネットの上で使用するのにおいて一般に適切ではありません。
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.
応用層では、「リンクはダウンする」という指摘の用法が、存在システムを増大させるために提案されました。そのようなシステムでは、クライアント装置は、Instant MessagingのためのSIPとPresence Leveraging Extensions(SIMPLE)[RFC3428]かExtensible MessagingやPresenceプロトコル(XMPP)[RFC3921]などの応用層プロトコルを使用することでそれらの存在状態を定期的にリフレッシュします。 クライアントが外されるようになると、それらの使用不能は外に存在状態回数まで検出されないでしょう(何分もかかるかもしれません)。 しかしながら、リンクが落ちて、分離指示を存在サーバに送ることができるなら(おそらくAccess Pointで、どれが残っているかは接続しました)、ほとんど即座にユーザのコミュニケーションアプリケーションの状態をアップデートできます。
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 Loaアンデションブライアン大工レスリーDaigle ElwynデイヴィースケビンFallオラフ・Kolkmanカーティス・リンクヴィスト・デヴィッド・マイヤー・デヴィッド・オラン・エリック・レスコラ・デーヴ・ターレルLixiaチャン
IAB Informational [Page 60] RFC 4907 Link Indications June 2007
IABの情報[60ページ]のRFC4907は指摘2007年6月にリンクします。
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、6605Fax: +1 425 936 7329
IAB
IAB
EMail: iab@iab.org URI: http://www.iab.org/
メール: iab@iab.org ユリ: http://www.iab.org/
IAB Informational [Page 61] RFC 4907 Link Indications June 2007
IABの情報[61ページ]のRFC4907は指摘2007年6月にリンクします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
IAB Informational [Page 62]
IAB情報です。[62ページ]
一覧
スポンサーリンク
