RFC3210 日本語訳

Network Working Group                                         D. Awduche
Request for Comments: 3210                                Movaz Networks
Category: Informational                                       A.  Hannan
                                                             Routingloop
                                                                 X. Xiao
                                                                Photuris
                                                           December 2001

Awducheがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3210Movazはカテゴリをネットワークでつなぎます: 情報のA.ハナンRoutingloop X.Xiao Photuris2001年12月

     Applicability Statement for Extensions to RSVP for LSP-Tunnels

LSP-TunnelsのためのRSVPへの拡大のための適用性証明

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

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

Abstract

要約

   This memo discusses the applicability of "Extensions to RSVP
   (Resource ReSerVation Protocol) for LSP Tunnels".  It highlights the
   protocol's principles of operation and describes the network context
   for which it was designed.  Guidelines for deployment are offered and
   known protocol limitations are indicated.  This document is intended
   to accompany the submission of "Extensions to RSVP for LSP Tunnels"
   onto the Internet standards track.

このメモは「LSP TunnelsのためのRSVP(資源予約プロトコル)への拡大」の適用性について議論します。 それは、プロトコルの操作の原則を強調して、設計されたネットワーク文脈について説明します。 展開のためのガイドラインを提供します、そして、知られているプロトコル制限を示します。 このドキュメントが「LSP TunnelsのためのRSVPへの拡大」のインターネット標準化過程への服従に伴うことを意図します。

1.0 Introduction

1.0 序論

   Service providers and users have indicated that there is a great need
   for traffic engineering capabilities in IP networks.  These traffic
   engineering capabilities can be based on Multiprotocol Label
   Switching (MPLS) and can be implemented on label switching routers
   (LSRs) from different vendors that interoperate using a common
   signaling and label distribution protocol.  A description of the
   requirements for traffic engineering in MPLS based IP networks can be
   found in [2].  There is, therefore, a requirement for an open, non-
   proprietary, standards based signaling and label distribution
   protocol for the MPLS traffic engineering application that will allow
   label switching routers from different vendors to interoperate.

サービスプロバイダーとユーザは、IPネットワークには交通工学能力のすばらしい必要があるのを示しました。 一般的なシグナリングとラベル分配プロトコルを使用することでこれらの交通工学能力は、Multiprotocol Label Switching(MPLS)に基づくことができて、ラベル切り換えルータ(LSRs)で共同利用する異なったベンダーから実装することができます。 [2]でMPLSのベースのIPネットワークにおける交通工学のための要件の記述を見つけることができます。 したがって、ベースのシグナリングとラベル分配が異なったベンダーからのラベル切り換えルータが共同利用するMPLS交通工学アプリケーションのために議定書の中で述べる開いていて、非独占である規格のための要件があります。

   The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1]
   was developed by the IETF MPLS working group to address this
   requirement.  RSVP-TE is a composition of several related proposals

「LSPトンネルへのRSVPへの拡大」(RSVP-TE)仕様[1]は、この要件を扱うためにIETF MPLSワーキンググループによって開発されました。 RSVP-TEはいくつかの関連する提案の構成です。

Awduche, et. al.             Informational                      [Page 1]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[1ページ]のRFC3210適用性証明

   submitted to the IETF MPLS working group.  It contains all the
   necessary objects, packet formats, and procedures required to
   establish and maintain explicit label switched paths (LSPs).
   Explicit LSPs are foundational to the traffic engineering application
   in MPLS based IP networks.  Besides the traffic engineering
   application, the RSVP-TE specification may have other uses within the
   Internet.

IETF MPLSワーキンググループに提出します。 それは明白なラベルの切り換えられた経路(LSPs)を設立して、維持するのに必要であるすべての必要なオブジェクト、パケット・フォーマット、および手順を含んでいます。 明白なLSPsはMPLSのベースのIPネットワークで交通工学アプリケーションに基礎的です。 交通工学アプリケーション以外に、RSVP-TE仕様はインターネットの中に他の用途を持っているかもしれません。

   This memo describes the applicability of the RSVP-TE specifications
   [1].  The protocol's principles of operation are highlighted, the
   network context for which it was developed is described, guidelines
   for deployment are offered, and known protocol limitations are
   indicated.

