RFC4830 日本語訳
4830 Problem Statement for Network-Based Localized Mobility Management(NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT=29815 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kempf, Ed. Request for Comments: 4830 DoCoMo USA Labs Category: Informational April 2007
ワーキンググループのJ.ケンフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4830年のDoCoMo米国研究室カテゴリ: 情報の2007年4月
Problem Statement for Network-Based Localized
Mobility Management (NETLMM)
ネットワークを拠点とするローカライズしている移動性管理のための問題声明(NETLMM)
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management.
移動性管理であるとローカライズされているのは、多くのソリューションが既に利用可能のIETFのよく理解されている概念です。 このドキュメントは、それのすべてが移動性管理にホストにかかわる既存のソリューションの主要な短所を見て、ネットワークを拠点とするローカルの移動性管理のために主張します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. The Local Mobility Problem ......................................4
3. Scenarios for Localized Mobility Management .....................7
3.1. Large Campus ...............................................7
3.2. Advanced Cellular Network ..................................7
3.3. Picocellular Network with Small But Node-Dense Last
Hop Links ..................................................8
4. Problems with Existing Solutions ................................8
5. Advantages of Network-based Localized Mobility Management .......9
6. Security Considerations ........................................10
7. Informative References .........................................10
8. Acknowledgements ...............................................11
9. Contributors ...................................................12
1. 序論…2 1.1. 用語…3 2. ローカルの移動性問題…4 3. ローカライズしている移動性管理のためのシナリオ…7 3.1. 大きいキャンパス…7 3.2. セルラー・ネットワークを唱えます…7 3.3. Picocellularは最後の小さい、しかし、ノード濃いホップでリンクをネットワークでつなぎます…8 4. 既存のソリューションに関する問題…8 5. ネットワークベースの利点は、移動性が管理であるとローカライズしました…9 6. セキュリティ問題…10 7. 有益な参照…10 8. 承認…11 9. 貢献者…12
Kempf Informational [Page 1] RFC 4830 NETLMM Problem Statement April 2007
[1ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
1. Introduction
1. 序論
Localized mobility management has been the topic of much work in the IETF. The experimental protocols developed from previous works, namely Fast-Handovers for Mobile IPv6 (FMIPv6) [13] and Hierarchical Mobile IPv6 (HMIPv6) [18], involve host-based solutions that require host involvement at the IP layer similar to, or in addition to, that required by Mobile IPv6 [10] for global mobility management. However, recent developments in the IETF and the Wireless LAN (WLAN) infrastructure market suggest that it may be time to take a fresh look at localized mobility management.
移動性管理であるとローカライズされているのは、IETFでの多くの仕事の話題です。 前の作品から開発された実験プロトコル(すなわち、モバイルIPv6(FMIPv6)[13]とHierarchicalのモバイルIPv6(HMIPv6)[18]のためのFast-身柄の引き渡し)はそれかグローバルな移動性管理のためにモバイルIPv6[10]によって必要とされたそれで同様のIP層でホストかかわり合いを必要とするホストベースのソリューションにかかわります。 しかしながら、IETFの最近の進展とWireless LAN(WLAN)インフラストラクチャ市場は、もうローカライズしている移動性管理への新鮮な一見を取るべき時間であるかもしれないと示唆します。
First, new IETF work on global mobility management protocols that are not Mobile IPv6, such as Host Identity Protocol (HIP) [16] and IKEv2 Mobility and Multihoming (MOBIKE) [4], suggests that future wireless IP nodes may support a more diverse set of global mobility protocols. While it is possible that existing localized mobility management protocols could be used with HIP and MOBIKE, some would require additional effort to implement, deploy, or in some cases, even specify in a non-Mobile IPv6 mobile environment.
まず最初に、Host Identityプロトコル(HIP)[16]やIKEv2 MobilityとMultihoming(MOBIKE)[4]などのモバイルIPv6でないグローバルな移動性管理プロトコルに対する新しいIETF仕事は、将来のワイヤレスのIPノードが、よりさまざまのセットのグローバルな移動性プロトコルをサポートするかもしれないのを示します。 或るものは、追加取り組みが実装するのをHIPとMOBIKEと共に移動性管理プロトコルであるとローカライズされた存在は使用できたのが可能である間、展開するか、またはいくつかの場合、非変わりやすいIPv6モバイル環境で指定さえするように必要とするでしょう。
Second, the success in the WLAN infrastructure market of WLAN switches, which perform localized management without any host stack involvement, suggests a possible paradigm that could be used to accommodate other global mobility options on the mobile node while reducing host stack software complexity, expanding the range of mobile nodes that could be accommodated.
2(少しもホストスタックかかわり合いなしでローカライズしている管理を実行するWLANスイッチのWLANインフラストラクチャ市場の成功)番目はホストスタックソフトウェアの複雑さを減少させている間、モバイルノードで他のグローバルな移動性オプションに対応するのに使用できた可能なパラダイムを示します、対応できたモバイルノードの範囲を広げて。
This document briefly describes the general local mobility problem and scenarios where localized mobility management would be desirable. Then problems with existing or proposed IETF localized mobility management protocols are briefly discussed. The network-based mobility management architecture and a short description of how it solves these problems are presented. A more detailed discussion of goals for a network-based, localized mobility management protocol and gap analysis for existing protocols can be found in [11]. Note that IPv6 and wireless links are considered to be the initial scope for a network-based localized mobility management, so the language in this document reflects that scope. However, the conclusions of this document apply equally to IPv4 and wired links, where nodes are disconnecting and reconnecting.
このドキュメントは簡潔に一般的なローカルの移動性問題について説明します、そして、移動性管理であるとローカライズされるところでシナリオは望ましいでしょう。 そして、簡潔に存在することに関する問題か移動性管理プロトコルであるとローカライズされた提案されたIETFについて議論します。 ネットワークベースの移動性管理体系とそれがどうこれらの問題を解決するかに関する短い記述は提示されます。 [11]で既存のプロトコルのためのネットワークベースの、そして、ローカライズしている移動性管理プロトコルとギャップ分析の目標の、より詳細な議論を見つけることができます。 言語が本書ではその範囲を反映するように、IPv6とワイヤレスのリンクがネットワークを拠点とするローカライズしている移動性管理のための初期の範囲であると考えられることに注意してください。 しかしながら、このドキュメントの結末は等しくIPv4とワイヤードなリンクに適用されます。そこではノードは、切断するのと再接続です。
Kempf Informational [Page 2] RFC 4830 NETLMM Problem Statement April 2007
[2ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
1.1. Terminology
1.1. 用語
Mobility terminology in this document follows that in RFC 3753 [14], with the addition of some new and revised terminology given here:
移動性用語はRFC3753[14]で本書ではそれに続きます、何らかの新しくて改訂された用語の追加をここに与えていて:
WLAN Switch
WLANスイッチ
A WLAN switch is a multiport bridge Ethernet [8] switch that
connects network segments but also allows a physical and logical
star topology, which runs a protocol to control a collection of
802.11 [6] access points. The access point control protocol
allows the switch to perform radio resource management functions
such as power control and terminal load balancing between the
access points. Most WLAN switches also support a proprietary
protocol for inter-subnet IP mobility, usually involving some kind
of inter-switch IP tunnel, which provides session continuity when
a terminal moves between subnets.
WLANスイッチはネットワークセグメントを接続しますが、プロトコルを実行する物理的で論理的なスタートポロジーが802.11[6]アクセスポイントの収集をまた制御できる「マルチ-ポート」ブリッジイーサネット[8]スイッチです。 アクセスポイント制御プロトコルで、スイッチはアクセスポイントの間の電源制御装置や端末のロードバランシングなどのラジオリソース管理機能を実行できます。 また、ほとんどのWLANスイッチが相互サブネットIPの移動性、通常意味ありげなある種の相互スイッチIPトンネルに固有のプロトコルをサポートします。(端末がサブネットの間で移行すると、それは、セッションの連続を提供します)。
Access Network
アクセスネットワーク
An access network is a collection of fixed and mobile network
components allowing access to the Internet all belonging to a
single operational domain. It may consist of multiple air
interface technologies (for example, 802.16e [7], Universal Mobile
Telecommunications System (UMTS) [1], etc.) interconnected with
multiple types of backhaul interconnections (such as Synchronous
Optical Network (SONET) [9], metro Ethernet [15] [8], etc.).
アクセスネットワークはただ一つの操作上のドメインにすべて属すインターネットへのアクセスを許す修理されてモバイルのネットワーク要素の収集です。 それは複数のタイプの逆送インタコネクト(同期式光通信網(Sonet)[9]、地下鉄イーサネット[15][8]などの)でインタコネクトされた複数の空気インタフェース技術(例えば、802.16e[7]、UniversalのモバイルTelecommunications System(UMTS)[1]など)から成るかもしれません。
Local Mobility (revised)
地方の移動性(改訂されます)
Local Mobility is mobility over an access network. Note that
although the area of network topology over which the mobile node
moves may be restricted, the actual geographic area could be quite
large, depending on the mapping between the network topology and
the wireless coverage area.
地方のMobilityはアクセスネットワークの上の移動性です。 モバイルノードが移行するネットワーク形態の領域が制限されるかもしれませんが、実際の地理的な地域がかなり広大であるかもしれないことに注意してください、ネットワーク形態とワイヤレスの適用範囲の地域の間のマッピングによって。
Localized Mobility Management
移動性管理であるとローカライズされます。
Localized Mobility Management is a generic term for any protocol
that maintains the IP connectivity and reachability of a mobile
node for purposes of maintaining session continuity when the
mobile node moves, and whose signaling is confined to an access
network.
Mobility Managementであるとローカライズされているのは、モバイルノードが移行して、シグナリングがアクセスネットワークに閉じ込められるセッションの連続を維持する目的のためのモバイルノードのIPの接続性と可到達性を維持するどんなプロトコルのための総称です。
Localized Mobility Management Protocol
移動性管理プロトコルであるとローカライズされます。
A protocol that supports localized mobility management.
それがサポートするプロトコルは、移動性が管理であるとローカライズしました。
Kempf Informational [Page 3] RFC 4830 NETLMM Problem Statement April 2007
[3ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
Global Mobility Management Protocol
グローバルな移動性管理プロトコル
A Global Mobility Management Protocol is a mobility protocol used
by the mobile node to change the global, end-to-end routing of
packets for purposes of maintaining session continuity when
movement causes a topology change, thus invalidating a global
unicast address of the mobile node. This protocol could be Mobile
IP [10] [17], but it could also be HIP [16] or MOBIKE [4].
Global Mobility Managementプロトコルはモバイルノードによって使用される、動きがトポロジー変化を引き起こすとセッションの連続を維持する目的のために終わりから終わりへのパケットのグローバルなルーティングを変える移動性プロトコルです、その結果、モバイルノードのグローバルなユニキャストアドレスを無効にします。 このプロトコルはモバイルIP[10][17]であるかもしれませんが、また、それは、HIP[16]かMOBIKE[4]であるかもしれない。
Global Mobility Anchor Point
グローバルな移動性アンカー・ポイント
A node in the network where the mobile node maintains a permanent
address and a mapping between the permanent address and the local
temporary address where the mobile node happens to be currently
located. The Global Mobility Anchor Point may be used for
purposes of rendezvous and possibly traffic forwarding.
ネットワークにおけるモバイルノードが本籍を維持するノードと本籍とローカルの仮の住所の間のモバイルノードが現在たまたま見つけられるマッピング。 Global Mobility Anchor Pointはランデブーとことによるとトラフィック推進の目的に使用されるかもしれません。
Intra-Link Mobility
イントラリンクの移動性
Intra-Link Mobility is mobility between wireless access points
within a link. Typically, this kind of mobility only involves
Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2
mobility. No IP subnet configuration is required upon movement
since the link does not change, but some IP signaling may be
required for the mobile node to confirm whether or not the change
of wireless access point also resulted in the previous access
routers becoming unreachable. If the link is served by a single
access point/router combination, then this type of mobility is
typically absent. See Figure 1.
イントラリンクMobilityはリンクの中のワイヤレス・アクセスポイントの間の移動性です。 通常、この種類の移動性がLayer2メカニズムを伴うだけであるので、Intra-リンクMobilityはしばしばLayer2の移動性と呼ばれます。 リンクが変化しないので、IPサブネット構成は全く動きのときに必要ではありませんが、モバイルノードが、また、ワイヤレス・アクセスポイントの変化が手が届かなくなる前のアクセスルータをもたらしたかどうか確認するのに何らかのIPシグナリングが必要であるかもしれません。 シングルアクセスポイント/ルータ組み合わせでリンクが役立たれているなら、このタイプの移動性は通常欠けています。 図1を参照してください。
2. The Local Mobility Problem
2. ローカルの移動性問題
The local mobility problem is restricted to providing IP mobility management for mobile nodes within an access network. The access network gateways function as aggregation routers. In this case, there is no specialized routing protocol (e.g., Generic Tunneling Protocol (GTP), Cellular IP, Hawaii, etc.) and the routers form a standard IP routed network (e.g., OSPF, Intermediate System to Intermediate System (IS-IS), RIP, etc.). This is illustrated in Figure 1, where the access network gateway routers are designated as "ANG". Transitions between service providers in separate autonomous systems, or across broader, topological "boundaries" within the same service provider, are excluded.
ローカルの移動性問題はアクセスネットワークの中でモバイルノードのためのIP移動性管理を提供するのに制限されます。 アクセスネットワークゲートウェイは集合ルータとして機能します。 この場合、どんな専門化しているルーティング・プロトコル(例えば、Generic Tunnelingプロトコル(GTP)、Cellular IP、ハワイなど)もなくて、ルータフォームの標準のIPがネットワークを発送した、(例えば、OSPF、Intermediate SystemへのIntermediate System、(-、)、RIPなど) これは図1で例証されます。そこでは、アクセスネットワークゲートウェイルータが「アン」として指定されます。 別々の自律システムか、同じサービスプロバイダーの中の、より広くて、位相的な「境界」の向こう側のサービスプロバイダーの間の変遷は除かれます。
Figure 1 depicts the scope of local mobility in comparison to global mobility. The Access Network Gateways (ANGs), GA1 and GB1, are gateways to their access networks. The Access Routers (ARs), RA1 and RA2, are in access network A; RB1 is in access network B. Note that
図1は比較における地方の移動性の範囲をグローバルな移動性に説明します。 Access Network Gateways(ANGs)(GA1とGB1)はそれらのアクセスネットワークへのゲートウェイです。 アクセスネットワークAにはAccess Routers(ARs)(RA1とRA2)はあります。 RB1がアクセスネットワークB.Noteにある、それ
Kempf Informational [Page 4] RFC 4830 NETLMM Problem Statement April 2007
[4ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
it is possible to have additional aggregation routers between ANG GA1 and ANG GB1, and the access routers if the access network is large. Access Points (APs) PA1 through PA3 are in access network A; PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are also possible, and other routers can separate the ARs from the ANGs. The figure implies a star topology for the access network deployment, and the star topology is the primary interest since it is quite common, but the problems discussed here are equally relevant to ring or mesh topologies in which ARs are directly connected through some part of the network.
アクセスネットワークが大きいなら、ANG GA1と、ANG GB1と、アクセスルータの間に追加集合ルータを持っているのは可能です。 アクセスネットワークAにはアクセスPoints(APs)のPA1からPA3があります。 PB1とPB2がアクセスネットワークB.Other ANGsにあります、ARs、そして、また、APsも可能です、そして、他のルータはANGsとARsを切り離すことができます。 図はアクセスネットワーク展開のためにスタートポロジーについて暗示して、それが全く一般的であるので、スタートポロジーは主要な関心ですが、ここで議論した問題はARsがネットワークの何らかの部分を通って直接接続されるtopologiesを鳴らすか、または網の目にかけるために等しく関連しています。
Access Network A Access Network B
アクセスはアクセスネットワークBをネットワークでつなぎます。
+-------+ +-------+
|ANG GA1| (other ANGs) |ANG GB1| (other ANGs)
+-------+ +-------+
@ @ @
@ @ @
@ @ @ (other routers)
@ @ @
@ @ @
@ @ @
+------+ +------+ +------+
|AR RA1| |AR RA2|(other ARs) |AR RB1| (other ARs)
+------+ +------+ +------+
* * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * (other APs) * * (other APs)
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \
------ ------ ------ ------ ------
+-------+ +-------+ |アンGA1| (他のANGs) |アンGB1| (他のANGs) +-------+ +-------+ @ @ @ @ @ @ @ @ @ (other routers) @ @ @ @ @ @ @ @ @ +------+ +------+ +------+ |アルゴンRA1| |アルゴンRA2|(他のARs) |アルゴンRB1| (他のARs) +------+ +------+ +------+ * * * * * * * * * * * * * * * * * * * * * * * * * * (other APs) * * (other APs) /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ /PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \ ------ ------ ------ ------ ------
+--+ +--+ +--+ +--+
|MN|----->|MN|----->|MN|-------->|MN|
+--+ +--+ +--+ +--+
Intra-link Local Global
(Layer 2) Mobility Mobility
Mobility
+--+ +--+ +--+ +--+ |ミネソタ|、-、-、-、--、>|ミネソタ|、-、-、-、--、>|ミネソタ|、-、-、-、-、-、-、--、>|ミネソタ| +--+ +--+ +--+ +--+ イントラリンクの地方のグローバルな(層2)移動性移動性の移動性
Figure 1. Scope of Local and Global Mobility Management
図1。 地方の、そして、グローバルな移動性管理の範囲
Kempf Informational [Page 5] RFC 4830 NETLMM Problem Statement April 2007
[5ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
As shown in the figure, a global mobility protocol may be necessary when a mobile node (MN) moves between two access networks. Exactly what the scope of the access networks is depends on deployment considerations. Mobility between two APs under the same AR constitutes intra-link (or Layer 2) mobility, and is typically handled by Layer 2 mobility protocols (if there is only one AP/cell per AR, then intra-link mobility may be lacking). Between these two lies local mobility. Local mobility occurs when a mobile node moves between two APs connected to two different ARs.
モバイルノード(ミネソタ)が2つのアクセスネットワークの間で移行するとき、図に示されるように、グローバルな移動性プロトコルが必要であるかもしれません。 アクセスネットワークの範囲が何であるかというまさにことであることは展開問題によります。 同じARの下の2APsの間の移動性は、イントラリンク(または、Layer2)の移動性を構成して、Layer2移動性プロトコルによって通常扱われます(1ARあたり1つのAP/セルしかなければ、イントラリンクの移動性は欠けているかもしれません)。 これらの2の間に、地方の移動性があります。 モバイルノードが2異なったARsに接続された2APsの間で移行すると、地方の移動性は起こります。
Global mobility protocols allow a mobile node to maintain reachability when the MN's globally routable IP address changes. It does this by updating the address mapping between the permanent address and temporary local address at the global mobility anchor point, or even end to end by changing the temporary local address directly at the node with which the mobile node is corresponding. A global mobility management protocol can therefore be used between ARs for handling local mobility. However, there are three well-known problems involved in using a global mobility protocol for every movement between ARs. Briefly, they are:
ミネソタのものがIPアドレス変化をグローバルに発送可能するとき、グローバルな移動性プロトコルで、モバイルノードは可到達性を維持できます。 直接モバイルノードが対応しているノードで一時的なローカルアドレスを変えることによって終わるのは、本籍と一時的なローカルアドレスの間のアドレス・マッピングをアップデートすることによって、グローバルな移動性アンカー・ポイント、または同等の終わりにこれをします。 したがって、地方の移動性を扱うのにARsの間でグローバルな移動性管理プロトコルを使用できます。 しかしながら、ARsの間のあらゆる動きにグローバルな移動性プロトコルを使用するのにかかわる3つのよく知られる問題があります。 簡潔に、それらは以下の通りです。
1) Update latency. If the global mobility anchor point and/or
correspondent node (for route-optimized traffic) is at some
distance from the mobile node's access network, the global
mobility update may require a considerable amount of time. During
this time, packets continue to be routed to the old temporary
local address and are essentially dropped.
1) 潜在をアップデートしてください。 グローバルな移動性アンカー・ポイント、そして/または、通信員ノード(ルートで最適化されたトラフィックのための)が少し離れたところにモバイルノードのアクセスネットワークからあるなら、グローバルな移動性アップデートはかなりの時間を必要とするかもしれません。 この間に、パケットは、古い一時的なローカルアドレスに発送され続けて、本質的には下げられます。
2) Signaling overhead. The amount of signaling required when a
mobile node moves from one last-hop link to another can be quite
extensive, including all the signaling required to configure an IP
address on the new link and global mobility protocol signaling
back into the network for changing the permanent to temporary
local address mapping. The signaling volume may negatively impact
wireless bandwidth usage and real-time service performance.
2) オーバーヘッドに合図します。 モバイルノードが別のものへの1個の最後のホップリンクから移行するとき必要であるシグナリングの量はかなり大規模である場合があります、永久的な一時的なローカルアドレスマッピングを変えるためにネットワークに合図して戻りながら新しいリンクとグローバルな移動性プロトコルでIPアドレスを構成するのに必要であるすべてのシグナリングを含んでいて。 シグナリングボリュームは否定的にワイヤレスの帯域幅用法とリアルタイムのサービス性能に影響を与えるかもしれません。
3) Location privacy. The change in temporary local address as the
mobile node moves exposes the mobile node's topological location
to correspondents and potentially to eavesdroppers. An attacker
that can assemble a mapping between subnet prefixes in the mobile
node's access network and geographical locations can determine
exactly where the mobile node is located. This can expose the
mobile node's user to threats on their location privacy. A more
detailed discussion of location privacy for Mobile IPv6 can be
found in [12].
3) 位置のプライバシー。 モバイルノードが移行するとき、一時的なローカルアドレスにおける変化は潜在的に通信員へのモバイルノードの位相的な位置を立ち聞きする者に暴露します。 モバイルノードのアクセスネットワークと地理的な位置でサブネット接頭語の間のマッピングを組み立てることができる攻撃者は、モバイルノードがちょうどどこに位置しているかを決心できます。 これはそれらの位置のプライバシーでモバイルノードのユーザを脅威にさらすことができます。 [12]でモバイルIPv6のための位置のプライバシーの、より詳細な議論を見つけることができます。
Kempf Informational [Page 6] RFC 4830 NETLMM Problem Statement April 2007
[6ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
These problems suggest that a protocol to localize the management of topologically small movements is preferable to using a global mobility management protocol on each movement to a new link. In addition to these problems, localized mobility management can provide a measure of local control, so mobility management can be tuned for specialized local conditions. Note also that if localized mobility management is provided, it is not strictly required for a mobile node to support a global mobility management protocol since movement within a restricted IP access network can still be accommodated. Without such support, however, a mobile node experiences a disruption in its traffic when it moves beyond the border of the localized mobility management domain.
これらの問題は管理をローカライズするそのaプロトコルを示します。小さい運動は新しいリンクへの各動きのときにグローバルな移動性管理プロトコルを使用するより位相的に、望ましいです。 これらの問題に加えてローカライズしている移動性経営者側が現場制御の手段を提供できるので、専門化している現地の状況のために移動性管理を調整できます。 また、ローカライズしている移動性管理を提供するなら、モバイルノードが、まだ制限されたIPアクセスネットワークの中の動きを設備することができるのでグローバルな移動性が管理プロトコルであることを支えるように厳密にそれを必要としないことに注意してください。 しかしながら、そのようなサポートがなければ、ローカライズしている移動性管理ドメインの境界を超えて移行すると、モバイルノードはトラフィックにおける分裂になります。
3. Scenarios for Localized Mobility Management
3. ローカライズしている移動性管理のためのシナリオ
There are a variety of scenarios in which localized mobility management is useful.
ローカライズしている移動性管理が役に立つさまざまなシナリオがあります。
3.1. Large Campus
3.1. 大きいキャンパス
One scenario where localized mobility management would be attractive is a campus WLAN deployment, in which the geographical span of the campus, distribution of buildings, availability of wiring in buildings, etc. preclude deploying all WLAN access points as part of the same IP subnet. WLAN Layer 2 mobility could not be used across the entire campus.
ローカライズしている移動性管理が魅力的である1つのシナリオはキャンパスWLAN展開です。(そこでは、キャンパスの地理的な長さ、ビルの分配、ビルの配線の有用性などが同じIPサブネットの一部としてすべてのWLANアクセスポイントを配布するのを排除します)。 全体のキャンパスの向こう側にWLAN Layer2の移動性を使用できませんでした。
In this case, the campus is divided into separate last-hop links, each served by one or more access routers. This kind of deployment is served today by WLAN switches that coordinate IP mobility between them, effectively providing localized mobility management at the link layer. Since the protocols are proprietary and not interoperable, any deployments that require IP mobility necessarily require switches from the same vendor.
この場合、キャンパスが別々の最後のホップリンクに分割されるか、それぞれが1時までに役立ったか、または以上はルータにアクセスします。 この種類の展開は今日それらの間のIPの移動性を調整するWLANスイッチによって役立たれています、事実上、リンクレイヤでローカライズしている移動性管理を提供して。 プロトコルが独占であって、共同利用できないので、IPの移動性を必要とするどんな展開も必ず同じベンダーからスイッチを必要とします。
3.2. Advanced Cellular Network
3.2. 高度なセルラー・ネットワーク
Next-generation cellular protocols, such as 802.16e [7] and Super 3G/3.9G [2], have the potential to run IP deeper into the access network than the current 3G cellular protocols, similar to today's WLAN networks. This means that the access network can become a routed IP network. Interoperable localized mobility management can unify local mobility across a diverse set of wireless protocols all served by IP, including advanced cellular, WLAN, and personal area wireless technologies such as UltraWide Band (UWB) [5] and Bluetooth [3]. Localized mobility management at the IP layer does not replace Layer 2 mobility (where available) but rather complements it. A standardized, interoperable localized mobility management protocol
802.16e[7]やSuper 3G/3.9G[2]などの次世代のセルプロトコルには、IPを現在の3Gセルプロトコルよりアクセスネットワークに深く経営している可能性があります、今日のWLANネットワークと同様です。 これは、アクセスネットワークが発送されたIPネットワークになることができることを意味します。 共同利用できるローカライズしている移動性経営者側はIPによってすべて役立たれたさまざまのセットのワイヤレスのプロトコルの向こう側に地方の移動性を統一できます、UltraWide Band(UWB)[5]やブルートゥース[3]などの高度なセル的、そして、WLAN的、そして、個人的な領域無線技術を含んでいて。 IP層でのローカライズしている移動性管理は、Layer2の移動性(入手できるところ)を取り替えませんが、むしろそれの補足となります。 標準化されて、共同利用できるローカライズしている移動性管理プロトコル
Kempf Informational [Page 7] RFC 4830 NETLMM Problem Statement April 2007
[7ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
for IP can remove the dependence on IP-layer localized mobility protocols that are specialized to specific link technologies or proprietary, which is the situation with today's 3G protocols. The expected benefit is a reduction in maintenance cost and deployment complexity. See [11] for a more detailed discussion of the goals for a network-based localized mobility management protocol.
IPが特定のリンク技術に専門にされた、独占である移動性プロトコルであるとローカライズされた今日の3Gプロトコルがある状況であるIP-層への依存を取り除くことができるので。 期待される利益は維持費と展開の複雑さの減少です。 ネットワークベースのローカライズしている移動性管理プロトコルの目標の、より詳細な議論のための[11]を見てください。
3.3. Picocellular Network with Small But Node-Dense Last-Hop Links
3.3. 小さい、しかし、ノード濃い最後のホップリンクがあるPicocellularネットワーク
Future radio link protocols at very high frequencies may be constrained to very short, line-of-sight operation. Even some existing protocols, such as UWB [5] and Bluetooth [3], are designed for low transmit power, short-range operation. For such protocols, extremely small picocells become more practical. Although picocells do not necessarily imply "pico subnets", wireless sensors and other advanced applications may end up making such picocellular type networks node-dense, requiring subnets that cover small geographical areas, such as a single room. The ability to aggregate many subnets under a localized mobility management scheme can help reduce the amount of IP signaling required on link movement.
超短波における将来のラジオリンク・プロトコルは非常に短い照準線操作に抑制されるかもしれません。 プロトコルがUWB[5]やブルートゥース[3]のように低く設計されているいくつかの存在がパワー、短距離操作を伝えさえします。 そのようなプロトコルのために、非常に小さいpicocellsは、より実用的になります。 picocellsは必ず「ピコサブネット」を含意するというわけではありませんが、ワイヤレスのセンサと他の高度なアプリケーションでそのようなpicocellularタイプネットワークは結局ノード濃くなるかもしれません、小さい地理的な領域をカバーするサブネットを必要として、シングルの部屋のように。 ローカライズしている移動性管理体系の下で多くのサブネットに集める能力は、リンク運動のときに必要であったIPシグナリングの量を減少させるのを助けることができます。
4. Problems with Existing Solutions
4. 既存のソリューションに関する問題
Existing solutions for localized mobility management fall into two classes:
ローカライズしている移動性管理のための既存のソリューションは2つのクラスになります:
1) Interoperable IP-level protocols that require changes to the
mobile node's IP stack and handle localized mobility management as
a service provided to the mobile node by the access network.
1) サービスがアクセスネットワークによるモバイルノードに提供されたとき、モバイルノードのIPスタックとハンドルへの変化を必要とする共同利用できるIP-レベルプロトコルは、移動性が管理であるとローカライズしました。
2) Link specific or proprietary protocols that handle localized
mobility for any mobile node but only for a specific type of link
layer, for example, 802.11 [6].
2) どんなモバイルノードのためにもローカライズしている移動性を扱う特定であるか固有のプロトコルをリンクしなさい、ただし、特定のタイプのリンクだけに関して、例えば、802.11[6]を層にしてください。
The dedicated localized mobility management IETF protocols for Solution 1 are not yet widely deployed, but work continues on standardization. Some Mobile IPv4 deployments use localized mobility management. For Solution 1, the following are specific problems:
ソリューション1のためのひたむきなローカライズしている移動性管理IETFプロトコルはまだ広く配布されていませんが、仕事は標準化のときに続きます。 何らかのモバイルIPv4展開使用が、移動性が管理であるとローカライズしました。 ソリューション1のために、↓これは特定の問題です:
1) The host stack software requirement limits broad usage even if the
modifications are small. The success of WLAN switches indicates
that network operators and users prefer no host stack software
modifications. This preference is independent of the lack of
widespread Mobile IPv4 deployment, since it is much easier to
deploy and use the network.
1) 変更が小さくても、ホストスタックソフトウェア要件は広い用法を制限します。 WLANスイッチの成功は、ネットワーク・オペレータとユーザがホストスタックソフトウェア変更を全く好まないのを示します。 この好みは広範囲のモバイルIPv4展開の不足から独立しています、ネットワークを配布して、使用するのがはるかに簡単であるので。
Kempf Informational [Page 8] RFC 4830 NETLMM Problem Statement April 2007
[8ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
2) Future mobile nodes may choose other global mobility management
protocols, such as HIP or MOBIKE. The existing localized mobility
management solutions all depend on Mobile IP or derivatives.
2) 将来のモバイルノードはHIPかMOBIKEなどの他のグローバルな移動性管理プロトコルを選ぶかもしれません。 既存のローカライズしている移動性運営方法はモバイルIPか派生物にすべて頼っています。
3) Existing localized mobility management solutions do not support
both IPv4 and IPv6.
3) 存在は運営方法がサポートしない移動性にIPv4とIPv6の両方をローカライズしました。
4) Existing host-based localized mobility management solutions
require setting up additional security associations with network
elements in the access domain.
4) 既存のホストベースのローカライズしている移動性運営方法は、アクセスドメインにネットワーク要素との追加担保協会を設立するのを必要とします。
Market acceptance of WLAN switches has been very large, so Solution 2 is widely deployed and continuing to grow. Solution 2 has the following problems:
WLANスイッチの市場承認が非常に大きいので、ソリューション2は、広く配布されて、成長し続けています。 ソリューション2には、以下の問題があります:
1) Existing solutions only support WLAN networks with Ethernet
backhaul and therefore are not available for advanced cellular
networks or picocellular protocols, or other types of wired
backhaul.
1) 既存のソリューションだけが、イーサネット逆送でWLANにネットワークをサポートして、したがって、高度なセルラー・ネットワーク、picocellularプロトコル、または他のタイプのワイヤードな逆送に利用可能ではありません。
2) Each WLAN switch vendor has its own proprietary protocol that does
not interoperate with other vendors' equipment.
2) それぞれのWLANスイッチベンダーには、他のベンダーの設備で共同利用しないそれ自身の固有のプロトコルがあります。
3) Because the solutions are based on Layer 2 routing, they may not
scale up to a metropolitan area or local province, particularly
when multiple kinds of link technologies are used in the backbone.
3) ソリューションがLayer2ルーティングに基づいているので、都市エリアか地方の州まで比例しないかもしれません、特に複数の種類のリンク技術がバックボーンに使用されるとき。
5. Advantages of Network-based Localized Mobility Management
5. ネットワークを拠点とするローカライズしている移動性管理の利点
Having an interoperable, standardized localized mobility management protocol that is scalable to topologically large networks, but requires no host stack involvement for localized mobility management is a highly desirable solution. The advantages that this solution has over Solutions 1 and 2 above are as follows:
共同利用できて、標準化される、それが位相的にスケーラブルである移動性管理プロトコルに大きいネットワークをローカライズしますが、ローカライズしている移動性管理が非常に望ましいソリューションであるのでホストスタックかかわり合いを全く必要としません。 このソリューションが上のソリューション1と2の上に持っている利点は以下の通りです:
1) Compared with Solution 1, a network-based solution requires no
localized mobility management support on the mobile node and is
independent of global mobility management protocol, so it can be
used with any or none of the existing global mobility management
protocols. The result is a more modular mobility management
architecture that better accommodates changing technology and
market requirements.
1) ネットワークベースのソリューションがソリューション1と比べてモバイルノードの上でローカライズしている移動性管理サポートを全く必要としないで、グローバルな移動性管理プロトコルから独立しているので、既存のグローバルな移動性管理プロトコルのいずれかいずれと共にもそれを使用できません。 結果は技術を変えて、市場の必要性を収容するほうがよいよりモジュールの移動性管理体系です。
2) Compared with Solution 2, an IP-level network-based localized
mobility management solution works for link protocols other than
Ethernet, and for wide area networks.
2) ソリューション2と比べて、IP-レベルのネットワークベースのローカライズしている移動性運営方法はイーサネット以外のリンク・プロトコル、および広域ネットワークのために働いています。
Kempf Informational [Page 9] RFC 4830 NETLMM Problem Statement April 2007
[9ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
RFC 4831 [11] discusses a reference architecture for a network- based, localized mobility protocol and the goals of the protocol design.
RFC4831[11]はネットワークのベースの、そして、ローカライズしている移動性プロトコルとプロトコルデザインの目標と参照アーキテクチャについて議論します。
6. Security Considerations
6. セキュリティ問題
Localized mobility management has certain security considerations, one of which -- the need for security from access network to mobile node -- was discussed in this document. Host-based localized mobility management protocols have all the security problems involved with providing a service to a host. Network-based localized mobility management requires security among network elements that is equivalent to what is needed for routing information security, and security between the host and network that is equivalent to what is needed for network access, but no more. A more complete discussion of the security goals for network-based localized mobility management can be found in [11].
ローカライズしている移動性管理には、あるセキュリティ問題があります。本書ではその1つについて議論しました(アクセスネットワークからモバイルノードまでのセキュリティの必要性)。 ホストベースのローカライズしている移動性管理プロトコルで、すべての警備上の問題がホストに対するサービスを提供するのにかかわります。 ネットワークを拠点とするローカライズしている移動性経営者側はネットワーク要素の中のルーティング情報セキュリティに必要であるものに同等なセキュリティ、およびホストとネットワークの間のネットワークアクセスに必要な、そして、より多くないことに同等なセキュリティを必要とします。 [11]でネットワークを拠点とするローカライズしている移動性管理のセキュリティ目標の、より完全な議論を見つけることができます。
7. Informative References
7. 有益な参照
[1] 3GPP, "UTRAN Iu interface: General aspects and principles", 3GPP
TS 25.410, 2002,
http://www.3gpp.org/ftp/Specs/html-info/25410.htm.
[1] 3GPP、「UTRAN Iuは連結します」。 3GPP TS25.410の「一般局面と原則」、2002、 http://www.3gpp.org/ftp/Specs/html-info/25410.htm 。
[2] 3GPP, "3GPP System Architecture Evolution: Report on Technical
Options and Conclusions", TR 23.882, 2005,
http://www.3gpp.org/ftp/Specs/html-info/23882.htm.
[2] 3GPP、「3GPPシステム構築発展:」 「技術的なオプションと結論に関するレポート」、TR23.882、2005、 http://www.3gpp.org/ftp/Specs/html-info/23882.htm 。
[3] Bluetooth SIG, "Specification of the Bluetooth System",
November, 2004, available at http://www.bluetooth.com.
[3] ブルートゥースSIG、「ブルートゥースシステムの仕様」、 http://www.bluetooth.com に空いている2004年11月。
[4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
RFC 4555, June 2006.
[4]Eronen、2006年6月のP.、「IKEv2移動性とマルチホーミングプロトコル(MOBIKE)」RFC4555。
[5] IEEE 802.15 WPAN High Rate Alternative PHY Task Group 3a (TG3a),
http://www.ieee802.org/15/pub/TG3a.html.
[5] IEEE802.15WPAN高い率代替手段PHYタスクは3aを分類します。(TG3a)、 http://www.ieee802.org/15/pub/TG3a.html 。
[6] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[6]IEEE、「無線LAN Medium Access Control(MAC)とPhysical Layer(PHY)仕様」、IEEE Std。 802.11, 1999.
[7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan
Area Networks - Part 16: Air Interface for Fixed Broadband
Wireless Access Systems - Physical and Medium Access Control
Layers for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE Std. 802.16e-2005, 2005.
[7] IEEE、「地方とメトロポリタンエリアネットワークのIEEE規格の修正--16を分けてください」 「固定広帯域のワイヤレス・アクセスシステムのための空気インタフェース--物理的で中型のアクセスコントロールは結合した修理されてモバイルの操作のために認可されたバンドで層にされます」、IEEE Std。 802.16e-2005、2005。
Kempf Informational [Page 10] RFC 4830 NETLMM Problem Statement April 2007
[10ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
[8] IEEE, "Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications", IEEE
Std. 802.3-2005, 2005.
[8]IEEE、「衝突検出(CSMA/CD)アクセス法と物理的な層の仕様がある搬送波感知多重アクセス」、IEEE Std。 802.3-2005, 2005.
[9] ITU-T, "Architecture of Transport Networks Based on the
Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, 2000.
[9] ITU-T、「輸送の構造は同期デジタルハイアラーキに基づいて(SDH)をネットワークでつなぐ」ITU-T G.803、2000年3月。
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[10] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[11] Kempf, J., Ed., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[11] ケンフ、J.、エド、「ネットワークを拠点とする局所化された移動性管理(NETLMM)の目標」、RFC4831、4月2007日
[12] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", Work in Progress, February 2007.
[12]Koodli、R.、「IPは位置のプライバシーとモバイルIPv6を記述します」。 「問題声明」、処理中の作業、2007年2月。
[13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
2005.
[13] Koodli(R.)は「速く、モバイルIPv6"、RFCのために、4068、2005年7月を引き渡します」。
[14] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[14] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[15] Metro Ethernet Forum, " Metro Ethernet Network Architecture
Framework - Part 1: Generic Framework", MEF 4, May, 2004.
[15] 地下鉄イーサネットフォーラム、「地下鉄イーサネットネットワークアーキテクチャ枠組み--、第1部:、」 「一般的な枠組み」、MEF4、2004年5月。
[16] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[16] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)の構造」、RFC4423)は2006がそうするかもしれません。
[17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[17] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[18] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
[18] ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。
8. Acknowledgements
8. 承認
The authors would like to acknowledge the following for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.
作者は特に勤勉な論評のために以下を承認したがっています: ビジェイDevarapalli、ピーター・マッキャン、ガブリエル・モンテネグロ、Vidyaナラヤナン、ペッカSavola、およびフレッド・テンプリン。
Kempf Informational [Page 11] RFC 4830 NETLMM Problem Statement April 2007
[11ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
9. Contributors
9. 貢献者
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com
レオンシスコシステムズInc.170の西タスマン・Driveケントカリフォルニア95134サンノゼ(米国)はメールされます: kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
フィルロバーツモトローラ研究室Schaumberg、不-米国はメールされます: phil.roberts@motorola.com
Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 EMail: nishidak@nttdocomo.co.jp
勝利西田NTTドコモ株式会社3-5Hikarino-oka、横須賀市神奈川(日本)は以下に電話をします。 +81 46 840 3545はメールされます: nishidak@nttdocomo.co.jp
Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 EMail: gerardo.giaretta@tilab.com
G.ライス・ロモリを通したヘラルドGiarettaテレコムイタリアLab、274 10148トリノイタリア電話: +39 011 2286904 メール: gerardo.giaretta@tilab.com
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 EMail: marco.liebsch@ccrle.nec.de
マルコLiebsch NECネットワーク研究所Kurfuersten-原基36 69115ハイデルベルグドイツ電話: +49 6221-90511-46 メールしてください: marco.liebsch@ccrle.nec.de
Editor's Address
エディタのアドレス
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
ジェームスケンフDoCoMo米国研究室181地下鉄ドライブ、Suite300サンノゼ、カリフォルニア95110米国は以下に電話をします。 +1 4711年の408 451メール: kempf@docomolabs-usa.com
Kempf Informational [Page 12] RFC 4830 NETLMM Problem Statement April 2007
[12ページ]RFC4830NETLMM問題声明2007年4月の情報のケンフ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kempf Informational [Page 13]
ケンフInformationalです。[13ページ]
一覧
スポンサーリンク
