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
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インターネット標準ではありません。これは、インターネット研究タスクフォースのMOBOPTS研究グループのコンセンサスを表しています。これは、将来的には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トリガの形態として、他の層の情報を知っているか、または利用するプロトコル層のために不可欠です。しかし、各プロトコル層は基本的に独立して設計されています。各プロトコル層はまた、現在のオペレーティングシステムに独立に実装されているので、プロトコル層との間で制御情報を交換することは非常に困難です。この文書では、問題を解決するための手段として、ネットワーク層での高速ハンドオーバを実現するために、「プリミティブ」の形でL2の抽象化の9種類を定義します。ネットワーク層は、プリミティブを使用して、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]、[3]モバイルIPv6は、モバイルノードとの通信をサポートするために、標準化されています。そのようなモバイルIPv6（FMIPv6と）のための高速ハンドオーバとしてIPv6ネットワークにおけるシームレスハンドオーバのためのいくつかの提案がある[4]及び階層モバイルIPv6（HMIPv6の）[5]。 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.
問題を解決するために、このドキュメントは、ネットワーク層での高速ハンドオーバを実現するために、「プリミティブ」の形でL2の抽象化の9種類を定義します。ネットワーク層は、プリミティブを使用して、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研究グループのコンセンサスを表しています。それは仕事の特定の領域に積極的に研究グループのメンバーによって検討されています。
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
ポア
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つのクラスがあります。プリミティブの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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がどのプロトコルエンティティこのプリミティブは、送信すべきかを指定例えば、IEEE 802.11 [7]またはIEEE 802.3 [8]。
For unified L2 abstractions for L3-driven fast handovers, three different usages of primitives are defined, as described below:
後述のようにL3-駆動高速ハンドオーバのための統一L2の抽象化のために、プリミティブの三つの異なる用途は、定義されています。
Type 1. To provide L2 information to upper layers immediately
直ちに上位層にL2情報を提供するためにタイプ1
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
非同期L2イベントの上位層に通知するタイプ2
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
上位層からL2の動作を制御するにはタイプ3
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におけるL2プリミティブおよびプリミティブとの間の例示的なマッピングを示している[7]とのIEEE802.16e [9]。
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上層は、リンクの現在の情報を必要とする場合、リンクレイヤに送られます。 L2-LinkStatus.requestプリミティブは、「ネットワークインタフェースID」パラメータを（5.1節を参照）が含まれています。応答において、L2-LinkStatus.confirmプリミティブ戻ります。 「ネットワークインターフェイスID」、「PoAの」、および「条件」：プリミティブL2-LinkStatus.confirmは、次の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.
上層は、候補のPoAのリストを必要とするときプリミティブL2-PoAList.requestは、リンク層に送信されます。 L2-PoAList.requestプリミティブは、「ネットワークインターフェイスID」パラメータが含まれています。応答では、L2-PoAList.confirmプリミティブを返す「ネットワークインタフェースID」パラメータと「PoAのリスト」パラメータ。 「PoAのリスト」パラメータは、候補のPoAのリストです。
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.
新規のPoAが検出されたときプリミティブL2-PoAFound.indicationは非同期上位層に提供されます。このプリミティブは、「ネットワークインターフェイスID」パラメータと「PoAのリスト」パラメータを運びます。 「PoAのリスト」パラメータは、モバイルノードによって検出された新しいのPoAについての情報が含まれています。この通知を使用するために、プリミティブL2-PoAFound.requestプリミティブL2-PoAFound.confirmを用いた登録処理が事前に必要とされます。 「ネットワークインターフェイスID」と「有効/無効」：プリミティブL2-PoAFound.requestは、2つのパラメータがあります。 「有効/無効」パラメータは、この通知機能がオンになっているかどうかを示します。この登録は、「ネットワークインターフェイスID」パラメータと応答「ACK」パラメータを使用して、L2-PoAFound.confirmプリミティブ戻る成功したとき。
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.
POAはのPoAが消え候補のリストに含まれるプリミティブL2-PoALost.indicationは非同期上位層に提供されます。このプリミティブは、「ネットワークインターフェイスID」パラメータと「PoAのリスト」パラメータを運びます。 「PoAのリスト」パラメータは、候補者のリストから消えたのPoAについての情報が含まれています。プリミティブL2-PoALost.requestプリミティブL2-PoALost.confirmを用いた登録処理は、上述したL2-PoAFoundプリミティブと同様です。
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は非同期上位層に提供されます。 RFC 4957 [12]に記載のもの「リンクが接続されている」とは、リンクの種類に依存します。アクセスポイントへの関連付けが確立されると、例えば、IEEE 802.11 [7]（無線LAN）でインフラストラクチャモードの場合には、このプリミティブが提供されます。このプリミティブは、「ネットワークインターフェイスID」パラメータと「PoAの」パラメータを運びます。 L2-LinkUp.requestプリミティブは、「ネットワークインターフェイス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.
既存のリンクが切断され、IPパケットがリンクを介して送信することができない場合プリミティブL2-LinkDown.indicationは非同期上位層に提供されます。登録処理は、上述したL2-のLinkUpプリミティブと同じです。
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プリミティブは、「ネットワークインターフェイス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上層が特定の「当該PoA」に新しいリンクを確立しなければならないとき、リンク層に送信されます。このプリミティブは、「ネットワークインターフェイスID」パラメータと「PoAの」パラメータを運びます。リンク層は、「ACK」とプリミティブL2-LinkConnect.confirmを返した後、この操作は開始されます。
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上層が特定「のPoA」への既存のリンクを切断する必要がある場合、リンクレイヤに送られます。このプリミティブは、「ネットワークインターフェイスID」パラメータと「PoAの」パラメータを運びます。リンク層は、「ACK」とプリミティブL2-LinkDisconnect.confirmを返した後、この操作は開始されます。
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]、第三世代パートナーシッププロジェクト（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.
利用可能な帯域幅とリンクの品質レベル：「条件」パラメータは、以下のサブパラメータで構成されています。これらのサブパラメータは、サービスの現在の品質を表す抽象化情報です。サブパラメータの抽象化アルゴリズムは、ハードウェアデバイスとソフトウェア実装に依存します。降順に優れ、GOOD、FAIR、BAD、およびNONE：リンク品質の有用な範囲は、5つのレベルに分割されます。 L2デバイスの品質レベルは、他のデバイスのものとは無関係です。しかし、これらの測定基準に基づいて意思決定を行うと、エラーを起こしやすいとリンクの最適な選択をもたらすことが保証されていません。 IEEE 802.11の5つのレベル間の閾値の一例は、[7]の付録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のリスト」パラメータには、二つのサブパラメータの任意のカップルで構成されています。このパラメータは、のPoAとその条件のリストが表示されます。
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.
「有効/無効」フラグがオン/オフイベント通知を回すために使用されています。上位層は、通知を必要とするとき、「有効」と要求プリミティブは、登録など、リンク層に送信されます。上位層は、これ以上の通知を必要とするとき、「無効」との要求プリミティブが送信されます。
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.
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は、AES及びプリミティブを使用しての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.
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は、両方向のリンク品質を表しています。これは、過渡リンク条件に対処するためにRSSIの平均値または1秒以上減衰再送回数を使用する必要があります。
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.
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.
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.
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.
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.
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で述べたセキュリティ上の考慮事項について説明します。
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.
Transportation of the link indications between nodes is not
assumed; hence, this consideration is beyond the scope of our
proposal.
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.
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[2]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[4] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[4] Koodli、R.、エド。、 "モバイル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]ソリマン、H.、カステルッシア、C.、エルMalki、K.、およびL. Bellier、 "階層型Mobile 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.
、IEEE P802.21 / D02.00、2006年9月：[6]「メディア独立ハンドオーバサービスローカルおよびメトロポリタンエリアネットワークのためのIEEE規格案」。
[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-2007 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年版ISO / IEC 8802-3：2000（E）情報技術 - LAN / MAN - パート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.、及びPROCにおいてF.寺岡、 "IPv6の移動度のL3ドリブン高速ハンドオーバ機構"、。アプリケーションに関する国際シンポジウムおよびIPv6でインターネット（SAINT2006）ワークショップ、2006年2月の。
[11] Aboba, B., Ed., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[11] Aboba、B.、エド。、 "リンク適応の建築的意味"、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]クリシュナン、S.、エド。、Montavont、N.、Njedjou、E.、Veerepalli、S.、およびA. Yegin、エド。、 "検出ネットワーク添付ファイルのリンク層イベント通知"、RFC 4957、8月2007。
[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.、上原、K.、江崎、H.、およびF.寺岡、 "LINA：ワイドエリアネットワークにおけるモビリティサポートする新しいアプローチ"、通信容量に電子情報通信学会論文誌。 E84-B、ありません。 8頁。2076年から2086年、2001年8月。
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主導高速ハンドオーバ機構は、モバイルノード（MN）にトリガーを示しています。
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.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はL3とL2-LinkStatusChanged.indicationを送信します。 L3は、ハンドオーバの準備（例えば、気付アドレス（CoA）の生成、重複アドレス検出（DAD）、近隣探索（ND）キャッシュの作成、およびルーティングテーブルの設定）とアクセスのリスト場合はL2にL2-PoAList.requestを送信ポイントが必要とされています。
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はL3にL2-LinkConnect.confirmを送信した後、L2ハンドオーバが開始されます。 L2ハンドオーバが完了したとき、L2はL3を通知するL2-LinkUp.indicationを送信します。最後に、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主導型高速ハンドオーバの重要な特徴の一つは、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と異なっています。
B.1. Example Operation-1 for FMIPv6
B.1。動作例-1 FMIPv6のため
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を確認してください：表示RtSolPrをします。Routerプロキシルータ通知FBU：プロキシ代理ルータ広告のための勧誘高速更新FBACKバインディング：高速近隣広告HI：高速謝辞FNAバインディングハンドオーバハックを開始しますハンドオーバはアクノリッジ
Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 1
図4：FMIPv6とシナリオ1とL3ドリブン高速ハンドオーバメカニズム
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.
MNがPARへのリンク接続を確立すると、それは、ルータ検出を実行します。 MNは、サブネットルータ情報へのアクセスポイントの識別子を解決するためにPARにRtSolPrをメッセージを送信します。 RtSolPrをを送信するには、MNは、リンク層にL2-PoAList.requestを送信することによって、1つまたは複数のアクセスポイントを検出します。 L2-PoAList.requestへの応答として、L2-PoAList.confirmは、近くのアクセスポイントの識別子と条件が含まれている「PoAのリスト」パラメータを返します。 1つ以上のアクセスポイントが発見された場合、最初のAPを発見した後、「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.
MNのリンク層は、無線信号強度が低下していることを検出すると、それはネットワーク層にL2-LinkStatusChanged.indicationを送信します。その後、MNはL3ハンドオーバ手順の始まりとしてPARにFBUメッセージを送信します。 FBUメッセージに必要なNCOAは、MNのポリシーデータベースと受信代理ルータ広告メッセージに応じて決定されます。 FBUメッセージに対する応答として、MNはFBACKメッセージを受信した後、直ちに特定「のPoA」パラメータを使用してL2-LinkConnect.requestによってそのリンクを切り替えます。 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は、すぐに新しいアクセスルータ（NAR）へFNAメッセージを送信します。 NARは、MNにトンネリングし、バッファされたパケットを送信します。
B.2. Example Operation-2 for FMIPv6
B.2。動作例-2 FMIPv6のため
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を確認してください：表示RtSolPrをします。Routerプロキシルータ通知FBU：プロキシ代理ルータ広告のための勧誘高速更新FBACKバインディング：高速近隣広告HI：高速謝辞FNAバインディングハンドオーバハックを開始しますハンドオーバはアクノリッジ
Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 2
図5：FMIPv6とシナリオ2とL3ドリブン高速ハンドオーバメカニズム
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.
MNは、FBUメッセージを送信した後、シナリオ1とは異なり、シナリオ2におけるMNは、リンク層、ネットワーク層からLinkConnect.reqを送信します。 PARは、PARのサブネットにもNARのサブネットにないだけFBACKメッセージを送ると、MNは、NARを通じてPARによって送信さ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.
私たちは、FreeBSD-5.4にFMIPv6とし、提案されているL2プリミティブを実装しました。図6は、我々のテストネットワークを示しています。 MNは、IEEE802.11aの無線LANを使用してアクセスルータに接続されています。 MNは、NARにPARから移動します。
|
+--+---+
|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.
それはL2-LinkStatusChanged.indicationを受信するシナリオ2よりも安定であったので、シナリオ1は、この実験で使用された、MNのL3は、FBUメッセージを送信した後FBACKメッセージを受信しました。それはFBACKメッセージの受信にFBUメッセージの送信から20msのを取りました。 FBACKメッセージを受信した後、MNのL3は、L2とL2-LinkConnect.requestを発行しました。 L2ハンドオーバが完了したら、L3は、L2からL2-LinkUp.indicationを受けました。これは、L2ハンドオーバのための1ミリ秒を要しました。次に、MNがNARにFNAメッセージを送りました。 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
L2プリミティブおよびIEEE 802.11及びIEEE 802.16eの中のプリミティブとの間の付録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.
このセクションでは、表1に示す[9] [7]とのIEEE802.16e L2プリミティブとIEEE 802.11でプリミティブとの間の例示的なマッピングを示します。
+-------------------+----------------------+------------------+
| 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プリミティブおよびプリミティブとの間のマッピング
Appendix D. Example Mapping of Primitives and IEEE 802.11
付録D.例プリミティブのマッピングおよびIEEE 802.11
This section shows examples of the mapping between primitives and IEEE 802.11 [7] parameters.
このセクションでは、プリミティブおよびIEEE 802.11 [7]のパラメータの間のマッピングの例を示します。
D.1. L2-LinkStatus
1. D。 Qlnquestts用
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.
利用可能な帯域幅とリンクの品質レベル：「条件」パラメータの二つのサブパラメータがあります。現在のPoAの利用可能な帯域幅は、伝送レート表示とフレーム送信の統計フレームが送信される度に維持することによって得ることができます。送信/レイテンシ、ビットエラーレート、フレームエラーレートを、受信、受信信号強度インジケータ（RSSI）、送信/受信レート表示：リンクの品質レベルは、フレームが受信されるたびに、次のパラメータと統計を維持することによって更新することができますノイズレベル。降順に優れ、GOOD、FAIR、BAD、およびNONE：リンク品質レベルは、5つのレベルに分割されます。一部のパラメータは、ソフトウェアからしきい値を設定することで管理することができます。パラメータがしきい値を越えた場合、割り込みは、ソフトウェアのために生成されます。
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の候補のために指定されたしきい値を超えて検出されたAPを返します。したがって、MNは常にビーコンフレーム、プローブ応答フレーム、及び全てのフレームの受信に応じて利用可能なアクセスポイントのデータベースを維持しなければなりません。このAPデータベースは、時間、フレーム数、及び信号強度を考慮して管理されています。所望のイベントがソフトウェアからしきい値を設定することにより発生したときにのみ、オペレーティング・システムにイベントを通知することができるネットワーク・インターフェース・ハードウェアのいくつかの種類があります。必要に応じてさらに、MNは、アクセスポイントの発見のためのプローブ要求フレームを送信することができます。
D.3. L2-PoAFound
D.A. Qpfnd用
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.
そのリンク品質レベル新規のPoAがビーコンまたはスキャンAPをリッスンすることによって検出される指定されたしきい値を超えたときにIEEE 802.11ネットワークでは、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のリンク品質が良好でより良好になったときに上位層に送られます。
D.4. L2-PoALost
4. D。 Qubolsh用
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.
APは、ビーコン又は走査APを聞くことによって失われた候補APのリストに含まれるIEEE 802.11ネットワークでは、L2-PoALostが通知されます。付録D.2に記載のAPデータベース内のエントリの有効期限が切れた、またはリンク品質レベルがしきい値以下になった場合、リンク層はL2-PoALost.indicationを作成します。リンク品質レベルを計算するために、受信したフレームの信号強度は、（主にビーコンまたはプローブ応答）を用いることができます。 L2-PoALostによって指定されたリンク品質の閾値が悪い場合、例えば、L2-PoALost.indicationが作成されたPoAのリンク品質が悪いよりも悪くなった場合に上位レイヤに送られます。
D.5. L2-LinkUp
D.5。 L2-のLinkUp
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を作成します。
D.6. L2-LinkDown
D。T. Qlncdonn用
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を作成します。
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の無線信号強度が所定の閾値を下回ったときに通知されます。
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によって識別され、複数のAPのサービスセットは、SSIDによって識別されます。 L2-LinkConnectは、特定のAPまたはサービスのセットを接続するために使用される場合、リンクレイヤは、基本サービスセット識別子（BSSID）またはサービスセット識別子（SSID）を設定しなければなりません。また、チャネル付録D.2に記載のデータベースを検索することにより、同時に適切に設定されるべきです。 APに接続するには、MNは、APによって認証されなければなりません。 MNはAPに認証メッセージを送信し、MNは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.
IEEE 802.11ネットワークでは、MNは、切断のために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デバイスドライバは、修正ドライバは、2つのAPのリストを有し、セクション4で定義されたプリミティブの形で抽象リンク層情報を提供するために変更されました。一つは、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 EXCELLENT - 34 - GOOD
o GOOD -- 27 -- FAIR
O GOOD - 27 - FAIR
o FIAR -- 22 -- BAD o BAD -- 15 -- NONE
またはFIAR - 22 - BADまたはBAD - 15 - NONE
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が通知されます。 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〜100メートル間隔で設置8つのアクセスルータ（ARS）があります。 APは、ARで一緒に配置されます。 IEEE 802.11aのは、リンク層として用いました。同じ無線チャネルは、すべてのAPで使用しました。このように、テストベッドで8つのワイヤレスIPv6のサブネットがあります。モバイルノードは、毎時30〜40キロの速度で移動車でした。現在のAPのリンク品質がダウンすると、モバイルノードは、デジタルビデオ交通システム（DVTS）と呼ばれるアプリケーションは、モバイルノード上で実行されていた付録Aで説明したとのデータレートでデジタルビデオデータを送信し、L3主導型ハンドオーバを実行します約15Mbpsのデジタルビデオデータを受信し再生コレスポンデントノードへ無線IPv6サブネットを介し。この環境では、L2ハンドオーバが1未満ミリ秒を必要とし、IPv6におけるモビリティプロトコル場所独立ネットワーク（LIN6）[13]は、位置登録のためのいくつかのミリ秒を要します。したがって、ハンドオーバに起因する総ギャップ時間は3~4ミリ秒でした。ほとんどの場合、ハンドオーバによる再生画像には影響はありませんでした。
Authors' Addresses
著者のアドレス
Fumio Teraoka Faculty of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan
ふみお てらおか ふぁくｌｔｙ おｆ Ｓしえんせ あんｄ てｃｈのぉｇｙ、 けいお うにゔぇｒしｔｙ ３ー１４ー１ ひよし、 こほくーく よこはま、 かながわ ２２３ー８５２２ じゃぱん
Phone: +81-45-566-1425 EMail: tera@ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
電話：+ 81-45-566-1425 Eメール：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
かずたか ごご Ｇらづあて Ｓちょおｌ おｆ Ｓしえんせ あんｄ てｃｈのぉｇｙ、 けいお うにゔぇｒしｔｙ ３ー１４ー１ ひよし、 こほくーく よこはま、 かながわ ２２３ー８５２２ じゃぱん
Phone: +81-45-566-1425 EMail: gogo@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
電話：+ 81-45-566-1425 Eメール：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
こしろ みつや じゅん むらい ぁｂ、 しょなん ふじさわ かｍぷｓ、 けいお うにゔぇｒしｔｙ ５３２２ えんど ふじさわ、 かながわ ２５２ー８５２０ じゃぱん
Phone: +81-466-49-1100 EMail: mitsuya@sfc.wide.ad.jp
電話：+ 81-466-49-1100 Eメール：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
りえ しぶい Ｇらづあて Ｓちょおｌ おｆ Ｓしえんせ あんｄ てｃｈのぉｇｙ、 けいお うにゔぇｒしｔｙ ３ー１４ー１ ひよし、 こほくーく よこはま、 かながわ ２２３ー８５２２ じゃぱん
Phone: +81-45-566-1425 EMail: shibrie@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
電話：+ 81-45-566-1425 Eメール：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
こき みたに Ｇらづあて Ｓちょおｌ おｆ Ｓしえんせ あんｄ てｃｈのぉｇｙ、 けいお うにゔぇｒしｔｙ ３ー１４ー１ ひよし、 こほくーく よこはま、 かながわ ２２３ー８５２２ じゃぱん
Phone: +81-45-566-1425 EMail: koki@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/
電話：+ 81-45-566-1425 Eメール：koki@tera.ics.keio.ac.jp URI：http://www.tera.ics.keio.ac.jp/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。