このメモはRSVP-TE仕様[1]の適用性について説明します。 プロトコルの操作の原則を強調します、そして、それが開発されたネットワーク文脈について説明します、そして、展開のためのガイドラインを提供します、そして、知られているプロトコル制限を示します。

   This applicability statement concerns only the use of RSVP to set up
   unicast LSP-tunnels.  It is noted that not all of the features
   described in RFC2205 [3] are required to support the instantiation
   and maintenance of LSP-tunnels.  Aspects related to the support of
   other features and capabilities of RSVP by an implementation that
   also supports LSP-tunnels are beyond the scope of this document.
   However, support of such additional features and capabilities should
   not introduce new security vulnerabilities in environments that only
   use RSVP to set up LSP-tunnels.

この適用性証明は、RSVPの使用だけがユニキャストLSP-トンネルを設立するのが関係があります。 RFC2205[3]で説明された特徴のすべてがLSP-トンネルの具体化とメインテナンスをサポートするのに必要であるというわけではないことに注意されます。 他の特徴のサポートに関連する局面とまた、LSP-トンネルを支える実装によるRSVPの能力はこのドキュメントの範囲を超えています。 しかしながら、そのような付加的な機能と能力のサポートはLSP-トンネルを設立するのにRSVPを使用するだけである環境における新しいセキュリティの脆弱性を導入するべきではありません。

   This applicability statement does not preclude the use of other
   signaling and label distribution protocols for the traffic
   engineering application in MPLS based networks.  Service providers
   are free to deploy whatever signaling protocol that meets their
   needs.

この適用性証明はMPLSのベースのネットワークで他のシグナリングとラベル分配プロトコルの交通工学アプリケーションの使用を排除しません。 サービスプロバイダーは自由にそれが満たすどんなシグナリングプロトコルにも彼らの必要性を配布することができます。

   In particular, CR-LDP [6] and RSVP-TE [1] are two signaling protocols
   that perform similar functions in MPLS networks.  There is currently
   no consensus on which protocol is technically superior.  Therefore,
   network administrators should make a choice between the two based
   upon their needs and particular situation.

CR-自由民主党[6]とRSVP-TE[1]は特に、MPLSネットワークで同様の機能を実行する2つのシグナリングプロトコルです。 現在、プロトコルが技術的に優れているコンセンサスが全くありません。 したがって、ネットワーク管理者は彼らの必要性と特定の状況のベースの2の選択をするべきです。

2.0 Technical Overview of Extensions to RSVP for LSP Tunnels

2.0 LSP TunnelsのためのRSVPへの拡大の技術的な概要

   The RSVP-TE specification extends the original RSVP protocol by
   giving it new capabilities that support the following functions in an
   MPLS domain:

RSVP-TE仕様はMPLSドメインで以下の機能をサポートする新しい能力をそれに与えることによって、オリジナルのRSVPプロトコルを広げています:

     (1) downstream-on-demand label distribution
     (2) instantiation of explicit label switched paths
     (3) allocation of network resources (e.g., bandwidth) to
         explicit LSPs
     (4) rerouting of established LSP-tunnels in a smooth fashion
         using the concept of make-before-break

(1) 明白なラベルの川下要求次第のラベル分配(2)具体化は、滑らかなファッションで確立したLSP-トンネルのコースを変更しながら、以前開閉していることの概念を使用することでネットワーク資源(例えば、帯域幅)の経路(3)配分を明白なLSPs(4)に切り換えました。

Awduche, et. al.             Informational                      [Page 2]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[2ページ]のRFC3210適用性証明

     (5) tracking of the actual route traversed by an LSP-tunnel
     (6) diagnostics on LSP-tunnels
     (7) the concept of nodal abstraction
     (8) preemption options that are administratively controllable

(7) (5) LSP-トンネルの上でLSP-トンネル(6)病気の特徴によって横断された実際のルートを追跡するのは、行政上制御可能なこぶのような抽象化(8)先取りオプションの概念です。

   The RSVP-TE specification introduces several new RSVP objects,
   including the LABEL-REQUEST object, the RECORD-ROUTE object, the
   LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects.
   New error messages are defined to provide notification of exception
   conditions.  All of the new objects defined in RSVP-TE are optional
   with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL
   objects, which are both mandatory for the establishment of LSP-
   tunnels.

RSVP-TE仕様は数個の新しいRSVPオブジェクトを導入します、LABEL-REQUESTオブジェクト、RECORD-ROUTEオブジェクト、LABELオブジェクト、EXPLICIT-ROUTEオブジェクト、および新しいSESSIONオブジェクトを含んでいて。 新しいエラーメッセージは、例外条件の通知を提供するために定義されます。 RSVP-TEで定義された新しいオブジェクトのすべてがRSVPプロトコルに関して任意です、LABEL-REQUESTとLABELオブジェクトを除いて。(オブジェクトはともにLSPトンネルの設立に義務的です)。

   Two fundamental aspects distinguish the RSVP-TE specification [1]
   from the original RSVP protocol [3].

