[要約] RFC 6107は、動的にシグナリングされる階層的なラベルスイッチパスの手順に関するものです。その目的は、階層的なパスの設定と制御を効率的に行うための手順を提供することです。
Internet Engineering Task Force (IETF) K. Shiomoto, Ed.
Request for Comments: 6107 NTT
Updates: 3477, 4206 A. Farrel, Ed.
Category: Standards Track Old Dog Consulting
ISSN: 2070-1721 February 2011
Procedures for Dynamically Signaled Hierarchical Label Switched Paths
動的に信号された階層ラベルスイッチされたパスの手順
Abstract
概要
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.
マルチプロトコルラベルスイッチング（MPLS）または一般化されたMPLS（GMPLS）ネットワークでセットアップされたラベルスイッチ付きパス（LSP）ネットワークを使用して、それらのネットワークまたは他の（クライアント）ネットワークでトラフィックを運ぶリンクを形成できます。
Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process.
このようなLSPの確立を促進し、トラフィックエンジニアリング（TE）リンクをバンドルするために、ルーティングプロトコルの負荷を減らすために、プロトコルメカニズムがすでに存在しています。このドキュメントでは、これらのメカニズムへの拡張機能を定義して、そのようなLSPを配置する使用の識別をサポートし、シグナル伝達プロセス中にTEリンクエンドポイントに割り当てられたアドレスまたは非仮定された識別子を可能にします。
The mechanisms defined in this document deprecate the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206.
このドキュメントで定義されているメカニズムは、RFC 4206で説明されている数字のリンクとして使用されるLSPのシグナル伝達の手法を非難します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6107.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6107で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction and Problem Statement ..............................3
1.1. Background .................................................4
1.1.1. Hierarchical LSPs ...................................4
1.1.2. LSP Stitching Segments ..............................5
1.1.3. Private Links .......................................5
1.1.4. Routing Adjacencies .................................5
1.1.5. Forwarding Adjacencies ..............................5
1.1.6. Client/Server Networks ..............................6
1.1.7. Link Bundles ........................................6
1.2. Desired Function ...........................................7
1.3. Existing Mechanisms ........................................7
1.3.1. LSP Setup ...........................................7
1.3.2. Routing Adjacency Establishment and Link
State Advertisement .................................7
1.3.3. TE Link Advertisement ...............................7
1.3.4. Configuration and Management Techniques .............8
1.3.5. Signaled Unnumbered FAs .............................8
1.3.6. Establishing Numbered FAs through Signaling
and Routing .........................................9
1.4. Overview of Required Extensions ...........................10
1.4.1. Efficient Signaling of Numbered FAs ................10
1.4.2. LSPs for Use as Private Links ......................10
1.4.3. Signaling an LSP for Use in Another Network ........10
1.4.4. Signaling an LSP for Use in a Link Bundle ..........11
1.4.5. Support for IPv4 and IPv6 ..........................11
1.4.6. Backward Compatibility .............................11
2. Overview of Solution ...........................................11
2.1. Common Approach for Numbered and Unnumbered Links .........11
2.2. LSP Usage Indication ......................................12
2.3. IGP Instance Identification ...............................12
2.4. Link Bundle Identification ................................12
2.5. Backward Compatibility ....................................12
3. Mechanisms and Protocol Extensions .............................13
3.1. LSP_TUNNEL_INTERFACE_ID Object ............................13
3.1.1. Existing Definition and Usage ......................13
3.1.2. Unnumbered Links with Action Identification ........13
3.1.3. IPv4 Numbered Links with Action Identification .....16
3.1.4. IPv6 Numbered Links with Action Identification .....17
3.2. Target IGP Identification TLV .............................18
3.3. Component Link Identification TLV .........................19
3.3.1. Unnumbered Component Link Identification ...........20
3.3.2. IPv4 Numbered Component Link Identification ........20
3.3.3. IPv6 Numbered Component Link Identification ........21
3.4. Link State Advertisement ..................................21
3.5. Message Formats ...........................................22
3.6. Error Cases and Non-Acceptance ............................22
3.7. Backward Compatibility ....................................24
4. Security Considerations ........................................25
5. IANA Considerations ............................................25
5.1. New Class Types ...........................................25
5.2. Hierarchy Actions .........................................26
5.3. New Error Codes and Error Values ..........................26
6. Acknowledgements ...............................................27
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Traffic Engineering (TE) links in a Multiprotocol Label Switching (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as hierarchical LSPs (H-LSPs).
マルチプロトコルラベルスイッチング（MPLS）または一般化されたMPLS（GMPLS）ネットワークのトラフィックエンジニアリング（TE）リンクは、ラベルスイッチ付きパス（LSP）[RFC4206]から構築できます。このようなLSPは、階層LSP（H-LSP）として知られています。
The LSPs established in one network may be used as TE links in another network, and this is particularly useful when a server layer network (for example, an optical network) provides LSPs for use as TE links in a client network (for example, a packet network). This enables the construction of a multilayer network (MLN) [RFC5212].
あるネットワークで確立されたLSPは、別のネットワークのTEリンクとして使用される場合があります。これは、サーバーレイヤーネットワーク（光学ネットワークなど）がクライアントネットワークでTEリンクとして使用するLSPを提供する場合に特に役立ちます（たとえば、パケットネットワーク）。これにより、多層ネットワーク（MLN）[RFC5212]の構築が可能になります。
When the number of TE links (created from LSPs or otherwise) between a pair of nodes grows large, it is inefficient to advertise them individually. This may cause scaling issues in configuration and in the routing protocols used to carry the advertisements. The solution (described in [RFC4201]) is to collect the TE links together and to advertise them as a single TE link called a link bundle.
ノードのペア間のTEリンクの数（LSPまたはその他から作成された）の数が大きくなると、個別に宣伝することは非効率的です。これにより、構成と広告の携帯に使用されるルーティングプロトコルのスケーリングの問題が発生する可能性があります。ソリューション（[RFC4201]で説明）は、TEリンクを収集し、リンクバンドルと呼ばれる単一のTEリンクとして宣伝することです。
These various mechanisms have proved to be very powerful in building dynamically provisioned networks, but, as set out later in this document, several issues have been identified during deployment with how LSPs are established and made available for use as H-LSPs or as components of a link bundle, and with how these links are advertised appropriately in an interior gateway protocol (IGP). These issues relate to how the LSP's endpoints coordinate two things: the use to which the LSP is put and the identifiers of the endpoints.
これらのさまざまなメカニズムは、動的にプロビジョニングされたネットワークの構築において非常に強力であることが証明されていますが、このドキュメントの後半に記載されているように、展開中にLSPがどのように確立され、H-LSPとして使用できるか、またはのコンポーネントとして使用できるようになったいくつかの問題が特定されています。リンクバンドル、およびこれらのリンクがインテリアゲートウェイプロトコル（IGP）で適切に宣伝される方法とともに。これらの問題は、LSPのエンドポイントが2つのことをどのように調整するかに関連しています：LSPが置かれる使用とエンドポイントの識別子。
This document provides solutions to these issues by defining mechanisms so that the ends of signaled LSPs can exchange information about:
このドキュメントは、メカニズムを定義することにより、これらの問題の解決策を提供し、シグナル付きLSPの終わりが以下の情報を交換できるようにします。
- Whether the LSP is an ordinary LSP or an H-LSP. - In which IGP instances the LSP should be advertised as a link. - How the client networks should make use of the new links. - Whether the link should form part of a bundle (and if so, which bundle). - How the link endpoints should be identified when advertised.
- LSPが通常のLSPであるかH-LSPであるか。 - IGPインスタンスLSPをリンクとして宣伝する必要があります。 - クライアントネットワークが新しいリンクを使用する方法。 - リンクがバンドルの一部を形成するかどうか（もしそうなら、どのバンドル）。 - 宣伝されたときにリンクのエンドポイントを識別する方法。
This document deprecates one of the mechanisms defined in [RFC4206] for the signaling of LSPs that are to be used as numbered TE links (see Sections 1.3.6 and 1.4.6 for more details), and provides extensions to the other mechanisms defined in [RFC4206] so that the use to which the new LSP is to be put may be indicated during signaling. It also extends the mechanisms defined in [RFC3477] for signaling unnumbered TE links.
このドキュメントは、番号付きのリンクとして使用されるLSPのシグナル伝達について[RFC4206]で定義されたメカニズムの1つを非推奨します（詳細については、セクション1.3.6および1.4.6を参照）。[RFC4206]新しいLSPを配置する使用をシグナリング中に示すことができるように。また、[RFC3477]で定義されているメカニズムを、非自己拠点の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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
[RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of H-LSPs is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of an H-LSP that can carry one or more other LSPs.
[RFC3031]は、MPLSラベルを積み重ねる方法を説明して、LSPが1つのLSPを別のLSPを実行してネストすることができるようにします。H-LSPのこの概念は、[RFC4206]で形式化されており、1つ以上の他のLSPを運ぶことができるH-LSPを確立するための一連のプロトコルメカニズムがあります。
[RFC4206] goes on to explain that an H-LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable (PSC) network, the H-LSP can carry other PSC LSPs using the MPLS label stack. In non-packet networks where the label is implicit, label stacks are not possible, and H-LSPs rely on the ability to nest switching technologies. Thus, for example, a lambda switch capable (LSC) LSP can carry a time-division multiplexing (TDM) LSP, but cannot carry another LSC LSP.
[RFC4206]は、H-LSPがスイッチングタイプに従って他のLSPを運ぶ可能性があることを説明し続けています。これは、ラベルが運ばれる方法の関数です。パケットスイッチ対応（PSC）ネットワークでは、H-LSPはMPLSラベルスタックを使用して他のPSC LSPを運ぶことができます。ラベルが暗黙的な非パケットネットワークでは、ラベルスタックは不可能であり、H-LSPはスイッチングテクノロジーをネストする機能に依存しています。したがって、たとえば、ラムダスイッチ対応（LSC）LSPには、時間帯マルチプレックス（TDM）LSPを運ぶことができますが、別のLSC LSPを運ぶことはできません。
Signaling mechanisms defined in [RFC4206] allow an H-LSP to be treated as a single hop in the path of another LSP (i.e., one hop of the LSP carried by the H-LSP). This mechanism is known as "non-adjacent signaling".
[RFC4206]で定義されているシグナル伝達メカニズムにより、H-LSPを別のLSPの経路で単一のホップとして扱うことができます（つまり、H-LSPによって運ばれるLSPの1つのホップ）。このメカニズムは、「非隣接シグナル伝達」として知られています。
LSP stitching is defined in [RFC5150]. It enables LSPs of the same switching type to be included (stitched) as hops in an end-to-end LSP. The stitching LSP (S-LSP) is used in the control plane in the same way as an H-LSP, but in the data plane the LSPs are stitched so that there is no label stacking or nesting of technologies. Thus, an S-LSP must be of the same switching technology as the end-to-end LSP that it facilitates.
LSPステッチは[RFC5150]で定義されています。エンドツーエンドのLSPのホップとして、同じスイッチングタイプのLSPを含める（ステッチされた）ことを可能にします。ステッチLSP（S-LSP）は、H-LSPと同じ方法でコントロールプレーンで使用されますが、データプレーンでは、LSPがテクノロジーのラベルスタッキングまたはネストがないように縫い付けられます。したがって、S-LSPは、促進するエンドツーエンドLSPと同じスイッチングテクノロジーでなければなりません。
An H-LSP or S-LSP can be used as a private link. Such links are known by their endpoints, but are not more widely known and are not advertised by routing protocols. They can be used to carry traffic between the endpoints, but are not usually used to carry traffic that is going beyond the egress of the LSP.
H-LSPまたはS-LSPは、プライベートリンクとして使用できます。このようなリンクはエンドポイントで知られていますが、それほど広く知られておらず、ルーティングプロトコルによって宣伝されていません。それらはエンドポイント間のトラフィックを運ぶために使用できますが、通常、LSPの出口を超えて行くトラフィックを運ぶためには使用されません。
A routing adjacency is formed between two IGP speakers that are logically adjacent. In this sense, 'logically adjacent' means that the routers have a protocol tunnel between them through which they can exchange routing protocol messages. The tunnel is also usually available for carrying IP data although a distinction should be made in GMPLS networks between data-plane traffic and control-plane traffic.
ルーティング隣接は、論理的に隣接する2つのIGPスピーカー間に形成されます。この意味で、「論理的に隣接する」とは、ルーターの間にルーター間のプロトコルトンネルがあることを意味し、ルーティングプロトコルメッセージを交換できます。トンネルは通常、IPデータを運ぶためにも利用できますが、データプレーントラフィックとコントロールプレーントラフィックの間のGMPLSネットワークで区別を作成する必要があります。
Routing adjacencies for forwarding data traffic are only relevant in PSC networks (i.e., IP/MPLS networks).
データトラフィックを転送するためのルーティング隣接は、PSCネットワーク（つまり、IP/MPLSネットワーク）にのみ関連します。
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP.
フォワーディング隣接（FA）は、[RFC4206]でLSPから作成されたデータリンクとして定義され、LSPが構築されているTEリンクを宣伝するコントロールプレーンの同じインスタンスで宣伝されています。LSP自体はFA-LSPと呼ばれます。
Thus, an H-LSP or S-LSP may form an FA such that it is advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that the LSP traverses.
したがって、H-LSPまたはS-LSPはFAを形成して、LSPが移動するTEリンクを宣伝するために使用されたのと同じインスタンスのルーティングプロトコルのTEリンクとして宣伝されるようになります。
As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency.
[RFC4206]で観察されているように、FAの端にあるノードには通常、ルーティング隣接がありません。
An LSP may be created in one network and used as a link (sometimes called a virtual link) in another network [RFC5212]. In this case, the networks are often referred to as server and client networks, respectively.
LSPは1つのネットワークで作成され、別のネットワーク[RFC5212]のリンク（仮想リンクと呼ばれることもあります）として使用できます。この場合、ネットワークはそれぞれサーバーとクライアントのネットワークと呼ばれることがよくあります。
The server network LSP is used as an H-LSP or an S-LSP as described above, but it does not form an FA because the client and server networks run separate instances of the control-plane routing protocols.
サーバーネットワークLSPは、上記のようにH-LSPまたはS-LSPとして使用されますが、クライアントとサーバーネットワークがコントロールプレーンルーティングプロトコルの個別のインスタンスを実行するため、FAを形成しません。
The virtual link may be used in the client network as a private link or may be advertised in the client network IGP. Additionally, the link may be used in the client network to form a routing adjacency and/or as a TE link.
仮想リンクは、クライアントネットワークでプライベートリンクとして使用されるか、クライアントネットワークIGPで宣伝される場合があります。さらに、リンクをクライアントネットワークで使用して、ルーティングの隣接性および/またはTEリンクとして形成することができます。
[RFC4201] recognizes that a pair of adjacent routers may have a large number of TE links that run between them. This can be a considerable burden to the operator who may need to configure them and to the IGP that must distribute information about each of them. A TE link bundle is defined by [RFC4201] as a TE link that is advertised as an aggregate of multiple TE links that could have been advertised in their own right. All TE links that are collected into a TE link bundle have the same TE properties.
[RFC4201]は、隣接するルーターのペアに、それらの間で実行される多数のTEリンクがあることを認識しています。これは、それらを構成する必要がある可能性のあるオペレーターと、それらのそれぞれに関する情報を配布する必要があるIGPにかなりの負担となる可能性があります。TEリンクバンドルは、[RFC4201]によって定義され、それ自体で宣伝される可能性のある複数のTEリンクの集計として宣伝されているTEリンクとして定義されます。TEリンクバンドルに収集されたすべてのTEリンクには、同じプロパティがあります。
Thus, a link bundle is a shorthand that improves the scaling properties of the network.
したがって、リンクバンドルは、ネットワークのスケーリングプロパティを改善する速記です。
Since a TE link may, itself, be an LSP (either an FA or a virtual link), a link bundle may be constructed from FA-LSPs or virtual links.
TEリンクは、それ自体がLSP（FAまたは仮想リンクのいずれか）である可能性があるため、FA-LSPまたは仮想リンクからリンクバンドルを構築できます。
It should be possible to signal an LSP and automatically coordinate its use and advertisement in any of the ways described in Section 1.3 with minimum involvement from an operator. The mechanisms used should be applicable to numbered and unnumbered links and should not require implementation complexities.
LSPを信号に合わせて、セクション1.3で説明した方法でその使用と広告を自動的に調整することが可能であるはずです。使用されるメカニズムは、番号付きのリンクと数のないリンクに適用できる必要があり、実装の複雑さを必要としないでください。
This section briefly introduces existing protocol mechanisms used to satisfy the desired function described in Section 1.2.
このセクションでは、セクション1.2で説明する目的の関数を満たすために使用される既存のプロトコルメカニズムを簡単に紹介します。
Both unidirectional LSPs and bidirectional LSPs are signaled from the ingress label switching router (LSR) to the egress LSR. That is, the ingress LSR is the initiator, and the egress learns about the LSP through the signaling protocol [RFC3209] [RFC3473].
単方向LSPと双方向LSPの両方が、侵入ラベルスイッチングルーター（LSR）から出口LSRにシグナル伝達されます。つまり、イングレスLSRはイニシエーターであり、出口はシグナル伝達プロトコル[RFC3209] [RFC3473]を介してLSPについて学習します。
Although hosts can discover routers (for example, through ICMP [RFC1256]), routing adjacencies are usually configured at both ends of the adjacency. This requires that each router know the identity of the router at the other end of the link connecting the routers, and know that the IGP is to be run on this link.
ホストはルーターを発見できますが（たとえば、ICMP [RFC1256]）、ルーティング隣接は通常、隣接の両端で構成されます。これには、各ルーターがルーターを接続するリンクのもう一方の端にあるルーターのアイデンティティを把握し、このリンクでIGPを実行することを知る必要があります。
Once a routing adjacency has been established, a pair of routers may use the IGP to share information about the links available for carrying IP traffic in the network.
ルーティングの隣接性が確立されると、1組のルーターがIGPを使用して、ネットワーク内のIPトラフィックを運ぶために利用可能なリンクに関する情報を共有する場合があります。
Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], and IS-IS [RFC1195].
適切なルーティングプロトコルは、OSPFバージョン2 [RFC2328]、OSPFバージョン3 [RFC5340]、およびIS [RFC1195]です。
Extensions have been made to IGPs to advertise TE link properties ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and also to advertise link properties in GMPLS networks ([RFC4202], [RFC4203], and [RFC5307]).
IGPSに拡張機能が作成され、TEリンクプロパティ（[RFC3630]、[RFC5329]、[RFC5305]、[RFC5308]、および[ISIS-IPV6-TE]）を宣伝し、GMPLSネットワークのリンクプロパティを宣伝します（[RFC4202]、[RFC4203]、および[RFC5307]）。
TE link advertisement can be performed by the same instance of the IGP as is used for normal link state advertisement, or can use a separate instance. Furthermore, the ends of a TE link advertised in an IGP do not need to form a routing adjacency. This is particularly the case with FAs as described in Section 1.1.5.
TEリンク広告は、通常のリンク状態広告に使用されるのと同じIGPのインスタンスによって実行されるか、別のインスタンスを使用することができます。さらに、IGPで宣伝されているTEリンクの端は、ルーティング隣接を形成する必要はありません。これは、セクション1.1.5で説明されているように、FASの場合に特に当てはまります。
LSPs are usually created as the result of a management action. This is true even when a control plane is used: the management action is a request to the control plane to signal the LSP.
LSPは通常、管理アクションの結果として作成されます。これは、コントロールプレーンが使用されている場合でも当てはまります。管理アクションは、LSPに信号を送るためのコントロールプレーンへの要求です。
If the LSP is to be used as an H-LSP or S-LSP, management commands can be used to install the LSP as a link. The link must be defined, interface identifiers allocated, and the endpoints configured to know about (and advertise, if necessary) the new link.
LSPをH-LSPまたはS-LSPとして使用する場合、管理コマンドを使用してLSPをリンクとしてインストールできます。リンクを定義し、インターフェイス識別子が割り当てられ、エンドポイントは新しいリンクについて知る（および必要に応じて宣伝する）ように構成されている必要があります。
If the LSP is to be used as part of a link bundle, the operator must decide which bundle it forms part of and ensure that information is configured at the ingress and egress, along with the necessary interface identifiers.
LSPをリンクバンドルの一部として使用する場合、オペレーターは、どのバンドルを形成するかを決定し、必要なインターフェイス識別子とともに、イングレスと出口で情報が構成されていることを確認する必要があります。
These mechanisms are perfectly functional and quite common in MLNs, but require configuration coordination and additional management. They are open to user error and misconfiguration that might result in the LSP not being used (a waste of resources) or the LSP being made available in the wrong way with some impact on traffic engineering.
これらのメカニズムは完全に機能的であり、MLNで非常に一般的ですが、構成調整と追加の管理が必要です。それらは、LSPが使用されない可能性のあるユーザーエラーと誤解を受け入れています（リソースの無駄）またはLSPは、トラフィックエンジニアリングにある程度の影響を与え、間違った方法で利用可能になります。
[RFC3477] describes how to establish an LSP and to make it available automatically as a TE link in the same instance of the routing protocol as advertises the TE links it traverses, using IPv4-based unnumbered identifiers to identify the new TE link. That is, [RFC3477] describes how to create an unnumbered FA.
[RFC3477]は、LSPを確立する方法と、ルーティングプロトコルの同じインスタンスとしてTEリンクとして自動的に利用可能にする方法を説明しています。TEリンクを宣伝し、IPv4ベースの番号のない識別子を使用して新しいTEリンクを識別します。つまり、[rfc3477]は、数え切れないほどのFAを作成する方法について説明しています。
The mechanism, as defined in Section 3 of [RFC3477], is briefly as follows:
[RFC3477]のセクション3で定義されているメカニズムは、次のとおりです。
- The ingress of the LSP signals the LSP as normal using a Path message, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The sender's LSR Router ID - The sender's interface ID for the TE link being created
- LSPの侵入は、パスメッセージを使用して通常どおりLSPを信号し、LSP_TUNNEL_INTERFACE_IDオブジェクトを含みます。lsp_tunnel_interface_idオブジェクト識別： - 送信者のLSRルーターID-作成中のTEリンクの送信者のインターフェイスID
- The egress of the LSP responds as normal to accept the LSP and set it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The egress's LSR Router ID - The egress's interface ID for the TE link being created.
- LSPの出口は、LSPを受け入れてセットアップするために通常どおり応答し、LSP_Tunnel_interface_IDオブジェクトを含みます。lsp_tunnel_interface_idオブジェクトは識別されます。
- Following the exchange of the Path and Resv messages, both the ingress and the egress know that the LSP is to be advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that it traverses, and also know the unnumbered interface identifiers to use in the advertisement.
- パスメッセージとRESVメッセージの交換に続いて、イングレスと出口の両方は、LSPが、それが通過するTEリンクを宣伝するために使用されたルーティングプロトコルの同じインスタンスでTEリンクとして宣伝されることを知っています。広告で使用する番号のないインターフェイス識別子を知ってください。
[RFC3477] does not include mechanisms to support IPv6-based unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers.
[RFC3477]には、IPv6ベースの非仮定識別子もIPv4またはIPv6番号付き識別子もサポートするメカニズムは含まれていません。
[RFC4206] describes procedures to establish an LSP and to make it available automatically as a TE link that is identified using IPv4 addresses in the same instance of the routing protocol as advertises the TE links it traverses (that is, as a numbered FA).
[RFC4206]は、LSPを確立し、ルーティングプロトコルの同じインスタンスでIPv4アドレスを使用して識別されるTEリンクとして自動的に利用可能にする手順を説明しています。
The mechanism, as defined in [RFC4206], is briefly as follows:
[RFC4206]で定義されているメカニズムは、次のように簡単になります。
- The ingress of the LSP signals the LSP as normal using a Path message, and sets the IPv4 tunnel sender address to the IP address it will use to identify its interface for the TE link being created. This is one address from a /31 pair.
- LSPの侵入は、パスメッセージを使用して通常どおりLSPを信号し、作成されるTEリンクのインターフェイスを識別するために使用するIPv4トンネル送信者アドレスをIPアドレスに設定します。これは、A /31ペアの1つのアドレスです。
- The egress of the LSP responds as normal to accept the LSP and set it up. It infers the address that it must assign to identify its interface for the TE link being created as the partner address of the /31 pair.
- LSPの出口は、LSPを受け入れてセットアップするために通常どおり応答します。/31ペアのパートナーアドレスとして作成されているTEリンクのインターフェイスを識別するために割り当てなければならないアドレスを推測します。
- The ingress decides whether the LSP is to be advertised as a TE link (i.e., as an FA). If so, it advertises the link in the IGP in the usual way.
- 侵入は、LSPをTEリンクとして宣伝されるかどうかを決定します（つまり、FAとして）。その場合、通常の方法でIGPのリンクを宣伝します。
- If the link is unidirectional, nothing more needs to be done. If the link is bidirectional, the egress must also advertise the link, but it does not know that advertisement is required as there is no indication in the signaling messages.
- リンクが単方向である場合、これ以上行う必要はありません。リンクが双方向である場合、出力もリンクを宣伝する必要がありますが、信号メッセージには兆候がないため、広告が必要であることはわかりません。
- When the ingress's advertisement of the link is received by the egress, it must check to see whether it is the egress of the LSP that formed the link. Typically, this means the egress: - Checks to see if the link advertisement is new. - Checks to see if the Link-ID address in the received advertisement matches its own TE Router ID. - Checks the advertising router ID from the advertisement against the ingress address of each LSP for which it is the egress. - Deduces the LSP that has been advertised as a TE link and issues the corresponding advertisement for the reverse direction.
- リンクのイングレスの広告が出口によって受信される場合、リンクを形成したのがLSPの出口であるかどうかを確認する必要があります。通常、これは出口を意味します。-リンク広告が新しいかどうかを確認します。 - 受信した広告のLink-IDアドレスが独自のTEルーターIDと一致するかどうかを確認します。 - 広告ルーターIDを、それが出口である各LSPの入り口アドレスに対して広告からチェックします。-TEリンクとして宣伝されているLSPを推定し、対応する広告を逆方向に発行します。
It is possible that some reduction in processing can be achieved by mapping based on the /31 pairing, but nevertheless, there is a fair amount of processing required, and this does not scale well in large networks.
/31ペアリングに基づいてマッピングすることで処理のいくらかの削減を達成できる可能性がありますが、それでもかなりの量の処理が必要であり、これは大規模なネットワークでは十分にスケーリングされません。
Note that this document deprecates this procedure as explained in Section 1.4.6.
この文書は、セクション1.4.6で説明されているように、この手順を非推奨していることに注意してください。
No explanation is provided in [RFC4206] of how to create numbered IPv6 FAs.
[RFC4206]には、番号付きのIPv6 FASの作成方法について説明は提供されていません。
This section provides a brief outline of the required protocol extensions.
このセクションでは、必要なプロトコル拡張の簡単な概要を示します。
The mechanism described in Section 1.3.6 is inefficient. The egress must wait until it receives an advertisement from the ingress before it knows that the LSP is to be installed as a TE link and advertised as an FA. Further, it must parse all received advertisements to determine if any is the trigger for it to advertise an FA.
セクション1.3.6で説明したメカニズムは非効率的です。出力は、LSPがTEリンクとしてインストールされ、FAとして宣伝されることを知る前に、イングレスから広告を受け取るまで待つ必要があります。さらに、受信したすべての広告を解析して、FAを宣伝するためのトリガーがあるかどうかを判断する必要があります。
An efficient signaling mechanism is required so that the egress is informed by the ingress during LSP establishment.
効率的なシグナル伝達メカニズムが必要であるため、LSP施設中の侵入によって出口が通知されるようにします。
There is currently no mechanism by which an ingress can indicate that an LSP is set up for use as a private link. Any attempt to make it a link would currently cause it to be advertised as an FA.
現在、イングレスがLSPがプライベートリンクとして使用するために設定されていることを示すメカニズムはありません。それをリンクにしようとすると、現在、FAとして宣伝されます。
A signaling mechanism is needed to identify the use to which an LSP is to be put.
LSPを配置する使用を特定するには、シグナル伝達メカニズムが必要です。
The existing signaling/routing mechanisms are designed for use in the creation of FAs. That is, the TE link created is advertised in the single IGP instance.
既存のシグナリング/ルーティングメカニズムは、FAの作成に使用するために設計されています。つまり、作成されたTEリンクは、単一のIGPインスタンスで宣伝されています。
The numbered TE link mechanism (Section 1.3.6) could, in theory, be used in an MLN with multiple IGP instances if the addressing model is kept consistent across the networks, and if the egress searches all advertisements in all IGP instances. However, this is complex and does not work for unnumbered interfaces.
番号付きのリンクメカニズム（セクション1.3.6）は、理論的には、アドレス指定モデルがネットワーク全体で一貫性を保ち、出力がすべてのIGPインスタンスですべての広告を検索する場合、複数のIGPインスタンスを持つMLNで使用できます。ただし、これは複雑であり、数のないインターフェイスでは機能しません。
A signaling mechanism is required to indicate in which IGP instance the TE link should be advertised.
IGPインスタンスのTEリンクを宣伝する必要があることを示すために、シグナル伝達メカニズムが必要です。
A signaling mechanism is required to indicate that an LSP is intended to form a component link of a link bundle, and to identify the bundle and the IGP instance in which the bundle is advertised.
LSPがリンクバンドルのコンポーネントリンクを形成し、バンドルとバンドルが宣伝されているIGPインスタンスを識別することを目的としていることを示すために、シグナル伝達メカニズムが必要です。
The protocol mechanisms must support IPv4 and IPv6 numbered and unnumbered TE links.
プロトコルメカニズムは、IPv4およびIPv6番号のないTEリンクをサポートする必要があります。
The existing protocol mechanisms for unnumbered FAs as defined in [RFC4206] and [RFC3477] must continue to be supported, and new mechanisms must be devised such that their introduction will not break existing implementations or deployments.
[RFC4206]および[RFC3477]で定義されている番号のないFASの既存のプロトコルメカニズムは引き続きサポートされ、導入が既存の実装や展開を破らないように新しいメカニズムを考案する必要があります。
Note that an informal survey in the CCAMP working group established that there are no significant deployments of numbered FAs established using the technique described in [RFC4206] and set out in Section 1.3.6. Therefore, this document deprecates this procedure.
CCAMPワーキンググループの非公式の調査では、[RFC4206]に記載され、セクション1.3.6に記載されている手法を使用して確立された数字のFAの重要な展開がないことを確認したことに注意してください。したがって、この文書はこの手順を非難します。
This section provides an overview of the mechanisms and protocol extensions defined in this document. Details are presented in Section 3.
このセクションでは、このドキュメントで定義されているメカニズムとプロトコル拡張の概要を説明します。詳細については、セクション3に記載されています。
The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for all H-LSPs and S-LSPs whether they form numbered or unnumbered IPv4 or IPv6 links. Different Class Types of the object identify the address type for which it applies.
LSP_TUNNEL_INTERFACE_IDオブジェクト[RFC3477]は、すべてのH-LSPSおよびS-LSPSが数字のIPv4またはIPv6リンクまたはIPv6リンクを数個形成するかどうかにかかわらず使用するために拡張されます。オブジェクトのさまざまなクラスタイプが適用されるアドレスタイプを識別します。
The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions field to say how the LSP is to be used. The following categories are supported:
LSP_TUNNEL_INTERFACE_IDオブジェクトには、LSPがどのように使用されるかを示す新しいアクションフィールドにフラグが与えられます。次のカテゴリがサポートされています。
- The LSP is used as an advertised TE link. - The LSP is used to form a routing adjacency. - The LSP is used to form an advertised TE link and a routing adjacency. - The LSP forms a private link and is not advertised. - The LSP is used as part of a link bundle. - The LSP is used as a hierarchical LSP or a stitching segment.
- LSPは、広告されたTEリンクとして使用されます。-LSPは、ルーティングの隣接を形成するために使用されます。-LSPは、広告されたTEリンクとルーティング隣接を形成するために使用されます。-LSPはプライベートリンクを形成し、宣伝されていません。-LSPは、リンクバンドルの一部として使用されます。-LSPは、階層LSPまたはステッチセグメントとして使用されます。
An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to identify the IGP instance into which the link formed by the LSP is to be advertised. If the TLV is absent and the link is to be advertised as indicated by the Actions field, the link is advertised in the same instance of the IGP as was used to advertise the TE links it traverses.
オプションのTLVがlsp_tunnel_interface_idオブジェクトに追加され、LSPによって形成されたリンクが宣伝されるIGPインスタンスを識別します。TLVが存在しない場合、アクションフィールドで示されるようにリンクを宣伝する場合、リンクは、トラバースのTEリンクを宣伝するために使用されたのと同じIGPの同じインスタンスで宣伝されます。
When an LSP is to be used as a component link of a link bundle, the LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how the bundle is addressed and used, and a new TLV indicates the component link identifier for the link that the LSP creates.
LSPをリンクバンドルのコンポーネントリンクとして使用する場合、LSP_TUNNEL_INTERFACE_IDオブジェクトは、バンドルのアドレス指定と使用方法を示すバンドルを指し、新しいTLVはLSPが作成するリンクのコンポーネントリンク識別子を示します。
Backward compatibility has three aspects.
後方互換性には3つの側面があります。
- Existing mechanisms for unnumbered FAs described in [RFC3477] and [RFC4206] must continue to work, so that ingress nodes do not have to be updated when egresses are updated.
- [RFC3477]および[RFC4206]に記載されている番号のないFASの既存のメカニズムは、出力を更新したときにイングレスノードを更新する必要がないように、引き続き機能し続ける必要があります。
- Existing mechanisms for establishing numbered FAs described in [RFC4206] are safely deprecated by this document, as they are not significantly deployed.
- [RFC4206]に記載されている番号の付いたFAを確立するための既存のメカニズムは、このドキュメントが大幅に展開されていないため、このドキュメントによって安全に非推奨されています。
- New mechanisms must be gracefully rejected by existing egress implementations so that egress nodes do not have to be updated when ingresses are updated.
- 新しいメカニズムは、既存の出力実装によって優雅に拒否されなければならないため、出口ノードを更新するときに更新する必要がないようにします。
This section defines protocol mechanisms and extensions to achieve the function described in the previous section.
このセクションでは、プロトコルメカニズムと拡張機能を定義して、前のセクションで説明した関数を実現します。
The principal signaling protocol element used to achieve all of the required functions is the LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. The existing definition and usage continues to be supported as described in the next section. Subsequent sections describe new variants of the object (denoted by new Class Types), and additional information carried in the object by means of extensions.
必要なすべての関数を達成するために使用される主要なシグナル伝達プロトコル要素は、[RFC3477]で定義されているLSP_TUNNEL_INTERFACE_IDオブジェクトです。既存の定義と使用法は、次のセクションで説明されているように引き続きサポートされています。次のセクションでは、オブジェクトの新しいバリアント（新しいクラスタイプで示されています）と、拡張機能によってオブジェクトに掲載された追加情報について説明します。
This document does not deprecate the mechanisms defined in [RFC3477] and [RFC4206]. Those procedures must continue to operate as described in Section 3.7.
この文書は、[RFC3477]および[RFC4206]で定義されているメカニズムを非難しません。これらの手順は、セクション3.7で説明されているとおり、引き続き動作する必要があります。
That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 remains unchanged, and can be used to establish an LSP that will be advertised as an unnumbered TE link in the same instance of the IGP as was used to advertise the TE links that the LSP traverses (that is, as an FA). The procedure is unchanged and operates as summarized in Section 1.3.5.
つまり、クラスタイプ1を持つLSP_TUNNEL_INTERFACE_IDオブジェクトは変更されておらず、LSPリンクの宣伝に使用されたのと同じインスタンスのIGPと同じインスタンスで、NOMUMBERED TEリンクとして宣伝されるLSPを確立するために使用できます（LSPが移動するTEリンクを宣伝することができます（つまり、FAとして）。この手順は変更されておらず、セクション1.3.5で要約されているように動作します。
[RFC3477] does not make any suggestions about where in Path or Resv messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See Section 3.5 for recommended placement of this object in new implementations.
[RFC3477]は、パスまたはRESVメッセージ内の場所について、LSP_TUNNEL_INTERFACE_IDオブジェクトを配置する必要がある場所について提案を行いません。新しい実装でのこのオブジェクトの推奨配置については、セクション3.5を参照してください。
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an unnumbered interface identifier and to indicate into which instance of the IGP the consequent TE link should be advertised. This does not deprecate the use of C-Type 1.
lsp_tunnel_interface_idオブジェクトの新しいc型バリアントは、数本のインターフェイス識別子を運ぶように定義され、結果として生じるteリンクを宣伝するIGPのインスタンスを示すように定義されます。これは、Cタイプ1の使用を非難するものではありません。
The format of the object is as shown below.
オブジェクトの形式は、以下に示すように示します。
C-NUM = 193, C-Type = 4
c-num = 193、c-type = 4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSR's Router ID
LSRのルーターID
Unchanged from the definition in [RFC3477].
[RFC3477]の定義から変更されていません。
Interface ID
インターフェイスID
Unchanged from the definition in [RFC3477].
[RFC3477]の定義から変更されていません。
Actions
行動
This field specifies how the LSP that is being set up is to be treated.
このフィールドは、セットアップされているLSPの処理方法を指定します。
The field has meaning only on a Path message. On a Resv message, the field SHOULD be set to reflect the value received on the corresponding Path message, and it MUST be ignored on receipt.
フィールドには、パスメッセージのみの意味があります。RESVメッセージでは、フィールドは、対応するパスメッセージで受信された値を反映するように設定する必要があり、受信時に無視する必要があります。
The field is composed of bit flags as follows:
フィールドは、次のようにビットフラグで構成されています。
-+-+-+-+-+-+-+-
| | | |H|B|R|T|P|
-+-+-+-+-+-+-+-
P-flag (Private) 0 means that the LSP is to be advertised as a link according to the settings of the other flags. 1 means the LSP is to form a private link and is not to be advertised in the IGP, but is to be used according to the settings of the other flags.
p-flag（private）0は、LSPが他のフラグの設定に従ってリンクとして宣伝されることを意味します。1は、LSPがプライベートリンクを形成することであり、IGPで宣伝されるのではなく、他のフラグの設定に従って使用されることを意味します。
T-flag (TE link) 0 means that the LSP is to be used as a TE link. 1 means that the LSP is not to be used as a TE link. It may still be used as an IP link providing a routing adjacency as defined by the R-flag.
T-Flag（TEリンク）0は、LSPをTEリンクとして使用することを意味します。1は、LSPをTEリンクとして使用しないことを意味します。r-flagで定義されているルーティング隣接を提供するIPリンクとして使用される場合があります。
R-flag (Routing adjacency) 0 means that the link is not to be used as a routing adjacency. 1 means that the link is to be used to form a routing adjacency.
r-flag（ルーティング隣接）0は、リンクをルーティング隣接として使用しないことを意味します。1は、リンクを使用してルーティング隣接を形成することを意味します。
B-flag (Bundle) 0 means that the LSP will not form part of a link bundle. 1 means that the LSP will form part of a bundle. See Section 3.3 for more details.
b-flag（bundle）0は、LSPがリンクバンドルの一部を形成しないことを意味します。1は、LSPがバンドルの一部を形成することを意味します。詳細については、セクション3.3を参照してください。
H-flag (Hierarchy/stitching) The use of an LSP as an H-LSP or as an S-LSP is usually implicit from the network technologies of the networks and the LSP, but this is not always the case (for example, in PSC networks). 0 means that the LSP is to be used as a hierarchical LSP. 1 means that the LSP is to be used as a stitching segment.
h-flag（階層/ステッチ）h-lspまたはs-lspとしてのLSPの使用は、通常、ネットワークとLSPのネットワークテクノロジーから暗黙的ですが、これは常にそうではありません（たとえば、PSCネットワーク）。0は、LSPが階層LSPとして使用されることを意味します。1は、LSPがステッチセグメントとして使用されることを意味します。
Other bits are reserved for future use. They MUST be set to zero on transmission and SHOULD be ignored on receipt.
他のビットは将来の使用のために予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Note that all defined bit flags have meaning at the same time. An LSP that is to form an FA would carry the Actions field set to 0x00. That is: P=0 (advertised) T=0 (TE link) R=0 (not a routing adjacency) B=0 (not a bundle) H=0 (hierarchical LSP)
定義されたすべてのビットフラグには、同時に意味があることに注意してください。FAを形成するLSPは、設定されたアクションフィールドを0x00に運びます。つまり、p = 0（広告）t = 0（te link）r = 0（ルーティング隣接性ではありません）b = 0（バンドルではありません）h = 0（階層LSP）
Reserved
予約済み
The Reserved bits MUST be set to zero on transmission and SHOULD be ignored on receipt.
予約されたビットは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
TLVs
TLVS
Zero, one, or more TLVs may be present. Each TLV is encoded as follows:
ゼロ、1つ、またはそれ以上のTLVが存在する場合があります。各TLVは次のようにエンコードされます。
Type (16 bits)
タイプ（16ビット）
The identifier of the TLV. Two type values are defined in this document:
TLVの識別子。このドキュメントでは、2つのタイプ値が定義されています。
1 IGP Instance Identifier TLV 2 Unnumbered Component Link Identifier TLV 3 IPv4 Numbered Component Link Identifier TLV 4 IPv6 Numbered Component Link Identifier TLV
1 IGPインスタンス識別子TLV 2アンナンバーコンポーネントリンク識別子TLV 3 IPv4番号付きコンポーネントリンク識別子TLV 4 IPv6番号付きコンポーネントリンク識別子TLV
Length (16 bits)
長さ（16ビット）
Indicates the total length of the TLV in octets, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
オクテット内のTLVの全長、つまり、オクテットの値フィールドの長さを示します。長さが4つの倍数ではない値フィールドは、TLVが4オクテットに並べられるように、ゼロパッドをゼロにする必要があります。
Value
価値
The data for the TLV padded as described above.
上記のようにパッドで埋められたTLVのデータ。
If this object is carried in a Path message, it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message, the object is known as the "Reverse Interface ID" for the LSP.
このオブジェクトがパスメッセージに携帯されている場合、セットアップされているLSPの「フォワードインターフェイスID」として知られています。RESVメッセージでは、オブジェクトはLSPの「リバースインターフェイスID」として知られています。
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an IPv4 numbered interface address.
lsp_tunnel_interface_idオブジェクトの新しいCタイプバリアントは、IPv4番号付きインターフェイスアドレスを運ぶように定義されています。
The format of the object is as shown below.
オブジェクトの形式は、以下に示すように示します。
C-NUM = 193, C-Type = 2
c-num = 193、c-type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Interface Address
IPv4インターフェイスアドレス
The address assigned to the interface that the sender applies to this LSP.
送信者がこのLSPに適用するインターフェイスに割り当てられたアドレス。
Actions
行動
See Section 3.1.2.
セクション3.1.2を参照してください。
Reserved
予約済み
See Section 3.1.2.
セクション3.1.2を参照してください。
TLVs
TLVS
See Section 3.1.2.
セクション3.1.2を参照してください。
If this object is carried in a Path message, it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message, the object is known as the "Reverse Interface ID" for the LSP.
このオブジェクトがパスメッセージに携帯されている場合、セットアップされているLSPの「フォワードインターフェイスID」として知られています。RESVメッセージでは、オブジェクトはLSPの「リバースインターフェイスID」として知られています。
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an IPv6 numbered interface address.
lsp_tunnel_interface_idオブジェクトの新しいCタイプバリアントは、IPv6番号付きインターフェイスアドレスを運ぶように定義されています。
The format of the object is as shown below.
オブジェクトの形式は、以下に示すように示します。
C-NUM = 193, C-Type = 3
c-num = 193、c-type = 3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Interface Address
IPv6インターフェイスアドレス
The address assigned to the interface the sender applies to this LSP.
送信者がこのLSPに適用するインターフェイスに割り当てられたアドレス。
Actions
行動
See Section 3.1.2.
セクション3.1.2を参照してください。
Reserved
予約済み
See Section 3.1.2.
セクション3.1.2を参照してください。
TLVs
TLVS
See Section 3.1.2.
セクション3.1.2を参照してください。
If this object is carried in a Path message, it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message, the object is known as the "Reverse Interface ID" for the LSP.
このオブジェクトがパスメッセージに携帯されている場合、セットアップされているLSPの「フォワードインターフェイスID」として知られています。RESVメッセージでは、オブジェクトはLSPの「リバースインターフェイスID」として知られています。
If the LSP being set up is to be advertised as a link, the egress needs to know which instance of the IGP it should use to make the advertisement. The default in [RFC4206] and [RFC3477] is that the LSP is advertised as an FA, that is, in the same instance of the IGP as was used to advertise the TE links that the LSP traverses.
セットアップされているLSPがリンクとして宣伝される場合、出力は広告を作成するために使用するIGPのどのインスタンスを知る必要があります。[RFC4206]および[RFC3477]のデフォルトは、LSPがFAとして宣伝されていることです。つまり、LSPが横断するTEリンクを宣伝するために使用されたのと同じIGPの場合と同じです。
In order to facilitate an indication from the ingress to the egress of which IGP instance to use, the IGP Identification TLV is defined for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID object defined in this document.
IGPインスタンスを使用するIGPインスタンスへの侵入からの兆候を促進するために、IGP識別TLVは、このドキュメントで定義されているLSP_Tunnel_Interface_IDオブジェクトの新しいバリアントに含めるために定義されます。
The TLV has meaning only in a Path message. It SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and MUST be ignored if found.
TLVには、パスメッセージにのみ意味があります。RESVメッセージのlsp_tunnel_interface_idオブジェクトに含めるべきではなく、見つかった場合は無視する必要があります。
If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in a Path message is clear (i.e., zero), this TLV indicates the IGP instance to use for the advertisement. If the TLV is absent, the same instance of the IGP should be used as is used to advertise the TE links that the LSP traverses. Thus, for an FA, the TLV can be omitted; alternatively, the IGP Instance TLV may be present and identify the IGP instance or carry the reserved value 0xffffffff.
パスメッセージのLSP_Tunnel_interface_IDオブジェクトのアクションフィールドのP-FLAGがクリア（つまり、ゼロ）である場合、このTLVは広告に使用するIGPインスタンスを示します。TLVが存在しない場合、IGPの同じインスタンスを使用して、LSPが横断するTEリンクを宣伝するために使用する必要があります。したがって、FAの場合、TLVは省略できます。あるいは、IGPインスタンスTLVが存在し、IGPインスタンスを特定するか、予約値0xffffffffを運ぶことができます。
If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID object in a Resv message is set (i.e., one) indicating that the LSP is not to be advertised as a link, this TLV SHOULD NOT be present and MUST be ignored if encountered.
rsvメッセージのlsp_tunnel_interface_idオブジェクトのアクションフィールドのp-flagが設定されている場合（つまり、1つ）、lspがリンクとして宣伝されないことを示す場合、このTLVを存在しないでください。遭遇した場合は無視する必要があります。
The TLV is formatted as described in Section 3.1.2. The Type field has the value 1, and the Value field has the following content:
TLVは、セクション3.1.2で説明されているようにフォーマットされています。タイプフィールドには値1があり、値フィールドには次のコンテンツがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGP Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IGP Instance Identifier
IGPインスタンス識別子
A 32-bit identifier assigned to each of the IGP instances within a network, such that ingress and egress LSRs have the same understanding of these numbers. This is a management configuration exercise outside the scope of this document.
ネットワーク内の各IGPインスタンスに割り当てられた32ビット識別子。IngressとEusress LSRは、これらの数値を同じ理解しています。これは、このドキュメントの範囲外の管理構成演習です。
Note that the IGP Instance Identifier might be mapped from an instance identifier used in the IGP itself (such as section 2.4 of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter of network policy. See [OSPF-TI] for further discussion of this topic in OSPF, and [ISIS-GENAP] for IS-IS.
IGPインスタンス識別子は、ネットワークポリシーの問題として、IGP自体（OSPFV3の[RFC5340]のセクション2.4、または[OSPFV2-MI]の[OSPFV2-MI]など）からマッピングされる可能性があることに注意してください。[OSPF-Ti]を参照してください。OSPFでのこのトピックの詳細については、IS-ISについては[ISIS-GENAP]を参照してください。
The value 0xffffffff is reserved to mean that the LSP is to be advertised in the same instance of the IGP as was used to advertise the TE links that the LSP traverses.
0xffffffffffの値は、LSPがLSPが通過するTEリンクを宣伝するために使用されたのと同じインスタンスと同じインスタンスでLSPが宣伝されることを意味するように予約されています。
If the LSP that is being set up is to be used as a component link in a link bundle [RFC4201], it is necessary to indicate both the identity of the component link and the identity of the link bundle. Furthermore, it is necessary to indicate how the link bundle (that may be automatically created by the establishment of this LSP) is to be used and advertised.
セットアップされているLSPがリンクバンドル[RFC4201]のコンポーネントリンクとして使用される場合、コンポーネントリンクのIDとリンクバンドルのIDの両方を示す必要があります。さらに、リンクバンドル（このLSPの確立によって自動的に作成される可能性がある）を使用して宣伝する方法を示す必要があります。
If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object is set, the other fields of the object apply to the link bundle itself. That is, the interface identifiers (numbered or unnumbered) and the other flags in the Actions field apply to the link bundle and not to the component link that the LSP will form.
lsp_tunnel_interface_idオブジェクトのアクションフィールドのb-flagが設定されている場合、オブジェクトの他のフィールドがリンクバンドル自体に適用されます。つまり、インターフェイス識別子（番号が付けられていないか、数字なし）とアクションフィールドの他のフラグは、LSPが形成するコンポーネントリンクではなく、リンクバンドルに適用されます。
Furthermore, the IGP Instance Identifier TLV (if present) also applies to the link bundle and not to the component link.
さらに、IGPインスタンス識別子TLV（存在する場合）は、コンポーネントリンクではなく、リンクバンドルにも適用されます。
In order to exchange the identity of the component link, the Component Link Identifier TLVs are introduced as set out in the next sections. If the B-flag is set in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in both the Path and Resv objects.
コンポーネントリンクのIDを交換するために、次のセクションに記載されているように、コンポーネントリンク識別子TLVが紹介されます。b-flagがパスメッセージ内のlsp_tunnel_interface_idオブジェクトのアクションフィールドに設定されている場合、これらのTLVの1つがパスオブジェクトとRESVオブジェクトの両方のlsp_tunnel_interface_idオブジェクトに正確に存在する必要があります。
If the component link is to be unnumbered, the Unnumbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 2, and the Value field has the following content:
コンポーネントリンクを非自己負担する場合、非仮定コンポーネントリンク識別子TLVが使用されます。TLVは、セクション3.1.2で説明されているようにフォーマットされています。タイプフィールドには値2があり、値フィールドには次のコンテンツがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Component Link Identifier
コンポーネントリンク識別子
Unnumbered identifier that is assigned to this component link within the bundle [RFC4201].
バンドル内のこのコンポーネントリンクに割り当てられた非仮定識別子[RFC4201]。
If the component link is identified with an IPv4 address, the IPv4 Numbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 3, and the Value field has the following content:
コンポーネントリンクがIPv4アドレスで識別される場合、IPv4番号付きコンポーネントリンク識別子TLVが使用されます。TLVは、セクション3.1.2で説明されているようにフォーマットされています。タイプフィールドには値3があり、値フィールドには次のコンテンツがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address
IPv4アドレス
The IPv4 address that is assigned to this component link within the bundle.
バンドル内のこのコンポーネントリンクに割り当てられたIPv4アドレス。
If the component link is identified with an IPv6 address, the IPv6 Numbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 4, and the Value field has the following content:
コンポーネントリンクがIPv6アドレスで識別される場合、IPv6番号付きコンポーネントリンク識別子TLVが使用されます。TLVは、セクション3.1.2で説明されているようにフォーマットされています。タイプフィールドには値4があり、値フィールドには次のコンテンツがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address
IPv6アドレス
The IPv6 address that is assigned to this component link within the bundle.
バンドル内のこのコンポーネントリンクに割り当てられたIPv6アドレス。
The ingress and egress of an LSP that is set up using the LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in the parameters of the object.
lsp_tunnel_interface_idオブジェクトを使用して設定されているLSPの侵入と出口は、オブジェクトのパラメーターで合意したようにLSPを宣伝する必要があります。
Where a TE link is created from the LSP, the TE link SHOULD inherit the TE properties of the LSP as described in [RFC5212], but this process is subject to local and network-wide policy.
LSPからTEリンクが作成されている場合、TEリンクは[RFC5212]で説明されているようにLSPのTEプロパティを継承する必要がありますが、このプロセスはローカルおよびネットワーク全体のポリシーの対象となります。
It is possible that an LSP will be used to offer capacity and connectivity to multiple other networks. In this case, multiple instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the same Path and Resv messages. Each instance MUST have a different IGP Instance Identifier.
LSPを使用して、他の複数のネットワークに容量と接続を提供する可能性があります。この場合、LSP_TUNNEL_INTERFACE_IDオブジェクトの複数のインスタンスが同じパスとRESVメッセージで許可されています。各インスタンスには、異なるIGPインスタンス識別子が必要です。
Note, however, that a Path or Resv message MUST NOT contain more than one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if such an object is present, all other instances of the LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance Identifier TLV with IGP Instance Identifier set to a value that identifies some other IGP instance (in particular, not the value 0xffffffff).
ただし、パスまたはRESVメッセージには、Cタイプ1を持つLSP_Tunnel_interface_IDオブジェクトの1つ以上のインスタンスを含む必要があり、そのようなオブジェクトが存在する場合、LSP_TUNNEL_INTERFACE_IDオブジェクトの他のすべてのインスタンスがIGPインスタンス識別子TLVを含む必要があることに注意してください。IGPインスタンス識別子は、他のIGPインスタンスを識別する値に設定されています（特に、値0xffffffffではなく）。
If the link created from an LSP is advertised in the same IGP instance as was used to advertise the TE links that the LSP traverses, the addresses for the new link and for the links from which it is built MUST come from the same address space.
LSPから作成されたリンクが、LSPが横断するTEリンク、新しいリンクのアドレス、およびそれが構築されるリンクのアドレスを宣伝するために使用されたのと同じIGPインスタンスで宣伝されている場合、同じアドレス空間から来る必要があります。
If the link is advertised into another IGP instance, the addresses MAY be drawn from overlapping address spaces such that some addresses have different meanings in each IGP instance.
リンクが別のIGPインスタンスに宣伝されている場合、アドレスは、各IGPインスタンスで異なる意味を持つアドレスの重複するアドレススペースから描画される場合があります。
In the IGP, the TE Router ID of the ingress LSR is taken from the Tunnel Sender Address in the Sender Template object signaled in the Path message. It is assumed that the ingress LSR knows the TE Router ID of the egress LSR since it has chosen to establish an LSP to that LSR and plans to use the LSP as a TE link.
IGPでは、Ingress LSRのTEルーターIDは、パスメッセージに合図された送信者テンプレートオブジェクトのトンネル送信者アドレスから取得されます。Ingress LSRは、LSRにLSPを確立することを選択し、LSPをTEリンクとして使用することを計画しているため、出力LSRのTEルーターIDを知っていると想定されています。
The link interface addresses or link interface identifiers for the forward and reverse direction links are taken from the LSP_TUNNEL_INTERFACE_ID object on the Path and Resv messages, respectively.
リンクインターフェイスは、順方向および逆方向のリンクのリンクインターフェイス識別子をアドレス指定します。リンクは、パスとRESVメッセージのlsp_tunnel_interface_idオブジェクトからそれぞれ取得されます。
When an LSP is torn down through explicit action (a PathTear message or a PathErr message with the Path_State_Removed flag set), the ingress and egress LSRs SHOULD withdraw the advertisement of any link that the LSP created and that was previously advertised. The link state advertisement MAY be retained as a virtual link in another layer network according to network-wide policy [PCE-LAYER].
LSPが明示的なアクション（Path_State_Removedフラグセットを使用したPATHTEARメッセージまたはPatherRメッセージ）を通じて取り壊される場合、IngressとEugress LSRは、LSPが作成し、以前に広告されたリンクの広告を撤回する必要があります。リンク状態広告は、ネットワーク全体のポリシー[PCE-Layer]に従って、別のレイヤーネットワークの仮想リンクとして保持される場合があります。
[RFC3477] does not state where in the Path message or Resv message the LSP_TUNNEL_INTERFACE_ID object should be placed.
[RFC3477]は、パスメッセージまたはRESVメッセージのどこにLSP_TUNNEL_INTERFACE_IDオブジェクトを配置する必要があります。
It is RECOMMENDED that new implementations place the LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after the SENDER_TSPEC object, and in the Resv message immediately after the FILTER_SPEC object.
新しい実装は、sender_tspecオブジェクトの直後のパスメッセージにlsp_tunnel_interface_idオブジェクトを、filter_specオブジェクトの直後のRESVメッセージに配置することをお勧めします。
All implementations SHOULD be able to handle received messages with objects in any order, as described in [RFC3209].
すべての実装は、[RFC3209]で説明されているように、任意の順序でオブジェクトを使用して受信したメッセージを処理できる必要があります。
Error cases and non-acceptance of new object variants caused by back-level implementations are discussed in Section 3.7.
バックレベルの実装によって引き起こされる新しいオブジェクトバリアントのエラーケースと非受容については、セクション3.7で説明します。
An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may have cause to reject the parameters carried in the object for a number of reasons as set out below. In all cases, the egress SHOULD respond with a PathErr message with the error code as indicated in the list below. In most cases, the error will arise during LSP setup, no Resv state will exist, and the PathErr will cause Path state to be removed. Where the error arises after the LSP has been successfully set up, the PathErr SHOULD be sent with the Path_State_Removed flag [RFC3473] clear so that the LSP remains operational.
lsp_tunnel_interface_idオブジェクトを受信する出力LSRには、以下に示すように、いくつかの理由でオブジェクトに運ばれたパラメーターを拒否する原因がある場合があります。すべての場合において、出口は、以下のリストに示されているように、エラーコードを使用してpatherrメッセージで応答する必要があります。ほとんどの場合、LSPのセットアップ中にエラーが発生し、RESV状態は存在しません。Patherrはパス状態を削除します。LSPが正常にセットアップされた後にエラーが発生する場合、PATHERRはPATH_STATE_REMOVEDフラグ[RFC3473]をクリアして送信する必要があります。
The error cases identified are as follows and are reported using the new error code 'LSP Hierarchy Issue' (code 38) and the error values listed below.
特定されたエラーケースは次のとおりであり、新しいエラーコード「LSP階層の問題」（コード38）と以下にリストされているエラー値を使用して報告されます。
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 1 Link advertisement not supported
38 2 Link advertisement not allowed by policy
38 3 TE link creation not supported
38 4 TE link creation not allowed by policy
38 5 Routing adjacency creation not supported
38 6 Routing adjacency creation not allowed by policy
38 7 Bundle creation not supported
38 8 Bundle creation not allowed by policy
38 9 Hierarchical LSP not supported
38 10 LSP stitching not supported
38 11 Link address type or family not supported
38 12 IGP instance unknown
38 13 IGP instance advertisement not allowed by policy
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a Resv message, it may need to reject it because of the setting of certain parameters in the object. Since these reasons all represent errors rather than mismatches of negotiable parameters, the ingress SHOULD respond with a PathTear to remove the LSP. The ingress MAY use a ResvErr with one of the following error codes, allowing the egress the option to correct the error in a new Resv message, or to tear down the LSP with a PathErr with the Path_State_Removed flag set. An ingress that uses the ResvErr MUST take precautions against a protocol loop where the egress responds with the same LSP_TUNNEL_INTERFACE_ID object with the same (or different) issues.
Ingress LSRがRESVメッセージでlsp_tunnel_interface_idオブジェクトを受信した場合、オブジェクト内の特定のパラメーターの設定のために拒否する必要がある場合があります。これらの理由はすべて、交渉可能なパラメーターの不一致ではなくエラーを表すため、侵入はLSPを削除するためにPATHTEARで応答する必要があります。Ingressは、次のエラーコードのいずれかを備えたRESVERRを使用して、新しいRESVメッセージでエラーを修正するオプションを出力するか、PATH_STATE_REMOVEDフラグセットでPATHERRでLSPを取り壊すことができます。RESVERRを使用する侵入は、同じ（または異なる）問題を持つ同じLSP_Tunnel_interface_IDオブジェクトで出口が応答するプロトコルループに対して予防策を講じる必要があります。
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 11 Link address type or family not supported
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
38 16 Component link identifier missing
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class number of 193. According to [RFC2205], this means that a node that does not understand the object SHOULD ignore the object but forward it, unexamined and unmodified. Thus, there are no issues with transit LSRs supporting the pre-existing or new Class Types of this object.
[RFC3477]で定義されているLSP_TUNNEL_INTERFACE_IDオブジェクトは、クラス番号193を持っています。[RFC2205]によると、これはオブジェクトを理解していないノードがオブジェクトを無視する必要があるが、それを転送していないことを意味します。したがって、このオブジェクトの既存または新しいクラスタイプをサポートするトランジットLSRに問題はありません。
A back-level ingress node will behave as follows:
バックレベルのイングレスノードは次のように動作します。
- It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID objects with the new Class Types defined in this document.
- このドキュメントで定義されている新しいクラスタイプで、lsp_tunnel_interface_idオブジェクトを含むパスメッセージは発行しません。
- It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID objects with the new Class Types defined in this document as described in [RFC2205]. In any case, such a situation would represent an error by the egress.
- [RFC2205]で説明されているように、このドキュメントで定義された新しいクラスタイプを使用して、LSP_Tunnel_interface_IDオブジェクトを含むresvメッセージを拒否します。いずれにせよ、そのような状況は出口によるエラーを表します。
- It will continue to use the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 as defined in [RFC3477]. This behavior is supported by back-level egresses and by egresses conforming to this document.
- [RFC3477]で定義されているように、クラスタイプ1を持つLSP_TUNNEL_INTERFACE_IDオブジェクトを引き続き使用します。この動作は、バックレベルの出口と、このドキュメントに準拠した出口によってサポートされています。
- According to an informal survey, there is no significant deployment of numbered FA establishment following the procedures defined in [RFC4206] and set out in Section 1.3.6 of this document. It is therefore safe to assume that back-level ingress LSRs will not use this mechanism.
- 非公式の調査によると、[RFC4206]で定義され、この文書のセクション1.3.6に記載されている手順に従って、番号付きFA施設の重要な展開はありません。したがって、バックレベルのイングレスLSRがこのメカニズムを使用しないと仮定するのは安全です。
A back-level egress node will behave as follows:
バックレベルの出口ノードは次のように動作します。
- It will continue to support the LSP_TUNNEL_INTERFACE_ID object with Class Type 1, as defined in [RFC3477], if issued by an ingress.
- イングレスによって発行された場合、[RFC3477]で定義されているように、クラスタイプ1でlsp_tunnel_interface_idオブジェクトを引き続きサポートします。
- It will reject a Path message that carries an LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types defined in this document using the procedures of [RFC2205]. This will inform the ingress that the egress is a back-level LSR.
- [RFC2205]の手順を使用して、このドキュメントで定義されている新しいクラスタイプのいずれかを使用して、lsp_tunnel_interface_idオブジェクトを運ぶパスメッセージを拒否します。これは、出口がバックレベルのLSRであることを侵入に通知します。
- It will not expect to use the procedures for numbered FA establishment defined in [RFC4206] and set out in Section 1.3.6 of this document.
- [RFC4206]で定義され、このドキュメントのセクション1.3.6に記載されている数字のFA確立の手順を使用することは期待されません。
In summary, the new mechanisms defined in this document do not impact the method to exchange unnumbered FA information described in [RFC3477]. That mechanism can be safely used in combination with the new mechanisms described here and is functionally equivalent to using the new C-Type indicating an unnumbered link with target IGP instance identifier with the Target IGP Instance value set to 0xffffffff.
要約すると、このドキュメントで定義されている新しいメカニズムは、[RFC3477]に記載されている数本のFA情報を交換する方法に影響を与えません。このメカニズムは、ここで説明した新しいメカニズムと組み合わせて安全に使用でき、ターゲットIGPインスタンス識別子と0xffffffffに設定されたターゲットIGPインスタンス識別子との非自在のリンクを示す新しいCタイプを使用することと機能的に同等です。
The mechanisms in this document obsolete the method to exchange the numbered FA information described in [RFC4206] as described in Section 1.4.6.
このドキュメントのメカニズムは、セクション1.4.6で説明されているように、[RFC4206]で説明されている数字のFA情報を交換する方法を廃止します。
[RFC3477] points out that one can argue that the use of the extra interface identifier that it provides could make an RSVP message harder to spoof. In that respect, the minor extensions to the protocol made in this document do not constitute an additional security risk, but could also be said to improve security.
[RFC3477]は、提供される追加のインターフェイス識別子の使用がRSVPメッセージをスプーフィングしにくくする可能性があると主張できると指摘しています。その点で、このドキュメントで作成されたプロトコルへのマイナーな拡張は、追加のセキュリティリスクを構成するものではありませんが、セキュリティを改善するとも言えます。
It should be noted that the ability of an ingress LSR to request that an egress LSR advertise an LSP as a TE link MUST be subject to appropriate policy checks at the egress LSR. That is, the egress LSR MUST NOT automatically accept the word of the ingress unless it is configured with such a policy.
侵入LSRの能力は、出口LSRがLSPをTEリンクとして宣伝することを要求する能力に、Egress LSRで適切なポリシーチェックの対象となる必要があることに注意してください。つまり、出力LSRは、そのようなポリシーで構成されていない限り、イングレスの単語を自動的に受け入れてはなりません。
Further details of security for MPLS-TE and GMPLS can be found in [RFC5920].
MPLS-TEおよびGMPLSのセキュリティの詳細については、[RFC5920]に記載されています。
IANA maintains a registry of RSVP parameters called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Class Names, Class Numbers, and Class Types". There is an entry in this registry for the LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] with one Class Type defined.
IANAは、「クラス名、クラス番号、クラスタイプ」と呼ばれるサブレジストリを使用して、「リソース予約プロトコル（RSVP）パラメーター」と呼ばれるRSVPパラメーターのレジストリを維持しています。このレジストリには、[RFC3477]で定義されたLSP_Tunnel_interface_IDオブジェクトのエントリがあり、1つのクラスタイプが定義されています。
IANA has allocated three new Class Types for this object as defined
in Sections 3.1.2, 3.1.3, and 3.1.4 as follows:
C-Type Meaning Reference
---------------------------------------------------------------
2 IPv4 interface identifier with target [RFC6107]
3 IPv6 interface identifier with target [RFC6107]
4 Unnumbered interface with target [RFC6107]
Section 3.1.2 defines an 8-bit flags field in the LSP_TUNNEL_INTERFACE_ID object. IANA has created a new sub-registry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry called the "Hierarchy Actions" sub-registry as follows:
セクション3.1.2は、LSP_Tunnel_interface_IDオブジェクトの8ビットフラグフィールドを定義します。IANAは、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングパラメーター」の新しいサブレジストリを作成しました。レジストリは「階層アクション」サブレジストリと呼ばれます。
Registry Name: Hierarchy Actions Reference: [RFC6107] Registration Procedures: Standards Action
レジストリ名：階層アクション参照：[RFC6107]登録手順：標準アクション
Registry:
Bit Number Hex Value Name Reference
---------- ----------- ----------------------- ---------
0-2 Unassigned
3 0x10 Hierarchy/stitching (H) [RFC6107]
4 0x08 Bundle (B) [RFC6107]
5 0x04 Routing adjacency (R) [RFC6107]
6 0x02 TE link (T) [RFC6107]
7 0x01 Private (P) [RFC6107]
IANA maintains a registry of RSVP error codes and error values as the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry.
IANAは、RSVPエラーコードとエラー値のレジストリを「エラーコードとグローバルに定義されたエラー値サブコード」として維持しています。
IANA has defined a new error code with value 38 as below (see also Section 3.6).
IANAは、以下の値38を持つ新しいエラーコードを定義しました（セクション3.6も参照）。
Error Code Meaning
エラーコードの意味
38 LSP Hierarchy Issue [RFC6107]
38 LSP階層の問題[RFC6107]
IANA has listed the following error values for this error code (see also Section 3.6).
IANAは、このエラーコードの次のエラー値をリストしました（セクション3.6も参照）。
This Error Code has the following globally-defined Error Value sub-codes:
このエラーコードには、次のグローバルに定義されたエラー値サブコードがあります。
1 = Link advertisement not supported [RFC6107]
2 = Link advertisement not allowed by policy [RFC6107]
3 = TE link creation not supported [RFC6107]
4 = TE link creation not allowed by policy [RFC6107]
5 = Routing adjacency creation not supported [RFC6107]
6 = Routing adjacency creation not allowed by policy [RFC6107]
7 = Bundle creation not supported [RFC6107]
8 = Bundle creation not allowed by policy [RFC6107]
9 = Hierarchical LSP not supported [RFC6107]
10 = LSP stitching not supported [RFC6107]
11 = Link address type or family not supported [RFC6107]
12 = IGP instance unknown [RFC6107]
13 = IGP instance advertisement not allowed by policy [RFC6107]
14 = Component link identifier not valid [RFC6107]
15 = Unsupported component link identifier address [RFC6107]
family
16 = Component link identifier missing [RFC6107]
The authors would like to thank Lou Berger, Deborah Brungard, John Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable discussions and comments.
著者は、ルー・ベルガー、デボラ・ブランガード、ジョン・ドレイク、ヤコフ・レクター、イゴール・ブリスキン、ルーシー・ヨンの貴重な議論とコメントに感謝したいと思います。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3209] 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.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける非番号のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベル交通工学（GMPLS TE）を使用したラベルスイッチングパスステッチ」、RFC 5150、2008年2月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S.、ed。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212] Shiomoto、K.、Papadimitriou、D.、Le Roux、Jl。、Vigoureux、M。、およびD. Brungard、「GMPLSベースのマルチレジオンおよびマルチ層ネットワーク（MRN/MLN）の要件」RFC 5212、2008年7月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308] Hopps、C。、「IS-ISを使用したIPv6をルーティング」、RFC 5308、2008年10月。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A。、およびA. Lindem、ed。、「Traffic Engineering Extensions to OSPFバージョン3」、RFC 5329、2008年9月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[ISIS-GENAP] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", Work in Progress, November 2010.
[ISIS-GENAP] Ginsberg、L.、Previdi、S。、およびM. Shand、「IS-ISの一般的な情報を広告」、2010年11月、進行中の作業。
[ISIS-IPV6-TE] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", Work in Progress, September 2010.
[ISIS-IPV6-TE] Harrison、J.、Berger、J。、およびM. Bartlett、「IS-ISにおけるIPv6トラフィックエンジニアリング」、2010年9月に進行中の作業。
[OSPF-TI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport Instance Extensions", Work in Progress, October 2010.
[OSPF-TI] Lindem、A.、Roy、A。、およびS. Mirtorabi、「OSPF Transport Instance Extensions」、2010年10月の作業。
[OSPFv2-MI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi-Instance Extensions", Work in Progress, October 2010.
[OSPFV2-MI] Lindem、A.、Roy、A。、およびS. Mirtorabi、「OSPF Multi-Instance Extensions」、2010年10月の作業。
[PCE-LAYER] Takeda, T., Ed., and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Work in Progress, December 2010.
[PCE-Layer] Takeda、T.、ed。、およびA. Farrel、「PCC-PCE通信およびPCE層間交通工学のPCE発見要件」、2010年12月、進行中の作業。
Authors' Addresses
著者のアドレス
Richard Rabbat Google Inc. 1600 Amphitheatre Pkwy Mountain View, CA 94043 United States of America EMail: rabbat@alum.mit.edu
Richard Rabbat Google Inc. 1600 Amphitheater Pkwy Mountain View、CA 94043アメリカ合衆国電子メール：rabbat@alum.mit.edu
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America EMail: arthi@juniper.net
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国電子メール：arthi@juniper.net
Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: zali@cisco.com
Zafar Ali Cisco Systems、Inc。2000 Innovation Drive Drive Kanata、Ontario、K2K 3e8 Canada：zali@cisco.com
Editors' Addresses
編集者のアドレス
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
Kohei Shiomoto NTTネットワークサービスシステム研究所3-9-11 Midori Musashino、Tokyo 180-8585日本電話：81 422 59 4402メール：shiomoto.kohei@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk