RFC5271 日本語訳
5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G.Dommety. June 2008. (Format: TXT=49316 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Yokota
Request for Comments: 5271 KDDI Lab
Category: Informational G. Dommety
Cisco Systems, Inc.
June 2008
コメントを求めるワーキンググループH.ヨコタの要求をネットワークでつないでください: 5271年のKDDI研究室カテゴリ: 情報のG.DommetyシスコシステムズInc.2008年6月
Mobile IPv6 Fast Handovers for 3G CDMA Networks
モバイルIPv6は3G CDMAのために速くネットワークを引き渡します。
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
要約
Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover.
モバイルIPv6は、1つのネットワークから別のネットワークまで移行している間、接続性を維持するように設計されています。 モバイルノード(ミネソタ)がアクセスルータの間で移行するとき、それは接続性を維持する方法として3G CDMAネットワークで採用されます。 しかしながら、この引き渡し手順がミネソタによる動き検出だけではなく、aの獲得も新しく必要とする、Care、-、新しさがあるAddressとモバイルIPv6登録、注意、-、目標ネットワークでトラフィックの前のアドレスを送るか、または受け取ることができます。 この期間、モバイルノードのために運命づけられたパケット(ボイス・オーバー IPなどのリアルタイムの適用(VoIP)かビデオ電話において、許容できないかもしれない)は失われるかもしれません。 このドキュメントは、引き渡しの間、潜在とパケット損失を抑えるために3G CDMAネットワークで速い引き渡しメソッドを指定します。
Yokota & Dommety Informational [Page 1] RFC 5271 3G CDMA Fast Handover June 2008
速い[1ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Terminology .....................................................3
4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks ...4
5. Fast Handover Procedures ........................................6
5.1. Predictive Fast Handover ...................................7
5.2. Reactive Fast Handover ....................................12
5.3. Considerations on the Link Indications ....................15
6. Message Format .................................................15
6.1. Handover Assist Information Option ........................15
6.2. Mobile Node Identifier Option .............................16
6.3. New Flag Extension to FBU Message .........................17
6.4. New Flag Extension to PrRtAdv Message .....................17
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
1. 序論…2 2. 要件記法…3 3. 用語…3 4. モバイルIPv6のために3G CDMAネットワークの上で規範モデルをネットワークでつないでください…4 5. 速い引き渡し手順…6 5.1. 予言の速い引き渡し…7 5.2. 反応速い引き渡し…12 5.3. リンク指摘での問題…15 6. メッセージ形式…15 6.1. 引き渡しアシスト情報オプション…15 6.2. モバイルノード識別子オプション…16 6.3. FBUメッセージへの新しい旗の拡大…17 6.4. PrRtAdvメッセージへの新しい旗の拡大…17 7. セキュリティ問題…18 8. IANA問題…18 9. 承認…19 10. 参照…19 10.1. 標準の参照…19 10.2. 有益な参照…19
1. Introduction
1. 序論
Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP connectivity while the MN moves around in the IPv6 network. It is adopted in 3G CDMA networks for handling host-based mobility management [12]. During handover, however, the mobile node (MN) needs to switch the radio link to obtain a new Care-of Address (CoA) and to re-register with the home agent (HA), which may cause a communication disruption. This is not desirable for real-time applications such as VoIP and video telephony. To reduce this disruption time or latency, a fast handover protocol for Mobile IPv6 [3] is proposed. RFC 4260 [7] further describes how this Mobile IPv6 Fast Handover could be implemented on link layers conforming to the IEEE 802.11 suite of specifications. However, 3G CDMA and IEEE 802.11 networks are substantially different in the radio access, the representations of the network nodes or parameters, and the network attachment procedures; for example, the beacon scanning or New Access Router (NAR) discovery based on [Access Point Identifier, Access Router-info (AP-ID, AR-info)] tuples specified in RFC 4260 can not be directly applied to 3G CDMA networks. This document therefore specifies how Mobile IPv6 fast handovers can be applied in the 3G CDMA networks.
ミネソタはIPv6ネットワークで動き回りますが、モバイルIPv6[2]はモバイルノード(MNs)に永続的なIPの接続性を維持させます。 それは、ホストを拠点とする移動性管理[12]を扱うために3G CDMAネットワークで採用されます。 しかしながら、引き渡しの間、モバイルノード(ミネソタ)が、新しい状態でaを得るためにラジオリンクを切り換える必要がある、Care、-、(CoA)と再レジスタへのホームのエージェント(HA)がいるAddress。(そのエージェントは、コミュニケーション分裂を引き起こすかもしれません)。 VoIPやビデオなどのリアルタイムのアプリケーション電話には、これは望ましくはありません。 この分裂時間かレイテンシを減少させるために、モバイルIPv6[3]のための速い引き渡しプロトコルは提案されます。 RFC4260[7]はさらに仕様のIEEE802.11スイートに従いながらリンクレイヤでどうこのモバイルIPv6 Fast Handoverを実装することができたかを説明します。 しかしながら、3G CDMAとIEEE802.11ネットワークはラジオアクセス、ネットワーク・ノードかパラメタの表現、およびネットワーク付属手順において実質的に異なっています。 例えば、直接RFC4260で指定されたtuplesに基づく[Point Identifierにアクセスしてください、Access Router-インフォメーション(AP-ID、AR-インフォメーション)]標識スキャンかNew Access Router(NAR)発見は3G CDMAネットワークに適用できません。 したがって、このドキュメントは3G CDMAネットワークでどうモバイルIPv6速い身柄の引き渡しを適用できるかを指定します。
Yokota & Dommety Informational [Page 2] RFC 5271 3G CDMA Fast Handover June 2008
速い[2ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
2. Requirements Notation
2. 要件記法
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
3. Terminology
3. 用語
This document refers to [3] for Mobile IPv6 fast handover terminology. Terms that first appear in this document are defined below:
このドキュメントはモバイルIPv6速い引き渡し用語のための[3]について言及します。 最初に現れる用語は以下で本書では定義されます:
Access Network Identifier (ANID): An identifier that is used by the
Packet Data Serving Node (PDSN) to determine whether the MN is
being handed off from the access network that was not previously
using this PDSN. Anytime the MN crosses into a new region, which
is defined by the ANID, it must re-register with that access
network. The ANID is further composed of the System ID (SID),
Network ID (NID), and Packet Zone ID (PZID) and these values are
administered by the operator. The lengths of the SID, NID, and
PZID are 2 octets, 2 octets, and 1 octet, respectively. Thus,
that of the ANID occupies 5 octets [11].
ネットワーク識別子(ANID)にアクセスしてください: ミネソタがアクセスから渡されているか否かに関係なく、それをネットワークでつなぐように決定するのにPacket Data Serving Node(PDSN)によって使用される識別子は以前に、このPDSNを使用していませんでした。 いつでも、ミネソタは新しい領域に渡って、それはそのアクセスネットワークに再登録されなければなりません。(領域はANIDによって定義されます)。 ANIDはSystem Network ID(SID)(ID)(NID)でさらに構成されます、そして、Packet Zone ID(PZID)とこれらの値はオペレータによって統治されます。 SID、NID、およびPZIDの長さは、それぞれ2つの八重奏と、2つの八重奏と、1つの八重奏です。 したがって、ANIDのものは5つの八重奏[11]を占領します。
Forward Pilot Channel: A portion of the Forward Channel that carries
the pilot. The Forward Channel is a portion of the physical layer
channels transmitted from the 3G CDMA access network to the MN.
Further, several sets of pilots (e.g., the active set or neighbor
set) are defined to determine when and where to handover.
監視通信路を進めてください: パイロットを運ぶForward Channelの一部。 Forward Channelは3G CDMAアクセスネットワークからミネソタまで送られた物理的な層のチャンネルの一部です。 さらに、数セットの案内人(例えば、活動的なセットか隣人がセットしました)は、いつ、どこかを引き渡しに決定するために定義されます。
Home Link Prefix (HLP): The prefix address assigned to the home link
where the MN should send the binding update message. This is also
called Home Network Prefix (HNP) and one of the bootstrap
parameters for the MN.
家では、接頭語(HLP)がリンクします: ミネソタが拘束力があるアップデートメッセージを送るべきであるホームのリンクに割り当てられた接頭語アドレス。 また、これがホームNetwork Prefix(HNP)と1と呼ばれる、ミネソタのためのパラメタを独力で進んでください。
International Mobile Subscriber Identity (IMSI): The IMSI is a
string of decimal digits, up to a maximum of 15 digits, that
identifies a unique mobile terminal or mobile subscriber
internationally. The IMSI consists of three fields: the Mobile
Country Code (MCC), the Mobile Network Code (MNC), and the Mobile
Subscriber Identification Number (MSIN). An example of the IMSI
is "440701234567890", where "440" is the MCC, "70" is the MNC, and
"1234567890" is the MSIN. The IMSI conforms to the ITU-T E.212
numbering standard [6]. In this specification, IMSI is an ASCII
string that consists of not more than 15 decimal digits (ASCII
values between 30 and 39 hexadecimal), one character per IMSI
digit. The above example would therefore be encoded as "34 34 30
37 30 31 32 33 34 35 36 37 38 39 30" in hexadecimal notation.
移動加入者識別番号(IMSI): IMSIは最大15ケタまでユニークな移動体端末か携帯電話の契約者を国際的に特定する一連の10進数字です。 IMSIは3つの分野から成ります: モバイル国名略号(MCC)、モバイルネットワークコード(MNC)、および携帯電話の契約者識別番号(MSIN)。 IMSIに関する例は「440701234567890」です、そして、「70インチはMNCです、そして、「1234567890」はMSINです」。そこでは、「440」がMCCです。 IMSIはITU-T E.212付番規格[6]に従います。 この仕様では、IMSIは15以上の10進数字(ASCIIは30〜39 16進を評価します)(IMSIケタあたり1つのキャラクタ)でないことから成るASCIIストリングです。 したがって、上記の例がコード化されるだろう、「34 34 30 37 30 31 32 33 34 35 36 37 38 39、16進法における30インチ、」
Yokota & Dommety Informational [Page 3] RFC 5271 3G CDMA Fast Handover June 2008
速い[3ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Mobile Identity (MN ID): An identifier of the Mobile Node that is
used by the access network. The value (e.g., IMSI) is unique
within the operator's network.
モバイルアイデンティティ(MN ID): アクセスネットワークによって使用されるモバイルNodeに関する識別子。 値(例えば、IMSI)はオペレータのネットワークの中でユニークです。
Packet Data Serving Node (PDSN): An entity that routes MN originated
or MN terminated packet data traffic. A PDSN establishes,
maintains, and terminates link-layer sessions to MNs. A PDSN is
the access router in the visited access provider network.
ノード(PDSN)に役立つパケットデータ: ルートミネソタが溯源した実体かミネソタがパケットデータ通信量を終えました。 PDSNはMNsへのリンクレイヤセッションを確立して、維持して、終えます。 PDSNは訪問されたアクセスプロバイダネットワークでアクセスルータです。
Sector Address Identifier (SectorID): A typical cell divides its
coverage area into several sectors. In 3G CDMA systems, each
sector uses a different PN (Pseudo Noise) code offset and is
associated with SectorID. The SectorID is 128 bits long and can
be represented in the IPv6 address format [8].
セクタ・アドレス識別子(SectorID): 典型的なセルは適用範囲の地域をいくつかのセクターに分割します。 3G CDMAシステムでは、それぞれのセクターは、異なったPN(疑似Noise)コードオフセットを使用して、SectorIDに関連しています。 SectorIDは長さ128ビットであり、IPv6アドレス形式[8]で表すことができます。
4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks
4. 3G CDMAネットワークの上のモバイルIPv6のネットワーク規範モデル
Figure 1 shows a simplified reference model of the Mobile IP enabled 3G CDMA networks. The home agent (HA) and Authentication, Authorization, and Accounting (AAA) server of the mobile node (MN) reside in the home IP network, and the MN roams within or between the access provider network(s). Usually, the home IP network is not populated by the MNs, which are instead connected only to the access provider networks. Prior to the Mobile IPv6 registration, the MN establishes a 3G CDMA access technology specific link-layer connection with the access router (AR). When the MN moves from one AR to another, the link-layer connection is re-established, and a Mobile IPv6 handover is performed. Those ARs reside in either the same or different access provider network(s). The figure shows the situation, where the MN moves from the Previous Access Router (PAR) to the New Access Router (NAR) via the radio access network (RAN).
図1は、モバイルIPの簡易型の規範モデルが3G CDMAネットワークを可能にしたのを示します。 モバイルノード(ミネソタ)のホームのエージェント(HA)とAuthentication、Authorization、およびAccounting(AAA)サーバはホームIPネットワークであります、そして、ミネソタはネットワーク以内かアクセスプロバイダネットワークの間を移動します。 通常、ホームIPネットワークはMNsによって居住されません。(MNsは代わりにアクセスプロバイダネットワークだけに接続されます)。 モバイルIPv6登録の前に、ミネソタはアクセスルータ(AR)との3G CDMAアクセス技術特有のリンクレイヤ関係を確立します。 ミネソタが1ARから別のARまで移行するとき、リンクレイヤ接続は復職します、そして、モバイルIPv6引き渡しは実行されます。 それらのARsは同じであるか異なったアクセスプロバイダネットワークで住んでいます。 図は状況を示しています。そこでは、ミネソタがラジオアクセスネットワーク(RAN)を通してPrevious Access Router(PAR)からNew Access Router(NAR)まで移行します。
Yokota & Dommety Informational [Page 4] RFC 5271 3G CDMA Fast Handover June 2008
速い[4ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Home IP Network
+........................+
. +--------+ +--------+ .
. | HA |--| AAA | .
. +--------+ +--------+ .
+../......\..............+
/ \
Access Provider Network(s)
+.............+ +.............+
. +---------+ . . +---------+ .
. | PAR | . . | NAR | .
. +---------+ . . +---------+ .
. |: . . :| .
. |:L2link L2link:| .
. |: . . :| .
. +----+:---+ . . +---:+----+ .
. | RAN | . . | RAN | .
. +----+:---+ . . +---:+----+ .
. |: . . :| .
. +----+ . . +----+ .
. | MN | ---------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
ホームIPネットワーク+…+ . +--------+ +--------+ . . | ハ|--| AAA| . . +--------+ +--------+ . +../......\..............+/\アクセスプロバイダは(s) +をネットワークでつなぎます…+ +.............+ . +---------+ . . +---------+ . . | 平価| . . | NAR| . . +---------+ . . +---------+ . . |: . . :| . . |:L2link L2link:、||: . . :| . . +----+:---+ . . +---:+----+ . . | 走りました。| . . | 走りました。| . . +----+:---+ . . +---:+----+ . . |: . . :| . . +----+ . . +----+ . . | ミネソタ| --------->| ミネソタ| . . +----+ . . +----+ . +.............+ +.............+
Figure 1: Reference Model for Mobile IP
図1: モバイルIPの規範モデル
In 3G CDMA networks, pilot channels transmitted by base stations allow the MN to obtain a rapid and accurate C/I (carrier to interference) estimate. This estimate is based on measuring the strength of the Forward Pilot Channel or the pilot, which is associated with a sector of a base station (BS). The MN searches for the pilots and maintains those with sufficient signal strength in the pilot sets. The MN sends measurement results, which include the offsets of the PN code in use and the C/Is in the pilot sets, to provide the radio access network (RAN) with the estimate of sectors in its neighborhood. There are several triggers for the MN to send those estimates, e.g., when the strength of a pilot in the pilot sets exceeds that of the current pilot, the MN sends the estimates to the access network. As long as the sector to which the MN is going to move belongs to the same access network, the mobility within that access network is handled by the access-specific interfaces [10] and the link-layer connection between the MN and AR can be maintained without a re-establishment. The MN can continually search for pilots without disrupting the data communication and a timely handover is assisted by the network. If, however, the serving access network finds that the sector associated with the highest pilot strength belongs to a different AR, it attempts to close the connection with the MN. The MN then attempts to get a new traffic channel assigned
3G CDMAネットワークでは、基地局によって送られた監視通信路はミネソタに私(干渉へのキャリヤー)が見積もっている急速で正確なC/を得させます。 この見積りはForward Pilot Channelかパイロットの強さを測定するのに基づいています。(強さは基地局(BS)のセクターに関連しています)。 ミネソタは、パイロットセットでパイロットを捜し求めて、十分な信号強度があるそれらを維持します。 ミネソタは測定結果を送ります、そして、ラジオアクセスネットワーク(RAN)を近所のセクターの見積りに提供するために、パイロットセットにC/があります。(結果はPNコードのオフセットを使用中に含んでいます)。 ミネソタがそれらの見積りを送るように、数個の引き金があります、例えば、パイロットセットにおける、パイロットの強さが現在のパイロットのものを超えているとミネソタはアクセスネットワークに見積りを送ります。 ミネソタが移行するセクターが同じアクセスネットワークに属す限り、アクセス特有のインタフェース[10]でそのアクセスネットワークの中の移動性を扱います、そして、再建なしでミネソタとARとのリンクレイヤ接続を維持できます。 データ通信を中断しないで、ミネソタは絶えずパイロットを捜し求めることができます、そして、タイムリーな引き渡しはネットワークによって促進されます。 しかしながら、最も高いパイロットの強さに関連しているセクターが異なったARに属すのが給仕アクセスネットワークによってわかるなら、それは、ミネソタとの接続を終えるのを試みます。 そして、ミネソタは、新しいトラフィックチャンネルを選任させるのを試みます。
Yokota & Dommety Informational [Page 5] RFC 5271 3G CDMA Fast Handover June 2008
速い[5ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
in the new access network, which is followed by establishing a new connection with the new AR. This could cause a noticeable communication disruption and lead to a serious degradation of the user experience. In order to minimize the service degradation, during the handover between ARs, an IP-level fast handover approach as defined in RFC 5268 needs to be involved. If the air interface information can be used as a trigger for the handover between access routers, fast and smooth handover of Mobile IPv6 can be realized in 3G CDMA networks. The MN can continually search for pilots without disrupting the data communication and a timely handover is assisted by the network.
新しいアクセスネットワークで。(新しいARとの新しい接続を確立するのはそれのあとに続きます)。 これは、めぼしいコミュニケーション分裂を引き起こして、ユーザー・エクスペリエンスの重大な退行に通じるかもしれません。 引き渡しの間、ARsの間でサービス退行を最小にするために、RFC5268で定義されるIP-レベルの速い引き渡しアプローチは、かかわる必要があります。 アクセスルータの間の引き渡しに引き金として空気インターフェース情報を使用できるなら、3G CDMAネットワークでモバイルIPv6の速くて滑らかな引き渡しを実現できます。 データ通信を中断しないで、ミネソタは絶えずパイロットを捜し求めることができます、そして、タイムリーな引き渡しはネットワークによって促進されます。
To assist the handover of the MN to the new AR, various types of information can be considered: the pilot sets, which include the candidates of the target sectors or BSs, the cell information where the MN resides, the serving nodes in the radio access network, and the location of the MN, if available. To identify the access network that the MN moves to or from, the Access Network Identifiers (ANID) or the subnet information can be used [9][10]. In this document, a collection of such information is called "handover assist information". In 3G CDMA networks, the Link-Layer Address of the New Access Point (AP) defined in [3] may not be available. If this is the case, the Handover Assist Information option defined in this document SHOULD be used instead.
ミネソタの引き渡しを新しいARに促進するために、様々なタイプの情報を考えることができます: パイロットはセットします(目標のセクターかBSsの候補、ミネソタがどこに住んでいるかというセル情報、ラジオアクセスネットワークにおける給仕ノード、およびミネソタの位置を含んでいます)、利用可能であるなら。 または、ミネソタが移行するアクセスネットワークを特定する、Access Network Identifiers(ANID)かサブネット情報が中古の[9][10]であることができる。 本書では、そのような情報の収集は「引き渡しアシスト情報」と呼ばれます。 3G CDMAネットワークでは、[3]で定義されたNew Access Point(AP)のAddress Link-層は利用可能でないかもしれません。 Handover Assist情報オプションはこれがそうであるなら、本書ではSHOULDを定義しました。代わりに使用されます。
5. Fast Handover Procedures
5. 速い引き渡し手順
There are two modes defined in [3] according to the time of sending the FBU (Fast Binding Update); one is called "predictive mode", where the MN sends the FBU and receives the FBAck (Fast Binding Acknowledgment) on the PAR's (Previous Access Router's) link and the other is called "reactive mode", where the MN sends the FBU from the NAR's (New Access Router's) link. In the predictive mode, the time and place the MN hands off must be indicated sufficiently before the time it actually happens. In cellular systems, since handovers are controlled by the network, the predictive mode is well applied. However, if the network is not configured to be able to identify the new AR, to which the MN is moving next, in a timely manner, the reactive mode is better applied.
FBU(速いBinding Update)を送る時間に従って[3]で定義された2つのモードがあります。 1はミネソタがPAR(Access Routerの前のもの)のリンクの上にFBUを送って、FBAckを受ける(速いBinding Acknowledgment)「予言のモード」と呼ばれます、そして、もう片方が「反応モード」と呼ばれます。そこでは、ミネソタがNAR(新しいAccess Routerのもの)のリンクからFBUを送ります。 予言のモードで、実際に起こるとき、以前、ミネソタが渡す時間と場所を十分示さなければなりません。 セルラ方式では、身柄の引き渡しがネットワークによって制御されるので、予言のモードは上手に適用されます。 しかしながら、ネットワークがミネソタが次に移行する新しいARを特定できるように構成されないなら、直ちに、反応モードは適用されるほうがよいです。
Section 2 of RFC 4907 [20] suggests architectural principles on the link indication and the effectiveness of the optimization. The link indication of this document relies on 3G CDMA networks and the effectiveness of the optimization is attributed to RFC 5268. The above principles are thus considered by the related specifications referenced in this document.
RFC4907[20]のセクション2はリンク指示と最適化の有効性に建築原則を示します。 このドキュメントのリンクしるしは3G CDMAネットワークを当てにします、そして、最適化の有効性はRFC5268の結果と考えられます。 上の原則は本書では参照をつけられる関連する仕様でこのようにして考えられます。
Yokota & Dommety Informational [Page 6] RFC 5271 3G CDMA Fast Handover June 2008
速い[6ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
5.1. Predictive Fast Handover
5.1. 予言の速い引き渡し
Figure 2 shows the predictive mode of MIPv6 fast handover operation. When the MN finds a sector or a BS whose pilot signal is sufficiently strong, it initiates handover according to the following sequence:
図2はMIPv6の速い引き渡し操作の予言のモードを示しています。 ミネソタがパイロット信号が十分強いセクターかBSを見つけるとき、以下の系列によると、引き渡しを開始します:
(a) A router solicitation for proxy router advertisement is sent to
the PAR. Handover assist information for the target 3G CDMA
network is attached to this message.
(a) プロキシルータ通知のためのルータ懇願をPARに送ります。 目標3G CDMAネットワークのための引き渡しアシスト情報はこのメッセージに添付されます。
(b) Based on the received handover assist information, the NAR is
determined and a proxy router advertisement (PrRtAdv) containing
the prefix of the NAR is sent back to the MN. The MN also
checks that the R flag is not set in the PrRtAdv message, which
indicates the network supports the predictive fast handover mode
(defined later).
(b) 受信された引き渡しアシスト情報に基づいてNARは断固としています、そして、NARの接頭語を含むプロキシルータ通知(PrRtAdv)はミネソタに送り返されます。 また、ミネソタは、R旗がPrRtAdvメッセージに設定されないのをチェックします。(メッセージは、ネットワークが、予言の速い引き渡しがモード(後で定義される)であるとサポートするのを示します)。
(c) The MN creates an NCoA (new CoA) and sends the Fast Binding
Update (FBU) with the NCoA to the PAR, which in turn sends the
Handover Initiate (HI) to the NAR.
(c) ミネソタは、NARへのHandover Initiate(HI)が順番に発信するPARにNCoA(新しいCoA)を作成して、NCoAとFast Binding Update(FBU)を送ります。
(d) The NAR sends the Handover Acknowledge (HAck) back to the PAR,
which in turn sends the FBU acknowledgment (FBAck) to the MN.
(d) NARはミネソタへのFBU承認(FBAck)が順番に発信するPARにHandover Acknowledge(HAck)を送り返します。
(e) The PAR starts forwarding packets toward the NCoA and the NAR
captures and buffers them.
(e) PARがNCoAに向かってパケットを送り始めて、NARはそれらをキャプチャして、バッファリングします。
(f) The link-layer connection associated with the PAR is closed and
a new traffic channel is assigned in the new access network.
(f) PARに関連づけられたリンクレイヤ接続は閉店されています、そして、新しいトラフィックチャンネルは新しいアクセスネットワークで選任されます。
(g) The MN attaches to the new access network. The attachment
procedure is access technology specific and that for 3G CDMA
network including the PPP transactions is described later.
(g) ミネソタは新しいアクセスネットワークに付きます。 付属手順はアクセス技術特有です、そして、PPPトランザクションを含む3G CDMAネットワークのためのそれは後で説明されます。
(h) The MN sends the Unsolicited Neighbor Advertisement (UNA).
(h) ミネソタはUnsolicited Neighbor Advertisement(UNA)を送ります。
(i) The NAR starts delivering packets to the MN.
(i) NARはパケットをミネソタに提供し始めます。
(j) The MN sends the Binding Update (BU) to the HA to update the
Binding Cache Entry (BCE) with the NCoA, and the HA sends back
the Binding Acknowledgment (BA) to the MN.
(j) ミネソタはNCoAと共にBinding Cache Entry(BCE)をアップデートするために、Binding Update(BU)をHAに送ります、そして、HAはBinding Acknowledgment(BA)をミネソタに返送します。
Yokota & Dommety Informational [Page 7] RFC 5271 3G CDMA Fast Handover June 2008
速い[7ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | Hl | | |
(c) |------------->|-------------->| | |
| FBack | HAck | | |
(d) |<-------------|<--------------| | |
| |forward packets| | |
(e) | |==============>|(buffering) | |
| | | | |
(f) handover | | | |
| | | | |
+--------------------------------------------------------------+
(g) | Attachment procedure |
+--------------------------------------------------------------+
| UNA | | |
(h) |----------------------------->| | |
| deliver packets | | |
(i) |<=============================| | |
| | BU/BA | | |
(j) |<------------------------------------------->| |
| | | | |
ミネソタ平価NAR、ハ、AAA| RtSolPr| | | | (a) |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| PrRtAdv| | | | (b) | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| FBU| hl| | | (c) |------------->|-------------->| | | | FBack| ハッキング| | | (d) |<-------------|<--------------| | | | |前進のパケット| | | (e) | |==============>|(バッファリング) | | | | | | | (f) 引き渡し| | | | | | | | | +--------------------------------------------------------------+ (g)| 付属手順| +--------------------------------------------------------------+ | ウナ| | | (h) |----------------------------->| | | | パケットを提供してください。| | | (i) |<===============| | | | | BU/Ba| | | (j) |<------------------------------------------->| | | | | | |
Figure 2: MIPv6 Fast Handover Operation (Predictive Mode)
図2: MIPv6の速い引き渡し操作(予言のモード)
It is assumed that the NAR can be identified by the PAR leveraging the handover assist information from the MN. To perform the predictive mode, the MN MUST send the FBU before the connection with the current access network is closed. If the MN fails to send the FBU before handover, it SHOULD fall back to the reactive mode. Even if the MN successfully sends the FBU, its reception by the PAR may be delayed for various reasons such as congestion. If the NAR receives the HI triggered by the delayed FBU after the reception of the UNA ((c) comes after (h)), then the NAR SHOULD send the HAck with handover not accepted and behave as the reactive mode.
引き渡しアシストがミネソタからの情報であると利用するPARがNARを特定できると思われます。 予言のモードを実行するために、現在のアクセスネットワークとの接続が閉じるようになる前にミネソタはFBUを送らなければなりません。 ミネソタは引き渡しの前にFBUを送らないで、それは反応モードへのSHOULD落下であって戻ります。 ミネソタが首尾よくFBUを送っても、PARによるレセプションは混雑などの様々な理由で遅れるかもしれません。 NARがUNA((c)のレセプションが(h))に続いた後に遅れたFBUによって引き起こされたHIを受けるなら、NAR SHOULDは引き渡しが受け入れられていなくHAckを送って、反応モードとして振る舞います。
In (a), Router Solicitation for Proxy Advertisement (RtSolPr) is supposed to include the New Access Point and the MN Link-Layer Address (LLA) options (Option Code=1 and 2, respectively) according to [3]. The New AP-LLA option MAY be replaced by the handover assist information option in 3G CDMA networks. As for the MN-LLA option, if the LLA for the MN is not available, 3G specific IDs such as IMSI[11] MAY be used. If this is the case, the MN ID option defined in Section 6.2, which can support other types of IDs and a length that is not necessarily multiples of 8 octets, SHOULD be used instead of the MN-LLA option.
(a)では、[3]によると、Proxy Advertisement(RtSolPr)のためのRouter SolicitationはNew Access PointとミネソタLink-層のAddress(LLA)オプション(それぞれオプションCode=1と2)を含むべきです。 New AP-LLAオプションを3G CDMAネットワークにおける引き渡しアシスト情報オプションに取り替えるかもしれません。 ミネソタ-LLAオプションに関して、ミネソタへのLLAがIMSI[11] MAYなどの利用可能でなくて、3G特有のIDであるなら、使用されてください。 これがケース、IDオプションがセクション6.2で定義したミネソタであるなら、サポート他のタイプのIDと必ず倍数であるというわけではない8つの八重奏、SHOULDの長さはどれであるかもしれません。ミネソタ-LLAオプションの代わりに、使用されます。
Yokota & Dommety Informational [Page 8] RFC 5271 3G CDMA Fast Handover June 2008
速い[8ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
In (b), PrRtAdv MUST include options for the IP address of the NAR, which may be the link-local address, and the prefix for the MN. The PAR SHOULD be able to identify the NAR from the handover assist information provided by the MN.
(b)では、PrRtAdvはリンクローカルアドレスと、ミネソタへの接頭語であるかもしれないNARのIPアドレスのためのオプションを含まなければなりません。 PAR SHOULD、ミネソタによって提供された引き渡しアシスト情報からNARを特定できてください。
Figure 3 shows the call flow for the initial attachment in the 3G CDMA network [12]. After the traffic channel is assigned, the MN first establishes a link-layer connection between itself and the access router. As a link-layer protocol, PPP is considered in this figure, and a PPP handshake is depicted as an example. After a link-layer connection is established, the MN registers with the HA by sending a Binding Update message. There are several parameters for using Mobile IPv6 such as the home address (HoA), the Care-of Address (CoA), the home agent address (HA), and the home link prefix (HLP). In [12], obtaining these values is called bootstrapping, and the bootstrapping information can be obtained during the link-layer establishment phase and/or the mobility binding phase [13].
図3は初期の付属のために3G CDMAネットワーク[12]で呼び出し流動を示しています。 トラフィックチャンネルが選任された後に、ミネソタは最初に、それ自体とアクセスルータとのリンクレイヤ関係を確立します。 リンク層プロトコルとして、PPPはこの図で考えられます、そして、PPP握手は例として描かれます。 リンクレイヤ接続が確立された後に、ミネソタは、Binding Updateメッセージを送ることによって、HAとともに記名します。 ホームアドレス(HoA)などのモバイルIPv6を使用するためのいくつかのパラメタがある、Care、-、Address(CoA)、ホームエージェントアドレス(HA)、およびホームは接頭語(HLP)をリンクします。 [12]では、これらの値を得るのを独力で進むと呼びます、そして、リンクレイヤ確立段階、そして/または、移動性の拘束力がある段階[13]の間、ブートストラップ法情報を得ることができます。
Yokota & Dommety Informational [Page 9] RFC 5271 3G CDMA Fast Handover June 2008
速い[9ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
MN PAR NAR HA AAA
/ | (serving PDSN) (target PDSN) | |
| | LCP | | | |
| (1) |<----------------------->| | |
| | CHAP/PAP | Access-Request/Accept |
| (2) |<----------------------->|<-------------|------->|
| | | +------+ | | |
| (3) | | | HA |<---------+ |
| | | +------+ | |
|+........................................+ | |
|. | | . | |
|. | IPv6CP(IF-ID) | . | |
|.(4)* |<---------|------------->| . | |
(g)< . +---------+ | | | . | |
|.(5)*| LL-addr |<-+ | | . | |
|. +---------+ | | . | |
|. | | . | |
|. | RA(prefix) | . | |
|.(6)* |<---------|--------------| . | |
|. +-----+ | | | . | |
|.(7)*| CoA |<-----+ | | . | |
|. +-----+ | | . | |
|+........................................+ | |
| | DHCPv6(HA) | | |
| (8) |<---------------+------->| | |
| +-----+ | | | | |
| (9) | HA |<-----------+ | | |
| +-----+ | | | |
| | | | | |
\ | | | | |
ミネソタ平価NAR、ハ、AAA/| (PDSNに役立ちます) (目標PDSN) | | | | LCP| | | | | (1) | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| やつ/乳首| アクセスして要求するか、または受け入れてください。| | (2) |<----------------------->|<-------------|------->| | | | +------+ | | | | (3) | | | ハ| <、-、-、-、-、-、-、-、--+ | | | | +------+ | | |+........................................+ | | |. | | . | | |. | IPv6CP、(-、ID、)| . | | |.(4)* | <、-、-、-、-、-、-、-、--、|、-、-、-、-、-、-、-、-、-、-、-、--、>| . | | (g)<+---------+ | | | . | | |.(5)*| LL-addr| <、-+ | | . | | |. +---------+ | | . | | |. | | . | | |. | RA(接頭語)| . | | |.(6)* | <、-、-、-、-、-、-、-、--、|、-、-、-、-、-、-、-、-、-、-、-、-、--、| . | | |. +-----+ | | | . | | |.(7)*| CoA| <、-、-、-、--+ | | . | | |. +-----+ | | . | | |+........................................+ | | | | DHCPv6(ハ)| | | | (8) | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+------->|、|、|、| +-----+ | | | | | | (9) | ハ| <、-、-、-、-、-、-、-、-、-、--+ | | | | +-----+ | | | | | | | | | | \ | | | | |
Figure 3: Attachment Procedure in 3G CDMA Network
図3: 3G CDMAネットワークにおける付属手順
The procedure for the initial attachment is as follows:
初期の付属のための手順は以下の通りです:
(g) The link-layer connection establishment and the bootstrapping
phase.
(g) リンクレイヤコネクション確立とブートストラップ法フェーズ。
(g-1) The LCP (Link Control Protocol) configure-request/response
messages are exchanged.
(g-1) 要求を構成しているLCP(リンクControlプロトコル)/応答メッセージを交換します。
(g-2) User authentication (e.g., Challenge Handshake Authentication
Protocol (CHAP) or Password Authentication Protocol (PAP)) is
conducted.
(g-2) ユーザー認証(例えば、チャレンジハンドシェイク式認証プロトコル(CHAP)かパスワード認証プロトコル(PAP))が行われます。
Yokota & Dommety Informational [Page 10] RFC 5271 3G CDMA Fast Handover June 2008
速い[10ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
(g-3) The static bootstrapping information is conveyed from the AAA
and stored in the NAR (target PDSN). The HoA and HLP can be
dynamically assigned by the HA in the mobility binding phase.
This step can be skipped in the handover case.
(g-3) 静的なブートストラップ法情報は、AAAから伝えられて、NAR(目標PDSN)に保存されます。 移動性の拘束力があるフェーズにおけるHAはダイナミックにHoAとHLPを割り当てることができます。 引き渡し場合でこのステップをサボることができます。
(g-4) Unique interface IDs are negotiated in IPv6 Control Protocol
(IPv6CP).
(g-4) ユニークなインタフェースIDはIPv6 Controlプロトコル(IPv6CP)で交渉されます。
(g-5) The MN configures its link-local address based on the obtained
interface ID.
(g-5) ミネソタは、リンクローカルアドレスがIDを得られたインタフェースに基礎づけたのを構成します。
(g-6) A router advertisement containing the prefix is received by
the MN.
(g-6) 接頭語を含むルータ通知はミネソタによって受け取られます。
(g-7) The MN configures its CoA based on the obtained prefix.
(g-7) ミネソタは得られた接頭語に基づくCoAを構成します。
(g-8) DHCPv6 is used to obtain the static bootstrap information
(e.g., the HA address). This step is performed in the initial
attachment and can be skipped once the MN obtains those
parameters.
(g-8) DHCPv6による使用されて、静電気を得るのが情報(例えば、HAアドレス)を独力で進むということです。 このステップを初期の付属で実行して、ミネソタがいったんそれらのパラメタを得ると、サボることができます。
(g-9) The MN installs the bootstrap information for further
procedures (e.g., the mobility binding).
(g-9)ミネソタがインストールされる、さらなる手順(例えば、移動性結合)のための情報を独力で進んでください。
As is shown in Figure 3, it takes a considerable amount of time to establish a link-layer connection and almost all of the above sequences run every time the MN attaches to a new access network. It is therefore beneficial if packets in transit to the MN are saved not only during the time period when the MN switches to the new radio channel but also during the time period when the MN establishes the link-layer connection.
図3に示されて、そのままで、リンクレイヤ接続を証明するにはかなりの時かかります、そして、ミネソタが新しいアクセスネットワークに付くときはいつも、上の系列のほとんどすべてが走ります。 したがって、ミネソタへのトランジットにおけるパケットがミネソタが新しいラジオチャンネルに切り替わる期間、救われるだけではなく、ミネソタがリンクレイヤ接続を確立する期間も、救われるなら、有益です。
There are several ways to configure a unique IP address for the MN. If a globally unique prefix is assigned per link as introduced in [12], the MN can use any interface ID except that of the other peer (the AR to which the MN is attached) to create a unique IP address. If this is the case, however, the PAR cannot provide the MN with a correct prefix for the new network in the PrRtAdv since such a prefix is selected by the NAR and provided in the router advertisement. The MN therefore configures a temporary NCoA with the prefix provided by the PAR and the correct NCoA MUST be assigned by the NAR. Therefore, in 3G CDMA network, the PAR MUST send the HI with the S flag set when it receives the FBU from the MN at step (c) in Figure 2.
ミネソタへの固有のIPアドレスを構成するいくつかの方法があります。 グローバルにユニークな接頭語が[12]で導入するようにリンク単位で割り当てられるなら、ミネソタは、固有のIPアドレスを作成するのにもう片方の同輩(ミネソタが付けているAR)のもの以外のどんなインタフェースIDも使用できます。 これがそうであるなら、しかしながら、PARは、そのような接頭語をNARが選択して、ルータ通知に提供するので、PrRtAdvの新しいネットワークのために正しい接頭語をミネソタに提供できません。 したがって、ミネソタはPARによって提供される接頭語で一時的なNCoAを構成します、そして、NARは正しいNCoAを割り当てなければなりません。 したがって、3G CDMAネットワークでは、PAR MUSTは図2におけるステップ(c)のミネソタからそれがFBUを受けるとき設定されたS旗でHIを送ります。
Yokota & Dommety Informational [Page 11] RFC 5271 3G CDMA Fast Handover June 2008
速い[11ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
The UNA is supposed to include the MN-LLA [3], but the point-to-point link-layer connection may be able to uniquely identify the MN. The most required information by the UNA is the NCoA to check if there is a corresponding buffer. Therefore, in (h), the function of the UNA can be realized in several ways:
UNAはミネソタ-LLA[3]を含むべきですが、二地点間リンクレイヤ接続は唯一ミネソタを特定できるかもしれません。 UNAによる最も必要な情報は対応するバッファがあるかどうかチェックするNCoAです。 したがって、(h)では、いくつかの方法でUNAの機能を実現できます:
o Since the establishment of the link-layer connection in (g)
indicates readiness of data communication on the MN side, the NAR
immediately checks if there is a buffer that has packets destined
for the NCoA, which was configured at steps (c) - (d), and starts
delivering, if any (substitution of UNA).
o リンクレイヤ接続の(g)への設立がミネソタの側におけるデータ通信の準備を示すので、NARは、すぐにステップ(c)--(d)で構成されたNCoAのためにパケットを運命づけさせていて、配送し始めるバッファがあるかどうかチェックします、もしあれば(UNAの代替)。
o The MN sends the UNA as defined in [3]. Instead of the MN-LLA in
the LLA option, the MN ID MAY be included in the MN ID option
(standard implementation of UNA).
o ミネソタは[3]で定義されるようにUNAを送ります。 LLAオプションにおけるミネソタ-LLAの代わりに、ミネソタIDはミネソタのIDオプション(UNAの標準の実現)に含まれるかもしれません。
The primary benefit of the predictive fast handover mode is that the packets destined for the MN can be buffered at the NAR, and packet loss due to handover will be much lower than that of the normal MIPv6 operation. Regarding the bootstrapping, the following benefit can be obtained, too:
予言の速い引き渡しモードの主要便益はNARでミネソタに運命づけられたパケットをバッファリングできて、引き渡しによるパケット損失が通常のMIPv6操作のものよりはるかに低くなるということです。 ブートストラップ法に関して、また、以下の利益を得ることができます:
o Since the NCoA can be configured via the fast handover procedures,
a router advertisement is not required.
o 速い引き渡し手順でNCoAを構成できるので、ルータ通知は必要ではありません。
Therefore, the procedures (g-4) to (g-7) can be skipped from the standard MIPv6 operation in Figure 3.
したがって、図3における標準のMIPv6操作から(g-7)への手順(g-4)をスキップできます。
5.2. Reactive Fast Handover
5.2. 反応速い引き渡し
When the network does not support the predictive fast handover mode, the reactive fast handover is applied. In this document, a new flag is defined in PrRtAdv to inform the MN about the capability of the network (see Section 6.4). To minimize packet loss in this situation, the PAR instead of the NAR can buffer packets for the MN until the MN regains connectivity with the NAR. The NAR obtains the information of the PAR from the MN on the NAR's link and receives packets buffered at the PAR. In this case, the PAR does not need to know the IP address of the NAR or the NCoA and just waits for the NAR to contact the PAR. However, since the PAR needs to know when to buffer packets for the MN, the PAR obtains the timing of buffering from the MN via the FBU or the lower-layer signaling, e.g., an indication of the release of the connection with the MN. Details of the procedure are as follows:
ネットワークが予言の速い引き渡しモードを支持しないとき、反応速い引き渡しは適用されています。 本書では、新しい旗は、ネットワークの能力に関してミネソタに知らせるためにPrRtAdvで定義されます(セクション6.4を見てください)。 この状況におけるパケット損失を最小にするために、ミネソタがNARと共に接続性を取り戻すまで、NARの代わりにPARはミネソタへのパケットをバッファリングできます。 NARはNARのリンクの上のミネソタからPARの情報を得て、PARでバッファリングされたパケットを受けます。 この場合、PARは、NARかNCoAのIPアドレスを知る必要はなくて、NARがPARに連絡するのをただ待ちます。 しかしながら、PARが、いつパケットをバッファリングするかをミネソタに知る必要があるので、PARはFBUを通したミネソタからのバッファリングのタイミングか下層シグナリング(例えば、ミネソタとの接続の解放のしるし)を得ます。 手順の詳細は以下の通りです:
(a) A router solicitation for proxy router advertisement MAY be sent
to the PAR.
(a) プロキシルータ通知のためのルータ懇願をPARに送るかもしれません。
Yokota & Dommety Informational [Page 12] RFC 5271 3G CDMA Fast Handover June 2008
速い[12ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
(b) The proxy router advertisement MAY be sent to the MN. If the
information on the NAR is not available by the PAR, "0::0" MUST
be used for the options related to the NAR (e.g., IP address of
the NAR).
(b) プロキシルータ通知をミネソタに送るかもしれません。 NARの情報がPARで利用可能でないなら「0:、:、」NAR(例えば、NARのIPアドレス)に関連するオプションに0インチを使用しなければなりません。
(c) The MN sends the FBU or the access network indicates the close
of the connection with the MN by the lower-layer signaling. If
the MN cannot formulate the NCoA, "0::0", MUST be used for the
NCoA in the FBU. If the B flag is set in the FBU, the PAR
SHOULD start buffering packets destined for the PCoA.
(c) ミネソタがFBUを送るか、またはアクセスネットワークは下層による合図するミネソタとの接続の閉鎖を示します。 ミネソタがNCoAを定式化できないなら「0:、:、」何0インチも、FBUのNCoAに使用しなければなりません。 B旗がFBUに設定されるなら、PAR SHOULDはPCoAのために運命づけられたパケットをバッファリングし始めます。
(d) The link-layer connection associated with the PAR is closed and
a new traffic channel is assigned in the new access network.
(d) PARに関連づけられたリンクレイヤ接続は閉店されています、そして、新しい交通チャンネルは新しいアクセスネットワークで選任されます。
(e) The MN attaches to the new access network. This part is the
same as described in Section 5.1 and illustrated in Figure 3.
(e) ミネソタは新しいアクセスネットワークに付きます。 この部分はセクション5.1で説明されて、図3で例証されるのと同じです。
(f) The MN sends the UNA to the NAR.
(f) ミネソタはUNAをNARに送ります。
(g) The MN sends the Fast Binding Update (FBU) to the PAR via the
NAR.
(g) ミネソタはNARを通してFast Binding Update(FBU)をPARに送ります。
(h) The NAR forwards the FBU from the MN to the PAR.
(h) NARはミネソタからPARまでFBUを進めます。
(i) The PAR sends the Handover Initiate (HI) to the NAR with the
Code set to 1.
(i) PARはHandover Initiate(HI)を1に用意ができているCodeとNARに送ります。
(j) The NAR sends the Handover Acknowledge (HAck) back to the PAR.
(j) NARはHandover Acknowledge(HAck)をPARに送り返します。
(k) The PAR sends the FBAck to the NAR.
(k) PARはFBAckをNARに送ります。
(l) If the PAR is buffering packets destined for the PCoA, it starts
forwarding them as well as newly arriving ones to the NAR.
(l) PARがPCoAのために運命づけられたパケットをバッファリングしているなら、それはそれらを進めている、新たに到着しているものをNARに始めます。
(m) The NAR delivers the packets to the MN.
(m) NARはパケットをミネソタに届けます。
(n) The MN sends the BU to the HA to update the BCE with the NCoA
and the HA sends back the BA to the MN.
(n) ミネソタはNCoAと共にBCEをアップデートするためにBUをHAに送ります、そして、HAはミネソタにBAを返送します。
Yokota & Dommety Informational [Page 13] RFC 5271 3G CDMA Fast Handover June 2008
速い[13ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | | | |
(c) |- - - - - - ->|(buffering) | | |
| | | | |
(d) handover | | | |
| | | | |
+--------------------------------------------------------------+
(e) | Attachment procedure |
+--------------------------------------------------------------+
| UNA | | |
(f) |----------------------------->| | |
| FBU | | |
(g) |----------------------------->| | |
| | FBU | | |
(h) | |<--------------| | |
| | HI | | |
(i) | |-------------->| | |
| | HAck | | |
(j) | |<--------------| | |
| | FBack | | |
(k) | |-------------->| | |
| |forward packets| | |
(l) | |==============>| | |
| deliver packets | | |
(m) |<=============================| | |
| | BU/BA | | |
(n) |<------------------------------------------->| |
| | | | |
ミネソタ平価NAR、ハ、AAA| RtSolPr| | | | (a) |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| PrRtAdv| | | | (b) | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| FBU| | | | (c) |- - - - - - ->|(バッファリング) | | | | | | | | (d) 引き渡し| | | | | | | | | +--------------------------------------------------------------+ (e)| 付属手順| +--------------------------------------------------------------+ | ウナ| | | (f) |----------------------------->| | | | FBU| | | (g) |----------------------------->| | | | | FBU| | | (h) | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| こんにちは| | | (i) | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| ハッキング| | | (j) | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| FBack| | | (k) | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |前進のパケット| | | (l) | |==============>|、|、|、| パケットを届けてください。| | | (m) |<===============| | | | | BU/Ba| | | (n) |<------------------------------------------->| | | | | | |
Figure 4: MIPv6 Fast Handover Operation (Reactive Mode)
図4: MIPv6の速い引き渡し操作(反応モード)
To indicate the PAR to buffer packets destined for the PCoA, in step (c), a new flag 'B' is defined in the FBU. When the PAR receives the FBU with this flag set, it SHOULD buffer packets for the MN. The PAR MAY also start buffering packets for the MN based on lower layer signal during handover. Since the packets are buffered at the PAR in this scenario, the UNA, which is received and processed by the NAR, can not be used to trigger to forward the buffered packets at the PAR. In Figure 4, the HAck from the NAR is used as the trigger for the forwarding of any buffered packets.
PCoAのために運命づけられたパケットをバッファリングするようにPARを示すために、ステップ(c)では、新しい旗'B'はFBUで定義されます。 PARが受信するとき、この旗があるFBUはセットして、それはミネソタへのSHOULDバッファパケットです。 また、PAR MAYは引き渡しの間に下層信号に基づくミネソタにパケットをバッファリングし始めます。パケットがこのシナリオのPARでバッファリングされるので、PARでバッファリングされたパケットのフォワードに引き金となるのにUNA(NARによって受け取られて、処理される)は使用できません。 図4では、NARからのHAckはどんなバッファリングされたパケットの推進にも引き金として使用されます。
The handover indication from the lower layer of 3G CDMA system is reasonably reliable by the periodical reports from the MN; however, there are several situations where the target link is not available
3G CDMAシステムの下層からの引き渡し指示はミネソタからの定期刊行のレポートで合理的に信頼できます。 しかしながら、いくつかの状況が目標リンクが入手できないところにあります。
Yokota & Dommety Informational [Page 14] RFC 5271 3G CDMA Fast Handover June 2008
速い[14ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
after the handover (step (d)) and the MN comes back to the PAR, or the MN is not able to move to the target link for some reason after the connection was closed. If this is the case, the attachment procedure is performed on the previous link. The packets buffered at the PAR SHOULD be delivered to the MN after the connection is re-established.
引き渡しの後、((d))を踏んでください。そうすれば、ミネソタはPARに戻ります、または、接続が閉店したある理由で後にミネソタが目標リンクに動くことができません。 これがそうであるなら、付属手順は前のリンクに実行されます。 パケット、PAR SHOULDでバッファリングされて、接続を復職させた後にミネソタに届けてください。
5.3. Considerations on the Link Indications
5.3. リンク指摘での問題
This section discusses if the link indications assumed in this document meet the principles defined in Section 2 of RFC 4907[20], which suggests 11 architectural principles on the link indication and the effectiveness of the optimization. This document relies on the 3G CDMA network regarding the link indication, which is precisely specified by 3GPP2. Therefore, principles (1) to (5), (7), (8), and (11), that is, "Model Validation", "Clear Definition", "Robustness", "Recovery from Invalid Indications", "Congestion Control", "Interoperability", "Race Condition", and "Transport of Link Indications" are considered by those specs. Principle (6) "Effectiveness" mentions the effectiveness of the optimization. This document bases its effectiveness on RFC 5268. Therefore, this principle is dealt by that RFC. Principle (9) "Metric Consistency" mentions inconsistencies between link and routing layer metrics. The spec of this document does not change the routing metrics and multi-homing is not considered. Finally, principle (10) "Layer Compression", mentions an overhead reduction scheme and interoperability. This document does not deal with overhead reduction and therefore this principle does not apply.
このセクションは、本書では想定されたリンク指摘がリンク指示と最適化の有効性で11の建築原則を勧めるRFC 4907[20]のセクション2で定義された原則を満たすかどうか論じます。 このドキュメントはリンク指示に関する3G CDMAネットワークを当てにします。(指示は3GPP2によって正確に指定されます)。 すなわち、したがって、(5)、(7)、(8)、および(11)への原則(1)、「モデル検証」、「明確な定義」、「相互運用性」、「競合条件」、および「リンク指摘の輸送」はそれらの仕様によって「丈夫さ」、「無効の指摘からの回復」、「輻輳制御」と考えられます。 原則(6)「有効性」は最適化の有効性について言及します。 このドキュメントは有効性をRFC5268に基礎づけます。 したがって、この原則はそのRFCによって取扱われます。 原則(9)「メートル法の一貫性」はリンクとルーティング層の測定基準の間の矛盾について言及します。 このドキュメントの仕様はルーティング測定基準を変えません、そして、マルチホーミングは考えられません。 (10)が「圧縮を層にする」という最終的に原則は頭上の減少計画と相互運用性について言及します。 このドキュメントは頭上の減少に対処しません、そして、したがって、この原則は当てはまりません。
6. Message Format
6. メッセージ・フォーマット
6.1. Handover Assist Information Option
6.1. 引き渡しアシスト情報オプション
If the lower layer information of the new point of attachment is not represented as the link-layer address, the following option SHOULD be used. The primary purpose of this option is to convey the handover assist information described in Section 4.
新しい接着点の情報は下層であるならリンクレイヤアドレスとして表されません、以下のオプションSHOULD。使用されます。 このオプションの第一の目的はセクション4で説明された引き渡しアシスト情報を伝えることです。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Option-Code | HAI-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HAI-Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| HAI-長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HAI-値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Yokota & Dommety Informational [Page 15] RFC 5271 3G CDMA Fast Handover June 2008
速い[15ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Type 29
29をタイプしてください。
Length The size of this option in 8 octets including the
Type, Length, Option-Code, and HAI-Length (Handover
Assist Information-Length) fields.
8つの八重奏における、Typeを含むこのオプションのサイズ、Length、Option-コード、およびHAI-長さ(引き渡しAssist情報長さ)がさばく長さ。
Option-Code
1: Access Network Identifier (AN ID)
2: Sector ID
オプションコード1: ネットワーク識別子(ID)2にアクセスしてください: セクターID
HAI-Length The size of the HAI-Value field in octets.
HAI-価値のサイズが八重奏でさばくHAI-長さ。
HAI-Value The value specified by the Option-Code.
Option-コードによって指定された値をHAI評価してください。
If those that received this message do not support this option, they SHOULD treat this option as opaque and MUST NOT drop it.
それらであるなら、受け取って、このメッセージがこのオプションをサポートしないで、それらがSHOULDであることは不明瞭なこの同じくらいオプションを扱って、それを落としてはいけません。
Option-Code indicates the particular type of handover assist information. Currently, two types of information are defined to assist the discovery of the NAR (see Section 3).
オプションコードは、引き渡しの特定のタイプが情報を補助するのを示します。 現在、情報の2つのタイプが、NARの発見を促進するために定義されます(セクション3を見てください)。
Depending on the size of the HAI-Value field, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets. The HAI-Length is used to disambiguate the size of the HAI-Value.
HAI-値の分野のサイズによって、全体のオプションサイズが8つの八重奏の倍数であることを保証するのに適切な詰め物を使用しなければなりません。 HAI-長さは、HAI-価値のサイズのあいまいさを除くのに使用されます。
The handover assist information MAY replace the New Access Point Link-Layer Address in 3G CDMA networks.
引き渡しアシスト情報は3G CDMAネットワークでAddress New Access Point Link-層を取り替えるかもしれません。
6.2. Mobile Node Identifier Option
6.2. モバイルノード識別子オプション
This option is used to transfer the Identifier of the MN, which is not its link-layer address.
このオプションは、そのリンクレイヤアドレスでないミネソタのIdentifierを移すのに使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type | Length | Option-Code | MN ID-Length |
+---------------------------------------------------------------+
| MN ID ...
+-----------------------------
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | タイプ| 長さ| オプションコード| MnのID-長さ| +---------------------------------------------------------------+ | ミネソタID… +-----------------------------
Type 30
30をタイプしてください。
Length The size of this option is in 8 octets including the
Type, Length, and Option-Code.
長さ、このオプションのサイズはType、Length、およびOption-コードを含む8つの八重奏中です。
Yokota & Dommety Informational [Page 16] RFC 5271 3G CDMA Fast Handover June 2008
速い[16ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Option-Code
1: NAI [4]
2: IMSI (See Section 3)
オプションコード1: NAI[4]2: IMSI(セクション3を見ます)
MN ID-Length The length of the MN ID in octets.
ミネソタのID-長さ、八重奏における、ミネソタIDの長さ。
MN ID MN ID value
ミネソタIDミネソタID価値
The MN ID MAY replace the MN Link-Layer Address in 3G CDMA networks.
ミネソタIDは3G CDMAネットワークでミネソタAddress Link-層を取り替えるかもしれません。
6.3. New Flag Extension to FBU Message
6.3. FBUメッセージへの新しい旗の拡大
The MN MUST send the FBU to the PAR with the following new (B) flag set in the previous network to indicate the PAR to buffer packets destined for the PCoA. The rest of the Binding Update message format remains the same as defined in [2] and with the additional (M), (R), and (P) flags as specified in [14], [15], and [16], respectively.
ミネソタは前のネットワークでPCoAのために運命づけられたパケットをバッファリングするようにPARを示すように設定された以下の新しい(B)旗でFBUをPARに送らなければなりません。 Binding Updateメッセージ・フォーマットの残りは[2]、追加(M)、(R)、および指定されるとしての(P)旗が[14]、[15]、および[16]にある状態でそれぞれ定義されるように同じままで残っています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|B| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B flag: If the 'B' flag is set, the PAR SHOULD start buffering
the packets destined for the MN as specified in
Section 5.2.
B旗: 'B'旗が設定されるなら、PAR SHOULDはセクション5.2における指定されるとしてのミネソタに運命づけられたパケットをバッファリングし始めます。
6.4. New Flag Extension to PrRtAdv Message
6.4. PrRtAdvメッセージへの新しい旗の拡大
A new flag 'R' is defined in the PrRtAdv to inform the MN about the fast handover mode that the network supports.
新しい旗'R'は、ネットワークが支持する速い引き渡しモードに関してミネソタに知らせるためにPrRtAdvで定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |R| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype|R| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Yokota & Dommety Informational [Page 17] RFC 5271 3G CDMA Fast Handover June 2008
速い[17ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
R flag: If the 'R' flag is set, the network supports only the
reactive handover mode. Otherwise, the network
supports both the predictive and reactive fast
handover mode.
R旗: 'R'旗が設定されるなら、ネットワークは反応引き渡しモードだけを支持します。 さもなければ、ネットワークは予言的で反応している速い引き渡しモードを支持します。
7. Security Considerations
7. セキュリティ問題
The security considerations for Mobile IPv6 fast handover are described in [3]. When a 3G CDMA network is considered, it can be assumed that the PAR and the NAR have a trust relationship and the links between them and those between the ARs and the MN are secured. The MN is authenticated every time it attaches to the new link; therefore, the AR can securely identify the MN. Depending on the operator's policy, however, SEcure Neighbor Discovery (SEND) [18] and the shared handover key defined in [17] can also be applied.
モバイルIPv6速い引き渡しのためのセキュリティ問題は[3]で説明されます。 3G CDMAネットワークが考えられるとき、PARとNARには信用関係があると思うことができて、ARsとミネソタの間のそれらとそれらとのリンクは固定されています。 新しいリンクに付くときはいつも、ミネソタは認証されます。 したがって、ARはしっかりとミネソタを特定できます。 しかしながら、オペレータの方針によって、また、SEcure Neighborディスカバリー(SEND)[18]と[17]で定義された共有された引き渡しキーは適用できます。
8. IANA Considerations
8. IANA問題
This document defines two new IPv6 Neighbor Discovery options that have been assigned from the same space as the IPv6 Neighbor Discovery Options defined in [19].
このドキュメントは[19]で定義されたIPv6 NeighborディスカバリーOptionsと同じスペースから割り当てられた2つの新しいIPv6 Neighborディスカバリーオプションを定義します。
29: Handover Assist Information Option (Section 6.1)
29: 引き渡しアシスト情報オプション(セクション6.1)
30: Mobile Node Identifier Option (Section 6.2)
30: モバイルノード識別子オプション(セクション6.2)
This document creates two new registries for the Option-Code field in the Handover Assist Information Option and that in the Mobile Node Identifier Option. The values for the Option-Code must be within the range 0-255. New values for both registries can be allocated by Standards Action or IESG approval [5].
このドキュメントはモバイルNode Identifier OptionでHandover Assist情報OptionとそれでOption-コード分野に2つの新しい登録を作成します。 範囲0-255の中にOption-コードのための値があるに違いありません。 Standards ActionかIESG承認[5]で両方の登録への新しい値を割り当てることができます。
The Option-Code values that have been assigned by IANA are as follows:
IANAによって割り当てられたOption-コード値は以下の通りです:
Option-Code for Handover Assist Information Option
Value Description Reference
----- ---------------------------- ----------
0 Reserved
1 ANID Section 6.1
2 Sector ID Section 6.1
引き渡しアシスト情報オプション価値記述参照のためのオプションコード----- ---------------------------- ---------- 0 1つの予約されたANID部6.1の2セクターID部6.1
Yokota & Dommety Informational [Page 18] RFC 5271 3G CDMA Fast Handover June 2008
速い[18ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Option-Code for Mobile Node Identifier Option
Value Description Reference
----- ---------------------------- ----------
0 Reserved
1 NAI Section 6.2
2 IMSI Section 6.2
モバイルノード識別子オプション価値記述参照のためのオプションコード----- ---------------------------- ---------- 0 1つの予約されたNAI部6.2の2IMSI部6.2
9. Acknowledgements
9. 承認
The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved Kafle, and Vijay Devarapalli for providing feedback and support for this work. The authors would also thank Sebastian Thalanany for 3GPP2 expert review.
作者は、この仕事のフィードバックとサポートを提供して頂いて、Kuntalチョードリ、Ashutoshドゥッタ、Ved Kafle、およびビジェイDevarapalliに感謝したがっています。 また、作者は3GPP2の専門のレビューについてセバスチャンThalananyに感謝するでしょう。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June
2008.
[3]Koodli、R.、エド、「モバイルIPv6速い身柄の引き渡し」、RFC5268、6月2008日
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
2005年12月の[4]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[5] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[6] ITU-T Recommendation, "The international identification plan
for mobile terminals and mobile users", ITU-T E.212, May 2004.
[6]ITU-T Recommendation、「移動体端末と可動のユーザのための国際的な識別プラン」、ITU-T E.212、2004年5月。
10.2. Informative References
10.2. 有益な参照
[7] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks",
RFC 4260, November 2005.
[7] マッキャン、P.、「モバイルIPv6は802.11のために速くネットワークを引き渡す」RFC4260、2005年11月。
[8] 3GPP2 TSG-C, "cdma2000 High Rate Packet Data Air Interface
Specification", C.S0024-A v.2.0, July 2005.
2005年7月の[8] 3GPP2 TSG-C、"cdma2000 High Rate Packet Data Air Interface Specification"C.S0024-A v.2.0。
[9] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability
Specification", A.S0001-A v.2.0, June 2001.
[9]3GPP2 TSG-A、「3GPP2アクセスネットワーク・インターフェース相互運用性仕様」、A.S0001-A v.2.0、2001年6月。
Yokota & Dommety Informational [Page 19] RFC 5271 3G CDMA Fast Handover June 2008
速い[19ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
[10] 3GPP2 TSG-A, "Interoperability Specification for High Rate
Packet 1 2 Data (HRPD) Access Network Interfaces - Rev A.",
A.S0007-A v.2.0, May 2003.
[10] 3GPP2 TSG-A、「高い率パケット1 2データ(HRPD)アクセスネットワーク・インターフェースのための相互運用性仕様--A.を回転させてください」、A.S0007-A v.2.0、2003年5月。
[11] 3GPP2 TSG-A, "Interoperability Specification (IOS) for High
Rate Packet Data (HRPD) Access Network Interfaces", 3GPP2
A.S0008-0 v3.0, May 2003.
[11]3GPP2 TSG-A、「高い率パケットデータ(HRPD)アクセスネットワーク・インターフェースのための相互運用性仕様(IOS)」、3GPP2A.S0008-0 v3.0、2003年5月。
[12] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
and Mobile IP services", X.S0011-002-D v.1.0, February 2006.
[12] 3GPP2 TSG-X、「cdma2000無線電信IPは規格をネットワークでつなぎます」。 「簡単なIPとモバイルIPサービス」、X.S0011-002-D v.1.0、2006年2月。
[13] Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury,
"Mobile IPv6 Bootstrapping for the Authentication Option
Protocol", Work in Progress, September 2007.
[13] V.、パテル、A.、Keung、K.、およびK.チョードリ、「認証オプションプロトコルのために独力で進むモバイルIPv6」というDevarapalliは進行中(2007年9月)で働いています。
[14] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
[14] ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。
[15] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[15]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[16] Gundavell, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", Work in Progress, February
2008.
[16]Gundavell、S.(エド)とレオンとK.とDevarapalliとV.とチョードリ、K.とB.パティル、「プロキシのモバイルIPv6"、処理中の作業、2008年2月。」
[17] Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6
Handover Key using SEND", RFC 5269, June 2008.
[17] ケンフ、J.、エドR.Koodli、「左右対称のFMIPv6引き渡し主要な使用を分配して、発信してください」、RFC5269、2008年6月。
[18] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[18]Arkko、J.、エド、ケンフ、J.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971、3月2005日
[19] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[19]Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
[20] Aboba, B., Ed., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
[20]Aboba、B.、エド、「リンク指摘の建築含意」、RFC4907、6月2007日
Yokota & Dommety Informational [Page 20] RFC 5271 3G CDMA Fast Handover June 2008
速い[20ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
Authors' Addresses
作者のアドレス
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP
KDDI研究室2-1-15Ohara、Hidetoshiヨコタ埼玉ふじみ野356-8502JP
Phone: +81 49 278 7894 Fax: +81 49 278 7510 EMail: yokota@kddilabs.jp
以下に電話をしてください。 +81 49 278 7894Fax: +81 49 278 7510はメールされます: yokota@kddilabs.jp
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US
西タスマン・DriveゴパルDommetyシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
Phone: +1 408 525 1404 EMail: gdommety@cisco.com
以下に電話をしてください。 +1 1404年の408 525メール: gdommety@cisco.com
Yokota & Dommety Informational [Page 21] RFC 5271 3G CDMA Fast Handover June 2008
速い[21ページ]RFC5271 3G CDMA引き渡し2008年6月の情報のヨコタとDommety
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に情報を記述してください。
Yokota & Dommety Informational [Page 22]
ヨコタとDommety情報です。[22ページ]
一覧
スポンサーリンク
