[要約] RFC 8390は、RSVP-TEパスの多様性を実現するためのExclude Routeの使用に関するものです。このRFCの目的は、ネットワークのパス選択において、特定の経路を除外するための機能を提供することです。
Internet Engineering Task Force (IETF) Z. Ali, Ed.
Request for Comments: 8390 Cisco Systems
Updates: 4874 G. Swallow, Ed.
Category: Standards Track SETC
ISSN: 2070-1721 F. Zhang, Ed.
Huawei
D. Beller, Ed.
Nokia
July 2018
RSVP-TE Path Diversity Using Exclude Route
除外ルートを使用したRSVP-TEパスの多様性
Abstract
概要
RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS).
RSVP-TEは、Label Switched Path（LSP）セットアップ中の除外情報の通信をサポートします。典型的なLSPダイバーシティの使用例は保護用であり、単一障害点を回避するために2つのLSPがネットワーク上の異なるパスをたどる必要があるため、サービスの可用性が大幅に向上します。このドキュメントでは、パスの抽象識別子を使用してフルパスが必ずしもわかっているわけではないネットワークシナリオで使用できるアプローチを指定します。 3つのタイプの抽象識別子が指定されています。クライアントベース、パス計算エレメント（PCE）ベース、およびネットワークベースです。このドキュメントでは、RSVP eXclude Route Object（XRO）とExplicit Exclusion Route Subobject（EXRS）の2つの新しい多様性サブオブジェクトを指定します。
For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.
保護の使用例の場合、LSPは通常低速で作成され、長期間存在するため、現在既知の（既知の識別子を持つ）与えられた（参照）パスが存在し続け、新しい多様なパスを作成するときに参照として使用されます。新しいパスが確立される前に、既存の（参照）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 https://www.rfc-editor.org/info/rfc8390.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8390で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 6
1.3. Client-Initiated Identifier . . . . . . . . . . . . . . . 7
1.4. PCE-Allocated Identifier . . . . . . . . . . . . . . . . 7
1.5. Network-Assigned Identifier . . . . . . . . . . . . . . . 9
2. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . 10
2.1. Diversity XRO Subobject . . . . . . . . . . . . . . . . . 10
2.2. Diversity EXRS Subobject . . . . . . . . . . . . . . . . 16
2.3. Processing Rules for the Diversity XRO and EXRS
Subobjects . . . . . . . . . . . . . . . . . . . . . . . 16
3. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. New XRO Subobject Types . . . . . . . . . . . . . . . . . 21
4.2. New EXRS Subobject Types . . . . . . . . . . . . . . . . 21
4.3. New RSVP Error Sub-codes . . . . . . . . . . . . . . . . 22
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Normative References . . . . . . . . . . . . . . . . . . 22
5.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Path diversity for multiple connections is a well-known operational requirement. Diversity constraints ensure that Label Switched Paths (LSPs) can be established without sharing network resources, thus greatly reducing the probability of simultaneous connection failures.
複数の接続のパスダイバーシティは、よく知られた運用上の要件です。多様性の制約により、ネットワークリソースを共有せずにラベルスイッチドパス（LSP）を確立できるため、同時接続障害の確率が大幅に減少します。
The source node can compute diverse paths for LSPs when it has full knowledge of the network topology and is permitted to signal an Explicit Route Object (ERO). However, there are scenarios where different nodes perform path computations, and therefore there is a need for relevant diversity constraints to be signaled to those nodes. These include (but are not limited to):
ソースノードは、ネットワークトポロジに関する完全な知識を持ち、明示的ルートオブジェクト（ERO）に信号を送ることが許可されている場合、LSPの多様なパスを計算できます。ただし、さまざまなノードがパス計算を実行するシナリオがあるため、関連するダイバーシティ制約をそれらのノードに通知する必要があります。これらには以下が含まれます（ただし、これらに限定されません）。
o LSPs with loose hops in the Explicit Route Object, e.g., inter-domain LSPs; and
o 明示的なルートオブジェクトにルーズホップのあるLSP（ドメイン間LSPなど）。そして
o Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI), where the core node may perform path computation [RFC4208].
o 一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）。コアノードはパス計算を実行できます[RFC4208]。
[RFC4874] introduced a means of specifying nodes and resources to be excluded from a route using the eXclude Route Object (XRO) and Explicit Exclusion Route Subobject (EXRS). It facilitates the calculation of diverse paths for LSPs based on known properties of those paths including addresses of links and nodes traversed and Shared Risk Link Groups (SRLGs) of traversed links. Employing these mechanisms requires that the source node that initiates signaling knows the relevant properties of the path(s) from which diversity is desired. However, there are circumstances under which this may not be possible or desirable, including (but not limited to):
[RFC4874]は、除外ルートオブジェクト（XRO）と明示的除外ルートサブオブジェクト（EXRS）を使用して、ルートから除外するノードとリソースを指定する手段を導入しました。リンクのアドレスとトラバースされたノードおよびトラバースされたリンクの共有リスクリンクグループ（SRLG）を含むこれらのパスの既知のプロパティに基づいて、LSPの多様なパスの計算を容易にします。これらのメカニズムを採用するには、シグナリングを開始する送信元ノードが、ダイバーシティが必要なパスの関連プロパティを知っている必要があります。ただし、次のような（ただしこれらに限定されない）これが不可能または望ましくない場合があります。
o Exclusion of a path that does not originate, terminate, or traverse the source node of the diverse LSP, in which case the addresses of links and SRLGs of the path from which diversity is required are unknown to the source node.
o ダイバーシティLSPのソースノードを開始、終了、または通過しないパスの除外。この場合、ダイバーシティが必要なパスのリンクおよびSRLGのアドレスは、ソースノードには不明です。
o Exclusion of a path that is known to the source node of the diverse LSP for which the node has incomplete or no path information, e.g., due to operator policy. In this case, the source node is aware of the existence of the reference path, but the information required to construct an XRO object to guarantee diversity from the reference path is not fully known. Inter-domain and GMPLS overlay networks can impose such restrictions.
o オペレーターのポリシーなどにより、ノードにパス情報が不完全であるかパス情報がない多様なLSPのソースノードに既知のパスを除外します。この場合、ソースノードは参照パスの存在を認識していますが、参照パスからの多様性を保証するためにXROオブジェクトを構築するために必要な情報は完全にはわかっていません。ドメイン間およびGMPLSオーバーレイネットワークは、このような制限を課すことができます。
This is illustrated in Figure 1, where the overlay reference model from [RFC4208] is shown.
これを図1に示します。[RFC4208]のオーバーレイ参照モデルを示しています。
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | UNI | | | | | | | | UNI | | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | +--+--+ | | | | | | +---+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
+---------+ | | | | | | | +---------+
| | | | | | |
+---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ |
+---------+ +----------------------------------+ +---------+
Overlay Core Network Overlay
Network Network
Legend: EN - Edge Node
CN - Core Node
Figure 1: Overlay Reference Model [RFC4208]
図1：オーバーレイ参照モデル[RFC4208]
Figure 1 depicts two types of UNI connectivity: single-homed and dual-homed ENs (which also applies to higher-order multihomed connectivity). Single-homed EN devices are connected to a single CN device via a single UNI link. This single UNI link may constitute a single point of failure. UNI connection between EN1 and CN1 is an example of singled-homed UNI connectivity.
図1に、2つのタイプのUNI接続を示します。シングルホームENとデュアルホームENです（これは、高次マルチホーム接続にも適用されます）。シングルホームのENデバイスは、単一のUNIリンクを介して単一のCNデバイスに接続されます。この単一のUNIリンクは、単一障害点を構成する場合があります。 EN1とCN1間のUNI接続は、シングルホームUNI接続の例です。
Such a single point of failure can be avoided when the EN device is connected to two different CN devices, as depicted for EN2 in Figure 1. For the dual-homing case, it is possible to establish two different UNI connections from the same source EN device to the same destination EN device. For example, two connections from EN2 to EN3 may use the two UNI links EN2-CN1 and EN2-CN4. To avoid single points of failure within the provider network, it is necessary to also ensure path (LSP) diversity within the core network.
図1のEN2に示すように、ENデバイスが2つの異なるCNデバイスに接続されている場合、このような単一障害点を回避できます。デュアルホーミングの場合、同じソースENから2つの異なるUNI接続を確立できます。デバイスを同じ宛先ENデバイスに接続します。たとえば、EN2からEN3への2つの接続では、2つのUNIリンクEN2-CN1およびEN2-CN4を使用できます。プロバイダーネットワーク内の単一障害点を回避するには、コアネットワーク内のパス（LSP）の多様性も保証する必要があります。
In a network providing a set of UNI interfaces between ENs and CNs such as that shown in Figure 1, the CNs typically perform path computation. Information sharing across the UNI boundary is restricted based on the policy rules imposed by the core network. Typically, the core network topology information as well as LSP path information is not exposed to the ENs. In the network shown in Figure 1, consider a use case where an LSP from EN2 to EN4 needs to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 may not know SRLG attributes of the EN1-EN3 LSP and hence cannot construct an XRO to exclude these SRLGs. In this example, EN2 cannot use the procedures described in [RFC4874]. Similarly, an LSP from EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to EN3 going via CN4. Again, in this case, exclusions based on [RFC4874] cannot be used.
図1に示すように、ENとCNの間にUNIインターフェイスのセットを提供するネットワークでは、CNは通常、パス計算を実行します。 UNI境界を越えた情報共有は、コアネットワークによって課されるポリシールールに基づいて制限されます。通常、コアネットワークトポロジ情報とLSPパス情報はENに公開されません。図1に示すネットワークで、EN2からEN4へのLSPがEN1からEN3へのLSPとは異なるSRLGである必要があるユースケースを考えます。この場合、EN2はEN1-EN3 LSPのSRLG属性を認識していない可能性があるため、これらのSRLGを除外するXROを構築できません。この例では、EN2は[RFC4874]で説明されている手順を使用できません。同様に、CN1を通過するEN2からEN3へのLSPは、CN4を経由するEN2からEN3へのLSPと異なる必要があります。この場合も、[RFC4874]に基づく除外は使用できません。
This document addresses these diversity requirements by introducing an approach of excluding the path taken by these particular LSP(s). Each reference LSP or route from which diversity is required is identified by an abstract "identifier". The type of identifier to use is highly dependent on the core network operator's networking deployment scenario; it could be client initiated (provided by the EN), provided by a PCE, or allocated by the (core) network. This document defines three different types of identifiers corresponding to these three cases: a client-initiated identifier, a PCE-allocated identifier, and an identifier allocated by the CN ingress node (UNI-N), i.e., a network-assigned identifier.
このドキュメントでは、これらの特定のLSPがたどるパスを除外するアプローチを導入することにより、これらの多様性要件に対処します。多様性が要求される各参照LSPまたはルートは、抽象的な「識別子」によって識別されます。使用する識別子の種類は、コアネットワークオペレーターのネットワーク展開シナリオに大きく依存します。クライアントによって開始（ENによって提供）、PCEによって提供、または（コア）ネットワークによって割り当てられます。このドキュメントでは、これらの3つのケースに対応する3種類の識別子を定義します。クライアントが開始した識別子、PCEが割り当てた識別子、CN入力ノード（UNI-N）によって割り当てられた識別子、つまりネットワーク割り当ての識別子です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Diverse LSP: A diverse Label Switched Path (LSP) is an LSP that has a path that does not have any link or SRLG in common with the path of a given LSP. Diverse LSPs are meaningful in the context of protection or restoration.
多様なLSP：多様なラベルスイッチドパス（LSP）は、特定のLSPのパスと共通のリンクまたはSRLGがないパスを持つLSPです。さまざまなLSPは、保護または復元のコンテキストで意味があります。
ERO: Explicit Route Object as defined in [RFC3209].
ERO：[RFC3209]で定義されている明示的なルートオブジェクト。
EXRS: Explicit Exclusion Route Subobject as defined in [RFC4874].
EXRS：[RFC4874]で定義されている明示的な除外ルートサブオブジェクト。
SRLG: Shared Risk Link Group as defined in [RFC4202].
SRLG：[RFC4202]で定義されている共有リスクリンクグループ。
Reference Path: The reference path is the path of an existing LSP to which the path of a diverse LSP shall be diverse.
参照パス：参照パスは、多様なLSPのパスが多様である既存のLSPのパスです。
XRO: eXclude Route Object as defined in [RFC4874].
XRO：[RFC4874]で定義されているルートオブジェクトを除外します。
The following fields MUST be used to represent the client-initiated identifier: IPv4/IPv6 tunnel sender address, IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended Tunnel ID. Based on local policy, the client MAY also include the LSP ID to identify a specific LSP within the tunnel. These fields are defined in Sections 4.6.1.1 and 4.6.2.1 of [RFC3209].
次のフィールドは、クライアント開始の識別子を表すために使用する必要があります：IPv4 / IPv6トンネル送信者アドレス、IPv4 / IPv6トンネルエンドポイントアドレス、トンネルID、および拡張トンネルID。ローカルポリシーに基づいて、クライアントはトンネル内の特定のLSPを識別するためにLSP IDを含めることもできます（MAY）。これらのフィールドは、[RFC3209]のセクション4.6.1.1および4.6.2.1で定義されています。
The usage of the client-initiated identifier is illustrated by Figure 1. Suppose an LSP from EN2 to EN4 needs to be diverse with respect to an LSP from EN1 to EN3.
クライアントが開始した識別子の使用法を図1に示します。EN2からEN4へのLSPは、EN1からEN3へのLSPに関して多様である必要があると仮定します。
The LSP identifier of the EN1-EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by the tuple
EN1-EN3 LSPのLSP識別子はLSP-IDENTIFIER1で、LSP-IDENTIFIER1はタプルによって定義されます
(tunnel-id = T1, LSP ID = L1, source address = EN1.RID (Route Identifier), destination address = EN3.RID, extended tunnel-id = EN1.RID).
（トンネルID = T1、LSP ID = L1、送信元アドレス= EN1.RID（ルート識別子）、宛先アドレス= EN3.RID、拡張トンネルID = EN1.RID）。
Similarly, the LSP identifier of the EN2-EN4 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER2 is defined by the tuple
同様に、EN2-EN4 LSPのLSP識別子はLSP-IDENTIFIER2で、LSP-IDENTIFIER2はタプルによって定義されます
(tunnel-id = T2, LSP ID = L2, source address = EN2.RID, destination address = EN4.RID, extended tunnel-id = EN2.RID).
（トンネルID = T2、LSP ID = L2、送信元アドレス= EN2.RID、宛先アドレス= EN4.RID、拡張トンネルID = EN2.RID）。
The EN1-EN3 LSP is signaled with an exclusion requirement from LSP-IDENTIFIER2, and the EN2-EN4 LSP is signaled with an exclusion requirement from LSP-IDENTIFIER1. In order to maintain diversity between these two connections within the core network, the core network SHOULD implement crankback signaling extensions as defined in [RFC4920]. Note that crankback signaling is known to lead to slower setup times and suboptimal paths under some circumstances as described by [RFC4920].
EN1-EN3 LSPはLSP-IDENTIFIER2からの除外要件で通知され、EN2-EN4 LSPはLSP-IDENTIFIER1からの除外要件で通知されます。コアネットワーク内のこれら2つの接続間の多様性を維持するために、コアネットワークは、[RFC4920]で定義されているクランクバックシグナリング拡張を実装する必要があります（SHOULD）。 [RFC4920]で説明されているように、一部の状況では、クランクバックシグナリングがセットアップ時間の遅延と最適でないパスにつながることが知られていることに注意してください。
In scenarios where a PCE is deployed and used to perform path computation, typically the ingress node of the core network (e.g., node CN1 in Figure 1) could consult a PCE to allocate identifiers, which are used to signal path diversity constraints. In other deployment scenarios, a PCE is deployed at a network node(s) or it is part of a Network Management System (NMS). In all these cases, the PCE is consulted and the Path Key, as defined in [RFC5520], can be used in RSVP signaling as the identifier to ensure diversity.
PCEが展開されてパス計算を実行するために使用されるシナリオでは、通常、コアネットワークの入力ノード（たとえば、図1のノードCN1）はPCEに問い合わせて、パスダイバーシティ制約を通知するために使用される識別子を割り当てます。他の展開シナリオでは、PCEはネットワークノードに展開されるか、ネットワーク管理システム（NMS）の一部です。これらすべてのケースで、PCEが参照され、[RFC5520]で定義されているパスキーをRSVPシグナリングで識別子として使用して、多様性を確保できます。
An example of specifying LSP diversity using a Path Key is shown in Figure 2, where a simple network with two domains is shown. It is desired to set up a pair of path-disjoint LSPs from the source in Domain 1 to the destination in Domain 2, but the domains keep strict confidentiality about all path and topology information.
パスキーを使用してLSPダイバーシティを指定する例を図2に示します。ここでは、2つのドメインを持つ単純なネットワークが示されています。ドメイン1のソースからドメイン2の宛先へのパスの互いに素なLSPのペアを設定することが望まれますが、ドメインはすべてのパスとトポロジー情報について厳格な機密性を保持します。
The first LSP is signaled by the source with ERO {A, B, loose Dst} and is set up with the path {Src, A, B, U, V, W, Dst}. However, when sending the Record Route Object (RRO) out of Domain 2, node U would normally strip the path and replace it with a loose hop to the destination. With this limited information, the source is unable to include enough detail in the ERO of the second LSP to avoid it taking, for example, the path {Src, C, D, X, V, W, Dst} for path-disjointness.
最初のLSPはソースによってERO {A、B、ルーズDst}で通知され、パス{Src、A、B、U、V、W、Dst}で設定されます。ただし、ドメイン2からレコードルートオブジェクト（RRO）を送信する場合、ノードUは通常、パスを取り除き、宛先へのルーズホップに置き換えます。この限られた情報では、ソースは2番目のLSPのEROに十分な詳細を含めることができず、たとえばパスの素性のためにパス{Src、C、D、X、V、W、Dst}をとることを回避できません。
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------
Figure 2: A Simple Multi-domain Network
図2：シンプルなマルチドメインネットワーク
In order to support LSP diversity, node U consults the PCE and replaces the path segment {U, V, W} in the RRO with a Path Key subobject. The PCE function assigns an "identifier" and puts it into the Path Key field of the Path Key subobject. The PCE ID in the message indicates that this replacement operation was performed by node U.
LSPダイバーシティをサポートするために、ノードUはPCEを参照し、RROのパスセグメント{U、V、W}をパスキーサブオブジェクトに置き換えます。 PCE関数は「識別子」を割り当て、それをパスキーサブオブジェクトのパスキーフィールドに入れます。メッセージ内のPCE IDは、この置換操作がノードUによって実行されたことを示しています。
With this additional information, the source node is able to signal the subsequent LSPs with the ERO set to {C, D, exclude Path Key (signaled in the EXRS RSVP subobject), loose Dst}. When the signaling message reaches node X, it can consult the PCE function associated with node U to expand the Path Key in order to calculate a path that is diverse with respect to the first LSP. Alternatively, the source node could use an ERO of {C, D, loose Dst} and include an XRO containing the Path Key.
この追加情報により、ソースノードはEROを{C、Dに設定して後続のLSPに信号を送信し、パスキーを除外（EXRS RSVPサブオブジェクトで信号を送信）、Dstを緩める}ことができます。シグナリングメッセージがノードXに到達すると、ノードUに関連付けられたPCE機能を参照してパスキーを展開し、最初のLSPに関して多様なパスを計算できます。または、ソースノードは{C、D、ルーズDst}のEROを使用し、パスキーを含むXROを含めることができます。
This mechanism can work with all the Path Key resolution mechanisms, as detailed in Section 3.1 of [RFC5553]. A PCE, co-located or not, may be used to resolve the Path Key, but the node (i.e., a Label Switching Router (LSR)) can also use the Path Key information to index a path segment previously supplied to it by the entity that originated the Path Key (for example, the LSR that inserted the Path Key in the RRO or a management system).
このメカニズムは、[RFC5553]のセクション3.1に詳述されているように、すべてのパスキー解決メカニズムで機能します。同じ場所にあるかどうかに関係なく、PCEを使用してパスキーを解決できますが、ノード（つまり、ラベルスイッチングルーター（LSR））はパスキー情報を使用して、以前にパスキーを生成したエンティティ（たとえば、パスキーをRROまたは管理システムに挿入したLSR）。
There are scenarios in which the network provides diversity-related information for a service that allows the client device to include this information in the signaling message. If the Shared Risk Link Group (SRLG) identifier information is both available and shareable (by policy) with the ENs, the procedure defined in [RFC8001] can be used to collect SRLG identifiers associated with an LSP (LSP1). When a second LSP (LSP2) needs to be diverse with respect to LSP1, the EN constructing the RSVP signaling message for setting up LSP2 can insert the SRLG identifiers associated with LSP1 as diversity constraints into the XRO using the procedure described in [RFC4874]. However, if the core network SRLG identifiers are either not available or not shareable with the ENs based on policies enforced by the core network, existing mechanisms cannot be used.
ネットワークがサービスにダイバーシティ関連情報を提供し、クライアントデバイスがこの情報をシグナリングメッセージに含めることを可能にするシナリオがあります。共有リスクリンクグループ（SRLG）識別子情報が利用可能であり、ENと（ポリシーによって）共有可能である場合、[RFC8001]で定義された手順を使用して、LSP（LSP1）に関連付けられたSRLG識別子を収集できます。 2番目のLSP（LSP2）がLSP1に関して多様である必要がある場合、LSP2をセットアップするためのRSVPシグナリングメッセージを構築するENは、[RFC4874]で説明されている手順を使用して、LSP1に関連付けられたSRLG識別子をダイバーシティ制約としてXROに挿入できます。ただし、コアネットワークによって実施されたポリシーに基づいて、コアネットワークのSRLG識別子が使用できないか、ENと共有できない場合、既存のメカニズムは使用できません。
In this document, a signaling mechanism is defined where information signaled to the CN via the UNI does not require shared knowledge of core network SRLG information. For this purpose, the concept of a Path Affinity Set (PAS) is defined for abstracting SRLG information. The motive behind the introduction of the PAS is to minimize the exchange of diversity information between the core network (CNs) and the client devices (ENs). The PAS contains an abstract SRLG identifier associated with a given path rather than a detailed SRLG list. The PAS is a single identifier that can be used to request diversity and associate diversity. The means by which the processing node determines the path corresponding to the PAS is beyond the scope of this document.
このドキュメントでは、UNIを介してCNにシグナリングされる情報がコアネットワークSRLG情報の共有知識を必要としない場合のシグナリングメカニズムが定義されています。この目的のために、パスアフィニティセット（PAS）の概念がSRLG情報を抽象化するために定義されています。 PASの導入の背景にある動機は、コアネットワーク（CN）とクライアントデバイス（EN）の間の多様性情報の交換を最小限に抑えることです。 PASには、詳細なSRLGリストではなく、特定のパスに関連付けられた抽象的なSRLG識別子が含まれています。 PASは、多様性を要求し、多様性を関連付けるために使用できる単一の識別子です。処理ノードがPASに対応するパスを決定する方法は、このドキュメントの範囲外です。
A CN on the core network boundary interprets the specific PAS identifier (e.g., "123") as meaning to exclude the core network SRLG information (or equivalent) that has been allocated by LSPs associated with this PAS identifier value. For example, if a path exists for the LSP with the PAS identifier "123", the CN would use local knowledge of the core network SRLGs associated with the LSPs tagged with PAS attribute "123" and use those SRLGs as constraints for path computation. If a PAS identifier is used as an exclusion identifier in the connection request, the CN (UNI-N) in the core network is assumed to be able to determine the existing core network SRLG information and calculate a path that meets the determined diversity constraints.
コアネットワーク境界のCNは、特定のPAS識別子（「123」など）を、このPAS識別子の値に関連付けられたLSPによって割り当てられたコアネットワークSRLG情報（または同等のもの）を除外する意味として解釈します。たとえば、PAS識別子「123」を持つLSPのパスが存在する場合、CNは、PAS属性「123」でタグ付けされたLSPに関連付けられたコアネットワークSRLGのローカル知識を使用し、それらのSRLGをパス計算の制約として使用します。 PAS識別子が接続要求の除外識別子として使用される場合、コアネットワークのCN（UNI-N）は、既存のコアネットワークSRLG情報を決定し、決定されたダイバーシティ制約を満たすパスを計算できると想定されます。
When a CN satisfies a connection setup for an SRLG-diverse signaled path, the CN may optionally record the core network SRLG information for that connection in terms of CN-based parameters and associate that with the EN addresses in the Path message. Specifically, for Layer 1 Virtual Private Networks (L1VPNs), Port Information Tables (PITs) [RFC5251] can be leveraged to translate between client (EN) addresses and core network addresses.
CNがSRLGの多様な信号パスの接続設定を満たす場合、CNはオプションで、その接続のコアネットワークSRLG情報をCNベースのパラメーターの観点から記録し、それをPathメッセージのENアドレスに関連付けることができます。具体的には、レイヤー1バーチャルプライベートネットワーク（L1VPN）の場合、ポート情報テーブル（PIT）[RFC5251]を利用して、クライアント（EN）アドレスとコアネットワークアドレスの間の変換を行うことができます。
The means to distribute the PAS information within the core network is beyond the scope of this document. For example, the PAS and the associated SRLG information can be distributed within the core network by an Interior Gateway Protocol (IGP) or by other means such as configuration. Regardless of means used to distribute the PAS information, the information is kept inside the core network and is not shared with the overlay network (see Figure 1).
コアネットワーク内でPAS情報を配信する方法は、このドキュメントの範囲外です。たとえば、PASおよび関連するSRLG情報は、インテリアゲートウェイプロトコル（IGP）または構成などの他の手段によってコアネットワーク内に配布できます。 PAS情報の配信に使用される手段に関係なく、情報はコアネットワーク内に保持され、オーバーレイネットワークと共有されません（図1を参照）。
This section describes the signaling extensions required to address the aforementioned requirements and use cases.
このセクションでは、前述の要件と使用例に対処するために必要なシグナリング拡張について説明します。
New Diversity XRO subobjects are defined below for the IPv4 and IPv6 address families. Most of the fields in the IPv4 and IPv6 Diversity XRO subobjects are common and are described following the definition of the two subobjects.
新しい多様性XROサブオブジェクトは、IPv4およびIPv6アドレスファミリに対して以下に定義されています。 IPv4およびIPv6の多様性XROサブオブジェクトのフィールドのほとんどは共通であり、2つのサブオブジェクトの定義に従って説明されています。
The IPv4 Diversity XRO subobject is defined as follows:
IPv4 Diversity XROサブオブジェクトは、次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Similarly, the IPv6 Diversity XRO subobject is defined as follows:
同様に、IPv6 Diversity XROサブオブジェクトは次のように定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L flag is used in the same way as for the XRO subobjects defined in [RFC4874], that is:
L：Lフラグは、[RFC4874]で定義されているXROサブオブジェクトと同じ方法で使用されます。
0 indicates that the diversity constraints MUST be satisfied, and
0は、多様性の制約を満たさなければならないことを示します。
1 indicates that the diversity constraints SHOULD be satisfied.
1は、多様性の制約を満たす必要があることを示します。
XRO Type: The value is set to 38 for the IPv4 Diversity XRO subobject. The value is set to 39 for the IPv6 Diversity XRO subobject.
XROタイプ：IPv4多様性XROサブオブジェクトの値は38に設定されます。 IPv6 Diversity XROサブオブジェクトの値は39に設定されています。
Length: Per [RFC4874], the Length contains the total length of the IPv4/IPv6 subobject in bytes, including the XRO Type and Length fields. The Length is variable, depending on the Diversity Identifier Value.
長さ：[RFC4874]ごとに、長さには、XROタイプおよび長さフィールドを含む、IPv4 / IPv6サブオブジェクトの全長がバイト単位で含まれます。長さは、多様性識別子の値によって異なります。
Diversity Identifier Type (DI Type): Diversity Identifier Type (DI Type) indicates the way the reference LSP(s) or route(s) with which diversity is required is identified in the IPv4/IPv6 Diversity subobjects. The following three DI Type values are defined in this document:
ダイバーシティ識別子タイプ（DIタイプ）：ダイバーシティ識別子タイプ（DIタイプ）は、IPv4 / IPv6ダイバーシティサブオブジェクトで、ダイバーシティが必要な参照LSPまたはルートを識別する方法を示します。このドキュメントでは、次の3つのDIタイプ値が定義されています。
DI Type value Definition
------------- --------------------------------
1 Client-Initiated Identifier
2 PCE-Allocated Identifier
3 Network-Assigned Identifier
Attribute Flags (A-Flags): The Attribute Flags (A-Flags) are used to communicate desirable attributes of the LSP being signaled in the IPv4/IPv6 Diversity subobjects. Each flag acts independently. Any combination of flags is permitted.
属性フラグ（Aフラグ）：属性フラグ（Aフラグ）は、IPv4 / IPv6多様性サブオブジェクトでシグナリングされるLSPの望ましい属性を伝えるために使用されます。各フラグは独立して機能します。フラグの任意の組み合わせが許可されます。
0x01 = Destination node exception Indicates that the exclusion does not apply to the destination node of the LSP being signaled.
0x01 =宛先ノードの例外除外が、シグナリングされているLSPの宛先ノードに適用されないことを示します。
0x02 = Processing node exception Indicates that the exclusion does not apply to the node(s) performing ERO expansion for the LSP being signaled. An ingress UNI-N node is an example of such a node.
0x02 =ノード例外の処理シグナリングされているLSPのERO拡張を実行するノードに除外が適用されないことを示します。入力UNI-Nノードは、そのようなノードの例です。
0x04 = Penultimate node exception Indicates that the penultimate node of the LSP being signaled MAY be shared with the excluded path even when this violates the exclusion flags. This flag is useful, for example, when an EN is not dual homed (like EN4 in Figure 1, where all LSPs have to go through CN5).
0x04 =最後から2番目のノードの例外シグナリングされているLSPの最後から2番目のノードが、除外フラグに違反している場合でも、除外されたパスと共有される可能性があることを示します。このフラグは、たとえば、ENがデュアルホームでない場合に役立ちます（図1のEN4のように、すべてのLSPがCN5を通過する必要があります）。
The "Penultimate node exception" flag is typically set when the destination node is single homed (e.g., EN1 or EN4 in Figure 2). In such a case, LSP diversity can only be accomplished inside the core network up to the egress node and the penultimate hop must be the same for the LSPs.
「最後から2番目のノードの例外」フラグは通常、宛先ノードがシングルホームである場合に設定されます（たとえば、図2のEN1またはEN4）。このような場合、LSPダイバーシティは、コアネットワーク内で出口ノードまでしか達成できず、LSPの最後から2番目のホップは同じでなければなりません。
0x08 = LSP ID to be ignored This flag is used to indicate tunnel-level exclusion. Specifically, this flag is used to indicate that if the diversity identifier contains an LSP ID field, then the LSP ID is to be ignored, and the exclusion applies to any LSP matching the rest of the diversity identifier.
0x08 = LSP IDを無視するこのフラグは、トンネルレベルの除外を示すために使用されます。具体的には、このフラグは、ダイバーシティ識別子にLSP IDフィールドが含まれている場合、LSP IDが無視され、残りのダイバーシティ識別子と一致するすべてのLSPに除外が適用されることを示すために使用されます。
Exclusion Flags (E-Flags): The Exclusion Flags are used to communicate the desired type(s) of exclusion requested in the IPv4/IPv6 Diversity subobjects. The following flags are defined. Any combination of these flags is permitted. Please note that the exclusion specified by these flags may be modified by the value of the A-Flags. For example, the node exclusion flag is ignored for the penultimate node if the "Penultimate node exception" flag of the A-Flags is set.
除外フラグ（Eフラグ）：除外フラグは、IPv4 / IPv6多様性サブオブジェクトで要求される除外の目的のタイプを通知するために使用されます。以下のフラグが定義されています。これらのフラグの任意の組み合わせが許可されます。これらのフラグで指定された除外は、Aフラグの値によって変更される場合があることに注意してください。たとえば、Aフラグの「最後から2番目のノードの例外」フラグが設定されている場合、最後から2番目のノードのノード除外フラグは無視されます。
0x01 = SRLG exclusion Indicates that the path of the LSP being signaled is requested to be SRLG disjoint with respect to the excluded path specified by the IPv4/IPv6 Diversity XRO subobject.
0x01 = SRLG exclusionシグナリングされているLSPのパスが、IPv4 / IPv6 Diversity XROサブオブジェクトで指定された除外パスに対してSRLGディスジョイントであることが要求されていることを示します。
0x02 = Node exclusion Indicates that the path of the LSP being signaled is requested to be "node diverse" from the excluded path specified by the IPv4/IPv6 Diversity XRO subobject.
0x02 = Node exclusionシグナリングされているLSPのパスが、IPv4 / IPv6 Diversity XROサブオブジェクトで指定された除外パスから「ノードダイバーシティ」になるように要求されていることを示します。
0x04 = Link exclusion Indicates that the path of the LSP being signaled is requested to be "link diverse" from the path specified by the IPv4/IPv6 Diversity XRO subobject.
0x04 = Link exclusionシグナリングされるLSPのパスが、IPv4 / IPv6 Diversity XROサブオブジェクトで指定されたパスから「リンクダイバーシティ」になるように要求されていることを示します。
0x08 = Reserved This flag is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO subobjects.
0x08 =予約済みこのフラグは予約済みです。送信時にゼロに設定する必要があり、両方のIPv4 / IPv6ダイバーシティXROサブオブジェクトの受信時に無視する必要があります。
Resvd: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO subobjects.
Resvd：このフィールドは予約されています。送信時にゼロに設定する必要があり、両方のIPv4 / IPv6ダイバーシティXROサブオブジェクトの受信時に無視する必要があります。
IPv4/IPv6 Diversity Identifier Source Address: This field MUST be set to the IPv4/IPv6 address of the node that assigns the diversity identifier. Depending on the Diversity Identifier Type, the diversity identifier source may be a client node, PCE entity, or network node. Specifically:
IPv4 / IPv6ダイバーシティ識別子の送信元アドレス：このフィールドは、ダイバーシティ識別子を割り当てるノードのIPv4 / IPv6アドレスに設定する必要があります。ダイバーシティ識別子のタイプに応じて、ダイバーシティ識別子のソースは、クライアントノード、PCEエンティティ、またはネットワークノードになります。具体的には：
* When the Diversity Identifier Type is set to the "Client-Initiated Identifier", the value MUST be set to IPv4/IPv6 tunnel sender address of the reference LSP against which diversity is desired. The IPv4/IPv6 tunnel sender address is as defined in [RFC3209].
* Diversity Identifier Typeが「Client-Initiated Identifier」に設定されている場合、値は、多様性が要求される参照LSPのIPv4 / IPv6トンネル送信者アドレスに設定する必要があります。 IPv4 / IPv6トンネル送信者アドレスは、[RFC3209]で定義されています。
* When the Diversity Identifier Type is set to "PCE-Allocated Identifier", the value MUST be set to the IPv4/IPv6 address of the node that assigned the Path Key identifier and that can return an expansion of the Path Key or use the Path Key as exclusion in a path computation. The Path Key is defined in [RFC5553]. The PCE ID is carried in the Diversity Identifier Source Address field of the subobject.
* Diversity Identifier Typeが「PCE-Allocated Identifier」に設定されている場合、値は、パスキー識別子を割り当てたノードのIPv4 / IPv6アドレスに設定する必要があり、パスキーの拡張を返すか、パスキーを使用できます。パス計算の除外として。パスキーは[RFC5553]で定義されています。 PCE IDは、サブオブジェクトのDiversity Identifier Source Addressフィールドに含まれています。
* When the Diversity Identifier Type is set to "Network-Assigned Identifier", the value MUST be set to the IPv4/IPv6 address of the node allocating the Path Affinity Set (PAS).
* Diversity Identifier Typeが "Network-Assigned Identifier"に設定されている場合、値はパスアフィニティセット（PAS）を割り当てるノードのIPv4 / IPv6アドレスに設定する必要があります。
Diversity Identifier Value: Encoding for this field depends on the Diversity Identifier Type, as defined in the following.
多様性識別子の値：このフィールドのエンコーディングは、以下で定義されているように、多様性識別子のタイプによって異なります。
When the Diversity Identifier Type is set to "Client-Initiated Identifier" in the IPv4 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
多様性識別子タイプがIPv4多様性XROサブオブジェクトで「クライアント開始識別子」に設定されている場合、多様性識別子値は次のようにエンコードする必要があります。
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 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and LSP ID are as defined in [RFC3209].
IPv4トンネルエンドポイントアドレス、トンネルID、拡張トンネルID、およびLSP IDは、[RFC3209]で定義されています。
When the Diversity Identifier Type is set to "Client-Initiated Identifier" in the IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
ダイバーシティ識別子タイプがIPv6ダイバーシティXROサブオブジェクトで「クライアント開始識別子」に設定されている場合、ダイバーシティ識別子の値は次のようにエンコードする必要があります。
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 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Tunnel Endpoint Address, Tunnel ID, IPv6 Extended Tunnel ID, and LSP ID are as defined in [RFC3209].
IPv6トンネルエンドポイントアドレス、トンネルID、IPv6拡張トンネルID、およびLSP IDは、[RFC3209]で定義されています。
When the Diversity Identifier Type is set to "PCE-Allocated Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
多様性識別子タイプがIPv4またはIPv6多様性XROサブオブジェクトで「PCE割り当て識別子」に設定されている場合、多様性識別子の値は次のようにエンコードする必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Key is defined in [RFC5553].
パスキーは[RFC5553]で定義されています。
When the Diversity Identifier Type is set to "Network-Assigned Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
多様性識別子タイプがIPv4またはIPv6多様性XROサブオブジェクトで「ネットワーク割り当て識別子」に設定されている場合、多様性識別子の値は次のようにエンコードする必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Affinity Set (PAS) Identifier field is a 32-bit value that is scoped by (i.e., is only meaningful when used in combination with) the Diversity Identifier Source Address field. There are no restrictions on how a node selects a PAS identifier value. Section 1.3 defines the PAS term and provides context on how values may be selected.
パスアフィニティセット（PAS）識別子フィールドは、ダイバーシティ識別子の送信元アドレスフィールドによってスコープされる（つまり、組み合わせて使用する場合にのみ意味を持つ）32ビットの値です。ノードがPAS識別子の値を選択する方法に制限はありません。セクション1.3は、PAS用語を定義し、値を選択する方法に関するコンテキストを提供します。
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to identify abstract nodes or resources that must not or should not be used on the path between two inclusive abstract nodes or resources in the explicit route. An EXRS contains one or more subobjects of its own, called EXRS subobjects [RFC4874].
[RFC4874]はEXRS EROサブオブジェクトを定義します。 EXRSは、明示的なルートの2つの包括的な抽象ノードまたはリソース間のパスで使用してはならない、または使用してはならない抽象ノードまたはリソースを識別するために使用されます。 EXRSには、EXRSサブオブジェクト[RFC4874]と呼ばれる独自のサブオブジェクトが1つ以上含まれています。
An EXRS MAY include a Diversity subobject as specified in this document. The same type values 38 and 39 MUST be used.
EXRSは、このドキュメントで指定されている多様性サブオブジェクトを含む場合があります。同じタイプ値38と39を使用する必要があります。
The procedure defined in [RFC4874] for processing the XRO and EXRS is not changed by this document. The processing rules for the Diversity XRO and EXRS subobjects are similar unless the differences are explicitly described. Similarly, IPv4 and IPv6 Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS subobjects follow the same processing rules.
[RFC4874]で定義されている、XROおよびEXRSを処理するための手順は、このドキュメントでは変更されていません。 Diversity XROおよびEXRSサブオブジェクトの処理規則は、違いが明示的に説明されていない限り、類似しています。同様に、IPv4およびIPv6の多様性XROサブオブジェクトとIPv4およびIPv6の多様性EXRSサブオブジェクトは、同じ処理規則に従います。
If the processing node cannot recognize the Diversity XRO/EXRS subobject, the node is expected to follow the procedure defined in [RFC4874].
処理ノードがDiversity XRO / EXRSサブオブジェクトを認識できない場合、ノードは[RFC4874]で定義されている手順に従うことが期待されます。
An XRO/EXRS object MAY contain multiple Diversity subobjects of the same DI Type. For example, in order to exclude multiple Path Keys, a node MAY include multiple Diversity XRO subobjects, each with a different Path Key. Similarly, in order to exclude the routes taken by multiple LSPs, a node MAY include multiple Diversity XRO/EXRS subobjects, each with a different LSP identifier. Likewise, to exclude multiple PAS identifiers, a node MAY include multiple Diversity XRO/EXRS subobjects, each with a different PAS identifier. However, all Diversity subobjects in an XRO/EXRS MUST contain the same Diversity Identifier Type. If a Path message contains an XRO/ EXRS with multiple Diversity subobjects of different DI Types, the processing node MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "XRO/EXRS Too Complex" (68/69).
XRO / EXRSオブジェクトには、同じDIタイプの複数の多様性サブオブジェクトが含まれる場合があります。たとえば、複数のパスキーを除外するために、ノードには、それぞれ異なるパスキーを持つ複数の多様性XROサブオブジェクトを含めることができます。同様に、複数のLSPがたどるルートを除外するために、ノードには、それぞれが異なるLSP識別子を持つ複数のDiversity XRO / EXRSサブオブジェクトを含めることができます（MAY）。同様に、複数のPAS識別子を除外するには、ノードに、それぞれ異なるPAS識別子を持つ複数の多様性XRO / EXRSサブオブジェクトを含めることができます（MAY）。ただし、XRO / EXRSのすべての多様性サブオブジェクトには、同じ多様性識別子タイプを含める必要があります。 Pathメッセージに、異なるDIタイプの複数の多様性サブオブジェクトを持つXRO / EXRSが含まれている場合、処理ノードは、エラーコード "Routing Problem"（24）およびエラーサブコード "XRO / EXRS Too Complex"（68 / 69）。
If the processing node recognizes the Diversity XRO/EXRS subobject but does not support the DI Type, it MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "Unsupported Diversity Identifier Type" (36).
処理ノードがDiversity XRO / EXRSサブオブジェクトを認識してもDIタイプをサポートしない場合は、PathErrをエラーコード "Routing Problem"（24）およびエラーサブコード "Unsupported Diversity Identifier Type"（36）とともに返す必要があります。
In the case of DI Type "Client-Initiated Identifier", all nodes along the path SHOULD process the diversity information signaled in the XRO/EXRS Diversity subobjects to verify that the signaled diversity constraint is satisfied. If a diversity violation is detected, crankback signaling MAY be initiated.
DIタイプ「クライアント開始識別子」の場合、パスに沿ったすべてのノードは、XRO / EXRSダイバーシティサブオブジェクトでシグナル通知されたダイバーシティ情報を処理して、通知されたダイバーシティ制約が満たされていることを確認する必要があります。ダイバーシティ違反が検出された場合、クランクバックシグナリングが開始される場合があります。
In the case of DI Type "PCE-Allocated Identifier" and "Network-Assigned Identifier", the nodes in the domain that perform path computation SHOULD process the diversity information signaled in the XRO/EXRS Diversity subobjects as follows. In the PCE case, the ingress node of a domain sends a path computation request for a path from ingress node to egress node, including diversity constraints to a PCE. Or, in the PAS case, the ingress node is capable of calculating the path for the new LSP from ingress node to the egress node, taking the diversity constraints into account. The calculated path is then carried in the Explicit Route Object (ERO). Hence, the transit nodes in a domain and the domain egress node SHOULD NOT process the signaled diversity information unless path computation is performed.
DIタイプ「PCE-Allocated Identifier」および「Network-Assigned Identifier」の場合、パス計算を実行するドメイン内のノードは、XRO / EXRSダイバーシティサブオブジェクトで通知されたダイバーシティ情報を次のように処理する必要があります。 PCEの場合、ドメインの入口ノードは、PCEへのダイバーシティ制約を含め、入口ノードから出口ノードへのパスのパス計算要求を送信します。または、PASの場合、入口ノードは、ダイバーシティの制約を考慮して、入口ノードから出口ノードへの新しいLSPのパスを計算できます。計算されたパスは、明示的ルートオブジェクト（ERO）で伝達されます。したがって、ドメイン内のトランジットノードとドメイン出口ノードは、パス計算が実行されない限り、シグナリングされたダイバーシティ情報を処理してはなりません。
While processing the EXRS object, if a loose hop expansion results in the creation of another loose hop in the outgoing ERO, the processing node MAY include the EXRS in the newly created loose hop for further processing by downstream nodes.
EXRSオブジェクトの処理中に、ルーズホップの拡張により発信EROに別のルーズホップが作成される場合、処理ノードは、ダウンストリームノードによるさらなる処理のために新しく作成されたルーズホップにEXRSを含めることができます（MAY）。
The A-Flags affect the processing of the Diversity XRO/EXRS subobject as follows:
Aフラグは、Diversity XRO / EXRSサブオブジェクトの処理に次のように影響します。
o When the "Processing node exception" flag is set, the exclusion MUST be ignored for the node processing the XRO or EXRS subobject.
o 「ノード例外の処理」フラグが設定されている場合、XROまたはEXRSサブオブジェクトを処理するノードの除外を無視する必要があります。
o When the "Destination node exception" flag is set, the exclusion MUST be ignored for the destination node in processing the XRO subobject. The destination node exception for the EXRS subobject applies to the explicit node identified by the ERO subobject that identifies the next abstract node. When the "Destination node exception" flag is set in the EXRS subobject, exclusion MUST be ignored for said node (i.e., the next abstract node).
o「宛先ノード例外」フラグが設定されている場合、XROサブオブジェクトを処理する際、宛先ノードの除外を無視する必要があります。 EXRSサブオブジェクトの宛先ノード例外は、次の抽象ノードを識別するEROサブオブジェクトによって識別される明示的なノードに適用されます。 「宛先ノード例外」フラグがEXRSサブオブジェクトに設定されている場合、そのノード（つまり、次の抽象ノード）の除外を無視する必要があります。
o When the "Penultimate node exception" flag is set in the XRO subobject, the exclusion MUST be ignored for the penultimate node on the path of the LSP being established.
o 「最後から2番目のノードの例外」フラグがXROサブオブジェクトに設定されている場合、確立されているLSPのパス上の最後から2番目のノードの除外を無視する必要があります。
The penultimate node exception for the EXRS subobject applies to the node before the explicit node identified by the ERO subobject that identifies the next abstract node. When the "Penultimate node exception" flag is set in the EXRS subobject, the exclusion MUST be ignored for said node (i.e., the node before the next abstract node).
EXRSサブオブジェクトの最後から2番目のノード例外は、次の抽象ノードを識別するEROサブオブジェクトによって識別される明示的なノードの前のノードに適用されます。 「最後のノード例外」フラグがEXRSサブオブジェクトで設定されている場合、そのノード（つまり、次の抽象ノードの前のノード）の除外を無視する必要があります。
If the L-flag of the Diversity XRO subobject or Diversity EXRS subobject is not set, the processing node proceeds as follows.
Diversity XROサブオブジェクトまたはDiversity EXRSサブオブジェクトのLフラグが設定されていない場合、処理ノードは次のように進みます。
o If the Diversity Identifier Type is set to "Client-Initiated Identifier", the processing node MUST ensure that the path calculated/expanded for the signaled LSP is diverse from the route taken by the LSP identified in the Diversity Identifier Value field.
o Diversity Identifier Typeが「Client-Initiated Identifier」に設定されている場合、処理ノードは、シグナリングされたLSPに対して計算/拡張されたパスが、Diversity Identifier Valueフィールドで識別されたLSPがたどるルートと異なることを確認する必要があります。
o If the Diversity Identifier Type is set to "PCE-Allocated Identifier", the processing node MUST ensure that any path calculated for the signaled LSP is diverse from the route identified by the Path Key. The processing node MAY use the PCE identified by the Diversity Identifier Source Address in the subobject for route computation. The processing node MAY use the Path Key resolution mechanisms described in [RFC5553].
o Diversity Identifier Typeが "PCE-Allocated Identifier"に設定されている場合、処理ノードは、シグナリングされたLSPに対して計算されたすべてのパスが、パスキーで識別されるルートと異なることを確認する必要があります。処理ノードは、ルート計算のために、サブオブジェクト内のダイバーシティー識別子ソースアドレスによって識別されるPCEを使用できます。処理ノードは、[RFC5553]で説明されているパスキー解決メカニズムを使用してもよい（MAY）。
o If the Diversity Identifier Type is set to "Network-Assigned Identifier", the processing node MUST ensure that the path calculated for the signaled LSP is diverse with respect to the values associated with the PAS Identifier and Diversity Identifier Source Address fields.
o Diversity Identifier Typeが "Network-Assigned Identifier"に設定されている場合、処理ノードは、シグナリングされたLSPに対して計算されたパスが、PAS IdentifierおよびDiversity Identifier Source Addressフィールドに関連付けられた値に関して多様であることを確認する必要があります。
o Regardless of whether the path computation is performed locally or at a remote node (e.g., PCE), the processing node MUST ensure that any path calculated for the signaled LSP is diverse from the requested Exclusion Flags.
o パス計算がローカルで実行されるか、リモートノード（PCEなど）で実行されるかに関係なく、処理ノードは、シグナリングされたLSPに対して計算されたパスが、要求された除外フラグと異なることを確認する必要があります。
o If the excluded path referenced in the XRO subobject is unknown to the processing node, the processing node SHOULD ignore the Diversity XRO subobject and SHOULD proceed with the signaling request. After sending the Resv for the signaled LSP, the processing node MUST return a PathErr with the error code "Notify Error" (25) and error sub-code "Route of XRO LSP identifier unknown" (14) for the signaled LSP.
o XROサブオブジェクトで参照されている除外されたパスが処理ノードに認識されていない場合、処理ノードは多様性XROサブオブジェクトを無視し（SHOULD）、シグナリング要求を続行する必要があります（SHOULD）。シグナリングされたLSPのResvを送信した後、処理ノードは、シグナリングされたLSPのエラーコード「Notify Error」（25）とエラーサブコード「Route of XRO LSP identifier unknown」（14）を含むPathErrを返す必要があります。
o If the processing node fails to find a path that meets the requested constraint, the processing node MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "Route blocked by Exclude Route" (67).
o 処理ノードが、要求された制約を満たすパスを見つけられない場合、処理ノードは、エラーコード "Routing Problem"（24）とエラーサブコード "Exclude Routeによってブロックされたルート"（67）のPathErrを返さなければなりません（MUST）。
If the L-flag of the Diversity XRO subobject or Diversity EXRS subobject is set, the processing node proceeds as follows:
Diversity XROサブオブジェクトまたはDiversity EXRSサブオブジェクトのLフラグが設定されている場合、処理ノードは次のように進みます。
o If the Diversity Identifier Type is set to "Client-Initiated Identifier", the processing node SHOULD ensure that the path calculated/expended for the signaled LSP is diverse from the route taken by the LSP identified in the Diversity Identifier Value field.
o Diversity Identifier Typeが「Client-Initiated Identifier」に設定されている場合、処理ノードは、シグナリングされたLSPに対して計算/拡張されたパスが、Diversity Identifier Valueフィールドで識別されたLSPがたどるルートと異なることを確認する必要があります。
o If the Diversity Identifier Type is set to "PCE-Allocated Identifier", the processing node SHOULD ensure that the path calculated for the signaled LSP is diverse from the route identified by the Path Key.
o Diversity Identifier Typeが "PCE-Allocated Identifier"に設定されている場合、処理ノードは、シグナリングされたLSPに対して計算されたパスが、パスキーによって識別されたルートと異なることを確認する必要があります。
o If the Diversity Identifier Type is set to "Network-Assigned Identifier", the processing node SHOULD ensure that the path calculated for the signaled LSP is diverse with respect to the values associated with the PAS Identifier and Diversity Identifier Source Address fields.
o Diversity Identifier Typeが "Network-Assigned Identifier"に設定されている場合、処理ノードは、シグナリングされたLSPに対して計算されたパスが、PAS IdentifierおよびDiversity Identifier Source Addressフィールドに関連付けられた値に関して多様であることを確認する必要があります。
o If the processing node fails to find a path that meets the requested constraint, it SHOULD proceed with signaling using a suitable path that meets the constraint as far as possible. After sending the Resv for the signaled LSP, it MUST return a PathErr message with error code "Notify Error" (25) and error sub-code "Failed to satisfy Exclude Route" (15) to the source node.
o 処理ノードが要求された制約を満たすパスを見つけるのに失敗した場合、それは可能な限り制約を満たす適切なパスを使用してシグナリングを続行する必要があります。シグナリングされたLSPのResvを送信した後、それはエラーコード "Notify Error"（25）とエラーサブコード "Exclude Routeを満たすことができませんでした"（15）を含むPathErrメッセージをソースノードに返す必要があります。
If, subsequent to the initial signaling of a diverse LSP, an excluded path referenced in the XRO subobject becomes known to the processing node or a change in the excluded path becomes known to the processing node, the processing node MUST re-evaluate the exclusion and diversity constraints requested by the diverse LSP to determine whether they are still satisfied.
多様なLSPの最初のシグナリングに続いて、XROサブオブジェクトで参照される除外されたパスが処理ノードに認識されるか、除外されたパスの変更が処理ノードに認識されるようになった場合、処理ノードは除外を再評価しなければなりません。多様性LSPが依然として満たされているかどうかを判断するために要求する多様性制約。
o In the case where the L-flag was not set in the initial setup message, the exclusion and diversity constraints were satisfied at the time of the initial setup. If the processing node re-evaluating the exclusion and diversity constraints for a diverse LSP detects that the exclusion and diversity constraints are no longer met, it MUST send a PathErr message for the diverse LSP with the error code "Routing Problem" (24) and error sub-code "Route blocked by Exclude Route" (67). The Path_State_Removed (PSR) flag [RFC3473] MUST NOT be set. A source node receiving a PathErr message with this error code and sub-code combination SHOULD take appropriate actions and move the diverse LSP to a new path that meets the original constraints.
o初期設定メッセージでLフラグが設定されていない場合、初期設定時に除外およびダイバーシティの制約が満たされました。多様なLSPの除外と多様性の制約を再評価する処理ノードが、除外と多様性の制約が満たされていないことを検出した場合、多様なLSPのPathErrメッセージを送信し、エラーコード "Routing Problem"（24）およびエラーサブコード「除外ルートによってブロックされたルート」（67）。 Path_State_Removed（PSR）フラグ[RFC3473]を設定してはならない（MUST NOT）。このエラーコードとサブコードの組み合わせを含むPathErrメッセージを受信するソースノードは、適切なアクションを実行して、元の制約を満たす新しいパスに多様なLSPを移動する必要があります（SHOULD）。
o In the case where the L-flag was set in the initial setup message, the exclusion and diversity constraints may or may not be satisfied at any given time. If the exclusion constraints for a diverse LSP were satisfied before, and if the processing node re-evaluating the exclusion and diversity constraints for a diverse LSP detects that exclusion and diversity constraints are no longer met, it MUST send a PathErr message for the diverse LSP with the error code "Notify Error" (25) and error sub-code "Failed to satisfy Exclude Route" (15). The PSR flag MUST NOT be set. The source node MAY take no consequent action and keep the LSP along the path that does not meet the original constraints. Similarly, if the exclusion constraints for a diverse LSP were not satisfied before, and if the processing node re-evaluating the exclusion and diversity constraints for a diverse LSP detects that the exclusion constraints are met, it MUST send a PathErr message for the diverse LSP with the error code "Notify Error" (25) and a new error sub-code "Compliant path exists" (16). The PSR flag MUST NOT be set. A source node receiving a PathErr message with this error code and sub-code combination MAY move the diverse LSP to a new path that meets the original constraints.
o Lフラグが初期セットアップメッセージで設定された場合、除外およびダイバーシティの制約は、いつでも満たされる場合と満たされない場合があります。多様なLSPの除外制約が以前に満たされ、多様なLSPの除外と多様性の制約を再評価している処理ノードが、除外と多様性の制約が満たされていないことを検出した場合、多様なLSPのPathErrメッセージを送信する必要がありますエラーコード「Notify Error」（25）とエラーサブコード「Failed to meet Exclude Route」（15）が表示されます。 PSRフラグを設定してはなりません。ソースノードは、結果として生じるアクションを実行せず、元の制約を満たさないパスに沿ってLSPを維持する場合があります。同様に、多様なLSPの除外制約が以前に満たされていない場合、および多様なLSPの除外と多様性制約を再評価している処理ノードが除外制約が満たされていることを検出した場合、多様なLSPのPathErrメッセージを送信する必要がありますエラーコード「Notify Error」（25）と新しいエラーサブコード「Compliant path exists」（16）が表示されます。 PSRフラグを設定してはなりません。このエラーコードとサブコードの組み合わせを含むPathErrメッセージを受信するソースノードは、元の制約を満たす新しいパスに多様なLSPを移動できます（MAY）。
This document does not introduce any additional security issues in addition to those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC2747], [RFC4874], [RFC5520], and [RFC5553].
このドキュメントでは、[RFC5920]、[RFC2205]、[RFC3209]、[RFC3473]、[RFC2747]、[RFC4874]、[RFC5520]、および[RFC5553]で識別されたものに加えて、追加のセキュリティ問題を紹介しません。
The diversity mechanisms defined in this document rely on the new diversity subobject that is carried in the XRO or EXRS, respectively. In Section 7 of [RFC4874], it is noted that some administrative boundaries may remove the XRO due to security concerns on explicit route information exchange. However, when the diversity subobjects specified in this document are used, removing at the administrative boundary an XRO containing these diversity subobjects would result in the request for diversity being dropped at the boundary, and path computation would be unlikely to produce the requested diverse path. As such, diversity subobjects MUST be retained in an XRO crossing an administrative boundary, even if other subobjects are removed. This retention would be based on operator policy. The use of diversity subobjects is based on mutual agreement. This avoids the need to share the identity of network resources when supporting diversity.
このドキュメントで定義されている多様性メカニズムは、それぞれXROまたはEXRSで実行される新しい多様性サブオブジェクトに依存しています。 [RFC4874]のセクション7では、明示的なルート情報交換に関するセキュリティ上の懸念により、一部の管理境界でXROが削除される場合があることに注意してください。ただし、このドキュメントで指定されているダイバーシティサブオブジェクトが使用されている場合、管理境界でこれらのダイバーシティサブオブジェクトを含むXROを削除すると、境界でダイバーシティのリクエストが削除され、パス計算でリクエストされたダイバーシティパスが生成される可能性は低くなります。そのため、他のサブオブジェクトが削除された場合でも、管理境界を越えるXROに多様性サブオブジェクトを保持する必要があります。この保持は、オペレーターのポリシーに基づいています。多様性サブオブジェクトの使用は、相互の合意に基づいています。これにより、多様性をサポートするときにネットワークリソースのIDを共有する必要がなくなります。
IANA has assigned new values defined in this document and summarized in this section.
IANAは、このドキュメントで定義され、このセクションで要約されている新しい値を割り当てました。
In the IANA registry for RSVP parameters, under "Class Names, Class Numbers, and Class Types", this document defines two new subobjects for the EXCLUDE_ROUTE object [RFC4874], C-Type 1 (see "Class Types or C-Types - 232 EXCLUDE_ROUTE" on <https://www.iana.org/assignments/ rsvp-parameters>).
このドキュメントでは、RSVPパラメータのIANAレジストリの「クラス名、クラス番号、およびクラスタイプ」で、EXCLUDE_ROUTEオブジェクト[RFC4874]の2つの新しいサブオブジェクト、Cタイプ1を定義しています（「クラスタイプまたはCタイプ-232を参照」 EXCLUDE_ROUTE "<https://www.iana.org/assignments/ rsvp-parameters>で）。
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+
The Diversity XRO subobjects are also defined as new EXRS subobjects (see "Class Types or C-Types - 20 EXPLICIT_ROUTE" on <https://www.iana.org/assignments/rsvp-parameters>). The same numeric values have been assigned:
多様性XROサブオブジェクトは、新しいEXRSサブオブジェクトとしても定義されています（<https://www.iana.org/assignments/rsvp-parameters>の「クラスタイプまたはCタイプ-20 EXPLICIT_ROUTE」を参照）。同じ数値が割り当てられています。
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+
In the IANA registry for RSVP parameters, under "Error Codes and Globally Defined Error Value Sub-Codes", for Error Code "Routing Problem" (24) (see [RFC3209]), the following sub-codes are defined (see "Sub-Codes - 24 Routing Problem" on <https://www.iana.org/assignments/rsvp-parameters>).
RSVPパラメータのIANAレジストリの「エラーコードとグローバルに定義されたエラー値のサブコード」で、エラーコード「ルーティングの問題」（24）（[RFC3209]を参照）について、次のサブコードが定義されています（「サブ-Codes-24 Routing Problem」（<https://www.iana.org/assignments/rsvp-parameters>）
+-------+---------------------------------------+-----------+
| Value | Description | Reference |
+-------+---------------------------------------+-----------+
| 36 | Unsupported Diversity Identifier Type | RFC 8390 |
+-------+---------------------------------------+-----------+
For Error Code "Notify Error" (25) (see [RFC3209]), the following sub-codes are defined (see "Sub-Codes - 25 Notify Error" on <https://www.iana.org/assignments/rsvp-parameters>).
エラーコード「Notify Error」（25）（[RFC3209]を参照）の場合、次のサブコードが定義されています（<https://www.iana.org/assignments/rsvpの「Sub-Codes-25 Notify Error」を参照） -parameters>）。
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 14 | Route of XRO LSP identifier unknown | RFC 8390 |
| 15 | Failed to satisfy Exclude Route | RFC 8390 |
| 16 | Compliant path exists | RFC 8390 |
+-------+-------------------------------------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, <https://www.rfc-editor.org/info/rfc2747>.
[RFC2747]ベイカー、F。、リンデル、B。、およびM.タルワー、「RSVP暗号化認証」、RFC 2747、DOI 10.17487 / RFC2747、2000年1月、<https://www.rfc-editor.org/info/ rfc2747>。
[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, <https://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月、<https://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, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //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, <https://www.rfc-editor.org/info/rfc4202>.
[RFC4202] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、DOI 10.17487 / RFC4202、2005年10月、<https://www.rfc-editor.org/info / rfc4202>。
[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, <https://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月、< https://www.rfc-editor.org/info/rfc4874>。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, <https://www.rfc-editor.org/info/rfc4920>.
[RFC4920] Farrel、A.、Ed。、Satyanarayana、A.、Iwata、A.、Fujita、N。、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナリング拡張機能」、RFC 4920、DOI 10.17487 / RFC4920、2007年7月、<https://www.rfc-editor.org/info/rfc4920>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc5553>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc2205>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc4208>。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, DOI 10.17487/RFC5251, July 2008, <https://www.rfc-editor.org/info/rfc5251>.
[RFC5251] Fedyk、D。、編、Rekhter、Y。、編、Papadimitriou、D.、Rabbat、R。、およびL. Berger、「Layer 1 VPN Basic Mode」、RFC 5251、DOI 10.17487 / RFC5251 2008年7月、<https://www.rfc-editor.org/info/rfc5251>。
[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, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<https://www.rfc-editor.org/info/rfc5520>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C., Hartley, M., and Z. Ali, "RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information", RFC 8001, DOI 10.17487/RFC8001, January 2017, <https://www.rfc-editor.org/info/rfc8001>.
[RFC8001] Zhang、F.、Ed。、Gonzalez de Dios、O.、Ed。、Margaria、C.、Hartley、M.、and Z. Ali、 "RSVP-TE Extensions Collecting Shared Risk Link Group（SRLG）情報」、RFC 8001、DOI 10.17487 / RFC8001、2017年1月、<https://www.rfc-editor.org/info/rfc8001>。
Acknowledgements
謝辞
The authors would like to thank Xihua Fu for his contributions. The authors also would like to thank Luyuan Fang and Walid Wakim for their review and comments.
著者は彼の貢献のためにXihua Fuに感謝したいと思います。著者はまた、Luyuan FangとWalid Wakimのレビューとコメントに感謝します。
Contributors
貢献者
Igor Bryskin Huawei Technologies Email: Igor.Bryskin@huawei.com
Igor Bryskin Huawei Technologiesメール：Igor.Bryskin@huawei.com
Daniele Ceccarelli Ericsson Email: Daniele.Ceccarelli@ericsson.com
Daniele Ceccarelli Ericssonメール：Daniele.Ceccarelli@ericsson.com
Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com
Dhruv Dhody Huawei Technologiesメール：dhruv.ietf@gmail.com
Don Fedyk Hewlett-Packard Enterprise Email: don.fedyk@hpe.com
Don Fedyk Hewlett-Packard Enterpriseメール：don.fedyk@hpe.com
Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Systems、Inc.メール：cfilsfil@cisco.com
Gabriele Maria Galimberti Cisco Systems Email: ggalimbe@cisco.com Ori Gerstel SDN Solutions Ltd. Email: origerstel@gmail.com
Gabriele Maria Galimbertiシスコシステムズメール：ggalimbe@cisco.com Ori Gerstel SDN Solutions Ltd.メール：origerstel@gmail.com
Oscar Gonzalez de Dios Telefonica I+D Email: ogondio@tid.es
オスカーゴンザレスデディオステレフォニカI + Dメール：ogondio@tid.es
Matt Hartley Cisco Systems Email: mhartley@cisco.com
マットハートリーシスコシステムズメール：mhartley@cisco.com
Kenji Kumaki KDDI Corporation Email: ke-kumaki@kddi.com
けんじ くまき Ｋっぢ こｒぽらちおん えまいｌ： けーくまき＠ｋっぢ。こｍ
Ruediger Kunze Deutsche Telekom AG Email: Ruediger.Kunze@telekom.de
Ruediger Kunze Deutsche Telekom AGメール：Ruediger.Kunze@telekom.de
Lieven Levrau Nokia Email: Lieven.Levrau@nokia.com
Lieven Levrau Nokiaメール：Lieven.Levrau@nokia.com
Cyril Margaria Email: cyril.margaria@gmail.com
Cyril Margariaメール：cyril.margaria@gmail.com
Julien Meuric France Telecom Orange Email: julien.meuric@orange.com
Julien Meuric France Telecom Orangeメール：julien.meuric@orange.com
Yuji Tochio Fujitsu Email: tochio@jp.fujitsu.com
ゆじ とちお ふじつ えまいｌ： とちお＠ｊｐ。ふじつ。こｍ
Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com
X Ian Zhang hu Aは技術メールです：Zhang。Xian @ Huawei.com
Authors' Addresses
著者のアドレス
Zafar Ali (editor) Cisco Systems.
Zafar Ali（editor）Cisco Systems。
Email: zali@cisco.com
George Swallow (editor) Southend Technical Center
ジョージスワロー（編集者）サウスエンドテクニカルセンター
Email: swallow.ietf@gmail.com
Fatai Zhang (editor) Huawei Technologies
fa too Zhang（editor）hu A is technologies
Email: zhangfatai@huawei.com
Dieter Beller (editor) Nokia
ディーター・ベラー（編集者）ノキア
Email: Dieter.Beller@nokia.com