Network Working Group H. Chaskar, Ed.
Request for Comments: 3583 Nokia Research Center
Category: Informational September 2003
Requirements of a Quality of Service (QoS) Solution for Mobile IP
モバイルIPのためのサービス品質（QoS：Quality of Service）ソリューションの要件
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 Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP.
モバイルノードは、インターネットへの接続点を変更するようにモバイルIPは、モバイルノードへのパケットの正しいルーティングを確実にします。しかし、またのQoSに敏感なIPサービスは、モバイルIPを介してサポートすることができるように、ネットワーク内の中間ノードに移動ノードのパケットストリームへのサービス（QoS）の転送処理の適切な品質を提供するために必要とされます。この文書では、モバイルIPとの満足な動作のためのIP QoSメカニズムのための要件について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement. . . . . . . . . . . . . . . . . . . . 2
1.2. An approach for solving QoS problem in Mobile IP . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements of a QoS solution for Mobile IP . . . . . . . . . 3
3.1. Performance requirements . . . . . . . . . . . . . . . . 4
3.2. Interoperability requirements. . . . . . . . . . . . . . 5
3.3. Miscellaneous requirements . . . . . . . . . . . . . . . 6
3.4. Standard requirements. . . . . . . . . . . . . . . . . . 7
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
Mobile IP is a technology that allows a "mobile node" (MN) to change its point of attachment to the Internet while communicating with the "correspondent node" (CN) using IP. The formal description of Mobile IP can be found in [1, 6]. Mobile IP primarily addresses the correct routing of packets to MN's current point of attachment with the Internet.
モバイルIPは、IPを使用して、「相手ノード」（CN）との通信中に「移動ノード」（MN）がインターネットへの接続点を変更することを可能にする技術です。モバイルIPの正式な記述は[1,6]に見出すことができます。モバイルIPは、主にインターネットで添付ファイルのMNの現在のポイントにパケットを正しくルーティングに対応しています。
It is also essential to provide proper Quality of Service (QoS) forwarding treatment to the packets sent by or destined to MN as they propagate along different routes in the network due to node mobility. This document will identify the requirements that Mobile IP places on an IP QoS mechanism.
彼らが、ノードの移動に伴うネットワーク内の異なるルートに沿って伝播するよう送信またはMN宛てのパケットに適切なサービス品質（QoS）の転送処理を提供することも不可欠です。この文書では、モバイルIPはIP QoSメカニズムに置く要件を特定します。
When an MN using Mobile IP undergoes handover from one access router to another, the path traversed by MN's packet stream in the network may change. Such a change may be limited to a small segment of the end-to-end path near the extremity, or it could also have an end-to-end impact. Further, the packets belonging to MN's ongoing session may start using a new care-of address after handover. Hence, they may not be recognized by some forwarding functions in the nodes even along that segment of the end-to-end path that remains unaltered after handover. Finally, handover may occur between the subnets that are under different administrative control.
モバイルIPを使用してMNが別のアクセスルータからのハンドオーバを受ける場合は、ネットワーク内のMNのパケットストリームが通過するパスが変更されることがあります。そのような変化は、先端の近くのエンドツーエンドパスの小さなセグメントに限定されてもよく、またはそれは、エンド・ツー・エンドの影響を有することができます。さらに、MNの進行中のセッションに属するパケットは、ハンドオーバ後に新しい気付アドレスを使用して起動することがあります。したがって、それらは、ハンドオーバ後に不変のままであっても、エンドツーエンドのパスのそのセグメントに沿ったノードの一部の転送機能によって認識されない可能性があります。最後に、ハンドオーバが異なる管理制御下にあるサブネット間で起こり得ます。
In the light of this scenario, it is essential to establish proper QoS support for the MN's packet stream along the new packet path.
このシナリオの光では、新しいパケット・パスに沿ってMNのパケットストリームに対する適切なQoSサポートを確立することが不可欠です。
There are four important steps involved in solving the QoS problem for Mobile IP. They are as follows: (1) List the requirements that Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS solutions against these requirements, (3) Decide if current solutions need to be extended, or if new ones need to be defined, and (4) Depending on the result of step 3, define new solutions or fix the old ones.
モバイルIPのためのQoSの問題を解決するに関与4つの重要なステップがあります。それらは次の通りです：新しいものがする必要がある場合は、現在のソリューションを拡張する必要がある場合、または（1）（3）決定し、（2）これらの要求に対して、現在のIPのQoSソリューションを評価し、QoSメカニズム上のモバイルIPの場所の要件を一覧表示します定義されたこと、及び（4）ステップ3の結果に応じて、新しいソリューションを定義したり、古いものを修正。
Of these, the first step, i.e., the requirements step, is addressed in this document. The last three steps are not dealt with here in detail. However, so as to create useful insight into the Mobile IP QoS problem, at times this document highlights the shortcomings of some well known current proposals for establishing QoS support for the packet stream in the network, when directly used with Mobile IP.
これらのうち、最初のステップは、すなわち、要求ステップは、本書で取り上げています。最後の3つの手順は、ここで詳細に取り扱われていません。しかし、時にはこの文書は直接モバイルIPを使用したネットワークにおけるパケットストリームのためのQoSサポートを確立するためのいくつかのよく知られた現在の提案の欠点を強調し、モバイルIPのQoS問題に有益な洞察を作成するように。
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 BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
This section describes the requirements for a QoS solution for its satisfactory operation with Mobile IP. Conversely, note that only Mobile IP-specific requirements are described here. We do not assume any particular version (4 or 6) of IP while describing the requirements. Solutions can be designed for IPv4 and IPv6 independently, or a single solution can be designed to work with both versions.
このセクションでは、モバイルIPとの満足な動作のためのQoSソリューションのための要件について説明します。逆に、唯一のモバイルIP固有の要件は、ここで説明されていることに注意してください。要件を記述しながら、我々はIPの任意の特定のバージョン（4又は6）を想定していません。ソリューションは、独立して、IPv4とIPv6のために設計することができ、または単一の溶液は、両方のバージョンで動作するように設計することができます。
In this document, we assume that the target access router for MN's handover is already pinned down by other protocols. For example, Seamoby working group has started work on the candidate access router discovery protocols [7]. Thus, any QoS-capability specific negotiations that may affect the handover decision are outside the scope of QoS solution as such, rather need to be performed by candidate and target access router selection protocols.
この文書では、我々は、MNのハンドオーバのためのターゲット・アクセス・ルータは、すでに他のプロトコルで釘付けにされていることを前提としています。例えば、Seamobyワーキンググループは、候補アクセスルータ発見プロトコル上で作業を開始した[7]。したがって、ハンドオーバの決定に影響を与える可能性がある任意のQoS能力特定交渉はなく、候補ターゲットアクセスルータ選択プロトコルによって実行される必要がある、などのQoSソリューションの範囲外です。
1. Minimize the interruption in QoS at the time of handover:
1.ハンドオーバ時のQoSの中断を最小限に抑えます。
At the time of handover, interruption in QoS would occur if the packets sent by or destined to the MN arrive at the intermediate node in the new packet path without that node having information about their QoS forwarding requirement. Then, those packets will receive default forwarding treatment. Such QoS interruption MUST be minimized. A good metric for this performance is the number of packets that may potentially get served with the "default" QoS at the time of handover. The number of such packets MUST be minimized.
送信またはMN宛のパケットは、そのノードが要求を転送し、それらのQoSに関する情報を有することなく、新たなパケット経路内の中間ノードに到着する場合、ハンドオーバ時に、QoSの中断が発生します。次に、これらのパケットは、デフォルトの転送処理を受け取ります。このようなQoSの中断を最小限に抑えなければなりません。このパフォーマンスのための良い指標は、潜在的ハンドオーバ時に「デフォルト」のQoSを添えれるかもしれませんパケットの数です。そのようなパケットの数が最小化されなければなりません。
As an example, this performance metric is computed in [8] for the case of end-to-end RSVP signaling [3] with Mobile IPv6. It is shown there that when the end-to-end path of packets changes at large after handover or when the care-of address changes after handover, OPWA (One Pass With Advertisement) model of reservation used by RSVP causes the latency of about one round-trip time between the MN and the CN before QoS can be established along the new packet path. In other words, the packets using the new care-of address that would be released by the MN or the CN during one round-trip time, after these nodes are ready to use the new care-of address, may get default forwarding treatment at the intermediate nodes. Such a latency in QoS programming may be acceptable at the time of session initiation, but it is not acceptable in the middle of an active session as would be the case with handover.
一例として、このパフォーマンスメトリックは、で計算される[8] [3]モバイルIPv6とシグナリングエンドツーエンドRSVPの場合について。ときに、ハンドオーバ後に大でパケット変化のエンドツーエンドパスまたは場合気付アドレスを変更ハンドオーバ後、RSVPによって使用される予約のOPWA（広告付きワンパス）モデル約1のレイテンシを引き起こすことが示されています。 QoSの前MNとCN間の往復時間は、新たなパケットの経路に沿って確立することができます。言い換えれば、これらのノードは、新しい気付アドレスを使用する準備が整いました後に、新しい気付アドレス1往復時間の間、MNまたはCNによって解放されるだろう使用してパケットは、時にデフォルトの転送処理を得ることができます中間ノード。 QoSのプログラミングのような待ち時間は、セッション開始時に許容されるかもしれないが、それは、ハンドオーバの場合のように、アクティブセッションの途中で許容できません。
2. Localize the QoS (re)establishment to the affected parts of the packet path in the network:
2.ネットワーク内のパケットパスの影響を受けた部分にQoS（再）確立をローカライズ。
In many cases, handover changes only a small segment of the end-to-end path of MN's packet stream near the extremity. Then, the QoS mechanism MUST limit the extent of QoS (re)establishment to the affected segment of the end-to-end path only.
多くの場合、ハンドオーバは、四肢の近くにMNのパケットストリームのエンドツーエンドのパスの唯一の小さなセグメントを変更します。次に、QoSメカニズムは、エンドツーエンドパスの影響を受けたセグメントへのQoS（再）確立の範囲を制限しなければなりません。
However, note that handover may sometimes cause the end-to-end path of MN's packet stream in the network to change at large. This may happen, for example, in the case of handover between different administrative domains. If the QoS mechanism used to establish QoS support for the MN's packet stream along the new packet path in the network is based on the explicit end-to-end provisioning as such, it MUST perform so at the time of such handover.
しかし、そのハンドオーバが時々大に変更するネットワークにおけるMNのパケットストリームのエンドツーエンドのパスを引き起こす可能性があり注意してください。これは、例えば、異なる管理ドメイン間のハンドオーバの場合に、起こり得ます。ネットワーク上の新しいパケットの経路に沿ってMNのパケットストリームのためのQoSサポートを確立するために使用されるQoSメカニズムは、のような明示的なエンド・ツー・エンドのプロビジョニングに基づいている場合、それは、このようなハンドオーバーの際にとても実行しなければなりません。
When the care-of address changes upon handover, it may be required to perform some signaling even over the unchanged part of the end-to-end path if the path contains any QoS mechanisms that use IP address as a key to forwarding functions. Examples are FILTER SPECs in the IntServ nodes or packet classifiers at the edges of DiffServ networks. However, double provisioning of resources over the unchanged part of the packet path MUST be avoided.
場合気付アドレス変更ハンドオーバ時には、パスが転送機能へのキーとしてIPアドレスを使用するすべてのQoSメカニズムが含まれている場合であっても、エンドツーエンド経路の不変部分の上にいくつかのシグナリングを実行するために必要とされ得ます。例としては、DiffServのネットワークのエッジでのIntServノードまたはパケット分類のフィルタ仕様です。しかし、パケットパスの変わらない部分を超えるリソースの二重のプロビジョニングは避けなければなりません。
Note that the QoS signaling protocol such as RSVP [9] can localize the QoS signaling to the affected parts of the end-to-end path if the care-of address does not change upon handover. However, if the care-of address changes upon handover, RSVP as currently defined [4] fails to localize the QoS signaling. In addition, it will cause double reservations on the part of end-to-end path that remains unchanged after handover.
例えばRSVPのようなシグナリングプロトコルのQoS [9]気付アドレスは、ハンドオーバ時に変化しない場合、エンドツーエンドパスの影響を受けた部分にQoSシグナリングを局在化することができることに留意されたいです。気付のハンドオーバ時のアドレス変更は、RSVPは、現在定義されている場合しかし、[4]のQoSシグナリングをローカライズすることができません。また、ハンドオーバー後に変更されないまま、エンドツーエンドのパスの一部に二重の予約が発生します。
3. Releasing after handover the QoS state (if any) along the old packet path:
3.ハンドオーバ古いパケットパスに沿ってのQoS状態（もしあれば）の後に解放します：
The QoS mechanism MUST provide some means (explicit or timer-based) to release any QoS state along the old packet path that is not required after handover. It is desirable that the unwarranted QoS states, if any, along the old path are released as quickly as possible at the time of handover. Note that, during handover, the MN may not always get a chance to send explicit tear down message along the old path because of the loss of link layer connectivity with the old access router.
QoSメカニズムは、いくつかの手段を提供しなければならない（明示的またはタイマーベース）ハンドオーバ後に必要とされていない古いパケットの経路に沿って任意のQoSの状態を解除します。古いパスに沿って不当なQoS状態は、もしあれば、ハンドオーバ時に、可能な限り迅速に放出されることが望ましいです。ハンドオーバー中、MNは常にあるため、旧アクセスルータとのリンクレイヤの接続性の損失の古いパスに沿ってメッセージを明示的に涙をダウン送信する機会がないかもしれない、ということに注意してください。
1. Interoperability with mobility protocols:
モビリティプロトコル1.相互運用性：
A number of mobility protocols that are complementary to Mobile IP are already defined or may be defined in future in IETF, particularly in Mobile IP and Seamoby working groups. Examples are fast handover [10, 11], localized mobility management [12, 13], context transfer [5] etc. The QoS mechanism for Mobile IP SHOULD take advantage of these mobility protocols for the optimized operation. However, the QoS scheme MUST have provisions to accomplish its tasks even if one or more of these mobility protocols are not used.
モバイルIPに相補的なモビリティプロトコルの数は、既に定義されているか、特にモバイルIPとSeamobyワーキンググループでは、IETFで将来的に定義されてもよいです。例としては、高速ハンドオーバ[10、11]、ローカライズされたモビリティ管理[12、13]、[5]などの最適化された動作のために、これらのモビリティプロトコルを利用すべきであるモバイルIPのためのQoSメカニズムコンテキスト転送です。しかし、QoSの方式は、これらのモビリティプロトコルの1つ以上が使用されていない場合でも、そのタスクを達成するための規定を持っていなければなりません。
2. Interoperability with heterogeneous packet paths as regards QoS paradigms:
以下のような異種のパケットパスを持つ2.相互運用性は、QoSパラダイムについて：
The new path after handover, of the MN's packet stream, may traverse network domains employing different QoS paradigms compared to those along the old path. The QoS mechanism for
ハンドオーバ後の新しいパスは、MNのパケットストリームの、古いパスに沿ったものに比べて異なるQoSパラダイムを採用したネットワークドメインを横断してもよいです。以下のためのQoSメカニズム
Mobile IP SHOULD be able to establish proper QoS forwarding treatment for the MN's packet stream along the packet paths deploying different QoS paradigms (best current practices), in a manner consistent with the QoS mechanism deployed along those paths.
モバイルIPは、これらのパスに沿って展開されたQoSメカニズムと一致する方法で、異なるQoSパラダイム（現在のベストプラクティス）を展開パケット・パスに沿ってMNのパケットストリームのための治療を転送し、適切なQoSを確立することができるべきです。
As an illustration, suppose that the MN is currently attached to an access router which is the edge router of a DiffServ network, and that the packet classifier and traffic policer for the MN's flows are presently programmed in this access router. Now, suppose that the MN needs to be handed over to the access router which is at the edge of an IntServ network. The new access network would expect the exchange of RSVP messages so that proper QoS forwarding treatment can be established for the MN's packet stream in that access network. QoS mechanism for Mobile IP SHOULD have provisions to handle such heterogeneity as regards the QoS mechanisms deployed along different packet paths.
実例として、MNが現在のDiffServネットワークのエッジルータであるアクセスルータに接続されていることを想定し、MNのフローのパケット分類とトラフィックポリサーは、現在、このアクセスルータでプログラムされていること。さて、MNはイントサーブネットワークのエッジにあるアクセスルータに引き渡される必要があるとします。治療を転送して、適切なQoSがそのアクセスネットワークにおけるMNのパケットストリームのために確立することができるように、新しいアクセス・ネットワークは、RSVPメッセージの交換を期待します。異なるパケット経路に沿って展開QoSメカニズムに関してモバイルIPのためのQoSメカニズムは、そのような不均一性を処理するための規定を持っているべきです。
1. QoS support along multiple packet paths:
1. QoSは、複数のパケットの経路に沿ってサポートしています。
After MN undergoes handover from one access router to another, potentially, there could be multiple paths over which MN's packet may propagate. Examples of these path are: route-optimized path between the MN and its CN, triangle route via Home Agent (HA), temporary tunnel between old and new access routers, reverse tunnel from the new access router (Foreign Agent) to HA etc. A QoS mechanism SHOULD be able to support QoS along the different potential packet paths. However, whether all paths are supported or only a subset of them is supported will be determined by external mechanisms such as mobility management, policy, location privacy requirement and so on. Further, the same QoS mechanism may not be able to support all these paths.
MNは別のアクセスルータからのハンドオーバを受けた後、潜在的に、MNのパケットが伝播する可能性がその上に複数の経路があるかもしれません。これらのパスの例としては、MNとそのCN、ホームエージェント（HA）、古いものと新しいアクセスルータ間の一時的なトンネルを経由して、三角形のルート間のルート最適化パスなどHAへの新しいアクセスルータ（外部エージェント）からトンネルを逆転しますQoSメカニズムは異なる電位パケットパスに沿ってQoSをサポートすることができるべきです。しかし、すべてのパスがサポートされるか、またはそれらのサブセットのみがサポートされているかどうかように外部のようなモビリティ管理のようなメカニズム、ポリシー、位置プライバシー要件によって決定されるであろう。さらに、同じQoSメカニズムは、これらすべてのパスをサポートすることができないかもしれません。
2. Interactions with wireless link-layer support for QoS:
QoSのための無線リンク層をサポートする2.相互作用：
Since a vast number of devices using Mobile IP will be connected to the Internet via wireless links, the QoS mechanism for Mobile IP MAY provide some information to the wireless link layers for them to support the required QoS.
モバイルIPを使用してデバイスの膨大な数は、無線リンクを介してインターネットに接続されますので、彼らが必要なQoSをサポートするために、モバイルIPのためのQoSメカニズムは、無線リンクレイヤにいくつかの情報を提供することができます。
An example scenario that may benefit from such information is that of the two UDP streams associated with the same media, but requiring different levels of error protection at the wireless link layer due to certain characteristics of their respective encoding schemes. The packets of these two streams are equally delay sensitive (so as to maintain playout synchronization at the receiver), and hence, may be treated equally (as regards queuing) by IP layer. But they may need to be transmitted on wireless channels of different error characteristics (say different FEC coding or power levels).
そのような情報から利益を得ることができる例示的なシナリオでは、同じメディアに関連付けられた2つのUDPストリームのことであるが、それぞれの符号化方式の特定の特性による無線リンク層での誤り保護の異なるレベルを必要とします。これら二つのストリームのパケットが等しく（受信機での再生の同期を維持するように）遅延に敏感であるので、（キューイングに関して）、IP層で均等に処理してもよいです。しかし、彼らは異なる誤差特性（異なるFEC符号化やパワーレベルを言う）の無線チャネルで送信する必要があるかもしれません。
The QoS information included for the benefit of wireless link layers SHOULD be such that it is meaningful both ways: to applications that reside over IP so that they can choose the IP service of certain QoS characteristics and to wireless link QoS managers so that they can then map this information to the details of lower layer mechanisms and their parameters.
無線リンク層の利点は、両方の方法意味があるようなものでなければならないため、QoS情報が含まれる：それらは特定のQoS特性のIPサービスを選択できるように、IP上に常駐するアプリケーションへの無線リンクのQoSマネージャに彼らができるように、次いで下層メカニズムとそのパラメータの詳細にこの情報をマッピングします。
In the example scenario described above, such a QoS information could be expressed as the acceptable loss rate of IP packets in the UDP stream. This parameter enables the UDP application to choose the IP service having QoS that matches its requirements, and it also enables the wireless link QoS managers to choose the right wireless channel to transmit the packets of this UDP stream.
上記の例のシナリオでは、このようなQoS情報がUDPストリーム内のIPパケットの許容される損失率として表現することができます。このパラメータは、その要件に合致するIPサービス持つQoSを選択するUDPアプリケーションを可能にし、そしてそれはまた、このUDPストリームのパケットを送信するために右の無線チャネルを選択するために無線リンクのQoS管理を可能にします。
The QoS solution for Mobile IP SHOULD satisfy standard requirements such as scalability, security, conservation of wireless bandwidth, low processing overhead on mobile terminals, providing hooks for authorization and accounting, and robustness against failures of any Mobile IP-specific QoS components in the network. While it is not possible to set quantitative targets for these desirable properties, the QoS solution MUST be evaluated against these criteria.
モバイルIPのためのQoSソリューションは、拡張性、セキュリティ、無線帯域幅の節約、携帯端末上の低い処理オーバーヘッド、許可およびアカウンティングのためのフックを提供し、ネットワーク内の任意のモバイルIP固有のQoSコンポーネントの障害に対するロバスト性のような標準的な要件を満たさなければなりません。それはこれらの望ましい特性のための定量的な目標を設定することはできませんが、QoSソリューションは、これらの基準に照らして評価されなければなりません。
The QoS (re)establishment triggered by node mobility MUST be guarded against security attacks. Such attacks could be launched by malicious nodes that spoof the QoS signaling to make it appear to the intermediate nodes that the MN has undergone handover. Such an attack could disrupt the QoS offered to MN's ongoing sessions as the intermediate nodes may then tear down the QoS along some segments of the true packet paths between MN and CN. The malicious nodes may also request a reduced level of QoS or supply fake packet classifiers, thereby affecting QoS over some segments (e.g., that do not get affected by the spoofed handover) of the true packet paths between MN and CN. Further, network resources may be wasted or used in an unauthorized manner by the malicious nodes that spoof MN's handover. To prevent this, QoS mechanism MUST provide means for intermediate nodes to verify the authenticity of handover-induced QoS (re)establishment.
ノードの移動によってトリガたQoS（再）確立は、セキュリティ攻撃に対して守らなければなりません。このような攻撃は、それはMNがハンドオーバを受けた中間ノードに見えるようにするためにQoSシグナリングを偽造悪意のあるノードによって起動することができます。中間ノードは、次に、MNとCNとの間の真のパケットパスの一部のセグメントに沿ってQoSを取り壊すことができるように、このような攻撃は、MNの現在進行中のセッションに提供されるQoSを混乱させる可能性があります。悪意のあるノードはまた、それによって、MNとCNとの間の真のパケットパスの（スプーフィングされたハンドオーバによって影響を受けません。例えば、）いくつかのセグメント上のQoSに影響を与えると、QoSの低下したレベルを要求するか、偽のパケット分類を供給することができます。さらに、ネットワークリソースが浪費又はMNのハンドオーバをスプーフィング悪意のあるノードによって不正に使用されてもよいです。これを防止するために、QoSメカニズムは、中間ノードがハンドオーバ誘発性のQoS（再）確立の真正性を検証するための手段を提供しなければなりません。
In this document, we described the requirements for a QoS solution for its satisfactory operation with Mobile IP. The expectation is that the appropriate working group will use this requirements document to provide a QoS solution for Mobile IP.
この文書では、我々は、モバイルIPとの満足な動作のためのQoSソリューションの要件を説明しました。期待は適切なワーキンググループは、モバイルIPのためのQoSソリューションを提供するために、この要件ドキュメントを使用することです。
I would like to acknowledge the participants of the mailing list that was set up to discuss the above requirements. Their contributions and active participation in the discussion on the mailing list were very useful in the preparation of this document. Special thanks are due to, in alphabetical order, Brian Carpenter (IBM), Marc Greis (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael Thomas (Cisco) for their input during the preparation of this document.
私は、上記の要件を議論するために設立されたメーリングリストの参加者を確認したいと思います。彼らの貢献やメーリングリストでの議論に積極的に参加は、本文書の作成に非常に有用でした。特別な感謝は、本文書の作成時に、その入力のために、アルファベット順、ブライアン・カーペンター（IBM）、マルク・グレイス（ノキア）、グレン・モロー（ノーテル）で、フィル・ロバーツ（Megisto）とマイケル・トーマス（シスコ）によるものです。
[1] Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344, August 2002.
[1]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[3] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE. Felstaine、「Diffservのネットワーク経由の統合サービス操作のための枠組み」、RFC 2998、2000年11月。
[4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[4]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様書"、RFC 2205、1997年9月。
[5] Kempf, J., Ed., "Problem description: Reasons for performing context transfers between nodes in an IP Access Network", RFC 3374, September 2002.
[5]ケンプ、J.、編、「問題の説明：IPアクセスネットワーク内のノード間でコンテキスト転送を実行する理由」、RFC 3374、2002年9月。
[6] Johnson, D., Perkins, C. and J. Arkko, "Mobility support in IPv6", Work in Progress, May 2003.
[6]ジョンソン、D.、パーキンス、C.とJ. Arkko、 "IPv6におけるモビリティサポート"、進歩、2003年5月での作業。
[7] Trossen, D., et al., "Issues in Candidate Access Router discovery for seamless IP handoffs", Work in Progress, October 2002.
[7] Trossen、D.ら、「シームレスなIPハンドオフのための候補アクセスルータ発見における問題」、進歩、2002年10月の作業。
[8] Chaskar, H. and R. Koodli, "QoS support in Mobile IP version 6", IEEE Broadband Wireless Summit (Networld+Interop), May 2001.
[8] Chaskar、H.及びR. Koodli、 "モバイルIPバージョン6におけるQoSサポート"、IEEEブロードバンド無線サミット（たNetworld +相互運用）、2001年5月。
[9] Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work in Progress, February 2001.
[9]トーマス、M.、 "モバイルIPとRSVPの相互作用の解析"、進歩、2001年2月での作業。
[10] MIPv4 Handoffs Design Team, "Low latency handoffs in Mobile IPv4", Work in Progress, June 2002.
[10]のMIPv4ハンドオフ設計チーム、「モバイルIPv4における低遅延ハンドオフ」、進歩、2002年6月での作業。
[11] Koodli, R., Ed., "Fast handovers for Mobile IPv6", Work in Progress, March 2003.
[11] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバー"、進歩、2003年3月での作業。
[12] Williams, C., Ed., "Localized mobility management requirements", Work in Progress, March 2003.
[12]ウィリアムズ、C.、エド。、 "ローカライズされたモビリティ管理要件"、進歩、2003年3月に作業。
[13] Soliman, H., et al., "Hierarchical MIPv6 mobility management (HMIPv6)", Work in Progress, October 2002.
[13]ソリマン、H.、ら、 "階層MIPv6のモビリティ管理（HMIPv6の）"、進歩、2002年10月に働いています。
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡することができます。
John Loughney Nokia Research Center 11-13 Italahdenkatu 00180 Helsinki Finland
ジョンLoughneyノキア・リサーチセンター11-13 Italahdenkatu 00180ヘルシンキフィンランド
EMail: john.loughney@nokia.com
メールアドレス：john.loughney@nokia.com
Questions about this memo can be directed to the editor:
このメモに関する質問は編集者に向けることができます。
Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
Hemant Chaskarノキア・リサーチセンター5道端の道路バーリントン、MA 01803、USA
Phone: +1 781-993-3785 EMail: hemant.chaskar@nokia.com
電話：+1 781-993-3785電子メール：hemant.chaskar@nokia.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。