RFC3583 日本語訳

Network Working Group                                    H. Chaskar, Ed.
Request for Comments: 3583                         Nokia Research Center
Category: Informational                                   September 2003

ワーキンググループH.Chaskar、エドをネットワークでつないでください。コメントのために以下を要求してください。 3583年のノキアリサーチセンターカテゴリ: 情報の2003年9月

   Requirements of a Quality of Service (QoS) Solution for Mobile IP

モバイルIPのためのサービスの質(QoS)ソリューションの要件

Status of this Memo

この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)インターネット協会(2003)。 All rights reserved。

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はパケットの正しいルーティングをモバイルノードに確実にします。 しかしながら、また、それがネットワークにおける中間的ノードのモバイルノードのパケットストリームに処理を送りながらService(QoS)の適切なQualityを提供するのに必要です、モバイルIPの上でQoS敏感なIPサービスをサポートすることができるように。 このドキュメントはモバイルIPとの満足できる操作のためにIP QoSメカニズムのための要件について説明します。

Chaskar                      Informational                      [Page 1]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[1ページ]のRFC3583

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 問題声明。 . . . . . . . . . . . . . . . . . . . 2 1.2. モバイルIP. . . . 3 2のQoS問題を解決するためのアプローチ。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. モバイルIP. . . . . . . . . 3 3.1のためのQoSソリューションの要件。 パフォーマンス要件. . . . . . . . . . . . . . . . 4 3.2。 相互運用性要件。 . . . . . . . . . . . . . 5 3.3. 種々雑多な要件. . . . . . . . . . . . . . . 6 3.4。 標準の要件。 . . . . . . . . . . . . . . . . . 7 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 7 5. 推薦. . . . . . . . . . . . . . . . . . . . . . . . 8 6。 承認. . . . . . . . . . . . . . . . . . . . . . . . 8 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1。 引用規格. . . . . . . . . . . . . . . . . . 8 7.2。 有益な参照. . . . . . . . . . . . . . . . . 8 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 9 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 10

1.  Introduction

1. 序論

   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)とコミュニケートしている間に接着点をインターネットに変えることができる技術です。 [1、6]でモバイルIPの形式的記述を見つけることができます。 モバイルIPはインターネットで主としてミネソタの現在の接着点にパケットの正しいルーティングを扱います。

   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.

また、ノードの移動性のため、異なったルートに沿ってネットワークで伝播するとき、ミネソタにパケットへの処理が送ったService(QoS)推進の適切なQualityを提供するか、または運命づけるのも不可欠です。 このドキュメントはモバイルIPがIP QoSメカニズムに入賞するという要件を特定するでしょう。

1.1.  Problem Statement

1.1. 問題声明

   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を使用するミネソタが1つのアクセスルータから別のルータまでの引き渡しを受けるとき、ネットワークにおけるミネソタのパケットストリームによって横断された経路は変化するかもしれません。 それには、そのような変化が先端の近くで終わりから端への経路の小さいセグメントに制限されるかもしれませんか、またはまた、終わりから終わりへの影響力があるかもしれません。 したがって、それらは終わりから端への引き渡しの後に非変更されたままで残っている経路のそのセグメントに沿ってさえノードでのいくつかの推進機能によって認識されません。さらに、ミネソタの進行中のセッションに属するパケットが、新しい状態でaを使用し始めるかもしれない、注意、-、アドレス後引き渡し最終的に、引き渡しは異なった運営管理コントロールの下にあるサブネットの間に起こるかもしれません。

Chaskar                      Informational                      [Page 2]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[2ページ]のRFC3583

   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.

このシナリオの見地から、新しいパケット経路に沿ったミネソタのパケットストリームの適切なQoSサポートを確立するのは不可欠です。

1.2.  An approach for solving the QoS problem in Mobile IP

1.2. モバイルIPの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) QoSメカニズムの上のモバイルIP場所、(2)がこれらの要件に対して現在のIP QoSソリューションを評価するという要件をリストアップしてください、そして、もの定義されるべき新たな必要性、およびステップ3の結果に依存する(4)が現在のソリューションが、広げられる必要があるかどうか、新しいソリューションを定義するか、または古い方を修理するか決めてください。

   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問題に関する役に立つ洞察を作成するために、時にはこのドキュメントはパケットストリームのQoSサポートをネットワークに確立するためのいくつかのよく知られている現在の提案の短所を強調します、モバイルIPと共に直接使用されると。

2.  Terminology

2. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [2].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。

3.  Requirements of a QoS solution for Mobile IP

3. モバイルIPのためのQoSソリューションの要件

   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.

本書では、私たちは、ミネソタの引き渡しのための目標アクセスルータが他のプロトコルによって既に束縛されると思います。 例えば、Seamobyワーキンググループ候補アクセスルータ発見プロトコル[7]で就業しました。 したがって、そういうもののQoSソリューションの範囲の外に引き渡し決定に影響するかもしれないどんなQoS-能力の特定の交渉もあります、むしろ候補と目標アクセスルータ選択プロトコルによって実行されるべき必要性。

Chaskar                      Informational                      [Page 3]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[3ページ]のRFC3583

3.1.  Performance requirements

3.1. パフォーマンス要件

   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.

引き渡し時点で、発信するか、またはミネソタに運命づけられたパケットがそれらの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.

例、この性能としてメートル法であることは、終わらせる終わりのRSVPに関するケースのための計算されたコネ[8]です。モバイルIPv6と共に[3]に合図します。 終わりから端へのパケットの経路であるときに、そこでは、それが引き渡しかいつ以降多大に変化するかが示される、注意、-、引き渡しの後のアドレス変化、新しいパケット経路に沿ってQoSを設立できる前にRSVPによって使用された予約のOPWA(1つのPass With Advertisement)モデルがミネソタとCNの間の往復のおよそ1回の潜在を引き起こします。 言い換えれば、これらのノードがアドレスの新しい注意を働かせた準備ができていた後に往復の1回の間にミネソタかCNによってリリースされるアドレスの新しい注意を働かせるパケットで、デフォルトは中間的ノードで処理を進めるかもしれません。 QoSプログラミングにおけるそのような潜在はセッション開始の時代許容できるかもしれませんが、引き渡しに関してそうであるようにそれは活発なセッションの途中で許容できません。

   2. Localize the QoS (re)establishment to the affected parts of the
      packet path in the network:

2. ネットワークでQoS(re)が設立であるとパケット経路の患部にローカライズしてください:

      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.

多くの場合、引き渡しは先端の近くでミネソタのパケットストリームの終わりまでの端の経路の小さいセグメントだけを変えます。 そして、QoSメカニズムはQoS(re)設立の範囲を終わりから端への経路の影響を受けるセグメントだけに制限しなければなりません。

      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.

しかしながら、引き渡しがネットワークにおけるミネソタのパケットストリームの終わりから端への経路を時々詳細に変えさせるかもしれないことに注意してください。 例えば、これは異なった管理ドメインの間の引き渡しの場合で起こるかもしれません。 したがって、新しいパケット経路に沿ったミネソタのパケットストリームのQoSサポートをネットワークに確立するのにおいて中古のQoSメカニズムがそういうものの終わりから終わりへの明白な食糧を供給するのに基づいているなら、それはそのような引き渡し時点で、働かなければなりません。

Chaskar                      Informational                      [Page 4]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[4ページ]のRFC3583

      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ノードかパケットクラシファイアのFILTER SPECsです。 しかしながら、パケット経路の変わりのない地域の上リソースの二重食糧を供給することを避けなければなりません。

      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州が引き渡し時点でできるだけはやくリリースされるのは、望ましいです。ミネソタが引き渡しの間いつも古いアクセスルータがあるリンクレイヤの接続性の損失のために古い経路に沿って明白な裂け目をメッセージの下側に送る機会を得るかもしれないというわけではないことに注意してください。

3.2.  Interoperability requirements

3.2. 相互運用性要件

   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ワーキンググループで。 例は移動性文脈転送[5]管理[12、13]であるのなどとローカライズされた速い引き渡し[10、11]です。 モバイルIP SHOULDのための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

引き渡しの後の新しい経路はミネソタのパケットストリームについてパラダイムが古い経路に沿ってそれらと比較したネットワークドメインの雇用の異なったQoSを横断するかもしれません。 QoSメカニズム

Chaskar                      Informational                      [Page 5]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[5ページ]のRFC3583

      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 SHOULD、異なったQoSがパラダイム(最も良い現在の実務)であると配布しながら、パケット経路に沿ってミネソタのパケットストリームに関する適切なQoS推進処理を確立できてください、それらの経路に沿って配布される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.

