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マルチプロトコルラベルスイッチングで設定スイッチパス（LSP）（GMPLS）ネットワークは、それらのネットワークまたは他の（クライアント）のネットワークにトラフィックを伝送するためのリンクを形成するために使用することができます。
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に記載番号TEリンクとして使用される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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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).
トラフィックエンジニアリング（TE）（MPLS）をマルチプロトコルラベルスイッチングにおけるリンクまたは汎用MPLS（GMPLS）ネットワークは、ラベルから構成されてもよいが、パスのスイッチ（の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.
ノードのペア間（それ以外のLSPかから作成された）TEリンクの数が大きくなると、個別に宣伝するのは非効率的です。これは、コンフィギュレーションにして広告を運ぶために使用されるルーティングプロトコルに問題をスケーリング可能性があります。 （[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が置かれているために使用すると、エンドポイントの識別子：これらの問題は、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.
この文書では、番号のTEリンクとして使用されるLSPのシグナリングのために[RFC4206]で定義されたメカニズムのいずれかを廃止（セクション1.3.6および詳細については、1.4.6を参照）、およびで定義された他の機構に拡張機能を提供します[RFC4206]に新しいLSPを置くされるべき使用は、シグナリング中に示すことができるようになっています。それはまた、無数のTEリンクをシグナリングするための[RFC3477]で定義されたメカニズムを拡張します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]はのLSPが他通る1 LSPでネストすることができるように、MPLSラベルが積層されていてもよい方法を記述しています。 H-LSPのこの概念は、一の以上の他のLSPを運ぶことができるH-LSPの確立のためのプロトコルメカニズムのセットと[RFC4206]に定式化されます。
[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のホップ）。この機構は、「非隣接シグナル」として知られています。
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のスピーカとの間に形成されています。この意味で、「論理的に隣接する」はルータがそれを通してそれらがルーティングプロトコルメッセージを交換することができ、それらの間のプロトコルトンネルを有することを意味します。トンネルはまた、区別がデータプレーントラフィック及び制御プレーントラフィック間GMPLSネットワークで行われるべきであるがIPデータを搬送するための通常利用可能です。
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）は、LSPから作成され、LSPが構築されたTEリンクをアドバタイズ制御プレーンの同じインスタンスでアドバタイズデータリンクとして[RFC4206]で定義されています。 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は、それがLSPが横断TEリンクをアドバタイズするために使用されたようにルーティングプロトコルの同じインスタンスにTEリンクとしてアドバタイズされるようにFAを形成することができます。
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は、一つのネットワークで作成され、別のネットワーク[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リンクバンドルは、それ自体が宣伝されている可能性が複数のTEリンクの集合体として宣伝されてTEリンクとして[RFC4201]で定義されています。 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.
ルーティング隣接関係が確立されると、ルータのペアが、ネットワーク内のIPトラフィックを運ぶために利用可能なリンクに関する情報を共有するためにIGPを使用することができます。
Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], and IS-IS [RFC1195].
適切なルーティングプロトコルOSPFバージョン2 [RFC2328]、OSPFバージョン3 [RFC5340]であり、[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]).
拡張機能は[RFC4202]（TEリンク特性（[RFC3630]、[RFC5329]、[RFC5305]、[RFC5308]、および[ISIS-IPV6-TE]）をアドバタイズし、また、GMPLSネットワークにおけるリンク特性をアドバタイズするのIGPになされています、[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に記載したように、これは特にのFAの場合です。
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.
これらのメカニズムは完全に機能してMLNSでは非常に一般的ですが、設定の調整や追加の管理が必要です。彼らは、ユーザー・エラーや設定ミス使用されていない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の入口は、Pathメッセージを使用して通常通り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オブジェクトを識別： - 出口のLSRルータIDを - TEリンクの出口のインタフェース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メッセージの交換後、入力と出力の両方が、それは横断TEリンクを宣伝するために使用されたとしてLSPは、ルーティングプロトコルの同じインスタンスで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を確立し、TEは、それが（つまり、番号FAとして、である）横断リンクアドバタイズとしてルーティングプロトコルの同じインスタンスに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の入口は、Pathメッセージを使用して通常通りLSPを通知し、それが作成されるTEリンクのためにそのインタフェースを識別するために使用するIPアドレスにIPv4トンネルの送信元アドレスを設定します。これは、/ 31のペアから一つのアドレスです。
- 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を受け入れ、それを設定するために通常通りに応答します。それはTEリンクが/ 31ペアのパートナーアドレスとして作成されているために、そのインターフェイスを識別するために割り当てる必要がありますアドレスを推測します。
- 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（すなわち、FAなど）TEリンクとして広告されるべきであるか否かを判断します。もしそうなら、それは通常の方法で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の出口であるかどうかを確認しなければなりません。通常、これは出力を意味します - リンク広告が新しいものであるかどうかを確認します。 - 受信した広告でリンク-IDアドレスが自身のTEルータIDが一致するかどうかを確認します。 - それは出口である各LSPの入口アドレスに対して広告から広告ルータIDをチェックします。 - 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.
何の説明は番号のIPv6のFAを作成する方法の[RFC4206]に提供されていません。
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.
アドレッシングモデルはネットワーク全体で一貫性が保たれ、すべてのIGPのインスタンスで出口を検索すると、すべての広告されている場合、番号TEリンク機構（1.3.6）は、理論的には、複数のIGPインスタンスとMLNで使用することができます。しかし、これは複雑であり、非番号のインターフェイスでは動作しません。
A signaling mechanism is required to indicate in which IGP instance the TE link should be advertised.
シグナリングメカニズムは、TEリンクがアドバタイズされるべきIGPインスタンスで示すことが要求されます。
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]で定義されている番号なしのFAのための既存のプロトコルメカニズムがサポートされ続けなければならず、新しいメカニズムは、彼らの導入は、既存の実装や展開を壊さないように考案されなければなりません。
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ワーキンググループで非公式の調査があっ番のFAの有意な展開がありません[RFC4206]で説明し、1.3.6項に記載された技術を使用して確立することを確立していることに注意してください。そのため、この文書では、この手順を非難します。
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]は、それらが、番号または無数のIPv4またはIPv6リンクを形成するかどうか、すべてのH-のLSPとS-LSPのための使用のために拡張されます。オブジェクトの異なるクラスの型は、それが適用されるアドレスタイプを識別します。
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によって形成されたリンクがアドバタイズされるべきにIGPインスタンスを識別するためにLSP_TUNNEL_INTERFACE_IDオブジェクトに追加されます。 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.
下位互換性は、三つの側面があります。
- 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.
- egressesが更新されると、入口ノードを更新する必要がないように、番号なしのFAのための既存のメカニズム[RFC3477]と[RFC4206]で説明は、作業を続ける必要があります。
- 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.
- ingressesが更新されると出口ノードを更新する必要がないように、新しいメカニズムが優雅に既存の出口の実装によって拒否されなければなりません。
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が横断TEリンクを（宣伝するために使用されたとIGPの同じインスタンスで番号なしTEリンクとしてアドバタイズされますLSPを確立するために使用できることを意味しそれは）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-タイプ= 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.
フィールドは、Pathメッセージに意味があります。 Resvメッセージには、フィールドは、対応するPathメッセージで受信された値を反映するように設定する必要があり、それは領収書の上で無視しなければなりません。
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フラグ（プライベート）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フラグ（TEリンク）0 LSPがTEリンクとして使用されることを意味します。図1は、LSPは、TEリンクとして使用されるべきではないことを意味します。それはまだRフラグによって定義されるルーティング隣接関係を提供する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フラグ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フラグ（バンドル）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-フラグ（階層/ステッチ）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リンク）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
TLV
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の識別子。二つのタイプの値は、この文書で定義されています。
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.
4オクテットの値フィールドの長さ+、即ち、オクテットでTLVの合計長さを示します。 TLVは4オクテット整列されるように、その長さが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.
このオブジェクトはPathメッセージで運ばれる場合、それが設定されている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-タイプ= 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
TLV
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.
このオブジェクトはPathメッセージで運ばれる場合、それが設定されている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-タイプ= 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
TLV
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.
このオブジェクトはPathメッセージで運ばれる場合、それが設定されている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が横断TEリンクをアドバタイズするために使用されたようにLSPがIGPの同じインスタンス内に、即ち、FAとして宣伝されていることです。
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識別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は唯一のPathメッセージに意味があります。これは、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.
PathメッセージにLSP_TUNNEL_INTERFACE_IDオブジェクトのアクションフィールドにPフラグがクリアされている場合（すなわち、ゼロ）、このTLVは、広告に使用するIGPインスタンスを示します。 TLVが存在しない場合LSPが横断TEリンクをアドバタイズするために使用されるように、IGPの同じインスタンスを使用すべきです。したがって、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.
ResvメッセージにLSP_TUNNEL_INTERFACE_IDオブジェクト内のアクションフィールドにP-フラグが設定されている場合（すなわち1）は、このTLVが存在すべきではない、LSPがリンクとしてアドバタイズされるべきではないことを示すと遭遇した場合に無視しなければなりません。
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:
セクション3.1.2に記載したようにTLVがフォーマットされています。 Typeフィールドは値1を持ち、そしてValue分野には、以下の内容があります。
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
PGIインスタンス識別子
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ビットの識別子は、その入口と出口LSRsは、これらの番号の同じ理解を有します。これは、この文書の範囲外の管理構成の運動です。
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インスタンス識別子は、ネットワークポリシーの問題として（例えばOSPFv3のために[RFC5340]のセクション2.4、またはOSPFv2のための[OSPFv2の-MI]など）IGP自体で使用されるインスタンス識別子からマッピングされるかもしれないことに留意されたいです。さらにOSPFでこのトピックについての議論、およびISISについて[ISIS-GENAP]は[OSPF-TI]を参照してください。
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.
0xFFFFFFFFの値がLSPがLSPが横断TEリンクをアドバタイズするために使用されたとしてIGPの同じインスタンスでアドバタイズされることを意味するために予約されています。
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]でコンポーネントリンクとして使用される場合、コンポーネントリンクのアイデンティティとリンクバンドルのアイデンティティの両方を示すことが必要です。また、リンクバンドル（つまり自動的にこの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フラグが設定されている場合、オブジェクトの他のフィールドは、リンクバンドル自体に適用されます。すなわち、インタフェース識別子（番号または番号なし）とアクションフィールドに他のフラグは、リンクバンドルにはなく、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フラグがPathメッセージにLSP_TUNNEL_INTERFACE_IDオブジェクトのアクションフィールドに設定されている場合、これらのTLVの正確に一つのパスとの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が使用されます。セクション3.1.2に記載したようにTLVがフォーマットされています。 Typeフィールドは、値2を持ち、そしてValue分野には、以下の内容があります。
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が使用されます。セクション3.1.2に記載したようにTLVがフォーマットされています。 Typeフィールドには値3を有し、およびValue分野には、以下の内容があります。
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が使用されます。セクション3.1.2に記載したようにTLVがフォーマットされています。 Typeフィールドの値は4であり、Valueフィールドは、以下の内容を有します。
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.
TEリンクがLSPから作成される場合、[RFC5212]に記載されているようにTEリンクは、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オブジェクトの複数のインスタンスを含んではならない、そのようなオブジェクトが存在する場合、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から作成したリンクが同じIGPインスタンスに宣伝されている場合はLSPが横断TEリンクを宣伝するために使用されたとして、新しいリンクについて、それが構築され、そこからのリンクのアドレスは、同じアドレス空間から来なければなりません。
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では、入口LSRのTEルータIDは、Pathメッセージにおいてシグナリング送信者テンプレートオブジェクト内のトンネル送信元アドレスから取られます。それがそのLSRへのLSPを確立するために選択し、TEリンクとしてLSPを使用することを計画しているので、入口LSRが出口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は、明示的なアクション（PathTearメッセージまたはPath_State_Removedフラグが設定されたPathErrメッセージ）を介して切断されたときに、入口および出口の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.
PathメッセージやResvメッセージにLSP_TUNNEL_INTERFACE_IDオブジェクトが配置されるべきである。ここで、[RFC3477]は状態ありません。
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.
新しい実装がすぐFILTER_SPECオブジェクトの直後SENDER_TSPECオブジェクトの後、およびResvメッセージにPathメッセージにLSP_TUNNEL_INTERFACE_IDオブジェクトを配置することが推奨されます。
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はLSPが動作残るようにクリア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.
入口LSRは、ResvメッセージにLSP_TUNNEL_INTERFACE_IDオブジェクトを受信すると、それがために、オブジェクトに特定のパラメータの設定にそれを拒絶する必要があるかもしれません。これらの理由はすべてのエラーではなく、交渉のパラメータの不整合を表しているので、侵入は、LSPを削除するにはPathTearで応答する必要があります。入口は、出口新しいResvメッセージのエラーを修正する、またはPath_State_Removedフラグが設定されたPathErrとLSPをティアダウンするオプションを可能にする、以下のエラーコードのいずれかでResvErrを使用するかもしれません。 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オブジェクトは[RFC2205]によれば、193のクラス番号を有し、これはオブジェクトを理解していないノードがオブジェクトを無視するが、それを転送し、未未修飾なければならないことを意味します。したがって、このオブジェクトの既存または新規のクラスの型をサポートするトランジットの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オブジェクトを含むPathメッセージを発行しません。
- 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オブジェクトを使用し続けます。この動作は、バックレベルのegressesによって、このドキュメントに準拠egressesによってサポートされています。
- 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オブジェクトを搬送するPathメッセージを拒否します。これは、出力がバックレベルの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情報を交換する方法に影響を与えません。その機構は、安全にここに記載の新規メカニズムと組み合わせて使用すると0xFFFFFFFFのに設定された目標IGPインスタンス値と目標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の能力は、TEリンクが出口LSRで適切なポリシーチェックの対象としなければならないので、出口LSRがLSPを宣伝することを要求することに留意すべきです。それは、このようなポリシーで構成されていない限り、つまり、出力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パラメータのレジストリを維持します。定義された1クラスタイプと[RFC3477]で定義されLSP_TUNNEL_INTERFACE_IDオブジェクトのこのレジストリのエントリがあります。
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:
次のようにIANAはセクション3.1.2、3.1.3で定義された、このオブジェクトのための3つの新しいクラスの型を割り当てられ、3.1.4ました：
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）パラメータ」レジストリのサブレジストリとして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]
ポリシーで許可されていない1 =リンク広告サポートされていない[RFC6107] 2 =リンク広告[RFC6107] 3 = TEリンクの作成がサポートされていない[RFC6107] 4 = TEリンク作成ポリシーによって許可されていない[RFC6107] 5 =ルーティング隣接関係の作成がサポートされていません[ RFC6107]ポリシーで許可されていない6 =ルーティング隣接作成[RFC6107] 7 =バンドルの作成がサポートされていない[RFC6107]ポリシーで許可されていない8 =バンドルの作成[RFC6107] 9 =階層LSPサポートされていない[RFC6107] 10 = LSPステッチがサポートされていません[ RFC6107] 11 =リンク・アドレス・タイプまたはファミリがサポートされていない[RFC6107] 12 = IGPインスタンス不明[RFC6107]ポリシー[RFC6107] 14 =コンポーネントリンク識別子有効でない[RFC6107] 15 =サポートされていないコンポーネントリンク識別子で許可されていない13 = IGPインスタンス広告アドレス[RFC6107]家族16 =欠落しているコンポーネントリンク識別子[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.
著者は、彼らの貴重な議論とコメントをルー・バーガー、デボラBrungard、ジョン・ドレイク、ヤコフ・レックター、イゴールBryskin、そしてルーシー龍に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]デアリング、S.、エド。、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[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.、ルルー、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]李、T.とH.スミットは、RFC 5305、2008年10月 "トラフィックエンジニアリングのための拡張機能-IS IS"。
[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.、エド。、およびY. Rekhter、エド。、 "IS-ISの拡張一般化マルチプロトコルラベルスイッチング（GMPLS）の支援で"、RFC 5307、2008年10月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
"IS-ISとルーティングのIPv6" [RFC5308] Hoppsが、C.、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]石黒、K.、Manral、V.、デイビー、A.、およびA. Lindem、エド。、RFC 5329、2008年9月 "OSPFバージョン3へのトラフィックエンジニアリングの拡張"。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "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]ギンズバーグ、L.、Previdi、S.、およびM.シャンド、 "ISISで広告ジェネリック情報"、進歩、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]ハリソン、J.、バーガー、J.、およびM.バートレット、 "ISISでの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.、ロイ、A.、およびS. Mirtorabi、 "OSPF交通インスタンスの拡張機能"、進歩、2010年10月の作業。
[OSPFv2-MI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi-Instance Extensions", Work in Progress, October 2010.
[OSPFv2の-MI] Lindem、A.、ロイ、A.、およびS. Mirtorabi、 "OSPFマルチインスタンス機能拡張"、進歩、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]武田、T.、エド。、およびA.ファレル、 "レイヤ間トラフィックエンジニアリングのためのPCC-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
リチャードRabbatグーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043アメリカ合衆国Eメール：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ジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089アメリカ合衆国Eメール：arthi@juniper.net
Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: zali@cisco.com
Zafarアリシスコシステムズ株式会社2000年イノベーションドライブカナタ、オンタリオ、K2K 3E8カナダEメール：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
こへい しおもと んっｔ ねとぉｒｋ せｒゔぃせ Ｓｙｓてｍｓ ぁぼらとりえｓ ３ー９ー１１ みどり むさしの、 ときょ １８０ー８５８５ じゃぱん Ｐほね： ＋８１ ４２２ ５９ ４４０２ えまいｌ： しおもと。こへい＠ぁｂ。んっｔ。こ。ｊｐ
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk