[要約] RFC 4874は、RSVP-TEにおけるルート除外のための拡張であり、トラフィックエンジニアリングを目的としています。
Network Working Group CY. Lee
Request for Comments: 4874 A. Farrel
Updates: 3209, 3473 Old Dog Consulting
Category: Standards Track S. De Cnodder
Alcatel-Lucent
April 2007
Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
除外ルート - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）への拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).
このドキュメントは、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）を使用して、パスセットアップ中にルート除外を通信する方法を指定しています。
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.
RSVP-TE仕様、「RSVP-TE：LSPトンネルのRSVPへの拡張」（RFC 3209）およびGMPLS拡張、RSVP-TE、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナルリソースリソースリソース予約プロトコル実装工学（RSVP-TE）拡張機能 "（RFC 3473）抽象ノードとリソースをパスセットアップに明示的に含めることを可能にしますが、明示的に除外されません。
In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document.
正確な明示的なパスがヘッドエンドで計算されていないいくつかのネットワークでは、ルートから明示的に除外される抽象ノードとリソースを指定および信号することが有用かもしれません。これらの除外は、パス全体、または明示的なパスで指定された2つの抽象ノード間のパスの一部に適用される場合があります。このドキュメントでは、共有リスクリンクグループ（SRLG）を除外する方法も指定されています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Scope of Exclude Routes ....................................4
1.3. Relationship to MPLS TE MIB ................................5
2. Shared Risk Link Groups .........................................6
2.1. SRLG Subobject .............................................6
3. Exclude Route List ..............................................7
3.1. EXCLUDE_ROUTE Object (XRO) .................................7
3.1.1. IPv4 Prefix Subobject ...............................8
3.1.2. IPv6 Prefix Subobject ...............................9
3.1.3. Unnumbered Interface ID Subobject ..................10
3.1.4. Autonomous System Number Subobject .................10
3.1.5. SRLG Subobject .....................................11
3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO) .......11
4. Explicit Exclusion Route .......................................13
4.1. Explicit Exclusion Route Subobject (EXRS) .................13
4.2. Processing Rules for the Explicit Exclusion Route
Subobject (EXRS) ..........................................15
5. Processing of XRO together with EXRS ...........................16
6. Minimum Compliance .............................................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................17
8.1. New ERO Subobject Type ....................................17
8.2. New RSVP-TE Class Numbers .................................18
8.3. New Error Codes ...........................................18
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Applications ..........................................21
A.1. Inter-Area LSP Protection .................................21
A.2. Inter-AS LSP Protection ...................................22
A.3. Protection in the GMPLS Overlay Model .....................24
A.4. LSP Protection inside a Single Area .......................25
The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup, using the Explicit Route Object (ERO).
In some systems, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. This may be because loose hops or abstract nodes need to be prevented from selecting a route through a specific resource. This is a special case of distributed path calculation in the network.
一部のシステムでは、ルートから明示的に除外される抽象的なノードとリソースを指定および信号することが役立つ場合があります。これは、ゆるいホップまたは抽象的なノードを特定のリソースを介してルートを選択できないようにする必要があるためかもしれません。これは、ネットワーク内の分散パス計算の特別なケースです。
For example, route exclusion could be used in the case where two non-overlapping Label Switched Paths (LSPs) are required. In this case, one option might be to set up one path and collect its route using route recording, and then to exclude the routers on that first path from the setup for the second path. Another option might be to set up two parallel backbones, dual home the provider edge (PE) routers to both backbones, and then exclude the local router on backbone A the first time that you set up an LSP (to a particular distant PE), and exclude the local router on backbone B the second time that you set up an LSP.
たとえば、2つの非重複ラベルスイッチ付きパス（LSP）が必要な場合には、ルートの除外を使用できます。この場合、1つのオプションは、1つのパスをセットアップし、ルート録音を使用してルートを収集し、2番目のパスのセットアップからその最初のパスのルーターを除外することです。別のオプションは、2つのパラレルバックボーン、デュアルホームプロバイダーエッジ（PE）ルーターを両方のバックボーンにセットアップし、バックボーン上のローカルルーターを初めて（特定の遠くのPEに）セットアップすることを除外することです。LSPをセットアップする2度目のバックボーンBのローカルルーターを除外します。
Two types of exclusions are required:
2種類の除外が必要です。
1. Exclusion of certain abstract nodes or resources on the whole path. This set of abstract nodes is referred to as the Exclude Route list.
1. パス全体に特定の抽象ノードまたはリソースを除外します。この抽象ノードのセットは、除外ルートリストと呼ばれます。
2. Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an ERO. Such specific exclusions are referred to as Explicit Exclusion Route.
2. EROに存在する特定の抽象ノード間の特定の抽象ノードまたはリソースの除外。このような特定の除外は、明示的な除外ルートと呼ばれます。
To convey these constructs within the signaling protocol, a new RSVP object and a new ERO subobject are introduced respectively.
これらのコンストラクトをシグナル伝達プロトコル内で伝えるために、それぞれ新しいRSVPオブジェクトと新しいEROサブオブジェクトが導入されます。
- A new RSVP-TE object is introduced to convey the Exclude Route list. This object is the EXCLUDE_ROUTE object (XRO).
- 除外ルートリストを伝えるために、新しいRSVP-TEオブジェクトが導入されています。このオブジェクトは、exclude_routeオブジェクト（xro）です。
- The second type of exclusion is achieved through a modification to the existing ERO. A new ERO subobject type the Explicit Exclusion Route Subobject (EXRS) is introduced to indicate an exclusion between a pair of included abstract nodes.
- 2番目のタイプの除外は、既存のEROの変更によって達成されます。新しいEROサブオブジェクトタイプ明示的な除外ルートサブオブジェクト（EXRS）が導入され、含まれる抽象ノードのペア間の除外を示す。
The knowledge of SRLGs, as defined in [RFC4216], may be used to compute diverse paths that can be used for protection. In systems where it is useful to signal exclusions, it may be useful to signal SRLGs to indicate groups of resources that should be excluded on the whole path or between two abstract nodes specified in an explicit path.
[RFC4216]で定義されているSRLGの知識は、保護に使用できる多様なパスを計算するために使用できます。除外に信号を送ることが有用なシステムでは、SRLGSを信号に合わせて、パス全体で除外されるべきリソースのグループを示すか、明示的なパスで指定された2つの抽象的なノードの間で除外する必要がある場合があります。
This document introduces a subobject to indicate an SRLG to be signaled in either of the two exclusion methods described above. This document does not assume or preclude any other usage for this subobject. This subobject might also be appropriate for use within an Explicit Route object (ERO) or Record Route object (RRO), but this is outside the scope of this document.
このドキュメントでは、上記の2つの除外方法のいずれかでSRLGが信号を送信することを示すサブオブジェクトを紹介します。このドキュメントでは、このサブオブジェクトの他の使用法を想定または排除しません。このサブオブジェクトは、明示的なルートオブジェクト（ERO）またはレコードルートオブジェクト（RRO）内での使用にも適している場合がありますが、これはこのドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document does not preclude a route exclusion from listing arbitrary nodes or network elements to avoid. The intent is, however, to indicate only the minimal number of subobjects to be explicitly avoided. For instance, it may be necessary to signal only the SRLGs (or Shared Risk Link Groups) to avoid. That is, the route exclusion is not intended to define the actual route by listing all of the choices to exclude at each hop, but rather to constrain the normal route selection process where loose hops or abstract nodes are to be expanded by listing certain elements to be avoided.
このドキュメントは、回避する任意のノードまたはネットワーク要素をリストすることからのルート除外を排除するものではありません。ただし、意図は、明示的に回避されるサブオブジェクトの最小数のみを示すことです。たとえば、回避するためにSRLG（または共有リスクリンクグループ）のみに信号を送る必要がある場合があります。つまり、ルートの除外は、各ホップで除外するすべての選択肢をリストすることで実際のルートを定義することではなく、特定の要素を特定の要素にリストすることによって緩和されたホップまたは抽象的なノードが拡張される通常のルート選択プロセスを制約することを目的としています。避けてください。
It is envisaged that most of the conventional inclusion subobjects are specified in the signaled ERO only for the area where they are pertinent. The number of subobjects to be avoided, specified in the signaled XRO, may be constant throughout the whole path setup, or the subobjects to be avoided may be removed from the XRO as they become irrelevant in the subsequent hops of the path setup.
従来のインクルージョンサブオブジェクトのほとんどは、適合性のある領域でのみ信号型EROで指定されていることが想定されています。シグナル付きXROで指定されたサブオブジェクトの数は、パスセットアップ全体で一定である場合があります。または、パスセットアップの後続のホップで無関係になるため、避けられるサブオブジェクトがXROから削除される場合があります。
For example, consider an LSP that traverses multiple computation domains. A computation domain may be an area in the administrative or IGP sense, or may be an arbitrary division of the network for active management and path computational purposes. Let the primary path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where:
たとえば、複数の計算ドメインを通過するLSPを検討してください。計算ドメインは、管理またはIGPの意味の領域である可能性があるか、アクティブな管理およびパス計算目的のためのネットワークのarbitrary意的な分割である場合があります。一次パスを（Ingress、A1、A2、AB1、B1、B2、BC1、C1、C2、Egress）とします。
- Xn denotes a node in domain X, and
- xnは、ドメインxのノードを示します
- XYn denotes a node on the border of domain X and domain Y.
- Xynは、ドメインXとドメインYの境界上のノードを示します。
Note that Ingress is a node in domain A, and Egress is a node in domain C. This is shown in Figure 1 where the domains correspond with areas.
イングレスはドメインAのノードであり、出口はドメインCのノードであることに注意してください。これは、ドメインが領域に対応する図1に示されています。
area A area B area C
<-------------------> <----------------> <------------------>
Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
^ \ / | \ / | \ /
| \ / | \ / | \ /
| A3----------A4--AB2--B3--------B4--BC2--C3----------C4
| ^ ^
| | |
| | |
| | ERO: (C3-strict, C4-strict,
| | Egress-strict)
| | XRO: Not needed
| |
| ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
| XRO: (BC1, C1, C2)
|
ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
XRO: (AB1, B1, B2, BC1, C1, C2, Egress)
Figure 1: Domains Corresponding to IGP Areas
図1：IGP領域に対応するドメイン
Consider the establishment of a node-diverse protection path in the example above. The protection path must avoid all nodes on the primary path. The exclusions for area A are handled during Constrained Shortest Path First (CSPF) computation at Ingress, so the ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2), respectively. At AB2, the ERO and XRO could be (B3-strict, B4- strict, BC2-strict, Egress-loose) and (BC1, C1, C2), respectively. At BC2, the ERO could be (C3-strict, C4-strict, Egress-strict) and an XRO is not needed from BC2 onwards.
上記の例では、ノードダイバー保護パスの確立を検討してください。保護パスは、プライマリパス上のすべてのノードを回避する必要があります。エリアAの除外は、Ingressでの制約最短パス（CSPF）計算中に処理されるため、IngressでEROとXROは（A3-Strict、A4-Strict、AB2-Strict、Eutress-Loose）およびAB1、（AB1、）である可能性があります。それぞれB1、B2、BC1、C1、C2）。AB2では、EROとXROはそれぞれ（B3-Strict、B4-Strict、BC2-Strict、Egress-Loose）および（BC1、C1、C2）である可能性があります。BC2では、EROはBC2以降からXROが必要ではありません（C3-Strict、C4-Strict、Higress-Strict）は必要ありません。
In general, consideration SHOULD be given (as with explicit route) to the size of signaled data and the impact on the signaling protocol.
一般に、シグナル付きデータのサイズとシグナル伝達プロトコルへの影響について、（明示的なルートのように）考慮すべきです。
[RFC3812] defines managed objects for managing and modeling MPLS-based traffic engineering. Included in [RFC3812] is a means to configure explicit routes for use on specific LSPs. This configuration allows the exclusion of certain resources.
[RFC3812] MPLSベースのトラフィックエンジニアリングを管理およびモデル化するための管理されたオブジェクトを定義します。[RFC3812]に含まれるのは、特定のLSPで使用するための明示的なルートを構成する手段です。この構成により、特定のリソースを除外できます。
In systems where the full explicit path is not computed at the ingress (or at a path computation site for use at the ingress), it may be necessary to signal those exclusions. This document offers a means of doing this signaling.
完全な明示的なパスがイングレスで（またはイングレスで使用するためのパス計算部位で計算されないシステムでは、それらの除外を信号する必要がある場合があります。このドキュメントは、このシグナル伝達を行う手段を提供します。
The identifier of an SRLG is defined as a 32-bit quantity in [RFC4202]. An SRLG subobject is introduced such that it can be used in the exclusion methods as described in the following sections. This document does not assume or preclude any other usage for this subobject. This subobject might also be appropriate for use within Explicit Route object (ERO) or Record Route object (RRO), but this is outside the scope of this document.
SRLGの識別子は、[RFC4202]の32ビット量として定義されます。次のセクションで説明されているように、除外方法で使用できるようにSRLGサブオブジェクトが導入されます。このドキュメントでは、このサブオブジェクトの他の使用法を想定または排除しません。このサブオブジェクトは、明示的なルートオブジェクト（ERO）またはレコードルートオブジェクト（RRO）内での使用にも適している場合がありますが、これはこのドキュメントの範囲外です。
The new SRLG subobject is defined by this document as follows. Its format is modeled on the ERO subobjects defined in [RFC3209].
新しいSRLGサブオブジェクトは、このドキュメントで次のように定義されています。その形式は、[RFC3209]で定義されているEROサブオブジェクトにモデル化されています。
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| Type | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
l lビットはサブオブジェクトの属性です。サブオブジェクトが明示的なルートのルーズホップを表す場合、Lビットが設定されます。ビットが設定されていない場合、サブオブジェクトは明示的なルートでの厳密なホップを表します。
For exclusions (as used by XRO and EXRS defined in this document), the L bit SHOULD be set to zero and ignored.
除外の場合（このドキュメントで定義されているXROおよびEXRSで使用）、Lビットはゼロに設定して無視する必要があります。
Type The type of the subobject (34)
サブオブジェクトのタイプを入力します（34）
Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
長さの長さには、タイプと長さのフィールドを含むバイトのサブオブジェクトの全長が含まれます。長さは常に8です。
SRLG Id The 32-bit identifier of the SRLG.
SRLG ID SRLGの32ビット識別子。
Reserved This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
予約されたこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The exclude route identifies a list of abstract nodes that should not be traversed along the path of the LSP being established. It is RECOMMENDED that the size of the exclude route list be limited to a value local to the node originating the exclude route list.
除外ルートは、確立されているLSPの経路に沿って通過してはならない抽象ノードのリストを識別します。除外ルートリストのサイズは、除外ルートリストを発信するノードにローカルに制限することをお勧めします。
Abstract nodes to be excluded from the path are specified via the EXCLUDE_ROUTE object (XRO).
パスから除外される抽象ノードは、exclude_routeオブジェクト（xro）を介して指定されます。
Currently, one C_Type is defined, Type 1 EXCLUDE_ROUTE. The EXCLUDE_ROUTE object has the following format:
現在、1つのC_Typeが定義されており、タイプ1 exclude_routeです。exclude_routeオブジェクトには、次の形式があります。
Class = 232, C_Type = 1
class = 232、c_type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of an EXCLUDE_ROUTE object are a series of variable-length data items called subobjects. This specification adapts ERO subobjects as defined in [RFC3209], [RFC3473], and [RFC3477] for use in route exclusions. The SRLG subobject as defined in Section 2 of this document has not been defined before. The SRLG subobject is defined here for use with route exclusions.
exclude_routeオブジェクトの内容は、Subobjectsと呼ばれる一連の可変長データ項目です。この仕様は、ルート除外で使用するために[RFC3209]、[RFC3473]、および[RFC3473]で定義されているEROサブオブジェクトを適合します。このドキュメントのセクション2で定義されているSRLGサブオブジェクトは、以前に定義されていません。SRLGサブオブジェクトは、ルート除外で使用するためにここで定義されています。
The following subobject types are supported.
次のサブオブジェクトタイプがサポートされています。
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
The defined values for Type above are specified in [RFC3209] and in this document.
上記のタイプの定義された値は、[RFC3209]およびこのドキュメントで指定されています。
The concept of loose or strict hops has no meaning in route exclusion. The L bit, defined for ERO subobjects in [RFC3209], is reused here to indicate that an abstract node MUST be excluded (value 0) or SHOULD be avoided (value 1). The distinction is that the path of an LSP must not traverse an abstract node listed in the XRO with the L bit clear, but may traverse one with the L bit set. A node responsible for routing an LSP (for example, for expanding a loose hop) should attempt to minimize the number of abstract nodes listed in the XRO with the L bit set that are traversed by the LSP according to local policy. A node generating XRO subobjects with the L bit set must be prepared to accept an LSP that traverses one, some, or all of the corresponding abstract nodes.
ゆるいまたは厳格なホップの概念は、ルートの排除には意味がありません。[RFC3209]のEROサブオブジェクトで定義されているLビットは、ここで再利用され、抽象ノードを除外する必要があるか（値0）、または避ける必要があることを示します（値1）。区別は、LSPのパスは、XROにリストされている抽象ノードをlビットクリアで横断してはならないが、Lビットセットで1つを横断する場合があることです。LSPのルーティングを担当するノード（たとえば、ルーズホップを拡張する場合）は、ローカルポリシーに従ってLSPによって横断されるLビットセットを使用して、XROにリストされている抽象ノードの数を最小限に抑えようと試みる必要があります。L BITセットを使用してXROサブオブジェクトを生成するノードは、対応する抽象ノードの1つ、一部、またはすべてを通過するLSPを受け入れるように準備する必要があります。
Subobjects 1, 2, and 4 refer to an interface or a set of interfaces. An Attribute octet is introduced in these subobjects to indicate the attribute (e.g., interface, node, SRLG) associated with the interfaces that should be excluded from the path. For instance, the attribute node allows a whole node to be excluded from the path by specifying an interface of that node in the XRO subobject, in contrast to the attribute interface, which allows a specific interface (or multiple interfaces) to be excluded from the path without excluding the whole node. The attribute SRLG allows all SRLGs associated with an interface to be excluded from the path.
サブオブジェクト1、2、および4は、インターフェイスまたはインターフェイスのセットを指します。これらのサブオブジェクトに属性が導入され、パスから除外するインターフェイスに関連付けられた属性（インターフェイス、ノード、SRLGなど）を示します。たとえば、属性ノードは、属性インターフェイスとは対照的に、Xroサブオブジェクトのそのノードのインターフェイスを指定することにより、パスからノード全体を除外できます。これにより、特定のインターフェイス（または複数のインターフェイス）を除外できますノード全体を除外せずにパス。属性SRLGを使用すると、インターフェイスに関連付けられたすべてのSRLGをパスから除外できます。
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| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided.
L 0は、指定された属性を除外する必要があることを示します。1は、指定された属性を避ける必要があることを示します。
Attribute
属性
Interface attribute values 0 indicates that the interface or set of interfaces associated with the IPv4 prefix should be excluded or avoided.
インターフェイス属性値0は、IPv4プレフィックスに関連付けられたインターフェイスまたはインターフェイスのセットを除外または避ける必要があることを示します。
Node attribute value 1 indicates that the node or set of nodes associated with the IPv4 prefix should be excluded or avoided.
ノード属性値1は、IPv4プレフィックスに関連付けられたノードのノードまたはセットを除外または避ける必要があることを示します。
SRLG attribute values 2 indicates that all the SRLGs associated with the IPv4 prefix should be excluded or avoided.
SRLG属性値2は、IPv4プレフィックスに関連付けられているすべてのSRLGを除外または避ける必要があることを示します。
The rest of the fields are as defined in [RFC3209].
残りのフィールドは[RFC3209]で定義されています。
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| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided.
L 0は、指定された属性を除外する必要があることを示します。1は、指定された属性を避ける必要があることを示します。
Attribute
属性
Interface attribute value 0 indicates that the interface or set of interfaces associated with the IPv6 prefix should be excluded or avoided.
インターフェイス属性値0は、IPv6プレフィックスに関連付けられたインターフェイスまたはインターフェイスのセットを除外または避ける必要があることを示します。
Node attribute value 1 indicates that the node or set of nodes associated with the IPv6 prefix should be excluded or avoided.
ノード属性値1は、IPv6プレフィックスに関連付けられたノードのノードまたはセットを除外または避ける必要があることを示します。
SRLG attribute value 2 indicates that all the SRLGs associated with the IPv6 prefix should be excluded or avoided.
SRLG属性値2は、IPv6プレフィックスに関連付けられているすべてのSRLGを除外または避ける必要があることを示します。
The rest of the fields are as defined in [RFC3209].
残りのフィールドは[RFC3209]で定義されています。
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| Type | Length | Reserved | Attribute |
| | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided.
L 0は、指定された属性を除外する必要があることを示します。1は、指定された属性を避ける必要があることを示します。
Attribute
属性
Interface attribute value 0 indicates that the Interface ID specified should be excluded or avoided.
インターフェイス属性値0は、指定されたインターフェイスIDを除外または回避する必要があることを示します。
Node attribute value 1 indicates that the node with the Router ID should be excluded or avoided (this can be achieved using an IPv4/v6 subobject as well, but is included here because it may be convenient to use information from subobjects of an RRO, as defined in [RFC3477], in specifying the exclusions).
ノード属性値1は、ルーターIDを持つノードを除外または避ける必要があることを示します（これはIPv4/V6サブオブジェクトを使用しても実現できますが、RROのサブオブジェクトからの情報を使用するのに便利な場合があるため、ここに含まれています。[RFC3477]で定義されており、除外を指定します）。
SRLG attribute value 2 indicates that all the SRLGs associated with the interface should be excluded or avoided.
SRLG属性値2は、インターフェイスに関連付けられているすべてのSRLGを除外または避ける必要があることを示します。
Reserved This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
予約されたこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The rest of the fields are as defined in [RFC3477].
残りのフィールドは[RFC3477]で定義されています。
The meaning of the L bit is as follows: 0 indicates that the abstract node specified MUST be excluded. 1 indicates that the abstract node specified SHOULD be avoided.
Lビットの意味は次のとおりです。0指定された抽象ノードを除外する必要があることを示します。1は、指定された抽象ノードを避ける必要があることを示します。
The rest of the fields are as defined in [RFC3209]. There is no Attribute octet defined.
残りのフィールドは[RFC3209]で定義されています。Octetが定義されている属性はありません。
The meaning of the L bit is as follows: 0 indicates that the SRLG specified MUST be excluded 1 indicates that the SRLG specified SHOULD be avoided
Lビットの意味は次のとおりです。0指定されたSRLGを除外する必要があることを示します1は、指定されたSRLGを避ける必要があることを示します
The Attribute octet is not present. The rest of the fields are as defined in the "SRLG Subobject" section of this document.
属性オクテットは存在しません。残りのフィールドは、このドキュメントの「SRLGサブオブジェクト」セクションで定義されています。
The exclude route list is encoded as a series of subobjects contained in an EXCLUDE_ROUTE object. Each subobject identifies an abstract node in the exclude route list.
除外ルートリストは、exclude_routeオブジェクトに含まれる一連のサブオブジェクトとしてエンコードされます。各サブオブジェクトは、除外ルートリストの抽象ノードを識別します。
Each abstract node may be a precisely specified IP address belonging to a node, or an IP address with prefix identifying interfaces of a group of nodes, an Autonomous System, or an SRLG.
各抽象ノードは、ノードに属する正確に指定されたIPアドレス、またはノードのグループ、自律システム、またはSRLGのグループのインターフェイスを識別するプレフィックスを備えたIPアドレスである場合があります。
The Explicit Route and routing processing is unchanged from the description in [RFC3209] with the following additions:
明示的なルートとルーティングの処理は、[RFC3209]の説明とは変更されていません。
1. When a Path message is received at a node, the node MUST check that it is not a member of any of the abstract nodes in the XRO if it is present in the Path message. If the node is a member of any of the abstract nodes in the XRO with the L-flag set to "exclude", it SHOULD return a PathErr with the error code "Routing Problem" and error value of "Local node in Exclude Route". If there are SRLGs in the XRO, the node SHOULD check that the resources the node uses are not part of any SRLG with the L-flag set to "exclude" that is specified in the XRO. If it is, it SHOULD return a PathErr with error code "Routing Problem" and error value of "Local node in Exclude Route".
1. パスメッセージがノードで受信された場合、ノードは、パスメッセージに存在する場合、XROの抽象ノードのメンバーではないことを確認する必要があります。ノードがXROの抽象ノードのメンバーである場合、l-flagが「除外」に設定されている場合、エラーコード「ルーティングの問題」と「除外ルートでのローカルノードのローカルノード」のエラー値を持つpatherrを返す必要があります。。XROにSRLGSがある場合、ノードは、ノードが使用するリソースが、XROで指定されている「除外」するL-Flagセットを備えたSRLGの一部ではないことを確認する必要があります。もしそうなら、エラーコード「ルーティング問題」と「除外ルートのローカルノード」のエラー値を備えたPatherrを返す必要があります。
2. Each subobject MUST be consistent. If a subobject is not consistent then the node SHOULD return a PathErr with error code "Routing Problem" and error value "Inconsistent Subobject". An example of an inconsistent subobject is an IPv4 Prefix subobject containing the IP address of a node and the attribute field is set to "interface" or "SRLG".
2. 各サブオブジェクトは一貫している必要があります。サブオブジェクトが一貫していない場合、ノードはエラーコード「ルーティング問題」とエラー値「一貫性のないサブオブジェクト」を備えたPatherrを返す必要があります。一貫性のないサブオブジェクトの例は、ノードのIPアドレスと属性フィールドを含むIPv4プレフィックスサブオブジェクトです。
3. The subobjects in the ERO and XRO SHOULD NOT contradict each other. If a Path message is received that contains contradicting ERO and XRO subobjects, then:
3. EROとXROのサブオブジェクトは、互いに矛盾するべきではありません。矛盾するEROおよびXROサブオブジェクトを含むパスメッセージを受信した場合、次のとおりです。
- Subobjects in the XRO with the L flag not set (zero) MUST take precedence over the subobjects in the ERO -- that is, a mandatory exclusion expressed in the XRO MUST be honored and an implementation MUST reject such a Path message. This means that a PathErr with error code "Routing Problem" and error value of "Route blocked by Exclude Route" is returned.
- XROのサブオブジェクトは、Lフラグが設定されていない（ゼロ）を使用して、EROのサブオブジェクトよりも優先されなければなりません。つまり、XROで表明された必須の除外を尊重し、実装はそのようなパスメッセージを拒否しなければなりません。これは、エラーコード「ルーティング問題」と「除外ルートによってブロックされたルート」のエラー値を持つPatherrが返されることを意味します。
- Subobjects in the XRO with the L flag set do not take precedence over ERO subobjects -- that is, an implementation MAY choose to reject a Path message because of such a contradiction, but MAY continue and set up the LSP (ignoring the XRO subobjects that contradict the ERO subobjects).
- Lフラグセットを備えたXROのサブオブジェクトは、EROサブオブジェクトよりも優先されません。つまり、実装はそのような矛盾のためにパスメッセージを拒否することを選択する場合がありますが、LSPを継続してセットアップする場合があります（XROサブオブジェクトを無視してください。EROサブオブジェクトと矛盾します）。
4. When choosing a next hop or expanding an explicit route to include additional subobjects, a node:
4. 次のホップを選択したり、明示的なルートを拡張して追加のサブオブジェクトを含める場合、ノード：
a. MUST NOT introduce an explicit node or an abstract node that equals or is a member of any abstract node that is specified in the EXCLUDE_ROUTE object with the L-flag set to "exclude". The number of introduced explicit nodes or abstract nodes with the L flag set to "avoid", which indicates that it is not mandatory to be excluded but that it is less preferred, SHOULD be minimized in the computed path.
a. l-flagが「除外」に設定されたexclude_routeオブジェクトで指定されている抽象ノードのメンバーに等しい、またはメンバーである明示的なノードまたは抽象ノードを導入しないでください。導入された明示的なノードまたは「回避」に設定されたLフラグを備えた抽象ノードの数は、除外されることは必須ではないが、それがあまり好ましくないことを、計算されたパスで最小化する必要があることを示します。
b. MUST NOT introduce links, nodes, or resources identified by the SRLG Id specified in the SRLG subobjects(s). The number of introduced SRLGs with the L flag set to "avoid" SHOULD be minimized.
b. SRLGサブオブジェクトで指定されたSRLG IDによって識別されたリンク、ノード、またはリソースを導入してはなりません。「回避」に設定されたLフラグを備えた導入されたSRLGの数を最小限に抑える必要があります。
If these rules preclude further forwarding of the Path message, the node SHOULD return a PathErr with the error code "Routing Problem" and error value of "Route blocked by Exclude Route".
これらのルールがパスメッセージのさらなる転送を排除する場合、ノードはエラーコード「ルーティング問題」と「除外ルートによってブロックされたルート」のエラー値を持つPatherrを返す必要があります。
Note that the subobjects in the XRO is an unordered list of subobjects.
XROのサブオブジェクトは、サブオブジェクトの順序付けられていないリストであることに注意してください。
A node receiving a Path message carrying an XRO MAY reject the message if the XRO is too large or complicated for the local implementation or the rules of local policy. In this case, the node MUST send a PathErr message with the error code "Routing Error" and error value "XRO Too Complex". An ingress LSR receiving this error code/value combination MAY reduce the complexity of the XRO or route around the node that rejected the XRO.
XROを運ぶパスメッセージを受信するノードは、XROが大きすぎるか、ローカルポリシーのルールに対して複雑すぎる場合にメッセージを拒否する場合があります。この場合、ノードはエラーコード「ルーティングエラー」とエラー値「XROが複雑すぎる」を使用してPATHERRメッセージを送信する必要があります。このエラーコード/値の組み合わせを受信するIngress LSRは、XROを拒否したノード周辺のXROまたはルートの複雑さを減らす場合があります。
The XRO Class-Num is of the form 11bbbbbb so that nodes that do not support the XRO forward it uninspected and do not apply the extensions to ERO processing described above. This approach is chosen to allow route exclusion to traverse parts of the network that are not capable of parsing or handling the new function. Note that Record Route may be used to allow computing nodes to observe violations of route exclusion and attempt to re-route the LSP accordingly.
Xroクラスナムはフォーム11bbbbbbbであるため、XRO転送をサポートしないノードが検査されず、上記のERO処理に拡張機能を適用しません。このアプローチは、新しい機能を解析または処理できないネットワークの部分を横断するためのルート除外を可能にするために選択されます。レコードルートを使用して、コンピューティングノードがルートの除外の違反を観察し、それに応じてLSPを再ルーティングしようとすることに注意することができます。
If a node supports the XRO, but not a particular subobject or part of that subobject, then that particular subobject is ignored. Examples of a part of a subobject that can be supported are: (1) only prefix 32 of the IPv4 prefix subobject could be supported, or (2) a particular subobject is supported but not the particular attribute field.
ノードがXROをサポートしますが、特定のサブオブジェクトまたはそのサブオブジェクトの一部ではない場合、その特定のサブオブジェクトは無視されます。サポートできるサブオブジェクトの一部の例は次のとおりです。（1）IPv4プレフィックスサブオブジェクトのプレフィックス32のみをサポートできます。
When a node forwards a Path message, it can do the following three operations related to XRO besides the processing rules mentioned above:
ノードがパスメッセージを転送すると、上記の処理ルールに加えて、XROに関連する次の3つの操作を実行できます。
1. If no XRO was present, an XRO may be included.
1. XROが存在しない場合、XROを含めることができます。
2. If an XRO was present, it may remove the XRO if it is sure that the next nodes do not need this information anymore. An example is where a node can expand the ERO to a full strict path towards the destination. See Figure 1 where BC2 is removing the XRO from the Path message.
2. XROが存在する場合、次のノードがこの情報を必要としなくなった場合がある場合、XROを削除する場合があります。例は、ノードがEROを宛先に向かって完全に厳格なパスに拡張できる場合です。BC2がパスメッセージからXROを削除している図1を参照してください。
3. If an XRO was present, the content of the XRO can be modified. Subobjects can be added or removed. See Figure 1 for an example where AB2 is stripping off some subobjects.
3. XROが存在する場合、XROの内容を変更できます。サブオブジェクトは追加または削除できます。AB2がいくつかのサブオブジェクトを取り除いている例については、図1を参照してください。
In any case, a node MUST NOT introduce any explicit or abstract node in the XRO (irrespective of the value of the L flag) that it also has introduced in the ERO.
いずれにせよ、ノードは、EROで導入されたXRO（Lフラグの値に関係なく）に明示的または抽象ノードを導入してはなりません。
The Explicit Exclusion Route defines abstract nodes or resources (such as links, unnumbered interfaces, or labels) that must not or should not be used on the path between two inclusive abstract nodes or resources in the explicit route.
明示的な除外ルートは、明示的なルートの2つの包括的な抽象ノードまたはリソースの間のパスで使用してはならない、または使用してはならない、または使用してはならない、または使用してはならない抽象ノードまたはリソース（リンク、リンク、リンク、リンクなしのインターフェイス、またはラベルなど）を定義します。
A new ERO subobject type is defined. The Explicit Exclusion Route Subobject (EXRS) has type 33. Although the EXRS is an ERO subobject and the XRO is reusing the ERO subobject, an EXRS MUST NOT be present in an XRO. An EXRS is an ERO subobject that contains one or more subobjects of its own, called EXRS subobjects.
新しいEROサブオブジェクトタイプが定義されています。明示的な除外ルートサブオブジェクト（EXRS）にはタイプ33があります。EXRSはEROサブオブジェクトであり、XROはEROサブオブジェクトを再利用していますが、EXRはXROに存在してはなりません。EXRSは、EXRSサブオブジェクトと呼ばれる独自の1つ以上のサブオブジェクトを含むEROサブオブジェクトです。
The format of the EXRS is as follows:
EXRSの形式は次のとおりです。
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| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// one or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L It MUST be set to zero on transmission and MUST be ignored on receipt. (Note: The L bit in an EXRS subobject is as defined for the XRO subobjects.)
l送信時にゼロに設定する必要があり、受領時に無視する必要があります。（注：EXRSサブオブジェクトのLビットは、XROサブオブジェクトに対して定義されています。）
Type The type of the subobject (33).
サブオブジェクトのタイプ（33）を入力します。
Reserved This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
予約されたこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
EXRS subobjects An EXRS subobject indicates the abstract node or resource to be excluded. The format of an EXRS subobject is exactly the same as the format of a subobject in the XRO. An EXRS may include all subobjects defined in this document for the XRO.
EXRSサブオブジェクトEXRSサブオブジェクトは、除外する抽象ノードまたはリソースを示します。EXRSサブオブジェクトの形式は、XROのサブオブジェクトの形式とまったく同じです。EXRには、XROのこのドキュメントで定義されているすべてのサブオブジェクトが含まれる場合があります。
Thus, an EXRS for an IP hop may look as follows:
したがって、IPホップのEXRは次のように見える場合があります。
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| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each EXRS may carry multiple exclusions. The exclusion is encoded exactly as for XRO subobjects and prefixed by an additional Type and Length.
各EXRには複数の除外が含まれる場合があります。除外は、XROサブオブジェクトのように正確にエンコードされ、追加のタイプと長さが付けられています。
The scope of the exclusion is the step between the previous ERO subobject that identifies an abstract node, and the subsequent ERO subobject that identifies an abstract node. The processing rules of the EXRS are the same as the processing rule of the XRO within this scope. Multiple exclusions may be present between any pair of abstract nodes.
除外の範囲は、抽象ノードを識別する前のEROサブオブジェクトと、抽象ノードを識別するその後のEROサブオブジェクトの間のステップです。EXRの処理ルールは、この範囲内のXROの処理ルールと同じです。抽象ノードの任意のペア間に複数の除外が存在する場合があります。
Exclusions may indicate explicit nodes, abstract nodes, or Autonomous Systems that must not be traversed on the path to the next abstract node indicated in the ERO.
除外は、EROに示されている次の抽象ノードへのパスで通過してはならない明示的なノード、抽象ノード、または自律システムを示している場合があります。
Exclusions may also indicate resources (such as unnumbered interfaces, link ids, and labels) that must not be used on the path to the next abstract node indicated in the ERO.
除外は、EROに示されている次の抽象ノードへのパスで使用してはならないリソース（非仮定インターフェイス、リンクID、ラベルなど）を示している場合があります。
SRLGs may also be indicated for exclusion from the path to the next abstract node in the ERO by the inclusion of an EXRS containing an SRLG subobject. If the L bit in the SRLG subobject is zero, the resources (nodes, links, etc.) identified by the SRLG MUST NOT be used on the path to the next abstract node indicated in the ERO. If the L bit is set, the resources identified by the SRLG SHOULD be avoided.
SRLGは、SRLGサブオブジェクトを含むEXRを含めることにより、EROの次の抽象ノードへのパスから除外することも示される場合があります。SRLGサブオブジェクトのLビットがゼロの場合、SRLGによって識別されるリソース（ノード、リンクなど）は、EROに示されている次の抽象ノードへのパスで使用してはなりません。Lビットが設定されている場合、SRLGによって識別されるリソースを避ける必要があります。
If a node is called upon to process an EXRS and does not support handling of exclusions it will behave as described in [RFC3209] when an unrecognized ERO subobject is encountered. This means that this node will return a PathErr with error code "Routing Error" and error value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object included, truncated (on the left) to the offending EXRS.
ノードがEXRを処理するために呼び出され、除外の処理をサポートしない場合、認識されていないEROサブオブジェクトが発生したときに[RFC3209]に記載されているように動作します。つまり、このノードは、エラーコード「ルーティングエラー」とエラー値「bad reblicit_routeオブジェクト」を備えたpatherrを返します。
If the presence of EXRS precludes further forwarding of the Path message, the node SHOULD return a PathErr with the error code "Routing Problem" and error value "Route Blocked by Exclude Route".
EXRSの存在がパスメッセージのさらなる転送を妨げる場合、ノードはエラーコード「ルーティング問題」とエラー値「ルート」を除外したルートでブロックするパテラを返す必要があります。
A node MAY reject a Path message if the EXRS is too large or complicated for the local implementation or as governed by local policy. In this case, the node MUST send a PathErr message with the error code "Routing Error" and error value "EXRS Too Complex". An ingress LSR receiving this error code/value combination MAY reduce the complexity of the EXRS or route around the node that rejected the EXRS.
EXRが大きすぎるか複雑すぎる場合、またはローカルポリシーに準拠している場合、ノードはパスメッセージを拒否する場合があります。この場合、ノードはエラーコード「ルーティングエラー」とエラー値「EXRが複雑すぎる」を使用してPATHERRメッセージを送信する必要があります。このエラーコード/値の組み合わせを受信するIngress LSRは、EXRを拒否したノードの周りのEXRまたはルートの複雑さを軽減する場合があります。
When an LSR performs ERO expansion and finds both the XRO in the Path message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes, links, and resources listed in both places. Where some elements appear in both lists, it MUST be handled according to the stricter exclusion request. That is, if one list says that an SRLG, node, link, or resource must be excluded, and the other says only that it should be avoided, then the element MUST be excluded.
LSRがERO拡張を実行し、PATHメッセージ内のXROとEROのEXRの両方を見つけた場合、両方の場所にリストされているすべてのSRLG、ノード、リンク、およびリソースを除外する必要があります。いくつかの要素が両方のリストに表示される場合、より厳格な除外要求に従って処理する必要があります。つまり、1つのリストがSRLG、ノード、リンク、またはリソースを除外する必要があると書かれている場合、もう1つは避ける必要があると言う場合、要素を除外する必要があります。
An implementation MUST be at least compliant with the following:
実装は、少なくとも以下に準拠している必要があります。
1. The XRO MUST be supported with the following restrictions:
1. XROは、次の制限でサポートする必要があります。
- The IPv4 Prefix subobject MUST be supported with a prefix length of 32, and an attribute value of "interface" and "node". Other prefix values and attribute values MAY be supported.
- IPv4プレフィックスSubobjectは、32のプレフィックス長、および「インターフェイス」と「ノード」の属性値でサポートする必要があります。その他のプレフィックス値と属性値がサポートされる場合があります。
- The IPv6 Prefix subobject MUST be supported with a prefix length of 128, and an attribute value of "interface" and "node". Other prefix values and attribute values MAY be supported.
- IPv6プレフィックスSubobjectは、128のプレフィックス長、および「インターフェイス」と「ノード」の属性値でサポートする必要があります。その他のプレフィックス値と属性値がサポートされる場合があります。
2. The EXRS MAY be supported. If supported, the same restrictions as for the XRO apply. If not supported, an EXRS encountered during normal ERO processing MUST be rejected as an unknown ERO subobject as described in Section 4.2. Note that a node SHOULD NOT parse ahead into an ERO, and if it does, it MUST NOT reject the ERO if it discovers an EXRS that applies to another node.
2. EXRがサポートされる場合があります。サポートされている場合、XRO適用と同じ制限が適用されます。サポートされていない場合、通常のERO処理中に遭遇するEXRは、セクション4.2で説明されているように、未知のEROサブオブジェクトとして拒否されなければなりません。ノードはEROに進出してはならないことに注意してください。もしそうなら、別のノードに適用されるEXRを発見した場合、EROを拒否してはなりません。
3. If XRO or EXRS are supported, the implementation MUST be compliant with the processing rules of the supported, not supported, or partially supported subobjects as specified within this document.
3. XROまたはEXRがサポートされている場合、このドキュメント内で指定されているように、サポートされていない、サポートされていない、または部分的にサポートされているサブオブジェクトの処理ルールに実装が準拠している必要があります。
Security considerations for MPLS-TE and GMPLS signaling are covered in [RFC3209] and [RFC3473]. This document does not introduce any new messages or any substantive new processing, and so those security considerations continue to apply.
MPLS-TEおよびGMPLSシグナル伝達のセキュリティ上の考慮事項は、[RFC3209]および[RFC3473]でカバーされています。このドキュメントでは、新しいメッセージや実質的な新しい処理は導入されていないため、これらのセキュリティ上の考慮事項は引き続き適用されます。
Note that any security concerns that exist with explicit routes should be considered with regard to route exclusions. For example, some administrative boundaries may consider explicit routes to be security violations and may strip EROs from the Path messages that they process. In this case, the XRO should also be considered for removal from the Path message.
明示的なルートに存在するセキュリティの懸念は、ルート除外に関して考慮する必要があることに注意してください。たとえば、一部の管理上の境界は、明示的なルートがセキュリティ違反であることを考慮し、それらが処理するパスメッセージからエロを剥奪する場合があります。この場合、XROはパスメッセージからの削除についても考慮する必要があります。
It is possible that an arbitrarily complex XRO or EXRS sequence could be introduced as a form of denial-of-service attack since its presence will potentially cause additional processing at each node on the path of the LSP. It should be noted that such an attack assumes that an otherwise trusted LSR (i.e., one that has been authenticated by its neighbors) is misbehaving. A node that receives an XRO or EXRS sequence that it considers too complex according to its local policy may respond with a PathErr message carrying the error code "Routing Error" and error value "XRO Too Complex" or "EXRS Too Complex".
その存在がLSPのパス上の各ノードで追加の処理を引き起こす可能性があるため、任意の複雑なXROまたはEXRSシーケンスをサービス拒否攻撃の形として導入できる可能性があります。そのような攻撃は、そうでなければ信頼できるLSR（つまり、隣人によって認証されたもの）が誤動作していることを前提としていることに注意する必要があります。ローカルポリシーに応じて複雑すぎると見なすXROまたはEXRSシーケンスを受信するノードは、エラーコード「ルーティングエラー」とエラー値「XROが複雑すぎる」または「EXRSが複雑すぎる」を運ぶPatherRメッセージで応答する場合があります。
It might be considered that an alternative approach would be to assign one of the bits of the ERO subobject type field (perhaps the top bit) to identify that a subobject is intended for inclusion rather than exclusion. However, [RFC3209] states that the type field (seven bits) should be assigned as 0 - 63 through IETF consensus action, 64 - 95 as first come first served, and 96 - 127 are reserved for private use. It would not be acceptable to disrupt existing implementations, so the only option would be to split the IETF consensus range leaving only 32 subobject types. It is felt that 32 would be an unacceptably small number for future expansion of the protocol.
別のアプローチは、EROサブオブジェクト型フィールドのビットの1つ（おそらく最上部ビット）を割り当てて、サブオブジェクトが除外ではなく包含を目的としていることを特定することであると考えられるかもしれません。ただし、[RFC3209]は、タイプフィールド（7ビット）を0〜63からIETFコンセンサスアクションとして割り当てる必要があると述べています。既存の実装を破壊することは受け入れられないため、唯一のオプションは、IETFコンセンサス範囲を32のサブオブジェクトタイプのみを残して分割することです。32は、プロトコルの将来の拡大のために容認できないほど少ないと感じられています。
IANA registry: RSVP PARAMETERS Subsection: Class Names, Class Numbers, and Class Types
IANAレジストリ：RSVPパラメーターサブセクション：クラス名、クラス番号、クラスタイプ
A new subobject has been added to the existing entry for:
既存のエントリに新しいサブオブジェクトが追加されました。
20 EXPLICIT_ROUTE
20 liblicit_route
The registry reads:
レジストリは次のとおりです。
33 Explicit Exclusion Route subobject (EXRS)
33明示的な除外ルートSubobject（EXRS）
The Explicit Exclusion Route subobject (EXRS) is defined in Section 4.1, "Explicit Exclusion Route Subobject (EXRS)". This subobject may be present in the Explicit Route Object, but not in the Route Record Object or in the new EXCLUDE_ROUTE object, and it should not be listed among the subobjects for those objects.
明示的な除外ルートサブオブジェクト（EXRS）は、セクション4.1「明示的除外ルートサブオブジェクト（EXRS）」で定義されています。このサブオブジェクトは、明示的なルートオブジェクトに存在する場合がありますが、ルートレコードオブジェクトや新しいexclude_routeオブジェクトには存在しない可能性があり、それらのオブジェクトのサブオブジェクトにリストされないでください。
IANA registry: RSVP PARAMETERS Subsection: Class Names, Class Numbers, and Class Types
IANAレジストリ：RSVPパラメーターサブセクション：クラス名、クラス番号、クラスタイプ
A new class number has been added for EXCLUDE_ROUTE object (XRO) as defined in Section 3.1, "EXCLUDE_ROUTE Object (XRO)".
セクション3.1で定義されているように、exclude_routeオブジェクト（xro）の新しいクラス番号が追加されています。
EXCLUDE_ROUTE Class-Num of type 11bbbbbb Value: 232 Defined CType: 1 (EXCLUDE_ROUTE)
exclude_routeタイプ11bbbbbbb値のクラス番号：232定義ctype：1（exclude_route）
Subobjects 1, 2, 4, and 32 are as defined for Explicit Route Object. An additional subobject has been registered as requested in Section 8.1, "New ERO Subobject Type". The text should appear as:
サブオブジェクト1、2、4、および32は、明示的なルートオブジェクトに対して定義されています。セクション8.1「新しいEROサブオブジェクトタイプ」で要求されているように、追加のサブオブジェクトが登録されています。テキストは次のように表示されます。
Sub-object type
1 IPv4 address [RFC3209]
2 IPv6 address [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
33 Explicit Exclusion Route subobject (EXRS) [RFC4874]
34 SRLG [RFC4874]
The SRLG subobject is defined in Section 3.1.5, "SRLG Subobject". The value 34 has been assigned.
SRLGサブオブジェクトは、セクション3.1.5「SRLG Subobject」で定義されています。値34が割り当てられています。
IANA registry: RSVP PARAMETERS Subsection: Error Codes and Globally-Defined Error Value Sub-Codes
IANAレジストリ：RSVPパラメーターサブセクション：エラーコードとグローバルに定義されたエラー値サブコード
New Error Values sub-codes have been registered for the Error Code 'Routing Problem' (24).
新しいエラー値サブコードは、エラーコード「ルーティング問題」に登録されています（24）。
64 = Unsupported Exclude Route Subobject Type 65 = Inconsistent Subobject 66 = Local Node in Exclude Route 67 = Route Blocked by Exclude Route 68 = XRO Too Complex 69 = EXRS Too Complex
64 =サポートされていない除外ルートサブオブジェクトタイプ65 =一貫性のないサブオブジェクト66 =除外ルート67のローカルノード=除外ルート68 = XROが複雑すぎる69 = EXRが複雑すぎるルート
This document reuses text from [RFC3209] for the description of EXCLUDE_ROUTE.
このドキュメントは、exclude_routeの説明については、[rfc3209]のテキストを再利用します。
The authors would like to express their thanks to Lou Berger, Steffen Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and Richard Rabbat for their considered opinions on this document. Also thanks to Yakov Rekhter for reminding us about SRLGs!
著者は、この文書に関する考慮された意見について、ルー・ベルガー、ステフェン・ブロックマン、イゴール・ブリスキン、ディミトリ・パパディミトリウ、クリスタル・ペルバット、リチャード・ラバトに感謝したいと思います。また、SRLGについて私たちに思い出させてくれたYakov Rekhterに感謝します！
Thanks to Eric Gray for providing GenArt review and to Ross Callon for his comments.
Genart Reviewを提供してくれたEric Grayに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナルリソースリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[CRANKBACK] Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S. Marshall-Unitt, "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, January 2007.
[Crankback] Farrel、A.、Satyanarayana、A.、Iwata、A.、Ash、G。、およびS. Marshall-Unitt、「MPLSシグナル伝達のクランクバックシグナル伝達拡張」、2007年1月の作業。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）、RFC 3812、2004年6月。
[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, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4216] Zhang, R. and JP. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R。およびJP。Vasseur、「MPLS間の自律システム（AS）トラフィックエンジニアリング（TE）要件」、RFC 4216、2005年11月。
This section describes some applications that can make use of the XRO. The intention is to show that the XRO is not an application-specific object, but that it can be used for multiple purposes. In a few examples, other solutions might be possible for that particular case, but the intention is to show that a single object can be used for all the examples, hence making the XRO a rather generic object without having to define a solution and new objects for each new application.
このセクションでは、XROを使用できるアプリケーションについて説明します。意図は、XROがアプリケーション固有のオブジェクトではなく、複数の目的に使用できることを示すことです。いくつかの例では、その特定のケースで他のソリューションが可能かもしれませんが、意図はすべての例に単一のオブジェクトを使用できることを示すことです。新しいアプリケーションごとに。
One method to establish an inter-area LSP is where the ingress router selects an ABR, and then the ingress router computes a path towards this selected ABR such that the configured constraints of the LSP are fulfilled. In the example of Figure A.1, an LSP has to be established from node A in area 1 to node C in area 2. If no loose hops are configured, then the computed ERO at A could look as follows: (A1-strict, A2-strict, ABR1-strict, C-loose). When the Path message arrives at ABR1, then the ERO is (ABR1-strict, C-loose), and it can be expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). Similarly, at ABR3 the received ERO is (ABR3-strict, C-loose), and it can be expanded to (C1-strict, C2-strict, C-strict). If a backup LSP also has to be established, then A takes another ABR (ABR2 in this case) and computes a path towards this ABR that fulfills the constraints of the LSP and that is disjoint from the path of the primary LSP. The ERO generated by A looks as follows for this example: (A3-strict, A4-strict, ABR2-strict, C-loose).
エリア間LSPを確立する1つの方法は、IngressルーターがABRを選択する場所であり、Ingressルーターは、LSPの構成された制約が満たされるように、この選択したABRに向かってパスを計算します。図A.1の例では、LSPをエリア1のノードAからエリア2のノードCに確立する必要があります。ルーズホップが構成されていない場合、Aで計算されたEROは次のように見えます。、A2-STRICT、ABR1-STRICT、C-LOOSE）。パスメッセージがABR1に到着すると、EROは（ABR1-STRICT、C-LOOSE）であり、ABR1によって（B1-STRICT、ABR3-STRICT、C-LOOSE）まで拡張できます。同様に、ABR3で受信したEROは（ABR3-STRICT、C-LOOSE）であり、（C1-STRICT、C2-STRICT、C-STRICT）に拡張できます。バックアップLSPも確立する必要がある場合、Aは別のABR（この場合はABR2）を取得し、LSPの制約を満たし、プライマリLSPの経路からばらばらになるこのABRに向けて計算します。この例では、次のように外観で生成されたERO：（A3-Strict、A4-Strict、ABR2-Strict、C-Loose）。
In order to let ABR2 expand the ERO, it also needs to know the path of the primary LSP so that the ERO expansion is disjoint from the path of the primary LSP. Therefore, A also includes an XRO that at least contains (ABR1, B1, ABR3, C1, C2). Based on these constraints, ABR2 can expand the ERO such that it is disjoint from the primary LSP. In this example, the ERO computed by ABR2 would be (B2-strict, ABR4-strict, C-loose), and the XRO generated by B contains at least (ABR3, C1, C2). The latter information is needed for ABR4 to expand the ERO so that the path is disjoint from the primary LSP in area 2.
ABR2をEROに拡張させるためには、EROの拡張がプライマリLSPの経路からばらばらになるように、プライマリLSPの経路を知る必要もあります。したがって、aには、少なくとも含まれるXRO（ABR1、B1、ABR3、C1、C2）も含まれます。これらの制約に基づいて、ABR2はEROを拡張して、プライマリLSPからばらばらになります。この例では、ABR2によって計算されたEROは（B2-STRICT、ABR4-STRICT、C-LOOSE）であり、Bで生成されたXROには少なくとも（ABR3、C1、C2）が含まれます。後者の情報は、ABR4がEROを拡張するために必要であり、エリア2のプライマリLSPからパスがばらばらになるようにします。
Area 1 Area 0 Area 2
<---------------><--------------><--------------->
+---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
| | | | |
| | | | |
A | | | C
| | | | |
| | | | |
+---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
Figure A.1: Inter-area LSPs
図A.1：エリア間LSP
In this example, a node performing the path computation first selects an ABR and then computes a strict path towards this ABR. For the backup LSP, all nodes of the primary LSP in the next areas have to be put in the XRO (with the exception of the destination node if node protection and no link protection is required). When an ABR computes the next path segment, i.e., the path over the next area, it may remove the nodes from the XRO that are located in that area with the exception of the ABR where the primary LSP is exiting the area. The latter information is still required because when the selected ABR (ABR4 in this example) further expands the ERO, it has to exclude the ABR on which the primary LSP is entering that area (ABR3 in this example). This means that when ABR2 generates an XRO, it may remove the nodes in area 0 from the XRO but not ABR3. Note that not doing this would not cause harm in this example because there is no path from ABR4 to C via ABR3 in area 2. If there is a link between ABR4- ABR3 and ABR3-C, then it is required to have ABR3 in the XRO generated by ABR2.
この例では、パス計算を実行するノードが最初にABRを選択し、次にこのABRに向かって厳格なパスを計算します。バックアップLSPの場合、次の領域のプライマリLSPのすべてのノードをXROに配置する必要があります（ノード保護とリンク保護が不要な場合は宛先ノードを除きます）。ABRが次のパスセグメント、つまり次のエリアのパスを計算すると、主要なLSPがエリアを出ているABRを除き、その領域にあるXROからノードを削除する場合があります。選択したABR（この例のABR4）がEROをさらに拡張する場合、プライマリLSPがその領域に入るABRを除外する必要があるため、後者の情報が必要です。これは、ABR2がXROを生成すると、ABR3ではなくXROからエリア0のノードを削除する可能性があることを意味します。ABR4- ABR3とABR3-Cの間にリンクがある場合、ABR4からABR3を介してABR4からCへのパスがないため、この例ではこれを行わないことは、この例では害を引き起こさないことに注意してください。ABR2によって生成されたXro。
Discussion on the length of the XRO: When link or node protection is requested, the length of the XRO is bounded by the length of the RRO of the primary LSP. It can be made shorter by removing nodes by the ingress node and the ABRs. In the example above, the RRO of the primary LSP contains 8 subobjects, while the maximum XRO length can be bounded by 6 subobjects (nodes A1 and A2 do not have to be in the XRO). For SRLG protection, the XRO has to list all SRLGs that are crossed by the primary LSP.
XROの長さに関する議論：リンクまたはノード保護が要求されると、XROの長さはプライマリLSPのRROの長さによって境界を獲得します。IngressノードとABRSによってノードを削除することにより、短くすることができます。上記の例では、プライマリLSPのRROには8つのサブオブジェクトが含まれていますが、最大XROの長さは6つのサブオブジェクト（ノードA1とA2がXROである必要はありません）に境界を付けます。SRLG保護のために、XROはプライマリLSPと交差するすべてのSRLGをリストする必要があります。
When an inter-AS LSP (which has to be protected by a backup LSP to provide link or node protection) is established, the same method as for the inter-area LSP case can be used. The difference is when the backup LSP is not following the same AS-path as the primary LSP because then the XRO should always contain the full path of the primary LSP. In case the backup LSP is following the same AS-path (but with different ASBRs -- at least in case of node protection), it is similar to the inter-area case: ASBRs expanding the ERO over the next AS may remove the XRO subobjects located in that AS. Note that this can only be done by an ingress ASBR (the ASBR where the LSP is entering the AS).
LSP間（リンクまたはノード保護を提供するためにバックアップLSPによって保護する必要がある）が確立される場合、エリア間LSPの場合と同じ方法を使用できます。違いは、バックアップLSPがプライマリLSPと同じパスを追跡していない場合です。なぜなら、XROには常にプライマリLSPのフルパスが含まれている必要があるからです。バックアップLSPがパスと同じ（ただし、ASBRが異なる場合 - 少なくともノード保護の場合は異なる場合）に従う場合、それはエリア間のケースに似ています。その中にあるサブオブジェクト。これは、侵入ASBR（LSPがASに入るASBR）によってのみ行うことができることに注意してください。
Discussion on the length of the XRO: the XRO is bounded by the length of the RRO of the primary LSP.
XROの長さに関する議論：XROは、プライマリLSPのRROの長さによって制限されています。
Suppose that SRLG protection is required, and the ASs crossed by the main LSP use a consistent way of allocating SRLG-ids to the links (i.e., the ASs use a single SRLG space). In this case, the SRLG-ids of each link used by the main LSP can be recorded by means of the RRO; the SRLG-ids are then used by the XRO. If the SRLG-ids are only meaningful when local to the AS, putting SRLG-ids in the XRO crossing many ASs makes no sense. To provide SRLG protection for inter-AS LSPs the link IP address of the inter-AS link used by the primary LSP can be put into the XRO of the Path message of the detour LSP or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is entering the AS can translate this into the list of SRLG-ids known to the local AS.
SRLG保護が必要であり、メインのLSPによって交差するASSがSRLG-IDをリンクに割り当てる一貫した方法を使用していると仮定します（つまり、ASSは単一のSRLGスペースを使用します）。この場合、メインLSPで使用される各リンクのSRLG-IDは、RROによって記録できます。SRLG-IDはXROによって使用されます。SRLG-IDがASにローカルになった場合にのみ意味がある場合、XROの交差点にSRLG-IDを置くと、多くのお尻が意味がありません。inter-as lspsにSRLG保護を提供するには、プライマリLSPで使用されるリンク間ASリンクのリンクIPアドレスを迂回路LSPまたはバイパストンネルのパスメッセージのXROに配置できます。迂回路LSPまたはバイパストンネルが入力しているASBRは、これをローカルASに知られているSRLG-IDのリストに変換できます。
Discussion on the length of the XRO: the XRO only contains 1 subobject, which contains the IP address of the inter-AS link traversed by the primary LSP (assuming that the primary LSP and detour LSP or bypass tunnel are leaving the AS in the same area, and that they are also entering the next AS in the same area).
Xro：XROの長さに関する議論には、一次LSPによってトラバースされたリンク間リンクのIPアドレスが含まれる1つのサブオブジェクトのみが含まれています（プライマリLSPと迂回LSPまたはバイパストンネルが同じようにASを離れていると仮定しますエリア、そして彼らも同じ領域のように次に入っていること。
When an edge-node wants to establish an LSP towards another edge-node over an optical core network as described in [RFC4208] (see Figure A.2), the XRO can be used for multiple purposes.
[RFC4208]で説明されているように、エッジノードが別のエッジノードに向かって別のエッジノードに向けてLSPを確立したい場合（図A.2を参照）、XROは複数の目的に使用できます。
Overlay Overlay
Network +--------------------------------+ Network
+----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | | | | |
+----------+ | | | | | | | +----------+
| | | | | | |
+----------+ | | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | | |
| +----+ | | | | | +------+ | | | | +----+ |
| | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | |
| --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +--------------------------------+ | |
+----------+ Core Network +----------+
Overlay Overlay
Network Network
Legend: EN - Edge-Node CN - Core-Node
凡例：EN -Edge -Node CN -Core -Node
Figure A.2
図A.2
A first application is where an edge-node wants to establish multiple LSPs towards the same destination edge-node, and these LSPs need to have few or no SRLGs in common. In this case EN1 could establish an LSP towards EN3, and then it can establish a second LSP listing all links used by the first LSP with the indication to avoid the SRLGs of these links. This information can be used by CN1 to compute a path for the second LSP. If the core network consists of multiple areas, then the SRLG-ids have to be listed in the XRO. The same example applies to nodes and links.
最初のアプリケーションは、エッジノードが同じ宛先エッジノードに向けて複数のLSPを確立したい場合であり、これらのLSPには共通のSRLGが少ないか、まったくない必要があります。この場合、EN1はEN3に向かってLSPを確立することができ、次に、これらのリンクのSRLGを避けるために、最初のLSPが使用するすべてのリンクを示すすべてのリンクをリストする2番目のLSPを確立できます。この情報は、CN1が2番目のLSPのパスを計算するために使用できます。コアネットワークが複数の領域で構成されている場合、SRLG-IDをXROにリストする必要があります。同じ例がノードとリンクにも当てはまります。
Another application is where the edge-node wants to set up a backup LSP that is also protecting the links between the edge-nodes and core-nodes. For instance, when EN2 establishes an LSP to EN4, it sends a Path message to CN4, which computes a path towards EN4 over (for instance) CN5. When EN2 gets back the RRO of that LSP, it can signal a new LSP to CN1 with EN4 as the destination and the XRO computed based on the RRO of the first LSP. Based on this information, CN1 can compute a path that has the requested diversity properties (e.g., a path going over CN2 and CN3, and then to EN4).
別のアプリケーションは、エッジノードがバックアップLSPをセットアップしたい場合です。これは、エッジノードとコアノードの間のリンクも保護しています。たとえば、EN2がLSPからEN4を確立すると、CN4にパスメッセージを送信します。これは、（たとえば）CN5に向かうパスを計算します。EN2がそのLSPのRROを取り戻すと、宛先としてEN4を使用してCN1に新しいLSPを信号し、最初のLSPのRROに基づいてXROを計算できます。この情報に基づいて、CN1は、要求された多様性プロパティを持つパス（たとえば、CN2とCN3を介して、EN4へのパス）を計算できます。
It is clear that in these examples, the core-node may not alter the RRO in a Resv message to make its only contents be the subobjects from the egress core-node through the egress edge-node.
これらの例では、コアノードはRESVメッセージのRROを変更して、その唯一の内容が出口コアノードから出口エッジノードを介してサブオブジェクトになるようにすることが明らかです。
The XRO can also be used inside a single area. Take for instance a network where the TE extensions of the IGPs as described in [RFC3630] and [RFC3784] are not used. Hence, each node has to select a next-hop and possibly crankback [CRANKBACK] has to be used when there is no viable next-hop. In this case, when signaling a backup LSP, the XRO can be put in the Path message to exclude the links, nodes, or SRLGs of the primary LSP. An alternative way to provide this functionality would be to indicate the following in the Path message of the backup LSP: the primary LSP and which type of protection is required. This latter solution would work for link and node protection, but not for SRLG protection.
XROは、単一の領域内でも使用できます。たとえば、[RFC3630]および[RFC3784]で説明されているIGPSのTE拡張機能が使用されないネットワークを考えてみましょう。したがって、各ノードは次のホップを選択する必要があり、おそらくクランクバック[クランクバック]を使用する必要がある場合は使用する必要があります。この場合、バックアップLSPを信号する場合、XROをパスメッセージに配置して、プライマリLSPのリンク、ノード、またはSRLGを除外できます。この機能を提供する別の方法は、バックアップLSPのパスメッセージで次のことを示すことです：プライマリLSPとどのタイプの保護が必要か。この後者のソリューションは、リンクとノード保護のために機能しますが、SRLG保護には機能しません。
When link or node protection is requested, the XRO is of the same length as the RRO of the primary LSP. For SRLG protection, the XRO has to list all SRLGs that are crossed by the primary LSP. Note that for SRLG protection, the link IP address to reference the SRLGs of that link cannot be used since the TE extensions of the IGPs are not used in this example. Hence, a node cannot translate any link IP address located in that area to its SRLGs.
リンクまたはノード保護が要求される場合、XROはプライマリLSPのRROと同じ長さです。SRLG保護のために、XROはプライマリLSPと交差するすべてのSRLGをリストする必要があります。SRLG保護の場合、IGPSのTE拡張機能がこの例では使用されていないため、そのリンクのSRLGを参照するリンクIPアドレスは使用できないことに注意してください。したがって、ノードは、その領域にあるリンクIPアドレスをSRLGに変換することはできません。
Authors' Addresses
著者のアドレス
Cheng-Yin Lee EMail: c.yin.lee@gmail.com
Cheng-Yin Leeメール：c.yin.lee@gmail.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consulting電話：44（0）1978 860944メール：adrian@olddog.co.uk
Stefaan De Cnodder Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel-lucent.be
Stefaan de Cnodder Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerp Belgium電話：32 3 240 85 15メール：stefaan.de_cnodder@alcatel-lucent.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。