2つの基本的な面がオリジナルのRSVPプロトコル[3]とRSVP-TE仕様[1]を区別します。

   The first distinguishing aspect is the fact that the RSVP-TE
   specification [1] is intended for use by label switching routers (as
   well as hosts) to establish and maintain LSP-tunnels and to reserve
   network resources for such LSP-tunnels.  The original RSVP
   specification [3], on the other hand, was intended for use by hosts
   to request and reserve network resources for micro-flows.

最初の区別局面はRSVP-TE仕様[1]がルータ(ホストと同様に)を切り換えるラベルによる使用のためにLSP-トンネルを確立して、維持して、そのようなLSP-トンネルへのネットワーク資源を予約することを意図するという事実です。 他方では、当初のRSVP仕様[3]は使用のためにマイクロ流れのための要求するホストと蓄えのネットワーク資源で意図しました。

   The second distinguishing aspect is the fact that the RSVP-TE
   specification generalizes the concept of "RSVP flow." The RSVP-TE
   specification essentially allows an RSVP session to consist of an
   arbitrary aggregation of traffic (based on local policies) between
   the originating node of an LSP-tunnel and the egress node of the
   tunnel.  To be definite, in the original RSVP protocol [3], a session
   was defined as a data flow with a particular destination and
   transport layer protocol.  In the RSVP-TE specification, however, a
   session is implicitly defined as the set of packets that are assigned
   the same MPLS label value at the originating node of an LSP-tunnel.
   The assignment of labels to packets can be based on various criteria,
   and may even encompass all packets (or subsets thereof) between the
   endpoints of the LSP-tunnel.  Because traffic is aggregated, the
   number of LSP-tunnels (hence the number of RSVP sessions) does not
   increase proportionally with the number of flows in the network.
   Therefore, the RSVP-TE specification [1] addresses a major scaling
   issue with the original RSVP protocol [3], namely the large amount of
   system resources that would otherwise be required to manage
   reservations and maintain state for potentially thousands or even
   millions of RSVP sessions at the micro-flow granularity.

局面を区別する秒はRSVP-TE仕様が「RSVP流動」の概念を広めるという事実です。 RSVP-TE仕様で、RSVPセッションはLSP-トンネルの起因するノードとトンネルの出口ノードの間でトラフィックの任意の集合から本質的には成ります(ローカルの方針に基づいています)。 オリジナルのRSVPプロトコル[3]で明確に、なるように、セッションは特定の目的地とトランスポート層プロトコルでデータフローと定義されました。 しかしながら、RSVP-TE仕様では、セッションはそれとなくLSP-トンネルの起因するノードにおける同じMPLSラベル価値が割り当てられるパケットのセットと定義されます。 パケットへのラベルの課題は、様々な評価基準に基づくことができて、LSP-トンネルの終点の間のすべてのパケット(または、それの部分集合)を取り囲みさえするかもしれません。 トラフィックが集められるので、ネットワークの流れの数に従って、LSP-トンネル(したがって、RSVPセッションの数)の数は比例して増加しません。 したがって、RSVP-TE仕様[1]はオリジナルのRSVPプロトコル[3](すなわち、潜在的に数千か何百万ものRSVPセッションのためにマイクロ流れ粒状で予約を管理して、状態を維持するのに別の方法で必要である多量のシステム資源)の主要なスケーリング問題を扱います。

   The reader is referred to [1] for a technical description of the
   RSVP-TE protocol specification.

読者はRSVP-TEプロトコル仕様の専門的説明のための[1]を参照されます。

Awduche, et. al.             Informational                      [Page 3]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[3ページ]のRFC3210適用性証明

3.0 Applicability of Extensions to RSVP for LSP Tunnels

3.0 LSP TunnelsのためのRSVPへの拡大の適用性

   Use of RSVP-TE is appropriate in contexts where it is useful to
   establish and maintain explicit label switched paths in an MPLS
   network.  LSP-tunnels may be instantiated for measurement purposes
   and/or for routing control purposes.  They may also be instantiated
   for other administrative reasons.

