[要約] RFC 4206は、GMPLSトラフィックエンジニアリング（TE）におけるラベルスイッチパス（LSP）の階層化に関するものです。このRFCの目的は、ネットワークの効率性と柔軟性を向上させるために、LSPの階層化を実現する方法を提案することです。
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)
一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を使用したラベルスイッチ付きパス（LSP）階層
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).
Copyright（c）The Internet Society（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）を集約することが役立つ場合があります。このような階層を作成する方法は、（a）ラベルスイッチングルーター（LSR）トラフィックエンジニアリングラベルスイッチパス（TE LSP）を作成することです。トラフィックエンジニアリング（TE）としてのこのLSPは、LSPを作成するために使用されたものと同じインスタンスのISIS/OSPFのインスタンスにリンクします）、（c）他のLSRがパス計算にFAを使用できるようにし、（d）ネスト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は、一般化されたMPLS（GMPLS）TE手順を使用して、LSPを作成および維持します。その後、LSRは（ローカル構成制御の下で）このLSPを、トラフィックエンジニアリング（TE）リンクとして、GMPLSコントロールプレーンの同じインスタンス（より正確には、ISIS/OSPFコンポーネント）と同じインスタンスとして発表します。LSP。このようなリンクを「転送隣接」（FA）と呼びます。LSPを「転送隣接LSP」、またはFA-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）には、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は、FASに関する情報を他のリンクに関する情報に浸水させます。この洪水の結果、LSRはTE Link Stateデータベースに、基本的なリンクだけでなくFASに関する情報もあります。
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リンクだけでなくFASも使用します。パスが計算されると、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は、ヘッドエンド以外のノードによって通常のSPFで使用されるISISまたはOSPFへのポイントツーポイントリンクとして宣伝される場合があることに注意してください。これは精神が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.
GMPLSコントロールプレーンのあるインスタンスによってLSPが作成（および維持される）シナリオは、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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の処理に関する手順について説明します。具体的には、このセクションでは、LSPをISIS/OSPFへのリンクとして宣伝するために必要な情報を構築する方法について説明します。このようなLSPの作成/終了の手順は、セクション5「FA-LSPの境界を制御する」で定義されています。
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アドレスで番号が付けられている場合、FA-LSPを発信するLSRによって割り当てられるA /31からローカルおよびリモートIPv4アドレスが出てきます。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.
すべてが1つのLSRで発生し、すべてが別のLSRで終了する複数のLSPがある場合、スペクトルの一方の端ですべてのLSPを（ヘッドエンドLSRの制御下）リンクの概念を使用して単一のFAにマージすることができますバンドリング（[bundle]を参照）;一方、スペクトルのもう一方の端には、そのような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に対して次の属性を構成できます。テールエンドアドレス;帯域幅とリソースの色の制約。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で個別の帯域幅のみが利用可能である場合は大きい場合があります。一般に、動的にプロビジョニングされたFASの場合、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-rsvp]、[unnum-crldp]で指定されています。
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メトリックはMAX（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リンクのSRLGの結合です。IS-ISのSRLG TLVまたはOSPFのTEリンク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).
FAがバンドルされている場合（リンクバンドリングを介して）、結果のバンドルされたリンクがSRLG TLVを持っている場合、基礎となるパスのSRLGのリストが続き、次にコンポーネントリンクを形成する各FA-LSPが続く必要があります。同じです（正確なパスは同じではないことに注意してください）。
It is expected that FAs will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency.
FASは、隣接の端でルーター間の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の拡張性ISに到達可能性TLVのデフォルトメトリックを最大リンクメトリック（2^24-1）に設定することで実現できます。OSPFでは、これはリンクを通常の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の境界を制御するために、このドキュメントでは、インターフェイススイッチング機能（[gmpls-isis、gmpls-sospf]を参照）と「LSP領域」（または「領域」）の2つの新しいメカニズムを紹介します。
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。インターフェイススイッチング機能をそれぞれISC-1とISC-2で2つのインターフェイスIF-1とIF-2が与えられた場合、IF-1 <IF-2 ISC-1 <ISC-2またはISC-1 == ISC-2 === 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.
LSPのパスが次のとおりです。Node-0、link-1、node-1、link-2、node-2、...、link-n、node-n。さらに、link-iの場合、[link-i、node-（i-1）]によって、link-iをノード（i-1）に接続するインターフェイスと[link-i、node-i]によってインターフェイスを示します。それはlink-iをnode-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].
[link-（i 1）、node-i）] <[link-（i 1）、node-（i 1）]]の場合、LSPはnode-iで領域の境界を越えたと言います。そのLSPパスに関しては、Node-IのLSRはEdge LSRです。LSPパスに関する領域の「その他のエッジ」はノードKです。ここで、kは[link-（i 1）、node-（i 1）]等しい[link-k]よりも私よりも最小の数です。、node-（k-1）]、および[link-k、node-（k-1）]> [link-k、node-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のパスを計算すると、パス計算が領域の境界を考慮することがあります。たとえば、PATH計算により、LSPがとるパスが、インターフェイススイッチング機能がPSC-1であるリンクのみに制限される場合があります。
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.
インターフェイスには複数のインターフェイススイッチング機能がある場合があることに注意してください。そのような場合、テストは、if-i <if-jがif-iおよびif-jに対して選択されたインターフェイススイッチング機能に依存しているかどうかであり、Node-Iに領域境界があるかどうかを決定します。
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以外のメカニズム（たとえば、管理制御を介して）またはGMPLS内のメカニズム（たとえば、凝集体LSPの端でのLSRの結果としてトリガーされる可能性があります。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.
いずれかの場合（RSVP-TEまたはCR-LDP）、LSPがFA-LSPを通じてトンネル化されると、FA-LSPのヘッドエンドでLSRがLSPの帯域幅をFAの非予約帯域幅から減算します。
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.
リンクバンドルの存在下で（LinkバンドリングがFASに適用される場合）、LSPがFA-LSPを通じてトンネル化されると、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.
RSVP-TEを使用してLSPを信号に合わせてFA-LSPにトンネルしている場合、パスメッセージには、RSVP_HOPオブジェクトの代わりにIF_ID RSVP_HOPオブジェクト[GRSVP-TE、GSIG]を含める必要があります。また、データインターフェイス識別は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.
パスメッセージを送信する推奨される方法は、パスメッセージのパスメッセージの宛先IPアドレスを計算されたNHOPに設定することです。この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.
さらに、パスメッセージのIPヘッダーには、ルーターアラートオプションが必要です。パスメッセージは、中間ノードのいずれかによって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:
最後に、IP TTL対RSVP 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_IDRSVP_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.
Check＃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トンネルのパスメッセージをカプセル化することです（または、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オブジェクトを使用してパスメッセージに応答して送信されたpatherrは、if_idホップオブジェクトを含める必要があります。（注：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.
FA-LSP（PHOP）のヘッドエンドに戻るRESVメッセージは、パスメッセージ内のPHOPにIP-Routedです。必要に応じて、RESVメッセージは、宛先IPアドレスが受信パスメッセージの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.
CR-LDPを使用してLSPをFA-LSPでトンネル化するように信号を送信する場合、リクエストメッセージには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は、HOPのサブシーケンスを、LSRによって発生するすべての既存のFA-LSPと比較します。一致が見つかった場合、FA-LSPにはLSPがシグナル伝達されるのに十分な予約されていない帯域幅があり、FA-LSPのL3PIDはLSPのL3PIDと互換性があり、LSRは次のようにFA-LSPを使用します。元のLSPのパス/リクエストメッセージは、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は、「基本的な」リンクまたはFASのいずれかを横断する可能性があることに注意してください。
After the LSR establishes the new FA-LSP, the LSR announces this LSP into IS-IS/OSPF as an FA.
LSRが新しいFA-LSPを確立した後、LSRはこのLSPをFAとしてIS-IS/OSPFに発表します。
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が運ぶLSPがなくなると、FA-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を通るLSPSトンネルの保持優先度でなければなりません（優先度の値が小さいことは優先度が高いことに注意してください）。したがって、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メッセージが送信されるインターフェイスがルーティングの変更に応じて変更される可能性があるため、「インターフェイスの送信」または「インターフェイスの受信」が明確に定義されなくなることを意味します。したがって、これらの概念（たとえば、セキュリティ協会の定義）に依存するメカニズムには、より明確な定義が必要です。
[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では、次の代わりに3番目の段落で
"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アドレスごとに異なるセキュリティ協会（およびキー）が必要です。...送信者では、セキュリティ協会の選択は、メッセージが送信される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、Ayan Banerjeeにも感謝します。
[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] Ashwood-Smith、P。and L. Berger、「一般化されたマルチプロトコルラベルスイッチング（GMPL）シグナリング制約ベースのルーティングラベル分布プロトコル（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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、2005年10月、RFC 4203。
[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] Berger、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] Berger、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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（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] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「Label Distribution Protocol」、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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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、「CR-LDP（Constraint-routing Label Distribution Protocol）の数のリンクのシグナリング」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、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.
[バンドル] Kompella、K.、Rekhter、Y。、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[LMP] Lang, L., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP] Lang、L.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Ave Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks、Inc。1194 N. Mathilda Ave Sunnyvale、CA 94089
EMail: yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。