イラストとして、ミネソタが現在、DiffServネットワークの縁のルータであるアクセスルータに付けられて、ミネソタの流れのためのパケットクラシファイアとトラフィックpolicerが現在このアクセスルータでプログラムされると仮定してください。 今度は、ミネソタが、IntServネットワークの縁にあるアクセスルータに引き渡される必要であると仮定してください。 新しいアクセスネットワークは、そのアクセスネットワークにおけるミネソタのパケットストリームのために適切なQoS推進処理を確立できるようにRSVPメッセージの交換を予想するでしょう。 モバイルIP SHOULDにはQoSメカニズムを見なすような異種性を扱う条項があるので、QoSメカニズムは異なったパケット経路に沿って展開しました。

3.3.  Miscellaneous requirements

3.3. 種々雑多な要件

   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.

ミネソタが1つのアクセスルータから別のルータまでの引き渡しを受けた後に、潜在的に、ミネソタのパケットが伝播されるかもしれない複数の経路があるかもしれません。 これらの経路に関する例は以下の通りです。 ミネソタとそのCNの間のルートで最適化された経路、ホームエージェント(HA)を通した三角形ルート、古くて新しいアクセスルータの間の一時的なトンネルは新しいアクセスルータ(外国人のエージェント)からHAなどまでトンネルを逆にします。 QoSメカニズムSHOULD、異なった潜在的パケット経路に沿ってQoSをサポートすることができてください。 しかしながら、すべての経路がサポートされるか、またはそれらの部分集合だけがサポートされるかが移動性管理、方針、位置のプライバシー要件などなどの外部のメカニズムで決定するでしょう。 さらに、同じ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

そのような情報の利益を得るかもしれない例のシナリオは2では、UDPがそれらのそれぞれのコード化体系のある特性のためワイヤレスのリンクレイヤで同じメディアに関連づけられますが、異なったレベルの誤り保護を必要としながら流れるということです。 これらの2つのストリームのパケットが遅れ等しく敏感である、(再生同期を維持します。

Chaskar                      Informational                      [Page 6]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[6ページ]のRFC3583

      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).

受信機)、したがって、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情報はそれが重要であるようなものが両方の道であったならワイヤレスのリンクレイヤの恩恵のためにSHOULDを含んでいました: 彼らが、ある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.

上で説明された例のシナリオでは、UDPストリームにおける、IPパケットの許容損害率としてそのようなQoS情報を言い表すことができました。 このパラメタは、UDPアプリケーションが要件に合っているQoSを持っているIPサービスを選ぶのを可能にします、そして、また、それはワイヤレスのリンクQoSマネージャがこのUDPストリームのパケットを伝えるために正しいワイヤレスのチャンネルを選ぶのを可能にします。

3.4.  Standard requirements

3.4. 標準の要件

   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 SHOULDのためのソリューションが承認、会計、および丈夫さのためにネットワークにおけるどんなモバイルIP特有のQoSの部品の失敗に対してフックするのをスケーラビリティ、セキュリティ、ワイヤレスの帯域幅の保護、移動体端末、提供での低い処理オーバヘッドなどの標準の要件に満たすQoS。 これらの望ましい特性のための定量的目標を設定するのが可能でない間、これらの評価基準に対してQoSソリューションを評価しなければなりません。

4.  Security Considerations

4. セキュリティ問題

   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を偽造する悪意があるノードはそのような攻撃に着手できました。そのような攻撃は、次に、中間的ノードがミネソタとCNの間の本当のパケット経路のいくつかのセグメントに沿ってQoSを取りこわすかもしれないのでミネソタの進行中のセッションまで提供されたQoSを混乱させるかもしれません。 悪意があるノードは、また、QoSの減少しているレベルを要求するか、またはにせのパケットクラシファイアを供給するかもしれません、その結果、ミネソタとCNの間の本当のパケット経路のいくつかのセグメント(例えば、それは偽造している引き渡しで影響を受けない)の上でQoSに影響します。 さらに、ネットワーク資源は、ミネソタの引き渡しを偽造する悪意があるノードによって、権限のない方法で浪費されるか、または使用されるかもしれません。これを防ぐために、QoSメカニズムは中間的ノードが引き渡しで誘発されたQoS(re)設立の信憑性について確かめる手段を提供しなければなりません。