RSVP-TEの使用はMPLSの切り換えられた経路がネットワークでつなぐ明白なラベルを設立して、維持するのが役に立つ文脈で適切です。 LSP-トンネルは測定目的ルーティング管理目的のために例示されるかもしれません。 また、それらは他の管理理由で例示されるかもしれません。

   For the measurement application, an LSP-tunnel can be used to capture
   various path statistics between its endpoints.  This can be
   accomplished by associating various performance management and fault
   management functions with an LSP-tunnel, such as packet and byte
   counters.  For example, an LSP-tunnel can be instantiated, with or
   without bandwidth allocation, solely for the purpose of monitoring
   traffic flow statistics between two label switching routers.

測定アプリケーションにおいて、終点の間の様々な経路統計を得るのにLSP-トンネルを使用できます。 様々なパフォーマンス管理と障害管理機能をLSP-トンネルに関連づけることによって、これを達成できます、パケットとバイトカウンタなどのように。 例えば、LSP-トンネルを例示できます、帯域幅配分のあるなしにかかわらず、唯一2つのラベル切り換えルータの間の交通の流れ統計をモニターする目的のために。

   For the routing control application, LSP-tunnels can be used to
   forward subsets of traffic through paths that are independent of
   routes computed by conventional Interior Gateway Protocol (IGP)
   Shortest Path First (SPF) algorithms.  This feature introduces
   significant flexibility into the routing function and allows policies
   to be implemented that can result in the performance optimization of
   operational networks.  For example, using LSP-tunnels, traffic can be
   routed away from congested network resources onto relatively
   underutilized ones.  More generally, load balancing policies can be
   actualized that increase the effective capacity of the network.

ルーティング制御アプリケーションにおいて、従来のInteriorゲートウェイプロトコル(IGP)の最も短いPath First(SPF)アルゴリズムによって計算されたルートから独立している経路を通してトラフィックの部分集合を送るのにLSP-トンネルを使用できます。この特徴は、重要な柔軟性を経路選択機能に取り入れて、性能をもたらすことができる実施される政策に操作上のネットワークの最適化を許容します。 例えば、使用しているLSP-トンネルであり混雑しているネットワーク資源から遠くにトラフィックを発送できます。比較的underutilizedされたものに。 より一般に、ネットワークの有効能力を増強するロードバランシング方針は顕在化できます。

   To further enhance the control application, RSVP-TE may be augmented
   with an ancillary constraint-based routing entity.  This entity may
   compute explicit routes based on certain traffic attributes, while
   taking network constraints into account.  Additionally, IGP link
   state advertisements may be extended to propagate new topology state
   information.  This information can be used by the constraint-based
   routing entity to compute feasible routes.  Furthermore, the IGP
   routing algorithm may itself be enhanced to take pre-established
   LSP-tunnels into consideration while building the routing table.  All
   these augmentations are useful, but not mandatory.  In fact, the
   RSVP-TE specification may be deployed in certain contexts without any
   of these additional components.

さらに制御アプリケーションを機能アップするために、RSVP-TEは付属の規制ベースのルーティング実体で増大するかもしれません。 この実体はネットワーク規制を考慮に入れている間にあるトラフィック属性に基づく明白なルートを計算するかもしれません。 さらに、IGPリンク州の広告は、新しいトポロジー州の情報を伝播するために広げられるかもしれません。 この情報は規制ベースのルーティング実体によって使用されて、可能なルートを計算できます。 その上、IGPルーティング・アルゴリズムがそうするかもしれない、それ自体、高められて、経路指定テーブルを組立てている間、プレ確立したLSP-トンネルを考慮に入れてください。 これらのすべての増大が、役に立ちますが、義務的であるというわけではありません。 事実上、RSVP-TE仕様はある文脈でこれらの追加コンポーネントのいずれなしでも配布されるかもしれません。

   The capability to monitor point to point traffic statistics between
   two routers and the capability to control the forwarding paths of
   subsets of traffic through a given network topology together make the
   RSVP-TE specifications applicable and useful for traffic engineering
   within service provider networks.

2つのルータの間のトラフィック統計を指すためにポイントをモニターする能力と与えられたネットワーク形態を通してトラフィックの部分集合の推進経路を一緒に制御する能力で、サービスプロバイダーネットワークの中で交通工学に適切であって、RSVP-TE仕様の役に立ちます。

   These capabilities also make the RSVP-TE applicable, in some
   contexts, as a component of an MPLS based VPN provisioning framework.

これらの能力で、また、MPLSの部品がフレームワークに食糧を供給するVPNを基礎づけたので、RSVP-TEはいくつかの文脈で適切になります。

