RFC5184 日本語訳
5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven FastHandover. F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani. May 2008. (Format: TXT=64137 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Teraoka
Request for Comments: 5184 K. Gogo
Category: Experimental K. Mitsuya
R. Shibui
K. Mitani
KEIO University
May 2008
Teraokaがコメントのために要求するワーキンググループF.をネットワークでつないでください: 5184年のK.の精力的なカテゴリ: 実験的なK.の渋井K.Mitani慶応大学三屋R.2008年5月
Unified Layer 2 (L2) Abstractions
for Layer 3 (L3)-Driven Fast Handover
層の3(L3)の駆動速い引き渡しのための統一された層2(L2)の抽象化
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note
IESG注意
This document is not an IETF Internet Standard. It represents the consensus of the MOBOPTS Research Group of the Internet Research Task Force. It may be considered for standardization by the IETF in the future.
このドキュメントはIETFインターネットStandardではありません。 それはインターネットResearch Task ForceのMOBOPTS Research Groupのコンセンサスを表します。 それは将来、標準化のためにIETFによって考えられるかもしれません。
Abstract
要約
This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
このドキュメントはLayer3(L3)の駆動速い身柄の引き渡しのための統一されたLayer2(L2)抽象化を提案します。 効率的なネットワークコミュニケーションに関しては、プロトコル層が他の層の情報を知っているか、または利用するのが、重大です、L2引き金のフォームなどのように。 しかしながら、各プロトコル層は基本的に独自に設計されています。 また、各プロトコル層が現在のオペレーティングシステムで独自に実装されるので、プロトコル層の間で制御情報を非常に交換しにくいです。 このドキュメントは、問題を解決する手段としてネットワーク層における速い身柄の引き渡しを達成するために「基関数」の形で9種類のL2抽象化を定義します。 ネットワーク層が基関数を使用することによってL2とL3身柄の引き渡しを開始するので、このメカニズムは「L3駆動の速い身柄の引き渡し」と呼ばれます。 このドキュメントはIP Mobility Optimizations(MobOpts)研究Groupの製品です。
Teraoka, et al. Experimental [Page 1] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[1ページ]RFC5184L2抽象化
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Primitives for L2 Abstractions ..................................4
4. Definitions of Primitives .......................................6
4.1. L2-LinkStatus (Type 1) .....................................6
4.2. L2-PoAList (Type 1) ........................................6
4.3. L2-PoAFound (Type 2) .......................................6
4.4. L2-PoALost (Type 2) ........................................6
4.5. L2-LinkUp (Type 2) .........................................7
4.6. L2-LinkDown (Type 2) .......................................7
4.7. L2-LinkStatusChanged (Type 2) ..............................7
4.8. L2-LinkConnect (Type 3) ....................................7
4.9. L2-LinkDisconnect (Type 3) .................................8
5. Definitions of Static Parameters ................................8
5.1. Network Interface ID .......................................8
6. Definitions of Dynamic Parameters ...............................8
6.1. PoA (Point of Attachment) ..................................8
6.2. Condition ..................................................8
6.3. PoA List ...................................................9
6.4. Enable/Disable .............................................9
6.5. Ack/Error ..................................................9
7. Architectural Considerations ....................................9
8. Security Considerations ........................................13
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
Appendix A. Example Scenario ....................................16
Appendix B. Example Operation for FMIPv6 ........................17
B.1. Example Operation-1 for FMIPv6 ............................18
B.2. Example Operation-2 for FMIPv6 ............................20
B.3. Experiment ................................................21
Appendix C. Example Mapping between L2 Primitives and
Primitives in IEEE 802.11 and IEEE 802.16e ..........22
Appendix D. Example Mapping of Primitives and IEEE 802.11 .......24
D.1. L2-LinkStatus ............................................24
D.2. L2-PoAList ................................................24
D.3. L2-PoAFound ..............................................24
D.4. L2-PoALost ................................................25
D.5. L2-LinkUp ................................................25
D.6. L2-LinkDown ..............................................25
D.7. L2-LinkStatusChanged ......................................25
D.8. L2-LinkConnect ............................................26
D.9. L2-LinkDisconnect ........................................26
Appendix E. Implementation and Evaluation of the Proposed
Model ................................................26
1. 序論…3 2. 用語…3 3. L2抽象化のための基関数…4 4. 基関数の定義…6 4.1. L2-LinkStatus(1をタイプします)…6 4.2. L2-PoAList(1をタイプします)…6 4.3. L2-PoAFound(2をタイプします)…6 4.4. L2-PoALost(2をタイプします)…6 4.5. L2-結合(2をタイプします)…7 4.6. L2-LinkDown(2をタイプします)…7 4.7. L2-LinkStatusChanged(2をタイプします)…7 4.8. L2-LinkConnect(3をタイプします)…7 4.9. L2-LinkDisconnect(3をタイプします)…8 5. 静的なパラメタの定義…8 5.1. インタフェースIDをネットワークでつないでください…8 6. 動的パラメータの定義…8 6.1. PoA(接着点)…8 6.2. 条件とします。8 6.3. PoAは記載します…9 6.4. 可能にするか、または無効にします。9 6.5. Ack/誤り…9 7. 建築問題…9 8. セキュリティ問題…13 9. 承認…14 10. 参照…14 10.1. 標準の参照…14 10.2. 有益な参照…14付録A.例のシナリオ…16 FMIPv6のための付録B.例の操作…17 B.1。 FMIPv6のための例の操作-1…18 B.2。 FMIPv6のための例の操作-2…20 B.3。 実験してください…L2基関数の間の21付録C.例のマッピング、IEEE802.11の基関数、およびIEEE802.16e…基関数とIEEE802.11に関する22付録D.例のマッピング…24 D.1。 L2-LinkStatus…24 D.2。 L2-PoAList…24 D.3。 L2-PoAFound…24 D.4。 L2-PoALost…25 D.5。 L2-結合…25 D.6。 L2-LinkDown…25 D.7。 L2-LinkStatusChanged…25 D.8。 L2-LinkConnect…26 D.9。 L2-LinkDisconnect…提案の26の付録E.実装と評価はモデル化されます…26
Teraoka, et al. Experimental [Page 2] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[2ページ]RFC5184L2抽象化
1. Introduction
1. 序論
Recent years have witnessed the rapid proliferation of wireless networks as well as mobile devices accessing them. Unlike wired network environments, wireless networks are characterized by dynamically changing radio conditions, connectivity, and available bandwidth. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' control information. Mobile IPv4 [2] and Mobile IPv6 [3] have been standardized to support communication with mobile nodes. There are several proposals for seamless handovers in IPv6 networks, such as Fast Handovers for Mobile IPv6 (FMIPv6) [4] and Hierarchical Mobile IPv6 (HMIPv6) [5]. In FMIPv6, the network layer must know in advance the indication of a handover from the link layer to achieve seamless handovers. However, control information exchange between protocol layers is typically not available because each protocol layer is designed independently.
近年はそれらにアクセスするモバイル機器と同様にワイヤレス・ネットワークの急速増殖を目撃しました。 有線ネットワーク環境と異なって、ワイヤレス・ネットワークは、ダイナミックにラジオ状態、接続性、および利用可能な帯域幅を変えることによって、特徴付けられます。 効率的なネットワークコミュニケーションに関しては、プロトコル層が他の層の制御情報を知っているか、または利用するのが、重大です。 モバイルIPv4[2]とモバイルIPv6[3]は、モバイルノードとのコミュニケーションをサポートするために標準化されました。 IPv6ネットワークにはシームレスの身柄の引き渡しのためのいくつかの提案があります、モバイルIPv6(FMIPv6)[4]とHierarchicalのモバイルIPv6(HMIPv6)[5]のためのFast Handoversなどのように。 FMIPv6では、ネットワーク層は、あらかじめ、シームレスの身柄の引き渡しを達成するためにリンクレイヤから引き渡しのしるしを知らなければなりません。 しかしながら、各プロトコル層が独自に設計されているので、プロトコル層の間のコントロール情報交換は通常利用可能ではありません。
To solve the problem, this document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives.
問題を解決するなら、このドキュメントは、ネットワーク層における速い身柄の引き渡しを達成するために「基関数」の形で9種類のL2抽象化を定義します。 ネットワーク層が基関数を使用することによってL2とL3身柄の引き渡しを開始するので、このメカニズムは「L3駆動の速い身柄の引き渡し」と呼ばれます。
IEEE 802.21 [6] also defines several services that make use of L2 information. For the sake of ease of implementation and deployment, the primitives defined in this document make use of only the information available in the mobile node, while IEEE 802.21 [6] introduces the information server in the network to provide the mobile node with network-related information, such as a global network map.
また、IEEE802.21[6]はL2情報を利用するいくつかのサービスを定義します。 実装と展開の容易さのために、本書では定義された基関数はモバイルノードで利用可能な情報だけを利用します、IEEE802.21[6]がネットワーク関連の情報をモバイルノードに提供するためにネットワークにおける情報サーバを紹介しますが、世界的なネットワーク地図のように。
This document represents the consensus of the MobOpts Research Group. It has been reviewed by Research Group members active in the specific area of work.
このドキュメントはMobOpts Research Groupのコンセンサスを表します。 それは仕事の特定の領域で活発なResearch Groupメンバーによって見直されました。
2. Terminology
2. 用語
This document uses the following terms:
このドキュメントは次の用語を使用します:
L3-Driven Fast Handover
L3駆動の速い引き渡し
The handover mechanism that is initiated by the network layer on a
mobile node. Since this mechanism allows handover preparation in
L3 before the start of an L2 handover on the mobile node, it can
reduce packet loss during a handover. The L3-driven fast handover
mechanism requires L2 information as a trigger for a handover
procedure.
モバイルノードの上でネットワーク層によって開始される引き渡しメカニズム。 このメカニズムがモバイルノードにおけるL2引き渡しの始まりの前にL3で引き渡し準備を許すので、それは引き渡しの間、パケット損失を抑えることができます。L3駆動の速い引き渡しメカニズムは引き渡し手順のための引き金としてL2情報を必要とします。
Teraoka, et al. Experimental [Page 3] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[3ページ]RFC5184L2抽象化
PoA
PoA
The point of attachment of a mobile node (e.g., an access point in
IEEE 802.11 networks [7]).
モバイルノードの付属を指してください。(例えば、IEEE802.11ネットワーク[7])におけるアクセスポイント。
Primitive
原始
A unit of information that is sent from one layer to another.
There are four classes of primitives: Request, Confirm,
Indication, and Response. One or more classes of a primitive are
exchanged, depending on the type of primitive.
1から送られる情報のユニットは別のものに層にされます。 4つのクラスに関する基関数があります: 要求、確認、指示、および応答。 基関数のタイプに頼っていて、基関数の複数のクラスを交換します。
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 RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. Primitives for L2 Abstractions
3. L2抽象化のための基関数
Each layer offers its services in the form of primitives. Four classes of primitives are defined, as shown in Figure 1. Request is issued by the layer that wants to get the services or information from another layer, and Confirm is the acknowledgment of the request. Indication is the notification of the information to the layer that requested the service, and Response is the acknowledgment of the indication. In this architecture, communication between layers is symmetrical.
各層は基関数の形で奉仕を申し出ます。 4つのクラスに関する基関数は図1に示されるように定義されます。 要求は別のものからのサービスを得る必需品か情報が層にする層によって出されます、そして、Confirmは要求の承認です。 指示はサービスを要求した層への情報が通知です、そして、Responseは指示の承認です。 このアーキテクチャでは、層のコミュニケーションは対称です。
------------------------- -----------------------------
Request Response
|| /\ /\ ||
Layer N || || || ||
------------||------||--- -------||------||------------
|| || || ||
\/ || || \/
Layer N-m Confirm Indication
------------------------- -----------------------------
------------------------- ----------------------------- 応答を要求してください。|| /\ /\ || 層N|| || || || ------------||------||--- -------||------||------------ || || || || \/ || || \/層のN-mは指示を確認します。------------------------- -----------------------------
Figure 1: Interaction Model between Layers
図1: 層の間の相互作用モデル
The primitive consists of five fields: protocol layer ID, protocol ID, primitive class (Request, Response, Indication, or Confirm), primitive name, and parameters. The protocol layer ID specifies to which layer this primitive should be sent, e.g., Layer 2 or Layer 3. The protocol ID specifies to which protocol entity this primitive should be sent, e.g., IEEE 802.11 [7] or IEEE 802.3 [8].
原始は5つの分野から成ります: 層のID、プロトコルID、原始のクラス(要求、Response、Indication、またはConfirm)、原始の名前、およびパラメタについて議定書の中で述べてください。 IDプロトコル層が、この基関数がどの層に送られるべきであるかを指定して、例えば、Layerは2かLayer3です。 プロトコルIDが、この基関数がどのプロトコル実体に送られるべきであるかを指定して、例えば、IEEE802.11は[7]かIEEE802.3[8]です。
Teraoka, et al. Experimental [Page 4] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[4ページ]RFC5184L2抽象化
For unified L2 abstractions for L3-driven fast handovers, three different usages of primitives are defined, as described below:
L3駆動の速い身柄の引き渡しのための統一されたL2抽象化において、基関数の3つの異なった用法が以下で説明されるように定義されます:
Type 1. To provide L2 information to upper layers immediately
1をタイプしてください。 すぐに上側の層への情報をL2に供給するために
This type of primitive is used to provide the L2 information to
upper layers immediately. The Request and Confirm classes of
primitives MUST be exchanged for the interaction. The Request
primitive is for an acquisition request for the L2 information.
The Confirm primitive is for the answer.
原始のこのタイプは、すぐにL2情報を上側の層に供給するのに使用されます。 基関数のRequestとConfirmのクラスを相互作用と交換しなければなりません。 Request基関数はL2情報に関する獲得要求のためのものです。 Confirm基関数は答えのためのものです。
Type 2. To notify upper layers of L2 events asynchronously
2をタイプしてください。 上側の層のL2イベントに非同期に通知するために
This type of primitive is used to notify upper layers of L2 events
asynchronously. The Request, Confirm, and Indication classes of
primitive MUST be exchanged, and the Response class MAY be
exchanged for the interaction. The Request and Confirm primitives
are used just for registration. When an event occurs, the
Indication primitive is asynchronously delivered to the upper
layer.
原始のこのタイプは、上側の層のL2イベントに非同期に通知するのに使用されます。 原始のRequest、Confirm、およびIndicationのクラスを交換しなければなりません、そして、Responseのクラスを相互作用と交換するかもしれません。 RequestとConfirm基関数はまさしく登録に使用されます。 イベントが起こるとき、Indication基関数は上側の層に非同期に提供されます。
Type 3. To control L2 actions from upper layers
3をタイプしてください。 上側の層からL2動作を制御するために
This type of primitive is used to control L2 actions from upper
layers. The Request and Confirm classes of primitives MUST be
exchanged for the interaction. The Request primitive is a request
for operation. Ack or Nack returns immediately as the Confirm
primitive.
原始のこのタイプは、上側の層からL2動作を制御するのに使用されます。 基関数のRequestとConfirmのクラスを相互作用と交換しなければなりません。 操作を求めてRequest基関数は要求です。 AckかナックがすぐConfirmとして原始的に戻ります。
A protocol entity can register primitives anytime by exchanging the Request and Confirm messages that include the fields defined above. When the registered event occurs, the Indication and Response messages are exchanged as well.
プロトコル実体はいつでも上で定義された分野を含んでいるRequestを交換して、Confirmメッセージで基関数を登録できます。 登録されたイベントが起こるとき、また、IndicationとResponseメッセージを交換します。
The way to exchange a message between protocol entities is beyond the scope of this document. Any information-exchange method between layers, such as the work in [10], can be used.
プロトコル実体の間でメッセージを交換する方法はこのドキュメントの範囲を超えています。 [10]での仕事などの層の間のどんな情報交換メソッドも使用できます。
The timing for sending an Indication primitive is also beyond the scope of this document. For example, a layer 2 event is generated when layer 2 status has been changed, and this depends upon how scanning algorithms, for example, are implemented.
原始的にIndicationを送るタイミングはこのドキュメントの範囲を超えてもいます。 層の2状態を変えたとき、例えば、層の2イベントは発生しています、そして、これは例えばスキャンアルゴリズムがどう実装されるかによります。
Teraoka, et al. Experimental [Page 5] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[5ページ]RFC5184L2抽象化
4. Definitions of Primitives
4. 基関数の定義
To obtain and exchange L2 information, the following primitives are defined. Appendix C shows example mapping between the L2 primitives and the primitives in IEEE 802.11 [7] and IEEE 802.16e [9].
L2情報を得て、交換するために、以下の基関数は定義されます。 付録CはIEEE802.11[7]とIEEE 802.16e[9]にL2基関数と基関数の間の例のマッピングを示しています。
4.1. L2-LinkStatus (Type 1)
4.1. L2-LinkStatus(タイプ1)
The L2-LinkStatus.request primitive is sent to the link layer when an upper layer requires the current information of a link. The L2-LinkStatus.request primitive contains the "Network Interface ID" parameter (see Section 5.1). In response, the L2-LinkStatus.confirm primitive returns. The L2-LinkStatus.confirm primitive contains three parameters: "Network Interface ID", "PoA", and "Condition". "PoA" and "Condition" indicate the current status of the link between the mobile node and a PoA.
上側の層がリンクに関する現行情報を必要とするとき、L2-LinkStatus.request primitiveをリンクレイヤに送ります。 L2-LinkStatus.request primitiveは「ネットワーク・インターフェースID」パラメタを含んでいます(セクション5.1を見てください)。 応答では、L2-LinkStatus.confirm primitiveは戻ります。 L2-LinkStatus.confirm primitiveは3つのパラメタを含んでいます: 「ネットワーク・インターフェースID」、"PoA"、および「状態。」 "PoA"と「状態」はモバイルノードとPoAとのリンクの現在の状態を示します。
4.2. L2-PoAList (Type 1)
4.2. L2-PoAList(タイプ1)
The L2-PoAList.request primitive is sent to the link layer when an upper layer requires a list of the candidate PoAs. The L2-PoAList.request primitive contains the "Network Interface ID" parameter. In response, the L2-PoAList.confirm primitive returns the "Network Interface ID" parameter and the "PoA List" parameter. The "PoA List" parameter is a list of the candidate PoAs.
上側の層が候補PoAsのリストを必要とするとき、L2-PoAList.request primitiveをリンクレイヤに送ります。 L2-PoAList.request primitiveは「ネットワーク・インターフェースID」パラメタを含んでいます。 応答では、L2-PoAList.confirm primitiveは「ネットワーク・インターフェースID」パラメタと「PoAリスト」パラメタを返します。 「PoAリスト」パラメタは候補PoAsのリストです。
4.3. L2-PoAFound (Type 2)
4.3. L2-PoAFound(タイプ2)
The L2-PoAFound.indication primitive is asynchronously provided to an upper layer when new PoAs are detected. This primitive carries the "Network Interface ID" parameter and the "PoA List" parameter. The "PoA List" parameter contains information on new PoAs detected by the mobile node. In order to use this notification, the registration process using the L2-PoAFound.request primitive and the L2-PoAFound.confirm primitive is needed in advance. The L2-PoAFound.request primitive has two parameters: "Network Interface ID" and "Enable/Disable". The "Enable/Disable" parameter shows whether this notification function is turned on. When this registration succeeds, the L2-PoAFound.confirm primitive returns with the "Network Interface ID" parameter and the "Ack" parameter in response.
新しいPoAsを検出するとき、上側の層にL2-PoAFound.indication primitiveを非同期に提供します。 この基関数は「ネットワーク・インターフェースID」パラメタと「PoAリスト」パラメタを運びます。 「PoAリスト」パラメタはモバイルノードによって検出された新しいPoAsの情報を含んでいます。 この通知を使用するために、L2-PoAFound.request primitiveとL2-PoAFound.confirm primitiveを使用する登録手続があらかじめ、必要です。 L2-PoAFound.request primitiveには、2つのパラメタがあります: ネットワークはIDを連結します。「」 「可能にするか、または無効にします」。 この通知機能がつけられているか否かに関係なく、パラメタショーを「可能にするか、または無効にします」。 この登録が成功すると、L2-PoAFound.confirm primitiveは「ネットワーク・インターフェースID」パラメタと応答における"Ack"パラメタとともに帰ります。
4.4. L2-PoALost (Type 2)
4.4. L2-PoALost(タイプ2)
The L2-PoALost.indication primitive is asynchronously provided to an upper layer when a PoA included in the list of candidate PoAs disappears. This primitive carries the "Network Interface ID" parameter and the "PoA List" parameter. The "PoA List" parameter
候補PoAsのリストに含まれていたPoAが見えなくなるとき、上側の層にL2-PoALost.indication primitiveを非同期に提供します。 この基関数は「ネットワーク・インターフェースID」パラメタと「PoAリスト」パラメタを運びます。 「PoAリスト」パラメタ
Teraoka, et al. Experimental [Page 6] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[6ページ]RFC5184L2抽象化
contains information on the PoAs that disappeared from the list of candidates. The registration process using the L2-PoALost.request primitive and the L2-PoALost.confirm primitive is similar to the L2-PoAFound primitive described above.
候補のリストから見えなくなったPoAsの情報を含んでいます。 上で説明されて、L2-PoALost.request primitiveとL2-PoALost.confirm primitiveを使用する登録手続はL2-PoAFoundと原始的に同様です。
4.5. L2-LinkUp (Type 2)
4.5. L2-結合(タイプ2)
The L2-LinkUp.indication primitive is asynchronously provided to an upper layer when a new link is connected and IP packets can be transmitted through the new link. As described in RFC 4957 [12], what "link is connected" means depends on link types. For example, in case of the infrastructure mode in IEEE 802.11 [7] (WiFi), this primitive is provided when an association to an access point is established. This primitive carries the "Network Interface ID" parameter and the "PoA" parameter. The L2-LinkUp.request primitive contains the "Network Interface ID" parameter and the "Enable/Disable" parameter for registration. When the registration succeeds, the L2-LinkUp.confirm primitive with the "Network Interface ID" parameter and the "Ack" parameter returns.
新しいリンクが接続されていて、新しいリンクを通してIPパケットを伝えることができるとき、上側の層にL2-LinkUp.indication primitiveを非同期に提供します。 RFC4957[12]で説明されるように、「リンクは接続されていること」が意味することがリンク型に頼っています。 アクセスポイントへの協会を設立するとき、例えば、IEEE802.11[7](WiFi)のインフラストラクチャモードの場合に、この基関数を提供します。 この基関数は「ネットワーク・インターフェースID」パラメタと"PoA"パラメタを運びます。 そして、L2-LinkUp.request primitiveが「ネットワーク・インターフェースID」パラメタを含んでいる、登録のためにパラメタを「可能にするか、または無効にします」。 登録が成功すると、「ネットワーク・インターフェースID」パラメタと"Ack"パラメタがあるL2-LinkUp.confirm primitiveは戻ります。
4.6. L2-LinkDown (Type 2)
4.6. L2-LinkDown(タイプ2)
The L2-LinkDown.indication primitive is asynchronously provided to an upper layer when an existing link is disconnected and IP packets cannot be transmitted through the link. The registration processing is the same as the L2-LinkUp primitive described above.
既存のリンクから切断して、リンクを通してIPパケットを伝えることができないとき、上側の層にL2-LinkDown.indication primitiveを非同期に提供します。 登録処理はL2-LinkUp基関数が上で説明したのと同じです。
4.7. L2-LinkStatusChanged (Type 2)
4.7. L2-LinkStatusChanged(タイプ2)
The L2-LinkStatusChanged.indication primitive is asynchronously provided to an upper layer when the status of a link has changed. This notification contains three parameters: "Network Interface ID", "PoA", and "Condition". The "PoA" parameter indicates the attachment point at which the link quality changed. In the registration processing, the L2-LinkStatusChanged.request primitive carries the "Network Interface ID" parameter, the "Enable/Disable" parameter, and the "Condition" parameter. "Condition" indicates the event type and the threshold for the Indication.
リンクの状態が変化したとき、上側の層にL2-LinkStatusChanged.indication primitiveを非同期に提供します。 この通知は3つのパラメタを含んでいます: 「ネットワーク・インターフェースID」、"PoA"、および「状態。」 "PoA"パラメタはリンク品質が変化した付着点を示します。 登録処理では、L2-LinkStatusChanged.request primitiveが「ネットワーク・インターフェースID」パラメタを運ぶ、パラメタ、および「状態」パラメタを「可能にするか、または無効にします」。 「状態」はIndicationのためにイベントタイプと敷居を示します。
4.8. L2-LinkConnect (Type 3)
4.8. L2-LinkConnect(タイプ3)
The L2-LinkConnect.request primitive is sent to the link layer when an upper layer has to establish a new link to the specific "PoA". This primitive carries the "Network Interface ID" parameter and the "PoA" parameter. This operation begins after the link layer returns the L2-LinkConnect.confirm primitive with "Ack".
上側の層が特定の"PoA"への新しいリンクを設立しなければならないとき、L2-LinkConnect.request primitiveをリンクレイヤに送ります。 この基関数は「ネットワーク・インターフェースID」パラメタと"PoA"パラメタを運びます。 リンクレイヤが"Ack"があるL2-LinkConnect.confirm primitiveを返した後にこの操作は始まります。
Teraoka, et al. Experimental [Page 7] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[7ページ]RFC5184L2抽象化
4.9. L2-LinkDisconnect (Type 3)
4.9. L2-LinkDisconnect(タイプ3)
The L2-LinkDisconnect.request primitive is sent to the link layer when an upper layer has to tear down an existing link to the specific "PoA". This primitive carries the "Network Interface ID" parameter and the "PoA" parameter. This operation begins after the link layer returns the L2-LinkDisconnect.confirm primitive with "Ack".
上側の層が特定の"PoA"への既存のリンクを取りこわさなければならないとき、L2-LinkDisconnect.request primitiveをリンクレイヤに送ります。 この基関数は「ネットワーク・インターフェースID」パラメタと"PoA"パラメタを運びます。 リンクレイヤが"Ack"があるL2-LinkDisconnect.confirm primitiveを返した後にこの操作は始まります。
5. Definitions of Static Parameters
5. 静的なパラメタの定義
This section lists static parameters. Once the values of static parameters are configured, they basically remain unchanged during communication. The following parameters are transferred as a part of primitives.
このセクションは静的なパラメタをリストアップします。 静的なパラメタの値がいったん構成されると、それらはコミュニケーションの間、基本的に変わりがありません。 基関数の一部として以下のパラメタを移します。
5.1. Network Interface ID
5.1. ネットワーク・インターフェースID
The "Network Interface ID" parameter uniquely identifies the network interface in the node. The syntax of the identifier is implementation-specific (e.g., name, index, or unique address assigned to each interface). This parameter also contains the network interface type that indicates the kind of technology of the network interface (e.g., IEEE 802.11a/b/g [7], Third Generation Partnership Project (3GPP), etc.). This parameter is required in all primitives.
「ネットワーク・インターフェースID」パラメタは唯一ノードのネットワーク・インターフェースを特定します。 識別子の構文は実装特有です(各インタフェースに割り当てられた例えば、名前、インデックス、またはユニークなアドレス)。 また、このパラメタはネットワーク・インターフェース(例えば、IEEE 802.11a/b/g[7]、Third Generation Partnership Project(3GPP)など)の技術の種類を示すネットワークインターフェース型を含みます。 このパラメタがすべての基関数で必要です。
6. Definitions of Dynamic Parameters
6. 動的パラメータの定義
This section lists dynamic parameters. The values of dynamic parameters change frequently during communication. The following parameters are transferred as a part of primitives.
このセクションは動的パラメータをリストアップします。 動的パラメータの値はコミュニケーションの間、頻繁に変化します。 基関数の一部として以下のパラメタを移します。
6.1. PoA (Point of Attachment)
6.1. PoA(接着点)
The "PoA" parameter uniquely identifies the PoA.
"PoA"パラメタは唯一PoAを特定します。
6.2. Condition
6.2. 状態
The "Condition" parameter consists of the following sub-parameters: available bandwidth and link quality level. These sub-parameters are the abstracted information that indicates the current quality of service. The abstraction algorithms of sub-parameters depend on hardware devices and software implementation. The useful range of link quality is divided into five levels: EXCELLENT, GOOD, FAIR, BAD, and NONE, in descending order. The quality levels of an L2 device
「状態」パラメタは以下のサブパラメタから成ります: 利用可能な帯域幅とリンク品質水準。 これらのサブパラメタは現在のサービスの質を示す放心している情報です。 サブパラメタの抽象化アルゴリズムはハードウェアデバイスとソフトウェア実行によります。 リンク品質の有効範囲は5つのレベルに分割されます: 降順でEXCELLENT、GOOD、FAIR、BAD、およびNONE。 L2デバイスの品質水準
Teraoka, et al. Experimental [Page 8] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[8ページ]RFC5184L2抽象化
are independent of those of other devices. However, making decisions based on these metrics is error prone and not guaranteed to result in an optimal choice of links. An example of the thresholds among the five levels in IEEE 802.11 [7] is described in Appendix E.
対向機器のものの如何にかかわらず、あります。 しかしながら、これらの測定基準に基づく決定をするのは、誤り傾向があって、リンクの最適選択をもたらすために保証されません。 IEEE802.11[7]の5つのレベルの中の敷居に関する例はAppendix Eで説明されます。
6.3. PoA List
6.3. PoAリスト
The "PoA List" parameter consists of arbitrary couples of two sub-parameters: "PoA" and "Condition". This parameter shows a list of PoAs and their conditions.
「PoAリスト」パラメタは2つのサブパラメタの任意のカップルから成ります: "PoA"と「状態。」 このパラメタはPoAsのリストと彼らの状態を示しています。
6.4. Enable/Disable
6.4. 可能にするか、または無効にします。
The "Enable/Disable" flag is used for turning event notification on/ off. When an upper layer needs notifications, the Request primitive with "Enable" is sent to the link layer as registration. When an upper layer needs no more notifications, the Request primitive with "Disable" is sent.
イベント通知をオンであるかオフにターンするために使用される旗を「可能にするか、または無効にします」。 上側の層が通知を必要とするとき、登録として「可能にすること」による原始のRequestをリンクレイヤに送ります。 上側の層がそれ以上の通知を全く必要としないとき、「無効にすること」による原始のRequestを送ります。
6.5. Ack/Error
6.5. Ack/誤り
When an upper layer requests some notifications, the link layer receives and confirms this Request. If the Request is valid, the Confirm primitive with "Ack" is sent to the upper layer. If it is invalid, the Confirm with "Error" is sent to the upper layer.
上側の層がいくつかの通知を要求するとき、リンクレイヤは、このRequestを受けて、確認します。 Requestが有効であるなら、"Ack"に伴う原始のConfirmを上側の層に送ります。 それが無効であるなら、「誤り」があるConfirmを上側の層に送ります。
7. Architectural Considerations
7. 建築問題
RFC 4907 [11] discusses the role and the issues of link indications within the Internet Architecture. This section discusses the architectural considerations mentioned in Section 2 of RFC 4907.
[11]が役割と問題について議論するRFC4907年はインターネットArchitectureの中で指摘をリンクします。 このセクションはRFC4907のセクション2で言及された建築問題について論じます。
1. Proposals should avoid use of simplified link models in
circumstances where they do not apply.
1. 提案はそれらが適用しない事情における簡易型のリンクモデルの使用を避けるべきです。
The information in each layer should be abstracted before it is
sent to another layer. For example, in IEEE 802.11 [7], the
Received Signal Strength Indicator (RSSI), the number of
retransmissions, and the existence of association between the
mobile node and the access point are used so that the link
layer indications can adjust themselves to various environments
or situations. The thresholds needed for some link indications
are defined from empirical study.
別の層にそれを送る前に各層の情報を抜き取るべきです。 例えば、IEEE802.11[7]では、モバイルノードとアクセスポイントの間のReceived Signal Strength Indicator(RSSI)、「再-トランスミッション」の数、および協会の存在は、リンクレイヤ指摘が様々な環境か状況に順応できるように、使用されています。 いくつかのリンク指摘に必要である敷居は実証的研究から定義されます。
In the conventional protocol-layering model, the Protocol
Entity (PE) is defined as the entity that processes a specific
protocol. Our proposal introduced the Abstract Entity (AE) to
従来のプロトコルを層にするモデルでは、プロトコルEntity(PE)は特定のプロトコルを処理する実体と定義されます。 私たちの提案は抽象的なEntity(AE)を紹介しました。
Teraoka, et al. Experimental [Page 9] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[9ページ]RFC5184L2抽象化
achieve link independency of the link indications. An AE and a
PE make a pair. An AE abstracts the PE-dependent information
to the PE-independent information.
リンク指摘のリンク独立性を達成してください。 AEとPEは対になります。 AEはPEから独立している情報にPE依存する情報を抜き取ります。
Figure 2 shows AEs and PEs using primitives.
図2は、基関数を使用することでAEsとPEsを示しています。
2. Link indications should be clearly defined, so that it is
understood when they are generated on different link layers.
2. リンク指摘が明確に定義されるべきであるので、それらがいつ異なったリンクの上に生成されるかが層にされるのが理解されています。
To make the link information/indications clear, our proposal
defines the 4 types of primitives: Request/Confirm and
Indication/Response, as described in Section 3. The Request is
used to obtain the information of another layer. The Confirm
is the reply to the request and it includes the requested
information. The Indication is generated when a particular
event occurs. The Response is the reply to the indication.
リンク情報/指摘を明らかにするために、私たちの提案は4つのタイプに関する基関数を定義します: 中の/が確認する要求と説明されるとしてのIndication/応答、セクション3 Requestは、別の層の情報を得るのに使用されます。 Confirmは要求に関する回答です、そして、それは求められた情報を含めます。 特定のイベントが起こるとき、Indicationは発生しています。 Responseは指示に関する回答です。
In our proposal on IEEE 802.11b [7], L2-LinkUp is defined as
the status in which an association to the Access Point (AP) is
established, and L2-LinkDown is defined as the status in which
an association to the AP is not established.
L2-LinkStatusChanged is generated when the link quality goes
below the predefined threshold. Since the Received Signal
Strength Indicator (RSSI) and the number of retransmissions are
used to abstract and evaluate the link quality, L2-
LinkStatusChanged represents the link quality in both
directions. It should use an average of the RSSI or the number
of retransmissions damped for one second or more to cope with
transient link conditions.
IEEE 802.11b[7]における私たちの提案では、L2-LinkUpはAccess Point(AP)への協会が設立される状態と定義されます、そして、L2-LinkDownはAPへの協会が設立されない状態と定義されます。 リンク品質が事前に定義された敷居を下に降りさせるとき、L2-LinkStatusChangedは発生しています。 Received Signal Strength Indicator(RSSI)と「再-トランスミッション」の数が要約に使用されて、リンク品質を評価するので、L2LinkStatusChangedはリンク品質を両方の方向に表します。 それは一時的なリンク状態に対処するために1秒以上間じめじめとした平均にRSSIか「再-トランスミッション」の数を使用するべきです。
3. Proposals must demonstrate robustness against misleading
indications.
3. 提案は紛らわしい指摘に対して丈夫さを示さなければなりません。
Since RSSI changes significantly even when the mobile node
stands still according to the measurements in our experiments,
our proposal uses the RSSI, the number of retransmissions, and
the existence of an association to calculate the link status,
as described above. In our experiments, there were some
"ping-pong" handovers between two APs. Such ping-pong
handovers could be reduced by detecting the most suitable AP by
L2-LinkStatus when L2-LinkStatusChanged is notified. The use
of L2 indications is related to parameter thresholds that
trigger handover. These thresholds vary based on the
deployment scenario and, if not configured properly, could lead
to misleading indications.
RSSIが、私たちの実験における測定値によると、可動のノードがいつ静止してさえいるかをかなり変えるので、私たちの提案はRSSI、「再-トランスミッション」の数、およびリンク状態について計算する協会の存在を使用します、上で説明されるように。 私たちの実験には、2APsの間には、いくつかの「ピンポン」身柄の引き渡しがありました。 L2-LinkStatusChangedが通知されるときL2-LinkStatusで最も適当なAPを検出することによって、そのようなピンポン身柄の引き渡しを抑えることができるでしょう。 L2指摘の使用は引き渡しの引き金となるパラメタ敷居に関連します。これらの敷居は、展開シナリオに基づいて異なって、適切に構成されないなら、紛らわしい指摘につながるかもしれません。
Teraoka, et al. Experimental [Page 10] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[10ページ]RFC5184L2抽象化
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.
4. 上側の層は、それらが影響された後に無効であることを決定しているリンク指摘から可能性のあるダメージを制限するのにタイムリーな回復ステップを利用するはずです。
The proposed L3-driven handover described in Appendix E uses
the L2-LinkStatusChanged indication as the trigger for starting
handover. L2-LinkStatusChanged is indicated when the link
quality goes below a specific threshold. This indication is
not canceled even if the link quality goes up soon. As
described above, L2-LinkStatus can be used to detect the most
suitable AP. The IP layer can cancel a handover if it finds
that the current AP is the most suitable one by using
L2-LinkStatus when L2-LinkStatusChanged is notified.
Appendix Eで説明された提案されたL3駆動の引き渡しはリンク品質が特定の敷居を下に降りさせるときの始めの引き渡しL2-LinkStatusChangedのための引き金が示されるようなL2-LinkStatusChanged指示を使用します。 リンク品質がすぐ上がっても、この指示は中止されません。 上で説明されるように、最も適当なAPを検出するのにL2-LinkStatusを使用できます。 現在のAPがL2-LinkStatusChangedが通知されるときL2-LinkStatusを使用することによって最も適当なものであることがわかるなら、IP層は引き渡しを中止できます。
5. Proposals must demonstrate that effective congestion control is
maintained.
5. 提案は、有効な輻輳制御が維持されるのを示さなければなりません。
Since this mechanism is coupled to the IP layer, and not
directly to the transport layer, the proposed mechanism does
not directly affect congestion control.
このメカニズムが直接トランスポート層ではなく、IP層と結合されるので、提案されたメカニズムは直接輻輳制御に影響しません。
6. Proposals must demonstrate the effectiveness of proposed
optimizations.
6. 提案は提案された最適化の有効性を示さなければなりません。
In IPv6 mobility, the L3-driven handover mechanism using link
indications can dramatically reduce gap time due to handover.
The L3-driven handover mechanism needs the L2-LinkStatusChanged
indication to predict disconnection. But L2-LinkStatusChanged
is not trusted sometimes because it is difficult to abstract
the link quality. Invalid L2-LinkStatusChanged may cause
redundant handover. A handover mechanism using only L2-LinkUp/
L2-LinkDown can also reduce gap time modestly. An example of
an implementation and evaluation of the L3-driven handover
mechanism is described in Appendix E.
IPv6の移動性では、リンク指摘を使用するL3駆動の引き渡しメカニズムは引き渡しのためギャップ時間を劇的に短縮できます。L3駆動の引き渡しメカニズムは、断線を予測するためにL2-LinkStatusChanged指示を必要とします。 しかし、時々リンク品質を抜き取るのが難しいので、L2-LinkStatusChangedは信じられません。 無効のL2-LinkStatusChangedは余分な引き渡しを引き起こすかもしれません。また、L2-LinkUp/ L2-LinkDownだけを使用する引き渡しメカニズムは遠慮深くギャップ時間を短縮できます。 実現に関する例とL3駆動の引き渡しメカニズムの評価はAppendix Eで説明されます。
7. Link indications should not be required by upper layers in
order to maintain link independence.
7. 上側の層は、リンク独立を維持するためにリンク指摘を必要とするはずがありません。
Our proposal does not require any modifications to the
transport and upper layers.
私たちの提案は輸送と上側の層への少しの変更も必要としません。
8. Proposals should avoid race conditions, which can occur where
link indications are utilized directly by multiple layers of
the stack.
8. 提案は競合条件を避けるべきです。(競合条件はリンク指摘が直接スタックの複数の層によって利用されるところに起こることができます)。
Since our proposal defines the link indications only to the IP
layer, race conditions between multiple layers never occur.
私たちの提案がリンク指摘をIP層だけと定義するので、複数の層の間の競合条件は決して起こりません。
Teraoka, et al. Experimental [Page 11] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[11ページ]RFC5184L2抽象化
9. Proposals should avoid inconsistencies between link and routing
layer metrics.
9. 提案はリンクとルーティング層の測定基準の間で矛盾を避けるべきです。
Our proposal does not deal with routing metrics.
私たちの提案はルーティング測定基準に対処しません。
10. Overhead reduction schemes must avoid compromising
interoperability and introducing link-layer dependencies into
the Internet and transport layers.
10. 頭上の減少計画は相互運用性で妥協して、インターネットとトランスポート層にリンクレイヤの依存を取り入れるのを避けなければなりません。
As described above, the link indications in our proposal are
abstracted to the information independent of link types to
reduce the gap time due to a handover, and the ordinary host
can execute handover without using the link indications defined
in our proposal.
上で説明されるように、私たちの提案におけるリンク指摘は引き渡しのためギャップ時間を短縮するので、リンク型の如何にかかわらず情報に抜き取られています、そして、私たちの提案で定義されたリンク指摘を使用しないで、普通のホストは引き渡しを実行できます。
11. Proposals advocating the transport of link indications beyond
the local host need to carefully consider the layering,
security, and transport implications. In general, implicit
signals are preferred to explicit transport of link indications
since they add no new packets in times of network distress,
operate more reliably in the presence of middle boxes, such as
NA(P)Ts (Network Address (Port) Translations), are more likely
to be backward compatible, and are less likely to result in
security vulnerabilities.
11. ローカル・ホストを超えてリンク指摘の輸送を支持する提案は、慎重にレイヤリング、セキュリティ、および輸送含意を考える必要があります。 一般に、ネットワーク苦悩の時代にどんな新しいパケットも加えないで、内在している信号はリンク指摘の明白な輸送より好まれます、そして、おそらく後方である以上は互換性があります、そして、中央箱があるときより確かに作動してください、NA(P)t(ネットワークAddress(ポート)翻訳)などのように以下はセキュリティの脆弱性をもたらしそうですか?
Our proposal does not define the exchange of link indications
between nodes.
私たちの提案はノードの間のリンク指摘の交換を定義しません。
Teraoka, et al. Experimental [Page 12] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[12ページ]RFC5184L2抽象化
---------------------------------------------------------
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N || /\ || /\
------------||---||-------------------||---||------------
Request|| || Response|| ||
|| || || ||
|| || || ||
|| ||Confirm || ||Indication
------------||---||-------------------||---||------------
\/ || \/ ||
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N-m
---------------------------------------------------------
--------------------------------------------------------- ----------=========== ----------=========== | |[ ] | |[ ] | PE|[AE]| PE|[AE]| |[ ] | |[ ] ----------=========== ----------=========== 層N|| /\ || /\ ------------||---||-------------------||---||------------ 要求|| || 応答|| || || || || || || || || || || ||確認します。|| ||指示------------||---||-------------------||---||------------ \/ || \/ || ----------=========== ----------=========== | |[ ] | |[ ] | PE|[AE]| PE|[AE]| |[ ] | |[ ] ----------=========== ----------=========== 層のN-m---------------------------------------------------------
Figure 2: AE and PE with Primitives
図2: 基関数があるAEとPE
8. Security Considerations
8. セキュリティ問題
RFC 4907 [11] discusses the role and issues of link indications within the Internet Architecture. This section discusses the security considerations mentioned in Section 4 of RFC 4907.
[11]が役割と問題について議論するRFC4907年はインターネットArchitectureの中で指摘をリンクします。 このセクションはRFC4907のセクション4で言及されたセキュリティ問題について論じます。
1. Spoofing
1. スプーフィング
The proposed primitives suffer from spoofed link-layer control
frames. For example, if a malicious access point is set up and
spoofed beacon frames are transmitted, L2-PoAFound.indication
is generated in the mobile node. As a result, the mobile node
may establish an association with the malicious access point by
an L2-LinkConnect.request.
提案された基関数はだまされたリンクレイヤ制御フレームが欠点です。 例えば、悪意があるアクセスポイントがセットアップされて、だまされた標識フレームが伝えられるなら、L2-PoAFound.indicationは可動のノードで発生します。 その結果、可動のノードはL2-LinkConnect.requestで悪意があるアクセスポイントとの協会を設立するかもしれません。
2. Indication validation
2. 指示合法化
Transportation of the link indications between nodes is not
assumed; hence, this consideration is beyond the scope of our
proposal.
ノードの間のリンク指摘の輸送は想定されません。 したがって、この考慮は私たちの提案の範囲を超えています。
Teraoka, et al. Experimental [Page 13] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[13ページ]RFC5184L2抽象化
3. Denial of service
3. サービスの否定
Since this proposal does not change link-layer protocols, no
more insecurity is added to a particular link-layer protocol.
However, the proposed primitives suffer from denial-of-service
attacks by spoofed link-layer frames. For example, L2-
PoAFound.indication and L2-PoALost.indication may frequently be
generated alternately if a malicious access point frequently
transmits control frames that indicate strong RSSI and weak
RSSI alternately.
この提案がリンク層プロトコルを変えないので、それ以上の不安定は全く特定のリンク層プロトコルに追加されません。 しかしながら、提案された基関数はだまされたリンクレイヤフレームのそばでサービス不能攻撃に苦しみます。 例えば、悪意があるアクセスポイントが頻繁に制御フレームを伝えるなら、交互に強いRSSIと弱いRSSIを示すL2PoAFound.indicationとL2-PoALost.indicationは頻繁に交互に発生するかもしれません。
9. Acknowledgements
9. 承認
The authors gratefully acknowledge the contributions of Jukka Manner, Christian Vogt, and John Levine for their review.
作者は彼らのレビューのために感謝してユッカManner、クリスチャンのフォークト、およびジョン・レヴィンの貢献を承諾します。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[2] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[2] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[4] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[4]Koodli、R.、エド、「速く、モバイルIPv6"、RFC4068、2005年7月に、引き渡します」。
[5] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
[5] ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。
[6] "Draft IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE P802.21/D02.00,
September 2006.
[6] 「地方とメトロポリタンエリアネットワークのIEEE規格を作成してください」 「独立している引き渡しが修理するメディア」、IEEE P802.21/D02.00、2006年9月。
[7] IEEE, "802.11-2007 IEEE Standard for LAN/MAN - Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications", 2007.
[7] IEEE、「LAN/MANのための802.11-2007IEEE Standard--決められた一定の要求Part11:、」 「無線のLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、2007。
Teraoka, et al. Experimental [Page 14] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[14ページ]RFC5184L2抽象化
[8] IEEE, "802.3, 2000 EDITION ISO/IEC 8802-3:2000 (E) Information
Technology - LAN/MAN - Part 3: Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) Access Method and Physical
Layer Specifications", 2000.
[8] IEEE、「802.3 2000版のISO/IEC8802-3: (2000(E)情報技術(LAN/男性))は3を分けます」。 「衝突検出型搬送波検知多重アクセス(CSMA/CD)は方法と物理的な層の仕様にアクセスする」2000。
[9] IEEE, "802.16e-2005 & 802.16/COR1 Part 16: Amendment for
Physical & Medium Access Control Layers for Combined Fixed &
Mobile Operation", 2006.
[9] IEEE、「802.16e-2005と802.16/COR1は16を分けます」。 「結合した修理されてモバイルの操作のための物理的で中型のアクセス管理層のための修正」、2006。
[10] Gogo, K., Shibu, R., and F. Teraoka, "An L3-Driven Fast Handover
Mechanism in IPv6 Mobility", In Proc. of International Symposium
on Applications and the Internet (SAINT2006) Workshop in IPv6,
February 2006.
[10] 精力的です、K.、渋、R.、およびF.Teraoka、「L3駆動の断食はIPv6の移動性でメカニズムを引き渡します」、Procで。. アプリケーションでの国際シンポジウムとIPv6、2006年2月のインターネット(SAINT2006)ワークショップについて。
[11] Aboba, B., Ed., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
[11]Aboba、B.、エド、「リンク指摘の建築含意」、RFC4907、6月2007日
[12] Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, Ed., "Link-Layer Event Notifications for Detecting
Network Attachments", RFC 4957, August 2007.
そして、[12] クリシュナン、S.(エド)、Montavont、N.、Njedjou、E.、Veerepalli、S.、A.Yegin(エド)、「検出のためのリンクレイヤイベント通知は付属をネットワークでつなぎます」、RFC4957、2007年8月。
[13] Ishiyama, M., Kunishi, M., Uehara, K., Esaki, H., and F.
Teraoka, "LINA: A New Approach to Mobility Support in Wide Area
Networks", IEICE Transactions on Communication vol. E84-B, no.
8, pp. 2076-2086, August 2001.
[13] 石山、M.、Kunishi、M.、Uehara、K.、江崎、H.、およびF.Teraoka、「リーナ:」 「ワイドエリアネットワークにおけるMobility SupportへのNew Approach」、Communication vol.E84-B、No.8、ページのIEICE Transactions 2076-2086と、2001年8月。
Teraoka, et al. Experimental [Page 15] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[15ページ]RFC5184L2抽象化
Appendix A. Example Scenario
付録A.例のシナリオ
For example, the picture below shows L3-driven fast handover mechanism using the L2 triggers on a mobile node (MN).
可動のノードの上で(ミネソタ)の引き金となります例えば、以下の絵が、L2を使用するL3駆動の速い引き渡しメカニズムを示している。
L2 L3
| |
|<----------LinkUP.req-----------|
|-----------LinkUP.cnf---------->|
|<-----LinkStatusChanged.req-----|
|------LinkStatusChanged.cnf---->|
= =
| |
Low |
Signal---LinkStatusChanged.ind---->|
| |
|<----------PoAList.req----------|
|-----------PoAList.cnf------>Handover
| Preparation
|<-------LinkConnect.req---------|
L2 Handover--LinkConnect.cnf-------->:
: :
: :
finish---------LinkUp.ind----->L3 Handover
| finish
| |
L2 L3| | | <、-、-、-、-、-、-、-、-、--LinkUP.req-----------| |-----------LinkUP.cnf---------->| | <、-、-、-、--LinkStatusChanged.req-----| |------LinkStatusChanged.cnf---->| = = | | 安値| 信号---LinkStatusChanged.ind---->|、|、| | <、-、-、-、-、-、-、-、-、--PoAList.req----------| |-----------PoAList.cnf------>引き渡し| 準備| <、-、-、-、-、-、--LinkConnect.req---------| L2引き渡し--LinkConnect.cnf-------->: : : : : 終わり---------LinkUp.ind----->L3引き渡し| 終わり| |
L2: Link Layer on MN
L3: Network Layer on MN
req: Request
cnf: Confirm
ind: Indication
L2: Mn L3の上のリンクレイヤ: ミネソタreqにLayerをネットワークでつないでください: cnfを要求してください: indを確認してください: 指示
Figure 3: L3-Driven Fast Handover Mechanism
図3: L3駆動の速い引き渡しメカニズム
First, L3 issues LinkUp.request to receive LinkUp.indication when the link becomes available. L3 also issues LinkStatusChanged.request to receive LinkStatusChanged.indication when the link quality goes below the threshold.
まず最初に、リンクが利用可能になると、L3は、LinkUp.indicationを受け取るためにLinkUp.requestを発行します。 また、L3は、リンク品質が敷居を下に降りさせるとき、LinkStatusChanged.indicationを受け取るためにLinkStatusChanged.requestを発行します。
In the beginning of the L3-driven handover procedure, L2 detects that the radio signal strength is going down. Then, L2 sends L2-LinkStatusChanged.indication to L3. L3 prepares for handover (e.g., Care-of Address (CoA) generation, Duplicate Address Detection (DAD), Neighbor Discovery (ND) cache creation, and routing table setting) and sends L2-PoAList.request to L2 if the list of access points is needed.
初めに、L3駆動の引き渡し手順では、L2はそれを検出します。ラジオ信号強度は落ちています。 そして、L2はL2-LinkStatusChanged.indicationをL3に送ります。 L3が引き渡しの用意をする、(例えば、Care、-、Duplicate Address Detection(DAD)、Neighborディスカバリー(ノースダコタ)が、創造をキャッシュして、テーブルの設定を発送することでのAddress(CoA)世代、アクセスポイントのリストが必要であるなら、L2-PoAList.requestをL2に送ります。
Teraoka, et al. Experimental [Page 16] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[16ページ]RFC5184L2抽象化
If L3 decides to perform handover according to some rules, L3 sends L2-LinkConnect.request with some parameters about candidate access points to request L2 handover. L2 handover begins after L2 sends L2-LinkConnect.confirm to L3. When the L2 handover finishes, L2 sends L2-LinkUp.indication to notify L3. Finally, L3 performs handover (e.g., sending a Binding Update (BU)).
L3が、いくつかの規則に従って引き渡しを実行すると決めるなら、L3は、L2引き渡しを要求するために候補アクセスポイントに関するいくつかのパラメタがあるL2-LinkConnect.requestを送ります。L2がL2-LinkConnect.confirmをL3に送った後にL2引き渡しは始まります。 L2引き渡しが終わると、L2は、L3に通知するためにL2-LinkUp.indicationを送ります。 最終的に、L3は引き渡し(例えば、Binding Update(BU)を送る)を実行します。
One of the important features of L3-driven fast handover using primitives is that L3 handover preparation can be done during communication. So, it can reduce disruption time during handover.
基関数を使用するL3駆動の速い引き渡しの重要な特徴の1つはコミュニケーションの間L3引き渡し準備ができるということです。 それで、それは引き渡しの間の分裂時間を減少させることができます。
Appendix B. Example Operation for FMIPv6
FMIPv6のための付録B.例の操作
There are two scenarios of L3-driven fast handover for FMIPv6. Scenario 2 is different from scenario 1 for the timing of sending some messages.
FMIPv6におけるL3駆動の速い引き渡しの2つのシナリオがあります。 いくつかのメッセージを送るタイミングにおいて、シナリオ2はシナリオ1と異なっています。
Teraoka, et al. Experimental [Page 17] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[17ページ]RFC5184L2抽象化
B.1. Example Operation-1 for FMIPv6
B.1。 FMIPv6のための例の操作-1
Figure 4 shows the predictive mode of FMIPv6 operation with an L3-driven link-switching mechanism.
図4はL3駆動のリンクスイッチ開閉装置によるFMIPv6操作の予言のモードを示しています。
MN-L2 MN-L3 PAR-L3
| | |
AP<----------PoAList.req----------| |
Scan----------PoAList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|----------PoAFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal---LinkStatusChanged.ind---->| | NAR-L3
| |-----FBU---->| |
| | |----HI---->|
| | |<--HAck----|
| |<----FBack---| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: |
: : |
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
ミネソタ-L2ミネソタ-L3パーL3| | | AP<。----------PoAList.req----------| | スキャン----------PoAList.cnf--------->|、|、| |---RtSolPr-->|、| | <--PrRtAdv---| |----------PoAFound.ind--------->|、|、| |---RtSolPr-->|、| | <--PrRtAdv---| | | | ~ ~ ~ | | | 安値| | 信号---LinkStatusChanged.ind---->|、| NAR-L3| |-----FBU---->|、|、|、| |----こんにちは---->|、|、| | <--ハッキング----| | | <、-、-、--FBack---| | | <、-、-、-、-、-、--LinkConnect.req---L3引き渡し| | L2引き渡し--LinkConnect.cnf-------->: | : : | : : | 終わり---------LinkUp.ind---------->: | | :-----------FNA---------->|、| <を終えてください。======パケット=========| | | |
MN-L2 : Link Layer on Mobile Node MN-L3 : Network Layer on Mobile Node PAR-L3 : Network Layer on Previous Access Router NAR-L3 : Network Layer on New Access Router req : Request cnf : Confirm ind : Indication RtSolPr : Router Solicitation for Proxy PrRtAdv : Proxy Router Advertisement FBU : Fast Binding Update FBack : Fast Binding Acknowledgment FNA : Fast Neighbor Advertisement HI : Handover Initiate HAck : Handover Acknowledge
ミネソタ-L2: モバイルノードミネソタ-L3の上のリンクレイヤ: モバイルノードパーL3の上のネットワーク層: 前のアクセスルータNAR-L3の上のネットワーク層: LayerをNew Access Router reqにネットワークでつないでください: cnfを要求してください: indを確認してください: 指示RtSolPr: プロキシPrRtAdvのためのルータ懇願: プロキシルータ通知FBU: 速く付いて、FBackをアップデートしてください: 速い拘束力がある承認FNA: 速い隣人Advertisement HI: 引き渡し開始ハッキング: 引き渡しは承認します。
Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 1
図4: FMIPv6シナリオ1があるL3駆動の速い引き渡しメカニズム
Teraoka, et al. Experimental [Page 18] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[18ページ]RFC5184L2抽象化
When MN establishes link connectivity to PAR, it performs router discovery. MN sends an RtSolPr message to PAR to resolve the access point identifiers to the subnet router information. To send RtSolPr, MN discovers one or more access points by sending L2-PoAList.request to the link layer. As a response to L2-PoAList.request, L2-PoAList.confirm returns with "PoA List" parameter that contains identifiers and conditions of nearby access points. After initial AP discovery, L2-PoAFound.indication with "PoA List" is also sent from the link layer when one or more access points are discovered.
ミネソタがリンクの接続性をPARに確立すると、それはルータ発見を実行します。 ミネソタは、サブネットルータ情報にアクセスポイント識別子を決議するためにRtSolPrメッセージをPARに送ります。 RtSolPr、ミネソタを送るのは、L2-PoAList.requestをリンクレイヤに送ることによって、1つ以上のアクセスポイントを発見します。 L2-PoAList.requestへの応答として、L2-PoAList.confirmは識別子を含む「PoAリスト」パラメタと近いアクセスポイントの状態とともに帰ります。 また、AP1つ以上のアクセスポイントを発見するとき、初期のリンクレイヤから「PoAは記載すること」があるL2-PoAFound.indicationを次々と送ります。
When the link layer of MN detects that radio signal strength is dropping, it sends L2-LinkStatusChanged.indication to the network layer. Then, MN sends the FBU message to PAR as the beginning of the L3 handover procedure. The NCoA required for the FBU message is determined according to the MN's policy database and the received PrRtAdv message. As a response to the FBU message, MN receives the FBack message and then immediately switches its link by L2-LinkConnect.request with the specific "PoA" parameter. The handover policy of the MN is outside the scope of this document.
ミネソタリンクレイヤが強さが落としているその無線信号を検出するとき、それはL2-LinkStatusChanged.indicationをネットワーク層に送ります。 そして、ミネソタはL3引き渡し手順の始まりとしてFBUメッセージをPARに送ります。 ミネソタの方針データベースと受信されたPrRtAdvメッセージによると、FBUメッセージに必要であるNCoAは断固としています。 FBUメッセージへの応答として、ミネソタはFBackメッセージを受け取ります、そして、特定の"PoA"パラメタがあるL2-LinkConnect.requestによるリンクはすぐにその時、切り替わります。 このドキュメントの範囲の外にミネソタの引き渡し方針があります。
After L2 handover, the link layer of the MN sends L2-LinkUp.indication to the network layer. MN immediately sends the FNA message to the New Access Router (NAR). The NAR will send tunneled and buffered packets to MN.
L2引き渡しの後に、ミネソタリンクレイヤはL2-LinkUp.indicationをネットワーク層に送ります。 ミネソタはすぐに、New Access Router(NAR)にFNAメッセージを送ります。 NARはトンネルを堀られてバッファリングされたパケットをミネソタに送るでしょう。
Teraoka, et al. Experimental [Page 19] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[19ページ]RFC5184L2抽象化
B.2. Example Operation-2 for FMIPv6
B.2。 FMIPv6のための例の操作-2
Figure 5 shows the predictive mode of FMIPv6 operation with an L3-driven link-switching mechanism.
図5はL3駆動のリンクスイッチ開閉装置によるFMIPv6操作の予言のモードを示しています。
MN-L2 MN-L3 PAR-L3
| | |
AP<----------PoAList.req----------| |
Scan----------PoAList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|----------PoAFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal---LinkStatusChanged.ind---->| | NAR-L3
| |-----FBU---->| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: | |
| | |----HI---->|
| | |<--HAck----|
| | <-FBack-|---FBack-->|
| |<----FBack---------------|
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
ミネソタ-L2ミネソタ-L3パーL3| | | AP<。----------PoAList.req----------| | スキャン----------PoAList.cnf--------->|、|、| |---RtSolPr-->|、| | <--PrRtAdv---| |----------PoAFound.ind--------->|、|、| |---RtSolPr-->|、| | <--PrRtAdv---| | | | ~ ~ ~ | | | 安値| | 信号---LinkStatusChanged.ind---->|、| NAR-L3| |-----FBU---->|、| | <、-、-、-、-、-、--LinkConnect.req---L3引き渡し| | L2引き渡し--LinkConnect.cnf-------->: | | | | |----こんにちは---->|、|、| | <--ハッキング----| | | <。FBack|---FBack-->|、| | <、-、-、--FBack---------------| : : | 終わり---------LinkUp.ind---------->: | | :-----------FNA---------->|、| <を終えてください。======パケット=========| | | |
MN-L2 : Link Layer on Mobile Node MN-L3 : Network Layer on Mobile Node PAR-L3 : Network Layer on Previous Access Router NAR-L3 : Network Layer on New Access Router req : Request cnf : Confirm ind : Indication RtSolPr : Router Solicitation for Proxy PrRtAdv : Proxy Router Advertisement FBU : Fast Binding Update FBack : Fast Binding Acknowledgment FNA : Fast Neighbor Advertisement HI : Handover Initiate HAck : Handover Acknowledge
ミネソタ-L2: モバイルノードミネソタ-L3の上のリンクレイヤ: モバイルノードパーL3の上のネットワーク層: 前のアクセスルータNAR-L3の上のネットワーク層: LayerをNew Access Router reqにネットワークでつないでください: cnfを要求してください: indを確認してください: 指示RtSolPr: プロキシPrRtAdvのためのルータ懇願: プロキシルータ通知FBU: 速く付いて、FBackをアップデートしてください: 速い拘束力がある承認FNA: 速い隣人Advertisement HI: 引き渡し開始ハッキング: 引き渡しは承認します。
Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 2
図5: FMIPv6シナリオ2があるL3駆動の速い引き渡しメカニズム
Teraoka, et al. Experimental [Page 20] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[20ページ]RFC5184L2抽象化
Unlike scenario 1, MN in scenario 2 sends LinkConnect.req from the network layer to the link layer after MN sends the FBU message. As PAR sends the FBack messages not only to PAR's subnet but also to NAR's subnet, MN can get the FBack message sent by PAR through NAR, and then it moves to NAR.
シナリオ1と異なって、FBUメッセージを送った後にシナリオ2のミネソタはネットワーク層からリンクレイヤにLinkConnect.reqを送ります。 PARがPARのサブネットに送るだけではなく、FBackメッセージをNARのサブネットにも送るとき、ミネソタはPARにNARを通してFBackメッセージを送らせることができます、そして、次に、それはNARに動きます。
B.3. Experiment
B.3。 実験
We implemented FMIPv6 and the proposed L2 primitives on FreeBSD-5.4. Figure 6 shows our test network. MN is connected to access routers by using IEEE802.11a wireless LAN. MN moves from PAR to NAR.
私たちはFMIPv6と無料OSの一つ-5.4に関する提案されたL2基関数を実行しました。 図6は私たちのテストネットワークを示しています。 ミネソタは、IEEE802.11a無線LANを使用することによってルータにアクセスするためにつなげられます。 ミネソタはPARからNARまで動きます。
|
+--+---+
|Router|
+--+---+
| 100BaseTX
---+--------+---------+---------+---------+------------
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| PAR | | NAR | | HA | | CN |
+-----+ +-----+ +-----+ +-----+
| |
IEEE802.11a IEEE802.11a PAR, NAR: nexcom EBC
|Channel 7 |Channel7 MN: ThinkPad X31
OS: FreeBSD-5.4
| | KAME/SHISA/TARZAN
+-----+ +-----+
| MN | -------> | MN |
+-----+ +-----+
| +--+---+ |ルータ| +--+---+ | 100BaseTX---+--------+---------+---------+---------+------------ | | | | +--+--+ +--+--+ +--+--+ +--+--+ | 平価| | NAR| | ハ| | CN| +-----+ +-----+ +-----+ +-----+ | | IEEE802.11a IEEE802.11a平価、NAR: nexcom EBC|チャンネル7|Channel7ミネソタ: シンクパッドX31OS: 無料OSの一つ-5.4| | ケイム/SHISA/ターザン+-----+ +-----+ | ミネソタ| ------->| ミネソタ| +-----+ +-----+
Figure 6: Test Network
図6: テストネットワーク
Scenario 1 was used in this experiment since it was more stable than scenario 2. Upon receiving L2-LinkStatusChanged.indication, L3 of MN sent the FBU message and then received the FBack message. It took 20ms from the transmission of the FBU message to the reception of the FBack message. After receiving the FBack message, L3 of MN issued L2-LinkConnect.request to L2. When L2 handover finished, L3 received L2-LinkUp.indication from L2. It took 1ms for an L2 handover. Next, MN sent the FNA message to NAR. Upon receiving the FNA message, NAR started forwarding packets to NM. ICMP echo request packets were sent at 10ms intervals. It was observed that zero or one ICMP echo reply packet was lost during a handover.
それがシナリオ2より安定していたので、シナリオ1はこの実験に使用されました。 ミネソタのL3はL2-LinkStatusChanged.indicationを受けて、FBUメッセージを送って、次に、FBackメッセージを受け取りました。 それはFBUメッセージの伝達からFBackメッセージのレセプションまで20msを取りました。 FBackメッセージを受け取った後に、ミネソタのL3はL2にL2-LinkConnect.requestを発行しました。 L2引き渡しが終わったとき、L3はL2からL2-LinkUp.indicationを受けました。 それはL2引き渡しように1msを取りました。次に、ミネソタはFNAメッセージをNARに送りました。 FNAメッセージを受け取ると、NARはパケットをニューメキシコに送り始めました。 10ms間隔を置いて、ICMPエコー要求パケットを送りました。 ゼロか1つのICMPエコー・リプライパケットが引き渡しの間失われたのが観測されました。
Teraoka, et al. Experimental [Page 21] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[21ページ]RFC5184L2抽象化
MN PAR NAR
| | |
|----- RtSolPr --->| |
|<---- PrRtAdv ----| |
| | |
+--- |------ FBU ------>| |
| | |------- HI ------>|
20ms| | | |
| | |<----- HAck ------|
| | | |
+--- |<-------------- FBack -------------->|
| | |
+-- disconnect | |
| 1ms| | |
| connect | |
8-10ms| | | |
| 7ms| | |
| | | |
| +----- FNA -------------------------->|
+-- |<------------------------ deliver packets
| | |
ミネソタ平価NAR| | | |----- RtSolPr--->|、| | <、-、-、-- PrRtAdv----| | | | | +--- |------ FBU------>|、|、|、| |------- こんにちは------>| 20ms| | | | | | | <、-、-、-、-- ハッキング------| | | | | +--- | <、-、-、-、-、-、-、-、-、-、-、-、-、-- FBack-------------->|、|、|、| +--連絡を断ってください。| | | 1ms| | | | 接続してください。| | 8-10 ms| | | | | 7ms| | | | | | | | +----- FNA-------------------------->| +-- | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- パケットを届けてください。| | |
Figure 7: Measured Results
図7: 測定結果
Appendix C. Example Mapping between L2 Primitives and the Primitives in
IEEE 802.11 and IEEE 802.16e
IEEE802.11とIEEE 802.16eのL2基関数と基関数の間の付録C.例のマッピング
This section shows example mapping between the L2 primitives and the primitives in IEEE 802.11 [7] and IEEE 802.16e [9] in Table 1.
このセクションはTable1のIEEE802.11[7]とIEEE 802.16e[9]にL2基関数と基関数の間の例のマッピングを示しています。
Teraoka, et al. Experimental [Page 22] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[22ページ]RFC5184L2抽象化
+-------------------+----------------------+------------------+
| L2 Primitive | IEEE802.11 | IEEE802.16e |
+-------------------+----------------------+------------------+
| L2-LinkStatus | PMD_RSSI | Available |
| | | |
| | PMD_RATE | |
| | | |
| L2-PoAList | MLME-SCAN | M_ScanScheduling |
| | | |
| | | M_Scanning |
| | | |
| L2-PoAFound | MLME-SCAN | M_Neighbor |
| | | |
| | | M_Scanning |
| | | |
| L2-PoALost | MLME-SCAN | M_Neighbor |
| | | |
| | | M_Scanning |
| | | |
| L2-LinkUp | MLME-ASSOCIATE | M_Registration |
| | | |
| | MLME-AUTHENTICATE | |
| | | |
| L2-LinkDown | MLME-DEASSOCIATE | M_Ranging |
| | | |
| | MLME-DISAUTHENTICATE | |
| | | |
| L2-StatusChanged | PMD_RSSI | M_Ranging |
| | | |
| | | M_ScanReport |
| | | |
| | | M_Scanning |
| | | |
| L2-LinkConnect | MLME-JOIN | M_MACHandover |
| | | |
| | MLME-ASSOCIATE | M_HOIND |
| | | |
| | MLME-REASSOCIATE | |
| | | |
| | MLME-AUTHENTICATE | |
| | | |
| L2-LinkDisconnect | MLME-DISASSOCIATE | M_Management |
| | | |
| | MLME-DEASSOCIATE | (Deregistration) |
+-------------------+----------------------+------------------+
+-------------------+----------------------+------------------+ | L2原始的です。| IEEE802.11| IEEE802.16e| +-------------------+----------------------+------------------+ | L2-LinkStatus| PMD_RSSI| 利用可能| | | | | | | PMD_レート| | | | | | | L2-PoAList| MLME-スキャン| M_ScanScheduling| | | | | | | | M_スキャン| | | | | | L2-PoAFound| MLME-スキャン| M_隣人| | | | | | | | M_スキャン| | | | | | L2-PoALost| MLME-スキャン| M_隣人| | | | | | | | M_スキャン| | | | | | L2-結合| MLME-仲間| M_登録| | | | | | | MLME認証します。| | | | | | | L2-LinkDown| MLME-DEASSOCIATE| M_及ぶこと| | | | | | | MLME-DISAUTHENTICATE| | | | | | | L2-StatusChanged| PMD_RSSI| M_及ぶこと| | | | | | | | M_ScanReport| | | | | | | | M_スキャン| | | | | | L2-LinkConnect| MLME接合してください。| M_MACHandover| | | | | | | MLME-仲間| M_HOIND| | | | | | | MLME-REASSOCIATE| | | | | | | | MLME認証します。| | | | | | | L2-LinkDisconnect| MLME分離してください。| M_管理| | | | | | | MLME-DEASSOCIATE| (Deregistration) | +-------------------+----------------------+------------------+
Table 1: Mapping between L2 Primitives and the Primitives in
IEEE 802.11 and IEEE 802.16e
テーブル1: IEEE802.11とIEEE 802.16eのL2基関数と基関数の間のマッピング
Teraoka, et al. Experimental [Page 23] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[23ページ]RFC5184L2抽象化
Appendix D. Example Mapping of Primitives and IEEE 802.11
基関数とIEEE802.11に関する付録D.例のマッピング
This section shows examples of the mapping between primitives and IEEE 802.11 [7] parameters.
このセクションは基関数とIEEE802.11[7]パラメタの間のマッピングに関する例を示しています。
D.1. L2-LinkStatus
D.1。 L2-LinkStatus
Most parameters of L2-LinkStatus are related to the configuration of network-interface hardware. The operating system and the device-driver module can easily collect such information. However, to create the "Condition" parameter, the MN should maintain statistics and parameters related to the current wireless environment.
L2-LinkStatusのほとんどのパラメタがネットワーク・インターフェースハードウェアの構成に関連します。 オペレーティングシステムとデバイスドライバモジュールは容易にそのような情報を集めることができます。 しかしながら、「状態」パラメタを作成するために、ミネソタは統計を取るべきでした、そして、パラメタは現在の無線の環境に関連しました。
There are two sub-parameters of the "Condition" parameter: available bandwidth and link quality level. The available bandwidth of the current PoA can be obtained by maintaining the transmission rate indication and the statistics of frame transmission every time a frame is sent. A link quality level can be updated by maintaining the following parameters and statistics every time a frame is received: Received Signal Strength Indicator (RSSI), transmission/ reception rate indication, transmit/receive latency, bit-error rate, frame-error rate, and noise level. Link quality level is divided into five levels: EXCELLENT, GOOD, FAIR, BAD, and NONE, in descending order. Some parameters can be managed by setting thresholds from software. When the parameters cross the threshold, an interrupt is generated for the software.
「状態」パラメタの2つのサブパラメタがあります: 利用可能な帯域幅とリンク品質水準。 フレームを送るときはいつも、通信速度指示とフレームトランスミッションの統計を維持することによって、現在のPoAの利用可能な帯域幅を得ることができます。 フレームが受け取られているときはいつも、以下のパラメタと統計を維持することによって、リンク品質水準をアップデートできます: 容認されたSignal Strength Indicator(RSSI)(トランスミッション/レセプションレート指示)は潜在、ビット誤り率、フレーム誤り率、および騒音レベルを伝えるか、または受けます。 リンク品質水準は5つのレベルに分割されます: 降順でEXCELLENT、GOOD、FAIR、BAD、およびNONE。 ソフトウェアから敷居を設定することによって、いくつかのパラメタに対処できます。 パラメタが家に入るとき、中断はソフトウェアのために発生します。
D.2. L2-PoAList
D.2。 L2-PoAList
In IEEE 802.11 networks, L2-PoAList returns the detected APs whose quality level exceeds the specified threshold for PoA candidates (by the "PoA List" parameter). Therefore, an MN should always maintain the database of available access points according to reception of beacon frame, probe response frame, and all frames. This AP database is managed in consideration of time, number of frames, and signal strength. There are some kinds of network-interface hardware that can notify events to operating system only when the desired event occurs by setting a threshold from software. Moreover, MN can transmit the probe request frame for access point discovery, if needed.
IEEEでは、802.11のネットワーク、L2-PoAListは検出を返します。品質水準がPoA候補(「PoAリスト」パラメタによる)のために指定された敷居を超えているAPs。 したがって、標識フレーム、徹底的調査レスポンス・フレーム、およびすべてのフレームのレセプションに従って、ミネソタはいつも利用可能なアクセスポイントに関するデータベースを維持するべきです。 このAPデータベースは時間、フレームの数、および信号強度を考慮して管理されます。 必要な出来事がソフトウェアから敷居を設定することによって起こる場合にだけオペレーティングシステムへの出来事に通知できる数種類のネットワーク・インターフェースハードウェアがあります。 そのうえ、必要であるなら、ミネソタはアクセスポイント発見のために徹底的調査要求フレームを伝えることができます。
D.3. L2-PoAFound
D.3。 L2-PoAFound
In IEEE 802.11 networks, L2-PoAFound is notified when new PoAs whose link quality level exceeds the specified threshold are detected by listening beacons or scanning APs. If the received frame (mainly the
新しいときに、IEEEでは、802.11のネットワーク、L2-PoAFoundは通知されます。リンク品質水準が指定された敷居を超えているPoAsは、標識となるか、またはAPsをスキャンしながら聴くことによって、検出されます。 容認されたフレームである、(主に。
Teraoka, et al. Experimental [Page 24] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[24ページ]RFC5184L2抽象化
beacon or the probe response) is not in the AP database described in Appendix D.2, then the link layer creates L2-PoAFound.indication.
標識か徹底的調査応答) コネはAppendix D.2で説明されたAPデータベースでなく、次に、リンクレイヤはL2-PoAFound.indicationを作成します。
For example, if the threshold of link quality level specified by L2-PoAFound.request is GOOD, L2-PoAFound.indication is created and sent to the upper layer when PoA's link quality becomes better than GOOD.
例えば、L2-PoAFound.requestによって指定されたリンク品質水準の敷居がGOODであるなら、PoAのリンク品質がGOODより良くなるとき、上側の層にL2-PoAFound.indicationを作成して、送ります。
D.4. L2-PoALost
D.4。 L2-PoALost
In IEEE 802.11 networks, L2-PoALost is notified when an AP included in the list of candidate APs is lost by listening beacons or scanning APs. If the entry in the AP database described in Appendix D.2 expires, or link quality level goes under the threshold, then the link layer creates L2-PoALost.indication. To calculate the link quality level, the signal strength of the received frame (mainly the beacon or the probe response) can be used. For example, if the threshold of the link quality specified by L2-PoALost is BAD, L2-PoALost.indication is created and sent to the upper layer when PoA's link quality becomes worse than BAD.
IEEEでは、802.11のネットワーク、L2-PoALostは通知されます。APがいつ候補のリストにAPsを含んでいたかは、標識を聴くか、またはAPsをスキャンすることによって、失われています。 Appendix D.2で説明されたAPデータベースにおけるエントリーが期限が切れるか、またはリンク品質水準が敷居の下を通るなら、リンクレイヤはL2-PoALost.indicationを作成します。 リンク品質水準について計算するために、容認されたフレーム(主に標識か徹底的調査応答)の信号強度を使用できます。 例えば、L2-PoALostによって指定されたリンク品質の敷居がBADであるなら、PoAのリンク品質がBADより悪くなるとき、上側の層にL2-PoALost.indicationを作成して、送ります。
D.5. L2-LinkUp
D.5。 L2-結合
In IEEE 802.11 networks, L2-LinkUp is notified when association or reassociation event occurs. When such an event occurs, MN receives the association response frame or the reassociation response frame. Immediately after receiving it, the link layer creates L2-LinkUp.indication.
協会か「再-協会」出来事が起こるとき、IEEE802.11では、ネットワークであり、L2-LinkUpは通知されます。 そのような出来事が起こると、ミネソタは協会レスポンス・フレームか「再-協会」レスポンス・フレームを受けます。 それを受ける直後、リンクレイヤはL2-LinkUp.indicationを作成します。
D.6. L2-LinkDown
D.6。 L2-LinkDown
In IEEE 802.11 networks, L2-LinkDown is notified when a disassociation event occurs or when no beacon is received during a certain time. When such an event occurs, MN sends the disassociation frame to AP, or the entry of the specific AP is deleted from the AP database described in Appendix D.2. By detecting such events, the link layer creates an L2-LinkDown.indication.
「不-協会」出来事が起こるか、またはある時間標識を全く受け取らないとき、IEEEでは、802.11のネットワークであり、L2-LinkDownに通知します。 そのような出来事が起こると、ミネソタが「不-協会」フレームをAPに送るか、または特定のAPのエントリーはAppendix D.2で説明されたAPデータベースから削除されます。 そのような出来事を検出することによって、リンクレイヤはL2-LinkDown.indicationを作成します。
D.7. L2-LinkStatusChanged
D.7。 L2-LinkStatusChanged
In IEEE 802.11 networks, L2-LinkStatusChanged is notified when the radio signal strength of the connected AP drops below the specified threshold.
IEEEでは、802.11のネットワーク、L2-LinkStatusChangedはそうです。指定された敷居の下の接続AP低下のラジオ信号強度であるときに、通知されます。
Teraoka, et al. Experimental [Page 25] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[25ページ]RFC5184L2抽象化
D.8. L2-LinkConnect
D.8。 L2-LinkConnect
In IEEE 802.11 networks, each AP is identified by the BSSID and the service set of several APs is identified by the SSID. When L2-LinkConnect is used to connect a specific AP or a service set, the link layer should set the Basic Service Set Identifier (BSSID) or the Service Set Identifier (SSID). Also, the channel should be set appropriately at the same time by searching the database described in Appendix D.2. To connect to AP, MN should be authenticated by AP. MN sends the authentication message to AP, and then MN sends the association message to associate with AP.
IEEEでは、802.11のネットワークであり、各APはBSSIDによって特定されます、そして、数個のAPsのサービスセットはSSIDによって特定されます。 L2-LinkConnectが特定のAPを接続するのに使用されたか、またはサービスがセットしたとき、リンクレイヤはBasic Service Set Identifier(BSSID)かService Set Identifier(SSID)を設定するはずです。 また、チャンネルは、同時にAppendix D.2で説明されたデータベースを捜すことによって、適切に据えられるべきです。 AP、ミネソタに接続するのはAPによって認証されるはずです。 ミネソタは認証メッセージをAPに送ります、そして、次に、ミネソタはAPと交際する協会メッセージを送ります。
D.9. L2-LinkDisconnect
D.9。 L2-LinkDisconnect
In IEEE 802.11 networks, MN sends the disassociation message to AP for disconnection. When L2-LinkDisconnect is used for disconnection from the current AP, the link layer should send the disassociation message to the appropriate AP, and stop data transmission.
IEEE802.11では、ネットワークであり、ミネソタは断線のために「不-協会」メッセージをAPに送ります。 L2-LinkDisconnectが断線に現在のAPから使用されるとき、リンクレイヤは適切なAP、および停止データ伝送に「不-協会」メッセージを送るはずです。
Appendix E. Implementation and Evaluation of the Proposed Model
提案されたモデルの付録E.実現と評価
This section describes an implementation of the proposed link indication architecture and its evaluation.
このセクションは提案されたリンク指示構造とその評価の実現について説明します。
An IEEE 802.11a wireless LAN device driver was modified to provide abstract link-layer information in the form of primitives defined in Section 4. The modified driver has two AP lists. One contains the device-dependent information such as RSSI, retransmission count, various AP parameters, and various statistics. The device-dependent information, except for the AP parameters, is updated whenever the device receives a frame. If the received frame is the management frame, the AP parameters are also updated according to the parameters in the frame.
IEEE 802.11a無線LANデバイスドライバは、セクション4で定義された基関数の形に抽象的なリンクレイヤ情報を供給するように変更されました。 変更されたドライバーには、2つのAPリストがあります。 1つはRSSIや、「再-トランスミッション」カウントや、様々なAPパラメタや、様々な統計などの装置依存する情報を含んでいます。 APパラメタを除いて、装置がフレームを受けるときはいつも、装置依存する情報をアップデートします。 また、容認されたフレームが管理フレームであるなら、フレームのパラメタによると、APパラメタをアップデートします。
Another AP list contains the abstract information. The abstract information is updated periodically by using the device-dependent information. In the abstraction processing, for example, RSSI or the retransmission count is converted to the common indicator "link quality". In our outdoor testbed described below, the thresholds of the RSSI value between the link quality levels were defined as follows:
別のAPリストは抽象的な情報を含んでいます。 装置依存する情報を使用することによって、抽象的な情報を定期的にアップデートします。 抽象化処理では、例えば、RSSIか「再-トランスミッション」カウントが一般的なインディケータ「リンク品質」に変換されます。 以下で説明された私たちの野外のテストベッドでは、リンク品質水準の間のRSSI価値の敷居は以下の通り定義されました:
o EXCELLENT -- 34 -- GOOD
o 素晴らしい(34)利益
o GOOD -- 27 -- FAIR
o いいぞ--27--フェア
o FIAR -- 22 -- BAD
o FIAR(22)悪いです。
Teraoka, et al. Experimental [Page 26] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[26ページ]RFC5184L2抽象化
o BAD -- 15 -- NONE
o 悪くない(15)なにも
L2-PoAList and L2-LinkStatus were implemented by using only the abstract information. Thus, the upper layers can use information of the current AP and the adjacent APs without depending on the devices. L2-PoAFound or L2-PoALost is notified if the link quality rises or falls beyond the thresholds when the abstract information is updated. If the link quality of the current AP goes below the specific threshold, L2-LinkStatusChanged is notified. L2-LinkUp or L2-LinkDown is notified when an association with an AP is established or destroyed. To realize L2-LinkConnect and L2-LinkDisconnect, functions to connect or disconnect to the specified AP were implemented. In these functions, since only abstract information is needed to specify the AP, other layers need not know the device-dependent information.
L2-PoAListとL2-LinkStatusは、抽象的な情報だけを使用することによって、実行されました。 したがって、装置によらないで、上側の層は現在のAPと隣接しているAPsの情報を使用できます。 抽象的な情報をアップデートするとき、リンク品質が敷居を超えて上昇するか、または下落するなら、L2-PoAFoundかL2-PoALostが通知されます。 現在のAPのリンク品質が特定の敷居を下に降りさせるなら、L2-LinkStatusChangedは通知されます。 APとの協会が設立されるか、または破壊されるとき、L2-LinkUpかL2-LinkDownが通知されます。 L2-LinkConnectとL2-LinkDisconnectがわかるために、指定されたAPに接続するか、または外す機能は実行されました。 抽象的な情報だけがAPを指定するのに必要である時から他の層がそうする必要はないこれらの機能では、装置依存する情報を知ってください。
In our outdoor testbed, there are eight Access Routers (ARs) located at 80-100m intervals. AP is collocated at AR. IEEE 802.11a was used as the link layer. The same wireless channel was used at all APs. Thus, there are eight wireless IPv6 subnets in the testbed. The mobile node was in a car moving at a speed of 30-40 km/h. When link quality of the current AP goes down, the mobile node executes L3-driven handover, described in Appendix A. An application called Digital Video Transport System (DVTS) was running on the mobile node and sent digital video data at a data rate of about 15Mbps through the wireless IPv6 subnet to the correspondent node, which replayed received digital video data. In this environment, the L2 handover required less than 1 msec, and the mobility protocol Location Independent Networking in IPv6 (LIN6) [13] required a few msecs for location registration. Thus, the total gap time due to the handover was 3-4 msec. In most cases, there was no effect on the replayed pictures due to handover.
私たちの野外のテストベッドに、80-100mの間隔を置いて見つけられた8Access Routers(ARs)があります。 APはそうです。ARでは、並べました。 IEEE 802.11aはリンクレイヤとして使用されました。 同じ無線のチャンネルはすべてのAPsで使用されました。 したがって、8つの無線のIPv6サブネットがテストベッドにあります。 可動のノードが、30-40km/hの速度で動きながら、車にありました。 現在のAPのリンク品質が落ちるとき、可動のノードは受信されたデジタルビデオデータを再演した呼ばれたDigital Video Transport System(DVTS)が無線のIPv6サブネットを通して15Mbpsに関して通信員ノードに可動のノードで動いていて、データ信号速度におけるデジタルビデオデータを送ったAppendix A.Anアプリケーションで説明されたL3駆動の引き渡しを実行します。 この環境、L2引き渡必要な1しmsec、および移動性プロトコルLocationでは、IPv6(LIN6)[13]の無党派Networkingは位置登録のために数msecを必要としました。 したがって、引き渡しによる総ギャップ時間は3-4msecでした。 多くの場合、再演された絵への効果が全く引き渡しのためにありませんでした。
Authors' Addresses
作者のアドレス
Fumio Teraoka Faculty of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
Fumio Teraoka理学部と技術、慶応大学3-14-1日義、湖北区横浜、日本神奈川223-8522
Phone: +81-45-566-1425 EMail: tera@ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
以下に電話をしてください。 +81-45-566-1425 メールしてください: tera@ics.keio.ac.jp ユリ: http://www.tera.ics.keio.ac.jp/
Teraoka, et al. Experimental [Page 27] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[27ページ]RFC5184L2抽象化
Kazutaka Gogo Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
科学技術のKazutakaの精力的な大学院、慶応大学3-14-1日義、湖北区横浜、日本神奈川223-8522
Phone: +81-45-566-1425 EMail: gogo@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
以下に電話をしてください。 +81-45-566-1425 メールしてください: gogo@tera.ics.keio.ac.jp ユリ: http://www.tera.ics.keio.ac.jp/
Koshiro Mitsuya Jun Murai Lab, Shonan Fujisawa Campus, KEIO University 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
Koshiro三屋6月の村井研究室、Shonan藤沢キャンパス、慶応大学5322の藤沢の遠藤、日本神奈川252-8520
Phone: +81-466-49-1100 EMail: mitsuya@sfc.wide.ad.jp
以下に電話をしてください。 +81-466-49-1100 メールしてください: mitsuya@sfc.wide.ad.jp
Rie Shibui Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
科学技術の理恵渋井大学院、慶応大学3-14-1日義、湖北区横浜、日本神奈川223-8522
Phone: +81-45-566-1425 EMail: shibrie@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
以下に電話をしてください。 +81-45-566-1425 メールしてください: shibrie@tera.ics.keio.ac.jp ユリ: http://www.tera.ics.keio.ac.jp/
Koki Mitani Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
科学技術のKoki Mitani大学院、慶応大学3-14-1日義、湖北区横浜、日本神奈川223-8522
Phone: +81-45-566-1425 EMail: koki@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
以下に電話をしてください。 +81-45-566-1425 メールしてください: koki@tera.ics.keio.ac.jp ユリ: http://www.tera.ics.keio.ac.jp/
Teraoka, et al. Experimental [Page 28] RFC 5184 L2 Abstractions for L3-Driven Fast Handover May 2008
Teraoka、他 L3駆動の速い引き渡し2008年5月のための実験的な[28ページ]RFC5184L2抽象化
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と http://www.rfc-editor.org/copyright.html に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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に情報を記述してください。
Teraoka, et al. Experimental [Page 29]
Teraoka、他 実験的[29ページ]
一覧
スポンサーリンク
