RFC5270 日本語訳
5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. H. Jang,J. Jee, Y. Han, S. Park, J. Cha. June 2008. (Format: TXT=42358 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Jang
Request for Comments: 5270 SAMSUNG
Category: Informational J. Jee
ETRI
Y. Han
KUT
S. Park
SAMSUNG Electronics
J. Cha
ETRI
June 2008
Jangがコメントのために要求するワーキンググループH.をネットワークでつないでください: 5270年の三星カテゴリ: 情報のJ.の公園三星エレクトロニクスJ.Cha ETRI Jee ETRI Y.ハンKUT S.2008年6月
Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
モバイルIPv6はIEEE 802.16eの上で速くネットワークを引き渡します。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently.
このドキュメントは仕様のIEEE 802.16eスイートに従いながらリンクレイヤでどうモバイルIPv6 Fast Handoverを実行できるかを説明します。 提案された計画は、リンクレイヤ引き渡しインディケータを利用して、その結果、モバイルIPv6速い引き渡し手順とIEEE 802.16e引き渡し手順を効率的に同期させることによって、シームレスの引き渡しを達成しようとします。
Jang, et al. Informational [Page 1] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[1ページ]のRFC5270FMIPv6
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . . 4
4. Network Topology Acquisition and Network Selection . . . . . . 5
5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 6
5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 6
5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 7
5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 8
5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 9
6. The Examples of Handover Scenario . . . . . . . . . . . . . . 10
6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 10
6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 12
7. IEEE 802.21 Considerations . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 IEEE 802.16e引き渡し概観. . . . . . . . . . . . . . . . 4 4。 ネットワーク形態獲得とネットワーク選択. . . . . . 5 5。 FMIPv6とIEEE 802.16e. . . . . . . . . 6 5.1との相互作用。 ルータ発見. . . . . . . . . . . . . . . . . 6 5.2にアクセスしてください。 引き渡し準備. . . . . . . . . . . . . . . . . . . 7 5.3。 引き渡し実行. . . . . . . . . . . . . . . . . . . . 8 5.4。 引き渡し完成. . . . . . . . . . . . . . . . . . . 9 6。 引き渡しシナリオ. . . . . . . . . . . . . . 10 6.1に関する例。 予言のモード. . . . . . . . . . . . . . . . . . . . . 10 6.2。 反応モード. . . . . . . . . . . . . . . . . . . . . . 12 7。 IEEE802.21問題.148 セキュリティ問題. . . . . . . . . . . . . . . . . . . 14 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 15 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC5268] was proposed to complement the Mobile IPv6 (MIPv6) [RFC3775] by reducing the handover latency for the real-time traffic. FMIPv6 assumes the support from the link-layer technology; however, the specific link-layer information available and its available timing differs according to the particular link-layer technology in use, as pointed out in [RFC4260], which provides an FMIPv6 solution for the IEEE 802.11 networks. So, this document is proposed to provide an informational guide to the developers about how to optimize the FMIPv6 handover procedures, specifically in the IEEE 802.16e networks [IEEE802.16][IEEE802.16e].
モバイルIPv6 Fast Handoverプロトコル(FMIPv6)[RFC5268]は、引き渡しレイテンシをリアルタイムの交通に減少させることによってモバイルIPv6(MIPv6)[RFC3775]の補足となるように提案されました。 FMIPv6はリンクレイヤ技術からサポートを仮定します。 しかしながら、使用中の特定のリンクレイヤ技術によると、利用可能な特定のリンクレイヤ情報とその利用可能なタイミングは異なります、[RFC4260](IEEEのFMIPv6解決策に802.11のネットワークを提供する)で指摘されるように。 それで、このドキュメントはどうFMIPv6引き渡し手順を最適化するかに関して情報のガイドを開発者に提供するために提案されます、特にIEEE 802.16eネットワーク[IEEE802.16][IEEE802.16e]で。
The proposed scheme achieves seamless handover by exploiting the link-layer handover indicators and designing an efficient interleaving scheme of the 802.16e and the FMIPv6 handover procedures. The scheme targets a hard handover, which is the default handover type of IEEE 802.16e. For the other handover types, i.e., the Macro Diversity Handover (MDHO) and Fast Base Station Switching (FBSS), the base stations in the same diversity set are likely to belong to the same subnet for diversity, and FMIPv6 might not be needed. Regarding the MDHO and the FBSS deployment with FMIPv6, further discussion will be needed and is not in the scope of this document.
提案された計画は、リンクレイヤ引き渡しインディケータを利用して、802.16eの効率的なインターリービング計画とFMIPv6引き渡し手順を設計することによって、シームレスの引き渡しを実現します。 計画は困難な引き渡しを狙います(IEEE 802.16eのデフォルト引き渡しタイプです)。 すなわち、他の引き渡しタイプ、Macro Diversity Handover(MDHO)とFast基地の駅のSwitching(FBSS)に関しては、同じ多様性セットの基地局は多様性のための同じサブネットに属しそうです、そして、FMIPv6は必要でないかもしれません。 FMIPv6とのMDHOとFBSS展開に関して、さらなる議論は、必要であり、このドキュメントの範囲にありません。
Jang, et al. Informational [Page 2] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[2ページ]のRFC5270FMIPv6
We begin with a summary of handover procedures of [IEEE802.16e] and then present the optimized complete FMIPv6 handover procedures by using the link-layer handover indicators. The examples of handover scenarios are described for both the predictive mode and reactive mode.
私たちは、[IEEE802.16e]の引き渡し手順の概要で始まって、次に、リンクレイヤ引き渡しインディケータを使用することによって、最適化された完全なFMIPv6引き渡し手順を提示します。 引き渡しシナリオに関する例は予言のモードと反応モードの両方のために説明されます。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document is to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Most of terms used in this document are defined in MIPv6 [RFC3775] and FMIPv6 [RFC5268].
本書では使用される用語の大部分はMIPv6[RFC3775]とFMIPv6[RFC5268]で定義されます。
The following terms come from the IEEE 802.16e specification [IEEE802.16e].
次の用語はIEEE 802.16e仕様[IEEE802.16e]から来ます。
MOB_NBR-ADV
暴徒_NBR-ADV
An IEEE 802.16e neighbor advertisement message sent
periodically by a base station.
定期的に基地局によって送られたIEEE 802.16e隣人広告メッセージ。
MOB_MSHO-REQ
暴徒_MSHO-REQ
An IEEE 802.16e handover request message sent by a mobile node.
可動のノードによって送られたIEEE 802.16e引き渡し要求メッセージ。
MOB_BSHO-RSP
暴徒_BSHO-RSP
An IEEE 802.16e handover response message sent by a base
station.
基地局によって送られたIEEE 802.16e引き渡し応答メッセージ。
MOB_BSHO-REQ
暴徒_BSHO-REQ
An IEEE 802.16e handover request message sent by a base
station.
基地局によって送られたIEEE 802.16e引き渡し要求メッセージ。
MOB_HO-IND
_に群がってください、おーい、-、インディアン座
An IEEE 802.16e handover indication message sent by a mobile
node.
可動のノードによって送られたIEEE 802.16e引き渡し指示メッセージ。
BSID
BSID
An IEEE 802.16e base station identifier.
IEEE 802.16e基地局識別子。
Jang, et al. Informational [Page 3] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[3ページ]のRFC5270FMIPv6
3. IEEE 802.16e Handover Overview
3. IEEE 802.16e引き渡し概観
Compared with the handover in the WLAN (Wireless Local Area Network), the IEEE 802.16e handover mechanism consists of more steps since the 802.16e embraces the functionality for elaborate parameter adjustment and procedural flexibility.
WLAN(無線のローカル・エリア・ネットワーク)の引き渡しと比べて、802.16eが入念なパラメータ調整と手続き上の柔軟性のための機能性を受け入れるので、IEEE 802.16e引き渡しメカニズムは、より多くのステップから成ります。
When a mobile node (MN) stays in a link, it listens to the Layer 2 neighbor advertisement messages, named MOB_NBR-ADV, from its serving base station (BS). A BS broadcasts them periodically to identify the network and announce the characteristics of neighbor BSs. Receiving this, the MN decodes this message to find out information about the parameters of neighbor BSs for its future handover. With the provided information in a MOB_NBR-ADV, the MN may minimize the handover latency by obtaining the channel number of neighbors and reducing the scanning time, or may select the better target BS based on the signal strength, Quality-of-Service (QoS) level, service price, etc.
MOB_NBR-ADVは、可動のノード(ミネソタ)がリンクに滞在すると、Layer2隣人広告メッセージを聞くと命名しました、基地局(BS)に役立つのから。 BSは、ネットワークを特定して、隣人BSsの特性を発表するために定期的に彼らを放送します。 これを受けて、ミネソタは将来の引き渡しに関して隣人BSsのパラメタの情報を見つけるこのメッセージを解読します。ミネソタは、隣人の論理機番を得て、スキャンニング時間を減少させることによって引き渡し潜在を最小にするか、または提供された情報はMOB_NBR-ADVにある状態で、信号強度に基づくより良い目標BS、サービスのQuality(QoS)レベル、サービス価格などを選択するかもしれません。
The handover procedure is conceptually divided into two steps: "handover preparation" and "handover execution" [SH802.16e]. The handover preparation can be initiated by either an MN or a BS.
引き渡し手順は概念的に以下の2ステップに分割されます: 「引き渡し準備」と「引き渡し実行。」[SH802.16e] ミネソタかBSのどちらかが引き渡し準備を開始できます。
During this period, neighbors are compared by the metrics such as signal strength or QoS parameters, and a target BS is selected among them. If necessary, the MN may try to associate (initial ranging) with candidate BSs to expedite a future handover. Once the MN decides to handover, it notifies its intent by sending a MOB_MSHO-REQ message to the serving BS (s-BS). The BS then replies with a MOB_BSHO-RSP containing the recommended BSs to the MN after negotiating with candidates. Optionally, it may confirm handover to the target BS (t-BS) over backbone when the target is decided. Alternatively, the BS may trigger handover with a MOB_BSHO-REQ message.
この期間、隣人は信号強度かQoSパラメタなどの測定基準によって比較されます、そして、目標BSは彼らの中で選択されます。 必要なら、ミネソタは、将来の引き渡しを速めるために候補BSsと交際しようとするかもしれません(初期の及ぶこと)。ミネソタがいったん引き渡しに決めると、給仕BS(s-BS)にMOB_MSHO-REQメッセージを送ることによって、それは意図に通知します。 そして、MOB_BSHO-RSPが候補と交渉した後にお勧めのBSsをミネソタに含んでいて、BSは返答します。 目標が決められるとき、任意に、それは背骨の上の目標BS(t-BS)に引き渡しを確認するかもしれません。 あるいはまた、BSはMOB_BSHO-REQメッセージで引き渡しの引き金となるかもしれません。
After handover preparation, handover execution starts. The MN sends a MOB_HO-IND message to the serving BS as a final indication of its handover. Once it makes a new attachment, it conducts 802.16e ranging through which it can acquire physical parameters from the target BS, tuning its parameters to the target BS. After ranging with the target BS successfully, the MN negotiates basic capabilities such as maximum transmit power and modulator/demodulator type. It then performs authentication and key exchange procedures, and finally registers with the target BS. If the target BS has already learned some contexts such as authentication or capability parameters through backbone, it may omit the corresponding procedures. For the details of the 802.16 handover procedures, refer to Section 6.3.22 of [IEEE802.16e]. After completing registration, the target BS starts
引き渡し準備の後に、引き渡し実行は始まります。 ミネソタは引き渡しの最終的なしるしとしてMOB_HO-INDメッセージを給仕BSに送ります。いったん新たな付属を作ると、目標BSから物理的なパラメタを取得できる802.16eの及ぶことを行います、目標BSにパラメタを調整して。 首尾よく、ミネソタが交渉する目標BSと共に及んだ後に、最大などの基本的な能力はパワーと変調器/復調タイプを伝えます。 そして、それは目標BSと共に認証、主要な交換手順、および最終的にレジスタを実行します。 目標BSが背骨を通して既に認証か能力パラメタのいくつかの文脈を学んだなら、それは対応する手順を省略するかもしれません。 802.16の引き渡し手順の詳細について、.22セクション6.3[IEEE802.16e]を参照してください。 登録を終了した後に、目標BSは始まります。
Jang, et al. Informational [Page 4] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[4ページ]のRFC5270FMIPv6
to serve the MN and communication via target BS is available. However, in case the MN moves to a different subnet, it should reconfigure a new IP address and reestablish an IP connection. To resume the active session of the previous link, the MN should also perform IP layer handover.
目標BSを通してミネソタとコミュニケーションに役立つのは利用可能です。 しかしながら、ミネソタが異なったサブネットに動くといけないので、それは、新しいIPアドレスを再構成して、IP接続を回復させるべきです。 また、前のリンクの活発なセッションを再開するために、ミネソタはIP層の引き渡しを実行するべきです。
4. Network Topology Acquisition and Network Selection
4. ネットワーク形態獲得とネットワーク選択
This section describes how discovery of adjacent networks and selection of target network work in the IEEE 802.16e for background information.
このセクションは隣接しているネットワークの発見と目標ネットワークの選択はIEEE 802.16eでどう効き目があるかを基礎的な情報に説明します。
An MN can learn the network topology and acquire the link information in several ways. First of all, it can do that via L2 neighbor advertisements. A BS supporting mobile functionality shall broadcast a MOB_NBR-ADV message periodically that includes the network topology information (its maximum interval is 1 second). This message includes BSIDs and channel information of neighbor BSs, and it is used to facilitate the MN's synchronization with neighbor BSs. An MN can collect the necessary information of the neighbor BSs through this message for its future handover.
ミネソタは、いくつかの方法でネットワーク形態を学んで、リンク情報を取得できます。 まず、それはL2隣人広告でそれができます。 可動の機能性を支持するBSは定期的に、それがネットワーク形態情報を含んでいるという(最大の間隔は1秒です)MOB_NBR-ADVメッセージを放送するものとします。 このメッセージは隣人BSsに関するBSIDsと経路情報を含んでいます、そして、それは、隣人BSsとのミネソタの同期を容易にするのに使用されます。 ミネソタは将来の引き渡しへのこのメッセージを通して隣人BSsに関する必要事項を集めることができます。
Another method for acquisition of network topology is scanning, which is the process to seek and monitor available BSs in order to find suitable handover targets. While a MOB_NBR-ADV message includes static information about neighbor BSs, scanning provides rather dynamic parameters such as link quality parameters. Since the MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically and scanning provides a way to sort out some adequate BSs, it is recommended that when new BSs are found in the advertisement, the MN identifies them via scanning and resolves their BSIDs to the information of the subnet where the BS is connected. The association, an optional initial ranging procedure occurring during scanning, is one of the helpful methods to facilitate the impending handover. The MN is able to get ranging parameters and service availability information for the purpose of proper selection of the target BS and expediting a potential future handover to it. The detailed explanation of association is described in Section 6.3.22 of [IEEE802.16e].
ネットワーク形態の獲得のための別の方法(適当な引き渡し目標を見つける求める過程とモニターの利用可能なBSsである)は、スキャンされています。 MOB_NBR-ADVメッセージは隣人BSsの静的な情報を含んでいますが、スキャンはリンクなどのかなりダイナミックなパラメタに上質のパラメタを提供します。 MOB_NBR-ADVメッセージが定期的に隣人BSIDsのリストを届けて、スキャンがいくつかの適切なBSsを整理する方法を提供するので、新しいBSsが広告で見つけられるとき、ミネソタがBSが接続されているところでスキャンで彼らを特定して、サブネットの情報に彼らのBSIDsを決議するのは、お勧めです。 協会(スキャンの間に起こる任意の初期の及んでいる手順)は差し迫っている引き渡しを容易にする役立っている方法の1つです。ミネソタは、目標BSと潜在的将来の引き渡しを速めるそれへの適切な選択の目的のためにパラメタを及ぶのに得ることができて、有用性情報をサービスに得ることができます。 協会の詳説は.22セクション6.3[IEEE802.16e]で説明されます。
Besides the methods provided by 802.16e, the MN may rely on other schemes. For instance, the topology information may be provided through the MIIS (Media Independent Information Service) [IEEE802.21], which has been developed by the IEEE 802.21 working group. The MIIS is a framework by which the MN or network can obtain network information to facilitate network selection and handovers.
802.16eによって提供された方法以外に、ミネソタは他の計画を当てにするかもしれません。 例えば、MIIS(メディア無党派情報Service)[IEEE802.21]を通してトポロジー情報を提供するかもしれません。MIISはIEEE802.21ワーキンググループによって開発されました。 MIISはミネソタかネットワークがネットワーク選択と身柄の引き渡しを容易にするためにネットワーク情報を得ることができる枠組みです。
Jang, et al. Informational [Page 5] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[5ページ]のRFC5270FMIPv6
After learning about neighbors, the MN may compare them to find a BS, which can serve better than the serving BS. The target BS may be determined by considering various criteria such as required QoS, cost, user preference, and policy. How to select the target BS is not in the scope of this document.
隣人に関して学んだ後に、ミネソタは、BSを見つけるために彼らを比較するかもしれません。(BSは給仕BSより一層役立つことができます)。 目標BSは、必要なQoSや、費用や、ユーザー選択や、方針などの様々な評価基準を考えることによって、決定するかもしれません。 どう目標BSを選択するかがこのドキュメントの範囲にありません。
5. Interaction between FMIPv6 and IEEE 802.16e
5. FMIPv6とIEEE 802.16eとの相互作用
In this section, a set of primitives is introduced for an efficient interleaving of the IEEE 802.16e and the FMIPv6 procedures as below. The following sections present the handover procedures in detail by using them.
このセクションでは、1セットの基関数はIEEE 802.16eの効率的な同じくらいインターリービングと以下のFMIPv6同じくらい手順のために紹介されます。 以下のセクションは、それらを使用することによって、詳細に引き渡し手順を提示します。
o NEW_LINK_DETECTED (NLD)
o _が検出した新しい_リンク(NLD)
A trigger from the link layer to the IP layer in the MN to
report that a new link has been detected.
新しいリンクが検出されたと報告するミネソタのリンクレイヤからIP層までの引き金。
o LINK_HANDOVER_IMPEND (LHI)
o リンク_引き渡し_は迫ります。(LHI)
A trigger from the link layer to the IP layer in the MN to
report that a link-layer handover decision has been made and
its execution is imminent.
リンクレイヤ引き渡し決定をしたと報告するミネソタのリンクレイヤからIP層までの引き金とその実行は差し迫っています。
o LINK_SWITCH (LSW)
o リンク_スイッチ(LSW)
A control command from the IP layer to the link layer in the MN
in order to force the MN to switch from an old BS to a new BS.
IP層からリンクまでの制御コマンドは、ミネソタを古いBSから新しいBSに切り換えさせるためにミネソタで層にされます。
o LINK_UP (LUP)
o _をリンクしてください。(LUP)
A trigger from the link layer to the IP layer in the MN to
report that the MN completes the link-layer connection
establishment with a new BS.
ミネソタが新しいBSとのリンクレイヤコネクション確立を終了すると報告するミネソタのリンクレイヤからIP層までの引き金。
5.1. Access Router Discovery
5.1. アクセスルータ発見
Once a new BS is detected through reception of a MOB_NBR-ADV and scanning, an MN may try to learn the associated access router (AR) information as soon as possible. In order to enable its quick discovery in the IP layer, the link layer (802.16) triggers a NEW_LINK_DETECTED primitive to the IP layer (FMIPv6) on detecting a new BS.
新しいBSがMOB_NBR-ADVとスキャンのレセプションでいったん検出されると、ミネソタはできるだけ早く、関連アクセスルータ(AR)情報を学ぼうとするかもしれません。 IP層の中で迅速な発見を可能にするために、リンクレイヤ(802.16)は新しいBSを検出するときIP(FMIPv6)層に原始的にNEW_LINK_DETECTEDの引き金となります。
Receiving the NEW_LINK_DETECTED from the link layer, the IP layer tries to learn the associated AR information by exchanging an RtSolPr (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy Router Advertisement) with the PAR (Previous Access Router).
リンクレイヤからNEW_LINK_DETECTEDを受けて、IP層は、PAR(前のAccess Router)と共にRtSolPr(Proxy AdvertisementのためのルータSolicitation)とPrRtAdv(プロキシRouter Advertisement)を交換することによって、関連AR情報を学ぼうとします。
Jang, et al. Informational [Page 6] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[6ページ]のRFC5270FMIPv6
According to [RFC5268], the MN may send an RtSolPr at any convenient time. However, this proposal recommends that, if feasible, the MN send it as soon as possible after receiving the NEW_LINK_DETECTED for quick router discovery because detection of a new BS usually implies MN's movement, which may result in handover.
[RFC5268]に従って、ミネソタは都合のよい時にRtSolPrを送るかもしれません。 しかしながら、新しいBSの検出が通常、ミネソタの動き(引き渡しをもたらすかもしれない)を含意するので、この提案は、ミネソタが可能であるならできるだけ早く迅速なルータ発見のためにNEW_LINK_DETECTEDを受けながらそれについて伝言を伝えることを勧めます。
Transmission of RtSolPr messages may cause the signaling overhead problem that is mentioned in Section 2 of [RFC4907]. To rate-limit the retransmitted RtSolPr messages, FMIPv6 provides a back-off mechanism. It is also possible that attackers may forge a MOB_NBR- ADV message so that it can contain a bunch of bogus BSIDs or may send a flood of MOB_NBR-ADV messages each of which contains different BSIDs. This problem is mentioned in Section 8.
RtSolPrメッセージの伝達は[RFC4907]のセクション2で言及される合図している頭上の問題を引き起こすかもしれません。 再送されたRtSolPrメッセージをレートで制限するために、FMIPv6は下に後部メカニズムを提供します。 また、攻撃者が多くのにせのBSIDsを含むことができるようにMOB_NBR- ADVメッセージを作り出すかもしれないか、またはそれのそれぞれが異なったBSIDsを含むMOB_NBR-ADVメッセージの洪水を送るのも、可能です。 この問題はセクション8で言及されます。
5.2. Handover Preparation
5.2. 引き渡し準備
When the MN decides to change links based on its policy such as the degrading signal strength or increasing packet loss rate, it initiates handover by sending a MOB_MSHO-REQ to the BS and will receive a MOB_BSHO-RSP from the BS as a response. Alternatively, the BS may initiate handover by sending a MOB_BSHO-REQ to the MN.
ミネソタが、下劣な信号強度か増加するパケット損失率などの方針に基づくリンクを変えると決めると、それは、MOB_MSHO-REQをBSに送ることによって引き渡しを開始して、応答としてBSからMOB_BSHO-RSPを受けるでしょう。 あるいはまた、BSは、MOB_BSHO-REQをミネソタに送ることによって、引き渡しを開始するかもしれません。
On receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ, the link layer triggers a LINK_HANDOVER_IMPEND in order to signal the IP layer of arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly. At this time, the target BS decided in the link layer is delivered to the IP layer as a parameter of the primitive. The primitive is used to report that a link-layer handover decision has been made and its execution is imminent. It can be helpfully used for FMIPv6 as an indication to start the handover preparation procedure, that is to send an FBU (Fast Binding Update) message to the PAR.
MOB_BSHO-RSPかMOB_BSHO-REQのどちらかを受けると、リンクレイヤは、すぐにMOB_BSHO-REQ/MOB_BSHO-RSPの到着のIP層に合図するためにLINK_HANDOVER_IMPENDの引き金となります。 このとき、原始のパラメタとしてリンクレイヤの中で決められた目標BSをIP層に渡します。 原始は、リンクレイヤ引き渡し決定をして、実行が差し迫っていると報告するのに使用されます。 それは、指示としてのFMIPv6が引き渡し準備手順を始めるのにそれを役立って使用できて、FBU(速いBinding Update)メッセージをPARに送ることになっています。
To avoid erroneous results due to unreliable and inconsistent characteristics of link, for instance, to move to the unpredicted network or to stay in the current network after sending an FBU, Section 2 of [RFC4907] advises the use of a combination of signal strength data with other techniques rather than relying only on signal strength for handover decision. For example, the LINK_HANDOVER_IMPEND may be sent after validating filtered signal strength measurements with other indications of link loss such as lack of beacon reception.
例えば、リンクの頼り無くて矛盾した特性のため非予測されたネットワークに動くか、またはFBUを送った後に現在のネットワークで滞在するために誤った結果を避けるために、[RFC4907]のセクション2は引き渡し決定のために唯一のオン信号の強さに当てにするよりむしろ他のテクニックへの信号強度データの組み合わせを使用に知らせます。 例えば、フィルターにかけることの信号強度測定値を有効にした後に、標識レセプションの不足などのリンクの損失の他のしるしはLINK_HANDOVER_IMPENDを送るかもしれません。
Once the IP layer receives the LINK_HANDOVER_IMPEND, it checks whether or not the specified target network belongs to a different subnet based on the information collected during the Access Router Discovery step. If the target proves to be in the same subnet, the MN can continue to use the current IP address after handover, and there is no need to perform FMIPv6. Otherwise, the IP layer
指定された目標ネットワークがAccess Routerディスカバリーステップの間に集められた情報に基づく異なったサブネットに属すか否かに関係なく、それは、一度、IP層がLINK_HANDOVER_IMPENDを受けるのをチェックします。 目標が同じサブネットにはあると判明するなら、ミネソタは、引き渡しの後に現在のIPアドレスを使用し続けることができます、そして、FMIPv6を実行する必要は全くありません。 そうでなければ、IP層
Jang, et al. Informational [Page 7] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[7ページ]のRFC5270FMIPv6
formulates a prospective NCoA (New Care-of Address) with the information provided in the PrRtAdv message and sends an FBU message to the PAR.
将来のNCoAを定式化する、(新しさ、Care、-、Address) PARへのFBUメッセージは、情報と共に、PrRtAdvメッセージに提供して、発信しています。
When the FBU message arrives in the PAR successfully, the PAR and the NAR (New Access Router) process it according to [RFC5268]. The PAR sets up a tunnel between the PCoA (Previous Care-of Address) and NCoA by exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) messages with the NAR, forwarding the packets destined for the MN to the NCoA. The NCoA is confirmed or re-assigned by the NAR in the HAck and, finally delivered to the MN through the FBack (Fast Binding Acknowledgment) in case of predictive mode.
FBUメッセージが首尾よくPARに到着するとき、[RFC5268]に従って、PARとNAR(新しいAccess Router)はそれを処理します。 PARセットがPCoAの間のトンネルを上げる、(前である、Care、-、Address) そして、ミネソタに運命づけられたパケットをNCoAに送って、NARと共にHI(引き渡しInitiate)とHAck(引き渡しAcknowledge)メッセージを交換するのによるNCoA。 NCoAはHAckのNARによって確認されるか、または再選任されます、そして、最終的に、(速いBinding Acknowledgment)は予言のモードの場合にFBackを通してミネソタに配送しました。
After the MN sends a MOB_HO-IND to the serving BS, data packet transfer between the MN and the BS is no longer allowed. Note that when a MOB_HO-IND is sent out before an FBack arrives in the MN, it is highly probable that the MN will operate in reactive mode because the serving BS releases all the MN's connections and resources after receiving a MOB_HO-IND. Therefore, if possible, the MN should exchange FBU and FBack messages with the PAR before sending a MOB_HO- IND to the BS so as to operate in predictive mode.
ミネソタがMOB_HO-INDを給仕BSに送った後に、ミネソタとBSの間のデータ・パケット転送はもう許容されていません。 FBackがミネソタに到着する前にMOB_HO-INDを出すとき、MOB_HO-INDを受けた後に給仕BSがすべてのミネソタの接続とリソースを釈放するのでミネソタが反応モードで作動するのが、非常にありえそうであることに注意してください。 したがって、できれば、予言のモードで作動するためにMOB_HO- INDをBSに送る前に、ミネソタはFBUとFBackメッセージをPARと交換するべきです。
5.3. Handover Execution
5.3. 引き渡し実行
If the MN receives an FBack message on the previous link, it runs in predictive mode after handover. Otherwise, it should run in reactive mode. In order for the MN to operate in predictive mode as far as possible after handover, implementations may allow use of a LINK_SWITCH primitive. The LINK_SWITCH is a command in order to force the MN to switch from an old BS to a new BS and the similar concept has introduced for the wireless LAN in [RFC5184]. When it is applied, the MN's IP layer issues a LINK_SWITCH primitive to the link layer on receiving the FBack message in the previous link. Until it occurs, the link layer keeps the current (previous) link if feasible and postpones sending a MOB_HO-IND message while waiting for the FBack message.
ミネソタが前のリンクに関するFBackメッセージを受け取るなら、それは引き渡しの後に予言のモードへ駆け込みます。さもなければ、反応モードに立候補するべきです。 ミネソタが引き渡しの後に予言のモードでできるだけ運用するように、実現は原始的にLINK_SWITCHの使用を許すかもしれません。 LINK_SWITCHは、ミネソタを新しいBSと同様の概念へのBSが[RFC5184]の無線LANのために紹介した老人から切り換えさせるためにはコマンドです。 それが適用されているとき、ミネソタIP層は前のリンクにFBackメッセージを受け取るときのリンクレイヤへの原始のLINK_SWITCHを発行します。 リンクレイヤは、起こるまで可能であるなら現在(前の)のリンクを保って、FBackメッセージを待っている間、MOB_HO-INDメッセージを送るのを延期します。
After switching links, the MN synchronizes with the target BS and performs the 802.16e network entry procedure. The MN exchanges the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP, and REG-REQ/RSP messages with the target BS. Some of these messages may be omitted if the (previously) serving BS transferred the context to the target BS over the backbone beforehand. When the network entry procedure is completed and the link layer is ready for data transmission, it informs the IP layer of the fact with a LINK_UP primitive.
リンクを切り換えた後に、ミネソタは、目標BSに連動して、802.16eネットワークエントリー手順を実行します。 ミネソタは目標BSと共にRNG-REQ/RSP、SBC-REQ/RSP、PKM-REQ/RSP、およびREG-REQ/RSPメッセージを交換します。 (以前に)役立っているBSがあらかじめ背骨の上の目標BSに文脈を移したなら、これらのメッセージのいくつかが省略されるかもしれません。 ネットワークエントリー手順が完了していて、リンクレイヤがデータ伝送の準備ができているとき、LINK_UPが原始的にそれは事実のIP層を知らせます。
Jang, et al. Informational [Page 8] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[8ページ]のRFC5270FMIPv6
Section 2 of [RFC4907] recommends that link indications should be designed with built-in damping. The LINK_UP primitive defined in this document is generated by the link layer state machine based on the 802.16e link layer message exchanges, that is, the IEEE 802.16e network entry and the service flow creation procedures. Therefore, the LINK_UP is typically less sensitive to changes in transient link conditions. The link may experience an intermittent loss. Even in such a case, the following FMIPv6 operation is performed only when the MN handovers to the link with a different subnet and there is no signaling overhead as a result of a intermittent loss.
[RFC4907]のセクション2は、リンク指摘が湿気内蔵設計されるべきであることを勧めます。 本書では定義されたLINK_UP基関数はすなわち、802.16eリンクレイヤ交換処理、IEEE 802.16eネットワークエントリーに基づくリンクレイヤ州のマシンとサービス流れ創造手順で発生します。 したがって、LINK_UPは一時的なリンク状態における変化に通常敏感ではありません。 リンクは間欠損失を経験するかもしれません。 そのような場合ではさえ、ミネソタが異なったサブネットとのリンクに引き渡して、間欠損失の結果、そこでオーバーヘッドに合図していないときだけ、以下のFMIPv6操作は実行されます。
5.4. Handover Completion
5.4. 引き渡し完成
When the MN's IP layer receives a LINK_UP primitive from the link layer, it should check whether it has moved into the target network predicted by FMIPv6. In case the target BS is within the same subnet, the MN does not perform the FMIPv6 operation.
ミネソタIP層がリンクレイヤからの原始のLINK_UPを受けるとき、それは、FMIPv6によって予測された目標ネットワークに動いたかどうかチェックするべきです。 同じサブネットの中に目標BSがあるといけないので、ミネソタはFMIPv6操作を実行しません。
* If the MN discovers itself in the predicted target network and
receives an FBack message in the previous link, the MN's IP
layer sends an UNA (Unsolicited Neighbor Advertisement) to the
NAR (predictive mode).
* ミネソタが予測された目標ネットワークでそれ自体を発見して、前のリンクにFBackメッセージを受け取るなら、ミネソタIP層はUNA(求められていないNeighbor Advertisement)をNAR(予言のモード)に送ります。
* If the MN has moved to the target network without receiving an
FBack message in the previous link, the IP layer sends an UNA
and also an FBU message immediately after sending the UNA
message (reactive mode). The NAR may provide a different IP
address by using an RA (Router Advertisement) with a NAACK
(Neighbor Advertisement Acknowledge) option other than the
formulated NCoA by the MN.
* ミネソタが前のリンクにFBackメッセージを受け取ることのない目標ネットワークに動いたなら、UNAメッセージ(反応モード)を送る直後IP層はUNAとFBUメッセージも送ります。 NARは、RA(ルータAdvertisement)を使用することによって、ミネソタのそばの定式化されたNCoA以外のNAACK(隣人Advertisement Acknowledge)オプションに異なったIPアドレスを提供するかもしれません。
* The MN may discover itself in the unpredicted network
(erroneous movement). If this is the case, the MN moves to the
network that is not the target specified in the
LINK_HANDOVER_IMPEND primitive. For the recovery from such an
invalid indication, which is mentioned in Section 2 of
[RFC4907], the MN should send a new FBU to the PAR according to
Section 5.6 of [RFC5268] so that the PAR can update the
existing binding entry and redirect the packets to the new
confirmed location.
* 非予測されたネットワーク(誤った運動)でミネソタはそれ自体を発見するかもしれません。 これがそうであるなら、ミネソタはLINK_HANDOVER_IMPENDで原始的に指定された目標でないネットワークに動きます。 そのような無効の指示からの回復のために、どれが[RFC4907]、ミネソタのセクション2で言及されるかが、PARがエントリーを縛りながら存在をアップデートできるように[RFC5268]のセクション5.6に応じて新しいFBUをPARに送って、新しい確認された位置にパケットを向け直すべきです。
In both cases of predictive and reactive modes, once the MN has moved into the new link, it uses the NCoA formulated by the MN as a source address of the UNA, irrespective of NCoA availability. It then starts a Duplicate Address Detection (DAD) probe for NCoA according to [RFC4862]. In case the NAR provides the MN with a new NCoA, the MN MUST use the provided NCoA instead of the NCoA formulated by the MN.
どちらの場合も、ミネソタがいったん新しいリンクに動くと、予言的で反応しているモードで、UNAのソースアドレスとしてミネソタによって定式化されたNCoAを使用します、NCoAの有用性の如何にかかわらず。 そして、[RFC4862]に従って、それはNCoAのために、(DAD)が調べるDuplicate Address Detectionを始動します。 NARが新しいNCoAをミネソタに提供するといけないので、ミネソタはミネソタによって定式化されたNCoAの代わりに提供されたNCoAを使用しなければなりません。
Jang, et al. Informational [Page 9] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[9ページ]のRFC5270FMIPv6
When the NAR receives an UNA message, it deletes its proxy neighbor cache entry if it exists, and forwards buffered packets to the MN after updating the neighbor cache properly. Detailed UNA processing rules are specified in Section 6.4 of [RFC5268].
NARがUNAメッセージを受け取るとき、存在しているなら、プロキシ隣人キャッシュエントリーを削除します、そして、適切に隣人キャッシュをアップデートした後に、フォワードはミネソタにパケットをバッファリングしました。 詳細なUNA処理規則は[RFC5268]のセクション6.4で指定されます。
6. The Examples of Handover Scenario
6. 引き渡しシナリオに関する例
In this section, the recommended handover procedures over 802.16e network are shown for both predictive and reactive modes. It is assumed that the MN handovers to the network that belongs to a different subnet.
このセクションで、802.16eネットワークの上のお勧めの引き渡し手順は予言的で反応の両方であっているモードのために示されます。 ミネソタがそれをネットワークに引き渡すと思われます。異なったサブネットに属します。
In the following figures, the messages between the MN's Layer 2 (MN L2) and the BS are the IEEE 802.16 messages, while messages between the MN's Layer 3 (MN L3) and the PAR and messages between PAR and NAR are the FMIPv6 messages. The messages between the MN L2 and the MN L3 are primitives introduced in this document.
以下の数字では、ミネソタのLayer2(MN L2)とBSの間のメッセージは802.16が通信させるIEEEです、ミネソタのLayer3(MN L3)とPARの間のメッセージとPARとNARの間のメッセージはFMIPv6メッセージですが。 MN L2とMN L3の間のメッセージは本書では紹介された基関数です。
6.1. Predictive Mode
6.1. 予言のモード
The handover procedures in the predictive mode are briefly described as follows. Figure 3 illustrates these procedures.
予言のモードによる引き渡し手順は以下の通り簡潔に説明されます。 図3はこれらの手順を例証します。
1. A BS broadcasts a MOB_NBR-ADV periodically.
1. BSは定期的にMOB_NBR-ADVを放送します。
2. If the MN discovers a new neighbor BS in this message, it may
perform scanning for the BS.
2. ミネソタがこのメッセージで新しい隣人BSを発見するなら、それはBSのためにスキャンを実行するかもしれません。
3. When a new BS is found through the MOB_NBR-ADV and scanning,
the MN's link layer notifies it to the IP layer by a
NEW_LINK_DETECTED primitive.
3. 新しいBSがMOB_NBR-ADVを通して見つけられて、スキャンしているとき、ミネソタのリンクレイヤはNEW_LINK_DETECTEDでIP層にそれに原始的に通知します。
4. The MN tries to resolve the new BS's BSID to the associated
AR by exchange of RtSolPr and PrRtAdv messages with the PAR.
4. ミネソタはPARがあるRtSolPrとPrRtAdvメッセージの交換で新しいBSのBSIDを関連ARに決議しようとします。
5. The MN initiates handover by sending a MOB_MSHO-REQ message
to the BS and receives a MOB_BSHO-RSP from the BS.
Alternatively, the BS may initiate handover by sending a
MOB_BSHO-REQ to the MN.
5. ミネソタは、MOB_MSHO-REQメッセージをBSに送ることによって引き渡しを開始して、BSからMOB_BSHO-RSPを受けます。 あるいはまた、BSは、MOB_BSHO-REQをミネソタに送ることによって、引き渡しを開始するかもしれません。
6. When the MN receives either a MOB_BSHO-RSP or a MOB_BSHO-REQ
from the BS, its link layer triggers a LINK_HANDOVER_IMPEND
primitive to the IP layer.
6. ミネソタがBSからMOB_BSHO-RSPかMOB_BSHO-REQのどちらかを受けるとき、リンクレイヤはIP層に原始的にLINK_HANDOVER_IMPENDの引き金となります。
Jang, et al. Informational [Page 10] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[10ページ]のRFC5270FMIPv6
7. On reception of the LINK_HANDOVER_IMPEND, the MN's IP layer
identifies that the target delivered along with the
LINK_HANDOVER_IMPEND belongs to a different subnet and sends
an FBU message to the PAR. On receiving this message, the
PAR establishes tunnel between the PCoA and the NCoA by
exchange of HI and HAck messages with the NAR, and it
forwards packets destined for the MN to the NCoA. During
this time, the NAR may confirm NCoA availability in the new
link via HAck.
7. 目標がLINK_と共に提供したIMPEND、ミネソタのIP層が特定するLINK_HANDOVER_のレセプションでは、HANDOVER_IMPENDは異なったサブネットに属して、FBUメッセージをPARに送ります。 このメッセージを受け取ると、PARはNARと共にHIとHAckメッセージの交換でPCoAとNCoAの間のトンネルを確立します、そして、それはミネソタに運命づけられたパケットをNCoAに送ります。 この間に、NARはHAckを通して新しいリンクでNCoAの有用性を確認するかもしれません。
8. The MN receives the FBack message before its handover and
sends a MOB_HO-IND message as a final indication of handover.
Issue of a MOB_HO-IND may be promoted optionally by using a
LINK_SWITCH command from the IP layer. Afterwards it
operates in predictive mode in the new link.
8. ミネソタは、引き渡しの前にFBackメッセージを受け取って、引き渡しの最終的なしるしとしてMOB_HO-INDメッセージを送ります。MOB_HO-INDの問題は、IP層からLINK_SWITCHコマンドを使用することによって、任意に促進されるかもしれません。 その後、それは新しいリンクの予言のモードで作動します。
9. The MN conducts handover to the target BS and performs the
IEEE 802.16e network entry procedure.
9. ミネソタは、目標BSに引き渡しを行って、IEEE 802.16eネットワークエントリー手順を実行します。
10. As soon as the network entry procedure is completed, the MN's
link layer signals the IP layer with a LINK_UP. On receiving
this, the IP layer identifies that it has moved to a
predicted target network and received the FBack message in
the previous link. It issues an UNA to the NAR by using the
NCoA as a source IP address. At the same time, it starts to
perform DAD for the NCoA.
10. ネットワークエントリー手順が完了しているとすぐに、ミネソタのリンクレイヤはLINK_UPと共にIP層を示します。 これを受けると、IP層は予測された目標ネットワークに動いて、前のリンクにFBackメッセージを受け取ったのを特定します。 それは、ソースIPアドレスとしてNCoAを使用することによって、NARにUNAを発行します。 同時に、それはNCoAのためにDADを実行し始めます。
11. When the NAR receives the UNA from the MN, it delivers the
buffered packets to the MN.
11. NARがミネソタからUNAを受けるとき、それはバッファリングされたパケットをミネソタに届けます。
Jang, et al. Informational [Page 11] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[11ページ]のRFC5270FMIPv6
(MN L3 MN L2) s-BS PAR t-BS NAR
| | | | | |
1-2. | |<---MOB_NBR-ADV --------| | | |
| |<-------Scanning------->| | | |
3. |<-NLD-| | | | |
4. |--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
5. | |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| |<-----MOB_BSHO-REQ------| | | |
6. |<-LHI-| | | | |
7. |------------------FBU---------------->| | |
| | | |--------HI-------->|
| | | |<------HACK--------|
|<-----------------FBack---------------|--> | |
| | | Packets==============>|
8. |(LSW)>|-------MOB_HO-IND------>| | | |
disconnect| | | | |
connect | | | | |
9. | |<---------IEEE 802.16 network entry-------->| |
10. |<-LUP-| | | | |
|----------------------------UNA-------------------------->|
11. |<==================================================== Packets
| | | | |
(Mn L3Mn L2) s-BS平価t-BS NAR| | | | | | 1-2. | | <、-、--暴徒_NBR-ADV--------| | | | | | <、-、-、-、-、-、--スキャン------->|、|、|、| 3. | <、-NLD| | | | | 4. |--------------(RtSolPr)-------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、--PrRtAdv----------------| | | | | | | | | 5. | |------暴徒_MSHO-REQ----->|、|、|、|、| | <、-、-、-、--暴徒_BSHO-RSP------| | | | | | または| | | | | | <、-、-、-、--暴徒_BSHO-REQ------| | | | 6. | <、-LHI| | | | | 7. |------------------FBU---------------->|、|、|、|、|、| |--------こんにちは-------->|、|、|、| | <、-、-、-、-、--ハッキング--------| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--FBack---------------| -->、|、|、|、|、| パケット==============>| 8. |(LSW)>|、-、-、-、-、-、--_に群がってください、おーい、-、インディアン座------>|、|、|、| 分離| | | | | 接続してください。| | | | | 9. | | <、-、-、-、-、-、-、-、--IEEE802.16ネットワークエントリー-------->|、| 10. | <、-LUP| | | | | |----------------------------ウナ-------------------------->| 11. |<========================== パケット| | | | |
Figure 3. Predictive Fast Handover in 802.16e
図3。 802.16eの予言の速い引き渡し
6.2. Reactive Mode
6.2. 反応モード
The handover procedures in the reactive mode are described as follows. Figure 4 is illustrating these procedures.
反応モードによる引き渡し手順は以下の通り説明されます。 図4はこれらの手順を例証しています。
1. ~ 7. The same as procedures of predictive mode.
1. ~ 7. 予言のモードの手順と同じです。
8. The MN does not receive the FBack message before handover and
sends a MOB_HO-IND message as a final indication of handover.
Afterwards, it operates in reactive mode in the new link.
8. ミネソタは、引き渡しの前にFBackメッセージを受け取らないで、引き渡しの最終的なしるしとしてMOB_HO-INDメッセージを送ります。その後、それは新しいリンクの反応モードで作動します。
9. The MN conducts handover to the target network and performs
the 802.16e network entry procedure.
9. ミネソタは、目標ネットワークに引き渡しを行って、802.16eネットワークエントリー手順を実行します。
Jang, et al. Informational [Page 12] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[12ページ]のRFC5270FMIPv6
10. As soon as the network entry procedure is completed, the MN's
link layer signals the IP layer with a LINK_UP. On receiving
this, the IP layer identifies that it has moved to the
predicted target network without receiving the FBack in the
previous link. The MN issues an UNA to the NAR by using NCoA
as a source IP address and starts to perform DAD for the
NCoA. Additionally, it sends an FBU to the PAR in the
reactive mode.
10. ネットワークエントリー手順が完了しているとすぐに、ミネソタのリンクレイヤはLINK_UPと共にIP層を示します。 これを受けると、IP層は、それが前のリンクでFBackを受けないで予測された目標ネットワークに動いたのを特定します。 ミネソタは、ソースIPアドレスとしてNCoAを使用することによってNARにUNAを発行して、NCoAのためにDADを実行し始めます。 さらに、それは反応モードでFBUをPARに送ります。
11. When the NAR receives the UNA and the FBU from the MN, it
forwards the FBack to the PAR. The FBack and Packets are
forwarded from the PAR and delivered to the MN (NCoA) through
the NAR. The NAR may supply a different IP address than the
NCoA by sending an RA with a NAACK option to the MN.
11. NARがミネソタからUNAとFBUを受けるとき、それはFBackをPARに送ります。 NARを通してFBackとPacketsをPARから送って、ミネソタ(NCoA)に届けます。 NARはNAACKオプションと共にRAをミネソタに送るのによるNCoAと異なったIPアドレスを供給するかもしれません。
(MN L3 MN L2) s-BS PAR t-BS NAR
| | | | | |
1-2. | |<---MOB_NBR-ADV & Scan--| | | |
| |<-------Scanning------->| | | |
3. |<-NLD-| | | | |
4. |--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
5. | |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| |<-----MOB_BSHO-REQ------| | | |
6. |<-LHI-| | | | |
7. |--------FBU----X---> | | | |
8. | |-------MOB_HO-IND------>| | | |
disconnect| | | | |
connect | | | | |
9. | |<---------IEEE 802.16 network entry-------->| |
10. |<-LUP-| | | | |
|----------------------------UNA-------------------------->|
|----------------------------FBU--------------------------)|
11. | | | |<-------FBU-------)|
| | | |<-----HI/HAck----->|
| | | | (if necessary) |
| | | Packets & FBack=========>|
|<=========================================================|
| | | | | |
(Mn L3Mn L2) s-BS平価t-BS NAR| | | | | | 1-2. | | <、-、--_NBR-ADVに群がってください、そして、スキャンしてください--| | | | | | <、-、-、-、-、-、--スキャン------->|、|、|、| 3. | <、-NLD| | | | | 4. |--------------(RtSolPr)-------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、--PrRtAdv----------------| | | | | | | | | 5. | |------暴徒_MSHO-REQ----->|、|、|、|、| | <、-、-、-、--暴徒_BSHO-RSP------| | | | | | または| | | | | | <、-、-、-、--暴徒_BSHO-REQ------| | | | 6. | <、-LHI| | | | | 7. |--------FBU----X--->|、|、|、| 8. | |-------_に群がってください、おーい、-、インディアン座------>|、|、|、| 分離| | | | | 接続してください。| | | | | 9. | | <、-、-、-、-、-、-、-、--IEEE802.16ネットワークエントリー-------->|、| 10. | <、-LUP| | | | | |----------------------------ウナ-------------------------->| |----------------------------FBU--------------------------)| 11. | | | | <、-、-、-、-、-、--FBU-------)| | | | | <、-、-、-、--HI/ハッキング----->|、|、|、|、| (必要なら) | | | | パケットとFBack=========>| |<=============================| | | | | | |
Figure 4. Reactive Fast Handover in 802.16e
図4。 802.16eの反応速い引き渡し
Jang, et al. Informational [Page 13] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[13ページ]のRFC5270FMIPv6
7. IEEE 802.21 Considerations
7. IEEE802.21問題
It is worth noting that great research has been conducted on defining generic services in the IEEE 802.21 working group that facilitate handovers between heterogeneous access links. The standard works are named as a Media Independent Handover (MIH) Service [IEEE802.21], and propose three kinds of services: Media Independent Event Service (MIES), Media Independent Command Service (MICS), and Media Independent Information Service (MIIS).
IEEE802.21ワーキンググループにおける身柄の引き渡しを容易にする一般的なサービスを定義するときかなりの研究が異種のアクセスリンクの間に行われたことに注意する価値があります。 メディア無党派Handover(MIH)が[IEEE802.21]を修理して、3種類のサービスを提案するとき、標準の作品は命名されます: メディア独立事象サービス(ミース)、メディア独立しているコマンドサービス(MICS)、およびメディア独立している情報サービス(MIIS。)
An MIES defines the events triggered from lower layers (physical and link) to higher layers (network and above) in order to report changes of physical and link-layer conditions. On the other hand, an MICS supports the commands sent from higher layers to lower layers, and it provides users with a way of managing the link behavior relevant to handovers and mobility. An MIIS provides a framework by which the MN or network can obtain network information to facilitate network selection and handovers.
ミースは身体検査とリンクレイヤ状態の変化を報告するために下層(身体検査とリンク)から、より高い層(ネットワークと上)まで引き起こされた出来事を定義します。 他方では、MICSは層を下ろすために、より高い層から送られたコマンドをサポートします、そして、それは身柄の引き渡しと移動性に関連しているリンクの振舞いを管理する方法をユーザに提供します。 MIISはミネソタかネットワークがネットワーク選択と身柄の引き渡しを容易にするためにネットワーク情報を得ることができる枠組みを提供します。
Although the purpose of IEEE 802.21 has been developed to enhance the user experience of MNs roaming between heterogeneous networks, the results may be utilized to optimize the handover performance in a homogeneous network. When the MIH primitives are available for handover in the 802.16e network, the MN can use them instead of the primitives proposed in this document. Table 1 shows examples of the mapping between the proposed primitives and the MIH primitives.
MNsが異機種ネットワークの間を移動するユーザー・エクスペリエンスを機能アップするためにIEEE802.21の目的を開発してありますが、結果は、同次のネットワークで引き渡し性能を最適化するのに利用されるかもしれません。 MIH基関数が802.16eネットワークにおける引き渡しに利用可能であるときに、ミネソタは本書では提案された基関数の代わりにそれらを使用できます。 テーブル1は提案された基関数とMIH基関数の間のマッピングに関する例を示しています。
+-------------------------+-------------------------+
| Proposed primitives | MIH primitives |
+===================================================+
| NEW_LINK_DETECTED | LINK_DETECTED |
+---------------------------------------------------+
| LINK_HANDOVER_IMPEND | LINK_HANDOVER_IMMINENT |
+---------------------------------------------------+
| LINK_SWITCH | HANDOVER_COMMIT |
+---------------------------------------------------+
| LINK_UP | LINK_UP |
+---------------------------------------------------+
+-------------------------+-------------------------+ | 提案された基関数| MIH基関数| +===================================================+ | _が検出した新しい_リンク| _が検出したリンク| +---------------------------------------------------+ | リンク_引き渡し_は迫ります。| リンク_引き渡し_差し迫っています。| +---------------------------------------------------+ | リンク_スイッチ| 引き渡し_は公約します。| +---------------------------------------------------+ | _をリンクしてください。| _をリンクしてください。| +---------------------------------------------------+
Table 1. The Proposed Primitives and MIH Primitives
1を見送ってください。 提案された基関数とMIH基関数
8. Security Considerations
8. セキュリティ問題
The primitives defined in this document are used only for local indication inside of the MN, so no security mechanism is required to protect those primitives. However, FMIPv6 messages and IEEE 802.16e messages, which may trigger the primitives, need to be protected.
本書では定義された基関数がミネソタの地方の指示内部にだけ使用されるので、セキュリティー対策は全くそれらの基関数を保護する必要はありません。 しかしながら、FMIPv6メッセージとIEEE 802.16eメッセージ(基関数の引き金となるかもしれない)は、保護される必要があります。
Jang, et al. Informational [Page 14] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[14ページ]のRFC5270FMIPv6
Security considerations of the FMIPv6 specification [RFC5268] are applicable to this document. It is also worthwhile to note that the IEEE802.16e has a security sub-layer that provides subscribers with privacy and authentication over the broadband wireless network. This layer has two main component protocols: a privacy key management protocol (PKM) for key management and authentication and an encapsulation protocol for encrypting data. From the perspective of the 802.16e, FMIPv6 messages are considered as data and are delivered securely by using those protocols.
FMIPv6仕様[RFC5268]のセキュリティ問題はこのドキュメントに適切です。 また、IEEE802.16eには広帯域のワイヤレス・ネットワークの上でプライバシーと認証を加入者に提供するセキュリティ副層があることに注意する価値があります。 この層には、2つの主なコンポーネントプロトコルがあります: プライバシーかぎ管理はかぎ管理と認証のための(PKM)とデータをコード化するためのカプセル化プロトコルについて議定書の中で述べます。 802.16eの見解から、FMIPv6メッセージをデータであるとみなして、それらのプロトコルを使用することによって、しっかりと送ります。
However, some of IEEE 802.16e management messages are sent without authentication. For example, there is no protection to secure 802.16e broadcast messages. It may be possible for the attacker to maliciously forge a MOB_NBR-ADV message so that it contains the bogus BSIDs, or send a flood of MOB_NBR-ADV messages having different bogus BSIDs toward the MN. As a result, the MN may trigger a bunch of NEW_LINK_DETECTED primitives and send useless consecutive RtSolPr messages to the PAR, finally resulting in wasting the air resources. Therefore, the MN SHOULD perform scanning when detecting new BSs in the received MOB_NBR-ADV messages in order to assure the included neighbor information.
しかしながら、認証なしでIEEE 802.16e管理メッセージのいくつかを送ります。 例えば、802.16e同報メッセージを保証するために、ノー・プロテクションがあります。 攻撃者がにせのBSIDsを含むように陰湿にMOB_NBR-ADVメッセージを作り出すか、またはMOB_NBR-ADVメッセージの洪水に異なったにせのBSIDsをミネソタに向かって持たせるのが、可能であるかもしれません。 その結果、ミネソタは、多くのNEW_LINK_DETECTED基関数の引き金となって、役に立たない連続したRtSolPrメッセージをPARに送るかもしれません、空気リソースが最終的にむだになるのに結果になって。 したがって、含まれている隣人情報を保証するために受信されたMOB_NBR-ADVメッセージに新しいBSsを検出するとき、MN SHOULDはスキャンを実行します。
It is also possible that attackers try a DoS (Denial-of-Service) attack by sending a flood of MOB_BSHO-REQ messages and triggering LINK_HANDOVER_IMPEND primitives in the MN. But the IEEE 802.16e provides a message authentication scheme for management messages involved in handover as well as network entry procedures by using a message authentication code (MAC) such as HMAC/CMAC (hashed/cipher MAC). Thus, those management messages are protected from the malicious use by attackers who intend to trigger LINK_HANDOVER_IMPEND or LINK_UP primitives in the MN.
また、攻撃者がMOB_BSHO-REQメッセージの洪水を送って、ミネソタでLINK_HANDOVER_IMPEND基関数の引き金となることによってDoS(サービスの否定)攻撃を試みるのも、可能です。 しかし、IEEE 802.16eはHMAC/CMAC(/暗号MACを論じ尽くす)などのメッセージ確認コード(MAC)を使用するのによるネットワークエントリー手順と同様に引き渡しにかかわる管理メッセージの通報認証計画を提供します。 したがって、それらの管理メッセージはミネソタにLINK_HANDOVER_IMPENDの引き金となるつもりである攻撃者かLINK_UP基関数によって悪意がある使用から保護されます。
9. Acknowledgments
9. 承認
Many thanks to the IETF Mobility Working Group members of KWISF (Korea Wireless Internet Standardization Forum) for their efforts on this work. In addition, we would like to thank Alper E. Yegin, Jinhyeock Choi, Rajeev Koodli, Jonne Soininen, Gabriel Montenegro, Singh Ajoy, Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli, and Ved Kafle who have provided technical advice.
この仕事のときに彼らの努力のためにKWISF(韓国WirelessインターネットStandardization Forum)のIETF Mobility作業部会のメンバーをありがとうございます。 さらに、技術的助言を提供したAlper E.Yegin、Jinhyeockチェ、Rajeev Koodli、Jonne Soininen、ガブリエル・モンテネグロ、シンAjoy、芳広オオバ、Behcet Sarikaya、ビジェイDevarapalli、およびVed Kafleに感謝申し上げます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Jang, et al. Informational [Page 15] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[15ページ]のRFC5270FMIPv6
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の国がないアドレス自動構成」、RFC4862、2007年9月。
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers",
RFC 5268, June 2008.
[RFC5268] Koodli、R.、エド、「モバイルIPv6速い身柄の引き渡し」、RFC5268、6月2008日
[IEEE802.16] "IEEE Standard for Local and Metropolitan Area
Networks, Part 16: Air Interface for Fixed Broadband
Wireless Access Systems", IEEE Std 802.16-2004,
October 2004.
[IEEE802.16] 「地方とメトロポリタンエリアネットワークにおける、標準のIEEE、16を分けてください」 「固定広帯域のワイヤレス・アクセスシステムのための空気インタフェース」、IEEE Std802.16-2004、2004年10月。
[IEEE802.16e] "IEEE Standard for Local and Metropolitan Area
Networks, Amendment 2: Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operation
in Licensed Bands and Corrigendum 1", IEEE
Std 802.16e-2005 and IEEE Std 802.16-2004/Cor 1-2005,
February 2006.
[IEEE802.16e]、「地方とメトロポリタンエリアネットワークのIEEE規格、修正2:」 物理的で中型のアクセス管理は結合した固定されてモバイルの認可されたバンドで操作するのと間違いの1インチ層にします、IEEE Std 802.16e-2005とIEEE Std802.16-2004/心臓1-2005、2006年2月。
10.2. Informative References
10.2. 有益な参照
[RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11
Networks", RFC 4260, November 2005.
[RFC4260] マッキャン、P.、「モバイルIPv6は802.11のために速くネットワークを引き渡す」RFC4260、2005年11月。
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5184]Teraoka、F.、精力的です、K.(三屋、K.、渋井、R.、およびK.Mitani)は「層の3(L3)の駆動速い引き渡しのための層2(L2)の抽象化を統一しました」、RFC5184、2008年5月。
[RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
[RFC4907] Aboba、B.、「リンク指摘の建築含意」、RFC4907、2007年6月。
[IEEE802.21] "Draft IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services", IEEE
Std P802.21 D9.0, February 2008.
[IEEE802.21] 「地方とメトロポリタンエリアネットワークのIEEE規格を作成してください」 「独立している引き渡しが修理するメディア」、IEEE Std P802.21 D9.0、2008年2月。
[SH802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover
Mechanism for IEEE 802.16e Broadband Wireless Access",
International Conference on Computational Science vol.
2, pp.527-534, 2005.
[SH802.16e] Computational Science vol.2、pp.527-534、2005に関するキム、K.、キム、C.、およびT.キム、「IEEE 802.16eの広帯域のワイヤレス・アクセスのためのシームレスの引き渡しメカニズム」国際コンファレンス。
Jang, et al. Informational [Page 16] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[16ページ]のRFC5270FMIPv6
Authors' Addresses
作者のアドレス
Heejin Jang SAMSUNG Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea
Heejin Jangの三星の高度な工科大学P.O. Box111韓国水原440-600
EMail: heejin.jang@gmail.com
メール: heejin.jang@gmail.com
Junghoon Jee Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea
Junghoon Jeeエレクトロニクスとテレコミュニケーション研究所161Gajeong-ドング、Yuseong-gu Daejon305-350韓国
EMail: jhjee@etri.re.kr
メール: jhjee@etri.re.kr
Youn-Hee Han Korea University of Technology and Education Gajeon-ri, Byeongcheon-myeon Cheonan 330-708 Korea
技術のYoun-ヒーハン高麗大学と教育Gajeon-ri、Byeongcheon-myeonチョナン330-708韓国
EMail: yhhan@kut.ac.kr
メール: yhhan@kut.ac.kr
Soohong Daniel Park SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea
公園三星エレクトロニクス416Maetan-3dong、SoohongダニエルYeongtong-gu韓国水原442-742
EMail: soohong.park@samsung.com
メール: soohong.park@samsung.com
Jaesun Cha Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea
Jaesun Chaエレクトロニクスとテレコミュニケーション研究所161Gajeong-ドング、Yuseong-gu Daejon305-350韓国
EMail: jscha@etri.re.kr
メール: jscha@etri.re.kr
Jang, et al. Informational [Page 17] RFC 5270 FMIPv6 over 802.16e June 2008
Jang、他 802.16e2008年6月の間の情報[17ページ]のRFC5270FMIPv6
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Jang, et al. Informational [Page 18]
Jang、他 情報[18ページ]
一覧
スポンサーリンク
