RFC3374 日本語訳

Network Working Group                                      J. Kempf, Ed.
Request for Comments: 3374                                September 2002
Category: Informational

ワーキンググループのJ.ケンフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 3374 2002年9月のカテゴリ: 情報

     Problem Description: Reasons For Performing Context Transfers
                 Between Nodes in an IP Access Network

問題記述: IPアクセスネットワークでノードの間の文脈転送を実行する理由

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 (2002).  All Rights Reserved.

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

Abstract

要約

   In IP access networks that support host mobility, the routing paths
   between the host and the network may change frequently and rapidly.
   In some cases, the host may establish certain context transfer
   candidate services on subnets that are left behind when the host
   moves.  Examples of such services are Authentication, Authorization,
   and Accounting (AAA), header compression, and Quality of Service
   (QoS).  In order for the host to obtain those services on the new
   subnet, the host must explicitly re-establish the service by
   performing the necessary signaling flows from scratch.  In some
   cases, this process would considerably slow the process of
   establishing the mobile host on the new subnet.  An alternative is to
   transfer information on the existing state associated with these
   services, or context, to the new subnet, a process called "context
   transfer".  This document discusses the desirability of context
   transfer for facilitating seamless IP mobility.

ホストに移動性をサポートするIPアクセスネットワークでは、ホストとネットワークの間のルーティング経路は頻繁に急速に変化するかもしれません。 いくつかの場合、ホストはホストが移行するとき後に残されるサブネットで、ある文脈転送候補サービスを確立するかもしれません。 そのようなサービスに関する例は、Service(QoS)のAuthenticationと、Authorizationと、Accounting(AAA)と、ヘッダー圧縮と、Qualityです。 ホストが新しいサブネットでそれらのサービスを得るように、ホストは最初から必要なシグナリング流れを実行することによって、サービスを明らかに復職させなければなりません。 いくつかの場合、このプロセスは新しいサブネットにモバイルホストを設立するプロセスをかなり遅くするでしょう。 代替手段はこれらのサービス、または文脈に関連している現状の情報を移すことです、新しいサブネットに、「文脈転送」と呼ばれるプロセス。 このドキュメントはシームレスのIPの移動性を容易にするための文脈転送の願わしさについて議論します。

Kempf                        Informational                      [Page 1]

RFC 3374           Context Transfer Problem Statement     September 2002