Awduche, et. al.             Informational                      [Page 4]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[4ページ]のRFC3210適用性証明

   It is significant that the MPLS architecture [4] states clearly that
   no single label distribution protocol is assumed for the MPLS
   technology.  Therefore, as noted in the introduction, this
   applicability statement does not (and should not be construed to)
   prevent a label switching router from implementing other signaling
   and label distribution protocols that also support establishment of
   explicit LSPs and traffic engineering in MPLS networks.

MPLSアーキテクチャ[4]が、どんなただ一つのラベル分配プロトコルもMPLS技術のために想定されないと明確に述べるのは、重要です。 そして、したがって、この適用性証明が序論に述べられるように述べられない、(解釈するべきでない、)、ラベル切り換えルータが、他のシグナリングとラベル分配がまた、MPLSネットワークで明白なLSPsと交通工学の確立をサポートするプロトコルであると実装するのを防いでください。

4.0 Deployment and Policy Considerations

4.0 展開と方針問題

   When deploying RSVP-TE, there should be well defined administrative
   policies governing the selection of nodes that will serve as
   endpoints for LSP-tunnels.  Furthermore, when devising a virtual
   topology for LSP-tunnels, special consideration should be given to
   the tradeoff between the operational complexity associated with a
   large number of LSP-tunnels and the control granularity that large
   numbers of LSP-tunnels allow.  Stated otherwise, a large number of
   LSP-tunnels allows greater control over the distribution of traffic
   across the network, but increases network operational complexity.  In
   large networks, it may be advisable to start with a simple LSP-tunnel
   virtual topology and then introduce additional complexity based on
   observed or anticipated traffic flow patterns.

RSVP-TEを配布するとき、LSP-トンネルへの終点として機能するノードの品揃えを治めるよく定義された施政方針があるべきです。 LSP-トンネルに仮想のトポロジーについて工夫するとき、その上、多くのLSP-トンネルに関連している操作上の複雑さと多くのLSP-トンネルが許容するコントロール粒状の間で特別の配慮を見返りに与えるべきです。 LSP-トンネルの述べられたそうでない多くがネットワークの向こう側にトラフィックの分配の、より大きいコントロールを許しますが、増加は操作上の複雑さをネットワークでつなぎます。 大きいネットワークでは、簡単なLSP-トンネル仮想のトポロジーから始めて、次に、観測されたか予期されたトラフィックフローパターンに基づく追加複雑さを導入するのは賢明であるかもしれません。

   Administrative policies may also guide the amount of bandwidth to be
   allocated (if any) to each LSP-tunnel.  Policies of this type may
   take into consideration empirical traffic statistics derived from the
   operational network in addition to other factors.

また、施政方針は(もしあれば)各LSP-トンネルに割り当てられる帯域幅の量を誘導するかもしれません。 このタイプの方針は他の要素に加えて操作上のネットワークから得られた実証的なトラフィック統計を考慮に入れるかもしれません。

5.0 Limitations

5.0 制限

   The RSVP-TE specification supports only unicast LSP-tunnels.
   Multicast LSP-tunnels are not supported.

RSVP-TE仕様はユニキャストLSP-トンネルだけを支えます。 マルチキャストLSP-トンネルは支えられません。

   The RSVP-TE specification supports only unidirectional LSP-tunnels.
   Bidirectional LSP-tunnels are not supported.

RSVP-TE仕様は、唯一の単方向がLSP-トンネルであるとサポートします。 双方向のLSP-トンネルは支えられません。

   The soft state nature of RSVP remains a source of concern because of
   the need to generate refresh messages periodically to maintain the
   state of established LSP-tunnels.  This issue is addressed in several
   proposals that have been submitted to the RSVP working group (see
   e.g. [5]).

生む必要性のために重要なソースが定期的に状態を維持するメッセージをリフレッシュするRSVPの残りの軟性国家本質はLSP-トンネルを確立しました。 この問題はRSVPワーキンググループに提出されたいくつかの提案で扱われます。(例えば、[5])を見てください。

6.0 Conclusion

6.0 結論

   The applicability of the "Extensions to RSVP for LSP Tunnels"
   specification has been discussed in this document.  The specification
   introduced several enhancements to the RSVP protocol, which make it

本書では「LSP TunnelsのためのRSVPへの拡大」仕様の適用性について議論しました。 仕様はRSVPプロトコルへのいくつかの増進を導入しました。(増進はそれを作ります)。

