[要約] 要約：RFC 8001は、RSVP-TEプロトコルの拡張機能であり、共有リスクリンクグループ（SRLG）情報の収集を目的としています。目的：RFC 8001の目的は、ネットワークの可用性と信頼性を向上させるために、RSVP-TEプロトコルにSRLG情報の収集機能を追加することです。
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 8001 Huawei
Category: Standards Track O. Gonzalez de Dios, Ed.
ISSN: 2070-1721 Telefonica Global CTO
C. Margaria
Juniper
M. Hartley
Z. Ali
Cisco
January 2017
RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information
共有リスクリンクグループ（SRLG）情報を収集するためのRSVP-TE拡張
Abstract
概要
This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).
このドキュメントでは、GMPLSを含むリソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）の拡張機能を提供し、ラベルスイッチドパス（LSP）によって形成されたTEリンクの共有リスクリンクグループ（SRLG）情報の自動収集をサポートします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8001.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8001で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Example: Dual-Homing . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5
3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 6
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. SRLG ID Definition . . . . . . . . . . . . . . . . . . . . 6
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6
4.2. RRO SRLG Subobject . . . . . . . . . . . . . . . . . . . 7
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10
5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . . 11
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 12
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12
8.3. Policy Control Failure Error Subcodes . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
It is important to understand which Traffic Engineering (TE) links in a given network might be at risk from the same failures. In this sense, a set of links can constitute a Shared Risk Link Group (SRLG) if they share a resource whose failure can affect all links in the set [RFC4202].
特定のネットワーク内のどのトラフィックエンジニアリング（TE）リンクが同じ障害のリスクがあるかを理解することが重要です。この意味で、障害がセット内のすべてのリンクに影響を与える可能性があるリソースを共有する場合、リンクのセットは共有リスクリンクグループ（SRLG）を構成できます[RFC4202]。
On the other hand, as described in [RFC4206] and [RFC6107], a Hierarchical LSP (H-LSP) or stitched LSP (S-LSP) can be used for carrying one or more other LSPs. Both the H-LSP and S-LSP can be formed as a TE link. In such cases, it is important to know the SRLG information of the LSPs that will be used to carry further LSPs.
一方、[RFC4206]と[RFC6107]で説明されているように、階層型LSP（H-LSP）またはスティッチドLSP（S-LSP）は、1つまたは複数の他のLSPを運ぶために使用できます。 H-LSPとS-LSPの両方をTEリンクとして形成できます。そのような場合、それ以降のLSPの伝送に使用されるLSPのSRLG情報を知ることが重要です。
This document provides a signaling mechanism that collects the SRLGs that are used by an LSP and can then be advertised as properties of the TE link formed by that LSP.
このドキュメントは、LSPによって使用され、そのLSPによって形成されるTEリンクのプロパティとしてアドバタイズできるSRLGを収集するシグナリングメカニズムを提供します。
An interesting use case for the SRLG collection procedures defined in this document is achieving LSP diversity in a dual-homing scenario. The use case is illustrated in Figure 1, when the overlay model is applied as defined in [RFC4208]. In this example, the exchange of routing information over the User-Network Interface (UNI) is prohibited by operator policy.
このドキュメントで定義されているSRLG収集手順の興味深い使用例は、デュアルホーミングシナリオでLSPダイバーシティを実現することです。 [RFC4208]で定義されているようにオーバーレイモデルが適用された場合のユースケースを図1に示します。この例では、ユーザーネットワークインターフェイス（UNI）を介したルーティング情報の交換は、オペレーターポリシーによって禁止されています。
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+
+---+ | PE1 | | PE3 | +---+
|CE1|----| | | |----|CE2|
+---+\ +-----+ +-----+ /+---+
\ | | /
\ +-----+ +-----+ /
\| PE2 | | PE4 |/
| | | |
+-----+ +-----+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Dual-Homing Configuration
図1：デュアルホーミング構成
Single-homed customer edge (CE) devices are connected to a single provider edge (PE) device via a single UNI link (which could be a bundle of parallel links, typically using the same fiber cable). This single UNI link can constitute a single point of failure. Such a single point of failure can be avoided if the CE device is connected to two PE devices via two UNI interfaces for CE1 and CE2, respectively, as depicted in Figure 1.
シングルホームのカスタマーエッジ（CE）デバイスは、単一のUNIリンク（通常は同じファイバーケーブルを使用する並列リンクのバンドルである場合があります）を介して単一のプロバイダーエッジ（PE）デバイスに接続されます。この単一のUNIリンクは、単一障害点を構成する可能性があります。図1に示すように、CEデバイスがCE1およびCE2の2つのUNIインターフェイスを介して2つのPEデバイスに接続されている場合、このような単一障害点を回避できます。
For the dual-homing case, it is possible to establish two connections (LSPs) from the source CE device to the same destination CE device where one connection is using one UNI link to PE1, for example, and the other connection is using the UNI link to PE2. In order to avoid single points of failure within the provider network, it is necessary to also ensure path (LSP) diversity within the provider network to achieve end-to-end diversity for the two LSPs between the two CE devices CE1 and CE2. This use case describes how it is possible to achieve path diversity within the provider network based on collected SRLG information. As the two connections (LSPs) enter the provider network at different PE devices, the PE device that receives the connection request for the second connection needs to know the additional path computation constraints such that the path of the second LSP is disjoint with respect to the already established first connection.
デュアルホーミングの場合、たとえば、1つの接続がPE1への1つのUNIリンクを使用しており、もう1つの接続がUNIを使用しているソースCEデバイスから同じ宛先CEデバイスへの2つの接続（LSP）を確立することが可能です。 PE2へのリンク。プロバイダーネットワーク内のシングルポイント障害を回避するために、プロバイダーネットワーク内のパス（LSP）ダイバーシティを確保して、2つのCEデバイスCE1とCE2間の2つのLSPのエンドツーエンドダイバーシティを実現する必要もあります。この使用例では、収集されたSRLG情報に基づいてプロバイダーネットワーク内でパスダイバーシティを実現する方法について説明します。 2つの接続（LSP）が異なるPEデバイスでプロバイダーネットワークに入ると、2番目の接続の接続要求を受信するPEデバイスは、2番目のLSPのパスがすでに最初の接続が確立されています。
As SRLG information is normally not shared between the provider network and the client network, i.e., between PE and CE devices, the challenge is how to solve the diversity problem when a CE is dual-homed. The RSVP extensions for collecting SRLG information defined in this document make it possible to retrieve SRLG information for an LSP and hence solve the dual-homing LSP diversity problem. For example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1 that is routed via PE3 to CE2. CE1 can then subsequently request an LSP2 to CE2 via PE2 with the constraint that it needs to be maximally SRLG disjoint with respect to LSP1. PE2, however, does not have any SRLG information associated with LSP1, and this is needed as input for its constraint-based path computation function. If CE1 is capable of retrieving the SRLG information associated with LSP1 from PE1, it can pass this discovered information to PE2 as part of the LSP2 setup request (RSVP PATH message) in an EXCLUDE_ROUTE Object (XRO) or Explicit Exclusion Route Subobject (EXRS) as described in [RFC4874], and PE2 can now calculate a path for LSP2 that is SRLG disjoint with respect to LSP1. The SRLG information associated with LSP1 can be retrieved when LSP1 is established or at any time before LSP2 is set up.
SRLG情報は通常、プロバイダーネットワークとクライアントネットワーク間、つまりPEデバイスとCEデバイス間で共有されないため、CEがデュアルホーム接続されている場合の多様性の問題をどのように解決するかが課題になります。このドキュメントで定義されているSRLG情報を収集するためのRSVP拡張機能により、LSPのSRLG情報を取得できるため、デュアルホーミングLSPダイバーシティの問題を解決できます。たとえば、図1のCE1は、PE3を介してCE2にルーティングされるPE1を介してLSP1をCE2に要求した可能性があります。その後、CE1は、LSP1に対してSRLGを最大限に切り離す必要があるという制約を使用して、PE2経由でCE2にLSP2を要求できます。ただし、PE2にはLSP1に関連付けられたSRLG情報がありません。これは、制約ベースのパス計算機能の入力として必要です。 CE1がLSP1に関連付けられたSRLG情報をPE1から取得できる場合、この検出された情報を、EXCLUDE_ROUTEオブジェクト（XRO）または明示的除外ルートサブオブジェクト（EXRS）のLSP2セットアップ要求（RSVP PATHメッセージ）の一部としてPE2に渡すことができます。 [RFC4874]で説明されているように、PE2はLSP1に関してSRLGの素であるLSP2のパスを計算できるようになりました。 LSP1が確立されたとき、またはLSP2が設定される前であればいつでも、LSP1に関連付けられたSRLG情報を取得できます。
When CE1 sends the setup request for LSP2 to PE2, it can also request the collection of SRLG information for LSP2 and send that information to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's discovered SRLGs. This will ensure that the two paths for the two LSPs remain mutually diverse; this is important when the provider network is capable of restoring connections that failed due to a network failure (fiber cut) in the provider network.
CE1がLSP2のセットアップ要求をPE2に送信すると、LSP2のSRLG情報のコレクションを要求し、LSP2の検出されたSRLGに基づくSRLG除外を使用してLSP1に再シグナリングすることにより、その情報をPE1に送信することもできます。これにより、2つのLSPの2つのパスが相互に多様性を保つことが保証されます。これは、プロバイダーネットワークでプロバイダーネットワークのネットワーク障害（ファイバーカット）が原因で失敗した接続を復元できる場合に重要です。
Note that the knowledge of SRLG information even for multiple LSPs does not allow a CE device to derive the provider network topology based on the collected SRLG information. It would, however, be possible for an entity controlling multiple CE devices to derive some information related to the topology. This document therefore allows PE devices to control the communication of SRLGs outside the provider network if desired.
複数のLSPについてもSRLG情報を認識しているため、CEデバイスは、収集されたSRLG情報に基づいてプロバイダーネットワークトポロジを導出できません。ただし、複数のCEデバイスを制御するエンティティがトポロジに関連するいくつかの情報を導出することは可能です。したがって、このドキュメントでは、必要に応じて、PEデバイスがプロバイダーネットワーク外のSRLGの通信を制御できるようにします。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The SRLG collection process takes place in three stages:
SRLG収集プロセスは、次の3つの段階で行われます。
o The LSP's ingress node requests that SRLG collection take place;
o LSPの入力ノードは、SRLG収集が行われることを要求します。
o SRLG data is added to the Path and Resv ROUTE_RECORD Objects (RROs) by all nodes during signaling;
o SRLGデータは、シグナリング中にすべてのノードによってPathおよびResv ROUTE_RECORDオブジェクト（RRO）に追加されます。
o Changes to previously signaled SRLG data are made by sending updated Path and Resv messages as required.
o 以前に通知されたSRLGデータへの変更は、必要に応じて更新されたPathおよびResvメッセージを送信することによって行われます。
The ingress node of the LSP needs be capable of indicating whether the SRLG information of the LSP is to be collected during the signaling procedure of setting up an LSP. There is no need for SRLG information to be collected without an explicit request by the ingress node.
LSPの入力ノードは、LSPをセットアップするシグナリング手順中に、LSPのSRLG情報を収集するかどうかを示すことができる必要があります。入力ノードによる明示的な要求なしにSRLG情報を収集する必要はありません。
It may be preferable for the SRLG collection request to be understood by all nodes along the LSP's path, or it may be more important for the LSP to be established successfully even if it traverses nodes that cannot supply SRLG information or have not implemented the procedures specified in this document. It is desirable for the ingress node to make the SRLG collection request in a manner that best suits its own policy.
SRLG収集要求がLSPのパスに沿ったすべてのノードによって理解されることが望ましい場合があります。または、SRLG情報を提供できないか、指定された手順を実装していないノードをトラバースする場合でも、LSPが正常に確立されることがより重要になる場合があります。このドキュメントで。入力ノードは、自身のポリシーに最も適した方法でSRLGコレクション要求を行うことが望ましいです。
If requested, the SRLG information is collected during the setup of an LSP. SRLG information is added by each hop to the Path RRO during Path message processing. The same information is also added to the Resv RRO during Resv processing at each hop.
要求された場合、LSPのセットアップ中にSRLG情報が収集されます。 SRLG情報は、パスメッセージの処理中に各ホップによってパスRROに追加されます。各ホップでのResv処理中に、同じ情報がResv RROにも追加されます。
When the SRLG information of an existing LSP for which SRLG information was collected during signaling changes, the relevant nodes of the LSP need to be capable of updating the SRLG information of the LSP. This means that the signaling procedure needs to be capable of updating the new SRLG information.
シグナリング中にSRLG情報が収集された既存のLSPのSRLG情報が変更された場合、LSPの関連ノードは、LSPのSRLG情報を更新できる必要があります。これは、シグナリング手順が新しいSRLG情報を更新できる必要があることを意味します。
The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity in [RFC4202]. This definition is used in this document.
SRLGの識別子（SRLG ID）は、[RFC4202]で32ビット量として定義されています。この定義はこのドキュメントで使用されます。
In order to indicate to nodes that SRLG collection is desired, this document defines a new flag in the Attribute Flags TLV (see [RFC5420]). This document defines a new SRLG Collection Flag in the Attribute Flags TLV. A node that wishes to indicate that SRLG collection is desired MUST set this flag in an Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES object (if collection is to be mandatory) or an LSP_ATTRIBUTES object (if collection is desired but not mandatory).
SRLGコレクションが必要であることをノードに示すために、このドキュメントでは、属性フラグTLVで新しいフラグを定義しています（[RFC5420]を参照）。このドキュメントでは、属性フラグTLVで新しいSRLGコレクションフラグを定義しています。 SRLGコレクションが必要であることを示すノードは、LSP_REQUIRED_ATTRIBUTESオブジェクト（コレクションが必須の場合）またはLSP_ATTRIBUTESオブジェクト（コレクションが必要だが必須ではない場合）の属性フラグTLVにこのフラグを設定する必要があります。
o Bit Number (specified in Section 8.1): SRLG Collection Flag
o ビット番号（セクション8.1で指定）：SRLGコレクションフラグ
The SRLG Collection Flag is meaningful on a Path message. If the SRLG Collection Flag is set to 1, it means that the SRLG information SHOULD be reported to the ingress and egress node along the setup of the LSP.
SRLGコレクションフラグは、パスメッセージで意味があります。 SRLGコレクションフラグが1に設定されている場合、LSPの設定に沿ってSRLG情報が入力ノードと出力ノードに報告される必要がある（SHOULD）。
The rules for the processing of the Attribute Flags TLV are not changed.
属性フラグTLVの処理規則は変更されません。
This document defines a new RRO subobject (ROUTE_RECORD subobject) to record the SRLG information of the LSP. Its format is modeled on the RRO subobjects defined in [RFC3209].
このドキュメントでは、LSPのSRLG情報を記録するための新しいRROサブオブジェクト（ROUTE_RECORDサブオブジェクト）を定義します。そのフォーマットは[RFC3209]で定義されたRROサブオブジェクトをモデルにしています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits)
タイプ（8ビット）
The type of the subobject. The value is specified in Section 8.2.
サブオブジェクトのタイプ。値はセクション8.2で指定されています。
Length (8 bits)
長さ（8ビット）
The Length field contains the total length of the subobject in octets, including the Type and Length fields. The Length depends on the number of SRLG IDs.
長さフィールドには、タイプおよび長さフィールドを含む、オクテット単位のサブオブジェクトの全長が含まれます。長さはSRLG IDの数によって異なります。
Direction bit (D-bit) (1 bit)
方向ビット（Dビット）（1ビット）
If not set, the SRLGs contained in this subobject apply to the downstream direction. If set, they apply to the upstream direction.
設定されていない場合、このサブオブジェクトに含まれているSRLGはダウンストリーム方向に適用されます。設定すると、上流方向に適用されます。
Reserved (15 bits)
予約済み（15ビット）
This 15-bit field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
この15ビットのフィールドは予約済みです。送信時にはゼロに設定する必要があり（SHOULD）、受信時には無視する必要があります。
SRLG ID (4 octets)
SRLG ID（4オクテット）
This field contains one SRLG ID. There is one SRLG ID field per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG subobject.
このフィールドには1つのSRLG IDが含まれます。収集されたSRLGごとに1つのSRLG IDフィールドがあります。 SRLGサブオブジェクトには複数のSRLG IDフィールドが存在する場合があります。
A node MUST NOT push an SRLG subobject in the ROUTE_RECORD without also pushing either an IPv4 subobject, an IPv6 subobject, an Unnumbered Interface ID subobject, or a Path Key Subobject (PKS).
ノードは、IPv4サブオブジェクト、IPv6サブオブジェクト、番号なしインターフェイスIDサブオブジェクト、またはパスキーサブオブジェクト（PKS）のいずれもプッシュせずに、ROUTE_RECORDのSRLGサブオブジェクトをプッシュしてはなりません（MUST NOT）。
As described in [RFC3209], the ROUTE_RECORD object is managed as a stack. The SRLG subobject MUST be pushed by the node before the node IP address or link identifier. The SRLG subobject SHOULD be pushed after the Attribute subobject, if present, and after the LABEL subobject, if requested. It MUST be pushed within the hop to which it applies.
[RFC3209]で説明されているように、ROUTE_RECORDオブジェクトはスタックとして管理されます。 SRLGサブオブジェクトは、ノードのIPアドレスまたはリンク識別子の前にノードによってプッシュされる必要があります。 SRLGサブオブジェクトは、存在する場合は属性サブオブジェクトの後に、要求された場合はLABELサブオブジェクトの後にプッシュする必要があります（SHOULD）。適用するホップ内にプッシュする必要があります。
[RFC5553] describes mechanisms to carry a PKS in the RRO so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. RFC 5553 allows the path segment that needs to be hidden (that is, a Confidential Path Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS contains SRLG subobjects, these MAY be retained in the RRO by adding them again after the PKS in the RRO. The CPS is defined in [RFC5520].
[RFC5553]は、ドメイン間TE LSPのシグナリングの機密性を容易にするために、RROでPKSを伝送するメカニズムについて説明しています。 RFC 5553では、非表示にする必要があるパスセグメント（つまり、機密パスセグメント（CPS））をRROでPKSに置き換えることができます。 CPSにSRLGサブオブジェクトが含まれている場合、これらはRROのPKSの後に再度追加することにより、RROに保持される場合があります。 CPSは[RFC5520]で定義されています。
The rules for the processing of the LSP_REQUIRED_ATTRIBUTES, LSP_ATTRIBUTES, and ROUTE_RECORD objects are not changed.
LSP_REQUIRED_ATTRIBUTES、LSP_ATTRIBUTES、およびROUTE_RECORDオブジェクトの処理のルールは変更されません。
The ingress node of the LSP MUST be capable of indicating whether the SRLG information of the LSP is to be collected during the signaling procedure of setting up an LSP.
LSPの入力ノードは、LSPをセットアップするシグナリング手順中に、LSPのSRLG情報を収集するかどうかを指示できなければなりません（MUST）。
Per [RFC3209], an ingress node initiates the recording of the route information of an LSP by adding an RRO to a Path message. If an ingress node also desires SRLG recording, it MUST set the SRLG Collection Flag in the Attribute Flags TLV, which MAY be carried in either an LSP_REQUIRED_ATTRIBUTES object (when the collection is mandatory) or an LSP_ATTRIBUTES object (when the collection is desired, but not mandatory).
[RFC3209]に従い、入力ノードはRROをPathメッセージに追加することにより、LSPのルート情報の記録を開始します。入力ノードがSRLG記録も必要とする場合は、属性フラグTLVにSRLGコレクションフラグを設定する必要があります。これは、LSP_REQUIRED_ATTRIBUTESオブジェクト（コレクションが必須の場合）またはLSP_ATTRIBUTESオブジェクト（コレクションが必要な場合）に含めることができますが、必須ではありません）。
A node MUST NOT add SRLG information without an explicit request by the ingress node in the Path message.
ノードは、Pathメッセージで入力ノードによる明示的な要求なしにSRLG情報を追加してはなりません（MUST NOT）。
When a node receives a Path message that carries an LSP_REQUIRED_ATTRIBUTES object with the SRLG Collection Flag set, if local policy determines that the SRLG information is not to be provided to the endpoints, it MUST return a PathErr message with
ノードがSRLGコレクションフラグが設定されたLSP_REQUIRED_ATTRIBUTESオブジェクトを運ぶPathメッセージを受信したときに、ローカルポリシーがSRLG情報をエンドポイントに提供しないことを決定した場合、ノードはPathErrメッセージを返す必要があります。
o Error Code 2 (policy) and
o エラーコード2（ポリシー）および
o Error subcode "SRLG Recording Rejected" (see Section 8.3 for value)
o エラーサブコード "SRLG Recording Rejected"（値についてはセクション8.3を参照）
to reject the Path message.
Pathメッセージを拒否します。
When a node receives a Path message that carries an LSP_ATTRIBUTES object with the SRLG Collection Flag set, if local policy determines that the SRLG information is not to be provided to the endpoints, the Path message MUST NOT be rejected due to the SRLG recording restriction, and the Path message MUST be forwarded without any SRLG subobject(s) added to the RRO of the corresponding outgoing Path message.
SRLGコレクションフラグが設定されたLSP_ATTRIBUTESオブジェクトを含むPathメッセージをノードが受信したときに、ローカルポリシーがSRLG情報をエンドポイントに提供しないことを決定した場合、SRLG記録の制限により、Pathメッセージを拒否してはなりません。また、Pathメッセージは、対応する発信PathメッセージのRROにSRLGサブオブジェクトを追加せずに転送する必要があります。
If local policy permits the recording of the SRLG information, the processing node SHOULD add local SRLG information, as defined below, to the RRO of the corresponding outgoing Path message. The processing node MAY add multiple SRLG subobjects to the RRO if necessary. It then forwards the Path message to the next node in the downstream direction. The processing node MUST retain a record of the SRLG recording request for reference during Resv processing described below.
ローカルポリシーがSRLG情報の記録を許可する場合、処理ノードは、以下に定義されているように、対応する発信パスメッセージのRROにローカルSRLG情報を追加する必要があります（SHOULD）。処理ノードは、必要に応じて複数のSRLGサブオブジェクトをRROに追加してもよい（MAY）。次に、Pathメッセージをダウンストリーム方向の次のノードに転送します。処理ノードは、以下で説明するResv処理中に参照できるように、SRLG記録要求の記録を保持する必要があります。
If the addition of SRLG information to the RRO would result in the RRO exceeding its maximum possible size or becoming too large for the Path message to contain it, the requested SRLGs MUST NOT be added. If the SRLG collection request was contained in an LSP_REQUIRED_ATTRIBUTES object, the processing node MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. If the SRLG collection request was contained in an LSP_ATTRIBUTES object, the processing node MAY omit some or all of the requested SRLGs from the RRO; otherwise, it MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. Subsequent processing of the LSP proceeds as further specified in [RFC3209].
RROにSRLG情報を追加すると、RROがその最大サイズを超えたり、パスメッセージに含めるには大きすぎたりする場合、要求されたSRLGを追加してはなりません（MUST NOT）。 SRLGコレクション要求がLSP_REQUIRED_ATTRIBUTESオブジェクトに含まれていた場合、処理ノードは[RFC3209]の指定どおりに動作し、RROをPathメッセージから完全に削除する必要があります。 SRLGコレクション要求がLSP_ATTRIBUTESオブジェクトに含まれていた場合、処理ノードは要求されたSRLGの一部またはすべてをRROから省略してもよい（MAY）。それ以外の場合は、[RFC3209]で指定されているとおりに動作し、RROをPathメッセージから完全に削除する必要があります。その後のLSPの処理は、[RFC3209]でさらに指定されているように進行します。
Following the steps described above, the intermediate nodes of the LSP can collect the SRLG information in the RRO during the processing of the Path message hop by hop. When the Path message arrives at the egress node, the egress node receives SRLG information in the RRO.
上記の手順に続いて、LSPの中間ノードは、Pathメッセージのホップごとの処理中にRRO内のSRLG情報を収集できます。 Pathメッセージが出力ノードに到着すると、出力ノードはRROでSRLG情報を受信します。
Per [RFC3209], when issuing a Resv message for a Path message that contains an RRO, an egress node initiates the RRO process by adding an RRO to the outgoing Resv message. The processing for RROs contained in Resv messages then mirrors that of the Path messages.
[RFC3209]によると、RROを含むPathメッセージに対してResvメッセージを発行する場合、出力ノードはRROを発信Resvメッセージに追加することによってRROプロセスを開始します。 Resvメッセージに含まれるRROの処理は、Pathメッセージの処理を反映します。
When a node receives a Resv message for an LSP for which SRLG Collection was specified in the corresponding Path message, then when local policy allows recording SRLG information, the node MUST add SRLG information to the RRO of the corresponding outgoing Resv message as specified below. When the Resv message arrives at the ingress node, the ingress node can extract the SRLG information from the RRO in the same way as the egress node.
ノードが対応するPathメッセージでSRLGコレクションが指定されたLSPのResvメッセージを受信した場合、ローカルポリシーがSRLG情報の記録を許可する場合、ノードは以下に指定されているように、対応する発信ResvメッセージのRROにSRLG情報を追加する必要があります。 Resvメッセージが入口ノードに到着すると、入口ノードは出口ノードと同じ方法でRROからSRLG情報を抽出できます。
Note that a link's SRLG information for the upstream direction cannot be assumed to be the same as that for the downstream direction.
上流方向のリンクのSRLG情報は、下流方向の情報と同じであるとは想定できないことに注意してください。
o For Path and Resv messages for a unidirectional LSP, a node SHOULD include SRLG subobjects in the RRO for the downstream data link only.
o 単方向LSPのPathおよびResvメッセージの場合、ノードは、ダウンストリームデータリンクのRROにのみSRLGサブオブジェクトを含める必要があります（SHOULD）。
o For Path and Resv messages for a bidirectional LSP, a node SHOULD include SRLG subobjects in the RRO for both the upstream data link and the downstream data link from the local node. In this case, the node MUST include the information in the same order for both Path messages and Resv messages. That is, the SRLG subobject for the upstream link is added to the RRO before the SRLG subobject for the downstream link.
o 双方向LSPのPathおよびResvメッセージの場合、ノードは、ローカルノードからのアップストリームデータリンクとダウンストリームデータリンクの両方のRROにSRLGサブオブジェクトを含める必要があります（SHOULD）。この場合、ノードはPathメッセージとResvメッセージの両方に同じ順序で情報を含める必要があります。つまり、アップストリームリンクのSRLGサブオブジェクトは、ダウンストリームリンクのSRLGサブオブジェクトの前にRROに追加されます。
If SRLG data is added for both the upstream and downstream links, the two sets of SRLG data MUST be added in separate SRLG subobjects. A single SRLG subobject MUST NOT contain a mixture of upstream and downstream SRLGs. When adding a SRLG subobject to an RRO, the D-bit MUST be set appropriately to indicate the direction of the SRLGs. If an SRLG ID applies in both directions, it SHOULD be added to both the upstream and downstream SRLG subobjects.
SRLGデータがアップストリームリンクとダウンストリームリンクの両方に追加される場合は、2セットのSRLGデータを別々のSRLGサブオブジェクトに追加する必要があります。単一のSRLGサブオブジェクトに、上流と下流のSRLGが混在していてはいけません（MUST NOT）。 SRLGサブオブジェクトをRROに追加する場合、Dビットを適切に設定して、SRLGの方向を示す必要があります。 SRLG IDが両方向に適用される場合、上流と下流の両方のSRLGサブオブジェクトに追加する必要があります（SHOULD）。
Based on the above procedure, the endpoints can get the SRLG information automatically. Then, for instance, the endpoints can advertise it as a TE link to the routing instance based on the procedure described in [RFC6107] and configure the SRLG information of the Forwarding Adjacency (FA) automatically.
上記の手順に基づいて、エンドポイントはSRLG情報を自動的に取得できます。次に、たとえば、エンドポイントは[RFC6107]で説明されている手順に基づいてルーティングインスタンスへのTEリンクとしてそれをアドバタイズし、転送隣接（FA）のSRLG情報を自動的に構成できます。
When the SRLG information of a link is changed, the endpoints of LSPs using that link need to be made aware of the changes. When a change to the set of SRLGs associated with a link occurs, the procedures defined in Section 4.4.3 of [RFC3209] MUST be used to refresh the SRLG information for each affected LSP if the local node's policy dictates that the SRLG change be communicated to other nodes.
リンクのSRLG情報が変更された場合、そのリンクを使用するLSPのエンドポイントに変更を認識させる必要があります。リンクに関連付けられているSRLGのセットに変更が発生した場合、ローカルノードのポリシーでSRLGの変更を通知するように指示されている場合、[RFC3209]のセクション4.4.3で定義されている手順を使用して、影響を受ける各LSPのSRLG情報を更新する必要があります。他のノードへ。
If mandated by local policy as specified by the network operator, a node MAY remove SRLG information from any RRO in a Path or Resv message being processed. It MAY add a summary of the removed SRLGs or map them to other SRLG values. However, this SHOULD NOT be done unless explicitly mandated by local policy.
ネットワークオペレーターによって指定されたローカルポリシーによって義務付けられている場合、ノードは、処理中のPathまたはResvメッセージ内のRROからSRLG情報を削除できます（MAY）。削除されたSRLGの概要を追加したり、他のSRLG値にマップしたりする場合があります。ただし、ローカルポリシーで明示的に義務付けられていない限り、これを実行してはなりません。
A node that does not recognize the SRLG Collection Flag in the Attribute Flags TLV is expected to proceed as specified in [RFC5420]. It is expected to pass the TLV on unaltered if it appears in an LSP_ATTRIBUTES object or to reject the Path message with the appropriate Error Code and Value if it appears in a LSP_REQUIRED_ATTRIBUTES object.
属性フラグTLVのSRLGコレクションフラグを認識しないノードは、[RFC5420]で指定されているように処理されることが期待されています。 LSP_ATTRIBUTESオブジェクトに表示される場合はTLVを変更せずに渡すか、LSP_REQUIRED_ATTRIBUTESオブジェクトに表示される場合は適切なエラーコードと値でパスメッセージを拒否することが期待されます。
A node that does not recognize the SRLG RRO subobject is expected to behave as specified in [RFC3209]: unrecognized subobjects are to be ignored and passed on unchanged.
SRLG RROサブオブジェクトを認識しないノードは、[RFC3209]で指定されたとおりに動作することが期待されています。認識されないサブオブジェクトは無視され、変更されずに渡されます。
In a border node of an inter-domain or inter-layer network, the following SRLG processing policy MUST be capable of being configured:
ドメイン間またはレイヤー間ネットワークの境界ノードでは、次のSRLG処理ポリシーを構成できる必要があります。
o Whether the node is allowed to participate in SRLG collection and notify changes to collected SRLG information to endpoint nodes as described in Section 5.2.
o セクション5.2で説明されているように、ノードがSRLGコレクションに参加し、収集されたSRLG情報の変更をエンドポイントノードに通知することを許可するかどうか。
o Whether the SRLG IDs of the domain or specific layer network can be exposed to the nodes outside the domain or layer network, or whether they SHOULD be summarized, mapped to values that are comprehensible to nodes outside the domain or layer network, or removed entirely as described in Section 5.3.
o ドメインまたは特定のレイヤーネットワークのSRLG IDをドメインまたはレイヤーネットワークの外部のノードに公開できるかどうか、またはそれらを要約するか、ドメインまたはレイヤーネットワークの外部のノードが理解できる値にマッピングするか、または完全に削除する必要があるか（SHOULD）セクション5.3で説明します。
A node using [RFC5553] and PKS MAY apply the same policy.
[RFC5553]とPKSを使用するノードは、同じポリシーを適用できます。
In a multi-layer, multi-domain scenario, SRLG IDs can be configured by different management entities in each layer or domain. In such scenarios, maintaining a coherent set of SRLG IDs is a key requirement in order to be able to use the SRLG information properly. Thus, SRLG IDs SHOULD be unique. Note that current procedures are targeted towards a scenario where the different layers and domains belong to the same operator or to several coordinated administrative groups. Ensuring the aforementioned coherence of SRLG IDs is beyond the scope of this document.
マルチレイヤー、マルチドメインのシナリオでは、SRLG IDは、各レイヤーまたはドメインの異なる管理エンティティーによって構成できます。このようなシナリオでは、SRLG IDの一貫したセットを維持することが、SRLG情報を適切に使用できるようにするための重要な要件です。したがって、SRLG IDは一意である必要があります。現在の手順は、異なるレイヤーとドメインが同じオペレーターまたは複数の調整された管理グループに属しているシナリオを対象としていることに注意してください。前述のSRLG IDの一貫性を保証することは、このドキュメントの範囲を超えています。
Further scenarios, where coherence in the SRLG IDs cannot be guaranteed, are out of the scope of the present document and are left for further study.
SRLG IDの一貫性が保証されないその他のシナリオは、現在のドキュメントの範囲外であり、今後の調査に残されます。
This document builds on the mechanisms defined in [RFC3473], which also discusses related security measures. In addition, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. The procedures defined in this document permit the transfer of SRLG data between layers or domains during the signaling of LSPs, subject to policy at the layer or domain boundary. As described in Sections 5.3 and 6.1, local policy as specified by the network operator will explicitly mandate the processing of information at domain or layer boundaries.
このドキュメントは、[RFC3473]で定義されているメカニズムに基づいており、関連するセキュリティ対策についても説明しています。さらに、[RFC5920]は、GMPLSコントロールプレーンのセキュリティの脆弱性と保護メカニズムの概要を提供します。このドキュメントで定義されている手順では、レイヤまたはドメインの境界でのポリシーに従い、LSPのシグナリング中にレイヤまたはドメイン間でSRLGデータを転送できます。セクション5.3および6.1で説明されているように、ネットワークオペレーターによって指定されたローカルポリシーは、ドメインまたはレイヤーの境界での情報の処理を明示的に要求します。
IANA has created a registry and manages the space of the Attribute bit flags of the Attribute Flags TLV, as described in Section 11.3 of [RFC5420], in the "Attribute Flags" subregistry of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located at <http://www.iana.org/assignments/rsvp-te-parameters>.
IANAは、レジストリを作成し、[RFC5420]のセクション11.3で説明されているように、「Resource Reservation Protocol-Traffic Engineering（RSVP-TE ）<http://www.iana.org/assignments/rsvp-te-parameters>にあるParameters "レジストリ。
This document introduces a new Attribute bit flag:
このドキュメントでは、新しい属性ビットフラグを紹介します。
Bit No Name Attribute Attribute RRO ERO Reference
Flags Path Flags Resv
--------- ---------- ---------- ----------- --- --- ---------
12 SRLG Yes No Yes No RFC 8001,
Collection [RFC7570]
Flag
IANA manages the "Resource Reservation Protocol (RSVP) Parameters" registry located at <http://www.iana.org/assignments/rsvp-parameters>. This document introduces a new RRO subobject under the "Sub-object type - 21 ROUTE_RECORD - Type 1 Route Record" subregistry:
IANAは、<http://www.iana.org/assignments/rsvp-parameters>にある「リソース予約プロトコル（RSVP）パラメータ」レジストリを管理します。このドキュメントでは、「サブオブジェクトタイプ-21 ROUTE_RECORD-タイプ1ルートレコード」サブレジストリの下に新しいRROサブオブジェクトを紹介します。
Value Description Reference
----- ------------------- ---------
34 SRLG subobject RFC 8001
IANA manages the assignments in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at <http://www.iana.org/assignments/rsvp-parameters>.
IANAは、<http://www.iana.org/assignments/rsvp-parametersにある「Resource Reservation Protocol（RSVP）Parameters」レジストリの「Error Codes and Globally-Defined Error Value Sub-Codes」セクションで割り当てを管理します>。
This document introduces a new value under "Sub-Codes - 2 Policy Control Failure":
このドキュメントでは、「サブコード-2ポリシー制御エラー」の下に新しい値を紹介しています。
Value Description Reference
----- ----------------------- ---------
21 SRLG Recording Rejected RFC 8001
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202] Kompella、K。、編、およびY. Rekhter、編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、DOI 10.17487 / RFC4202、2005年10月、<http： //www.rfc-editor.org/info/rfc4202>。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<http://www.rfc-editor.org/info/rfc5420>。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<http://www.rfc-editor.org/info/rfc5520>。
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, <http://www.rfc-editor.org/info/rfc5553>.
[RFC5553] Farrel、A.、Ed。、Bradford、R.、JP。 Vasseur、「Resource Reservation Protocol（RSVP）Extensions for Path Key Support」、RFC 5553、DOI 10.17487 / RFC5553、2009年5月、<http://www.rfc-editor.org/info/rfc5553>。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <http://www.rfc-editor.org/info/rfc4206>.
[RFC4206] Kompella、K。およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、DOI 10.17487 / RFC4206、2005年10月、<http ：//www.rfc-editor.org/info/rfc4206>。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, <http://www.rfc-editor.org/info/rfc4208>.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「Generalized Multiprotocol Label Switching（GMPLS）User-Network Interface（UNI）：Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、DOI 10.17487 / RFC4208、2005年10月、<http://www.rfc-editor.org/info/rfc4208>。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC4874] Lee、CY。、Farrel、A。、およびS. De Cnodder、「Exclude Routes-Extension to Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）」、RFC 4874、DOI 10.17487 / RFC4874、2007年4月、< http://www.rfc-editor.org/info/rfc4874>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, DOI 10.17487/RFC6107, February 2011, <http://www.rfc-editor.org/info/rfc6107>.
[RFC6107] Shiomoto、K.、Ed。、and A. Farrel、Ed。、 "Procedures for Dynamicly Signaled Hierarchical Label Switched Paths"、RFC 6107、DOI 10.17487 / RFC6107、February 2011、<http：//www.rfc- editor.org/info/rfc6107>。
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <http://www.rfc-editor.org/info/rfc7570>.
[RFC7570]マーガリア、C。、編、マルティネリ、G。、ボール、S。、およびB.ライト、「明示的ルートオブジェクト（ERO）のラベルスイッチドパス（LSP）属性」、RFC 7570、DOI 10.17487 / RFC7570、2015年7月、<http://www.rfc-editor.org/info/rfc7570>。
Acknowledgements
謝辞
The authors would like to thank Dieter Beller, Vishnu Pavan Beeram, Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah, and Xian Zhang for their useful comments and improvements to this document.
著者は、Dieter Beller、Vishnu Pavan Beeram、Lou Berger、Deborah Brungard、Igor Bryskin、Ramon Casellas、Niclas Comstedt、Alan Davey、Elwyn Davies、Dhruv Dhody、Himanshu Shah、およびXian Zhangに役立つコメントと改善に感謝します。このドキュメント。
Contributors
貢献者
Dan Li Huawei F3-5-B RD Center Bantian, Longgang District, Shenzhen 518129 China
Dan l IH UAはF3-5-br Dセンター禁止日、長いギャング地区、Sは非常に現実的です518129中国
Email: danli@huawei.com
Authors' Addresses
著者のアドレス
Fatai Zhang (editor) Huawei F3-5-B RD Center Bantian, Longgang District, Shenzhen 518129 China
fa too Zhang（編集者）hu AはF3-5-br Dセンター禁止日、長いギャング地区、Sは非常に現実的な518129中国
Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios (editor) Telefonica Global CTO Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 Madrid 28050 Spain Phone: +34 913129647
オスカーゴンザレスデディオス（編集者）テレフォニカグローバルCTO Distritoテレフォニカ、南の建物、ロンダデラコミュニカシオン28045マドリード28050スペイン電話：+34 913129647
Email: oscar.gonzalezdedios@telefonica.com
Cyril Margaria Juniper 200 Somerset Corporate Blvd., Suite 4001 Bridgewater, NJ 08807 United States of America
Cyril Margaria Juniper 200 Somerset Corporate Blvd.、Suite 4001 Bridgewater、NJ 08807 United States of America
Email: cmargaria@juniper.net
Matt Hartley Cisco
マットハートリーシスコ
Email: mhartley@cisco.com
Zafar Ali Cisco
シスコのドファール
Email: zali@cisco.com