[1ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

Table of Contents

目次

   1.0   Introduction................................................2
   2.0   Reference Definitions.......................................3
   3.0   Scope of the Context Transfer Problem.......................3
   4.0   The Need for Context Transfer...............................4
   4.1   Fast Context Transfer-candidate Service Re-establishment....4
   4.1.1 Authentication, Authorization, and Accounting (AAA).........4
   4.1.2 Header Compression..........................................5
   4.1.3 Quality of Service (QoS)....................................6
   4.2   Interoperability............................................6
   5.0   Limitations on Context Transfer.............................7
   5.1   Router Compatibility........................................7
   5.2   Requirement to Re-initialize Service from Scratch...........7
   5.3   Suitability for the Particular Service......................7
   5.4   Layer 2 Solutions Better....................................7
   6.0   Performance Considerations..................................8
   7.0   Security Considerations.....................................8
   8.0   Recommendations.............................................9
   9.0   Acknowledgements............................................9
   10.0  References.................................................10
   11.0  Complete List of Authors' Addresses........................12
   12.0  Full Copyright Statement...................................14

1.0序論…2 2.0 参照定義…3 3.0 文脈移転問題の範囲…3 4.0 文脈転送の必要性…4 4.1 速い文脈転送候補サービス再設立…4 4.1 .1 認証、承認、および会計(AAA)…4 4.1 .2 ヘッダー圧縮…5 4.1 .3 サービスの質(QoS)…6 4.2相互運用性…6 文脈における5.0の制限が移されます…7 5.1 ルータの互換性…7 最初からサービスを再初期化するという5.2要件…7 特定のサービスへの5.3適合…7 5.4 2つのソリューションをよりよく層にしてください…7 6.0 パフォーマンス問題…8 7.0 セキュリティ問題…8 8.0の推薦…9 9.0の承認…9 10.0の参照箇所…作者のアドレスに関する10 11.0全リスト…12 12.0 完全な著作権宣言文…14

1.0 Introduction

1.0 序論

   In networks where the hosts are mobile, the routing path through the
   network must often be changed in order to deliver the host's IP
   traffic to the new point of access.  Changing the basic routing path
   is the job of a IP mobility protocol, such as Mobile IPv4 [1] and
   Mobile IPv6 [2].  But the success of real time services such as VoIP
   telephony, video, etc., in a mobile environment depends heavily upon
   the minimization of the impact of this traffic redirection.  In the
   process of establishing the new routing path, the nodes along the new
   path must be prepared to provide similar routing treatment to the IP
   packets as was provided along the old routing path.

ホストモバイルであるネットワークでは、ホストのIPトラフィックをアクセサリーの新しいポイントに提供するためにネットワークを通したルーティング経路をしばしば変えなければなりません。 基本的なルーティング経路を変えるのは、IP移動性プロトコルの仕事です、モバイルIPv4[1]やモバイルIPv6[2]のように。 しかし、リアルタイムでVoIP電話、モバイル環境におけるビデオなどのサービスの成功は大いにこのトラフィックリダイレクションの影響の最小化によります。 新しいルーティング経路を確立することの途中に、古いルーティング経路に沿って提供されたIPパケットに同様のルーティング処理を提供するように新しい経路に沿ったノードを準備しなければなりません。

   In many cases, the routing treatment of IP packets within a network
   may be regulated by a collection of context transfer-candidate
   services that influence how packets for the host are treated.  For
   example, whether a particular host has the right to obtain any
   routing at all out of the local subnet may depend on whether the host
   negotiated a successful AAA exchange with a network access server at
   some point in the past.  Establishing these services initially
   results in a certain amount of related state within the network and
   requires a perhaps considerable amount of time for the protocol

多くの場合、ネットワークの中のIPパケットのルーティング処理はホストのためのパケットがどう扱われるかに影響を及ぼす文脈転送候補サービスの収集で規制されるかもしれません。 例えば、特定のホストには地方のサブネットから何か全くルーティングを得る権利があるかどうかがホストが過去に何らかのポイントのネットワークアクセス・サーバーとうまくいっているAAA交換を交渉したかどうかによるかもしれません。 初めはこれらのサービスを確立するとある量の関連する状態がネットワークの中でもたらされる、必要である、恐らくかなりの時間、プロトコル

Kempf                        Informational                      [Page 2]

RFC 3374           Context Transfer Problem Statement     September 2002

[2ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   exchanges.  If the host is required to re-establish those services by
   the same process as it uses to initially establish them, delay-
   sensitive real time traffic may be seriously impacted.

交換。 ホストがそれと同じプロセスでそれらのサービスを復職させなければならないなら、初めはへの用途はそれらを設立して、真剣に遅れの敏感なリアルタイムのトラフィックに影響を与えるかもしれません。

   An alternative is to transfer enough information on the context
   transfer-candidate service state, or context, to the new subnet so
   that the services can be re-established quickly, rather than require
   the mobile host to establish them from scratch.  The transfer of
   service context may be advantageous in minimizing the impact of host
   mobility on, for example, AAA, header compression, QoS, policy, and
   possibly sub-IP protocols and services such as PPP.  Context transfer
   at a minimum can be used to replicate the configuration information
   needed to establish the respective protocols and services.  In
   addition, it may also provide the capability to replicate state
   information, allowing stateful protocols and services at the new node
   to be activated along the new path with less delay and less signaling
   overhead.

代替手段はモバイルホストが最初からそれらを設立するのが必要であるというよりもサービスがすばやくむしろ復職できるように新しいサブネットへの文脈転送候補サービス状態、または文脈の十分な情報を移すことです。 サービス文脈の転送は例えば、PPPなどのAAA、ヘッダー圧縮、QoS、方針、ことによるとサブIPプロトコル、およびサービスのときにホストの移動性の影響を最小にするのに有利であるかもしれません。 それぞれのプロトコルとサービスを確立するのに必要である設定情報を模写するのに最小限での文脈転送を使用できます。 また、さらに、州の情報を模写する能力を提供するかもしれません、新しいノードでのstatefulプロトコルとサービスが新しい経路に沿って、より少ない遅れと、より少ないシグナリングオーバーヘッドで起動されるのを許容して。

   In this document, a case is made for why the Seamoby Working Group
   should investigate context transfer.

本書では、弁護はSeamoby作業部会が文脈転送を調査するべきである理由のためにされます。

2.0 Reference Definitions

2.0 参照定義

   Context

文脈

      The information on the current state of a service required to re-
      establish the service on a new subnet without having to perform
      the entire protocol exchange with the mobile host from scratch.

サービスの現状の情報が新しいサブネットで最初からモバイルホストと共に全体のプロトコル交換を実行する必要はなくてサービスを再確立するのが必要です。

   Context Transfer

文脈転送

      The movement of context from one router or other network entity to
      another as a means of re-establishing specific services on a new
      subnet or collection of subnets.

サブネットの新しいサブネットか収集に特定のサービスを復職させる手段としての文脈の1つのルータか他のネットワーク実体から別の実体までの動き。

   Context Transfer Candidate Service

文脈転送候補サービス

      A service that is a candidate for context transfer.  In this
      document, only services that are concerned with the forwarding
      treatment of packets, such as QoS and security, or involve
      granting or denying the mobile host access to the network, such as
      AAA, are considered to be context transfer-candidate services.

文脈転送の候補であるサービス。 QoSやセキュリティなどのパケットの推進処理に心配しているか、またはネットワークへのモバイルホストアクセスを承諾するか、または拒絶することを伴うAAAなどのサービスだけが、文脈転送候補サービスであると考えられます。

3.0 Scope of the Context Transfer Problem

3.0 文脈移転問題の範囲

   The context transfer problem examined in this document is restricted
   to re-establishing services for a mobile host that are, in some
   sense, related to the forwarding treatment of the mobile host's

本書では調べられた文脈移転問題はモバイルホストのための何らかの意味でモバイルホストの推進処理に関連するサービスを復職させるのに制限されます。

Kempf                        Informational                      [Page 3]

RFC 3374           Context Transfer Problem Statement     September 2002

[3ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   packets or network access for the mobile host.  It is not concerned
   with actually re-establishing routing information.  Routing changes
   due to mobility are the domain of the IP mobility protocol.  In
   addition, transfer of context related to application-level services,
   such as those associated with the mobile host's HTTP proxy, is also
   not considered in this document, although a generic context transfer
   protocol for transferring the context of services related to
   forwarding treatment or network access may also function for
   application-level services as well.

モバイルホストのためのパケットかネットワークアクセス。 それは実際にルーティング情報を復職させるのに関係がありません。 移動性によるルート設定変化はIP移動性プロトコルのドメインです。 さらに、それらなどのアプリケーションレベルサービスに関連する文脈の転送は、モバイルホストのHTTPプロキシと交際して、また、本書では考えられません、また、推進処理かネットワークアクセスに関連するサービスの文脈を移すためのジェネリック文脈転送プロトコルはまた、アプリケーションレベルサービスのために機能するかもしれませんが。

   An important consideration in whether a service is a candidate for
   context transfer is whether it is possible to obtain a "correct"
   context transfer for the service in a given implementation and
   deployment, that is, one which will result in the same context at the
   new access router as would have resulted had the mobile host
   undergone a protocol exchange with the access router from scratch.
   For some services, the circumstances under which context transfer may
   result in correctness may be very limited [11].

サービスが文脈転送の候補であるかどうかにおける重要な考慮すべき事柄は与えられた実装と展開(すなわち、モバイルホストが最初からアクセスルータでプロトコル交換を被ったならなったように新しいアクセスルータで同じ文脈をもたらすもの)でサービスのための「正しい」文脈転送を得るのが可能であるかどうかということです。 いくつかのサービスのために、文脈転送が正当性をもたらすかもしれない事情は非常に有限な[11]であるかもしれません。

4.0 The Need for Context Transfer

4.0 文脈転送の必要性

   There are two basic motivations for context transfer:

文脈に関する基本的な動機が移す2があります:

   1) The primary motivation, as mentioned in the introduction, is the
      need to quickly re-establish context transfer-candidate services
      without requiring the mobile host to explicitly perform all
      protocol flows for those services from scratch.

1) 序論で言及されるプライマリ動機はモバイルホストが最初からそれらのサービスのために明らかにすべてのプロトコル流れを実行する必要でない文脈転送候補サービスをすばやく復職させる必要性です。

   2) An additional motivation is to provide an interoperable solution
      that works for any Layer 2 radio access technology.

