Network Working Group F. Le Faucheur
Request for Comments: 3785 R. Uppili
BCP: 87 Cisco Systems, Inc.
Category: Best Current Practice A. Vedrenne
P. Merckx
Equant
T. Telkamp
Global Crossing
May 2004
Use of Interior Gateway Protocol (IGP) Metric
as a second MPLS Traffic Engineering (TE) Metric
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices.
この文書では、内部ゲートウェイプロトコル（IGP）の既存のメトリックは（MPLS）トラフィックエンジニアリングトンネルをマルチプロトコルラベルスイッチングの制約ベースルーティングのメトリックトラフィックエンジニアリング（TE）の代替メトリックとして使用することができます方法についての一般的な方法を説明します。さまざまな要件を持つ他のトンネルに別のメトリック（例えば、伝搬遅延）を最適化しながら、これは効果的にいくつかのトラフィックエンジニアリングトンネル（例えば、データトランクス）のための1つのメトリック（例えば、リンク帯域幅）の最適化と制約ベースのルーティングを実行する能力につながります（例えば、音声トランクス）。いいえプロトコル拡張や修正は必要ありません。このテキストは、現在のルータの実装と展開プラクティスを説明します。
Interior Gateway Protocol (IGP) routing protocols (OSPF and IS-IS) as well as MultiProtocol Label Switching (MPLS) signaling protocols (RSVP-TE and CR-LDP) have been extended (as specified in [ISIS-TE], [OSPF-TE], [RSVP-TE] and [CR-LDP]) in order to support the Traffic Engineering (TE) functionality as defined in [TE-REQ].
[ISIS-TE]、[OSPFで指定されるように、内部ゲートウェイプロトコル（IGP）ルーティングプロトコル（OSPFおよびISIS）、ならびにマルチプロトコルラベルスイッチング（MPLS）シグナリングプロトコル（RSVP-TEやCR-LDP）は、（拡張されました[TE-REQ]で定義されるようにトラフィックエンジニアリング（TE）機能をサポートするために-TE]、[RSVP-TE]及び[CR-LDP]）。
These IGP routing protocol extensions currently include advertisement of a single additional MPLS TE metric to be used for Constraint Based Routing of TE tunnels.
これらのIGPルーティングプロトコルの拡張機能は、現在、TEトンネルの制約ベースのルーティングに使用する単一の追加MPLS TEメトリックの広告が含まれます。
However, the objective of traffic engineering is to optimize the use and the performance of the network. So it seems relevant that TE tunnel placement may be optimized according to different optimization criteria. For example, some Service Providers want to perform traffic engineering of different classes of service separately so that each class of Service is transported on a different TE tunnel. One example motivation for doing so is to apply different fast restoration policies to the different classes of service. Another example motivation is to take advantage of separate Constraint Based Routing in order to meet the different Quality of Service (QoS) objectives of each Class of Service. Depending on QoS objectives one may require either (a) enforcement by Constraint Based Routing of different bandwidth constraints for the different classes of service as defined in [DS-TE], or (b) optimizing on a different metric during Constraint Based Routing or (c) both. This document discusses how optimizing on a different metric can be achieved during Constraint Based Routing.
しかし、トラフィックエンジニアリングの目的は、使用してネットワークのパフォーマンスを最適化することです。だから、TEトンネルの配置が異なる最適化基準に従って最適化することができることを、関連すると思われます。例えば、いくつかのサービスプロバイダは、サービスの各クラスが異なるTEトンネル上で輸送されるように、個別のサービスの異なるクラスのトラフィックエンジニアリングを実行したいです。そうするための一つの例の動機はサービスの異なるクラスに異なる高速の復旧ポリシーを適用することです。別の例の動機は異なるサービス品質（QoS）サービスの各クラスの目標を達成するために、別々の制約ベースルーティングを活用することです。 [DS-TE]で定義された、または（b）制約ベースのルーティングまたは（中に異なるメトリックに最適化などのQoS目標に応じて、1つは、サービスの異なるクラスに対して異なる帯域幅の制約の制約ベースのルーティングにより（a）は実施のいずれかを必要とするかもしれませんc）の両方。この文書では、異なるメトリックに最適化するには制約ベースのルーティング中に達成することができます方法について説明します。
The most common scenario for a different metric calls for optimization of a metric reflecting delay (mainly propagation delay) when Constraint Based Routing TE Label Switched Paths (LSPs) that will be transporting voice, while optimizing a more usual metric (e.g., reflecting link bandwidth) when Constraint Based Routing TE LSPs that will be transporting data.
より一般的なメトリック（例えば、反映リンク帯域幅を最適化しながら、制約ベースルーティングTEラベルは、声を輸送されるスイッチパス（LSP）する際の遅延（主に伝播遅延）を反映した評価指標の最適化のためのさまざまなメトリック呼び出しのための最も一般的なシナリオ）時にデータを転送します制約ベースルーティングTEのLSP。
Additional IGP protocol extensions could be defined so that multiple TE metrics could be advertised in the IGP (as proposed for example in [METRICS]) and would thus be available to Constraint Based Routing in order to optimize on a different metric. However this document describes how optimizing on a different metric can be achieved today by existing implementations and deployments, without any additional IGP extensions beyond [ISIS-TE] and [OSPF-TE], by effectively using the IGP metric as a "second" TE metric.
複数のTEメトリックは（[METRICS]、例えば提案されているように）IGPでアドバタイズすることができ、したがって、異なるメトリックに最適化するために、制約ベースのルーティングに利用可能となるように追加のIGPプロトコル拡張を定義することができます。しかし、この文書では、異なるメトリックに最適化が効果的に「第二」TEとしてIGPメトリックを使用することにより、任意の追加の[ISIS-TE]を超えたIGPの拡張と[OSPF-TE]なしで、既存の実装および展開で、今日実現する方法について説明しメトリック。
In current MPLS TE deployments, network administrators often want Constraint Based Routing of TE LSPs carrying data traffic to be based on the same metric as the metric used for Shortest Path Routing. Where this is the case, this practice allows the Constraint Based Routing algorithm running on the Head-End LSR to use the IGP metric advertised in the IGP to compute paths for data TE LSPs instead of the advertised TE metric. The TE metric can then be used to convey another metric (e.g., a delay-based metric) which can be used by the Constraint Based Routing algorithm on the Head-End LSR to compute path for the TE LSPs with different requirements (e.g., Voice TE LSP).
現在のMPLS TEの展開では、ネットワーク管理者は、多くの場合、TE LSPの制約ベースのルーティングは、最短パスルーティングのために使用されるメトリックと同じメトリックに基づいているとのデータトラフィックを伝送します。これが事実である場合には、このような行為は、制約ベースのルーティングアルゴリズムは、代わりに広告を出してTEメトリックのデータTEのLSPのパスを計算するためにIGPでアドバタイズIGPメトリックを使用するヘッドエンドLSR上で動作していることができます。 TEメトリックは、さまざまな要件（例えば、音声とTEのLSPのパスを計算するために、ヘッドエンドLSRに制約ベースのルーティングアルゴリズムで使用することができ、別のメトリック（例えば、遅延ベースのメトリックを）伝えるために使用することができますTE LSP）。
In some networks, network administrators configure the IGP metric to a value factoring the link propagation delay. In that case, this practice allows the Constraint Based Routing algorithm running on the Head-End LSR to use the IGP metric advertised in the IGP to compute paths for delay-sensitive TE LSPs (e.g., Voice TE LSPs) instead of the advertised TE metric. The TE metric can then be used to convey another metric (e.g., bandwidth based metric) which can be used by the Constraint Based Routing algorithm to compute paths for the data TE LSPs.
一部のネットワークでは、ネットワーク管理者は、リンクの伝搬遅延を考慮値にIGPメトリックを設定します。その場合には、このような行為は、制約ベースのルーティングアルゴリズムは、代わりに広告を出してTEメトリックの遅延に敏感なTEのLSP（例えば、音声TEのLSP）のパスを計算するためにIGPでアドバタイズIGPメトリックを使用するヘッドエンドLSR上で動作していることができます。 TEメトリックは、別のメトリックを伝えるために使用することができる（例えば、帯域幅ベースのメトリック）データTE LSPのためのパスを計算するために、制約ベースのルーティングアルゴリズムで使用することができます。
More generally, the TE metric can be used to carry any arbitrary metric that may be useful for Constraint Based Routing of the set of LSPs which need optimization on another metric than the IGP metric.
より一般的には、TEメトリックは、IGPメトリックは別のメトリックに最適化を必要とするLSPのセットの制約ベースのルーティングのために有用であり得る任意のメトリックを搬送するために使用することができます。
A Head-End LSR implements the current practice by:
ヘッドエンドLSRは、現在で練習を実装しています。
(i) Allowing configuration, for each TE LSP to be routed, of whether the IGP metric or the TE metric is to be used by the Constraint Based Routing algorithm.
各TE LSPの設定を許可する（i）は、IGPメトリックまたはTEメトリックは、制約ベースのルーティングアルゴリズムで使用されるか否かを、ルーティングすることができます。
(ii) Enabling the Constraint Based Routing algorithm to make use of either the TE metric or the IGP metric, depending on the above configuration for the considered TE-LSP
（ii）の考えTE-LSPのための上記の構成に応じて、TEメトリックまたはIGPメトリックのいずれかを利用するように制約ベースのルーティングアルゴリズムを有効にします
A Service Provider deploys this practice by:
サービスプロバイダは、ことで、この練習をデプロイします。
(i) Configuring, on every relevant link, the TE metric to reflect whatever metric is appropriate (e.g., delay-based metric) for Constraint Based Routing of some LSPs as an alternative metric to the IGP metric
（I）IGPメトリックの代替指標として、いくつかのLSPの制約ベースのルーティングのために（例えば、遅延ベースのメトリック）が適切であるどのようなメトリックを反映するために、すべての関連リンク、TEメトリックに、設定
(ii) Configuring, for every TE LSP, whether this LSP is to be constraint based routed according to the TE metric or IGP metric
（ii）の設定、すべてのTE LSPのために、このLSPがTEメトリックまたはIGPメトリックに従ってルーティング制約基づいするかどうか
The practice described in this document has the following constraints:
このドキュメントで説明するプラクティスは、次の制約があります。
(i) it only allows TE tunnels to be routed on either of two metrics (i.e., it cannot allow TE tunnels to be routed on one of three, or more, metrics). Extensions (for example such as those proposed in [METRICS]) could be defined in the future if necessary to relax this constraints, but this is outside the scope of this document.
（I）それだけで（即ち、それはTEトンネルが3つ、またはそれ以上のいずれか、メトリックにルーティングすることを可能にすることができない）TEトンネルは、2つのメトリックのいずれかにルーティングされることを可能にします。この制約を緩和するために、必要に応じて（例えば[METRICS]で提案されたものとして）拡張は、将来的に定義することができるが、これはこの文書の範囲外です。
(ii) it can only be used where the IGP metric is appropriate as one of the two metrics to be used for constraint based routing (i.e., it cannot allow TE tunnels to be routed on either of two metrics while allowing IGP SPF to be based on a third metric). Extensions (for example such as those proposed in [METRICS]) could be defined in the future if necessary to relax this constraints, but this is outside the scope of this document.
（II）はIGPメトリックは、制約ベースのルーティングのために使用される2つのメトリックの1つとして適切である（すなわち、それは、TEトンネルがIGP SPFが基づくことを可能にしながら、2つのメトリックのいずれかにルーティングすることを可能にすることができないだけを使用することができます第三のメトリックに）。この制約を緩和するために、必要に応じて（例えば[METRICS]で提案されたものとして）拡張は、将来的に定義することができるが、これはこの文書の範囲外です。
(iii) it can only be used on links which support an IGP adjacency so that an IGP metric is indeed advertised for the link. For example, this practice can not be used on Forwarding Adjacencies (see [LSP-HIER]).
（ⅲ）それが唯一のIGPメトリックが実際にリンクのために宣伝されるように、IGP隣接関係をサポートするリンク上で使用することができます。例えば、この方法は、（[LSP-HIER]参照）転送隣接関係で使用することができません。
Note that, as with [METRICS], this practice does not recommend that the TE metric and the IGP metric be used simultaneously during path computation for a given LSP. This is known to be an NP-complete problem.
【METRICS]と同様に、この方法は、TEメトリックとIGPメトリックは、所与のLSPのためのパス計算中に同時に使用することを推奨しないことに留意されたいです。これはNP完全問題であることが知られています。
Where path computation is entirely performed by the Head-End (e.g., intra-area operations with path computation on Head-end), this practice does not raise any interoperability issue among LSRs since the use of one metric or the other is a matter purely local to the Head-End LSR.
経路計算は完全にヘッドエンド（ヘッドエンドの経路計算を持つ例えば、エリア内の操作）によって実行される場合に1つのメトリックまたは他の使用は、純粋に問題があるため、このような行為は、LSRの間の任意の相互運用性の問題を提起しません。ヘッドエンドLSRへのローカル。
Where path computation involves another component than the Head-End (e.g., with inter-area operations where path computation is shared between the Head-End and Area Boundary Routers or a Path Computation Server), this practice requires that which metric to optimize on, be signaled along with the other constraints (bandwidth, affinity) for the LSP. See [PATH-COMP] for an example proposal on how to signal which metric to optimize, to another component involved in path computation when RSVP-TE is used as the protocol to signal path computation information.
経路計算はヘッドエンド（例えば、経路計算はヘッドエンドおよびエリア境界ルータまたはパス計算サーバ間で共有されるエリア間操作に）以外の他の成分を含む場合、この方法は、上で最適化するメトリックれることを必要としますLSPのための他の制約（帯域幅、親和性）と一緒にシグナリングします。 RSVP-TEは、経路計算情報をシグナリングするプロトコルとして使用される場合に、経路計算に関与する別のコンポーネントに、最適化するためにどのメトリック信号に方法の例提案のために[PATH-COMP]を参照。
Service Providers need to consider how to migrate from the current implementation to the new one supporting this practice.
サービスプロバイダは、この練習をサポートする新しいものに現在の実装から移行する方法を検討する必要があります。
Although the head-end routers act independently from each other, some migration scenarios may require that all head-end routers be upgraded to the new implementation to avoid any disruption on existing TE-LSPs before two metrics can effectively be used by TE. The reason is that routers with current implementation are expected to always use the TE metric for Constraint Based Routing of all tunnels; so when the TE metric is reconfigured to reflect the "second metric" (say to a delay-based metric) on links in the network, then all TE-LSPs would get routed based on the "second metric" metric, while the intent may be that only the TE-LSPs explicitly configured so should be routed based on the "second metric".
ヘッドエンドルータは、互いに独立して動作しますが、いくつかの移行シナリオは2つのメトリックを効果的にTEで使用することができます前に、すべてのヘッドエンドルータは、既存のTE-LSPの上の任意の混乱を避けるために、新しい実装にアップグレードすることを要求することができます。その理由は、現在の実装でルータは、常にすべてのトンネルの制約ベースのルーティングのためのTEメトリックを使用することが期待されていることです。 TEメトリックは、ネットワーク内のリンクを（遅延ベースのメトリックに言う）「第二のメトリック」を反映するように再設定されたときに意図がかもしれないがそう、すべてのTE-LSPは、「第二のメトリック」メトリックに基づいてルーティングされるになるだろう唯一のTE-LSPを明示的にそのように構成され、「第二メトリック」に基づいてルーティングされなければならないということ。
A possible migration scenario would look like this:
可能な移行シナリオは次のようになります。
1) upgrade software on all head-end routers in the network to support this practice.
1）この練習をサポートするために、ネットワーク内のすべてのヘッドエンドルータのソフトウェアをアップグレード。
2) change the TE-LSPs configuration on the head-end routers to use the IGP metric (e.g., bandwidth-based) for Constraint Based Routing rather than the TE metric.
2）IGPメトリックを使用するヘッドエンドルータにTE-LSPの設定を変更する（例えば、帯域幅ベースの）制約ベースのルーティングではなくTEメトリックため。
3) configure TE metric on the links to reflect the "second metric" (e.g., delay-based).
3）反射するようにリンクをTEメトリックを設定する「第二メトリック」（例えば、遅延に基づきます）。
4) modify the LSP configuration of the subset of TE-LSPs which need to be Constraint Based routed using the "second metric" (e.g., delay-based), and/or create new TE-LSPs with such a configuration.
4）使用してルーティング制約ベースである必要はTE-LSPのサブセットのLSPの設定を変更する「第二メトリック」（例えば、遅延に基づく）、および/またはそのような構成で新しいTE-LSPを作成します。
It is desirable that step 2 is non-disruptive (i.e., the routing of a LSP will not be affected in any way, and the data transmission will not be interrupted) by the change of LSP configuration to use "IGP metric" as long as the actual value of the "IGP metric" and "TE metric" are equal on every link at the time of LSP reconfiguration (as would be the case at step 2 in migration scenario above which assumed that TE metric was initially equal to IGP metric).
限り、「メトリックIGP」を使用するLSPの設定の変更により（すなわち、LSPのルーティングが何らかの方法で影響を受けることなく、データ伝送が中断されることはありません）。ステップ2は、非中断であることが望ましいことがあります「IGPメトリック」および「TEメトリック」の実際の値は（TEメトリックは、IGPメトリックに最初に等しかったと仮定した上に移行シナリオのステップ2で場合のように）LSPの再構成時に各リンクに等しいです。
The practice described in this document does not raise specific security issues beyond those of existing TE. Those are discussed in the respective security sections of [TE-REQ], [RSVP-TE] and [CR-LDP].
この文献に記載の練習では、既存のTEのそれを超えて特定のセキュリティ上の問題を提起しません。それらは、[TE-REQ]のそれぞれのセキュリティセクションで説明されている、[RSVP-TE]及び[CR-LDP]。
This document has benefited from discussion with Jean-Philippe Vasseur.
この文書では、ジャン=フィリップVasseurとの議論の恩恵を受けています。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, Requirements for Traffic Engineering over MPLS, RFC 2702, September 1999.
[TE-REQ] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、MPLS上のトラフィックエンジニアリング、RFC 2702、1999年9月のための要件。
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
、RFC 3630、2003年9月[OSPF-TE]カッツ、D.、Kompella、K.、およびD.ヨン、 "OSPFバージョン2へのトラフィックエンジニアリング（TE）の拡張"。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE), RFC 3784, May 2004.
トラフィックエンジニアリング（TE）のための[ISIS-TE]スミット、H.、およびT.李、「中間システム中間システム（ISIS）への拡張、RFC 3784、2004年5月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、 2001年12月。
[CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[CR-LDP] Jamoussi、B.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、 Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、2002年1月。
[METRICS] Fedyk, et al., "Multiple Metrics for Traffic Engineering with IS-IS and OSPF", Work in Progress, November 2000.
[メトリクス] Fedyk、ら、「IS-ISおよびOSPFとトラフィックエンジニアリングのための複数のメトリック」、進歩、2000年11月に作業。
[DIFF-TE] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DIFF-TE]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。
[PATH-COMP] Vasseur, et al., "RSVP Path computation request and reply messages", Work in Progress, June 2002.
[PATH-COMP] Vasseurら、 "RSVPの経路計算要求メッセージと応答メッセージ"、進歩、2002年6月での作業。
[LSP-HIER] Kompella, et al., "LSP Hierarchy with Generalized MPLS TE", Work in Progress, September 2002.
[LSP-HIER] Kompella、ら。、 "一般化MPLS TE LSPと階層"、進歩、2002年9月ワーク。
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオ・ソフィアアンティポリス、フランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Ramesh Uppili Cisco Systems, 2000 Innovation Drive Kanata, ONTARIO, Canada - K2K 3E8
ラメシュUppiliシスコシステムズ、2000イノベーションドライブカナタ、オンタリオ州、カナダ - K2K 3E8
Phone: 01-613-254 4578 Email: ruppili@cisco.com
電話番号：01-613-254 4578 Eメール：ruppili@cisco.com
Alain Vedrenne Equant Heraklion, 1041 route des Dolines, BP347 06906 Sophia Antipolis Cedex FRANCE
アランVedrenneイクアントイラクリオン、1041ルートDolines、BP347 06906ソフィアアンティポリスセデックスFRANCE
Phone: +33 4 92 96 57 22 EMail: alain.vedrenne@equant.com
電話：+33 4 92 96 57 22 Eメール：alain.vedrenne@equant.com
Pierre Merckx Equant 1041 route des Dolines - BP 347 06906 SOPHIA ANTIPOLIS Cedex FRANCE
ピエール・メルクスイクアント1041ルートDolines - BP 347 06906ソフィアアンティポリスセデックスFRANCE
Phone: +33 (0)492 96 6454 EMail: pierre.merckx@equant.com
電話：+33（0）492 96 6454 Eメール：pierre.merckx@equant.com
Thomas Telkamp Global Crossing, Ltd. Croeselaan 148 NL-3521CG Utrecht The Netherlands
（株）トーマスTelkampグローバル・クロッシング、 Croeselaan 148 NL-3521CGユトレヒトオランダ
Phone: +31 30 238 1250 EMail: telkamp@gblx.net
電話：+31 30 238 1250 Eメール：telkamp@gblx.net
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。