[要約] RFC 8149は、ポイントツーマルチポイントトラフィックエンジニアリングのラベルスイッチドパス（LSP）の再最適化のためのRSVP拡張に関するものです。このRFCの目的は、LSPの再最適化をサポートするためのRSVP拡張を提供することです。
Internet Engineering Task Force (IETF) T. Saad, Ed.
Request for Comments: 8149 R. Gandhi, Ed.
Category: Standards Track Z. Ali
ISSN: 2070-1721 Cisco Systems, Inc.
R. Venator
Defense Information Systems Agency
Y. Kamite
NTT Communications Corporation
April 2017
RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
緩やかにルーティングされたポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパス（LSP）の再最適化のためのRSVP拡張機能
Abstract
概要
The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.
ポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）の再最適化は、個々のソースツーリーフ（S2L）サブLSPまたはS2Lのセットを再最適化する必要性に基づいてトリガーされますサブLSP（両方ともサブグループベースの再最適化方法を使用）、またはMake-Before-Break（MBB）メソッドを使用したP2MP-TE LSPツリー全体。このドキュメントでは、ルーズルーティングされたポイントツーポイント（P2P）TE LSPからP2MP-TE LSPへのパス再最適化のための既存のメカニズムの適用について説明し、その際の問題を特定し、それらに対処する手順を定義します。サブグループベースの再最適化方法を使用してツリー内の多数のS2LサブLSPを再最適化する場合、S2LサブLSP記述子リストを意味的に断片化する必要がある場合があります。このドキュメントでは、フラグメント識別子の概念を定義して、受信ノードがフラグメント化されたS2LサブLSP記述子リストを明確に再構築できるようにします。
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/rfc8149.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8149で入手できます。
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
2. Conventions Used in This Document ...............................4
2.1. Key Word Definitions .......................................4
2.2. Abbreviations ..............................................4
2.3. Terminology ................................................4
3. Overview ........................................................5
3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree ...............5
3.2. Existing Mechanism for Tree-Based P2MP-TE LSP
Reoptimization .............................................6
3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP
Reoptimization .............................................7
4. Signaling Extensions for Loosely Routed P2MP-TE LSP
Reoptimization ..................................................8
4.1. Tree-Based Reoptimization ..................................8
4.2. Sub-Group-Based Reoptimization Using Fragment Identifier ...9
5. Message and Object Definitions .................................11
5.1. "P2MP-TE Tree Re-evaluation Request" Flag .................11
5.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......11
5.3. Fragment Identifier for S2L Sub-LSP Descriptor ............11
6. Compatibility ..................................................12
7. IANA Considerations ............................................13
7.1. "P2MP-TE Tree Re-evaluation Request" Flag .................13
7.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......13
7.3. Fragment Identifier for S2L Sub-LSP Descriptor ............14
8. Security Considerations ........................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgments ...................................................16
Authors' Addresses ................................................17
This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Paths (LSPs) [RFC4875] in a Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) [RFC3473] network.
このドキュメントでは、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）[RFC2205] [RFC3209]で拡張されたルーズルーテッドポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）[RFC4875]を再最適化するためのシグナリング拡張機能を定義します。マルチプロトコルラベルスイッチング（MPLS）または汎用MPLS（GMPLS）[RFC3473]ネットワーク。
A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one whose path does not contain the full explicit route identifying each node along the path to the egress node at the time of its signaling by the ingress node. Such an S2L sub-LSP is signaled with no Explicit Route Object (ERO) [RFC3209], with an ERO that contains at least one "loose next hop", or with an ERO that contains an abstract node that identifies more than one node. This is often the case with inter-domain P2MP-TE LSPs where a Path Computation Element (PCE) is not used [RFC5440].
P2MP-TE LSPは、1つ以上のソースからリーフ（S2L）へのサブLSPで構成されます。緩やかにルーティングされたP2MP-TE S2LサブLSPは、入口ノードによるシグナリング時に、出口ノードへのパスに沿った各ノードを識別する完全な明示ルートをパスに含まないものとして定義されます。このようなS2LサブLSPは、明示的ルートオブジェクト（ERO）[RFC3209]なし、少なくとも1つの「ルーズネクストホップ」を含むERO、または複数のノードを識別する抽象ノードを含むEROでシグナリングされます。これは、パス計算要素（PCE）が使用されないドメイン間P2MP-TE LSPでよく発生します[RFC5440]。
As per [RFC4875], an ingress node may reoptimize the entire P2MP-TE LSP tree by re-signaling all its S2L sub-LSPs using the Make-Before-Break (MBB) method, or it may reoptimize an individual S2L sub-LSP or a set of S2L sub-LSPs, i.e., an individual destination or a set of destinations, both using the Sub-Group-based reoptimization method.
[RFC4875]のように、イングレスノードはMake-Before-Break（MBB）メソッドを使用してすべてのS2LサブLSPを再シグナリングすることにより、P2MP-TE LSPツリー全体を再最適化するか、個々のS2LサブLSPを再最適化します。または、どちらもサブグループベースの再最適化方法を使用する、S2LサブLSPのセット、つまり、個別の宛先または宛先のセット。
[RFC4736] defines an RSVP signaling procedure for reoptimizing the path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). The mechanisms listed in [RFC4736] include a method for the ingress node to trigger a new path re-evaluation request and a method for the midpoint node to send a notification regarding the availability of a preferred path. This document discusses the application of those mechanisms to the reoptimization of loosely routed P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them.
[RFC4736]は、ルーズにルーティングされたポイントツーポイント（P2P）TE LSPのパスを再最適化するためのRSVPシグナリング手順を定義しています。 [RFC4736]に記載されているメカニズムには、入口ノードが新しいパスの再評価要求をトリガーする方法と、中間ノードが優先パスの可用性に関する通知を送信する方法が含まれます。このドキュメントでは、緩やかにルーティングされたP2MP-TE LSPの再最適化へのそれらのメカニズムの適用について説明し、その際の問題を特定し、それらに対処する手順を定義します。
For reoptimizing a group of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This RSVP message may need to be semantically fragmented when a large number of S2L sub-LSPs are added to the descriptor list. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.
サブグループベースの再最適化方法を使用してツリー内のS2LサブLSPのグループを再最適化するために、S2LサブLSP記述子リストを使用して、RSVPメッセージ内の1つ以上のS2LサブLSPを通知できます。このRSVPメッセージは、多数のS2LサブLSPが記述子リストに追加されるときに、意味的に断片化される必要がある場合があります。このドキュメントでは、フラグメント識別子の概念を定義して、受信ノードがフラグメント化されたS2LサブLSP記述子リストを明確に再構築できるようにします。
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]で説明されているように解釈されます。
ABR: Area Border Router.
ABR：エリアボーダールーター。
ERO: Explicit Route Object.
ERO：明示的なルートオブジェクト。
LSP: Label Switched Path.
LSP：ラベルスイッチドパス。
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
RRO: Record Route Object.
RRO：レコードルートオブジェクト。
S2L sub-LSP: Source-to-leaf sub-LSP.
S2L sub-LSP：ソースからリーフへのサブLSP。
TE LSP: Traffic Engineering LSP.
TE LSP：トラフィックエンジニアリングLSP。
This document defines the following terms:
このドキュメントでは、次の用語を定義しています。
o Ingress node: Head-end / source node of the TE LSP.
o 入力ノード：TE LSPのヘッドエンド/ソースノード。
o Egress node: Tail-end / destination node of the TE LSP.
o 出力ノード：TE LSPのテールエンド/宛先ノード。
It is assumed that the reader is also familiar with the terminology in [RFC4736] and [RFC4875].
読者も[RFC4736]と[RFC4875]の用語に精通していることを前提としています。
[RFC4736] defines RSVP signaling extensions for reoptimizing loosely routed P2P TE LSPs as follows:
[RFC4736]は、緩やかにルーティングされたP2P TE LSPを再最適化するためのRSVPシグナリング拡張を次のように定義しています。
o A midpoint LSR that expands loose next hop(s) sends a solicited or unsolicited PathErr with Notify error code 25 (as defined in [RFC3209]), with sub-code 6 to indicate "Preferable Path Exists" to the ingress node.
o 緩やかなネクストホップを拡張する中間ポイントLSRは、通知エラーコード25（[RFC3209]で定義）を使用して要請または非要請のPathErrを送信し、サブコード6は「優先パスの存在」を入力ノードに示します。
o An ingress node triggers a path re-evaluation request at all midpoint LSRs that expand loose next hop(s) by setting the "Path Re-evaluation Request" flag (0x20) in the SESSION_ATTRIBUTES object in the Path message.
o 入力ノードは、PathメッセージのSESSION_ATTRIBUTESオブジェクトの「Path Re-evaluation Request」フラグ（0x20）を設定することにより、ルーズネクストホップを拡張するすべての中間ポイントLSRでパス再評価要求をトリガーします。
o The ingress node, upon receiving this PathErr with the Notify error code (either solicited or unsolicited), initiates the reoptimization of the LSP, using the MBB method with a different LSP-ID.
o 入力ノードは、Notifyエラーコード（送信請求または非送信請求）とともにこのPathErrを受信すると、別のLSP-IDでMBBメソッドを使用して、LSPの再最適化を開始します。
The following sections discuss the issues that may arise when applying the mechanisms defined in [RFC4736] for reoptimizing loosely routed P2MP-TE LSPs.
次のセクションでは、ルーズにルーティングされたP2MP-TE LSPを再最適化するために[RFC4736]で定義されたメカニズムを適用するときに発生する可能性がある問題について説明します。
An example of a loosely routed inter-domain P2MP-TE LSP tree is shown in Figure 1. In this example, the P2MP-TE LSP tree consists of three S2L sub-LSPs, to destinations (i.e., leafs) R10, R11, and R12 from the ingress node (i.e., source) R1. Nodes R2 and R5 are branch nodes, and nodes ABR3, ABR4, ABR7, ABR8, and ABR9 are ABRs. For the S2L sub-LSP to destination R10, nodes ABR3, ABR7, and R10 are defined as loose next hops. For the S2L sub-LSP to destination R11, nodes ABR3, ABR8, and R11 are defined as loose next hops. For the S2L sub-LSP to destination R12, nodes ABR4, ABR9, and R12 are defined as loose next hops.
緩やかにルーティングされたドメイン間P2MP-TE LSPツリーの例を図1に示します。この例では、P2MP-TE LSPツリーは3つのS2LサブLSPから構成され、宛先（つまり、リーフ）R10、R11、および入力ノード（つまり、ソース）R1からのR12。ノードR2およびR5はブランチノードであり、ノードABR3、ABR4、ABR7、ABR8、およびABR9はABRです。宛先R10へのS2LサブLSPの場合、ノードABR3、ABR7、およびR10はルーズネクストホップとして定義されます。宛先R11へのS2LサブLSPの場合、ノードABR3、ABR8、およびR11はルーズネクストホップとして定義されます。宛先R12へのS2LサブLSPの場合、ノードABR4、ABR9、およびR12はルーズネクストホップとして定義されます。
<--area1--><--area0--><-area2->
ABR7---R10
/
/
ABR3---R5
/ \
/ \
R1---R2 ABR8---R11
\
\
ABR4---R6
\
\
ABR9---R12
Figure 1: Example of Loosely Routed Inter-domain P2MP-TE LSP Tree
図1：ルーズにルーティングされたドメイン間P2MP-TE LSPツリーの例
The mechanisms defined in [RFC4736] can be easily applied to trigger the reoptimization of an individual S2L sub-LSP or a group of S2L sub-LSPs. However, to apply those mechanisms for triggering the reoptimization of a P2MP-TE LSP tree, an ingress node needs to send path re-evaluation requests on all (typically hundreds) of the S2L sub-LSPs, and the midpoint LSR needs to send PathErrs with the Notify error code for all S2L sub-LSPs. Such mechanisms may lead to the following issues:
[RFC4736]で定義されたメカニズムは、個々のS2LサブLSPまたはS2LサブLSPのグループの再最適化をトリガーするために簡単に適用できます。ただし、これらのメカニズムを適用してP2MP-TE LSPツリーの再最適化をトリガーするには、入力ノードがすべて（通常は数百）のS2LサブLSPにパス再評価要求を送信し、ミッドポイントLSRがPathErrsを送信する必要がありますすべてのS2LサブLSPの通知エラーコード。このようなメカニズムにより、次の問題が発生する可能性があります。
o A midpoint LSR that expands loose next hop(s) may have to accumulate the received path re-evaluation request(s) for all S2L sub-LSPs (e.g., by using a wait timer) and interpret them as a reoptimization request for the whole P2MP-TE LSP tree. Otherwise, a midpoint LSR may prematurely send a "Preferable Path Exists" notification for one S2L sub-LSP or a subset of S2L sub-LSPs.
o 緩やかなネクストホップを拡張する中間ポイントLSRは、すべてのS2LサブLSPについて受信したパス再評価要求を（たとえば、待機タイマーを使用して）蓄積し、それらを全体の再最適化要求として解釈する必要がある場合があります。 P2MP-TE LSPツリー。そうでない場合、ミッドポイントLSRは、1つのS2LサブLSPまたはS2LサブLSPのサブセットについて、「優先パスの存在」通知を時期尚早に送信する可能性があります。
o Similarly, the ingress node may have to heuristically determine when to perform P2MP-TE LSP tree reoptimization and when to perform S2L sub-LSP reoptimization. For example, an implementation may choose to delay reoptimization long enough to allow all PathErrs to be received. Such timer-based procedures may produce undesired results.
o 同様に、入口ノードは、P2MP-TE LSPツリー再最適化をいつ実行するか、およびS2LサブLSP再最適化をいつ実行するかをヒューリスティックに決定する必要がある場合があります。たとえば、実装では、すべてのPathErrを受信できるように再最適化を十分に遅延させる場合があります。このようなタイマーベースの手順では、望ましくない結果が生じる可能性があります。
o The ingress node that receives (un)solicited PathErr(s) with the Notify error code for one or more individual S2L sub-LSPs may prematurely start reoptimizing the subset of S2L sub-LSPs. However, as mentioned in [RFC4875], Section 14.2, such a Sub-Group-based reoptimization procedure may result in data duplication that can be avoided if the entire P2MP-TE LSP tree is reoptimized using the MBB method with a different LSP-ID, especially if the ingress node eventually receives PathErrs with the Notify error code for all S2L sub-LSPs of the P2MP-TE LSP tree.
o 1つ以上の個別のS2LサブLSPの通知エラーコードを含む（未）要求PathErrを受信する入口ノードは、S2LサブLSPのサブセットの再最適化を時期尚早に開始する場合があります。ただし、[RFC4875]のセクション14.2で説明されているように、このようなサブグループベースの再最適化手順では、異なるLSP-IDを持つMBBメソッドを使用してP2MP-TE LSPツリー全体が再最適化される場合に回避できるデータの重複が生じる可能性があります。特に、入力ノードが最終的にP2MP-TE LSPツリーのすべてのS2LサブLSPのNotifyエラーコードを含むPathErrsを受信した場合。
In order to address the above-mentioned issues and to align the reoptimization of P2MP-TE LSPs with P2P LSPs [RFC4736], a mechanism is needed to trigger the reoptimization of the LSP tree by re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this requirement, this document defines RSVP-TE signaling extensions for the ingress node to trigger the re-evaluation of the P2MP LSP tree on every hop that has a next hop defined as a loose or abstract hop for one or more S2L sub-LSP paths, and a midpoint LSR to signal to the ingress node that a preferable LSP tree exists (compared to the current path) or that the whole P2MP-TE LSP must be reoptimized (because of maintenance required on the TE LSP path) (see Section 4.1).
上記の問題に対処し、P2MP-TE LSPの再最適化をP2P LSP [RFC4736]に合わせるには、すべてのS2LサブLSPを別のS2LサブLSPに再シグナリングして、LSPツリーの再最適化をトリガーするメカニズムが必要です。 LSP-ID。この要件を満たすために、このドキュメントでは、1つ以上のS2Lサブのルーズホップまたはアブストラクトホップとして定義されたネクストホップを持つすべてのホップでP2MP LSPツリーの再評価をトリガーするために、入力ノードのRSVP-TEシグナリング拡張を定義しますLSPパス、および望ましいLSPツリーが存在する（現在のパスと比較して）、またはP2MP-TE LSP全体を再最適化する必要がある（TE LSPパスで必要なメンテナンスのため）ことを入口ノードに通知するミッドポイントLSRセクション4.1）。
Applying the procedures discussed in [RFC4736] in conjunction with the Sub-Group-based reoptimization procedures ([RFC4875], Section 14.2), an ingress node MAY trigger path re-evaluation requests for a set of S2L sub-LSPs in a single Path message using an S2L sub-LSP descriptor list. Similarly, a midpoint LSR may send a PathErr with Notify error code 25 and sub-code 6 ("Preferable Path Exists") containing a list of S2L sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor list to notify the ingress node. This method can be used for reoptimizing a sub-group of S2L sub-LSPs within an LSP tree using the same LSP-ID. This method can alleviate the scaling issue associated with sending RSVP messages for individual S2L sub-LSPs. However, this procedure can lead to the following issues when used to reoptimize the LSP tree:
[RFC4736]で説明されている手順をサブグループベースの再最適化手順（[RFC4875]、セクション14.2）と組み合わせて適用すると、入力ノードは、単一パス内の一連のS2LサブLSPのパス再評価要求をトリガーできます（MAY） S2LサブLSP記述子リストを使用するメッセージ。同様に、ミッドポイントLSRは、S2LサブLSP記述子リストを使用してLSRを通過するS2LサブLSPのリストを含むNotifyエラーコード25とサブコード6（ "Preferable Path Exists"）を含むPathErrを送信し、イングレスに通知します。ノード。この方法は、同じLSP-IDを使用して、LSPツリー内のS2LサブLSPのサブグループを再最適化するために使用できます。この方法では、個々のS2LサブLSPのRSVPメッセージの送信に関連するスケーリングの問題を軽減できます。ただし、この手順を使用してLSPツリーを再最適化すると、次の問題が発生する可能性があります。
o A Path message that is intended to carry the path re-evaluation request as defined in [RFC4736] with a full list of S2L sub-LSPs in an S2L sub-LSP descriptor list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over the same next hop will be added in the descriptor list of the Path message propagated to downstream midpoint LSRs. Consequently, when a preferable path exists at such midpoint LSRs, the PathErr with the Notify error code can only include the subset of S2L sub-LSPs traversing the LSR. In this case, at the ingress node there is no way to distinguish which mode of reoptimization to invoke, i.e., Sub-Group-based reoptimization using the same LSP-ID or tree-based reoptimization using a different LSP-ID.
o [RFC4736]で定義されているS2LサブLSP記述子リスト内のS2LサブLSPの完全なリストを含むパス再評価要求を伝達することを目的としたパスメッセージは、分岐LSRで分解され、そのサブセットのサブセットのみ同じネクストホップを介してルーティングされるS2LサブLSPは、ダウンストリームミッドポイントLSRに伝達されるパスメッセージの記述子リストに追加されます。その結果、そのような中点LSRに望ましいパスが存在する場合、Notifyエラーコードを含むPathErrには、LSRを通過するS2LサブLSPのサブセットのみを含めることができます。この場合、入口ノードでは、どの最適化モードを呼び出すかを区別する方法がありません。つまり、同じLSP-IDを使用するサブグループベースの再最適化、または異なるLSP-IDを使用するツリーベースの再最適化です。
o An LSR may semantically fragment a large RSVP message (when a combined message may not be large enough to fit all S2L sub-LSPs). In this case, the ingress node may receive multiple PathErrs with subsets of S2L sub-LSPs in each (due to either the combined Path message getting fragmented or the combined PathErr message getting fragmented) and would require additional logic to determine how to reoptimize the LSP tree (for example, waiting for some time to aggregate all possible PathErr messages before taking an action). When fragmented, RSVP messages may arrive out of order, and the receiver has no way of knowing the beginning and end of the S2L sub-LSP list.
o LSRは意味的に大きなRSVPメッセージを断片化する場合があります（結合されたメッセージがすべてのS2LサブLSPに適合するほど大きくない場合）。この場合、イングレスノードは、それぞれにS2LサブLSPのサブセットを持つ複数のPathErrを受信する可能性があり（組み合わされたPathメッセージがフラグメント化されるか、結合されたPathErrメッセージがフラグメント化されるため）、LSPを再最適化する方法を決定するための追加のロジックが必要になりますツリー（たとえば、アクションを実行する前に、可能なすべてのPathErrメッセージを集約するためにしばらく待機します）。断片化すると、RSVPメッセージが順不同で到着する場合があり、受信者はS2LサブLSPリストの開始と終了を知る方法がありません。
In order to address the above-mentioned issues caused by semantic fragmentation of an RSVP message, this document defines a new fragment identifier object for the S2L sub-LSP descriptor list when combining a large number of S2L sub-LSPs in an RSVP message (see Section 4.2).
RSVPメッセージのセマンティックフラグメンテーションによって引き起こされる上記の問題に対処するために、このドキュメントでは、RSVPメッセージで多数のS2LサブLSPを組み合わせるときにS2LサブLSP記述子リストの新しいフラグメント識別子オブジェクトを定義します（セクション4.2）。
To evaluate a P2MP-TE LSP tree on midpoint LSRs that expand loose next hop(s), an ingress node MAY send a Path message with the "P2MP-TE Tree Re-evaluation Request" flag set (bit number 14 in the Attribute Flags TLV) as defined in this document. The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP tree transiting a midpoint LSR to trigger the re-evaluation request. The ingress node MAY send a re-evaluation request to each border LSR on the path of the LSP tree.
緩やかなネクストホップを拡張するミッドポイントLSRでP2MP-TE LSPツリーを評価するには、入力ノードが「P2MP-TEツリー再評価要求」フラグセット（属性フラグのビット番号14）を含むパスメッセージを送信してもよい（MAY） TLV）このドキュメントで定義されています。入力ノードは、中間点LSRを通過するP2MP-TE LSPツリーのS2LサブLSPの1つを選択して、再評価要求をトリガーします。入力ノードは、LSPツリーのパス上の各境界LSRに再評価要求を送信してもよい（MAY）。
A midpoint LSR that expands loose next hop(s) for one or more S2L sub-LSP paths does the following upon receiving a Path message with the "P2MP-TE Tree Re-evaluation Request" flag set:
「P2MP-TE Tree Re-evaluation Request」フラグが設定されたPathメッセージを受信すると、1つ以上のS2LサブLSPパスのルーズネクストホップを拡張するミッドポイントLSRは次のことを行います。
o The midpoint LSR MUST check for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSPs that are expanded paths of the loose next hops of the P2MP-TE LSP.
o ミッドポイントLSRは、P2MP-TE LSPのルーズネクストホップの拡張パスであるすべてのS2LサブLSPを再評価することにより、適切なP2MP-TE LSPツリーをチェックする必要があります。
o If a preferable P2MP-TE LSP tree is found, the midpoint LSR MUST send to the ingress node an RSVP PathErr with Notify error code 25 [RFC3209] and sub-code 13 ("Preferable P2MP-TE Tree Exists)" as defined in this document. The midpoint LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re-evaluation Request" flag in the subsequent RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP.
o 望ましいP2MP-TE LSPツリーが見つかった場合、ミッドポイントLSRは、これに定義されているように、Notifyエラーコード25 [RFC3209]およびサブコード13（ "Preferable P2MP-TE Tree Exists）"を持つRSVP PathErrを入口ノードに送信する必要があります（MUST）。資料。次に、ミッドポイントLSRは、再評価されたP2MP-TE LSPのためにダウンストリームに送信された後続のRSVPパスメッセージで「P2MP-TEツリー再評価要求」フラグを伝播しないでください。
o If no preferable tree for P2MP-TE LSPs can be found, the midpoint LSR that expands loose next hop(s) for one or more S2L sub-LSP paths MUST propagate the request downstream by setting the "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES object of the RSVP Path message.
o P2MP-TE LSPの適切なツリーが見つからない場合、1つ以上のS2LサブLSPパスのルーズネクストホップを拡張するミッドポイントLSRは、「P2MP-TEツリー再評価リクエストを設定して、リクエストをダウンストリームに伝播する必要があります。 RSVPパスメッセージのLSP_ATTRIBUTESオブジェクトのフラグ。
A midpoint LSR MAY send an unsolicited PathErr with the Notify error code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress node to notify the ingress node of a preferred P2MP-TE LSP tree when it determines that it exists. In this case, the midpoint LSR that expands loose next hop(s) for one or more S2L sub-LSP paths selects one of the S2L sub-LSPs of the P2MP-TE LSP tree to send this PathErr message to the ingress node. The midpoint LSR SHOULD consider how frequently it chooses to send such a PathErr, considering that both (1) a PathErr may be lost during its transit to the ingress node and (2) the ingress node may choose not to reoptimize the LSP when such a PathErr is received.
ミッドポイントLSRは、Notifyエラーコードと「Preferable P2MP-TE Tree Exists」サブコードを含む未承諾PathErrを入力ノードに送信して、存在すると判断したときに優先P2MP-TE LSPツリーを入力ノードに通知する場合があります。この場合、1つ以上のS2LサブLSPパスのルーズネクストホップを拡張するミッドポイントLSRは、P2MP-TE LSPツリーのS2LサブLSPの1つを選択して、このPathErrメッセージを入力ノードに送信します。中間点LSRは、（1）PathErrが入口ノードへの転送中に失われる可能性があること、および（2）そのような場合に入口ノードがLSPを再最適化しないことを選択できることを考慮して、そのようなPathErrを送信することを選択する頻度を考慮する必要があります（SHOULD）。 PathErrを受信しました。
The sending of an RSVP PathErr with the Notify error code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress node notifies the ingress node of the existence of a preferable P2MP-TE LSP tree, and upon receiving this PathErr, the ingress node SHOULD trigger the reoptimization of the LSP, using the MBB method with a different LSP-ID.
Notifyエラーコードと「Preferable P2MP-TE Tree Exists」サブコードを含むRSVP PathErrを入力ノードに送信すると、入力ノードに優先P2MP-TE LSPツリーの存在が通知され、このPathErrを受信すると、入力ノードは、異なるLSP-IDでMBBメソッドを使用して、LSPの再最適化をトリガーする必要があります（SHOULD）。
It might be preferable, as per [RFC4875], to reoptimize the entire P2MP-TE LSP by re-signaling all of its S2L sub-LSPs (Section 14.1 ("Make-before-Break") in [RFC4875]) or to reoptimize an individual S2L sub-LSP or a group of S2L sub-LSPs, i.e., an individual destination or a group of destinations (Section 14.2 ("Sub-Group-Based Re-Optimization") in [RFC4875]), both using the same LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by using the procedures defined in [RFC4736] to reoptimize one or more S2L sub-LSPs of the P2MP-TE LSP.
[RFC4875]のように、すべてのS2LサブLSP（[RFC4875]のセクション14.1（「Make-before-Break」））を再シグナリングするか、再最適化することにより、P2MP-TE LSP全体を再最適化することが望ましい場合があります。個々のS2LサブLSPまたはS2LサブLSPのグループ、つまり、個々の宛先または宛先のグループ（[RFC4875]のセクション14.2（「サブグループベースの再最適化」））。 LSP-ID。ルーズにルーティングされたS2LサブLSPの場合、これは[RFC4736]で定義されている手順を使用して、P2MP-TE LSPの1つ以上のS2LサブLSPを再最適化することで実現できます。
An ingress node may trigger path re-evaluation requests using the procedures defined in [RFC4736] for a set of S2L sub-LSPs by combining multiple Path messages using an S2L sub-LSP descriptor list [RFC4875]. An S2L sub-LSP descriptor list is created using a series of S2L_SUB_LSP objects as defined in [RFC4875]. Similarly, a midpoint LSR may send a PathErr with Notify error code 25 and sub-code 6 ("Preferable Path Exists") containing a list of S2L sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor list to notify the ingress node of preferable paths available.
入力ノードは、S2LサブLSP記述子リスト[RFC4875]を使用して複数のパスメッセージを組み合わせることにより、[RFC4736]で定義された手順を使用して、S2LサブLSPのセットに対してパス再評価要求をトリガーできます。 S2LサブLSP記述子リストは、[RFC4875]で定義されている一連のS2L_SUB_LSPオブジェクトを使用して作成されます。同様に、ミッドポイントLSRは、S2LサブLSP記述子リストを使用してLSRを通過するS2LサブLSPのリストを含むNotifyエラーコード25とサブコード6（ "Preferable Path Exists"）を含むPathErrを送信し、イングレスに通知します。利用可能な優先パスのノード。
The S2L_SUB_LSP_FRAG object defined in this document is optional, with the following exceptions:
このドキュメントで定義されているS2L_SUB_LSP_FRAGオブジェクトはオプションですが、次の例外があります。
o As per [RFC4875], Section 5.2.3 ("Transit Fragmentation of Path State Information"), when a Path message is not large enough to fit all S2L sub-LSPs in the descriptor list, an LSR may semantically fragment the message. In this case, the LSR MUST add the S2L_SUB_LSP_FRAG object defined in this document for each fragment in the S2L sub-LSP descriptor to be able to rebuild the list from the received fragments that may arrive out of order.
o [RFC4875]のセクション5.2.3（「パス状態情報のトランジットフラグメンテーション」）に従い、Pathメッセージが記述子リスト内のすべてのS2LサブLSPに収まるほど大きくない場合、LSRはメッセージを意味的にフラグメント化することがあります。この場合、LSRは、S2LサブLSP記述子のフラグメントごとに、このドキュメントで定義されているS2L_SUB_LSP_FRAGオブジェクトを追加して、順不同で到着する可能性がある受信フラグメントからリストを再構築できるようにする必要があります。
o In any other situation where an RSVP message needs to be fragmented, an LSR MUST add the S2L_SUB_LSP_FRAG object for each fragment in the S2L sub-LSP descriptor.
o RSVPメッセージをフラグメント化する必要がある他の状況では、LSRは各フラグメントのS2L_SUB_LSP_FRAGオブジェクトをS2LサブLSP記述子に追加する必要があります。
A midpoint LSR SHOULD wait to accumulate all S2L sub-LSPs before attempting to re-evaluate a preferable path when a Path message for "Path Re-evaluation Request" is received with the S2L_SUB_LSP_FRAG object. If a midpoint LSR does not receive all fragments of the Path message (for example, when fragments are lost) within a configurable time interval, it SHOULD trigger the re-evaluation of all S2L sub-LSPs of the P2MP-TE LSP transiting on the node. A midpoint LSR MUST receive at least one fragment of the Path message to trigger this behavior.
中間点のLSRは、S2L_SUB_LSP_FRAGオブジェクトで「Path Re-evaluation Request」のPathメッセージを受信したときに、優先パスの再評価を試みる前に、すべてのS2LサブLSPが蓄積されるのを待つ必要があります。ミッドポイントLSRがパスメッセージのすべてのフラグメントを受信しない場合（フラグメントが失われた場合など）は、構成可能な時間間隔内に、その上を通過するP2MP-TE LSPのすべてのS2LサブLSPの再評価をトリガーする必要があります（SHOULD）。ノード。ミッドポイントLSRは、この動作をトリガーするために、パスメッセージの少なくとも1つのフラグメントを受信する必要があります。
An ingress node SHOULD wait to accumulate all S2L sub-LSPs before attempting to trigger reoptimization when a PathErr with the Notify error code and the "Preferable Path Exists" sub-code is received with an S2L_SUB_LSP_FRAG object. If an ingress node does not receive all fragments of the PathErr message (for example, when fragments are lost) within a configurable time interval, it SHOULD trigger the reoptimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on the midpoint node that had sent the PathErr message. An ingress node MUST receive at least one fragment of the PathErr message to trigger this behavior.
Ingressノードは、S2L_SUB_LSP_FRAGオブジェクトでNotifyエラーコードと「Preferable Path Exists」サブコードを持つPathErrが受信されたときに、再最適化のトリガーを試みる前に、すべてのS2LサブLSPの蓄積を待つ必要があります。入力ノードが構成可能な時間間隔内にPathErrメッセージのすべてのフラグメントを受信しない場合（たとえば、フラグメントが失われた場合）、ミッドポイントノードを通過するP2MP-TE LSPのすべてのS2LサブLSPの再最適化をトリガーする必要があります（SHOULD）。 PathErrメッセージを送信した。入力ノードは、この動作をトリガーするために、PathErrメッセージの少なくとも1つのフラグメントを受信する必要があります。
The S2L_SUB_LSP_FRAG object defined in this document has a wider applicability in addition to the P2MP-TE LSP reoptimization. It can also be used (in Path and Resv messages) to set up a new P2MP-TE LSP and to send other PathErr messages as well as Path Tear and Resv Tear messages for a set of S2L sub-LSPs. This is outside the scope of this document.
このドキュメントで定義されているS2L_SUB_LSP_FRAGオブジェクトは、P2MP-TE LSP再最適化に加えて、より広い適用範囲を持っています。また、（PathおよびResvメッセージで）新しいP2MP-TE LSPをセットアップし、他のPathErrメッセージ、および一連のS2LサブLSPのPath TearおよびResv Tearメッセージを送信するためにも使用できます。これはこのドキュメントの範囲外です。
In order to trigger a tree re-evaluation request, a new flag in the Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420] is defined by this document:
ツリーの再評価要求をトリガーするために、LSP_ATTRIBUTESオブジェクト[RFC5420]の属性フラグTLVの新しいフラグがこのドキュメントで定義されています。
Bit Number 14: "P2MP-TE Tree Re-evaluation Request" flag
ビット番号14：「P2MP-TE Tree Re-evaluation Request」フラグ
The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node using the message format defined in [RFC6510].
「P2MP-TE Tree Re-evaluation Request」フラグは、P2MP-TE S2LサブLSPのPathメッセージで意味があり、[RFC6510]で定義されているメッセージ形式を使用して入口ノードによって挿入されます。
In order to indicate to an ingress node that a preferable P2MP-TE LSP tree exists, the following new sub-code for PathErr messages with Notify error code 25 [RFC3209] is defined by this document:
このドキュメントでは、望ましいP2MP-TE LSPツリーが存在することを入口ノードに示すために、Notifyエラーコード25 [RFC3209]のPathErrメッセージ用の次の新しいサブコードが定義されています。
Sub-code 13: "Preferable P2MP-TE Tree Exists" sub-code
サブコード13：「望ましいP2MP-TEツリーが存在します」サブコード
When a preferable path for a P2MP-TE LSP tree exists, the midpoint LSR sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" sub-code with a PathErr message with Notify error code 25 to the ingress node of the P2MP-TE LSP.
P2MP-TE LSPツリーの優先パスが存在する場合、ミッドポイントLSRは、P2MP-TEの入力ノードに、通知エラーコード25のPathErrメッセージとともに送信請求または非送信請求の「優先P2MP-TEツリーの存在」サブコードを送信しますLSP。
The S2L_SUB_LSP object [RFC4875] identifies a particular S2L sub-LSP belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is created using a series of S2L_SUB_LSP objects as defined in [RFC4875]. The RSVP message may need to be semantically fragmented [RFC4875] due to a large number of S2L sub-LSPs added in the descriptor list, and such fragments may be received out of order. To be able to rebuild the fragmented S2L sub-LSP descriptor list correctly, the following object is defined to identify the fragments:
S2L_SUB_LSPオブジェクト[RFC4875]は、P2MP-TE LSPに属する特定のS2LサブLSPを識別します。 S2LサブLSP記述子リストは、[RFC4875]で定義されている一連のS2L_SUB_LSPオブジェクトを使用して作成されます。記述子リストに追加された多数のS2LサブLSPが原因で、RSVPメッセージを意味的に断片化する必要がある場合があり[RFC4875]、そのような断片は順不同で受信される場合があります。フラグメント化されたS2LサブLSP記述子リストを正しく再構築できるように、フラグメントを識別するために次のオブジェクトが定義されています。
S2L_SUB_LSP_FRAG: Class Number 204
S2L_SUB_LSP_FRAG：クラス番号204
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (8 bytes) | Class Num 204 | C-Type 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Fragments Tot.| Fragment Num. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fragment ID: 16-bit integer in the range of 1 to 65535.
This value is incremented for each new RSVP message that needs to be semantically fragmented. The fragment ID is reset to 1 when it reaches the maximum value of 65535. The scope of the fragment ID is limited to the RSVP message type (e.g., Path) carrying the fragment. In other words, fragment IDs do not have any correlation between different RSVP message types (e.g., Path and PathErr). The receiver does not check to ensure that the consecutive new RSVP messages (e.g., Path messages) are received with fragment IDs incremented by 1.
この値は、意味的に断片化する必要がある新しいRSVPメッセージごとに増分されます。フラグメントIDは、最大値の65535に達すると1にリセットされます。フラグメントIDのスコープは、フラグメントを運ぶRSVPメッセージタイプ（パスなど）に制限されます。つまり、フラグメントIDは、異なるRSVPメッセージタイプ（PathやPathErrなど）の間に相関関係はありません。受信者は、フラグメントIDが1ずつ増分された連続した新しいRSVPメッセージ（Pathメッセージなど）が受信されたことを確認しません。
Fragments Total: 8-bit integer in the range of 1 to 255.
フラグメントの合計：1から255の範囲の8ビット整数。
This value indicates the number of fragments sent for the given RSVP message. This value MUST be the same in all fragmented RSVP messages with a common fragment ID.
この値は、特定のRSVPメッセージに対して送信されたフラグメントの数を示します。この値は、共通のフラグメントIDを持つフラグメント化されたすべてのRSVPメッセージで同じである必要があります。
Fragment Number: 8-bit integer in the range of 1 to 255.
フラグメント番号：1から255の範囲の8ビット整数。
This value indicates the position of this fragment in the given RSVP message.
この値は、指定されたRSVPメッセージ内のこのフラグメントの位置を示します。
The format of an S2L sub-LSP descriptor message is as follows:
S2LサブLSP記述子メッセージの形式は次のとおりです。
<S2L sub-LSP descriptor> ::=
[ <S2L_SUB_LSP_FRAG> ]
<S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
The S2L_SUB_LSP_FRAG object is added before adding the S2L_SUB_LSP object in the semantically fragmented RSVP message.
S2L_SUB_LSP_FRAGオブジェクトは、意味的に断片化されたRSVPメッセージにS2L_SUB_LSPオブジェクトを追加する前に追加されます。
The LSP_ATTRIBUTES object has been defined in [RFC5420] and its message formats in [RFC6510] with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], nodes not supporting this extension will ignore the new flag defined for this object in this document and will forward it without modification.
LSP_ATTRIBUTESオブジェクトは[RFC5420]で定義されており、そのメッセージフォーマットは[RFC6510]でクラス番号が11bbbbbbの形式で定義されています。これにより、サポートされていないノードとの互換性が保証されます。 [RFC2205]に従い、この拡張をサポートしないノードは、このドキュメントでこのオブジェクトに対して定義された新しいフラグを無視し、変更せずに転送します。
The S2L_SUB_LSP_FRAG object has been defined with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], nodes not supporting this object will ignore the object and will forward it without modification.
S2L_SUB_LSP_FRAGオブジェクトは、11bbbbbb形式のクラス番号で定義されています。これにより、サポートされていないノードとの互換性が確保されます。 [RFC2205]に従い、このオブジェクトをサポートしないノードはオブジェクトを無視し、変更せずに転送します。
IANA has performed the actions described below.
IANAは以下のアクションを実行しました。
IANA maintains the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry (see <http://www.iana.org/assignments/rsvp-te-parameters>). Per Section 5.1 of this document, IANA has registered a new flag in the "Attribute Flags" registry. This new flag is defined for the Attribute Flags TLV in the LSP_ATTRIBUTES object [RFC5420].
IANAは、「Resource Reservation Protocol-Traffic Engineering（RSVP-TE）Parameters」レジストリを維持しています（<http://www.iana.org/assignments/rsvp-te-parameters>を参照）。このドキュメントのセクション5.1に従って、IANAは「属性フラグ」レジストリに新しいフラグを登録しました。この新しいフラグは、LSP_ATTRIBUTESオブジェクト[RFC5420]の属性フラグTLVに対して定義されています。
+-----+---------------+----------+----------+-----+-----+-----------+
| Bit | Name | Attribute| Attribute| RRO | ERO | Reference |
| No | | Flags | Flags | | | |
| | | Path | Resv | | | |
+-----+---------------+----------+----------+-----+-----+-----------+
| | P2MP-TE Tree | Yes | No | No | No | This |
| 14 | Re-evaluation | | | | | document |
| | Request | | | | | |
+-----+---------------+----------+----------+-----+-----+-----------+
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). Per Section 5.2 of this document, IANA has registered a new error code in the "Sub-Codes - 25 Notify Error" sub-registry of the "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
IANAは「リソース予約プロトコル（RSVP）パラメータ」レジストリを維持します（<http://www.iana.org/assignments/rsvp-parameters>を参照）。このドキュメントのセクション5.2に従って、IANAは「エラーコードとグローバルに定義されたエラー値サブコード」レジストリの「サブコード-25通知エラー」サブレジストリに新しいエラーコードを登録しました。
As defined in [RFC3209], error code 25 in the ERROR_SPEC object corresponds to a PathErr with the Notify error. This document adds a new "Preferable P2MP-TE Tree Exists" sub-code for this PathErr as follows:
[RFC3209]で定義されているように、ERROR_SPECオブジェクトのエラーコード25は、NotifyエラーのあるPathErrに対応しています。このドキュメントでは、次のように、このPathErrの新しい「Preferable P2MP-TE Tree Exists」サブコードを追加します。
+----------+--------------------+---------+---------+-----------+
| Value | Description | PathErr | PathErr | Reference |
| | | Code | Name | |
+----------+--------------------+---------+---------+-----------+
| 13 | Preferable P2MP-TE | 25 | Notify | This |
| | Tree Exists | | Error | document |
+----------+--------------------+---------+---------+-----------+
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). Per Section 5.3 of this document, IANA has registered a new class number in the "Class Names, Class Numbers, and Class Types" registry.
IANAは「リソース予約プロトコル（RSVP）パラメータ」レジストリを維持します（<http://www.iana.org/assignments/rsvp-parameters>を参照）。このドキュメントのセクション5.3に従って、IANAは「クラス名、クラス番号、およびクラスタイプ」レジストリに新しいクラス番号を登録しました。
+-----------------+---------------------------+-----------------+
| Class Number | Class Name | Reference |
+-----------------+---------------------------+-----------------+
| 204 | S2L_SUB_LSP_FRAG | This document |
+-----------------+---------------------------+-----------------+
IANA has also created the "Class Types or C-Types - 204 S2L_SUB_LSP_FRAG" registry and populated it as follows:
IANAは「クラスタイプまたはCタイプ-204 S2L_SUB_LSP_FRAG」レジストリも作成し、次のように設定しました。
+-----------------+---------------------------+-----------------+
| Value | Description | Reference |
+-----------------+---------------------------+-----------------+
| 1 | S2L_SUB_LSP_FRAG | This document |
+-----------------+---------------------------+-----------------+
This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP tree downstream of a node and to allow a midpoint LSR to notify the ingress node of the existence of a preferable tree by sending a PathErr message. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple domains, it may be desirable for a midpoint LSR to modify the RSVP PathErr message to preserve confidentiality across domains.
このドキュメントでは、RSVP-TEシグナリング拡張を定義して、P2MP-TE LSPの入力ノードがノードのダウンストリームLSPツリーの再評価を要求できるようにし、中間点LSRが望ましいノードの存在を入力ノードに通知できるようにしますPathErrメッセージを送信してツリー。 [RFC4736]のように、複数のドメインにまたがるP2MP-TE LSP S2LサブLSPの場合、ミッドポイントLSRがRSVP PathErrメッセージを変更してドメイン間の機密性を維持することが望ましい場合があります。
This document also defines a fragment identifier for the S2L sub-LSP descriptor when combining a large number of S2L sub-LSPs in an RSVP message and the message needs to be semantically fragmented. The introduction of the fragment identifier, by itself, introduces no additional information to signaling. For a general discussion on security issues related to MPLS and GMPLS, see the MPLS/GMPLS security framework [RFC5920].
このドキュメントでは、RSVPメッセージで多数のS2LサブLSPを組み合わせる場合のS2LサブLSP記述子のフラグメント識別子も定義しており、メッセージを意味的に断片化する必要があります。フラグメント識別子の導入自体は、シグナリングに追加情報を導入しません。 MPLSおよびGMPLSに関連するセキュリティ問題の一般的な説明については、MPLS / GMPLSセキュリティフレームワーク[RFC5920]を参照してください。
[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>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<http://www.rfc-editor.org/info/rfc2205>。
[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>。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, November 2006, <http://www.rfc-editor.org/info/rfc4736>.
[RFC4736] Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "Reoptimization of Multiprotocol Label Switching（MPLS）Traffic Engineering（TE）Loosely Routed Label Switched Path（LSP）"、RFC 4736、DOI 10.17487 / RFC4736、2006年11月、<http://www.rfc-editor.org/info/rfc4736>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<http://www.rfc-editor.org/info/rfc4875>。
[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>。
[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>。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<http://www.rfc-editor.org/info/rfc5440>。
[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>。
[RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects", RFC 6510, DOI 10.17487/RFC6510, February 2012, <http://www.rfc-editor.org/info/rfc6510>.
[RFC6510] Berger、L。およびG. Swallow、「ラベルスイッチドパス（LSP）属性オブジェクトのリソース予約プロトコル（RSVP）メッセージ形式」、RFC 6510、DOI 10.17487 / RFC6510、2012年2月、<http：// www。 rfc-editor.org/info/rfc6510>。
Acknowledgments
謝辞
The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram, and Joel M. Halpern for reviewing this document and providing many useful comments and suggestions. The authors would also like to thank Ling Zeng with Cisco Systems for implementing the mechanisms defined in this document. A special thanks to Adrian Farrel for his thorough review of this document.
このドキュメントをレビューし、多くの有用なコメントや提案を提供してくれたLoa Andersson、Sriganesh Kini、Curtis Villamizar、Dimitri Papadimitriou、Nobo Akiya、Vishnu Pavan Beeram、およびJoel M. Halpernに感謝します。著者はまたこの文書で定義されたメカニズムを実装するためにシスコシステムズでLing Zengに感謝します。このドキュメントを徹底的にレビューしてくれたAdrian Farrelに特に感謝します。
Authors' Addresses
著者のアドレス
Tarek Saad (editor) Cisco Systems, Inc.
Tarek Saad（編集者）Cisco Systems、ed。
Email: tsaad@cisco.com
Rakesh Gandhi (editor) Cisco Systems, Inc.
Rakesh Gandhi（編集者）Cisco Systems、Inc.
Email: rgandhi@cisco.com
Zafar Ali Cisco Systems, Inc.
Zafar Ali Cisco Systems、Inc.
Email: zali@cisco.com
Robert H. Venator Defense Information Systems Agency
Robert H. Venator Defense Information Systems Agency
Email: robert.h.venator.civ@mail.mil
Yuji Kamite NTT Communications Corporation
UG Commit Nutt Communications Corporation
Email: y.kamite@ntt.com