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)
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）IETFトラスト（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する"-TEをRSVPする（RFC 3209）とGMPLS拡張、「一般化されたマルチプロトコルラベルスイッチング（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つの抽象ノードの間の経路の部分に適用することができます。どのように共有リスクリンクグループ（SRLGs）除外することができることも、この文書で指定されています。
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).
RSVP-TE仕様[RFC3209]とGMPLS拡張[RFC3473]は抽象ノードとリソースを明示的に明示的ルート・オブジェクト（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.
例えば、経路の排除は、二つの非重複ラベルパス（LSPの）必要とされるスイッチド場合に使用することができます。この場合、一つの選択肢は一つのパスを設定し、ルートの記録を使用して、そのルートを収集し、次いで第2のパスの設定からその第一の経路上のルータを除外するためにあるかもしれません。別のオプションは、両方のバックボーンに二つの平行なバックボーン、デュアルホームプロバイダーエッジ（PE）ルータを設定した後、（特に遠方のPEに）あなたがLSPを設定し、初めてAバックボーン上でローカルルータを除外するかもしれませんあなたがLSPを設定する第二の時間Bのバックボーン上でローカルルータを除外する。
Two types of exclusions are required:
除外の二つのタイプが必要です。
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.
EROに存在する抽象ノードの特定の対の間の特定の抽象ノードまたはリソースの2排除。このような特定の除外は、明示的な排除経路と呼ばれます。
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.
- 除外の第二のタイプは、既存の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]で定義されるようSRLGsの知識は、保護のために使用することができる多様な経路を計算するために使用することができます。除外をシグナリングすることが有用であるシステムでは、パス全体にまたは明示的なパスで指定された2つの抽象ノード間で除外されるべきリソースのグループを示すためにSRLGsをシグナリングすることが有用であり得ます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
この文書では、任意のノードまたは回避するために、ネットワーク要素をリストからのルートの除外を排除するものではありません。その意図は、明示的に避けるべきサブオブジェクトの唯一の最小数を示すために、しかし、です。例えば、回避するだけSRLGs（または共有リスク・リンク・グループ）をシグナリングする必要があるかもしれません。すなわち、ルートの除外は、各ホップで除外する選択肢のすべてをリストすることによって、実際のルートを定義することを意図していない、である、むしろ緩いホップまたは抽象ノードに特定の要素を列挙することによって拡張される通常の経路選択プロセスを制約します避けること。
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センスエリアであってもよいし、能動管理および経路計算の目的のためにネットワークの任意の分割であってもよいです。プライマリパスは（入力、A1、A2、AB1、B1、B2、BC1、C1、C2、出力）とします。
- 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内のノードであり、および出力これは、ドメインが領域に対応し、図1に示されている領域Cのノードであることに留意されたいです。
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の除外は、入口で制約付き最短パス優先（CSPF）計算中に処理するので、EROおよびXROが入口でシグナリングされる、（A3-厳密、A4-厳密、AB2、厳密、退出-緩い）であると（AB1ができB1、B2、BC1、C1、C2）、それぞれ。 AB2に、EROおよびXROは、それぞれ、（B3-厳密、B4-厳密、BC2、厳密、退出-ルーズ）及び（BC1、C1、C2）とすることができます。 BC2に、EROは、（C3-厳密、C4-厳密、退出-厳密）とすることができ、XROは以降BC2から必要とされません。
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は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
クラス= 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オブジェクトの内容は、サブオブジェクトと呼ばれる可変長のデータ項目のシリーズです。ルートの除外での使用のために[RFC3209]、[RFC3473]及び[RFC3477]で定義されるように、本明細書は、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
緩んでいるか、厳密なホップのコンセプトは、ルートの除外では意味がありません。 [RFC3209]でEROサブオブジェクトに対して定義されたLビットが、抽象ノードは排除しなければならないことを示すために、ここで再利用される（値
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.
0）または（値1を避けるべきです）。区別は、LSPの経路がLビットクリアとXROに記載されている抽象ノードを横断してはならないが、Lビットが設定されたものを横断することができるということです。 （例えば、ルーズホップを拡張するため）LSPルーティングを担当するノードは、ローカルポリシーに従ってLSPによって横断されるLビットの組とXROに記載されている抽象ノードの数を最小限にしようとすべきです。 Lビットセットと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は、インターフェイスに関連付けられたすべてのSRLGsパスから除外されることを可能にします。
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プレフィックスに関連付けられているすべてのSRLGsが除外または避けるべきであることを示している値。
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プレフィックスに関連付けられているすべてのSRLGsが除外または避けるべきであることを示しています。
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は、インターフェイスに関連付けられているすべてのSRLGsが除外または避けるべきであることを示しています。
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]で定義される通りです。定義された属性のオクテットはありません。
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を回避する必要があることを示し、指定SRLGは1を排除しなければならないことを示しています
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.
各抽象ノードは、ノード、もしくはノードのグループ、自律システム、またはSRLGのインターフェースを識別するプレフィックスを持つIPアドレスに属する正確に指定された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".
Pathメッセージをノードで受信されると1、ノードは、Pathメッセージ中に存在する場合、それはXROにおける抽象ノードのいずれかのメンバーではないことをチェックしなければなりません。ノードが「除外」に設定LフラグとXROにおける抽象ノードのいずれかのメンバーである場合、それは「ルートを除外におけるローカルノード」エラーコード「ルーティング問題」との誤差値とのPathErrを返すべき。 SRLGsがXROである場合、ノードは、リソースは、ノードが使用するXROに指定されていることを「除外」に設定L-フラグを持つすべての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のプレフィックスのサブオブジェクトは、「インタフェース」または「SRLG」に設定されています。
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内のサブオブジェクトは、互いに矛盾しない（SHOULD NOT）。 Pathメッセージは、その後、矛盾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.
- LフラグがセットされていないとXROにおけるサブオブジェクト（ゼロ）EROにおけるサブオブジェクトに優先しなければならない - つまり、必須の除外はXROで発現が優先されなければならないと実装は、Pathメッセージを拒絶しなければなりません。これは、「除外ルートによってブロックされたルート」のエラーコード「ルーティングの問題」との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サブオブジェクトよりも優先していない - つまり、実装があるため、このような矛盾のパスメッセージを拒否することを選ぶかもしれ、しかし（XROサブオブジェクトを無視し続けるとLSPを設定することもできそれは）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-フラグを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フラグを導入SRLGsの数が最小化されるべきです。
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".
これらのルールは、Pathメッセージのさらなる転送を排除した場合、ノードは、エラーコード「ルーティング問題」と「ルートを除外することによってブロックされたルート」のエラー値との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を搬送するPathメッセージを受信したノードは、メッセージを拒否するかもしれません。この場合、ノードは、エラーコード「ルーティングエラー」とエラー値「あまりに複雑XRO」とのPathErrメッセージを送らなければなりません。このエラーコード/値の組み合わせを受け取る入口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
フォワードXROをサポートしないノードは、それが未検査及び上記ERO処理への拡張を適用しないようにXROクラス-numがフォーム11bbbbbbです。このアプローチは、ルートの除外は、新しい機能を解析または処理することができないネットワークの部分を通過することを可能にするように選択されます。ご了承ください
Record Route may be used to allow computing nodes to observe violations of route exclusion and attempt to re-route the LSP accordingly.
レコードルートは、コンピューティングノードがルート除外の違反を観察し、それに応じて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ではなく、特定のサブオブジェクトまたは一部をサポートしている場合は、その特定のサブオブジェクトは無視されます。サポートすることができるサブオブジェクトの一部の例は、サポートされていることができるIPv4のプレフィックスのサブオブジェクトの（1）のみプレフィックス32、または（2）特定のサブオブジェクトがサポートされなく、特定の属性フィールド。
When a node forwards a Path message, it can do the following three operations related to XRO besides the processing rules mentioned above:
ノードは、Pathメッセージを転送するとき、それは、上述した処理ルール以外XROに関連する以下の3つの操作を行うことができます。
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は、Pathメッセージから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.
XROが存在した場合は3、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）はEXRSがEROサブオブジェクトでありXROは、EXRSはXROに存在してはならないEROサブオブジェクトを再利用しているが33を入力しています。 EXRSはEXRSサブオブジェクトと呼ばれる、独自のの一つ以上のサブオブジェクトが含まれている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でサブオブジェクトのフォーマットと全く同じです。 EXRSはXROのため、この文書で定義されたすべてのサブオブジェクトを含むことができます。
Thus, an EXRS for an IP hop may look as follows:
次のようにこのように、IPホップのための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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
各EXRSは、複数の除外を運ぶことができます。除外は、正確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サブオブジェクトとの間のステップです。 EXRSの処理ルールは、この範囲内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.
SRLGsもSRLGサブオブジェクトを含むEXRSを含めることによって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.
ノードはEXRSを処理するために呼び出され、除外の取扱いをサポートしていない場合は、[RFC3209]で説明したように認識されていないEROサブオブジェクトに遭遇した場合、それが動作します。これは、含まれ、このノードが問題のEXRSに（左に）切り捨て、EXPLICIT_ROUTEオブジェクトにエラーコード「ルーティングエラー」とエラー値「悪いEXPLICIT_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の存在は、Pathメッセージのさらなる転送を妨げる場合、ノードは、エラーコード「ルーティング問題」と「ルートを除外することによってブロックされたルート」のエラー値とのPathErrを返すべきです。
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.
EXRSが大きすぎるか、またはローカル実装の複雑またはローカルポリシーによって支配されるようであれば、ノードは、Pathメッセージを拒絶するかもしれません。この場合、ノードは、「あまりにも複雑EXRS」エラーコード「ルーティングエラー」と誤差値とのPathErrメッセージを送らなければなりません。このエラーコード/値の組み合わせを受け取る入口LSRはEXRSを拒否したノードの周りEXRS又は経路の複雑さを低減することができます。
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の拡張を実行し、EROでPathメッセージとEXRSでXROの両方を見つけると、それは両方の場所に記載されているすべてのSRLGs、ノード、リンク、およびリソースを除外する必要があります。いくつかの要素が両方のリストに表示された場合、それは厳しい排他要求に応じて処理しなければなりません。 1つのリストはSRLG、ノード、リンク、またはリソースが除外されなければならないことを述べている場合には、であり、他方は、それは、避けるべきで、その要素は排除しなければならない唯一のことを言います。
An implementation MUST be at least compliant with the following:
実装には、次のと少なくとも準拠している必要があります：
- 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のプレフィックスのサブオブジェクト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プレフィックスサブオブジェクト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. EXRSをサポートすることができます。サポートされている場合、XROと同じ制限が適用されます。サポートされていない場合は、セクション4.2で説明したように、EXRSは、通常のERO処理中に発生した未知のEROサブオブジェクトとして拒絶しなければなりません。ノードはEROに先に解析してはならないことに注意してください、そしてそれがない場合、それは別のノードに適用されるEXRSを発見した場合、それは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又はEXRSがサポートされている場合、実装は、サポートされている、サポートされている、または本文書内に指定されるように、部分的にサブオブジェクトをサポートしていないの処理ルールに準拠していなければなりません。
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.
明示的なルートで存在するすべてのセキュリティ上の懸念がルートの除外に関して考慮されるべきであることに注意してください。例えば、いくつかの管理境界は、セキュリティ違反であることを明示的なルートを検討することと、彼らが処理Pathメッセージからエロスを取り除くことがあります。この場合、XROもPathメッセージからの除去を考慮すべきです。
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を受信するか、エラーコード「ルーティングエラー」とエラー値「あまりに複雑XRO」または「あまりに複雑EXRS」を運ぶのPathErrメッセージで応答することができるそのローカルポリシーに従って、複雑すぎると考えて配列をEXRSノード。
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つを割り当てることであろうと考えられるかもしれません。配信、および96第最初に来るように95 - - 127は、私的使用のために予約されているIETFコンセンサス作用を介して63、64 - ただし、[RFC3209]はタイプフィールド（7ビット）が0として割り当てられるべきであると述べています。唯一のオプションは、32サブオブジェクトタイプを残すIETFコンセンサス範囲を分割することですので、既存の実装を混乱させることは受け入れられないでしょう。なお、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 EXPLICIT_ROUTE
The registry reads:
レジストリを読み取ります：
33 Explicit Exclusion Route subobject (EXRS)
33明示的な除外ルートサブオブジェクト（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）「が明示的除外ルートサブオブジェクト（EXRS）」、セクション4.1で定義されています。このサブオブジェクトは、明示的経路オブジェクトではなく、ルートレコードオブジェクトまたは新しい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)".
新しいクラス番号が「EXCLUDE_ROUTEオブジェクト（XRO）」、セクション3.1で定義されるようEXCLUDE_ROUTEオブジェクト（XRO）に追加されました。
EXCLUDE_ROUTE Class-Num of type 11bbbbbb Value: 232 Defined CType: 1 (EXCLUDE_ROUTE)
232定義ctype関数：1（EXCLUDE_ROUTE）型11bbbbbb値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]
サブオブジェクトタイプ1のIPv4アドレス[RFC3209] 2つのIPv6アドレス[RFC3209] 4アンナンバードインターフェイスID [RFC3477] 32自律システム番号[RFC3209] 33明示的な除外ルートサブオブジェクト（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サブオブジェクト」で定義されています。値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 =サポートされていないルート67 =ルートが複雑すぎる69 = EXRSすぎるコンプレックスを国道68 = XROを除外することによってブロックされた除外にルートサブオブジェクトタイプ65 =矛盾したサブオブジェクト66 =ローカル・ノードを除外
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!
作者はこのドキュメントの彼らの考えられて意見をルー・バーガー、ステファンブロックマン、イゴールBryskin、ディミトリPapadimitriou、Cristel Pelsser、そしてリチャードRabbatへの感謝の意を表したいと思います。またSRLGsについてを思い出させためのヤコフ・レックターに感謝！
Thanks to Eric Gray for providing GenArt review and to Ross Callon for his comments.
彼のコメントのためのGenArtのレビューを提供するためとロスCallonにエリック・グレイに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[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、RFC 4202、2005年10月 "一般化マルチプロトコルラベルスイッチング（GMPLS）の支援でルーティング拡張機能"。
[CRANKBACK] Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S. Marshall-Unitt, "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, January 2007.
[クランクバック]ファレル、A.、Satyanarayana、A.、岩田、A.、アッシュ、G.、およびS.マーシャル-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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、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]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（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]ツバメ、G.、ドレイク、J.、石松、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]張、R.及びJP。 Vasseur、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
Appendix A. Applications
付録A.アプリケーション
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は、アプリケーション固有のオブジェクトではありませんが、それは複数の目的のために使用することができるということを示すことです。いくつかの例では、他のソリューションは、その特定のケースのために可能かもしれないが、その意図は、単一のオブジェクトが溶液と新しいオブジェクトを定義することなくXROにかなり一般的なオブジェクトを作成するため、全ての実施例のために使用することができることを示すことですそれぞれの新しいアプリケーションのために。
A.1. Inter-Area LSP Protection
A.1。エリア間LSP保護
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).
入口ルータがABRを選択し、次いで、入口ルータがLSPの構成制約が満たされるように、この選択されたABRに向かってパスを計算する場合エリア間LSPを確立するための一つの方法です。 （A1-厳密：図A.1の例では、LSPは、不良ホップは、設定されていない場合のように見える可能性がAで計算EROが以下の領域2のノードCに領域1に、ノードAから確立されなければなりません、A2-厳密、ABR1-厳密、C-緩いです）。 PathメッセージがABR1に到着すると、次いで、EROは（ABR1-厳密、C-緩い）であり、（B1-厳密、ABR3-厳密、C-ルーズ）にABR1によって拡張することができます。同様に、ABR3で受信EROは（ABR3-厳密、C-緩い）であり、（C1-厳密、C2-厳密、C-厳密）に拡張することができます。バックアップLSPも確立されなければならない場合には、Aは、（この場合はABR2）別のABRをとり、LSPの制約を満たし、このABR向かってパスを計算し、それが一次LSPの経路からばらばらです。 （A3-厳密、A4-厳密、ABR2-厳密、C-ルーズ）：この例では次のようにAによって生成されたEROが見えます。
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は、少なくとも（ABR1、B1、ABR3、C1、C2）を含むことXROを含みます。これらの制約に基づいて、ABR2は、それが主LSPから互いに素であるように、EROを拡張することができます。この例では、ABR2によって計算EROは、（B2-厳密には、ABR4-厳密には、C-ルーズ）、及びBによって生成XROは、少なくとも（ABR3、C1、C2）を含むであろう。後者の情報は、パスが領域2における一次LSPから互いに素になるようにEROを拡大するABR4ために必要とされます。
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は、その領域（この例ではABR3）を入力されたABRを排除しなければならないので、後者の情報が依然として必要とされています。これはABR2はXROを生成するとき、それはABR3 XROからエリア0でなく、ノードを削除してもよいことを意味します。エリア2でABR3を経由してCへABR4からパスがないのでABR4- ABR3とABR3-Cとの間のリンクがある場合は、これをやっていないことは、この例では害を起こさないことに注意してください、でABR3であることが要求されます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の長さによって制限されます。これは、入口ノードとのABRによってノードを削除することによって短くすることができます。最大XRO長は6つのサブオブジェクト（A1とA2はXROである必要はないノード）で囲ますることができるが、上記の例では、一次LSPのRROは、8つのサブオブジェクトが含まれています。 SRLG保護のため、XROは、プライマリLSPが通過するすべてのSRLGsを一覧表示することがあります。
A.2. Inter-AS LSP Protection
A.2。インターAS LSP保護
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によって保護されなければならない）AS間LSPが確立されると、エリア間のLSPの場合と同様の方法を用いることができます。その後、XROは常にプライマリLSPの完全なパスを含まなければならないため、バックアップLSPがプライマリLSPと同じASパスを、次のされていない場合に違いがあります。場合にバックアップLSPは、次されているのと同じASパス（異なるのASBRと - 少なくともノード保護の場合）、それはエリア間の場合と同様である：XROを除去することができる次のAS上EROを拡大するのASBRそのASにあるサブオブジェクト。これは入口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が交差お尻リンク（すなわち、お尻単一SRLG空間を使用）にSRLG-IDを割り当てる一貫した方法を使用すると仮定する。この場合、メインLSPによって使用される各リンクのSRLG-IDは、RROを用いて記録することができます。 SRLG-IDは、その後XROで使用されています。 XROにSRLG-idを入れたときにASにローカル、SRLG-IDSだけ意味がある場合は、多くのASを横断しても意味がありません。 AS間のLSPのプライマリLSPによって使用されるAS間リンクのリンクIPアドレスをSRLGの保護を提供するために迂回LSPまたはバイパストンネルのPathメッセージのXROに入れることができます。迂回LSPまたはバイパストンネルがASに入っている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と迂回LSPまたはバイパストンネルが同じのように残していると仮定し、一次LSPによって横断AS間リンクのIPアドレスを含む1つのサブオブジェクトが含まれエリア、そして彼らも）同じ領域に次のASに入っていること。
A.3. Protection in the GMPLS Overlay Model
A.3。 GMPLSオーバレイモデルで保護
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を確立したい場合、XROは複数の目的に使用することができる（図A.2を参照）。
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 - エッジノードCN - コアノード
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は、一般的にいくつかまたは全くSRLGsを有する必要があります。この場合、EN1は、EN3へのLSPを確立することができ、そしてそれは、これらのリンクのSRLGsを避けるために、表示との最初のLSPによって使用されるすべてのリンクを一覧表示する第二LSPを確立することができます。この情報は、第2のLSPのためのパスを計算するためにCN1によって使用することができます。コアネットワークは、複数の領域で構成されている場合は、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がEN4にLSPを確立するとき、それは（例えば）CN5上EN4に向かってパスを計算CN4にPathメッセージを送信します。 EN2は、そのLSPのRROをバック取得すると、それは宛先としてEN4及び第LSPのRROに基づいて計算XROとCN1に新しいLSPをシグナリングすることができます。この情報に基づいて、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を変化させてもよいことは明らかです。
A.4. LSP Protection inside a Single Area
A.4。シングルエリア内のLSP保護
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]に記載されているようのIGPのTE拡張が使用されていないネットワークを取ります。したがって、各ノードは、次ホップとを選択しなければならない可能性がクランクバック【クランクバック】なし生存ネクストホップが存在しない場合に使用しなければなりません。バックアップLSPをシグナリングする場合この場合、XROは、一次LSPのリンク、ノード、またはSRLGsを除外するPathメッセージに入れることができます。この機能を提供する別の方法は、バックアップLSPのPathメッセージに次のように示すために、次のようになります。保護の主要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が通過するすべてのSRLGsを一覧表示することがあります。 IGPのTE拡張がこの例で使用されていないので、SRLGの保護のために、そのリンクのSRLGsを参照するリンクのIPアドレスが使用できないことに注意してください。したがって、ノードは、そのSRLGsにその領域に配置された任意のリンクのIPアドレスを変換することはできません。
Authors' Addresses
著者のアドレス
Cheng-Yin Lee EMail: c.yin.lee@gmail.com
.Lee @ Gmail.comの結果から、チェン観音リーメール:.
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティング電話：+44（0）1978 860944 Eメール：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デCnodderアルカテル・ルーセントCopernicuslaan 50 B-2018アントワープ、ベルギー電話：+32 3 240 85 15 Eメール：stefaan.de_cnodder@alcatel-lucent.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。