2) 追加動機はどんなLayer2ラジオアクセス技術のためにも働いている共同利用できる解決法を提供することです。

   These points are discussed in more detail in the following
   subsections.

さらに詳細に以下の小区分でこれらのポイントについて議論します。

4.1 Fast Context Transfer-candidate Service Re-establishment

4.1 速い文脈転送候補サービス再建

   As mentioned in the introduction, there are a variety of context
   transfer-candidate services that could utilize a context transfer
   solution.  In this section, three representative services are
   examined.  The consequences of not having a context transfer solution
   are examined as a means of motivating the need for such a solution.

序論で言及されるように、文脈転送解決を利用できたさまざまな文脈転送候補サービスがあります。 このセクションで、3つの代表しているサービスが調べられます。 文脈転送解決を持たない結果はそのようなソリューションの必要性を動機づける手段として調べられます。

4.1.1 Authentication, Authorization, and Accounting (AAA)

4.1.1 認証、承認、および会計(AAA)

   One of the more compelling applications of context transfer is
   facilitating the re-authentication of the mobile host and
   re-establishment of the mobile host's authorization for network
   access in a new subnet by transferring the AAA context from the

文脈転送の、より無視できない応用の1つはモバイルホストの再認証とネットワークのためのモバイルホストの承認の再建が新しいサブネットにおける移すのによるAAA文脈にアクセスする容易にすることです。

Kempf                        Informational                      [Page 4]

RFC 3374           Context Transfer Problem Statement     September 2002

[4ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   mobile host's previous AAA server to another.  This would allow the
   mobile host to continue access in the new subnet without having to
   redo an AAA exchange with the new subnet's AAA server.  Naturally, a
   security association between the AAA servers is necessary so that the
   mobile host's sensitive authentication information can be securely
   transferred.

モバイルホストは別のものへの前のAAAサーバです。 これで、新しいサブネットのAAAサーバによるAAA交換をやり直す必要はなくて、モバイルホストは新しいサブネットにおけるアクセスを続けることができるでしょう。当然、AAAサーバの間のセキュリティ協会が、しっかりとモバイルホストの機密の認証情報を移すことができるくらい必要です。

   In the absence of context transfer, there are two ways that can
   currently be used for AAA:

文脈転送が不在のとき、現在AAAに使用できる2つの方法があります:

   1) Layer 2 mechanisms, such as EAP [3] in PPP [4] or 802.1x [5] can
      be used to redo the initial protocol exchange, or possibly to
      update it.  Currently, there is no general Layer 3 mechanism for
      conducting an AAA exchange between a host and an AAA server in the
      network.

1) PPP[4]のEAP[3]などの2つのメカニズムを層にしてください。さもないと、初期のプロトコル交換をやり直すか、またはことによるとそれをアップデートするのに802.1x[5]は使用できます。 現在、ネットワークにおけるホストとAAAサーバの間には、AAA交換を行うためのどんな一般的なLayer3メカニズムもありません。

   2) If the mobile host is using Mobile IPv4 (but not Mobile IPv6
      currently), the host can use the AAA registration keys [6]
      extension for Mobile IPv4 to establish a security association with
      the new Foreign Agent.

2) モバイルホストがモバイルIPv4を使用している、(モバイルIPv6でない、現在)、モバイルIPv4が新しいForeignエージェントとのセキュリティ仲間を証明するのにホストはAAA登録キー[6]拡張子を使用できます。

   Since 2) is piggybacked on the Mobile IPv4 signaling, the performance
   is less likely to be an issue, but 2) is not a general solution.  The
   performance of 1) is likely to be considerably less than is necessary
   for maintaining good real time stream performance.

