RFC4874 日本語訳
4874 Exclude Routes - Extension to Resource ReserVationProtocol-Traffic Engineering (RSVP-TE). CY. Lee, A. Farrel, S. DeCnodder. April 2007. (Format: TXT=59569 bytes) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループCYをネットワークでつないでください。 コメントを求めるリーRequest: 4874のA.ファレルアップデート: 3209、3473の古い犬のコンサルティングカテゴリ: 2007年4月にアルカテル透明な標準化過程S.De Cnodder
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).
このドキュメントは経路セットアップの間にResource ReserVationプロトコルトラフィックEngineering(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 TunnelsのためのRSVPへの拡大」(RFC3209)とRSVP-TEへのGMPLS拡張子、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」(RFC3473)は明らかに除かれるのではなく、経路セットアップで抽象的なノードとリソースを明らかに含めさせます。
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つの抽象的なノードの間の経路の地域に適用されるかもしれません。 また、どう、Shared Risk Link Groups(SRLGs)を除くことができるかは本書では指定されます。
Lee, et al. Standards Track [Page 1] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[1ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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
1. 序論…3 1.1. 要件記法…4 1.2. 見る、ルートを除いてください…4 1.3. MPLS Te MIBとの関係…5 2. 共有されたリスクはグループをリンクします…6 2.1. SRLG Subobject…6 3. ルートリストを除いてください…7 3.1. _ルートオブジェクト(XRO)を除いてください…7 3.1.1. IPv4はSubobjectを前に置きます…8 3.1.2. IPv6はSubobjectを前に置きます…9 3.1.3. 無数のインタフェースID Subobject…10 3.1.4. 自律システム番号Subobject…10 3.1.5. SRLG Subobject…11 3.2. 処理が統治する、_ルートオブジェクト(XRO)を除いてください…11 4. 明白な除外ルート…13 4.1. 明白な除外ルートSubobject(EXRS)…13 4.2. 明白な除外のための処理規則はSubobject(EXRS)を発送します…15 5. EXRSに伴うXROの処理…16 6. 最小の承諾…16 7. セキュリティ問題…16 8. IANA問題…17 8.1. 新しいERO Subobjectはタイプします…17 8.2. 新しいRSVP-Teクラス番号…18 8.3. 新しいエラーコード…18 9. 承認…19 10. 参照…19 10.1. 標準の参照…19 10.2. 有益な参照…19 付録A.アプリケーション…21 A.1。 相互領域LSP保護…21 A.2。 相互、LSP保護…22 A.3。 GMPLSでの保護はモデルをかぶせました…24 A.4。 ただ一つの領域の中のLSP保護…25
Lee, et al. Standards Track [Page 2] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[2ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
1. Introduction
1. 序論
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]で抽象的なノードとリソースは経路セットアップが明らかに包含します、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非重なっているLabel Switched Paths(LSPs)が必要である場合にルート除外を使用できました。 この場合、1つのオプションは、1つの経路をセットアップして、ルート録音を使用することでルートを集めて、そして、2番目の経路のためのセットアップにその最初の経路のルータを入れないようにすることであるかもしれません。 別のオプションはバックボーンとその時の両方へのプロバイダー縁(PE)のルータが2つの平行なバックボーン、二元的なホームを設立するために、あなたがLSP(特定の遠方のPEへの)をセットアップする1回目にバックボーンAでローカルルータを除いて、あなたが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. 全体の経路に関する、ある抽象的なノードかリソースの除外。 このセットの抽象的なノードはExclude Routeリストと呼ばれます。
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の現在の抽象的なノードの特定の組の間のある抽象的なノードかリソースの除外。 そのような特定の除外はExplicit Exclusion Routeと呼ばれます。
To convey these constructs within the signaling protocol, a new RSVP object and a new ERO subobject are introduced respectively.
シグナリングプロトコルの中をこれらの構造物を運ぶために、それぞれ新しいRSVPオブジェクトと新しいERO subobjectを導入します。
- A new RSVP-TE object is introduced to convey the Exclude Route
list. This object is the EXCLUDE_ROUTE object (XRO).
- Exclude Routeリストを伝えるために新しい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への変更で達成されます。 Explicit Exclusion Route Subobject(EXRS)が取り入れられる新しいERO subobjectタイプは1組の含まれている抽象的なノードの間の除外を示します。
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
[RFC4216]で定義されるSRLGsに関する知識は、保護に使用できるさまざまの経路を計算するのに使用されるかもしれません。 除外に合図するのが役に立つシステムでは、それが除かれるべきであるリソースのグループを示すようにSRLGsに合図するのは役に立つかもしれません。
Lee, et al. Standards Track [Page 3] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[3ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
whole path or between two abstract nodes specified in an explicit path.
経路か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を示すために「副-オブジェクト」を導入します。 このドキュメントは、この「副-オブジェクト」のためにいかなる他の用法も仮定もしませんし、排除もしません。 また、Explicit Routeオブジェクト(ERO)かRecord Routeオブジェクト(RRO)の中の使用に、この「副-オブジェクト」も適切であるかもしれませんが、このドキュメントの範囲の外にこれはあります。
1.1. Requirements Notation
1.1. 要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Scope of Exclude Routes
1.2. 見る、ルートを除いてください。
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(または、Shared Risk Link Groups)だけが避けると合図するのに必要であるかもしれません。 すなわち、各ホップで除くために選択のすべてを記載することによって実際のルートを定義することを意図するのではなく、ルート除外は、むしろノーマルルート選択プロセスを抑制するために避けられるためにある要素を記載することによって広げられるところでゆるいホップか抽象的なノードがことである意図します。
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、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.
IngressがドメインAのノードであり、EgressがC.Thisがドメインが領域に対応する図1で案内されるドメインのノードであることに注意してください。
Lee, et al. Standards Track [Page 4] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[4ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
area A area B area C
<-------------------> <----------------> <------------------>
領域のA領域のB地域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)
イングレス-----A1----A2----AB1----B1----B2----BC1----C1----C2----出口^ \/| \ / | \ / | \ / | \ / | \ / | A3----------A4--AB2--B3--------B4--BC2--C3----------C4| ^ ^ | | | | | | | | ERO: (C3厳しくて、C4厳しい、|、|、出口厳しい、) | | XRO: 必要ではありません。| | | ERO: (ゆるいB3厳しくて、B4厳しくて、BC2厳しい出口) | XRO: (BC1、C1、C2) | ERO: (ゆるいA3厳しくて、A4厳しくて、AB2厳しい出口) XRO: (AB1、B1、B2、BC1、C1、C2、出口)
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.
ノードさまざまの保護経路の例への設立が上であると考えてください。 保護経路はプライマリ経路のすべてのノードを避けなければなりません。 したがって、Ingressで合図されたEROとXROはそれぞれ領域Aのための除外がConstrained Shortest Path First(CSPF)計算の間、Ingressで扱われて、(ゆるいA3厳しくて、A4厳しくて、AB2厳しいEgress)と(AB1、B1、B2、BC1、C1、C2)であるかもしれません。 AB2では、EROとXROはそれぞれ(ゆるいB3厳しくて、B4厳しくて、BC2厳しいEgress)と(BC1、C1、C2)であるかもしれません。 BC2では、EROはことであるかもしれません(C3厳しくて、C4厳しくて、Egress厳しい)、そして、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.
一般に、考慮SHOULD、合図されたデータのサイズとシグナリングプロトコルの影響に与えてください(明白なルートのように)。
1.3. Relationship to MPLS TE MIB
1.3. MPLS Te MIBとの関係
[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]に含まれているのは、特定のLSPsにおける使用のための明白なルートを構成する手段です。 この構成はあるリソースの除外を許します。
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.
完全な明白な経路がイングレス(またはイングレスにおける使用のための経路計算サイトで)で計算されないシステムでは、それらの除外に合図するのが必要であるかもしれません。 このドキュメントはこのシグナリングをする手段を提供します。
Lee, et al. Standards Track [Page 5] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[5ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
2. Shared Risk Link Groups
2. 共有されたリスクリンク群
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 subobjectを導入します。 このドキュメントは、この「副-オブジェクト」のためにいかなる他の用法も仮定もしませんし、排除もしません。 また、Explicit Routeオブジェクト(ERO)かRecord Routeオブジェクト(RRO)の中の使用に、この「副-オブジェクト」も適切であるかもしれませんが、このドキュメントの範囲の外にこれはあります。
2.1. SRLG Subobject
2.1. SRLG Subobject
The new SRLG subobject is defined by this document as follows. Its format is modeled on the ERO subobjects defined in [RFC3209].
新しいSRLG subobjectは以下のこのドキュメントによって定義されます。 [RFC3209]で定義されたERO subobjectsは形式に似せられます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| SRLG Id(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLGイド(続けられています)| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はゼロに用意ができて、無視されたSHOULDに噛み付きました。
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.
長さ、LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつもLengthは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.
予約されたThis分野は予約されています。 それ、SHOULDはトランスミッションのときにゼロに用意ができて、領収書の上で無視しなければなりません。
Lee, et al. Standards Track [Page 6] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[6ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
3. Exclude Route List
3. ルートリストを除いてください。
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の経路に沿って横断されるべきでない抽象的なノードのリストを特定します。 それがRECOMMENDEDである、それ、サイズ、ノードの起因するのに値に地方で制限されていて、ルートリストを除いてください、ルートリストを除いてください。
3.1. EXCLUDE_ROUTE Object (XRO)
3.1. _ルートオブジェクトを除いてください。(XRO)
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:
_Type1EXCLUDE_ROUTE、現在、1C Typeは定義されます。 EXCLUDE_ROUTEオブジェクトには、以下の形式があります:
Class = 232, C_Type = 1
クラス=232、C_は=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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 subobjectsを適合させます。 このドキュメントのセクション2で定義されるSRLG subobjectは以前、定義されたことがありません。 SRLG subobjectは使用のためにここでルート除外で定義されます。
The following subobject types are supported.
以下の「副-オブジェクト」タイプはサポートされます。
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
Subobjectをタイプしてください。-------------+------------------------------- 1 IPv4接頭語2IPv6接頭語4Unnumbered Interface ID32AutonomousシステムNo.34SRLG
The defined values for Type above are specified in [RFC3209] and in this document.
Typeのための上の定義された値は[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 subobjectsのために定義されたLビットが抽象的なノードを除かなければならないのを示すためにここで再利用される、(値
Lee, et al. Standards Track [Page 7] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[7ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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)かSHOULD、避けられてください(値1)。 区別はLSPの経路がLビットが明確な状態でXROにリストアップされた抽象的なノードを横断してはいけないということですが、Lビットによる横断1がセットしますように。 LSP(例えばゆるいホップを広げるために)を発送するのに原因となるノードは、ローカルの方針に応じてLSPによって横断されるLビットがセットした状態でXROにリストアップされた抽象的なノードの数を最小にするのを試みるはずです。 対応する抽象的なノードの1、いくつか、またはすべてを横断するLSPを受け入れるようにLビットがセットした状態でXRO subobjectsを生成するノードを準備しなければなりません。
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.
Subobjects1、2、および4はインタフェースかインタフェースのセットについて言及します。 経路から除かれるべきであるインタフェースに関連している属性(例えば、インタフェース、ノード、SRLG)を示すためにこれらの「副-オブジェクト」でAttribute八重奏を導入します。 例えば、属性ノードは、全体のノードが経路からXRO subobjectのそのノードのインタフェースを指定することによって除かれるのを許容します、属性インタフェースと対照して。インタフェースは、特定のインタフェース(または、複数のインタフェース)が経路から全体のノードを除かないで除かれるのを許容します。 属性SRLGは、インタフェースに関連しているすべてのSRLGsが経路から除かれるのを許容します。
3.1.1. IPv4 Prefix Subobject
3.1.1. IPv4接頭語Subobject
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| IPv4アドレス(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4アドレス(続けられています)| 接頭語の長さ| 属性| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
0 indicates that the attribute specified MUST be excluded.
1 indicates that the attribute specified SHOULD be avoided.
L0は、指定された属性を除かなければならないのを示します。 1は、属性の指定されたSHOULDが避けられるのを示します。
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接頭語に関連しているノードのノードかセットが除かれるべきであるか、または避けられるべきであるのを示します。
Lee, et al. Standards Track [Page 8] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[8ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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]で定義されるようにあります。
3.1.2. IPv6 Prefix Subobject
3.1.2. IPv6接頭語Subobject
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| IPv6アドレス(16バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| 接頭語の長さ| 属性| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
0 indicates that the attribute specified MUST be excluded.
1 indicates that the attribute specified SHOULD be avoided.
L0は、指定された属性を除かなければならないのを示します。 1は、属性の指定されたSHOULDが避けられるのを示します。
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]で定義されるようにあります。
Lee, et al. Standards Track [Page 9] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[9ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
3.1.3. Unnumbered Interface ID Subobject
3.1.3. 無数のインタフェースID Subobject
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| 予約されます。| 属性| | | | |(ゼロでなければなりません) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TeルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID(32ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
0 indicates that the attribute specified MUST be excluded.
1 indicates that the attribute specified SHOULD be avoided.
L0は、指定された属性を除かなければならないのを示します。 1は、属性の指定されたSHOULDが避けられるのを示します。
Attribute
属性
Interface attribute value
0 indicates that the Interface ID specified should be
excluded or avoided.
インタフェース属性値0は、IDが指定したInterfaceが除かれるべきであるか、または避けられるべきであるのを示します。
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は、Router IDがあるノードが除かれるべきであるか、または避けられるべきであるのを示します(これは、また、IPv4/v6 subobjectを使用することで達成できますが、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.
予約されたThis分野は予約されています。 それ、SHOULDはトランスミッションのときにゼロに用意ができて、領収書の上で無視しなければなりません。
The rest of the fields are as defined in [RFC3477].
分野の残りが[RFC3477]で定義されるようにあります。
3.1.4. Autonomous System Number Subobject
3.1.4. 自律システム番号Subobject
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は、抽象的なノードの指定されたSHOULDが避けられるのを示します。
The rest of the fields are as defined in [RFC3209]. There is no Attribute octet defined.
分野の残りが[RFC3209]で定義されるようにあります。 定義されたAttribute八重奏が全くありません。
Lee, et al. Standards Track [Page 10] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[10ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
3.1.5. SRLG Subobject
3.1.5. SRLG Subobject
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がSHOULDを指定したのを示すということでなければならないことを示す、避けられてください。
The Attribute octet is not present. The rest of the fields are as defined in the "SRLG Subobject" section of this document.
Attribute八重奏は存在していません。 分野の残りがこのドキュメントの"SRLG Subobject"セクションで定義されるようにあります。
3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO)
3.2. 処理が統治する、_ルートオブジェクトを除いてください。(XRO)
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アドレス、接頭語がノードのグループのインタフェースを特定しているIPアドレス、Autonomous System、またはSRLGであるかもしれません。
The Explicit Route and routing processing is unchanged from the description in [RFC3209] with the following additions:
Explicit Routeとルーティング処理は[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. ノードにPathメッセージを受け取るとき、ノードは、Pathメッセージに存在しているならそれがメンバーでないことをXROの抽象的なノードのどんなもチェックしなければなりません。 ノードであるなら、メンバーは中の抽象的なノードのどれかのものです。L-旗があるXROは「除外」にセットして、それはエラーコード「ルート設定問題」と誤りがあるPathErrが評価する「Exclude Routeのローカルのノード」のSHOULD復帰です。 SRLGsがXROにあれば、ノードSHOULDは、ノードが使用するリソースがXROで指定される「除く」L-旗のセットがあるどんなSRLGの一部でないこともチェックします。 それはそうであり、「Exclude Routeのローカルのノード」のエラーコード「ルート設定問題」と誤り値があるSHOULDリターンa 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. それぞれの「副-物」は一貫しているに違いありません。 「副-物」が一貫していないなら、ノードSHOULDはエラーコード「ルート設定問題」と誤り値の「矛盾したSubobject」と共にPathErrを返します。 矛盾した「副-物」に関する例は、ノードのIPアドレスと属性分野を含んだら「連結される」ように設定されるIPv4 Prefix subobjectか"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、その時:
- 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
- そしてSubobjects、どんなセット(ゼロ)もEROの「副-物」()、XRO MUSTで言い表された義務的な除外に優先してはいけないL旗があるXROでは、光栄に思ってください。
Lee, et al. Standards Track [Page 11] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[11ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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.
実現はそのようなPathメッセージを拒絶しなければなりません。 これは、「Exclude Routeによって妨げられたルート」のエラーコード「ルート設定問題」と誤り値がある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のSubobjectsはERO subobjectsの上で優先しません--すなわち、実現は、そのような矛盾でPathメッセージを拒絶するのを選ぶかもしれません、LSPを続けて、セットアップするかもしれないのを除いて(ERO subobjectsに矛盾するXRO subobjectsを無視して)。
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。 NOTが明白なノードかそれが等しい抽象的なノードを紹介しなければならない、さもなければ、何かEXCLUDE_ROUTE物で「除く」L-旗のセットで指定される抽象的なノードがメンバーがいますか? 導入された明白なノードの数か「避ける」L旗のセットとの抽象的なノード。(それは、最小にされたコネが計算された経路であったなら除かれるのがそれがそれほど都合のよくないSHOULDでなかったなら義務的でないことを示します)。
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 subobjects(s)で指定されたSRLG Idによって特定されたリンク、ノード、またはリソースを紹介してはいけません。 L旗のセットが「避け」SHOULDに最小にされている導入された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メッセージの、より遠い推進を排除するなら、ノードSHOULDは「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 MAY廃棄物を運んで、メッセージがXROであるなら大き過ぎるというPathメッセージを受け取るか、または複雑にされたノード。 この場合ノードがエラーコード「ルート設定誤り」と誤り値があるPathErrメッセージを送らなければならない、「XRO、複雑過ぎる、」 このエラーコード/値の組み合わせを受け取るイングレス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 Class-ヌムがフォーム11bbbbbbのものであるので、それが非点検したXROフォワードを支えて、しないノードが上で説明されたERO処理に拡大を適用しません。 このアプローチは、ルート除外がネットワークの構文解析ができない部分を横断するのを許容するのを選ぶか、または新しい機能を扱うことです。 それに注意してください。
Lee, et al. Standards Track [Page 12] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[12ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
Record Route may be used to allow computing nodes to observe violations of route exclusion and attempt to re-route the LSP accordingly.
記録的なRouteは、ルート除外の違反を観測して、それに従って、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) (2) 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:
ノードがPathメッセージを転送するとき、前記のように処理規則以外に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が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.
3. XROが存在していたなら、XROの内容を変更できます。 Subobjectsを加えるか、または取り外すことができます。 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旗の値の如何にかかわらず)のどんな明白であるか抽象的なノードも紹介してはいけません。
4. Explicit Exclusion Route
4. 明白な除外ルート
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.
Explicit Exclusion Routeは使用されるべきでないか、または明白なルートによる2つの包括的な抽象的なノードかリソースの間の経路で使用してはいけないべきである抽象的なノードかリソース(リンク、無数のインタフェース、またはラベルなどの)を定義します。
4.1. Explicit Exclusion Route Subobject (EXRS)
4.1. 明白な除外ルートSubobject(EXRS)
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 subobjectタイプは定義されます。 Explicit Exclusion Route Subobject(EXRS)には、タイプ33があります。 EXRSはERO subobjectです、そして、XROは現在のコネがXROであったならERO subobject、EXRS MUST NOTを再利用していますが。 EXRS subobjectsは、EXRSがそれ自身の1個以上の「副-物」を含むERO subobjectであると呼びました。
Lee, et al. Standards Track [Page 13] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[13ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //1EXRS 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 subobjectのLビットがXRO subobjectsのために定義されるようにあります。)
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.
予約されたThis分野は予約されています。 それ、SHOULDはトランスミッションのときにゼロに用意ができて、領収書の上で無視しなければなりません。
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 subobjects An EXRS subobjectは、除かれるために抽象的なノードかリソースを示します。 EXRS subobjectの形式はまさに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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| タイプ| 長さ| IPv4アドレス(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4アドレス(続けられています)| 接頭語の長さ| 属性| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lee, et al. Standards Track [Page 14] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[14ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
4.2. Processing Rules for the Explicit Exclusion Route Subobject (EXRS)
4.2. 明白な除外ルートSubobjectのための処理規則(EXRS)
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 subobjectsのようにコード化されて、追加TypeとLengthによって前に置かれています。
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 subobjectと、抽象的なノードを特定するその後のERO subobjectの間のステップです。 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で示された次の抽象的なノードに横断してはいけない明白なノード、抽象的なノード、またはAutonomous Systemsを示すかもしれません。
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で示された次の抽象的なノードに使用してはいけないリソース(無数のインタフェースや、リンクイドや、ラベルなどの)を示すかもしれません。
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 subobjectを含んでいて、SRLGsは除外のためにEROでEXRSの包含で経路から抽象的な次のノードまで示されるかもしれません。 ゼロがLビットであるならSRLG subobjectに、あります、リソース。(ノード、リンクなど) SRLG MUST NOTによって特定されて、経路でEROで示された次の抽象的なノードに使用されてください。 セット、リソースはLビットであるならSRLG SHOULDによって特定されます。避けられます。
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を処理するのが要求されて、扱うのを支えないと、除外では、それは認識されていないERO subobjectが遭遇するとき、[RFC3209]で説明されるように反応するでしょう。 これは、このノードがEXPLICIT_ROUTE物をもって「悪いEXPLICIT_ROUTEは反対すること」を含んでいるエラーコード「ルート設定誤り」と誤り値の怒っているEXRSに先端を切られた(左で)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メッセージの、より遠い推進を排除するなら、ノードSHOULDはエラーコード「ルート設定問題」と誤り値がある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メッセージを拒絶するかもしれません。 この場合ノードがエラーコード「ルート設定誤り」と誤り値があるPathErrメッセージを送らなければならない、「EXRS、複雑過ぎる、」 このエラーコード/値の組み合わせを受け取るイングレスLSRはEXRSを拒絶したノードの周りのEXRSかルートの複雑さを減少させるかもしれません。
Lee, et al. Standards Track [Page 15] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[15ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
5. Processing of XRO together with EXRS
5. EXRSに伴うXROの処理
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、ノード、リンク、またはリソースを除かなければならないと言って、もう片方が、それが避けられるだけであるべきであると言うなら、要素を除かなければなりません。
6. Minimum Compliance
6. 最小の承諾
An implementation MUST be at least compliant with the following:
実現は以下で少なくとも対応でなければなりません:
1. The XRO MUST be supported with the following restrictions:
1. XRO MUST、以下の制限で、支持されてください:
- 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.
- 32の接頭語の長さ、および「インタフェース」と「ノード」の属性値でIPv4 Prefix subobjectを支持しなければなりません。 他の接頭語値と属性値は支持されるかもしれません。
- 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.
- 128の接頭語の長さ、および「インタフェース」と「ノード」の属性値でIPv6 Prefix subobjectを支持しなければなりません。 他の接頭語値と属性値は支持されるかもしれません。
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 MAY、支持されてください。 支持されるなら、XROのような同じ制限は適用されます。 支持されないなら、セクション4.2で説明される未知のERO subobjectとして通常のERO処理の間に遭遇するEXRSを拒絶しなければなりません。 ノードSHOULD NOTが先で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が支持されるなら、実現はこのドキュメントの中の指定されるとしての支持されるのではなく、支持されたか、または部分的に支持された「副-物」の処理規則で対応するに違いありません。
7. Security Considerations
7. セキュリティ問題
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メッセージからEROsを剥取るかもしれません。 また、この場合、XROは取り外しのためにPathメッセージから考えられるべきです。
Lee, et al. Standards Track [Page 16] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[16ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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(すなわち、隣人によって認証されたもの)がそうであると仮定することに注意されるべきです。 PathErrメッセージがエラーコード「ルート設定誤り」と誤り値を運んでいてXROを受けるノードかそれがローカルの方針によると、複雑過ぎると考えるEXRS系列が応じるかもしれない、「XRO、複雑過ぎる、」、「EXRS、複雑過ぎる、」
8. IANA Considerations
8. IANA問題
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 subobjectタイプ分野(恐らくトップビット)のビットの1つを割り当てることであると考えられるかもしれません。 しかしながら、[RFC3209]は、IETFコンセンサス動作による0--63、先着順としての64--95、および96--127が私的使用目的で予約されるときタイプ分野(7ビット)が割り当てられるべきであると述べます。 既存の実現を中断するのは、32の「副-物」のタイプだけを出るIETFコンセンサス範囲を分けるために唯一のオプションがことである許容できないでしょう。 32がプロトコルの今後の拡大の容認できないほど少ない数であると感じられます。
8.1. New ERO Subobject Type
8.1. 新しいERO Subobjectはタイプします。
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の明白な_ルート
The registry reads:
登録は読みます:
33 Explicit Exclusion Route subobject (EXRS)
33 明白なExclusion Route 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.
Explicit Exclusion Route subobject(EXRS)はセクション4.1、「明白な除外ルートSubobject(EXRS)」で定義されます。 この「副-物」は、Explicit Route Objectに存在していますが、Route Record Objectか新しいEXCLUDE_ROUTE物に存在するかもしれないというわけではありません、そして、それらの物のために「副-物」の中にそれを記載するべきではありません。
Lee, et al. Standards Track [Page 17] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[17ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
8.2. New RSVP-TE Class Numbers
8.2. 新しいRSVP-Teクラス番号
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、「_ルート物(XRO)を除いてください」で定義されるように加えられます。
EXCLUDE_ROUTE Class-Num of type 11bbbbbb Value: 232 Defined CType: 1 (EXCLUDE_ROUTE)
タイプ11bbbbbb ValueのEXCLUDE_ROUTE Class-ヌム: 232はCTypeを定義しました: 1 (_ルートを除きます)
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:
Subobjects1、2、4、および32がExplicit Route Objectのために定義されるようにあります。 追加「副-物」が要求された通りセクション8.1に登録されたのを「新しいERO Subobjectはタイプします」。 テキストは以下として現れるべきです。
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]
サブオブジェクト・タイプ1IPv4アドレス[RFC3209]2IPv6アドレス[RFC3209]4Unnumbered Interface ID[RFC3477]32Autonomousシステム数の[RFC3209]33Explicit Exclusion Route subobject(EXRS)[RFC4874]34SRLG[RFC4874]
The SRLG subobject is defined in Section 3.1.5, "SRLG Subobject". The value 34 has been assigned.
SRLG subobjectはセクション3.1.5、"SRLG Subobject"で定義されます。 値34を割り当ててあります。
8.3. New Error Codes
8.3. 新しいエラーコード
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).
新しいError ValuesサブコードはError Code'ルート設定Problem'(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を除く矛盾したSubobject66ルートSubobjectタイプ65==は複雑過ぎる状態でルート68=XRO複雑過ぎる69=EXRSを除きます。
Lee, et al. Standards Track [Page 18] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[18ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
9. Acknowledgments
9. 承認
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!
作者はこのドキュメントに関する彼らのいろいろ考察してみた上での意見のためにルウ・バーガー、ステファンBrockmann、イーゴリBryskin、ディミトリPapadimitriou、Cristel Pelsser、およびリチャードRabbatに感謝したがっています。 また、SRLGsに関して私たちにヤコフRekhterに思い出させてくださいといってくださってありがとうございますこと!
Thanks to Eric Gray for providing GenArt review and to Ross Callon for his comments.
彼のコメントをレビューをGenArtに供給するためのエリック・グレーと、そして、ロスCallonをありがとうございます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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)拡大」、RFC3473、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)」、RFC3477、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)を支持したルート設定拡大」、RFC4202、2005年10月。
10.2. Informative References
10.2. 有益な参照
[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]ファレル、A.、A.、磐田、A.、灰、G.、およびS.マーシャル-Unitt、「MPLSシグナリングのための拡大に合図するCrankback」というSatyanarayanaは進行中(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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
Lee, et al. Standards Track [Page 19] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[19ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
[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)のための拡大、」、RFC3784(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.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、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.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、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)要件」、RFC4216、2005年11月。
Lee, et al. Standards Track [Page 20] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[20ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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).
相互領域LSPを確立する1つの方法がイングレスルータがABRを選択するところであり、次に、イングレスルータがこの選択されたABRに向かって経路を計算するので、LSPの構成された規制が実現します。 図A.1に関する例に、LSPは領域1のノードAから領域2のノードCまで設立されなければなりません。 どんなゆるいホップも構成されないなら、Aの計算されたEROは以下の通りに見えるかもしれません: (A1厳しくて、A2厳しくて、ABR1厳しくて、Cゆるい。) PathメッセージがABR1に到着すると、次に、EROは到着します、そして、(ABR1厳しくて、Cゆるい)ABR1は(ゆるいB1厳しくて、ABR3厳しいC)にそれを広げることができます。 同様に、容認されたEROはABR3では、こと(ABR3厳しくて、Cゆるい)です、そして、それに(C1厳しく、C2厳しく、C厳しい)で広げることができます。 バックアップLSPも設立されなければならないなら、Aは、別のABR(この場合、ABR2)を連れて行って、LSPの規制を実現させて、第一のLSPの経路からばらばらになることであるこのABRに向かって経路を計算します。 Aで発生するEROはこの例において以下の通りに見えます: (A3厳しくて、A4厳しくて、ABR2厳しくて、Cゆるい。)
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を広げさせて、また、第一のLSPの経路を知るのが必要であるので、ERO拡大は第一のLSPの経路からばらばらになることです。 したがって、また、Aは(ABR1、B1、ABR3、C1、C2)を少なくとも含むXROを含んでいます。 それが第一のLSPからばらばらになることであるように、これらの規制に基づいて、ABR2はEROを広げることができます。 この例では、ABR2によって計算されたEROは(ゆるいB2厳しくて、ABR4厳しいC)でしょう、そして、Bで発生するXROは少なくとも(ABR3、C1、C2)を含んでいます。 ABR4がEROを広げるのに後者の情報が必要であるので、経路は領域2の第一のLSPからばらばらになることです。
Lee, et al. Standards Track [Page 21] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[21ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
Area 1 Area 0 Area 2
<---------------><--------------><--------------->
1つの領域の領域の0地域2<。---------------><、-、-、-、-、-、-、-、-、-、-、-、-、--、><、-、-、-、-、-、-、-、-、-、-、-、-、-、-->。
+---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
| | | | |
| | | | |
A | | | C
| | | | |
| | | | |
+---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
+---A1---A2----ABR1-----B1-----ABR3----C1---C2---+ | | | | | | | | | | A| | | C| | | | | | | | | | +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
Figure A.1: Inter-area LSPs
A.1は計算します: 相互領域LSPs
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を発生させると、領域0でABR3ではなく、XROからノードを取り除くかもしれないことを意味します。 領域2のABR3を通してABR4からCまで経路が全くないのでこれをしないのがこの例の害を引き起こさないことに注意してください。 ABR4- ABR3とABR3-Cとのリンクがあれば、それが、XROのABR3をABR2によって発生させるのに必要です。
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の長さについての議論: リンクかノード保護が要求されているとき、第一のLSPのRROの長さに従って、XROの長さは境界があります。 イングレスノードとABRsによるノードを取り除くことによって、それをより短くすることができます。 上では、第一のLSPのRROが含む例では、最大のXROの長さがあることができる間の8「副-物」が6「副-物」でバウンドしました(ノードのA1とA2がXROにある必要はありません)。 SRLG保護のために、XROは第一のLSPによって交差されるすべてのSRLGsを記載しなければなりません。
A.2. Inter-AS LSP Protection
A.2。 相互、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
相互AS LSP(リンクかノード保護を提供するためにバックアップLSPによって保護されなければならない)が設立されるとき、相互領域LSPケースのような同じ方法を使用できます。 違いは次に、XROがいつも第一のLSPのフルパスを含むはずであるのでバックアップLSPが第一のLSPと同じAS-経路に続いていない時です。 バックアップLSPが同じAS-経路に続いているといけないので
Lee, et al. Standards Track [Page 22] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[22ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
(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).
(しかし少なくとも異なったASBRsノード保護の場合に)、それは相互領域ケースと同様です: 次のASの上にEROを広げるASBRsはそのASに位置するXRO subobjectsを取り外すかもしれません。 イングレスによる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の長さについての議論: 第一のLSPのRROの長さに従って、XROは境界があります。
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-イドをリンクに割り当てる一貫した方法を使用します(すなわち、ASsはただ一つのSRLGスペースを使用します)。 この場合、RROによって主なLSPによって使用されたそれぞれのリンクのSRLG-イドを記録できます。 そして、SRLG-イドはXROによって使用されます。 ASに地方であることのときにだけ、SRLG-イドが重要であるなら、多くのASsに交差しながらSRLG-イドをXROに入れるのは意味をなさないです。 相互AS LSPsのために保護をSRLGに供給するために、第一のLSPによって使用された相互ASリンクのリンクIPアドレスを回り道LSPか迂回トンネルに関するPathメッセージのXROに入れることができます。 回り道LSPか迂回トンネルがASに入っているASBRは地方のASにおいて知られているSRLG-イドのリストにこれを翻訳できます。
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は1個の「副-物」しか含んでいません(第一のLSPと回り道LSPか迂回トンネルが同じ領域でASを発っていて、また、彼らが同じ領域に次のASを入れていると仮定して)。(「副-物」は第一のLSPによって横断された相互ASリンクのIPアドレスを含みます)。
Lee, et al. Standards Track [Page 23] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[23ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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を設立したいと(図A.2を見てください)、複数の目的にXROを使用できます。
Overlay Overlay
Network +--------------------------------+ Network
+----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | | | | |
+----------+ | | | | | | | +----------+
| | | | | | |
+----------+ | | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | | |
| +----+ | | | | | +------+ | | | | +----+ |
| | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | |
| --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +--------------------------------+ | |
+----------+ Core Network +----------+
オーバレイオーバレイネットワーク+--------------------------------+ ネットワーク+----------+ | | +----------+ | +----+ | | +-----+ +-----+ +-----+ | | +----+ | | | | | | | | | | | | | | | | | | --+ EN1++-----+--+ CN1+---+ CN2+---+ CN3+---+-----++EN3+--| | | | | +--+--+ | | | | +---+--+ | | | | | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | | | | | | | | | | | | +----------+ | | | | | | | +----------+ | | | | | | | +----------+ | | | | | | | +----------+ | | | | +--+--+ | +--+--+ | | | | | +----+ | | | | | +------+ | | | | +----+ | | | +-+--+ | | CN4+-------------+ CN5| | +--+-+ | | | --+ EN2++-----+--+ | | +---+-----++EN4+--| | | | | | +-----+ +-----+ | | | | | | +----+ | | | | +----+ | | | +--------------------------------+ | | +----------+ コアネットワーク+----------+
Overlay Overlay
Network Network
オーバレイオーバレイネットワークネットワーク
Legend:
EN - Edge-Node
CN - Core-Node
伝説: アン--縁ノード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.
最初のアプリケーションは縁ノードが同じ目的地縁ノードに向かって複数のLSPsを設立したがっているところです、そして、これらのLSPsはどんなわずかもSRLGsも共通でない必要があります。 この場合、EN1はEN3に向かってLSPを設立できました、そして、次に、それは指示で最初のLSPによって使用された、これらのリンクのSRLGsを避けたすべてのリンクを記載する第2のLSPを設立できます。 CN1は、第2LSPのために経路を計算するのにこの情報を使用できます。 コアネットワークが複数の領域から成るなら、SRLG-イドはXROに記載されなければなりません。 同じ例はノードとリンクに適用されます。
Lee, et al. Standards Track [Page 24] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[24ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
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を設立すると、それはPathメッセージをCN4に送ります。(CN4は(例えば、)CN5の上でEN4に向かって経路を計算します)。 EN2がそのLSPのRROを取り戻すと、目的地とXROが最初のLSPのRROに基づいて計算したようにそれはEN4と共に新しいLSPにCN1に合図できます。 この情報に基づいて、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]で説明されるIGPsと[RFC3784]のTE拡張子が使用されていないネットワークを取ってください。 したがって、各ノードは次のホップを選択しなければなりません、そして、どんな実行可能な次のホップもないとき、ことによるとcrankback[CRANKBACK]は使用されなければなりません。 この場合バックアップLSPに合図するとき、第一のLSPのリンク、ノード、またはSRLGsを除くPathメッセージにXROを入れることができます。 この機能性を提供する代替の方法はバックアップ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を記載しなければなりません。 IGPsのTE拡張子がこの例で使用されないので、SRLG保護に、そのSRLGsがリンクする参照へのリンクIPアドレスを使用できないことに注意してください。 したがって、ノードはその領域にSRLGsに位置する少しのリンクIPアドレスも翻訳できません。
Lee, et al. Standards Track [Page 25] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[25ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
Authors' Addresses
作者のアドレス
Cheng-Yin Lee EMail: c.yin.lee@gmail.com
チェン-殷リーメール: c.yin.lee@gmail.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
エードリアンのファレルの古い犬のコンサルティング電話: +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のアルカテル透明なCopernicuslaan50B-2018アントワープベルギー電話: +32 3 240 85 15はメールされます: stefaan.de_cnodder@alcatel-lucent.be
Lee, et al. Standards Track [Page 26] RFC 4874 Exclude Routes - Extension to RSVP-TE April 2007
リー、他 標準化過程[26ページ]RFC4874は2007年4月にRSVP-Teまでルート--拡大を除きます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Lee, et al. Standards Track [Page 27]
リー、他 標準化過程[27ページ]
一覧
スポンサーリンク