Awduche, et. al.             Informational                      [Page 5]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[5ページ]のRFC3210適用性証明

   applicable in contexts in which the original RSVP protocol would have
   been inappropriate.  One context in which the RSVP-TE specification
   is particularly applicable is in traffic engineering in MPLS based IP
   networks.

オリジナルのRSVPプロトコルが不適当である文脈では、適切です。 MPLSのベースのIPネットワークにはRSVP-TE仕様が特に適切である1つの文脈が交通工学にあります。

7.0 Security Considerations

7.0 セキュリティ問題

   This document does not introduce new security issues.  The RSVP-TE
   specification adds new opaque objects to RSVP.  Therefore, the
   security considerations pertaining to the original RSVP protocol
   remain relevant.  When deployed in service provider networks, it is
   mandatory to ensure that only authorized entities are permitted to
   initiate establishment of LSP-tunnels.

このドキュメントは新しい安全保障問題を紹介しません。 RSVP-TE仕様は新しい不透明なオブジェクトをRSVPに加えます。 したがって、オリジナルのRSVPプロトコルに関係するセキュリティ問題は関連していたままで残っています。 使用中のプロバイダーネットワークであると配布されると、権限のある機関だけがLSP-トンネルの設立を開始することが許可されているのを保証するのは義務的です。

8.0 Acknowledgments

8.0 承認

   The authors gratefully acknowledge the useful comments received from
   the following individuals during initial review of this memo in the
   MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow.

作者は、役に立つコメントがMPLS WGメーリングリストにおける、このメモの初期のレビューの間以下の個人から受信されたと感謝して認めます: エリック・グレー、ジョン・レンウィック、およびジョージは飲み込みます。

9.0 References

9.0の参照箇所

   [1]   Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
         Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC
         3209, December 2001.

[1]Awduche、D.、バーガー、L.、ガン、D.、李、T.、ツバメ、G.、およびV.Srinivasan、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。

   [2]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
         McManus, "Requirements for Traffic Engineering Over MPLS," RFC
         2702, September 1999.

[2]AwducheとD.、マルコムとJ.とAgogbuaとJ.とオデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。

   [3]   Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
         Specification", RFC 2205, September 1997.

[3] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1、機能的な仕様」、RFC2205、1997年9月。

   [4]   Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
         Architecture for MPLS", RFC 3031, January 2001.

[4] ローゼンとE.とViswanathanとA.とR.Callon、「MPLSのための提案されたアーキテクチャ」、RFC3031、2001年1月。

   [5]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
         Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
         2961, April 2001.

[5]バーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュします」、RFC2961、2001年4月。

   [6]   Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP,"
         Work in Progress.

[6]Jamoussi、B.他、「自由民主党を使用する規制ベースのLSPセットアップ」、ProgressのWork。

Awduche, et. al.             Informational                      [Page 6]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[6ページ]のRFC3210適用性証明

10.0 Authors' Addresses

10.0 作者のアドレス

   Daniel O. Awduche
   Movaz Networks
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102

ダニエルO.Awduche Movazはヴァージニア 7926年のジョーンズ支店Drive、Suite615マクリーン、22102をネットワークでつなぎます。

   EMail: awduche@movaz.com
   Voice: +1 703-298-5291

メール: awduche@movaz.com 声: +1 703-298-5291

   Alan Hannan
   RoutingLoop
   112 Falkirk Court
   Sunnyvale, CA 94087

アランハナンRoutingLoop112フォルカーク法廷サニーベル、カリフォルニア 94087

   EMail: alan@routingloop.com
   Voice: +1 408 666-2326

メール: alan@routingloop.com 声: +1 408 666-2326

   XiPeng Xiao
   Photuris Inc.
   2025 Stierlin Ct.
   Mountain View, CA 94043

XiPeng Xiao Photuris2025年の株式会社ステアリンCt。 マウンテンビュー、カリフォルニア 94043

   EMail: xxiao@photuris.com
   Voice: +1 650-919-3215

メール: xxiao@photuris.com 声: +1 650-919-3215

Awduche, et. al.             Informational                      [Page 7]

RFC 3210        Applicability Statement for Extensions     December 2001

et Awduche、アル。 拡大2001年12月のための情報[7ページ]のRFC3210適用性証明

11.0  Full Copyright Statement

11.0 完全な著作権宣言文

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

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

Awduche, et. al.             Informational                      [Page 8]

et Awduche、アル。 情報[8ページ]