[要約] 要約：RFC 3583は、モバイルIPにおける品質サービス（QoS）ソリューションの要件について説明しています。 目的：このRFCの目的は、モバイルIP環境でのQoSの重要性を強調し、モバイルユーザーに高品質なサービスを提供するための要件を定義することです。
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）ソリューションの要件
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.
Copyright（c）The Internet Society（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は、「モバイルノード」（MN）がIPを使用して「特派員ノード」（CN）と通信しながら、インターネットへの添付ポイントを変更できるようにするテクノロジーです。モバイル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が送信または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が1つのアクセスルーターから別のアクセスルーターにハンドオーバーを受けると、ネットワーク内の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）モバイルIPがQoSメカニズムに配置する要件をリストします。（2）これらの要件に対して現在のIP QOSソリューションを評価します。定義され、（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 Working Groupは、候補者アクセスルーター発見プロトコルの作業を開始しました[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が送信または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.
例として、このパフォーマンスメトリックは、モバイルIPv6を使用したエンドツーエンドのRSVPシグナル伝達[3]の場合、[8]で計算されます。そこには、パケットのエンドツーエンドパスがハンドオーバー後またはハンドオーバー後に大規模に変化するとき、RSVPが使用する予約のOPWA（広告付きの1つのパス）モデルは、約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 [9]などのQoSシグナル伝達プロトコルは、ハンドオーバー時にケアのケアが変更されない場合、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を補完する多くのモビリティプロトコルは、すでに定義されているか、IETF、特にモバイルIPおよびSeamobyワーキンググループで将来定義されるか、将来定義される可能性があります。例は、高速ハンドオーバー[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 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.
ハンドオーバー後の新しいパス、MNのパケットストリームの場合、古い経路に沿ったQoSパラダイムと比較して、異なるQoSパラダイムを使用する可能性のあるネットワークドメインがあります。モバイルIPのQoSメカニズムは、それらのパスに沿って展開された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をIntServネットワークの端にあるアクセスルーターに引き渡す必要があると仮定します。新しいアクセスネットワークは、RSVPメッセージの交換を期待して、そのアクセスネットワーク内のMNのパケットストリームに対して適切なQoS転送処理を確立できるようにします。モバイルIPのQoSメカニズムには、さまざまなパケットパスに沿って展開された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が1つのアクセスルーターから別のアクセスルーターへの引き渡しを受けた後、潜在的に、MNのパケットが伝播する可能性のある複数のパスがある可能性があります。これらのパスの例は次のとおりです。MNとそのCNの間のルート最適化されたパス、ホームエージェント（HA）を介した三角形ルート、古いアクセスルーターと新しいアクセスルーターの間の一時的なトンネル、新しいアクセスルーター（外部エージェント）からHAなどへの逆トンネル。QoSメカニズムは、さまざまな潜在的なパケットパスに沿ってQOをサポートできる必要があります。ただし、すべてのパスがサポートされているか、それらのサブセットのみがサポートされているかどうかは、モビリティ管理、ポリシー、ロケーションプライバシー要件などの外部メカニズムによって決定されます。さらに、同じQoSメカニズムがこれらすべてのパスをサポートできない場合があります。
2. Interactions with wireless link-layer support for QoS:
2. QOSのワイヤレスリンク層サポートとの相互作用：
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を使用する膨大な数のデバイスがワイヤレスリンクを介してインターネットに接続されるため、モバイルIPのQoSメカニズムは、必要な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ストリームのシナリオですが、それぞれのエンコードスキームの特定の特性により、ワイヤレスリンク層で異なるレベルのエラー保護が必要です。これらの2つのストリームのパケットは、等しく遅延感受性があり（受信機でプレイアウト同期を維持するため）、したがって、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サービスを選択し、QoSマネージャーをワイヤレスリンクに選択できるように、IPに存在するアプリケーションにこの情報を下層メカニズムとそのパラメーターの詳細にマッピングします。
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パケットの許容可能な損失率として表現できます。このパラメーターにより、UDPアプリケーションは要件に一致するQoSを持つIPサービスを選択できます。また、ワイヤレスリンクQoSマネージャーが適切なワイヤレスチャネルを選択して、このUDPストリームのパケットを送信することもできます。
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（RE）施設は、セキュリティ攻撃から守らなければなりません。このような攻撃は、QoSシグナリングを押し上げて、MNがハンドオーバーを受けた中間ノードに表示される悪意のあるノードによって発売される可能性があります。このような攻撃は、中間ノードがMNとCNの間の真のパケットパスのいくつかのセグメントに沿ってQOを取り壊す可能性があるため、MNの継続的なセッションに提供されるQOを混乱させる可能性があります。悪意のあるノードは、QoSのレベルの低下または偽のパケット分類子を供給することも要求する場合があり、それにより、MNとCNの間の真のパケットパスのいくつかのセグメント（たとえば、スプーフィングされたハンドオーバーの影響を受けない）のQOに影響を与えます。さらに、ネットワークリソースは、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）、マークグレイ（ノキア）、グレンモロー（ノルテル）、フィルロバーツ（メギスト）、マイケルトーマス（シスコ）がこの文書の準備中に入力してくれたことに特に感謝しています。
[1] Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344, August 2002.
[1] Perkins、C.、ed。、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、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] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Kempf、J.、ed。、「問題の説明：IPアクセスネットワーク内のノード間のコンテキスト転送を実行する理由」、RFC 3374、2002年9月。
[6] Johnson, D., Perkins, C. and J. Arkko, "Mobility support in IPv6", Work in Progress, May 2003.
[6] Johnson、D.、Perkins、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.、et al。、「シームレスな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 Interop）、2001年5月。
[9] Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work in Progress, February 2001.
[9] Thomas、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.、ed。、「モバイルIPv6の高速ハンドオーバー」、2003年3月、進行中の作業。
[12] Williams, C., Ed., "Localized mobility management requirements", Work in Progress, March 2003.
[12] Williams、C.、ed。、「ローカライズされたモビリティ管理要件」、2003年3月、進行中の作業。
[13] Soliman, H., et al., "Hierarchical MIPv6 mobility management (HMIPv6)", Work in Progress, October 2002.
[13] Soliman、H.、et al。、「Hierarchical Mipv6 Mobility Management（hmipv6）」、2002年10月の作業。
The working group can be contacted via the current chair:
ワーキンググループは、現在の椅子から連絡できます。
John Loughney Nokia Research Center 11-13 Italahdenkatu 00180 Helsinki Finland
ジョン・ラウニー・ノキア・リサーチ・センター11-13イタラデンカトゥ00180ヘルシンキ・フィンランド
EMail: 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 Nokia Research Center 5ウェイサイドロードバーリントン、マサチューセッツ州01803、米国
Phone: +1 781-993-3785
EMail: hemant.chaskar@nokia.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。