Network Working Group D. Awduche
Request for Comments: 3210 Movaz Networks
Category: Informational A. Hannan
Routingloop
X. Xiao
Photuris
December 2001
Applicability Statement for Extensions to RSVP for LSP-Tunnels
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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トンネルのためのRSVPへの拡張（リソース予約プロトコル）」の適用可能性を論じています。これは、操作のプロトコルの原則を強調し、それが設計されたネットワークの状況を説明しています。展開のためのガイドラインが提供され、既知のプロトコルの制限が示されています。この文書は、インターネット標準トラックに「LSPトンネルのためのRSVPへの拡張」の提出を同行することを意図しています。
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ネットワークにおけるトラフィックエンジニアリング機能のための大きい必要性があることを示しています。これらのトラフィックエンジニアリング機能は、マルチプロトコルラベルスイッチング（MPLS）をベースとすることができ、一般的なシグナリングとラベル配布プロトコルを使用して相互運用異なるベンダーからルータ（LSRのを）ラベルスイッチングに実装することができます。 MPLSベースのIPネットワークにおけるトラフィックエンジニアリングのための要件の説明は、[2]に記載されています。異なるベンダーからラベルスイッチングルータを相互運用することを可能にする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 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.
「LSPトンネルのためのRSVPの拡張」（RSVP-TE）仕様は、この要求に対処するために、IETF MPLSワーキンググループによって開発された[1]しました。 RSVP-TEは、IETF MPLSワーキンググループに提出し、関連するいくつかの提案の組成物です。これは、明示的なラベルを確立し、維持するために必要なすべてのオブジェクト、パケットフォーマット、および手順は、スイッチパス（LSP）が含まれています。明示的なLSPは、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-トンネルを設定します。 LSP-トンネルのインスタンス化とメンテナンスをサポートするために必要とされない[3] RFC2205に記載された特徴の全てことに留意されたいです。また、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-LDP [6]、RSVP-TE [1] MPLSネットワークで同様の機能を実行する2つのシグナリングプロトコルです。プロトコルは、技術的に優れている上でコンセンサスが現在ありません。そのため、ネットワーク管理者は、自分のニーズや特定の状況に基づいて、2つの間の選択をする必要があります。
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〜（4）スムーズで確立LSP-トンネルの再ルーティングの概念を使用してのパス（3）割当を切り替えますメイク前にブレーク
(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
管理制御可能なノードの抽象化（6）LSP-トンネルの診断（7）概念LSPトンネルによって横断実際の経路の（5）トラッキング（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オブジェクトを、導入します。新しいエラーメッセージは、例外条件の通知を提供するために定義されています。 RSVP-TEで定義された新しいオブジェクトの全ては、LSP-トンネルの確立のために必須共にLABEL-REQUESTとLABELオブジェクトを除いて、RSVPプロトコルに関しては任意です。
Two fundamental aspects distinguish the RSVP-TE specification [1] from the original RSVP protocol [3].
二つの基本的な側面は、元のRSVPプロトコル[3]から[1] RSVP-TEの仕様を区別する。
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.
最初区別態様[1]はRSVP-TE仕様は（ホストと同様）ラベルスイッチングルータで使用するために意図されているという事実を確立及び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]と呼ばれます。
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トンネルは、単独で両ラベルスイッチングルータ間のトラフィックフローの統計情報を監視するために、帯域幅割り当ての有無にかかわらず、インスタンス化することができます。
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.
ルーティング制御アプリケーションのために、LSP-トンネルは、従来のインテリアゲートウェイプロトコル（IGP）最短パス優先（SPF）アルゴリズムによって計算された経路とは無関係である経路を通過するトラフィックのサブセットを転送するために使用することができます。この機能は、ルーティング機能に大きな柔軟性を紹介し、政策が運用ネットワークのパフォーマンスの最適化につながることができる実装することができます。例えば、LSP-トンネルを使用して、トラフィックが比較的十分に活用されていないものの上に混雑したネットワーク資源から離して配線することができます。より一般的には、ロード・バランシング・ポリシーは、ネットワークの有効容量を増やすこと実現することができます。
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を適用します。
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.
[4] MPLSアーキテクチャは、単一のラベル配布プロトコルは、MPLS技術のために想定されていないことを明確に述べていることは重要です。冒頭で述べたようにそのため、この適用性声明にはありません（とすると解釈されるべきではない）も、MPLSネットワークで明示的なLSPの確立とトラフィックエンジニアリングをサポートする他のシグナリングとラベル配布プロトコルを実装からラベルスイッチングルータを防ぎます。
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トンネルに（もしあれば）割り当てられる帯域幅の量を導くことができます。このタイプのポリシーは、他の要因に加えて、運用ネットワークから得られる対価経験的なトラフィック統計にかかる場合があります。
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]を参照）に提出されているいくつかの提案で扱われています。
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 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.
仕様「LSPトンネルのためのRSVPへの拡張」の適用は、この文書で説明されています。仕様では、オリジナルのRSVPプロトコルが不適切であったであろうした状況では、それが適用可能にRSVPプロトコルにいくつかの拡張機能を導入しました。 RSVP-TEの仕様は特に適用可能であるものでコンテキストは、MPLSベースのIPネットワークにおけるトラフィックエンジニアリングです。
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 - トンネルの確立を開始することが許可されることを保証するために必須です。
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メーリングリストでこのメモの最初のレビュー時に以下の個人から受け取った有益なコメントを認めます。
[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.スリニバサン、 "RSVP-TE：ExtensionsをLSPトンネルのためのRSVPに" RFC 3209、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のための要件、" RFC 2702、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機能仕様"、RFC 2205、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のために提案されたアーキテクチャ"、RFC 3031、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.、Tommasi、F.及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[6] Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP," Work in Progress.
[6] Jamoussi、B.ら、 "LDPを使用して、制約ベースLSPセットアップ、" 進行中の作業。
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
ダニエルO. Awduche Movazネットワーク7926ジョーンズ支店ドライブ、スイート615マクリーン、VA 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
アラン・阪南RoutingLoop 112フォルカーク裁判所サニーベール、CA 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シャオPhoturis株式会社2025 StierlinのCt。マウンテンビュー、CA 94043
EMail: xxiao@photuris.com Voice: +1 650-919-3215
電子メール：xxiao@photuris.com声：+1 650-919-3215
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。