2が)モバイルIPv4シグナリングで背負われるので、性能はそれほど問題である傾向がでありませんが、2は)一般解ではありません。 1の)性能は良いリアルタイムのストリーム性能を維持するのに必要とするよりかなり少ない傾向があります。

4.1.2 Header Compression

4.1.2 ヘッダー圧縮

   In [7], protocols are described for efficient compression of IP
   headers to avoid sending large headers over low bandwidth radio
   network links.  Establishing header compression generally requires
   from 1 to 4 exchanges between the last hop router and the mobile host
   with full or partially compressed headers before full compression is
   available.  During this period, the mobile host will experience an
   effective reduction in the application-available bandwidth equivalent
   to the uncompressed header information sent over the air.  Limiting
   the uncompressed traffic required to establish full header
   compression on a new last hop router facilitates maintaining adequate
   application-available bandwidth for real time streams, especially for
   IPv6 where the headers are larger.

[7]では、IPヘッダーの効率的な圧縮が、低い帯域幅ラジオ放送網リンクの上に大きいヘッダーを送るのを避けるように、プロトコルは説明されます。 完全な圧縮が利用可能になる前に一般に、ヘッダー圧縮を確立するのは完全であるか部分的に圧縮されたヘッダーと共に最後のホップルータとモバイルホストの間の交換を1〜4まで必要とします。 この期間、モバイルホストは空気の上に送られた解凍されたヘッダー情報に同等な利用可能なアプリケーション帯域幅での有効な減少を経験するでしょう。 最後の新しいホップルータで完全なヘッダー圧縮を確立するのに必要である解凍されたトラフィックを制限するのは、リアルタイムのストリームのために適切な利用可能なアプリケーション帯域幅を維持するのを容易にします、特にヘッダーが、より大きいIPv6のために。

   Context transfer can help in this case by allowing the network entity
   performing header compression, usually the last hop router, to
   transfer the header compression context to the new router.  The
   timing of context transfer must be arranged so that the header
   context is transferred from the old router as soon as the mobile host

ヘッダー圧縮を実行するネットワーク実体、通常最後のホップルータがヘッダー圧縮文脈を新しいルータに移すのを許容することによって、文脈転送はこの場合助けることができます。 文脈転送のタイミングをアレンジしなければならないので、モバイルホストの次第古いルータからヘッダー文脈を移します。

Kempf                        Informational                      [Page 5]

RFC 3374           Context Transfer Problem Statement     September 2002

