[要約] RFC 5184は、L3による高速ハンドオーバーのための統一されたL2抽象化を提供することを目的としています。このRFCは、異なるL2技術を使用するネットワークでのハンドオーバーの効率を向上させるためのガイドラインを提供しています。
Network Working Group F. Teraoka
Request for Comments: 5184 K. Gogo
Category: Experimental K. Mitsuya
R. Shibui
K. Mitani
KEIO University
May 2008
Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
統一レイヤー2（L2）レイヤー3（L3）駆動型の高速ハンドオーバーの抽象化
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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インターネット標準ではありません。これは、インターネット研究タスクフォースの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.
このドキュメントでは、レイヤー3（L3）駆動型の高速ハンドオーバーの統一レイヤー2（L2）抽象化を提案します。効率的なネットワーク通信のために、プロトコル層がL2トリガーの形式などの他のレイヤーの情報を知っているか利用することが重要です。ただし、各プロトコル層は基本的に独立して設計されています。各プロトコル層も現在のオペレーティングシステムで個別に実装されているため、プロトコル層間で制御情報を交換することは非常に困難です。このドキュメントでは、問題を解決する手段として、ネットワークレイヤーで高速な拳銃を達成するために、「プリミティブ」の形で9種類のL2抽象化を定義しています。このメカニズムは、ネットワークレイヤーがプリミティブを使用してL2とL3のハンドオーバーを開始するため、「L3駆動型高速ハンドオーバー」と呼ばれます。このドキュメントは、IPモビリティ最適化（MOBOPTS）研究グループの製品です。
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
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（FMIPV6）[4]や階層モバイルIPv6（HMIPV6）[5]の高速ハンドオーバーなど、IPv6ネットワークのシームレスな拳銃についてはいくつかの提案があります。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.
IEEE 802.21 [6]は、L2情報を使用するいくつかのサービスも定義しています。実装と展開を容易にするために、このドキュメントで定義されているプリミティブはモバイルノードで利用可能な情報のみを使用し、IEEE 802.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のコンセンサスを表しています。これは、特定の作業分野で活動している研究グループメンバーによってレビューされています。
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情報が必要です。
PoA
poa
The point of attachment of a mobile node (e.g., an access point in IEEE 802.11 networks [7]).
モバイルノードの添付ポイント（例：IEEE 802.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.
あるレイヤーから別のレイヤーに送信される情報の単位。リクエスト、確認、表示、および応答の4つのクラスには、4つのクラスがあります。プリミティブの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 RFC 2119 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [1]に記載されているように解釈される。
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.
各レイヤーは、プリミティブの形でサービスを提供しています。図1に示すように、4つのクラスのプリミティブが定義されています。リクエストは、別のレイヤーからサービスまたは情報を取得したいレイヤーによって発行され、リクエストの承認が確認されています。兆候とは、サービスを要求したレイヤーへの情報の通知であり、応答は表示の承認です。このアーキテクチャでは、レイヤー間の通信は対称です。
------------------------- -----------------------------
Request Response
|| /\ /\ ||
Layer N || || || ||
------------||------||--- -------||------||------------
|| || || ||
\/ || || \/
Layer N-m Confirm Indication
------------------------- -----------------------------
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].
プリミティブは、プロトコル層ID、プロトコルID、プリミティブクラス（要求、応答、表示、または確認）、プリミティブ名、およびパラメーターの5つのフィールドで構成されています。プロトコルレイヤーIDは、このプリミティブを送信するレイヤー、たとえばレイヤー2またはレイヤー3を指定します。プロトコルIDは、この原始的なプロトコルエンティティをどのように送信する必要があるかを指定します。
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情報をすぐに上層に提供するために使用されます。プリミティブの要求と確認のクラスは、相互作用のために交換する必要があります。リクエストプリミティブは、L2情報の取得要求のためです。確認の原始は答えのためです。
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イベントの上層に非同期に通知するために使用されます。プリミティブの要求、確認、および指示クラスを交換する必要があり、応答クラスは相互作用のために交換される場合があります。リクエストと確認プリミティブは、登録のためだけに使用されます。イベントが発生すると、指示プリミティブが上層に非同期に配信されます。
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アクションを制御するために使用されます。プリミティブの要求と確認のクラスは、相互作用のために交換する必要があります。リクエストプリミティブは、操作のリクエストです。ACKまたはNACKは、原始の確認としてすぐに戻ります。
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.
プロトコルエンティティは、リクエストを交換することにより、いつでもプリミティブを登録し、上記のフィールドを含むメッセージを確認できます。登録されたイベントが発生すると、表示メッセージと応答メッセージも交換されます。
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.
指示プリミティブを送信するタイミングは、このドキュメントの範囲を超えています。たとえば、レイヤー2ステータスが変更されたときにレイヤー2イベントが生成されます。これは、たとえばスキャンアルゴリズムの実装方法に依存します。
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は、IEEE 802.11 [7]およびIEEE 802.16E [9]のL2プリミティブとプリミティブの間のマッピングの例を示しています。
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プリミティブリターン。L2-Linkstatus.Confirm Primitiveには、「ネットワークインターフェイスID」、「POA」、および「条件」の3つのパラメーターが含まれています。「POA」と「条件」は、モバイルノードとPOAの間のリンクの現在のステータスを示しています。
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.
L2-Poalist.Request Primitiveは、上層に候補ポアのリストが必要な場合にリンク層に送信されます。L2-Poalist.Request Primitiveには、「ネットワークインターフェイスID」パラメーターが含まれています。これに応じて、L2-Poalist.Confirm Primitiveは、「ネットワークインターフェイスID」パラメーターと「POAリスト」パラメーターを返します。「POAリスト」パラメーターは、候補POASのリストです。
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.
L2-poafound.indicationプリミティブは、新しいPOAが検出されたときに上層に非同期に提供されます。このプリミティブには、「ネットワークインターフェイスID」パラメーターと「POAリスト」パラメーターが搭載されています。「POAリスト」パラメーターには、モバイルノードで検出された新しいPOAに関する情報が含まれています。この通知を使用するには、L2-Poafound.Request PrimitiveとL2-Poafound.Confirm Primitiveを使用した登録プロセスが事前に必要です。L2-Poafound.Request Primitiveには、「ネットワークインターフェイスID」と「有効/無効」の2つのパラメーターがあります。「有効化/無効」パラメーターは、この通知機能がオンになっているかどうかを示します。この登録が成功すると、L2-Poafound.Confirm Primitiveは、「ネットワークインターフェイスID」パラメーターと「ACK」パラメーターを使用して返されます。
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 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.
L2-poalost.indicationプリミティブは、候補POAのリストに含まれるPOAが消えると、上層に非同期に提供されます。このプリミティブには、「ネットワークインターフェイスID」パラメーターと「POAリスト」パラメーターが搭載されています。「POAリスト」パラメーターには、候補者のリストから消えたPOASに関する情報が含まれています。L2-Poalost.Request PrimitiveとL2-Poalost.Confirm Primitiveを使用した登録プロセスは、上記のL2-Poafound Primitiveに似ています。
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.
l2-linkup.indicationプリミティブは、新しいリンクが接続され、IPパケットを新しいリンクから送信できる場合、上層に非同期に提供されます。RFC 4957 [12]で説明されているように、「リンクが接続されている」という意味は、リンクタイプに依存します。たとえば、IEEE 802.11 [7]（WiFi）のインフラストラクチャモードの場合、アクセスポイントとの関連が確立されると、この原始が提供されます。このプリミティブには、「ネットワークインターフェイスID」パラメーターと「POA」パラメーターが搭載されています。L2-Linkup.Request Primitiveには、「ネットワークインターフェイスID」パラメーターと登録の「有効化/無効」パラメーターが含まれています。登録が成功すると、「ネットワークインターフェイスID」パラメーターと「ACK」パラメーターを使用したL2-Linkup.Confirmがプリミティブになります。
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.
l2-linkdown.indicationプリミティブは、既存のリンクが切断され、IPパケットをリンクから送信できない場合、上層に非同期に提供されます。登録処理は、上記のL2-Linkup Primitiveと同じです。
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プリミティブは、リンクのステータスが変更されたときに上層に非同期に提供されます。この通知には、「ネットワークインターフェイスID」、「POA」、および「条件」の3つのパラメーターが含まれています。「POA」パラメーターは、リンクの品質が変更されたアタッチメントポイントを示します。登録処理では、l2-linkstatuschanged.request Primitiveは、「ネットワークインターフェイスID」パラメーター、「有効化/無効」パラメーター、および「条件」パラメーターを搭載しています。「条件」は、イベントタイプと表示のしきい値を示します。
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".
L2-LinkConnect.Request Primitiveは、上層が特定の「POA」への新しいリンクを確立する必要がある場合にリンクレイヤーに送信されます。このプリミティブには、「ネットワークインターフェイスID」パラメーターと「POA」パラメーターが搭載されています。この操作は、リンクレイヤーがL2-LinkConnect.Confirm Primitiveを「ACK」で返すと開始されます。
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".
L2-LinkDisconnect.Request Primitiveは、上層が特定の「POA」への既存のリンクを取り壊す必要がある場合、リンクレイヤーに送信されます。このプリミティブには、「ネットワークインターフェイスID」パラメーターと「POA」パラメーターが搭載されています。この操作は、リンクレイヤーがL2-LinkDisconnect.Confirm Primitiveを「ACK」で返すと開始されます。
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.
このセクションには、静的パラメーターをリストします。静的パラメーターの値が構成されると、それらは基本的に通信中は変化しません。次のパラメーターは、プリミティブの一部として転送されます。
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]、第3世代パートナーシッププロジェクト（3GPP）など）を示すネットワークインターフェイスタイプも含まれています。このパラメーターは、すべてのプリミティブで必要です。
This section lists dynamic parameters. The values of dynamic parameters change frequently during communication. The following parameters are transferred as a part of primitives.
このセクションには、動的なパラメーターがリストされています。動的パラメーターの値は、通信中に頻繁に変化します。次のパラメーターは、プリミティブの一部として転送されます。
The "PoA" parameter uniquely identifies the PoA.
「POA」パラメーターは、POAを一意に識別します。
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 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.
「条件」パラメーターは、次のサブパラメーターで構成されています。利用可能な帯域幅とリンクの品質レベル。これらのサブパラメーターは、現在のサービス品質を示す抽象化された情報です。サブパラメーターの抽象アルゴリズムは、ハードウェアデバイスとソフトウェアの実装に依存します。リンク品質の有用な範囲は、優れた、良い、公正、悪い、そしていずれにせずに、5つのレベルに分けられます。L2デバイスの品質レベルは、他のデバイスの品質レベルとは無関係です。ただし、これらのメトリックに基づいて決定を下すことはエラーが発生しやすく、リンクの最適な選択になることを保証するものではありません。IEEE 802.11 [7]の5つのレベルのしきい値の例については、付録Eに記載されています。
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リスト」パラメーターは、「POA」と「条件」という2つのサブパラメーターの任意のカップルで構成されています。このパラメーターは、ポアとその条件のリストを示しています。
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.
「有効化/無効」フラグは、イベント通知のオン/オフを回すために使用されます。上層に通知が必要な場合、「enable」を備えたリクエストが登録としてリンクレイヤーに送信されます。上層にはこれ以上通知が必要な場合、「無効」の原始的なリクエストが送信されます。
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.
上層がいくつかの通知を要求すると、リンクレイヤーがこのリクエストを受信して確認します。リクエストが有効な場合、「ACK」を使用した原始の確認が上層に送信されます。無効な場合、「エラー」による確認が上層に送信されます。
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.
RFC 4907 [11]は、インターネットアーキテクチャ内のリンク表示の役割と問題について説明しています。このセクションでは、RFC 4907のセクション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.
各レイヤーの情報は、別のレイヤーに送信される前に抽象化する必要があります。たとえば、IEEE 802.11 [7]では、受信信号強度インジケータ（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 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.
従来のプロトコルレイアリングモデルでは、プロトコルエンティティ（PE）は、特定のプロトコルを処理するエンティティとして定義されます。私たちの提案は、リンクの表示のリンクの独立性を達成するために、要約エンティティ（AE）を導入しました。AEとPEがペアを作ります。AEは、PE依存情報をPEに依存しない情報に抽象化します。
Figure 2 shows AEs and PEs using primitives.
図2は、プリミティブを使用したAEとPEを示しています。
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.
リンク情報/表示を明確にするために、私たちの提案は、セクション3で説明されているように、4種類のプリミティブを定義します。リクエスト/確認と表示/応答を別のレイヤーの情報を取得するために要求を使用します。確認はリクエストへの返信であり、要求された情報が含まれています。特定のイベントが発生すると、表示が生成されます。応答は、表示への返信です。
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はアクセスポイント（AP）との関連性が確立されるステータスとして定義され、L2-LinkdownはAPとの関連がある状態として定義されます。未確立の。L2-LinkStatUsChangedは、リンクの品質が事前定義されたしきい値を下回ると生成されます。受信信号強度インジケーター（RSSI）と再送信の数を使用してリンク品質を抽象化および評価するため、L2-LinkStatUsChangedは両方向のリンク品質を表します。一時的なリンク条件に対処するために、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、再送信の数、および上記のリンクステータスを計算するための関連付けの存在を使用します。私たちの実験では、2つのAPの間にいくつかの「ピンポン」の握手がありました。このようなPing-Pongの握手は、L2-LinkStatusChangedが通知されたときにL2-Linkstatusによって最も適切なAPを検出することにより減少させることができます。L2表示の使用は、ハンドオーバーをトリガーするパラメーターしきい値に関連しています。これらのしきい値は、展開シナリオに基づいて異なり、適切に構成されていない場合、誤解を招く適応症につながる可能性があります。
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.
付録Eに記載されている提案されたL3駆動型のハンドオーバーは、L2-LinkStatusChangedの表示を、ハンドオーバーを開始するためのトリガーとして使用しています。L2-LinkStatUsChangedは、リンクの品質が特定のしきい値を下回ると示されます。リンクの品質がまもなく上昇しても、この兆候はキャンセルされません。上記のように、L2-Linkstatusを使用して、最も適切なAPを検出できます。L2-LinkStatusChangedが通知されたときにL2-Linkstatusを使用することにより、現在のAPが最も適切なAPであることがわかった場合、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駆動型のハンドオーバーメカニズムの実装と評価の例については、付録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レイヤーに対するリンク表示のみを定義しているため、複数のレイヤー間のレース条件は発生しません。
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）TS（ネットワークアドレス（ポート）翻訳）などの中央のボックスの存在下でより確実に動作します。、後方互換性がある可能性が高く、セキュリティの脆弱性をもたらす可能性が低くなります。
Our proposal does not define the exchange of link indications between nodes.
私たちの提案は、ノード間のリンクの表示の交換を定義していません。
---------------------------------------------------------
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N || /\ || /\
------------||---||-------------------||---||------------
Request|| || Response|| ||
|| || || ||
|| || || ||
|| ||Confirm || ||Indication
------------||---||-------------------||---||------------
\/ || \/ ||
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N-m
---------------------------------------------------------
Figure 2: AE and PE with Primitives
図2：プリミティブを備えたAEとPE
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.
RFC 4907 [11]は、インターネットアーキテクチャ内のリンク表示の役割と問題について説明しています。このセクションでは、RFC 4907のセクション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.
ノード間のリンク表示の輸送は想定されていません。したがって、この考慮事項は私たちの提案の範囲を超えています。
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.
この提案はリンク層プロトコルを変更しないため、特定のリンク層プロトコルにはこれ以上の不安定性は追加されません。しかし、提案されたプリミティブは、スプーフィングされたリンク層フレームによるサービス拒否攻撃に悩まされています。たとえば、l2- poafound.indicationとl2-poalost.indicationは、悪意のあるアクセスポイントが強力なrssiと弱いrssiを交互に示すコントロールフレームを頻繁に送信する場合、交互に頻繁に生成される場合があります。
The authors gratefully acknowledge the contributions of Jukka Manner, Christian Vogt, and John Levine for their review.
著者は、彼らのレビューのために、ジュッカマナー、クリスチャン・フォグト、ジョン・レヴァインの貢献に感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[2] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[4] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[4] Koodli、R.、ed。、「モバイルIPv6の高速ハンドオーバー」、RFC 4068、2005年7月。
[5] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[5] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイルIPv6モビリティ管理（HMIPV6）」、RFC 4140、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、「802.11-2007 LAN/MANのIEEE標準 - 特定の要件パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様」、2007。
[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 Edition ISO/IEC 8802-3：2000（e）情報技術-LAN/MAN -MAN -MAN -3：CARRIER SENSE Collision Detection（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] Gogo、K.、Shibu、R。、およびF. Teraoka、「IPv6モビリティにおけるL3駆動の高速ハンドオーバーメカニズム」、Proc。2006年2月、IPv6のアプリケーションとインターネット（SAINT2006）ワークショップに関する国際シンポジウム。
[11] Aboba, B., Ed., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[11] Aboba、B.、ed。、「リンク表示の建築的意味」、RFC 4907、2007年6月。
[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] Krishnan、S.、Ed。、Montavont、N.、Njedjou、E.、Veerepalli、S.、およびA. Yegin、ed。、「ネットワーク添付ファイルを検出するためのリンク層イベント通知」、RFC 4957、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.、Esaki、H。、およびF. teraoka、「Lina：広いエリアネットワークにおけるモビリティサポートへの新しいアプローチ」、IEICE Transactions on Communication Vol。E84-B、いいえ。8、pp。2076-2086、2001年8月。
For example, the picture below shows L3-driven fast handover mechanism using the L2 triggers on a mobile node (MN).
たとえば、以下の写真は、モバイルノード（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: Link Layer on MN L3: Network Layer on MN req: Request cnf: Confirm ind: Indication
L2：MN L3のリンクレイヤー：MN REQのネットワークレイヤー：リクエスト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.requestを発行して、リンクが使用可能になったときにlinkup.indicationを受信します。L3は、LinkStatUsChanged.Requestを発行して、リンクの品質がしきい値を下回るときにLinkStatUsChanged.Indicationを受信します。
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は、ハンドオーバーの準備（例：住所（COA）生成、複製アドレス検出（DAD）、近隣発見（ND）キャッシュの作成、およびルーティングテーブル設定）の準備をし、アクセスのリストの場合はL2-Poalist.RequestをL2に送信しますポイントが必要です。
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-LinkConnect.Requestを候補アクセスポイントに関するいくつかのパラメーターで送信して、L2ハンドオーバーを要求します。L2がL2-LinkConnect.ConfirmをL3に送信した後、L2ハンドオーバーが開始されます。L2のハンドオーバーが終了すると、L2はL2-Linkup.indicationを送信してL3を通知します。最後に、L3はハンドオーバーを実行します（例：バインディングアップデート（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ハンドオーバーの準備を行うことができることです。したがって、ハンドオーバー中の混乱時間を短縮できます。
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とは異なります。
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=========|
| | |
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
MN-L2：モバイルノードのリンクレイヤーMN-L3：モバイルノードのネットワークレイヤーPAR-L3：以前のアクセスルーターのネットワークレイヤーNAR-L3：新しいアクセスルーターのネットワークレイヤーReq：リクエストCNF：IND：INDICATION RTSOLPR：RouterプロキシPRRTADVの勧誘：プロキシルーター広告FBU：高速バインディングアップデートFBACK：高速バインディング承認FNA：高速隣接広告HI：ハンドオーバーイニシエートハック：ハンドオーバー承認
Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 1 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.
図4：FMIPv6シナリオ1を使用したL3駆動の高速ハンドオーバーメカニズム1 MNがPARへのリンク接続を確立すると、ルーターの発見を実行します。MNはRTSOLPRメッセージをPARに送信して、サブネットルーター情報のアクセスポイント識別子を解決します。RTSOLPRを送信するには、MNはL2-Poalist.requestをリンクレイヤーに送信して、1つ以上のアクセスポイントを発見します。L2-Poalist.Requestへの応答として、L2-Poalist.Confirmは、近くのアクセスポイントの識別子と条件を含む「POAリスト」パラメーターで返されます。最初のAP発見の後、「POAリスト」を使用したL2-Poafound.Indicationは、1つ以上のアクセスポイントが発見されたときにリンクレイヤーからも送信されます。
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.
MNのリンク層が無線信号強度が低下していることを検出すると、L2-LinkStatUsChanged.dicationをネットワークレイヤーに送信します。次に、MNはL3ハンドオーバー手順の開始としてFBUメッセージをPARに送信します。FBUメッセージに必要なNCOAは、MNのポリシーデータベースと受信したPRRTADVメッセージに従って決定されます。FBUメッセージへの応答として、MNはFBACKメッセージを受信し、L2-LinkConnect.Requestによって特定の「POA」パラメーターとすぐにリンクを切り替えます。MNのハンドオーバーポリシーは、このドキュメントの範囲外です。
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ハンドオーバー後、MNのリンクレイヤーはL2-Linkup.indicationをネットワークレイヤーに送信します。MNはすぐにFNAメッセージを新しいアクセスルーター（NAR）に送信します。NARは、トンネル付きのパケットとバッファリングされたパケットをMNに送信します。
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=========|
| | |
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
MN-L2：モバイルノードのリンクレイヤーMN-L3：モバイルノードのネットワークレイヤーPAR-L3：以前のアクセスルーターのネットワークレイヤーNAR-L3：新しいアクセスルーターのネットワークレイヤーReq：リクエストCNF：IND：INDICATION RTSOLPR：RouterプロキシPRRTADVの勧誘：プロキシルーター広告FBU：高速バインディングアップデートFBACK：高速バインディング承認FNA：高速隣接広告HI：ハンドオーバーイニシエートハック：ハンドオーバー承認
Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 2 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.
図5：FMIPv6シナリオ2を使用したL3駆動の高速ハンドオーバーメカニズムシナリオ1とは異なり、シナリオ2のMNは、MNがFBUメッセージを送信した後、ネットワークレイヤーからリンクレイヤーにlinkconnect.reqを送信します。PARがFbackメッセージをParのサブネットだけでなくNARのサブネットにも送信すると、MNはNARを介してPARで送信されたFbackメッセージを取得し、NARに移動できます。
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.
FREYBSD-5.4にFMIPV6と提案されたL2プリミティブを実装しました。図6は、テストネットワークを示しています。MNは、IEEE802.11aワイヤレスLANを使用して、アクセスルーターに接続されています。MNはパーから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 |
+-----+ +-----+
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.
シナリオ1は、シナリオ2よりも安定しているため、この実験で使用されました。L2-LinkStatUsChanged.indicationを受信すると、MNのL3はFBUメッセージを送信し、FBATメッセージを受信しました。FBUメッセージの送信からFbackメッセージの受信まで20分かかりました。FBACKメッセージを受信した後、MNのL3はL2-LinkConnect.RequestをL2に発行しました。L2ハンドオーバーが終了すると、L3はL2からL2-Linkup.indicationを受け取りました。L2ハンドオーバーには1msかかりました。次に、MNはFNAメッセージをNARに送信しました。FNAメッセージを受信すると、NARはパケットをNMに転送し始めました。ICMPエコーリクエストパケットは10ms間隔で送信されました。ゼロまたは1つのICMPエコー応答パケットがハンドオーバー中に失われたことが観察されました。
MN PAR NAR
| | |
|----- RtSolPr --->| |
|<---- PrRtAdv ----| |
| | |
+--- |------ FBU ------>| |
| | |------- HI ------>|
20ms| | | |
| | |<----- HAck ------|
| | | |
+--- |<-------------- FBack -------------->|
| | |
+-- disconnect | |
| 1ms| | |
| connect | |
8-10ms| | | |
| 7ms| | |
| | | |
| +----- FNA -------------------------->|
+-- |<------------------------ deliver packets
| | |
Figure 7: Measured Results
図7：測定結果
Appendix C. Example Mapping between L2 Primitives and the Primitives in IEEE 802.11 and IEEE 802.16e
付録C. IEEE 802.11とIEEE 802.16EのL2プリミティブとプリミティブの間のマッピングの例
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.
このセクションでは、表1のIEEE 802.11 [7]とIEEE 802.16E [9]のL2プリミティブとプリミティブのマッピングの例を示しています。
+-------------------+----------------------+------------------+
| 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) |
+-------------------+----------------------+------------------+
Table 1: Mapping between L2 Primitives and the Primitives in IEEE 802.11 and IEEE 802.16e
表1：IEEE 802.11とIEEE 802.16EのL2プリミティブとプリミティブのマッピング
This section shows examples of the mapping between primitives and IEEE 802.11 [7] parameters.
このセクションでは、プリミティブとIEEE 802.11 [7]パラメーターの間のマッピングの例を示します。
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のほとんどのパラメーターは、ネットワークインターフェイスハードウェアの構成に関連しています。オペレーティングシステムとデバイスドライバーモジュールは、そのような情報を簡単に収集できます。ただし、「条件」パラメーターを作成するには、MNは現在のワイヤレス環境に関連する統計とパラメーターを維持する必要があります。
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の利用可能な帯域幅は、フレームが送信されるたびに、伝送速度の表示とフレーム送信の統計を維持することで取得できます。リンクの品質レベルは、フレームを受信するたびに次のパラメーターと統計を維持することで更新できます。およびノイズレベル。リンクの品質レベルは、優れた、良い、公正、悪い、そしていずれにせずに、5つのレベルに分けられます。一部のパラメーターは、ソフトウェアからしきい値を設定することで管理できます。パラメーターがしきい値を通過すると、ソフトウェアの割り込みが生成されます。
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リスト」パラメーター）を超える検出されたAPを返します。したがって、MNは、ビーコンフレーム、プローブ応答フレーム、およびすべてのフレームの受信に応じて、利用可能なアクセスポイントのデータベースを常に維持する必要があります。このAPデータベースは、時間、フレーム数、信号強度を考慮して管理されています。ソフトウェアからしきい値を設定することによって目的のイベントが発生した場合にのみ、イベントをオペレーティングシステムに通知できるネットワークインターフェイスハードウェアには、いくつかの種類があります。さらに、MNは、必要に応じて、アクセスポイント発見のプローブ要求フレームを送信できます。
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 beacon or the probe response) is not in the AP database described in Appendix D.2, then the link layer creates L2-PoAFound.indication.
IEEE 802.11ネットワークでは、リンクの品質レベルが指定されたしきい値を超える新しいポアが、ビーコンをリスニングしたり、APをスキャンしたりすることで検出された場合にL2-Poafoundが通知されます。受信したフレーム（主にビーコンまたはプローブ応答）が付録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で指定されたリンク品質レベルのしきい値が良好な場合、L2-Poafound.indicationが作成され、POAのリンク品質が良好よりも良くなると上層に送信されます。
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ネットワークでは、候補APSのリストに含まれるAPがビーコンをリスニングしたり、APをスキャンしたりすることで失われたときにL2-Poalostが通知されます。付録D.2で説明されているAPデータベースのエントリが期限切れになる場合、またはリンクの品質レベルがしきい値の下にある場合、リンクレイヤーはL2-Poalost.indicationを作成します。リンクの品質レベルを計算するには、受信したフレームの信号強度（主にビーコンまたはプローブ応答）を使用できます。たとえば、L2-Poalostによって指定されたリンク品質のしきい値が悪い場合、L2-Poalost.indicationが作成され、POAのリンクの品質が悪いよりも悪くなると上層に送信されます。
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.
IEEE 802.11ネットワークでは、関連または再配分イベントが発生した場合にL2-Linkupが通知されます。このようなイベントが発生すると、MNは関連付け応答フレームまたは再配分応答フレームを受信します。受信した直後、リンクレイヤーはL2-Linkup.indicationを作成します。
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が通知されます。このようなイベントが発生すると、MNは分離フレームをAPに送信するか、特定のAPのエントリが付録D.2で説明されているAPデータベースから削除されます。このようなイベントを検出することにより、リンクレイヤーはL2-LinkDown.indicationを作成します。
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ネットワークでは、接続されたAPの無線信号強度が指定されたしきい値を下回ると、L2-LinkstatUsChangedが通知されます。
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によって識別され、いくつかのAPのサービスセットがSSIDによって識別されます。L2-LinkConnectを使用して特定のAPまたはAサービスセットを接続する場合、リンクレイヤーは基本サービスセット識別子（BSSID）またはサービスセット識別子（SSID）を設定する必要があります。また、付録D.2で説明したデータベースを検索して、チャネルを同時に適切に設定する必要があります。APに接続するには、MNをAPによって認証する必要があります。MNは認証メッセージをAPに送信し、MNはAPとAPに関連するために関連メッセージを送信します。
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.
IEEE 802.11ネットワークでは、MNは分離メッセージをAPに送信して切断します。L2-LinkDisconnectが現在のAPからの切断に使用される場合、リンクレイヤーは適切なAPに分離メッセージを送信し、データ送信を停止する必要があります。
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 BAD -- 15 -- NONE
o fiar -22 -bad o bad -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および隣接するAPの情報を使用できます。抽象情報が更新されたときにリンクの品質が上昇またはしきい値を超えて上昇または下落する場合、L2-PoafoundまたはL2-Poalostに通知されます。現在のAPのリンク品質が特定のしきい値を下回る場合、L2-LinkStatUsChangedに通知されます。L2-LinkupまたはL2-Linkdownは、APとの関連が確立または破壊されたときに通知されます。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間隔で8つのアクセスルーター（ARS）があります。APはARでコロケートされています。IEEE 802.11aは、リンクレイヤーとして使用されました。すべてのAPで同じワイヤレスチャネルが使用されました。したがって、テストベッドには8つのワイヤレスIPv6サブネットがあります。モバイルノードは、30〜40 km/hの速度で移動する車にありました。現在のAPのリンク品質が低下すると、モバイルノードは付録Aで説明されているL3駆動型のハンドオーバーを実行します。デジタルビデオトランスポートシステム（DVTS）と呼ばれるアプリケーションがモバイルノードで実行され、デジタルビデオデータをデータレートで送信しました。ワイヤレスIPv6サブネットを介して特派員ノードを介して約15Mbpsで、受信したデジタルビデオデータを再生しました。この環境では、L2のハンドオーバーに1ミリ秒未満が必要であり、IPv6（LIN6）[13]のモビリティプロトコルロケーション独立ネットワーキングは、ロケーション登録にいくつかのMSECを必要としました。したがって、ハンドオーバーによる総ギャップ時間は3〜4ミリ秒でした。ほとんどの場合、ハンドオーバーのために再生された写真に影響はありませんでした。
Authors' Addresses
著者のアドレス
Fumio Teraoka Faculty of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
Fumio Teraoka科学技術学部、Keio University 3-14-1 Hiyoshi、Kohoku-Ku Yokohama、Kanagawa 223-8522日本
Phone: +81-45-566-1425 EMail: tera@ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Kazutaka Gogo Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
電話：81-45-566-1425メール：tera@ics.keio.ac.jp uri：http：//www.tera.ics.keio.ac.ac.ac.ac.ac.ac.ac.ac.c.cogo科学技術大学院、Keio University 3-14-1 hiyoshi、kohoku-ku yokohama、kanagawa 223-8522日本
Phone: +81-45-566-1425
EMail: gogo@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Koshiro Mitsuya Jun Murai Lab, Shonan Fujisawa Campus, KEIO University 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
コシロ・ミツヤ・ジュン・ムレー・ラボ、藤沢shonan藤沢キャンパス、キオ大学5322藤井エンド・エンド・フジサワ252-8520日本
Phone: +81-466-49-1100
EMail: 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/
Koki Mitani Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
Keio University 3-14-1 Hiyoshi、Kohoku-Ku Yokohama、Kanagawa 223-8522日本科学技術大学院大学院科学大学院科学技術大学院
Phone: +81-45-566-1425
EMail: koki@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78および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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。