[要約] RFC 3210は、RSVPのLSP-Tunnelsへの拡張の適用性に関する文書であり、LSP-Tunnelsの使用に関するガイドラインを提供します。目的は、RSVPを使用してLSP-Tunnelsを設定する際の問題や制約を明確にし、ネットワークエンジニアに役立つ情報を提供することです。
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
LSP-TunnelsのRSVPへの拡張の適用性ステートメント
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.
Copyright（c）The Internet Society（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）仕様[1]は、この要件に対処するためにIETF MPLSワーキンググループによって開発されました。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.
このアプリケーションステートメントは、Unicast LSP-TunnelsをセットアップするためのRSVPの使用のみに関するものです。RFC2205 [3]で説明されているすべての機能が、LSPタンネルのインスタンス化とメンテナンスをサポートする必要があるわけではないことに注意してください。LSPタンネルもサポートする実装による他の機能とRSVPの機能のサポートに関連する側面は、このドキュメントの範囲を超えています。ただし、このような追加機能と機能のサポートは、RSVPのみを使用してLSP-Tunnelsをセットアップする環境に新しいセキュリティの脆弱性を導入するものではありません。
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）明示的なラベルスイッチされたパス（3）ネットワークリソースの割り当て（帯域幅など）のインスタンス化（4）メイクの概念を使用して、確立されたLSPタンネルのスムーズな方法での再ルーティング - ブレイク前
(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
(5) LSP-Tunnel（6）LSP-Tunnelsの診断によって横断される実際のルートの追跡
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で定義されているすべての新しいオブジェクトは、RSVPプロトコルに関してオプションです。ただし、LSP-Tunnelsの確立に必須のラベルリクエストとラベルオブジェクトを除きます。
Two fundamental aspects distinguish the RSVP-TE specification [1] from the original RSVP protocol [3].
2つの基本的な側面は、RSVP-TE仕様[1]を元のRSVPプロトコル[3]と区別します。
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.
2番目の際立った側面は、RSVP-TE仕様が「RSVPフロー」の概念を一般化するという事実です。RSVP-TE仕様により、RSVPセッションは、LSPトンネルの発生ノードとトンネルの出口ノードの間のトラフィックの任意の集約（ローカルポリシーに基づく）で構成されます。明確にするために、元のRSVPプロトコル[3]では、セッションは特定の宛先および輸送層プロトコルを備えたデータフローとして定義されました。ただし、RSVP-TE仕様では、セッションは、LSPタンネルの発信ノードで同じMPLSラベル値を割り当てられたパケットのセットとして暗黙的に定義されます。パケットへのラベルの割り当ては、さまざまな基準に基づいている可能性があり、LSPトンネルのエンドポイント間のすべてのパケット（またはそのサブセット）を含む場合があります。トラフィックは集約されているため、LSPタンネルの数（したがってRSVPセッションの数）は、ネットワーク内のフローの数に比例して増加しません。したがって、RSVP-TE仕様[1]は、元のRSVPプロトコル[3]の主要なスケーリングの問題に対処します。マイクロフローの粒度でのセッション。
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トンネルに関連付けることで実現できます。たとえば、2つのラベルスイッチングルーター間のトラフィックフロー統計を監視するためだけに、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-Tunnelsを使用して、従来のインテリアゲートウェイプロトコル（IGP）最短パスファースト（SPF）アルゴリズムによって計算されたルートに依存しないパスを介してトラフィックのサブセットを転送できます。この機能は、ルーティング関数に大きな柔軟性を導入し、運用ネットワークのパフォーマンス最適化をもたらす可能性のあるポリシーを実装できるようにします。たとえば、LSP-Tunnelsを使用して、トラフィックは混雑したネットワークリソースから比較的活用されていないものにルーティングできます。より一般的には、ネットワークの有効容量を高めるために、負荷分散ポリシーを実現できます。
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.
MPLSアーキテクチャ[4]が、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-Tunnel仮想トポロジから始めて、観測されたトラフィックフローパターンに基づいて追加の複雑さを導入することをお勧めします。
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仕様は、Unicast LSP-Tunnelsのみをサポートします。マルチキャスト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仕様が特に適用される1つのコンテキストは、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メーリングリストのこのメモの最初のレビュー中に、以下の個人から受け取った有用なコメントに感謝します：Eric Gray、John Renwick、およびGeorge Swallow。
[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.、Berger、L.、Gan、D.、Li、T.、Swallow、G。and V. Srinivasan、「RSVP-TE：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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1、機能仕様」、RFC 2205、1997年9月。
[4] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed Architecture for MPLS", RFC 3031, January 2001.
[4] Rosen、E.、Viswanathan、A。and 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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[6] Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP," Work in Progress.
[6] Jamoussi、B。et al、「LDPを使用した制約ベースのLSPセットアップ」作業進行中。
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive、Suite 615 McLean、VA 22102
EMail: awduche@movaz.com
Voice: +1 703-298-5291
Alan Hannan RoutingLoop 112 Falkirk Court Sunnyvale, CA 94087
Alan Hannan Routingloop 112 Falkirk Court Sunnyvale、CA 94087
EMail: alan@routingloop.com
Voice: +1 408 666-2326
XiPeng Xiao Photuris Inc. 2025 Stierlin Ct. Mountain View, CA 94043
Xipeng Xiao Photuris Inc. 2025 Stierlin Ct。マウンテンビュー、CA 94043
EMail: xxiao@photuris.com
Voice: +1 650-919-3215
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。