[5ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   is no longer receiving packets through the old router, and installed
   on the new router before any packets are delivered to or forwarded
   from the mobile host.

もう古いルータを通してパケットを受けていなくて、どんなパケットもモバイルホストから提供されるか進められる前に新しいルータにインストールされます。

4.1.3 Quality of Service (QoS)

4.1.3 サービスの質(QoS)

   Significant QoS protocol exchanges between the mobile host and
   routers in the network may be required in order to establish the
   initial QoS treatment for a mobile host's packets.  The exact
   mechanism whereby QoS for a mobile host should be established is
   currently an active topic of investigation in the IETF.  For existing
   QoS approaches (Diffsrv and Intsrv) preliminary studies have
   indicated that the protocol flows necessary to re-establish QoS in a
   new subnet from scratch can be very time consuming for Mobile IP, and
   other mobility protocols may suffer as well.

ネットワークにおけるモバイルホストとルータの間の重要なQoSプロトコル交換が、モバイルホストのパケットに関する初期のQoS処理を確立するのに必要であるかもしれません。 現在、モバイルホストのためのQoSが設立されるべきである正確なメカニズムはIETFの調査のアクティブな話題です。 既存のQoSアプローチ(DiffsrvとIntsrv)のために、予備的な研究はモバイルIPにおいて、最初から新しいサブネットでQoSを復職させるのに必要なプロトコル流れが非常に時間がかかる場合があって、また、他の移動性プロトコルに苦しむかもしれないのを示しました。

   A method of transferring the mobile host's QoS context from the old
   network to the new could facilitate faster re-establishment of the
   mobile host's QoS treatment on the new subnet.  However, for QoS
   mechanisms that are end-to-end, transferring context at the last hop
   router may be insufficient to completely re-initialize the mobile
   host's QoS treatment, since some number of additional routers in the
   path between the mobile host and corresponding node may also need to
   be involved.

古いネットワークから新しいネットワークまでモバイルホストのQoS文脈を移すメソッドは新しいサブネットでモバイルホストのQoS処理の、より速い再建を容易にするかもしれません。 しかしながら、終わらせる終わりであるQoSメカニズムのために最後のホップルータで文脈を移すのはモバイルホストのQoS処理を完全に再初期化するためには不十分であるかもしれません、また、モバイルホストと対応するノードの間の経路の何らかの数の追加ルータが、かかわる必要があるかもしれないので。

4.2 Interoperability

4.2 相互運用性

   A particular concern for seamless handover is that different Layer 2
   radio protocols may define their own solutions for context transfer.
   There are ongoing efforts within 3GPP [8] and IEEE [9] to define such
   solutions.  These solutions are primarily designed to facilitate the
   transfer of Layer 2-related context over a wired IP network between
   two radio access networks or two radio access points.  However, the
   designs can include extensibility features that would allow Layer 3
   context to be transferred.  Such is the case with [10], for example.

シームレスの引き渡しに関する特別の心配は異なったLayer2ラジオプロトコルが文脈転送のためにそれら自身のソリューションを定義するかもしれないということです。 そのようなソリューションを定義するために、3GPP[8]とIEEE[9]の中に進行中の取り組みがあります。 これらのソリューションは、2つのラジオアクセスネットワークか2つのラジオアクセスポイントの間のワイヤードなIPネットワークの上でLayerの2関連の文脈の転送を容易にするように主として設計されています。 しかしながら、デザインはLayer3文脈が移されるのを許容する伸展性機能を含むことができます。 そのようなものは例えば、[10]があるケースです。

   If Layer 2 protocols were to be widely adopted as an optimization
   measure for Layer 3 context transfer, seamless mobility of a mobile
   host having Layer 2 network interfaces that support multiple radio
   protocols would be difficult to achieve.  Essentially, a gateway or
   translator between Layer 2 protocols would be required, or the mobile
   host would be required to perform a full re-initialization of its
   context transfer-candidate services on the new radio network, if no
   translator were available, in order to hand over a mobile host
   between two access technologies.

Layer2プロトコルがLayer3文脈転送のための最適化測定として広く採用されることであるなら、複数のラジオプロトコルをサポートするLayer2ネットワーク・インターフェースを持っているモバイルホストのシームレスの移動性は達成するのが難しいです。 本質的には、Layer2プロトコルの間のゲートウェイか翻訳者が必要でしょう、またはモバイルホストは新しいラジオ放送網における文脈転送候補サービスの完全な再初期化を実行しなければならないでしょう、どんな翻訳者も手があかないなら、2つのアクセス技術の間のモバイルホストを引き渡すために。

Kempf                        Informational                      [Page 6]

RFC 3374           Context Transfer Problem Statement     September 2002

[6ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   A general Layer 3 context transfer solution may also be useful for
   Layer 2 protocols that do not define their own context transfer
   protocol.  Consideration of this issue is outside the scope of the
   Seamoby Working Group, however, since it depends on the details of
   the particular Layer 2 protocol.

また、一般的なLayer3文脈転送解決もそれら自身の文脈転送プロトコルを定義しないLayer2プロトコルの役に立つかもしれません。 Seamoby作業部会の範囲の外にしかしながら、この問題の考慮が、特定のLayer2プロトコルの詳細によるので、あります。

5.0 Limitations on Context Transfer

文脈における5.0の制限が移されます。

   Context transfer may not always be the best solution for
   re-establishing context transfer-candidate services on a new subnet.
   There are certain limitations on when context transfer may be
   useful. These limitations are discussed in the following subsections.

文脈転送は、いつも新しいサブネットで文脈転送候補サービスを復職させるための最も良いソリューションであるかもしれないというわけではありません。 文脈転送が役に立つかもしれない時ある制限があります。 以下の小区分でこれらの制限について議論します。

5.1 Router Compatibility

5.1 ルータの互換性

   Context transfer between two routers is possible only if the
   receiving router supports the same context transfer-candidate
   services as the sending router.  This does not mean that the two
   nodes are identical in their implementation, nor does it even imply
   that they must have identical capabilities.  A router that cannot
   make use of received context should refuse the transfer.  This
   results in a situation no different than a mobile host handover
   without context transfer, and should not be considered an error or
   failure situation.

受信ルータが、送付ルータとして同じ文脈が転送候補サービスであるとサポートする場合にだけ、2つのルータの間の文脈転送は可能です。 これは、2つのノードがそれらの実装が同じであることを意味しません、そして、それはそれらには同じ能力がなければならないのを含意さえしません。 受信された関係を利用できないルータは転送を拒否するべきです。 これをモバイルホスト引き渡しと文脈転送なしで異なっていない状況をもたらして、誤りか失敗状況であると考えるべきではありません。

5.2 Requirement to Re-initialize Service from Scratch

5.2 最初からサービスを再初期化するという要件

   The primary motivation for context transfer assumes that quickly
   re-establishing the same level of context transfer-candidate service
   on the new subnet is desirable.  And yet, there may be situations
   where either the device or the access network would prefer to
   re-establish or re-negotiate the level of service.  For example, if
   the mobile host crosses administrative domains where the operational
   policies change, negotiation of a different level of service may be
   required.

文脈転送に関するプライマリ動機は、新しいサブネットで同じレベルの文脈転送候補サービスをすばやく復職させるのが望ましいと仮定します。 そして、しかし、状況がデバイスかアクセスネットワークのどちらかがサービスのレベルを復職するか、または再交渉するのを好むところにあるかもしれません。 例えば、モバイルホストが運用政策が変化する管理ドメインを横断するなら、異なったレベルのサービスの交渉が必要であるかもしれません。

5.3 Suitability for the Particular Service

5.3 特定のサービスへの適合

   Context transfer assumes that it is faster to establish the service
   by context transfer rather than from scratch.  This may not be true
   for certain types of service, for example, multicast, "push"
   information services.

文脈転送は、最初からよりむしろ文脈転送でサービスを確立するのがさらに速いと仮定します。 あるタイプのサービス、例えば、マルチキャスト、「プッシュ」情報サービスには、これは本当でないかもしれません。

5.4 Layer 2 Solutions Better

5.4は2つのソリューションをよりよく層にします。

   Context transfer is an enhancement to improve upon the performance of
   a handover for Layer 3 context transfer-candidate services.  Many
   networks provide support for handover at Layer 2, within and between

文脈転送はLayerのための引き渡しの性能のときに3つの文脈転送候補サービスを改良する増進です。 多くのネットワークがLayer2において中、間に引き渡しのサポートを提供します。

Kempf                        Informational                      [Page 7]

RFC 3374           Context Transfer Problem Statement     September 2002

[7ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   subnets.  Layer 3 context transfer may not provide a significant
   improvement over Layer 2 solutions, even for Layer 3 context, if the
   handover is occurring between two subnets supporting the same Layer 2
   radio access technology.

サブネット。 層の3文脈転送はLayerの上のかなりの改善に2つの解決法を提供しないかもしれません、Layer3文脈のためにさえ、同じLayerが2ラジオアクセス技術であるとサポートしながら引き渡しが2つのサブネットの間に起こっているなら。

6.0 Performance Considerations

6.0 パフォーマンス問題

   The purpose of context transfer is to sustain the context
   transfer-candidate services being provided to a mobile host's traffic
   during handover.  It is essentially an enhancement to IP mobility
   that ultimately must result in an improvement in handover
   performance.  A context transfer solution must provide performance
   that is equal to or better than re-initializing the context
   transfer-candidate service between the mobile host and the network
   from scratch.  Otherwise, context transfer is of no benefit.

文脈転送の目的は引き渡しの間にモバイルホストのトラフィックに提供される文脈転送候補サービスを維持することです。それは本質的には結局引き渡し性能における改良をもたらさなければならないIPの移動性への増進です。 文脈転送解決はモバイルホストとネットワークの間では、最初から等しいか、または文脈転送候補サービスを再初期化するより良い性能を提供しなければなりません。 さもなければ、文脈転送は利益の全くものではありません。

7.0 Security Considerations

7.0 セキュリティ問題

   Any context transfer standard must provide mechanism for adequately
   securely the context transfer process, and a recommendation to deploy
   security, as is typically the case for Internet standards.  Some
   general considerations for context transfer security include:

文脈が適切にしっかりと、プロセス、およびセキュリティを配布するという推薦を移す通常ケースのようにどんな文脈管理換え基準もメカニズムをインターネット標準に提供しなければなりません。 文脈転送セキュリティのためのいくつかの一般的な問題は:

   - Information privacy: the context may contain information which the
     end user or network operator would prefer to keep hidden from
     unauthorized viewers.

- 情報プライバシー: 文脈はエンドユーザかネットワーク・オペレータが権限のないビューアーから隠された状態で保つのを好む情報を含むかもしれません。

   - Transfer legitimacy: a false or purposely corrupted context
     transfer could have a severe impact upon the operation of the
     receiving router, and therefore could potentially affect the
     operation of the access network itself.  The potential threats
     include denial of service and theft of service attacks.

- 合法性を移してください: 誤ったかわざわざ崩壊した文脈転送は、受信ルータの操作に厳しい影響を持つことができて、したがって、潜在的にアクセスネットワーク自体の操作に影響するかもしれません。 潜在的な脅威はサービスの否定とサービス攻撃の窃盗を含んでいます。

    - Security preservation: part of the context transfer may include
     information pertinent to a security association established between
     the mobile host and another entity on the network.  For this
     security association to be preserved during handover, the transfer
     of the security context must include the appropriate security
     measures.

- セキュリティ保存: 文脈転送の一部がネットワークにモバイルホストと別の実体の間に設立されたセキュリティ協会に適切な情報を含むかもしれません。 この引き渡しの間に保存されるべきセキュリティ協会に関しては、セキュリティ文脈の転送は適切な安全策を含まなければなりません。

   It is expected that the measures used to secure the transport of
   information between peers (e.g., IPSEC [10]) in an IP network should
   be sufficient for context transfer.  However, given the above
   considerations, there may be reason to provide for additional
   security measures beyond the available IETF solutions.

測定が以前はよく同輩の間の情報の輸送を保証していたと予想されます。(例えば、IPネットワークにおけるIPSEC[10])は文脈転送に十分であるべきです。 しかしながら、上の問題を考えて、利用可能なIETFソリューションを超えて追加セキュリティ対策に備える理由があるかもしれません。

Kempf                        Informational                      [Page 8]

RFC 3374           Context Transfer Problem Statement     September 2002

[8ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   Since context transfer requires a trust relationship between network
   entities, the compromise of only one of the network entities that
   transfer context may be sufficient to reduce the security of the
   whole system, if for example the context transferred includes
   encryption keying material.  When the host moves from the compromised
   network entity to an uncompromised network entity in the presence of
   context transfer, the compromised context may be used to decrypt the
   communication channel.  When context transfer is not used, a
   compromise of only one network entity only gives access to what that
   network entity can see.  When the mobile host moves to an
   uncompromised network entity in the absence of context transfer,
   security can be re-established at the new entity.  However, to the
   extent that context transfer happens primarily between routers, the
   security of context transfer will depend on the security of the
   routers.  Any compromise of security on a router that affects context
   transfer may also lead to other, equally serious disruptions in
   network traffic.

文脈転送がネットワーク実体の間の信頼関係を必要とするので、文脈を移すネットワーク実体の唯一の1つの感染は全体のシステムのセキュリティを下げるために十分であるかもしれません、例えば移された文脈が材料を合わせる暗号化を含んでいるなら。 ホストが文脈転送の面前で感染しているネットワーク実体から非感染しているネットワーク実体まで移行するとき、感染している文脈は、通信チャネルを解読するのに使用されるかもしれません。 文脈転送が使用されていないとき、1つのネットワーク実体だけの感染はそのネットワーク実体が見ることができるものへのアクセスを与えるだけです。 モバイルホストが文脈転送が不在のとき非感染しているネットワーク実体に移行するとき、セキュリティは新しい実体で復職できます。 しかしながら、文脈転送が主としてルータの間で起こるという範囲まで、文脈転送のセキュリティはルータのセキュリティによるでしょう。 また、文脈転送に影響するルータに関するセキュリティのどんな感染もネットワークトラフィックで他の、そして、等しく重大な分裂につながるかもしれません。

   The context transfer investigation must identify any novel security
   measures required for context transfer that exceed the capabilities
   of the existing or emerging IETF solutions.

文脈転送調査は存在かIETFソリューションとして現れる能力を超えている文脈転送に必要である目新しい安全策を特定しなければなりません。

8.0 Recommendations

8.0 推薦

   The following steps are recommended for Seamoby:

以下のステップはSeamobyのために推薦されます:

   - Investigation into candidate router-related services for context
     and an analysis of the transfer requirements for each candidate;

- 文脈のための候補のルータ関連のサービスへの調査と各候補者のための転送要件の分析。

   - The development of a framework and protocol(s) that will support
     the transfer of context between the routing nodes of an IP network.

- IPネットワークのルーティングノードの間の文脈の転送をサポートするフレームワークとプロトコルの開発。

   The context transfer solution must inter-work with existing and
   emerging IP protocols, in particular, those protocols supporting
   mobility in an IP network.

文脈転送解決は存在していて、IPプロトコルとして特に現れるのにIPネットワークで移動性をサポートするそれらのプロトコルを織り込まなければなりません。

9.0 Acknowledgements

9.0 承認

   The editor would like to thank the Seamoby CT design team (listed at
   the end of the document as co-authors), who were largely responsible
   for the initial content of this document, for their hard work, and
   especially Gary Kenward, who shepherded the document through its
   initial versions.

エディタはSeamobyコネチカットデザインチーム(ドキュメントの端では、共著者として記載されている)に感謝したがっています、彼らのきつい仕事、および特にゲーリーKenwardのために。(チームはこのドキュメントの初期の中身に主に責任感が強かったです)。(Kenwardは初期のバージョンを通してドキュメントを守りました)。

Kempf                        Informational                      [Page 9]

RFC 3374           Context Transfer Problem Statement     September 2002

[9ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

10.0 References

10.0の参照箇所

   [1]  Perkins, C., "IP Mobility Support", RFC 3220, January 2002.

[1] パーキンス、C.、「IP移動性サポート」、RFC3220、2002年1月。

   [2]  Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
        Progress.

[2] ジョンソンとD.とC.パーキンス、「IPv6"での移動性サポート、進行中の仕事。」

   [3]  Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

[3]BlunkとL.と1998年のVollbrecht、J.、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。

   [4]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
        1661, July 1994.

[4] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。

   [5]  IEEE Std. P802.1X/D11, "Standard for Port based Network Access
        Control", March 2001.

[5] IEEE Std。 2001年3月の「PortのベースのNetwork Access Controlにおける標準」のP802.1X/D11。

   [6]  Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile
        IP", Work in Progress.

[6] パーキンス、C.、およびP.カルフーン、「モバイルIPのためのAAA登録キー」は進行中で働いています。

   [7]  Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu,
        H., Jonsson, L., Hakenberg, R., Koren T., Le, K., Martensson,
        A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H.
        Zheng, "RObust Header Compression (ROHC): Framework and four
        profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

[7] ボーマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L.、Hakenberg、R.、コーレンT.、Le、K.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 フレームワークと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日

   [8]  3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS
        Domain," 3GPP, March 2001.

[8] 3GPP TR25.936V4.0.0、「PSドメインからリアルタイムで身柄の引き渡し」、3GPP、2001年3月。

   [9]  IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-
        Vendor Access Point Interoperability via an Inter-Access Point
        Protocol Across Distribution Systems Supporting IEEE 802.11
        Operation," July 2001.

[9] IEEE Std。 802.11f/D2.0、「MultiベンダーAccess Point InteroperabilityのためにInter-アクセスPointプロトコルAcross Distribution Systems Supporting IEEE802.11Operationを通してRecommended Practiceを作成してください」、2001年7月。

   [10] Kent, S. and Atkinson, R., "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

[10] ケントとS.とアトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [11] Aboba, B. and M. Moore, "A Model for Context Transfer in IEEE
        802", Work in Progress.

[11] 「IEEE802の文脈転送のためのモデル」というAboba、B.、およびM.ムーアは進行中で働いています。

Kempf                        Informational                     [Page 10]

RFC 3374           Context Transfer Problem Statement     September 2002

[10ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

11.0 Complete List of Authors' Addresses

11.0 作者のアドレスに関する全リスト

   O. Henrik Levkowetz
   A Brand New World
   Osterogatan 1
   S-164 28 Kista
   SWEDEN

O.Henrik Levkowetzはブランド新世界Osterogatan1秒間-164 28Kistaスウェーデンです。

   Phone: +46 8 477 9942
   EMail: henrik@levkowetz.com

以下に電話をしてください。 +46 8 477 9942はメールされます: henrik@levkowetz.com

   Pat R. Calhoun
   Black Storm Networks
   110 Nortech Parkway
   San Jose  CA 95134
   USA

適切なR.カルフーン黒い嵐のネットワーク110Nortech公園道路サンノゼカリフォルニア95134米国

   Phone: +1 408-941-0500
   EMail: pcalhoun@bstormnetworks.com

以下に電話をしてください。 +1 408-941-0500 メールしてください: pcalhoun@bstormnetworks.com

   James Kempf
   NTT DoCoMo USA Laboratories
   181 Metro Drive, Suite 300
   San Jose, CA 95110
   USA

ジェームスケンフNTTドコモ米国研究所181地下鉄ドライブ、Suite300サンノゼ、カリフォルニア95110米国

   Phone: 408-451-4711
   EMail: kempf@docomolabs-usa.com

以下に電話をしてください。 408-451-4711 メールしてください: kempf@docomolabs-usa.com

   Gary Kenward
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2G 6J8
   CANADA

ゲーリーKenwardノーテルは3500縦梁アベニューネピアン、オンタリオK2G 6J8カナダをネットワークでつなぎます。

   Phone: +1 613-765-1437
   EMail: gkenward@nortelnetworks.com

以下に電話をしてください。 +1 613-765-1437 メールしてください: gkenward@nortelnetworks.com

Kempf                        Informational                     [Page 11]

RFC 3374           Context Transfer Problem Statement     September 2002

[11ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   Hamid Syed
   Nortel Networks
   100 Constellation Crescent
   Nepean  Ontario K2G 6J8
   CANADA

ハミドSyedノーテルネットワーク100のConstellationの三日月形ネピアンオンタリオK2G 6J8カナダ

   Phone: +1 613 763-6553
   EMail: hmsyed@nortelnetworks.com

以下に電話をしてください。 +1 613 763-6553 メールしてください: hmsyed@nortelnetworks.com

   Jukka Manner
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 Helsinki
   FINLAND

ヘルシンキ私書箱26(Teollisuuskatu23)フィン-00014ヘルシンキフィンランドのユッカ方法コンピュータサイエンス学部大学

   Phone: +358-9-191-44210
   EMail: jmanner@cs.helsinki.fi

以下に電話をしてください。 +358-9-191-44210 メールしてください: jmanner@cs.helsinki.fi

   Madjid Nakhjiri
   Motorola
   1501 West Shure Drive
   Arlington Heights  IL 60004
   USA

Madjid Nakhjiriモトローラ1501西シュアー・ドライブアーリントンハイツ不-60004米国

   Phone: +1 847-632-5030
   EMail: madjid.nakhjiri@motorola.com

以下に電話をしてください。 +1 847-632-5030 メールしてください: madjid.nakhjiri@motorola.com

   Govind Krishnamurthi
   Communications Systems Laboratory, Nokia Research Center
   5 Wayside Road
   Burlington  MA 01803
   USA

Govind Krishnamurthi通信網研究所、ノキアリサーチセンター5道端の道路バーリントンMA01803米国

   Phone: +1 781 993 3627
   EMail: govind.krishnamurthi@nokia.com

以下に電話をしてください。 +1 3627年の781 993メール: govind.krishnamurthi@nokia.com

Kempf                        Informational                     [Page 12]

RFC 3374           Context Transfer Problem Statement     September 2002

[12ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

   Rajeev Koodli
   Communications Systems Lab, Nokia Research Center
   313 Fairchild Drive
   Mountain View  CA 94043
   USA

Rajeev Koodli通信網研究室、ノキアリサーチセンター313フェアチャイルド・ドライブマウンテンビューカリフォルニア94043米国

   Phone: +1 650 625 2359
   EMail: rajeev.koodli@nokia.com

以下に電話をしてください。 +1 2359年の650 625メール: rajeev.koodli@nokia.com

   Kulwinder S. Atwal
   Zucotto Wireless Inc.
   Ottawa  Ontario K1P 6E2
   CANADA

KulwinderのAtwal Zucottoの無線の株式会社オタワオンタリオS.K1P6の2Eのカナダ

   Phone: +1 613 789 0090
   EMail: kulwinder.atwal@zucotto.com

以下に電話をしてください。 +1 0090年の613 789メール: kulwinder.atwal@zucotto.com

   Michael Thomas
   Cisco Systems
   375 E Tasman Rd
   San Jose  CA 95134
   USA

マイケルトーマスシスコシステムズ375Eのタスマン・サンノゼ第カリフォルニア95134米国

   Phone: +1 408 525 5386
   EMail: mat@cisco.com

以下に電話をしてください。 +1 5386年の408 525メール: mat@cisco.com

   Mat Horan
   COM DEV Wireless Group
   San Luis Obispo  CA 93401
   USA

ホランCOM DEVの無線のグループサンルイスオビスポカリフォルニア93401米国をもつれさせてください。

   Phone: +1 805 544 1089
   EMail: mat.horan@comdev.cc

以下に電話をしてください。 +1 1089年の805 544メール: mat.horan@comdev.cc

   Phillip Neumiller
   3Com Corporation
   1800 W. Central Road
   Mount Prospect  IL 60056
   USA

フィリップNeumiller 3Com社1800のW.の中央の道路マウントプロスペクト不-60056米国

   EMail: phil_neumiller@3com.com

メール: phil_neumiller@3com.com

Kempf                        Informational                     [Page 13]

RFC 3374           Context Transfer Problem Statement     September 2002

[13ページ]RFC3374文脈移転問題声明2002年9月の情報のケンフ

12.0 Full Copyright Statement

12.0 完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 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 assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

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

Kempf                        Informational                     [Page 14]

ケンフInformationalです。[14ページ]