Chaskar                      Informational                      [Page 7]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[7ページ]のRFC3583

5.  Recommendation

5. 推薦

   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ソリューションのための要件について説明しました。 期待は適切なワーキンググループがQoS解決法をモバイルIPに提供するのにこの要件ドキュメントを使用するということです。

6.  Acknowledgment

6. 承認

   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.

セットアップされたメーリングリストの関係者が上記の要件について議論すると認めたいと思います。 メーリングリストについての議論への彼らの貢献と積極的な参加はこのドキュメントの準備で非常に役に立ちました。 特別な感謝はこのドキュメントの準備の間の彼らの入力のためのアルファベット順にブライアンCarpenter(IBM)、マークGreis(ノキア)、グレンモロー(ノーテル)、フィル・ロバーツ(Megisto)、およびマイケル・トーマス(シスコ)のためです。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [1]  Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344,
        August 2002.

[1] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、フォード、P.、Yavatkar、R.、パン屋、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE.Felstaine、「Diffservネットワークの上の統合サービス操作のためのフレームワーク」、RFC2998(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の機能的な仕様」、RFC2205、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 Access Networkのノードの間の文脈転送を実行する理由」、RFC3374、2002年9月。

7.2.  Informative References

7.2. 有益な参照

   [6]  Johnson, D., Perkins, C. and J. Arkko, "Mobility support in
        IPv6", Work in Progress, May 2003.

[6] ジョンソンとD.とパーキンスとC.とJ.Arkko、「IPv6"、Progress、2003年5月のWorkでの移動性サポート。」

Chaskar                      Informational                      [Page 8]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[8ページ]のRFC3583

   [7]  Trossen, D., et al., "Issues in Candidate Access Router
        discovery for seamless IP handoffs", Work in Progress, October
        2002.

Trossen(D.、他)が「Candidate Access Router発見ではシームレスのIP handoffsのために発行する」[7]、Progress、2002年10月のWork。

   [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、「QoSは2001年5月にモバイルIPでバージョン6インチ、IEEE Broadband Wirelessサミット(Networld+Interop)をサポートします」。

   [9]  Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work
        in Progress, February 2001.

[9] トーマス、M.、「モバイルIPとRSVP相互作用の分析」、Progress、2001年2月のWork。

   [10] MIPv4 Handoffs Design Team, "Low latency handoffs in Mobile
        IPv4", Work in Progress, June 2002.

[10] MIPv4 Handoffs Design Team、「モバイルIPv4"の低遅延handoffs、ProgressのWork、2002年6月。」

   [11] Koodli, R., Ed., "Fast handovers for Mobile IPv6", Work in
        Progress, March 2003.

[11]Koodli、R.、エド、「速く、モバイルIPv6"、ProgressのWork、2003年3月に、引き渡します」。

   [12] Williams, C., Ed., "Localized mobility management requirements",
        Work in Progress, March 2003.

[12] エドウィリアムズ、C.、Progress、2003年3月のWork「移動性管理要件であるとローカライズされ」て。

   [13] Soliman, H., et al., "Hierarchical MIPv6 mobility management
        (HMIPv6)", Work in Progress, October 2002.

[13] ソリマン、H.、他、「階層的なMIPv6移動性管理(HMIPv6)」、Progress、2002年10月のWork。

8.  Authors' Addresses

8. 作者のアドレス

   The working group can be contacted via the current chair:

現在のいすを通してワーキンググループに連絡できます:

   John Loughney
   Nokia Research Center
   11-13 Italahdenkatu
   00180 Helsinki
   Finland

ジョンLoughneyノキアResearch Center11-13Italahdenkatu00180ヘルシンキフィンランド

   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、米国

   Phone: +1 781-993-3785
   EMail: hemant.chaskar@nokia.com

以下に電話をしてください。 +1 781-993-3785 メールしてください: hemant.chaskar@nokia.com

Chaskar                      Informational                      [Page 9]

RFC 3583              Mobile IP QoS Requirements          September 2003

IP QoS要件2003年9月のモバイルのChaskar情報[9ページ]のRFC3583

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Chaskar                      Informational                     [Page 10]

Chaskar情報です。[10ページ]