Network Working Group K. Kompella
Request for Comments: 4206 Y. Rekhter
Category: Standards Track Juniper Networks
October 2005
Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).
一般化されたマルチプロトコルラベルスイッチング（GMPLS）のスケーラビリティを向上させることは、ラベルを集約するのに有用であり得るそのようなLSPの階層を作成することにより、パス（LSPを）スイッチ。そのような階層を作成する方法は、トラフィックエンジニアリングラベルスイッチパス（TE LSP）を作成する（a）のラベルスイッチングルータ（LSR）であり、（b）のLSRは、LSPのうち、転送隣接（FA）を形成する（広告により、他のLSRが、その経路計算のためのFAを使用することを可能にするLSPを作成するために使用されたもの）、（C）、及び（d）入れ子のようISIS / OSPFの同じインスタンスにトラフィックエンジニアリング（TE）リンクとして、このLSP （ラベルスタック構築物を使用して）そのLSPに、他のLSRによって発信のLSP。
This document describes the mechanisms to accomplish this.
この文書では、これを実現するためのメカニズムを説明します。
Table of Contents
目次
1. Overview ........................................................2
2. Specification of Requirements ...................................3
3. Routing Aspects .................................................4
3.1. Traffic Engineering Parameters .............................4
3.1.1. Link Type (OSPF Only) ...............................5
3.1.2. Link ID (OSPF Only) .................................5
3.1.3. Local and Remote Interface IP Address ...............5
3.1.4. Local and Remote Link Identifiers ...................5
3.1.5. Traffic Engineering Metric ..........................5
3.1.6. Maximum Bandwidth ...................................5
3.1.7. Unreserved Bandwidth ................................5
3.1.8. Resource Class/Color ................................5
3.1.9. Interface Switching Capability ......................6
3.1.10. SRLG Information ...................................6
4. Other Considerations ............................................6
5. Controlling FA-LSPs Boundaries ..................................7
5.1. LSP Regions ................................................7
6. Signalling Aspects ..............................................8
6.1. Common Procedures ..........................................8
6.1.1. RSVP-TE .............................................8
6.1.2. CR-LDP ..............................................9
6.2. Specific Procedures .......................................10
6.3. FA-LSP Holding Priority ...................................11
7. Security Considerations ........................................11
8. Acknowledgements ...............................................12
9. Normative References ...........................................12
10. Informative References ........................................13
An LSR uses Generalized MPLS (GMPLS) TE procedures to create and maintain an LSP. The LSR then may (under local configuration control) announce this LSP as a Traffic Engineering (TE) link into the same instance of the GMPLS control plane (or, more precisely, its ISIS/OSPF component) as the one that was used to create the LSP. We call such a link a "forwarding adjacency" (FA). We refer to the LSP as the "forwarding adjacency LSP", or just FA-LSP. Note that an FA-LSP is both created and used as a TE link by exactly the same instance of the GMPLS control plane. Thus, the concept of an FA is applicable only when an LSP is both created and used as a TE link by exactly the same instance of the GMPLS control plane. Note also that an FA is a TE link between two GMPLS nodes whose path transits zero or more (G)MPLS nodes in the same instance of the GMPLS control plane.
LSRは、LSPを作成し、維持するために一般化MPLS（GMPLS）TEの手順を使用します。 LSRは、次いで、（ローカル設定制御下で）GMPLS制御プレーンの同じインスタンスにトラフィックエンジニアリング（TE）リンクとして、このLSPをアナウンスすることができる（または、より正確には、そのISIS / OSPF成分）を作成するために使用されたものとLSP。私たちは「フォワーディング隣接関係」（FA）などのリンクを呼び出します。私たちは、「転送隣接LSP」、または単にFA-LSPとしてLSPを参照してください。 FA-LSPの両方GMPLS制御プレーンのまったく同じインスタンスによって作成され、TEリンクとして使用されることに留意されたいです。このように、FAの概念は、LSPが両方のGMPLS制御プレーンのまったく同じインスタンスによって作成され、TEリンクとして使用されている場合にのみ適用可能です。注またFAパスGMPLS制御プレーンの同じインスタンスにゼロ以上の（G）MPLSノードを通過する2つのGMPLSノード間のTEリンクであること。
The nodes connected by a 'basic' TE link may have a routing adjacency; however, the nodes connected by an FA would not usually have a routing adjacency. A TE link of any kind (either 'basic' or FA) would have to have a signaling adjacency in order for it to be used to establish an LSP across it.
「基本的な」TEリンクによって接続されたノードは、ルーティング隣接関係を有していてもよいです。しかし、FAによって接続されたノードは、通常のルーティング隣接関係を持たないであろう。 （いずれかの「基本的な」またはFA）任意の種類のTEリンクは、それを横切ってLSPを確立するために使用するためにシグナリング隣接を持ってなければなりません。
In general, the creation/termination of an FA and its FA-LSP could be driven either by mechanisms outside of GMPLS (e.g., via configuration control on the LSR at the head-end of the adjacency), or by mechanisms within GMPLS (e.g., as a result of the LSR at the head-end of the adjacency receiving LSP setup requests originated by some other LSRs).
一般に、FAとFA-LSPの作成/終了は、GMPLSの外部メカニズムによって（例えば、隣接のヘッドエンドにおけるLSRの設定制御を介して）、又はGMPLS内の機構のいずれかによって駆動することができる（例えば、いくつかの他のLSRによって発信LSP設定要求）を受信する隣接のヘッドエンドにおけるLSRの結果として。
ISIS/OSPF floods the information about FAs just as it floods the information about any other links. As a result of this flooding, an LSR has in its TE link state database the information about not just basic TE links, but FAs as well.
ISIS / OSPFは、それが他のリンクに関する情報をフラッディング同様のFAに関する情報をフラッディングします。この洪水の結果として、LSRはそのTEリンク状態データベースだけではなく、基本的なTEリンクに関する情報を持っていますが、FAのにも。
An LSR, when performing path computation, uses not just basic TE links, but FAs as well. Once a path is computed, the LSR uses RSVP/CR-LDP [RSVP-TE, CR-LDP] for establishing label binding along the path.
LSRは、経路計算を行う場合には、同様の基本的なTEリンクが、FAのではないだけを使用しています。経路が計算されると、LSRは、経路に沿ってラベルバインディングを確立するためのRSVP / CR-LDP [RSVP-TE、CR-LDP]を使用します。
In this document we define mechanisms/procedures to accomplish the above. These mechanisms/procedures cover both the routing (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects.
この文書では、上記を達成するためのメカニズム/手順を定義します。これらのメカニズム/手順は、ルーティング（ISIS / OSPF）及びシグナリング（RSVP / CR-LDP）の側面の両方をカバーします。
Note that an LSP may be advertised as a point-to-point link into ISIS or OSPF, to be used in normal SPF by nodes other than the head-end. While this is similar in spirit to an FA, this is beyond the scope of this document.
LSPは、ISIS又はOSPFへのポイントツーポイントリンクとして広告することができるヘッドエンド以外のノードによって正常なSPFで使用することに留意されたいです。これはFAとその精神において似ていますが、これはこのドキュメントの範囲を超えています。
Scenarios where an LSP is created (and maintained) by one instance of the GMPLS control plane, and is used as a (TE) link by another instance of the GMPLS control plane, are outside the scope of this document.
LSPは、GMPLS制御プレーンの1つのインスタンスによって（及び維持）が作成され、GMPLS制御プレーンの別のインスタンスによって（TE）リンクとして使用されるシナリオは、この文書の範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
In this section we describe procedures for constructing FAs out of LSPs, and handling of FAs by ISIS/OSPF. Specifically, this section describes how to construct the information needed to advertise LSPs as links into ISIS/OSPF. Procedures for creation/termination of such LSPs are defined in Section 5, "Controlling FA-LSPs boundaries".
このセクションでは、LSPの外のFAを構築するための手順、およびISIS / OSPFによってのFAの取り扱いについて説明します。具体的には、このセクションでは、ISIS / OSPFへのリンクなどのLSPを宣伝するために必要な情報を構築する方法について説明します。そのようなLSPの作成/終了の手順は、「FA-LSPの境界の制御」、第5節で定義されています。
FAs may be represented as either unnumbered or numbered links. If FAs are numbered with IPv4 addresses, the local and remote IPv4 addresses come out of a /31 that is allocated by the LSR that originates the FA-LSP; the head-end address of the FA-LSP is the one specified as the IPv4 tunnel sender address; the remote (tail-end) address can then be inferred. If the LSP is bidirectional, the tail-end can thus know the addresses to assign to the reverse FA.
FASが非番号または番号のいずれかのリンクとして表すことができます。 FAは、IPv4アドレスと番号付けされる場合、ローカルおよびリモートのIPv4アドレスは、FA-LSPを発信LSRによって割り当てられる/ 31から出てきます。 FA-LSPのヘッドエンドアドレスは、IPv4トンネルの送信元アドレスとして指定したものです。リモート（テールエンド）アドレスが推測できます。 LSPが双方向である場合には、テールエンドは、このように逆FAに割り当てるアドレスを知ることができます。
If there are multiple LSPs that all originate on one LSR and all terminate on another LSR, then at one end of the spectrum all these LSPs could be merged (under control of the head-end LSR) into a single FA using the concept of Link Bundling (see [BUNDLE]); while at the other end of the spectrum each such LSP could be advertised as its own adjacency.
そこオールインワンLSRに属し、複数のLSPがあり、すべての他のLSRに終了した場合、次に、スペクトルの一端には、これらすべてのLSPは、リンクの概念を使用して、単一のFAに（ヘッドエンドLSRの制御下で）併合することができますバンドル（[バンドル]を参照）。スペクトルの他端にそのような各LSPは、それ自身の隣接としてアドバタイズすることができました。
When an FA is created under administrative control (static provisioning), the attributes of the FA-LSP have to be provided via configuration. Specifically, the following attributes may be configured for the FA-LSP: the head-end address (if left unconfigured, this defaults to the head-end LSR's Router ID); the tail-end address; bandwidth and resource colors constraints. The path taken by the FA-LSP may be either computed by the LSR at the head-end of the FA-LSP, or specified by explicit configuration; this choice is determined by configuration.
FAは、管理制御（静的プロビジョニング）の下に作成された場合、FA-LSPの属性は、構成を介して提供されなければなりません。具体的には、次の属性はFA-LSPのために構成されてもよい：ヘッドエンドアドレス（未設定のままにすると、このデフォルトは、ヘッドエンドLSRのルータIDに）。テールエンドのアドレス。帯域幅とリソース色の制約。 FA-LSPにより撮影されたパスは、いずれかのFA-LSPのヘッドエンドでのLSRによって計算され、又は明示的な設定で指定されてもよいです。この選択は構成によって決定されます。
When an FA is created dynamically, the attributes of its FA-LSP are inherited from the LSP that induced its creation. Note that the bandwidth of the FA-LSP must be at least as big as the LSP that induced it, but may be bigger if only discrete bandwidths are available for the FA-LSP. In general, for dynamically provisioned FAs, a policy-based mechanism may be needed to associate attributes to the FA-LSPs.
FAが動的に作成されると、そのFA-LSPの属性は、その作成を誘発したLSPから継承されます。 FA-LSPの帯域幅がそれを誘発LSPと少なくとも同じ大きさでなければなりませんが、唯一の離散的な帯域幅は、FA-LSPのために利用可能である場合に大きくなることがあります。一般的に、動的プロビジョニングのFAのために、ポリシーベースのメカニズムは、FA-のLSPに属性を関連付けるために必要とされるかもしれません。
In this section, the Traffic Engineering parameters (see [OSPF-TE] and [ISIS-TE]) for FAs are described.
このセクションでは、トラフィックエンジニアリングパラメータは、Fasに記載されている（[OSPF-TE]および[ISIS-TE]を参照します）。
The Link Type of an FA is set to "point-to-point".
FAのリンクタイプは、「ポイント・ツー・ポイント」に設定されています。
The Link ID is set to the Router ID of the tail-end of FA-LSP.
リンクIDは、FA-LSPのテールエンドのルータIDに設定されています。
If the FA is to be numbered, the local interface IP address (OSPF) or IPv4 interface address (ISIS) is set to the head-end address of the FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor address (ISIS) is set to the tail-end address of the FA-LSP.
FAが番号付けされる場合、ローカルインタフェースIPアドレス（OSPF）またはIPv4インタフェースアドレス（ISIS）は、FA-LSPのヘッドエンドアドレスに設定されています。リモートインターフェイスのIPアドレス（OSPF）またはIPv4ネイバーアドレス（ISIS）は、FA-LSPの末尾のアドレスに設定されています。
For an unnumbered FA, the assignment and handling of the local and remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP].
無数のFAのために、ローカルおよびリモートのリンク識別子の割り当ておよび処理は[UNNUM-CRLDP]、[UNNUM-RSVP]で指定されています。
By default the TE metric on the FA is set to max(1, (the TE metric of the FA-LSP path) - 1) so that it attracts traffic in preference to setting up a new LSP. This may be overridden via configuration at the head-end of the FA.
デフォルトでは、FAのTEメトリックが最大に設定されている（1、FA-LSPパスの（TEメトリック） - 1）それは新しいLSPを設定に優先してトラフィックを集めているので。これは、FAのヘッドエンドに構成介して上書きされてもよいです。
By default, the Maximum Reservable Bandwidth and the initial Maximum LSP Bandwidth for all priorities of the FA is set to the bandwidth of the FA-LSP. These may be overridden via configuration at the head-end of the FA (note that the Maximum LSP Bandwidth at any one priority should be no more than the bandwidth of the FA-LSP).
デフォルトでは、最大予約可能帯域幅とFAの全ての優先順位の初期最大LSPの帯域幅は、FA-LSPの帯域幅に設定されています。これらはFAのヘッドエンド（いずれかの優先度で最大LSP帯域幅FA-LSPの帯域幅以下であってはならないことに注意）で構成介して上書きされてもよいです。
The initial unreserved bandwidth for all priority levels of the FA is set to the bandwidth of the FA-LSP.
FAの全ての優先順位の初期未予約帯域幅は、FA-LSPの帯域幅に設定されています。
By default, an FA does not have resource colors (administrative groups). This may be overridden by configuration at the head-end of the FA.
デフォルトでは、FAは、リソースの色（管理グループ）がありません。これは、FAのヘッドエンドに構成することによって上書きすることができます。
The (near-end) Interface Switching Capability associated with the FA is the (near end) Interface Switching Capability of the first link in the FA-LSP.
FAに関連付けられている（近端）インタフェーススイッチング能力は、FA-LSPの最初のリンクの（端部近傍）インタフェーススイッチング能力です。
When the (near-end) Interface Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the specific information includes Interface MTU and Minimum LSP Bandwidth. The Interface MTU is the minimum MTU along the path of the FA-LSP; the Minimum LSP Bandwidth is the bandwidth of the LSP.
（近端）インタフェーススイッチング機能フィールドは、PSC-1、PSC-2、PSC-3、またはPSC-4である場合、特定の情報は、インターフェースのMTU値と最小LSP帯域幅を含みます。インタフェースMTUはFA-LSPの経路に沿って最小のMTUです。最小LSPの帯域幅は、LSPの帯域幅です。
An FA advertisement could contain the information about the Shared Risk Link Groups (SRLG) for the path taken by the FA-LSP associated with that FA. This information may be used for path calculation by other LSRs. The information carried is the union of the SRLGs of the underlying TE links that make up the FA-LSP path; it is carried in the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF. See [GMPLS-ISIS, GMPLS-OSPF] for details on the format of this information.
FAの広告はそのFAに関連付けられているFA-LSPで撮影したパスの共有リスクリンクグループ（SRLG）に関する情報が含まれている可能性があります。この情報は、他のLSRによって経路計算のために使用することができます。運ばれる情報は、FA-LSPのパスを構成する基礎となるTEリンクのSRLGsの労働組合です。それは、IS-ISまたはOSPFでTEリンクTLVのSRLGサブTLVにSRLG TLVで運ばれます。この情報のフォーマットの詳細については[GMPLS-ISIS、GMPLS-OSPF]参照。
It is possible that the underlying path information might change over time, via configuration updates or dynamic route modifications, resulting in the change of the SRLG TLV.
基礎となる経路情報がSRLG TLVの変化をもたらす、構成の更新または動的経路変更を介して、時間とともに変化する可能性があることが可能です。
If FAs are bundled (via link bundling), and if the resulting bundled link carries an SRLG TLV, it MUST be the case that the list of SRLGs in the underlying path, followed by each of the FA-LSPs that form the component links, is the same (note that the exact paths need not be the same).
FASが（リンクバンドルを介して）バンドルされ、得られたバンドルリンクがSRLG TLVを運ぶ場合には、コンポーネントリンクを形成するFA-LSPの各々に続いて、基礎のパスにおけるSRLGsのリストある場合でなければならない場合（正確なパスが同じである必要はないことに注意）と同じです。
It is expected that FAs will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency.
のFAが隣接の両端のルータ間のISIS / OSPFピアリング関係を確立するために使用されないことが予想されます。
It may be desired in some cases to use FAs only in Traffic Engineering path computations. In IS-IS, this can be accomplished by setting the default metric of the extended IS reachability TLV for the FA to the maximum link metric (2^24 - 1). In OSPF, this can be accomplished by not advertising the link as a regular LSA, but only as a TE opaque LSA.
唯一のトラフィックエンジニアリングパス計算でのFAを使用するために、いくつかのケースでは望ましいことがあります。 IS-ISには、これは、FA用の到達可能性TLVは、最大リンクメトリック（1 - 2 ^ 24）まで延長のデフォルトメトリックを設定することにより、IS達成することができます。 OSPFでは、これが唯一のTE不透明LSAとして、定期的なLSAとしてリンクを広告しないことによって達成することができます。
To facilitate controlling the boundaries of FA-LSPs, this document introduces two new mechanisms: Interface Switching Capability (see [GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region").
FA-LSPの境界を制御容易にするために、このドキュメントは、2つの新しい機構を導入：インターフェーススイッチング能力は（[GMPLS-ISIS、GMPLS-OSPF]、及び「LSP領域」（又は単に「領域」を参照します）。
The information carried in the Interface Switching Capabilities is used to construct LSP regions and to determine regions' boundaries as follows.
インタフェーススイッチング機能で搬送される情報は、LSPの領域を構築するために、以下のように領域の境界を決定するために使用されます。
Define an ordering among interface switching capabilities as follows: PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two interfaces if-1 and if-2 with interface switching capabilities isc-1 and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than if-2's max LSP bandwidth.
PSC-1 <PSC-2 <PSC-3 <PSC-4 <TDM <LSC <FSC次のような機能を切り替えるインタフェース間の順序を定義します。与えられた2つのインターフェイスが1-場合とIF-2インタフェース切替機能を備えたISC-1及びISC-2それぞれ言うIF-1 <IF-2 ISC-1 <ISC-2またはISC-1 == ISC-2 = IFF = TDM、およびIF-1の最大LSPの帯域幅はIF-2の最大LSPの帯域幅よりも小さいです。
Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, node-2, ..., link-n, node-n. Moreover, for link-i denote by [link-i, node-(i-1)] the interface that connects link-i to node-(i-1), and by [link-i, node-i] the interface that connects link-i to node-i.
ノード0、リンク1、ノード1、リンク2、ノード2、...、リンク-N、ノードNを次のようにLSPの経路があると仮定する。また、リンクのため-iは[リンク-I、リンパ節転移（I-1）]（I-1）、および[リンク-I、ノードi]はインタフェースによりノード - リンクする-Iを接続するインタフェースで表しますそれは、リンクノードi-Iをするために接続します。
If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the LSP has crossed a region boundary at node-i; with respect to that LSP path, the LSR at node-i is an edge LSR. The 'other edge' of the region with respect to the LSP path is node-k, where k is the smallest number greater than i such that [link-(i+1), node-(i+1)] equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k, node-k].
[リンク - （I + 1）、ノード-I）] <[リンク - （I + 1）、リンパ節転移（I + 1）]であれば、我々は、LSPは、ノードiにおける領域の境界を越えていると言います。そのLSPの経路に対して、ノードiにおけるLSRは、エッジLSRです。 LSPパスに対する領域の「他のエッジはK」iは、このような[リンク - （I + 1）、リンパ節転移（I + 1）]に等しい[リンクよりも大きい最小の数であり、ノードK、あります-k、ノード - （K-1）]、および[リンク-K、リンパ節転移（K-1）]> [リンク-K、ノードK]。
Path computation may take region boundaries into account when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose Interface Switching Capability is PSC-1.
LSPのパスを計算するときに経路計算を考慮に領域境界がかかる場合があります。例えば、経路計算は、そのインターフェイス機能を切り替えPSC-1でのみリンクにLSPによって取られる経路を制限することができます。
Note that an interface may have multiple Interface Switching Capabilities. In such a case, the test is whether if-i < if-j depends on the Interface Switching Capabilities chosen for if-i and if-j, which in turn determines whether or not there is a region boundary at node-i.
インターフェイスは、複数のインターフェイスのスイッチング機能を有することができることに注意してください。このような場合には、テストは、jがあれば、今度はノードiにおける領域境界があるか否かを判定するI-IFおよびIF-jについて選択された機能をインタフェース切替に依存iはIF-<かどうかです。
In this section we describe procedures that an LSR at the head-end of an FA uses for handling LSP setup originated by other LSR.
このセクションでは、FAのヘッドエンドでのLSRは、他のLSRによって発信LSP設定を処理するために使用する手順について説明します。
As we mentioned before, establishment/termination of FA-LSPs may be triggered either by mechanisms outside of GMPLS (e.g., via administrative control), or by mechanisms within GMPLS (e.g., as a result of the LSR at the edge of an aggregate LSP receiving LSP setup requests originated by some other LSRs beyond LSP aggregate and its edges). Procedures described in Section 6.1, "Common Procedures", apply to both cases. Procedures described in Section 6.2, "Specific Procedures", apply only to the latter case.
我々は前に述べたように、FA-LSPの確立/終了は、GMPLSの外部メカニズムによって（例えば、管理制御を介して）、または集計LSPのエッジにおけるLSRの結果としてGMPLS内の機構（例えば、いずれかによってトリガされてもよいですLSPの集約とそのエッジ）を越えて他のいくつかののLSRによって発信LSP設定要求を受けました。 6.1節で説明した手順、「共通手順」、どちらの場合に適用されます。セクション6.2に記載の手順、「特定の手順」、後者のみの場合に適用されます。
For the purpose of processing the ERO in a Path/Request message of an LSP that is to be tunneled over an FA, an LSR at the head-end of the FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP hop away).
FA上にトンネリングされるLSPのパス/要求メッセージにEROを処理する目的のために、FA-LSPのヘッドエンドにおけるLSRは隣接としてそのFA-LSPの末尾にLSRを見（1つのIPは、ホップ離れて）。
How this is to be achieved for RSVP-TE and CR-LDP is described in the following subsections.
これはRSVP-TEとCR-LDPのために達成する方法を以下のサブセクションに記載されています。
In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's bandwidth from the unreserved bandwidth of the FA.
LSPは、FA-LSPを介してトンネリングされ、いずれの場合（RSVP-TEまたはCR-LDP）では、FA-LSPのヘッドエンドにおけるLSRはFAの未予約帯域幅からのLSPの帯域幅を減算します。
In the presence of link bundling (when link bundling is applied to FAs), when an LSP is tunneled through an FA-LSP, the LSR at the head-end of the FA-LSP also needs to adjust Max LSP bandwidth of the FA.
LSPは、FA-LSPを介してトンネリングされる（リンクバンドリングをのFAに適用される）リンクバンドルの存在下で、FA-LSPのヘッドエンドにおけるLSRはまたFAの最大LSP帯域幅を調整する必要があります。
If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP, then the Path message MUST contain an IF_ID RSVP_HOP object [GRSVP-TE, GSIG] instead of an RSVP_HOP object; and the data interface identification MUST identify the FA-LSP.
一つのFA-LSP上にトンネリングするLSPをシグナリングするRSVP-TEを使用する場合、PathメッセージはIF_ID RSVP_HOPオブジェクト[GRSVP-TE、GSIG]代わりのRSVP_HOPオブジェクトを含まなければなりません。データインタフェース同定はFA-LSPを識別しなければなりません。
The preferred method of sending the Path message is to set the destination IP address of the Path message to the computed NHOP for that Path message. This NHOP address must be a routable address; in the case of separate control and data planes, this must be a control plane address.
Pathメッセージを送信するための好ましい方法は、Pathメッセージのために計算さNHOPにPathメッセージの宛先IPアドレスを設定することです。このNHOPアドレスはルーティング可能なアドレスでなければなりません。別々の制御プレーンとデータプレーンの場合、これは制御プレーン・アドレスでなければなりません。
Furthermore, the IP header for the Path message MUST NOT have the Router Alert option. The Path message is intended to be IP-routed to the tail-end of the FA-LSP without being intercepted and processed as an RSVP message by any of the intermediate nodes.
さらに、PathメッセージのIPヘッダには、ルータアラートオプションを持ってはいけません。 Pathメッセージは、中間ノードのいずれかによって傍受され、RSVPメッセージとして処理されることなく、FA-LSPの末尾へIPルーティングされることを意図しています。
Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general, if the IF_ID RSVP_HOP object is used, this check must be disabled, as the number of hops over the control plane may be greater than one. Instead, the following check is done by the receiver Y of the IF_ID RSVP_HOP object:
最後に、RSVPのTTLチェック対IP TTLが行われてはなりません。 IF_ID RSVP_HOPオブジェクトが使用される場合、制御プレーン上のホップの数が1より大きくてもよいように、一般的に、このチェックは、無効にされなければなりません。その代わりに、以下のチェックがIF_ID RSVP_HOPオブジェクトの受信機Yによって行われます。
1. Make sure that the data interface identified in the IF_ID RSVP_HOP object actually terminates on Y.
1. IF_ID RSVP_HOPオブジェクトで識別されるデータ・インタフェースは、実際にY.に終了していることを確認してください
2. Find the "other end" of the above data interface, say X. Make sure that the PHOP in the IF_ID RSVP_HOP object is a control channel address that belongs to the same node as X.
2. X.がIF_ID RSVP_HOPオブジェクト内のPHOPはXと同じノードに属している制御チャネルアドレスであることを確認してくださいと言う、上記のデータ・インターフェースの「もう一方の端を」検索
How check #2 is carried out is beyond the scope of this document; suffice it to say that it may require a Traffic Engineering Database, or the use of LMP [LMP], or yet other means.
どのように確認してください＃2は、この文書の範囲を超えて行われます。それはトラフィックエンジニアリングデータベース、またはLMPの使用[LMP]、またはさらに他の手段を必要とするかもしれないことを言えば十分。
An alternative method is to encapsulate the Path message in an IP tunnel (or, in the case that the Interface Switching Capability of the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the message to the tail-end of the FA-LSP, without the Router Alert option. This option may be needed if intermediate nodes process RSVP messages regardless of whether the Router Alert option is present.
別の方法は、IPトンネル内のPathメッセージをカプセル化することである（または、FA-LSPのインターフェーススイッチング能力がFA-LSP自体におけるPSC [1-4]である場合）、およびユニキャストメッセージにルータアラートオプションなしFA-LSPのテールエンド。このオプションは関係なく、ルータアラートオプションが存在するかどうかの中間ノードのプロセスRSVPメッセージ場合に必要とすることができます。
A PathErr sent in response to a Path message with an IF_ID RSVP_HOP object SHOULD contain an IF_ID HOP object. (Note: a PathErr does not normally carry an RSVP_HOP object, but in the case of separated control and data, it is necessary to identify the data channel in the PathErr message.)
IF_ID RSVP_HOPオブジェクトとPathメッセージに応答して送信されたPathErrはIF_ID HOP物を含むべきです。 （注：たPathErrは通常RSVP_HOPオブジェクトを運ばないが、分離された制御およびデータの場合には、のPathErrメッセージ内のデータ・チャネルを特定する必要があります。）
The Resv message back to the head-end of the FA-LSP (PHOP) is IP-routed to the PHOP in the Path message. If necessary, Resv Messages MAY be encapsulated in another IP header whose destination IP address is the PHOP of the received Path message.
Resvメッセージは、バックFA-LSP（PHOP）のヘッドエンドへのPathメッセージでPHOPにIPルーティングです。必要に応じて、RESVメッセージは、その宛先IPアドレスが受信されたPathメッセージのPHOPである別のIPヘッダでカプセル化することができます。
If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP, then the Request message MUST contain an IF_ID TLV [GCR-LDP] object, and the data interface identification MUST identify the FA-LSP.
一つのFA-LSP上にトンネリングするLSPをシグナリングするCR-LDPを使用している場合、その要求メッセージがIF_ID TLV [GCR-LDP]を含まなければならないオブジェクト、およびデータインタフェース識別はFA-LSPを識別しなければなりません。
Furthermore, the head-end LSR must create a targeted LDP session with the tail-end LSR. The Request (Mapping) message is unicast from the head-end (tail-end) to the tail-end (head-end).
さらに、ヘッドエンドLSRはテールエンドLSRと目標とのLDPセッションを作成する必要があります。要求（マッピング）メッセージは、末尾（ヘッドエンド）にヘッドエンド（テール端部）からユニキャストです。
When an LSR receives a Path/Request message, the LSR determines whether it is at the edge of a region with respect to the ERO carried in the message. The LSR does this by looking up the interface switching capabilities of the previous hop and the next hop in its IGP database, and comparing them using the relation defined in this section. If the LSR is not at the edge of a region, the procedures in this section do not apply.
LSRは、パス/要求メッセージを受信した場合、LSRは、それがメッセージ中で搬送EROに対する領域のエッジであるか否かを判定する。 LSRは、前のホップとそのIGPデータベース内の次のホップの機能を切り替えるインタフェースを検索し、このセクションで定義された関係を使用してそれらを比較することによってこれを行います。 LSRは、領域のエッジではない場合、このセクションの手順は適用されません。
If the LSR is at the edge of a region, it must then determine the other edge of the region with respect to the ERO, again using the IGP database. The LSR then extracts (from the ERO) the subsequence of hops from itself to the other end of the region.
LSRは、領域の端にある場合、それは再びIGPデータベースを使用して、EROに対する領域の他のエッジを決定しなければなりません。 LSRは、次いで、領域の他端に（EROから）自身からのホップのシーケンスを抽出します。
The LSR then compares the subsequence of hops with all existing FA-LSPs originated by the LSR. If a match is found, that FA-LSP has enough unreserved bandwidth for the LSP being signaled, the L3PID of the FA-LSP is compatible with the L3PID of the LSP being signaled, and the LSR uses that FA-LSP as follows. The Path/Request message for the original LSP is sent to the egress of the FA-LSP, not to the next hop along the FA-LSP's path. The PHOP in the message is the address of the LSR at the head-end of the FA-LSP. Before sending the Path/Request message, the ERO in that message is adjusted by removing the subsequence of the ERO that lies in the FA-LSP, and replacing it with just the end point of the FA-LSP.
LSRは、LSRによって発信され、既存のすべてのFA-LSPをとホップのサブシーケンスを比較します。一致がFA-LSPは、LSPのための十分な未予約帯域幅シグナリングされたことが、発見された場合、FA-LSPのL3PIDが通知されるLSPのL3PIDと互換性があり、そして次のようにLSRは、FA-LSPを使用します。元のLSPのためのパス/ RequestメッセージはしないFA-LSPの経路に沿った次のホップに、FA-LSPの出口に送られます。メッセージ内のPHOPは、FA-LSPのヘッドエンドにおけるLSRのアドレスです。パス/要求メッセージを送信する前に、そのメッセージにおけるEROがFA-LSPにあるEROのサブシーケンスを除去し、FA-LSPのちょうど終点でそれを置き換えることによって調整されます。
Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA-LSP. That is, it initiates a new LSP setup just for the FA-LSP. Note that the new LSP may traverse either 'basic' TE links or FAs.
そうでない場合（既存のFA-LSPが見つからない場合）、LSRは新しいFA-LSPを設定します。それはそれだけでFA-LSPのための新しいLSPのセットアップを開始、です。新しいLSPは、「基本的な」TEリンクやFAのいずれかを通過することがあります。
After the LSR establishes the new FA-LSP, the LSR announces this LSP into IS-IS/OSPF as an FA.
LSRが新しいFA-LSPを確立した後、LSRはFAとしてIS-IS / OSPFにこのLSPを発表しました。
The unreserved bandwidth of the FA is computed by subtracting the bandwidth of sessions pending the establishment of the FA-LSP associated from the bandwidth of the FA-LSP.
FAの未予約帯域幅は、FA-LSPの帯域幅から関連FA-LSPの確立を保留中のセッションの帯域幅を減算することにより計算されます。
An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP as a matter of policy local to the LSR. It is expected that the FA-LSP would be torn down once there are no more LSPs carried by the FA-LSP. When the FA-LSP is torn down, the FA associated with the FA-LSP is no longer advertised into IS-IS/OSPF.
FA-LSPがLSRへのローカルポリシーの問題として、FA-LSPのヘッドエンドでのLSRによって取り壊さすることができます。 FA-LSPはかつてFA-LSPによって運ばれ、それ以上のLSPが存在しない取り壊されることが期待されます。 FA-LSPが切断された場合、FA-LSPに関連したFAは、もはやIS-IS / OSPFにアドバタイズされません。
The value of the holding priority of an FA-LSP must be the minimum of the configured holding priority of the FA-LSP and the holding priorities of the LSPs tunneling through the FA-LSP (note that smaller priority values denote higher priority). Thus, if an LSP of higher priority than the FA-LSP tunnels through the FA-LSP, the FA-LSP is itself promoted to the higher priority. However, if the tunneled LSP is torn down, the FA-LSP need not drop its priority to its old value right away; it may be advisable to apply hysteresis in this case.
FA-LSPの保持優先度の値は、FA-LSP（小さな優先値が高い優先順位を示すことに留意されたい）を介してFA-LSPとのLSPトンネルの保持優先度の設定された保持優先度の最小値でなければなりません。したがって、FA-LSPを介してFA-LSPトンネルよりも高い優先順位のLSP場合、FA-LSPは、より高い優先度に昇格自体です。トンネリングされたLSPが切断された場合は、FA-LSPは、すぐに元の値にその優先順位を落とす必要はありません。この場合には、ヒステリシスを適用することが推奨されます。
If the holding priority of an FA-LSP is configured, this document restricts it to 0.
FA-LSPの保持優先度が設定されている場合、この文書は0に制限されます。
From a security point of view, the primary change introduced in this document is that the implicit assumption of a binding between data interfaces and the interface over which a control message is sent is no longer valid.
セキュリティの観点からは、本文書に導入プライマリ変更は、データ・インターフェースおよび制御メッセージが送信されるインタフェースとの間の結合の暗黙の仮定はもはや有効ではないことです。
This means that the "sending interface" or "receiving interface" is no longer well-defined, as the interface over which an RSVP message is sent may change as routing changes. Therefore, mechanisms that depend on these concepts (for example, the definition of a security association) need a clearer definition.
これは、RSVPメッセージが送信されるインタフェースがASルーティングの変更を変更することができるように「送信インターフェース」または「受信インターフェース」は、もはや十分に定義されないことを意味します。したがって、（例えば、セキュリティアソシエーションの定義）これらの概念に依存するメカニズムは、明確な定義を必要とします。
[RFC2747] provides a solution: in Section 2.1, under "Key Identifier", an IP address is a valid identifier for the sending (and by analogy, receiving) interface. Since RSVP messages for a given LSP are sent to an IP address that identifies the next/previous hop for the LSP, one can replace all occurrences of 'sending [receiving] interface' with 'receiver's [sender's] IP address' (respectively). For example, in Section 4, third paragraph, instead of:
[RFC2747]は解決策を提供する：2.1節で、「鍵識別子」の下で、IPアドレスを送信（および類推により、受信）インターフェイスをするための有効な識別子です。所与のLSPのためのRSVPメッセージがLSPのために次/前のホップを識別するIPアドレスに送信されているので、一方が（それぞれ）「受信機の[送信者] IPアドレス」と「送信インターフェースを[受信]」のすべての発生を置き換えることができます。例えば、第4章、第三段落で、代わりに：
"Each sender SHOULD have distinct security associations (and keys) per secured sending interface (or LIH). ... At the sender, security association selection is based on the interface through which the message is sent."
「各送信側が固定送信インターフェース（またはLIH）ごとに個別のセキュリティアソシエーション（およびキー）を有するべきである。...送信側で、セキュリティアソシエーションの選択は、メッセージが送信されるインターフェイスに基づいています。」
it should read:
読み込みする必要があります。
"Each sender SHOULD have distinct security associations (and keys) per secured receiver's IP address. ... At the sender, security association selection is based on the IP address to which the message is sent."
「各送信者がセキュリティで保護された受信者のIPアドレスごとに個別のセキュリティアソシエーション（およびキー）を持つべきである（SHOULD）。...送信者では、セキュリティアソシエーションの選択は、メッセージが送信されるIPアドレスに基づいています。」
Note that CR-LDP does not have this issue, as CR-LDP messages are sent over TCP sessions, and no assumption is made that these sessions are to direct neighbors. The recommended mechanism for authentication and integrity of LDP message exchange is to use the TCP MD5 option [LDP].
CR-LDPメッセージがTCPセッションを介して送信され、そして何の仮定は、これらのセッションは、直接隣人にしていると判断されていないとして、CR-LDPは、この問題を持っていないことに注意してください。 LDPメッセージ交換の認証と完全性のために推奨されるメカニズムは、TCP MD5オプション[LDP]を使用することです。
Another consequence (relevant to RSVP) of the changes proposed in this document is that IP destination address of Path messages be set to the receiver's address, not to the session destination. Thus, the objections raised in Section 1.2 of [RFC2747] should be revisited to see if IPSec AH is now a viable means of securing RSVP-TE messages.
この文書で提案された変更の（RSVPに関連する）他の結果は、PathメッセージのIP宛先アドレスがないセッションの宛先に、受信者のアドレスに設定されていることです。したがって、[RFC2747]のセクション1.2で提起された異議は、IPSec AHは現在、RSVP-TEメッセージを確保する実行可能な手段であるかどうかを確認するために再検討する必要があります。
Many thanks to Alan Hannan, whose early discussions with Yakov Rekhter contributed greatly to the notion of Forwarding Adjacencies. We would also like to thank George Swallow, Quaizar Vohra and Ayan Banerjee.
早期の議論ヤコフ・レックターとフォワーディングの隣接関係の概念に大きく貢献したアラン・阪南、に感謝します。また、ジョージ・ツバメ、Quaizar Vohra著とアヤンバネルジーに感謝したいと思います。
[GCR-LDP] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[GCR-LDP]アッシュウッド・スミス、P。およびL.バーガー、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング制約ベースルーティングのラベル配布プロトコル（CR-LDP）の拡張"、RFC 3472、2003年1月。
[GMPLS-ISIS] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[GMPLS-ISIS] Kompella、K.、エド。、およびY. Rekhter、エド。、 "中間システム中間システム（ISIS）一般マルチプロトコルラベルのサポートで拡張機能は（GMPLS）をスイッチングする"、RFC 4205、 2005年10月。
[GMPLS-OSPF] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[GMPLS-OSPF] Kompella、K.、エド。、およびY. Rekhter、エド。、 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4203、2005月。
[GRSVP-TE] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GRSVP-TE]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[GSIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GSIG]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]スミット、H.、およびT.李、 "トラフィックエンジニアリングのための中間システム（ISIS）拡張機能（TE）への中間システム"、RFC 3784、2004年6月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "ラベル配布プロトコル"、RFC 3036、2001年1月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[UNNUM-CRLDP] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[UNNUM-CRLDP] Kompella、K.、Rekhter、Y.、およびA. Kullberg、 "CRLDPにおけるシグナリングアンナンバードリンク（制約ルーティングラベル配布プロトコル）"、RFC 3480、2003年2月。
[UNNUM-RSVP] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[UNNUM-RSVP] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[BUNDLE] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[LMP] Lang, L., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP]ラング、L.、エド。、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年10月。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニューサニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークス株式会社1194 N.マチルダアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、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機能のための基金は現在、インターネット協会によって提供されます。