Network Working Group                                          L. Berger
Request for Comments: 4873                               LabN Consulting
Updates: 3473, 4872                                           I. Bryskin
Category: Standards Track                                   ADVA Optical
                                                        D. Papadimitriou
                                                                 Alcatel
                                                               A. Farrel
                                                      Old Dog Consulting
                                                                May 2007
        
                         GMPLS Segment Recovery
        

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 describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects.

このドキュメントは、GMPLS(汎用マルチプロトコルラベルスイッチング)のためのプロトコルの具体的な手順を説明RSVP-TE(リソース予約プロトコル - トラフィックエンジニアリング)ラベルをサポートする拡張機能をシグナルパス(LSP)セグメントの保護と回復を切り替えます。これらの拡張機能は、補完し、エンドツーエンドGMPLS回復(RFC 4872)のためのRSVP-TE拡張機能と一致するように意図されています。高速リルートと影響との相互作用にも対処しています。この文書はまた、NOTIFY_REQUESTオブジェクトの処理を更新します。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Segment Recovery ................................................4
      2.1. Segment Protection .........................................6
      2.2. Segment Re-routing and Restoration .........................6
   3. ASSOCIATION Object ..............................................6
      3.1. Format .....................................................7
      3.2. Procedures .................................................7
           3.2.1. Recovery Type Processing ............................7
           3.2.2. Resource Sharing Association Type Processing ........7
   4. Explicit Control of LSP Segment Recovery ........................8
      4.1. Secondary Explicit Route Object Format .....................8
           4.1.1. Protection Subobject ................................8
      4.2. Explicit Control Procedures ................................9
           4.2.1. Branch Failure Handling ............................10
           4.2.2. Resv Message Processing ............................11
           4.2.3. Admin Status Change ................................12
           4.2.4. Recovery LSP Teardown ..............................12
      4.3. Teardown From Non-Ingress Nodes ...........................12
           4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13
           4.3.2. Modified Notify and Error Message Processing .......14
   5. Secondary Record Route Objects .................................14
      5.1. Format ....................................................14
      5.2. Path Processing ...........................................15
      5.3. Resv Processing ...........................................15
   6. Dynamic Control of LSP Segment Recovery ........................16
      6.1. Modified PROTECTION Object Format .........................16
      6.2. Dynamic Control Procedures ................................17
   7. Updated RSVP Message Formats ...................................18
   8. Security Considerations ........................................20
   9. IANA Considerations ............................................21
      9.1. New Association Type Assignment ...........................21
      9.2. Definition of PROTECTION Object Reserved Bits .............21
      9.3. Secondary Explicit Route Object ...........................21
      9.4. Secondary Record Route Object .............................21
      9.5. New Error Code ............................................22
      9.6. Use of PROTECTION Object C-type ...........................22
   10. References ....................................................23
      10.1. Normative References .....................................23
      10.2. Informative References ...................................23
        
1. Introduction
1. はじめに

[RFC4427] covers multiple types of protection, including end-to-end and segment-based approaches. "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery" [RFC4872] defines a set of extensions to support multiple types of recovery. The supported types include 1+1 unidirectional/ 1+1 bidirectional protection, LSP protection with extra-traffic (including 1:N protection with extra-traffic), pre-planned LSP re-routing without extra-traffic (including shared mesh), and full LSP re-routing. In all cases, the recovery is provided on an end-to-end basis, i.e., the ingress and egress nodes of both the protected and the protecting LSP are the same.

[RFC4427]はエンドツーエンドセグメントベースのアプローチを含む保護複数のタイプをカバー。 「RSVP-TE拡張機能は、エンドツーエンドの一般化マルチプロトコルラベルスイッチング(GMPLS)回復の支援に」[RFC4872]は、リカバリの複数のタイプをサポートするための拡張セットを定義します。サポートされているタイプは、1 + 1単方向/ 1 + 1双方向保護を含む、(1を含む:エクストラトラフィックでN保護し)、余分なトラフィックを有するLSP保護は、(共有メッシュを含む)、エクストラトラフィックなしLSP再ルーティング事前に計画しますフルLSP再ルーティング。全ての場合において、回復は、エンドツーエンドベースで提供される、即ち、保護及び保護LSPの両方の入力および出力ノードが同じです。

[RFC4090] provides a form of segment recovery for packet MPLS-TE networks. Two methods of fast reroute are defined in [RFC4090]. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point that is shared by multiple LSPs and uses label stacking. Neither approach supports the full set of recovery types supported by [RFC4872]. Additionally, the facility backup method is not applicable to most non-PSC (packet switch capable) switching technologies.

[RFC4090]はパケットMPLS-TEネットワークのセグメントの回復の形態を提供します。高速リルートの二つの方法が[RFC4090]で定義されています。一対一のバックアップ方式は、ローカル修復の各電位点における各保護LSPのために迂回LSPを作成します。施設バックアップ方法は、複数のLSPによって共有され、ラベルスタックを使用している潜在的な障害ポイントを保護するためのバイパストンネルを作成します。どちらのアプローチは、[RFC4872]でサポートされている回復タイプのフルセットをサポートしています。また、設備のバックアップ方法は、ほとんどの非PSC(パケットができるスイッチ)のスイッチング技術には適用できません。

The extensions defined in this document allow for support of the full set of recovery types supported by [RFC4872], but on a segment, or portion of the LSP, basis. The extensions allow (a) the signaling of desired LSP segment protection type, (b) upstream nodes to optionally identify where segment protection starts and stops, (c) the optional identification of hops used on protection segments, and (d) the reporting of paths used to protect an LSP. The extensions also widen the topological scope over which protection can be supported. They allow recovery segments that protect against an arbitrary number of nodes and links. They enable overlapping protection and nested protection. These extensions are intended to be compatible with fast reroute, and in some cases used with fast reroute.

この文書で定義された拡張機能は[RFC4872]でサポートされているリカバリタイプのフルセットのサポートを可能にするが、セグメント、又はLSP、基礎の部分に。拡張は、セグメント保護開始および停止ここで、(a)は、所望のLSPセグメント保護タイプのシグナリング、(b)は、上流ノードは、特定の(c)保護セグメント上で使用されるホップの任意の識別、および(d)の報告を任意に可能パスはLSPを保護するために使用されます。拡張子も保護をサポートすることができ、その上トポロジカル範囲を広げます。彼らは、ノードとリンクの任意の数から守る回復セグメントを可能にします。彼らは重複保護とネストされた保護を可能にします。これらの拡張機能は、高速リルートと、高速再ルーティングで使用されるいくつかの例では互換性があるように意図されています。

1.1. Conventions Used in This Document
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

In addition, the reader is assumed to be familiar with the terminology used in [RFC3209], [RFC3471], and [RFC3473], as well as [RFC4427], [RFC4426], [RFC4872], and [RFC4090].

また、読者は[RFC3209]で使用される用語、[RFC3471]及び[RFC3473]、ならびに[RFC4427]、[RFC4426]、[RFC4872]及び[RFC4090]に精通しているものとします。

2. Segment Recovery
2.セグメントの回復

Segment recovery is used to provide protection and restoration over a portion of an end-to-end LSP. Such segment protection and restoration is useful to protect against a span failure, a node failure, or failure over a particular portion of a network used by an LSP.

セグメントの回復は、エンドツーエンドLSPの部分上の保護と回復を提供するために使用されます。そのようなセグメント保護と回復は、LSPによって使用されるネットワークの特定の部分の上にスパン障害、ノード障害、または障害から保護するために有用です。

Consider the following topology:

次のトポロジを考えてみます。

                        A---B---C---D---E---F
                                 \     /
                                  G---I
        

In this topology, end-to-end protection and recovery is not possible for an LSP going between node A and node F, but it is possible to protect/recover a portion of the LSP. Specifically, if the LSP uses a working path of [A,B,C,D,E,F], then a protection or restoration LSP can be established along the path [C,G,I,E]. This LSP protects against failures on spans {C,D} and {D,E}, as well as a failure of node D. This form of protection/restoration is referred to as Segment Protection and Segment Restoration, or as Segment Recovery, collectively. The LSP providing the protection or restoration is referred to as a segment protection LSP or a segment restoration LSP. The term "segment recovery LSP" is used to cover either a segment protection LSP or a segment restoration LSP. The term "branch node" is used to refer to a node that initiates a recovery LSP, e.g., node C in the figure shown above. This is equivalent to the point of local repair (PLR) used in [RFC4090]. As with [RFC4090], the term "merge node" is used to refer to a node that terminates a recovery LSP, e.g., node E in the figure shown above.

このトポロジでは、エンド・ツー・エンドの保護とリカバリは、ノードAとノードFの間で起こってLSPのために可能ではないが、LSPの一部を回収/保護することが可能です。具体的には、LSPは、次に保護又は回復LSPパスに沿って確立することができる、[A、B、C、D、E、F]の現用パスを使用する場合、[C、G、I、E]。このLSPは、スパン{C、D}と{D、E}、ノードの同様の障害に障害から保護D.保護/修復のこの形態は、セグメント保護およびセグメント修復、またはセグメントの回復として、集合的に呼ばれています。保護または回復を提供するLSPは、セグメント保護LSPまたはセグメント回復LSPと呼ばれています。用語「セグメント回復LSPは、」セグメント保護LSPまたはセグメント回復LSPのいずれかをカバーするために使用されます。用語「分岐ノード」は、例えば、図中のノードCは、上記に示した、回復LSPを開始するノードを指すために使用されます。これは[RFC4090]で使用されるローカルリペア(PLR)の点に相当します。 [RFC4090]と同様に、用語「ノードをマージ」上に示した図で、例えば、ノードE、回復LSPの終端ノードを指すために使用されます。

Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID. Values for these fields are selected normally, including consideration for the make-before-break concept (as described in [RFC3209]). Intermediate nodes follow standard signaling procedures when processing segment recovery LSPs. A segment recovery LSP may be protected itself using segment or end-to-end protection/restoration. Note, in PSC environments, it may be desirable to construct the Sender_Template and Session objects per [RFC4090].

セグメント保護または復元が働くLSPと1つのまたは複数のセグメント回復LSPを使用して通知されます。各セグメント回復LSPは、独立LSPとしてシグナリングされます。具体的には、SENDER_TEMPLATEオブジェクトは上記に示したトポロジにおいて、例えば、ノードC、回復経路の起点ノードのIPアドレスを使用し、セッションオブジェクトが回収経路を終端ノードのIPアドレスが含まれ、例えば、ノードEは、上記に示しました。 LSP ID値、トンネルID、および拡張トンネルIDには、特定の要件はありません。これらのフィールドの値は、メイク・ビフォア・ブレークのコンセプトの対価([RFC3209]で説明したように)を含め、正常に選択されています。セグメント回復LSPを処理する場合、中間ノードは、標準的なシグナリング手順に従います。セグメント回復LSPは、セグメントまたはエンドツーエンドの保護/回復を使用してそれ自体を保護することができます。ノートは、PSC環境では、[RFC4090]あたりSENDER_TEMPLATEとセッション・オブジェクトを構築することが望ましい場合があります。

When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. The ASSOCIATION object is used to associate recovery LSPs with the LSP they are protecting. Working and protecting LSPs, as well as primary and secondary LSPs, are identified using LSP Status as described in [RFC4872]. The O-bit in the segment flags portion of the PROTECTION object is used to identify when a recovery LSP is carrying the normal (active) traffic.

[RFC4090]が使用されていないとき、他のLSPを有するセグメント回復LSPsの間の関連付けは、[RFC4872]で定義された関連オブジェクトを使用して示されています。 ASSOCIATIONオブジェクトは、それらが保護しているLSPに回復LSPを関連付けるために使用されます。 [RFC4872]に記載されているように働き、保護のLSP、ならびに一次および二次LSPは、LSPステータスを使用して同定されます。保護対象のセグメントのフラグ部にOビットは回復LSPが正常(アクティブ)トラフィックを搬送される際に識別するために使用されます。

An upstream node can permit downstream nodes to dynamically identify branch and merge points by setting the desired LSP segment protection bits in the PROTECTION object. These bits are defined below.

上流ノードは、動的に分岐を識別し、保護対象において所望のLSPセグメント保護ビットを設定することにより、ポイントをマージする下流ノードを可能にすることができます。これらのビットは、以下に定義されます。

Optionally, an upstream node, usually the ingress node, can identify the endpoints of a segment recovery LSP. This is accomplished using a new object. This object uses the same format as an Explicit Route Object (ERO) and is referred to as a Secondary Explicit Route object (SERO); see Section 4.1. SEROs also support a new subobject to indicate the type of protection or restoration to be provided. At a minimum, an SERO will indicate a recovery LSP's initiator, protection/restoration type and terminator. Standard ERO semantics (see [RFC3209]) can optionally be used within and SERO to explicitly control the recovery LSP. A Secondary Record Route object (SRRO) is defined for recording the path of a segment recovery LSP; see Section 5.

必要に応じて、上流ノード、通常、入口ノードは、セグメント回復LSPの端点を識別することができます。これは、新しいオブジェクトを使用して達成されます。このオブジェクトは、明示的ルート・オブジェクト(ERO)と同じ形式を使用し、二次明示的経路オブジェクト(SERO)と呼ばれます。セクション4.1を参照してください。 SEROsも提供される保護または復元の種類を示すために、新たなサブオブジェクトをサポートしています。最低でも、SEROは回復LSPのイニシエータ、保護/回復タイプとターミネータを示します。標準EROセマンティクスは([RFC3209]を参照)必要に応じて明示的に回復LSPを制御する内およびSERO使用することができます。セカンダリレコードルートオブジェクト(SRRO)はセグメント回復LSPの経路を記録するために定義されています。第5節を参照してください。

SEROs are carried between the node creating the SERO, typically the ingress, and the node initiating a recovery LSP. The node initiating a recovery LSP uses the SERO to create the ERO for the recovery LSP. At this (branch) node, all local objects are removed, and the new protection subobject is used to create the PROTECTION object for the recovery LSP. It is also possible to control the handling of a failure to establish a recovery LSP.

SEROsはSERO、典型的には、入口、及び回復LSPを開始ノードを作成するノードとの間で行われます。回復LSPを開始するノードは回復LSPのためのEROを作成するために、SEROを使用しています。この(分岐)ノードでは、すべてのローカルオブジェクトが削除され、新しい保護サブオブジェクトは回復LSPの保護オブジェクトを作成するために使用されます。回復LSPを確立するために、失敗の取り扱いを制御することも可能です。

SRROs are carried in Path messages between the node terminating a recovery LSP, the merge node, and the egress. SRROs are used in Resv messages between a branch node and the ingress. The merge node of a recovery LSP creates an SRRO by copying the RRO from the Path message of the associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Path message are also copied. The branch node of a recovery LSP creates an SRRO by copying the RRO from the Resv message of associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Resv message are also copied.

SRROsは回復LSP、マージノード、および出口を終端ノード間のPathメッセージで運ばれています。 SRROsはブランチノードと入力の間のResvメッセージで使用されています。回復LSPのマージノードが新しいSRROオブジェクトに関連付けられた回復LSPのPathメッセージからRROをコピーしSRROを作成します。回復LSPのPathメッセージ中に存在する任意のSRROsもコピーされます。回復LSPの分岐ノードは、新しいSRROオブジェクトに関連付けられた回復LSPのResvメッセージからRROをコピーしSRROを作成します。回復LSPのResvメッセージ中に存在する任意のSRROsもコピーされます。

Notify request processing is also impacted by LSP segment recovery. Per [RFC3473], only one NOTIFY_REQUEST object is meaningful and should be propagated. Additional NOTIFY_REQUEST objects are used to identify recovery LSP branch nodes.

通知要求処理もLSPセグメント回復によって影響されます。 [RFC3473]ごとに、一つだけNOTIFY_REQUESTオブジェクトは有意義であると伝播されなければなりません。追加NOTIFY_REQUESTオブジェクトは回復LSPのブランチノードを識別するために使用されています。

2.1. Segment Protection
2.1. セグメント保護

Three approaches for end-to-end protection are defined in [RFC4872]: 1+1 Unidirectional Protection (Section 5), 1+1 Bidirectional Protection (Section 6), and 1:1 Protection With Extra-Traffic (Section 7). The segment protection forms of these protection approaches all operate much like their end-to-end counterparts. Each behaves just like its end-to-end counterpart, with the exception that the protection LSP protects only a portion of the working LSP. The type of protection to be used on a segment protection LSP is indicated, to the protection LSP's ingress, using the protection SERO subobject defined in Section 4.1.

1 + 1双方向の保護(第6節)、1 + 1単方向保護(セクション5)、及び1:エンドツーエンドの保護のための3つのアプローチは、[RFC4872]で定義されているエクストラトラフィックと1保護(セクション7)。これらの保護アプローチのすべてのセグメントの保護形は、ずっと自分のエンド・ツー・エンドの対応のように動作します。それぞれの保護LSPが働くLSPの一部のみを保護することを除いて、ちょうどそのエンド・ツー・エンドの対応のように振る舞います。セグメント保護LSPで使用する保護のタイプは、セクション4.1で定義された保護SEROサブオブジェクトを使用して、保護LSPの入口に、示されています。

The switch-over processing for segment 1+1 Bidirectional protection and 1:1 Protection With Extra-Traffic follows the same procedures as end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872] for details.

セグメント1 + 1双方向保護するためのスイッチオーバー処理と1:エクストラトラフィックに1保護は、エンドツーエンドの保護形態と同じ手順に従います。詳細については、セクション6.2と[RFC4872]の7.2を参照してください。

2.2. Segment Re-routing and Restoration
2.2. セグメントの再ルーティングおよび復元

Three re-routing and restoration approaches are defined in [RFC4872]: Re-routing without Extra-Traffic (Section 8), Shared-Mesh Restoration (Section 9), (Full) LSP Re-routing (Section 11). As with protection, these approaches are supported on a segment basis. The segment forms of re-routing and restoration operate exactly like their end-to-end counterparts, with the exception that the restoration LSP recovers only a portion of the working LSP. The type of re-routing or restoration to be used on a segment restoration LSP is indicated, to the restoration LSP's ingress, using the new protection SERO subobject.

エクストラトラフィック(セクション8)、共有メッシュ修復(セクション9)、(フル)LSPの再ルーティング(セクション11)なしに再ルーティング:三再ルーティングおよび復元アプローチは[RFC4872]で定義されています。保護と同様に、これらのアプローチは、セグメントごとにサポートされています。再ルーティングおよび復元のセグメントの形態は、回復LSPが作動LSPの一部のみを回収することを除いて、正確にそれらのエンド・ツー・エンドの対応物と同様に動作します。セグメント回復LSPで使用する再ルーティングまたは修復のタイプが新しい保護SEROサブオブジェクトを使用して、復元LSPの入口に、示されています。

3. ASSOCIATION Object
3.関連オブジェクト

The ASSOCIATION object is used for the association of segment protection LSPs when [RFC4090] isn't being used. The ASSOCIATION object is defined in [RFC4872]. In this document, we define a new Association Type field value to support make-before-break; the formats and procedures defined in [RFC4872] are not otherwise modified.

[RFC4090]が使用されていないときASSOCIATIONオブジェクトは、セグメント保護LSPの関連付けのために使用されます。 ASSOCIATIONオブジェクトは[RFC4872]で定義されています。この文書では、我々は、メイク・ビフォア・ブレークをサポートする新しい協会Typeフィールドの値を定義します。 [RFC4872]で定義されたフォーマットおよび手順は、そうでなければ改変されていません。

3.1. Format
3.1. フォーマット

Association Type: 16 bits

協会の種類:16ビット

      Value       Type
      -----       ----
        2         Resource Sharing (R)
        

See [RFC4872] for the definition of other fields and values.

他のフィールドと値の定義については、[RFC4872]を参照してください。

3.2. Procedures
3.2. 手順

The ASSOCIATION object is used to associate different LSPs with each other. In the protection and restoration context, the object is used to associate a recovery LSP with the LSP it is protecting. The ASSOCIATION object is also used to support resource sharing during make-before-break. This object MUST NOT be used when association is made according to the methods defined in [RFC4090].

関連オブジェクトは、互いに異なるLSPを関連付けるために使用されます。保護と復旧状況では、オブジェクトは、それが保護しているLSPに回復LSPを関連付けるために使用されます。関連オブジェクトは、メイク・ビフォア・ブレーク中のリソースの共有をサポートするために使用されます。関連付けが行われたとき、このオブジェクトは、[RFC4090]で定義された方法に従って使用してはいけません。

3.2.1. Recovery Type Processing
3.2.1. 回復型の処理

Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP.

リカバリ型処理手順は、[RFC4872]で定義されたものと同じであるが、処理及び識別は、セグメント回復のLSPに対して起こります。このタイプの回復の複数の関連オブジェクトがLSP上に存在し得ることを意味することに留意されたいです。

3.2.2. Resource Sharing Association Type Processing
3.2.2. リソース共有の関連タイプの処理

The ASSOCIATION object with an Association Type with the value Resource Sharing is used to enable resource sharing during make-before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before-break.

値リソースの共有と関連タイプとの関連オブジェクトは、メイク・ビフォア・ブレーク中のリソースの共有を有効にするために使用されます。メイク・ビフォア・ブレーク中のリソース共有は、[RFC3209]で定義されています。定義されたサポートは、同じLSP出口を共有するLSPで動作します。 LSPエンドポイントは、メイク・ビフォア・ブレーク中に変化するため、セグメント回復LSPの導入により、それが可能になりました。

A node includes an ASSOCIATION object with a Resource Sharing Association Type in an outgoing Path message when it wishes to indicate resource sharing across an associated set of LSPs. The Association Source is set to the originating node's router address. The Association ID MUST be set to a value that uniquely identifies the association of LSPs. This MAY be set to the working LSP's LSP ID. Once included, an ASSOCIATION object with a Resource Sharing Association Type SHOULD NOT be removed from the Path messages associated with an LSP.

それはLSPの関連セットにわたってリソース共有を示すことを望む場合、ノードは、送信Pathメッセージにおけるリソース共有アソシエーションタイプと関連オブジェクトを含みます。協会のソースは、発信元ノードのルータアドレスに設定されています。アソシエーションIDは一意にLSPの関連を特定の値に設定しなければなりません。これは、作業LSPのLSP IDに設定されるかもしれません。一度含め、リソース共有の関連タイプとの関連オブジェクトは、LSPに関連したPathメッセージから除去されるべきではありません。

Any node processing a Path message for which the node does not have a matching state, and which contains an ASSOCIATION object with a Resource Sharing type, examines existing LSPs for matching Association Type, Association Source, and Association ID values. If any match is found, then [RFC3209] style resource sharing SHOULD be provided between the new and old LSPs. See [RFC3209] for additional details.

リソースの共有タイプとの関連オブジェクトが含まれている任意のノードが一致した状態を持たないため、Pathメッセージを処理ノード、およびは、協会タイプ、協会ソース、および協会のID値を一致させるためのLSPを既存の調べます。任意の一致が見つかった場合は、[RFC3209]スタイルのリソース共有新旧のLSPの間で提供されるべきです。詳細については、[RFC3209]を参照してください。

4. Explicit Control of LSP Segment Recovery
LSPセグメント回復の4明示的な制御

Secondary Explicit Route objects, or SEROs, are defined in this document. They may be used to indicate the branch and merge nodes of recovery LSPs. They may also provide additional information that is to be carried in a recovery LSP's ERO. When upstream control of branch and merge nodes is not desired, SEROs are not used.

二次明示的経路オブジェクト、またはSEROsは、この文書で定義されています。彼らは枝を示し、回復のLSPのノードをマージするために使用することができます。彼らはまた、回復LSPのEROで運ばれるべき付加的な情報を提供することができます。上流分岐の制御とマージノードが所望されていない場合、SEROsは使用されません。

4.1. Secondary Explicit Route Object Format
4.1. 二次明示的経路オブジェクトフォーマット

The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an EXPLICIT_ROUTE object. This includes the definition of subobjects defined for EXPLICIT_ROUTE object. The class of the SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

SECONDARY_EXPLICIT_ROUTEオブジェクトのフォーマットは、EXPLICIT_ROUTEオブジェクトと同じです。これはEXPLICIT_ROUTEオブジェクトに対して定義されたサブオブジェクトの定義が含まれています。 SECONDARY_EXPLICIT_ROUTEオブジェクトのクラスは、(フォーム11bbbbbbの)200です。

4.1.1. Protection Subobject
4.1.1. 保護サブオブジェクト

A new subobject, called the protection subobject, is defined for use in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new protection subobject is used to create the PROTECTION object for the recovery LSP. Specific procedures related to the protection subobject are provided in Section 4.2. The protection subobject is not valid for use with the Explicit and Record Route objects and MUST NOT be included in those objects.

保護サブオブジェクトと呼ばれる新しいサブオブジェクトは、SECONDARY_EXPLICIT_ROUTEオブジェクトでの使用のために定義されています。前述したように、新しい保護サブオブジェクトは回復LSPの保護オブジェクトを作成するために使用されます。保護サブオブジェクトに関連する具体的な手順は、セクション4.2で提供されています。保護サブオブジェクトは、明示的およびレコードのルート・オブジェクトでの使用のために有効ではありませんし、それらのオブジェクトに含まれてはいけません。

The format of the protection subobject is defined as follows:

次のように保護サブオブジェクトのフォーマットが定義されます。

       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   |   C-Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  PROTECTION Object Contents                   |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

L-bit

Lビット

This is defined in [RFC3209] and MUST be set to zero for protection subobjects.

これは[RFC3209]で定義され、保護サブオブジェクトのためにゼロに設定しなければなりません。

Type

タイプ

37 Protection

37保護

Length

長さ

As defined in [RFC3209], Section 4.3.3.

[RFC3209]で定義されるように、セクション4.3.3。

Reserved

予約済み

This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.

このフィールドは予約されています。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。

C-Type

C型

The C-Type of the included PROTECTION object.

含まれる保護対象のC型。

PROTECTION Object Contents

保護対象の内容

The contents of the PROTECTION object, with the format matching the indicated C-Type, excluding the object header.

フォーマットは、オブジェクトヘッダを除いた、示されたC-タイプ一致する保護対象の内容。

4.2. Explicit Control Procedures
4.2. 明示的な制御手順

SEROs are carried in Path messages and indicate at which node a recovery LSP is to be initiated relative to the LSP carrying the SERO. More than one SERO MAY be present in a Path message.

SEROsは、Pathメッセージで運ばとれるLSPがSEROを運ぶLSPに対して開始する回復されたノードを示しています。複数のSEROは、Pathメッセージ中に存在してもよいです。

To indicate the branch and merge nodes of a recovery LSP, an SERO is created and added to the Path message of the LSP being recovered. The decision to create and insert an SERO is a local matter and outside the scope of this document.

ブランチを示し、回復LSPのノードをマージするには、SEROが作成され、回収されるLSPのPathメッセージに追加されます。 SEROを作成して挿入するという決定は、ローカルの問題であり、この文書の範囲外。

An SERO SHOULD contain at least three subobjects. The first subobject MUST indicate the node that is to originate the recovery LSP, i.e. the segment branch node. The address used SHOULD also be listed in the ERO or another SERO. This ensures that the branch node is along the LSP path. The second subobject SHOULD be a protection subobject and should indicate the protection or restoration to be provided by the recovery LSP. When the protection subobject is present, the LSP Segment Recovery Flags in the protection subobject MUST be ignored. The final subobject in the SERO MUST be the merge node of the recovery LSP, and MAY have the L-bit set. Standard ERO subobjects MAY be inserted between the protection subobject and the final subobject. These subobjects MAY be loose or strict.

SEROは、少なくとも3つのサブオブジェクトを含むべきです。最初のサブオブジェクトは、回復LSP、すなわち、セグメントブランチノードを発信するノードを指定する必要があります。使用するアドレスはまたEROまたは別のSEROに表示される必要があります。これは、ブランチノードは、LSPパスに沿っていることを保証します。第二サブオブジェクトは、保護サブオブジェクトである必要があり、回復LSPが提供する保護や回復を示す必要があります。保護サブオブジェクトが存在する場合、保護サブオブジェクトにおけるLSPセグメント回復フラッグを無視しなければなりません。 SEROの最後のサブオブジェクトは、回復LSPのマージノードでなければなりません、及びLビットのセットがあるかもしれません。標準EROサブオブジェクトは、保護サブオブジェクトと、最終的なサブオブジェクトの間に挿入してもよいです。これらのサブオブジェクトが緩んでいるか厳しいかもしれ。

A node receiving a Path message containing one or more SEROs SHOULD examine each SERO to see if it indicates a local branch point. This determination is made by examining the first object of each SERO and seeing if the address indicated in the subobject can be associated with the local node. If any of indicated addresses are associated with the local node, then the local node is a branch node. If the local node is not a branch node, all received SEROs MUST be transmitted, without modification, in the corresponding outgoing Path message.

一つ以上のSEROsを含むPathメッセージを受信したノードは、ローカル分岐点を示しているかどうかを確認するために各SEROを調べる必要があります。この決意は、各SEROの最初のオブジェクトを検査し、サブオブジェクトで示されるアドレスがローカルノードに関連付けることができる場合に見によって行われます。示されたアドレスのいずれかがローカルノードに関連付けられている場合、ローカルノードがブランチノードです。ローカルノードがブランチノードではない場合、すべての受信SEROsは、対応する送信Pathメッセージに、変更なしで、送信されなければなりません。

At a branch node, the SERO, together with the Path message of LSP being recovered, provides the information to create the recovery LSP. The Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. Certain objects are replaced or modified in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. The Session object MUST be updated to use the address indicated in the final subobject of the SERO as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object is replaced with the contents of the matching SERO protection subobject, when present. In all cases, the R-bit of a new PROTECTION object is reset (0). Any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MUST be included, with the contents of the SERO that indicated a local branch. As with all EROs, no local information (local address and any protection subobjects) is carried in the ERO carried in the recovery LSP's outgoing Path message. The SERO that indicated a local branch MUST be omitted from the recovery LSP's outgoing Path message. Note, by default, all other received SEROs are passed in the recovery LSP's outgoing Path message. SEROs MAY be omitted, from the recovery LSP's outgoing Path message as well as the outgoing Path message for the LSP being protected, when the SERO does not relate to the outgoing path message.

ブランチノードでは、SEROは、一緒にLSPのPathメッセージが回収されると、回復のLSPを作成するための情報を提供します。回復LSPのためのPathメッセージは、保護されたLSPの受信Pathメッセージで運ばれたオブジェクトをクローニングすることによってブランチノードで作成されます。特定のオブジェクトは、交換または回復LSPの送信するPathメッセージで変更されています。 SENDER_TEMPLATEオブジェクトはローカルノード上で(そのトンネルの送信元アドレスフィールド内の)アドレスを使用するように更新されなければならない、とLSP IDは、一意性を確保するために更新されなければなりません。セッションオブジェクトがトンネル終点アドレスとしてSEROの最終のサブオブジェクトで示されるアドレスを使用するように更新する必要があり、トンネルIDを更新することができる、拡張トンネルIDは、ローカル・ノードのアドレスに設定しなければなりません。存在するとき保護対象は、マッチングSERO保護サブオブジェクトの内容に置き換えられます。全ての場合において、新たな保護対象のRビットは、リセット(0)です。入ってくるPathメッセージ中に存在する任意のRROsとエロスは回復LSPに含んではいけません。新しいEROは、ローカルブランチを示したSEROの内容が含まれなければなりません。すべてのエロスと同じように、ローカル情報(ローカルアドレスと任意の保護サブオブジェクト)が回復LSPの送信するPathメッセージで運ばEROで運ばれていません。ローカルブランチを示しSEROは回復LSPの送信するPathメッセージから省略しなければなりません。注は、デフォルトでは、他のすべての受信SEROsは回復LSPの送信するPathメッセージに渡されます。 SEROsはSEROは往路メッセージに関連していないとき、保護されて回復LSPの送信するPathメッセージだけでなく、LSPの発信Pathメッセージから、省略されるかもしれません。

The resulting Path message is used to create the recovery LSP. From this point on, Standard Path message processing is used in processing the resulting Path message.

その結果Pathメッセージは回復LSPを作成するために使用されます。この点から、標準パスメッセージ処理は、得られたPathメッセージを処理する際に使用されます。

4.2.1. Branch Failure Handling
4.2.1. 支店障害処理

During setup, it is possible that a processing node will be unable to support a requested branch. Additionally, during setup and normal operation, PathErr messages may be received at a branch node. The processing of these events depend on a number of factors.

セットアップ中に、処理ノードが要求されたブランチをサポートすることができなくなる可能性があります。また、セットアップおよび通常動作時、のPathErrメッセージはブランチノードで受信されても​​よいです。これらのイベントの処理は、多くの要因に依存します。

When a failure or received PathErr message is associated with the LSP being protected, the event is first processed per standard processing rules. This includes generation of a standard PathErr message. When LSP state is removed due to a local failure or a PathErr message with the Path_State_Removed flag set (1), the node MUST send a PathTear message downstream on all other branches.

障害または受信たPathErrメッセージが保護されたLSPに関連付けられている場合、イベントが最初に標準的な処理ルールごとに処理されます。これは、標準のPathErrメッセージの生成を含みます。 LSP状態が局部障害またはPath_State_Removedフラグが設定(1)とのPathErrメッセージに除去されると、ノードは、他のすべてのブランチで下流PathTearメッセージを送らなければなりません。

When a failure or received PathErr message is associated with a recovery LSP, processing is based on the R-bit in addition to the Path_State_Removed flag. In all cases, a received PathErr message is first processed per standard processing rules and the failure or received PathErr message SHOULD trigger the generation of a PathErr message upstream for the LSP being protected. The outgoing PathErr message SHOULD indicate an error of "Routing Problem/LSP Segment Protection Failed". The outgoing PathErr message MUST include any SEROs carried in a received PathErr message. If no SERO is present in a received PathErr message or when the failure is local, then an SERO that matches the errored LSP or failed branch MUST be added to the outgoing PathErr message.

障害または受信たPathErrメッセージが回復LSPに関連付けられている場合、処理はPath_State_Removedフラグに加えて、Rビットに基づいています。全ての場合において、受信したPathErrメッセージが最初標準的な処理ルールごとに処理され、LSPのために上流のPathErrメッセージの生成をトリガすべき障害または受信したPathErrメッセージは、保護されています。出たPathErrメッセージは、「ルーティング問題/ LSPセグメント保護は失敗しました」のエラーを示すべきです。発信たPathErrメッセージを受信したPathErrメッセージで運ばれる任意SEROsを含まなければなりません。何SEROが受信たPathErrメッセージに存在しない場合、障害がローカルである場合、または、その後エラーが発生したLSP又は故障したブランチと一致SEROは、発信のPathErrメッセージに追加しなければなりません。

When a PathErr message with the Path_State_Removed flag cleared (0) is received, the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0).

クリアPath_State_RemovedフラグとのPathErrメッセージ(0)が受信されると、送信(アップストリーム)のPathErrメッセージはクリアPath_State_Removedフラグ(0)を用いて送信されるべきです。

When a PathErr message for a recovery LSP with the Path_State_Removed flag set (1) is received, the processing node MUST examine the R-bit (as defined below) of the LSP being protected. The R-bit is carried in the PROTECTION object that triggered the initiation of the recovery LSP. When the R-bit is not set (0), the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0). When the R-bit is set (1), the outgoing (upstream) PathErr message MUST be sent with the Path_State_Removed flag set (1).

Path_State_Removedフラグが設定された回復LSPのためのPathErrメッセージは、(1)受信した場合(以下に定義される)、処理ノードは、保護されるLSPのRビットを検査しなければなりません。 Rビットが回復LSPの開始をトリガした保護対象で運ばれます。 Rビットは(0)に設定されていない場合、送信(アップストリーム)のPathErrメッセージはクリア(0)Path_State_Removedフラグと共に送信されるべきです。 Rビットがセットされている場合(1)、送信(アップストリーム)のPathErrメッセージはPath_State_Removedフラグを設定して送信する必要があります(1)。

In all cases where an outgoing (upstream) PathErr message is sent with the Path_State_Removed flag set (1), all path state for the LSP being protected MUST be removed, and the node MUST send a PathTear message downstream on all active branches.

送信(アップストリーム)のPathErrメッセージがPath_State_Removedフラグを設定(1)で送信されるすべての場合において、保護されたLSPのためのすべてのパスの状態が除去されなければならない、ノードは、すべてのアクティブなブランチで下流PathTearメッセージを送らなければなりません。

4.2.2. Resv Message Processing
4.2.2. RESVメッセージ処理

Branch nodes will process Resv messages for both recovery LSPs and LSPs being protected. Resv messages are propagated upstream of branch nodes only after a Resv message is received for the protected LSP. Resv messages on recovery LSPs will typically not trigger transmission of upstream Resv messages (for the LSP being protected). Exceptions to this include when RROs/SRROs are being collected and during certain ADMIN_STATUS object processing. See below for more information on related processing.

ブランチ・ノードは、保護され、回復のLSPとLSPの両方のためのRESVメッセージを処理します。 RESVメッセージは、Resvメッセージが保護LSPのために受信された後にのみブランチノードの上流に伝搬されます。 (LSPが保護されるために)回復のLSP上のRESVメッセージは、典型的には、上流のRESVメッセージの送信をトリガしないであろう。 RROs / SRROsを収集し、特定のADMIN_STATUSオブジェクト処理中にされているとき、これに例外が含まれます。関連する処理の詳細については、下記を参照してください。

4.2.3. Admin Status Change
4.2.3. 管理ステータス変更

In general, objects in a recovery LSP are created based on the corresponding objects in the LSP being protected. The ADMIN_STATUS object is created the same way, but it also requires some special coordination at branch nodes. Specifically, in addition to normal processing, a branch node that receives an ADMIN_STATUS object in a Path message also MUST relay the ADMIN_STATUS object in a Path on every recovery LSP. All Path messages MAY be concurrently sent downstream.

一般に、回復LSP内のオブジェクトはLSPに対応するオブジェクトが保護されているに基づいて作成されます。 ADMIN_STATUSオブジェクトは、同じように作成されますが、それはまた、ブランチノードでいくつかの特別な調整を必要とします。具体的には、通常の処理に加えて、PathメッセージにADMIN_STATUSオブジェクトを受信ブランチノードはまた、すべての回復LSP上のパスにADMIN_STATUSオブジェクトを中継しなければなりません。すべてのPathメッセージを同時に下流送るかもしれません。

Downstream nodes process the change in the ADMIN_STATUS object per [RFC3473], including generation of Resv messages. When the most recently received upstream ADMIN_STATUS object has the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to be received on all branches before relaying a corresponding Resv message upstream.

下流ノードは、RESVメッセージの生成を含む[RFC3473]あたりADMIN_STATUSオブジェクトの変化を処理します。最も最近に受信した上りADMIN_STATUSオブジェクトはRビットが設定されている場合、分岐ノードが上流の対応するResvメッセージを中継する前に、すべてのブランチで受信する一致ADMIN_STATUSオブジェクトとResvメッセージを待ちます。

4.2.4. Recovery LSP Teardown
4.2.4. 回復LSPティアダウン

Recovery LSP removal follows standard procedures defined in [RFC3209] and [RFC3473]. This includes with and without setting the administrative status.

回復LSPの除去は、[RFC3209]及び[RFC3473]で定義された標準的な手順に従います。これは、とし、管理ステータスを設定せずに含まれています。

4.2.4.1. Teardown Without Admin Status Change
4.2.4.1。管理者のステータスを変更せずにティアダウン

The node initiating the teardown originates a PathTear message. Each node that receives a PathTear message processes the PathTear message per standard processing (see [RFC3209] and [RFC2205]), and MUST also relay a PathTear on every recovery LSP. All PathTear messages (received from upstream and locally originated) may be concurrently sent downstream.

ティアダウンを開始するノードはPathTearメッセージを発信します。 PathTearメッセージを受信する各ノードは、標準的な処理ごとにPathTearメッセージを処理([RFC3209]及び[RFC2205]を参照)、また、すべての回復LSPにPathTearを中継しなければなりません。 (上流側とローカル発信から受信した)すべてのPathTearメッセージを同時に下流に送信することができます。

4.2.4.2. Teardown With Admin Status Change
4.2.4.2。管理者ステータスの変更にティアダウン

Per [RFC3473], the ingress node originates a Path message with the D and R bits set in the ADMIN_STATUS object. The admin status change procedure defined in Section 4.2.3 MUST then be followed. Once the ingress receives all expected Resv messages, it MUST follow the teardown procedure described in Section 4.2.4.1.

[RFC3473]あたり、入口ノードはADMIN_STATUSオブジェクトに設定D及びRビットのPathメッセージを発信します。セクション4.2.3で定義された管理上のステータス変更手続きはその後に従わなければなりません。侵入が予想されるすべてのRESVメッセージを受信すると、それは、セクション4.2.4.1で説明したティアダウン手順に従わなければなりません。

4.3. Teardown From Non-Ingress Nodes
4.3. 非進入ノードからティアダウン

As with any LSP, any node along a recovery LSP may initiate removal of the recovery LSP. To do this, the node initiating the teardown sends a PathErr message with the appropriate Error Code and the Path_State_Removed flag cleared (0) toward the LSP ingress. As described above, the recovery LSP ingress will propagate the error to the LSP ingress, which can then signal the removal of the recovery LSP.

任意LSPと同様に、回復LSPに沿った任意のノードが回復LSPの除去を開始することができます。これを行うには、ティアダウンを開始するノードは、LSPのイングレスに向けて適切なエラーコードとクリアPath_State_Removedフラグ(0)とのPathErrメッセージを送信します。上述したように、回復LSPの入口は、その後、回復LSPの除去を知らせることができるLSPの入口、にエラーを伝播します。

It is also possible for the node initiating the teardown to remove a Recovery LSP in a non-graceful manner. In this case, the initiator sends a PathTear message downstream and a PathErr message with a "Confirmation" indication (error code and value set to zero), and the Path_State_Removed flag set (1) toward the LSP ingress node. This manner of non-ingress node teardown is NOT RECOMMENDED because in some cases it can result in the removal of the LSP being protected.

これは、非優雅な方法で回復LSPを削除するにはティアダウンを開始ノードも可能です。この場合、イニシエータは、LSPの入口ノードへ向けて下流PathTearメッセージと「確認」の指示(エラーコード、ゼロに設定された値)とのPathErrメッセージ、及びPath_State_Removedフラグのセット(1)を送信します。いくつかのケースでは、保護されたLSPの除去につながる可能性があるため非入口ノードのティアダウンのこのやり方はお勧めしません。

4.3.1. Modified NOTIFY_REQUEST Object Processing
4.3.1. 修正NOTIFY_REQUESTオブジェクトの処理

A parallel set of rules are applied at branch and merge nodes to enable the branch or merge node to add a NOTIFY_REQUEST object to the Path and Resv messages of protected and recovery LSPs. Branch nodes add NOTIFY_REQUEST objects to Path messages, and merge nodes add NOTIFY_REQUEST objects to Resv messages.

ルールの並列セットは、分岐で適用し、保護と回復LSPのパスとのResvメッセージにNOTIFY_REQUESTオブジェクトを追加するブランチを有効にするか、ノードをマージノードをマージしています。ブランチノードは、PathメッセージにNOTIFY_REQUESTオブジェクトを追加し、マージノードがメッセージをRESVするNOTIFY_REQUESTオブジェクトを追加します。

When a node is branching or merging a recovery LSP, the node SHOULD include a single NOTIFY_REQUEST object in the Path message of the recovery LSP, in the case of a branch node, or the Resv message of the recovery LSP, in the case of a merge node. The notify node address MUST be set to the router address of the processing node.

ノードが回復LSPを分岐または合流された場合、ノードは、の場合には、ブランチノードの場合に回復LSPのPathメッセージ、または回復LSPのResvメッセージに単一NOTIFY_REQUESTオブジェクトを含めるべきですノードをマージします。通知ノードアドレスは、処理ノードのルータのアドレスに設定しなければなりません。

Branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the LSP being protected. For branch nodes, the notify node address is set to the address used in the sender template object of the associated recovery LSP. For merge nodes, the notify node address is set to the address used in the session object of the associated recovery LSP. A locally added NOTIFY_REQUEST object MUST be listed first in an outgoing message; any received NOTIFY_REQUEST objects MUST then be listed in the message in the order that they were received. Note that this can result in a stack (or ordered list) of objects.

ブランチノードをマージはまた、保護されたLSPにNOTIFY_REQUESTオブジェクトを追加する必要があります。ブランチノードのために、通知ノードアドレスは、関連する回復LSPの送信者テンプレートオブジェクトで使用されるアドレスに設定されています。マージノードに、通知ノードアドレスは、関連する回復LSPのセッション・オブジェクトで使用されるアドレスに設定されています。局所的に加えNOTIFY_REQUESTオブジェクトは、発信メッセージに最初にリストされなければなりません。任意受信NOTIFY_REQUESTオブジェクトは、それらが受信された順番でメッセージにリストされなければなりません。これは、オブジェクトのスタック(または順序付きリスト)になることに注意してください。

Normal notification procedures are then followed for the LSP being protected. That is, the notifying node MUST issue a Notify message to the recipient indicated by the notify address of the first listed NOTIFY_REQUEST object. Under local policy control, a node issuing a Notify message MAY also send a Notify message to the Notify Node Address indicated in the last, or any other, NOTIFY_REQUEST object carried in the Path or Resv message.

LSPは、保護されているため、通常の通知手順は、その後に続いています。つまり、通知ノードは、最初にリストされNOTIFY_REQUESTオブジェクトの通知アドレスが示す受信者に通知メッセージを発行しなければなりません。ローカルポリシーの制御下で、通知メッセージを発行するノードは、パスやResvメッセージで運ば最後、または任意の他、NOTIFY_REQUESTオブジェクトで示された通知ノードアドレスに通知メッセージを送信することができます。

Recovery LSP merge and branch nodes remove the object added by the recovery branch or merge node from outgoing Path and Resv messages for the LSP being protected. This is done by removing the NOTIFY_REQUEST object that, in the case of a merge node, matches the source address of the recovery LSP and, in the case of a branch node, matches the tunnel endpoint address of the recovery LSP. The matching NOTIFY_REQUEST object will normally be the first of the listed NOTIFY_REQUEST objects. Note, to cover certain backwards compatibility scenarios, the NOTIFY_REQUEST object SHOULD NOT be removed if it is the sole NOTIFY_REQUEST object.

回復LSPは、マージとブランチノードは、リカバリ支店で追加したオブジェクトを削除または送信パスと保護されたLSPのためのRESVメッセージからノードをマージします。これはブランチノードの場合には、マージノードの場合には、回復LSPの送信元アドレスと一致する、NOTIFY_REQUESTオブジェクトを除去することによって行われ、回復LSPのトンネル終点アドレスと一致します。マッチングNOTIFY_REQUESTオブジェクトは、通常、記載されているNOTIFY_REQUESTオブジェクトの最初であろう。それが唯一のNOTIFY_REQUESTオブジェクトである場合、特定の後方互換性のシナリオをカバーするために、注意してください、NOTIFY_REQUESTオブジェクトは削除しないでください。

Note this requires the following change to [RFC3473], Section 4.2.1:

これは[RFC3473]、セクション4.2.1を次のように変更を必要とします:

o old text: If a message contains multiple NOTIFY_REQUEST objects, only the first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be ignored and SHOULD NOT be propagated.

O古いテキスト:メッセージが複数のNOTIFY_REQUESTオブジェクトが含まれている場合は、唯一の第1の目的は有意義です。後続のNOTIFY_REQUESTオブジェクトは無視してもよいし、伝播されるべきではありません。

o new text: If a message contains multiple NOTIFY_REQUEST objects, only the first object used is in notification. Subsequent NOTIFY_REQUEST objects MUST be propagated in the order received.

O新しいテキスト:メッセージが複数のNOTIFY_REQUESTオブジェクトが含まれている場合は、使用される唯一の第一の目的は、通知です。後続のNOTIFY_REQUESTオブジェクトは、受信順に伝播しなければなりません。

4.3.2. Modified Notify and Error Message Processing
4.3.2. 通知およびエラーメッセージの処理に変更

Branch and merge nodes MUST support the following modification to Notify message processing. When a branch or merge node receives notification of an LSP failure and it is unable to recover from that failure, it MUST notify the node indicated in the first NOTIFY_REQUEST object received in the Path message (for branch nodes) or Resv message (for merge nodes) associated with the LSP.

分岐とマージノードは、メッセージ処理を通知するために、以下の変更をサポートしなければなりません。ブランチまたはノードをマージは、LSP障害の通知を受信し、その障害から回復することができない場合には、マージノードの(ブランチノードの)PathメッセージやResvメッセージ(で受信した第一NOTIFY_REQUESTオブジェクトで示されるノードに通知しなければなりません)LSPに関連しました。

5. Secondary Record Route Objects
5.二次経路記録オブジェクト

Secondary Record Route objects, or SRROs, are used to record the path used by recovery LSPs.

二次経路記録オブジェクト、またはSRROsは、回復のLSPが使用するパスを記録するために使用されています。

5.1. Format
5.1. フォーマット

The format of a SECONDARY_RECORD_ROUTE object is the same as a RECORD_ROUTE object, Class number 21. This includes the definition of subobjects defined for RECORD_ROUTE object. The class of the SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

SECONDARY_RECORD_ROUTEオブジェクトのフォーマットは、クラス番号21これはRECORD_ROUTEオブジェクトに対して定義されたサブオブジェクトの定義を含む、RECORD_ROUTEオブジェクトと同じです。 SECONDARY_RECORD_ROUTEオブジェクトのクラスは、(フォーム11bbbbbbの)201です。

The protection subobject defined above can also be used in SECONDARY_RECORD_ROUTE objects.

上記で定義された保護サブオブジェクトもSECONDARY_RECORD_ROUTEオブジェクトで使用することができます。

5.2. Path Processing
5.2. パス処理

SRROs may be carried in Path messages and indicate the presence of upstream recovery LSPs. More than one SRRO MAY be added and present in a Path message.

SRROsは、Pathメッセージで運ばれ、上流の回復LSPの存在を示すことができます。複数のSRROを加え、Pathメッセージ中に存在することができます。

Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Path message.

任意には、対応する送信Pathメッセージに、変更なしで、SRROはトランジットノードによって送信されなければならない受信しました。

SRROs are inserted in Path messages by recovery LSP merge nodes. The SRRO is created by copying the contents of an RRO received by the recovery LSP into a new SRRO object. This SRRO is added to the outgoing Path message of the recovered LSP. Note that multiple SRROs may be present. The collection of SRROs is controlled via the segment-recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY be set even when SEROs are not used.

SRROsは回復LSPのマージノードでPathメッセージに挿入されています。 SRROは新しいSRROオブジェクトに回復LSPが受信したRROの内容をコピーして作成されます。このSRROが回収LSPの送信するPathメッセージに追加されます。複数SRROsが存在してもよいことに留意されたいです。 SRROsのコレクションはSESSION_ATTRIBUTEオブジェクトにセグメント記録所望のフラグを介して制御されます。このフラグは、SEROsが使用されていない場合でも、設定されるかもしれません。

5.3. Resv Processing
5.3. RESV処理

SRROs may be carried in Resv messages and indicate the presence of downstream recovery LSPs. More than one SRRO MAY be added and present in a Resv message.

SRROsはRESVメッセージで運ばれ、下流の回復LSPの存在を示すことができます。複数SRROを添加し、Resvメッセージ中に存在してもよいです。

Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Resv message. When Resv messages are merged, the resulting merged Resv SHOULD contain all SRROs received in downstream Resv messages.

任意には、対応する送信Resvメッセージに、変更なしで、SRROはトランジットノードによって送信されなければならない受信しました。 RESVメッセージがマージされると、結果はのResv下流RESVメッセージで受信したすべてのSRROsを含むべきで合併しました。

SRROs are inserted in Resv messages by branch nodes of recovery LSPs. The SRRO SHOULD be created with the first two objects being the local node address, followed by a protection subobject with the contents of the recovery LSP's PROTECTION object. The remainder of the SRRO SHOULD be created by copying the contents of the RRO received by the recovery LSP. This SRRO SHOULD be added to the outgoing Resv message of the recovered LSP. Again, multiple SRROs may be present.

SRROsは回復LSPの分岐ノードによってRESVメッセージに挿入されています。 SRROは、最初の2つのオブジェクトが回復LSPの保護対象の内容を保護サブオブジェクトに続くローカルノードアドレス、あることで作成する必要があります。 SRROの残りは回復LSPによって受信されたRROの内容をコピーすることによって作成する必要があります。このSRROを回収LSPの送信Resvメッセージに追加しなければなりません。再び、複数SRROsが存在してもよいです。

If the newly added SRRO causes the message to be too big to fit in a Resv message, SRRO subobjects SHOULD be removed from any present SRROs. When removing subobjects, the first two subobjects and the last subobject in an SRRO MUST NOT be removed. Note that the subobject that followed a removed subobject MUST be updated with the L-bit set (1). If after removing all but the first and last subobjects in all SRROs the resulting message is still too large to fit, then whole SRROs SHOULD be removed until the message does fit.

新しく追加されたSRROメッセージがResvメッセージに収まるには大きすぎるようになる場合、SRROサブオブジェクトは、任意の存在SRROsから削除する必要があります。サブオブジェクトを削除する場合は、SRROの最初の2つのサブオブジェクトと最後のサブオブジェクトが削除されてはなりません。除去されたサブオブジェクトに従ったサブオブジェクトは、Lビットのセット(1)で更新されなければならないことに留意されたいです。すべてSRROsにすべてが、最初と最後のサブオブジェクトを削除した後に結果のメッセージはまだ収まらないほど大きい場合、メッセージがフィットしまで、全体SRROsを削除する必要があります。

6. Dynamic Control of LSP Segment Recovery
LSPセグメント回復の6.動的制御

Dynamic identification of branch and merge nodes is supported via the LSP Segment Recovery Flags carried in the PROTECTION object. The LSP Segment Recovery Flags are carried within one of the Reserved fields defined in the PROTECTION object defined in [RFC4872]. LSP Segment Recovery Flags are used to indicate when LSP segment recovery is desired. When these bits are set, branch and merge nodes are dynamically identified.

動的分岐の識別およびノー​​ドをマージは、保護対象で運ばLSPセグメント回復フラッグを経由してサポートされています。 LSPセグメント回復フラグは[RFC4872]で定義された保護対象で定義された予約済みフィールドのうちの1つの中に運ばれます。 LSPセグメント回復フラッグは、LSPセグメント回復が望まれる場合を示すために使用されています。これらのビットが設定されている場合、ブランチとマージノードを動的に識別されます。

Note, the procedures defined in this section parallel the explicit control procedures defined above in Section 4.2. The primary difference is in the creation of a recovery LSP's ERO.

このセクションで定義された手順は、セクション4.2で上記に定義された明示的な制御手順を平行に、留意されたいです。主な違いは、回復LSPのEROの作成です。

6.1. Modified PROTECTION Object Format
6.1. 変更された保護対象のフォーマット

LSP Segment Recovery Flags are carried in the PROTECTION object of the same C-Type defined in [RFC4872]. The format of the flags are:

LSPセグメント回復フラグは[RFC4872]で定義された同一のC型の保護対象で運ばれます。フラグのフォーマットは以下のとおりです。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             | Class-Num(37) | C-Type (2)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|P|N|O| Reserved  | LSP Flags |     Reserved      | Link Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|   Reserved    | Seg.Flags |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

In-Place (I): 1 bit

インプレース(I):1ビット

When set (1) indicates that the desired segment recovery type indicated in the LSP Segment Recovery Flag is already in place for the associated LSP.

設定されている場合(1)LSPセグメント回復フラグに示される所望のセグメントのリカバリ型が関連LSPのための場所に既にあることを示しています。

Required (R): 1 bit

必須(R):1ビット

When set (1) indicates that failure to establish the indicated protection should result in a failure of the LSP being protected.

セット(1)示された保護を確立するための障害が保護されたLSPの故障をもたらすはずであることを示している場合。

Segment Recovery Flags (Seg.Flags): 6 bits

セグメント回復フラッグ(Seg.Flags):6ビット

This field is used to indicate when an upstream node desires LSP Segment recovery to be dynamically initiated where possible. The values used in this field are identical to the values defined for LSP Flags; see [RFC4872].

このフィールドは、上流ノードが動的に可能な限り開始されるLSPセグメント回復を希望する場合を示すために使用されます。この分野で使用される値は、LSPのフラグに定義された値と同一です。 [RFC4872]を参照してください。

See [RFC4872] for the definition of other fields.

他のフィールドの定義については、[RFC4872]を参照してください。

6.2. Dynamic Control Procedures
6.2. 動的制御手順

LSP Segment Recovery Flags are set to indicate that LSP segment recovery is desired for the LSP being signaled. The type of recovery desired is indicated by the flags. The decision to set the LSP Segment Recovery Flags is a local matter and outside the scope of this document. A value of zero (0) means that no dynamic identification of segment recovery branch nodes are needed for the associated LSP. When the In-Place bit is set, it means that the desired type of recovery is already in place for that particular LSP.

LSPセグメント回復フラグは、LSPセグメント回復が通知されるLSPのために望まれることを示すように設定されています。所望の回復の種類がフラグで示されています。 LSPセグメント回復フラグを設定するという決定は、ローカルの問題と、この文書の範囲外です。ゼロ(0)の値は、セグメント回復ブランチノードの動的な識別が関連LSPのために必要とされないことを意味します。インプレースのビットが設定されている場合、それは回復の所望のタイプがその特定のLSPのための場所に既にあることを意味します。

A transit node receiving a Path message containing a PROTECTION object with a non-zero LSP Segment Recovery Flags value and the In-Place bit clear (0) SHOULD consider if it can support the indicated recovery type and if it can identify an appropriate merge node for a recovery LSP. Dynamic identification MUST NOT be done when the processing node is identified as a branch node in an SERO. If a node is unable to provide the indicated recovery type or identify a merge node, the Path message MUST be processed normally, and the LSP Segment Recovery Flags MUST NOT be modified.

非ゼロLSPセグメント回復フラグの値と明確なインプレースのビット(0)が示されたリカバリタイプをサポートできるかどうか検討する必要があり、それが適切なマージノードを識別することができる場合による保護オブジェクトを含むPathメッセージを受信したトランジットノード回復LSPのために。処理ノードはSEROでブランチノードとして識別されたときに動的識別が行われてはいけません。ノードがマージノードを示すリカバリ型を提供するか、または特定することができない場合、Pathメッセージを正常に処理されなければならない、およびLSPセグメント回復フラグは変更してはいけません。

When a node dynamically identifies itself as a branch node and identifies the merge node for the type of recovery indicated in the LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The dynamically identified information, together with the Path message of LSP being recovered, is used to create the recovery LSP.

ノードが動的にブランチノードとして自身を識別し、LSPセグメント回復フラグで示さ回復のタイプのマージノードを識別すると、それはセットアップに回復LSPを試みます。動的に識別された情報は、LSPのPathメッセージが回収されるとともに、回復LSPを作成するために使用されます。

The Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. Certain objects are replaced or modified in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. The Session object MUST be updated to use the address of the dynamically identified merge node as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object is updated with the In-Place bit set (1). Any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MAY be created based on any path information dynamically computed by the local node.

回復LSPのためのPathメッセージは、保護されたLSPの受信Pathメッセージで運ばれたオブジェクトをクローニングすることによってブランチノードで作成されます。特定のオブジェクトは、交換または回復LSPの送信するPathメッセージで変更されています。 SENDER_TEMPLATEオブジェクトはローカルノード上で(そのトンネルの送信元アドレスフィールド内の)アドレスを使用するように更新されなければならない、とLSP IDは、一意性を確保するために更新されなければなりません。セッションオブジェクトがトンネル終点アドレスとして動的に識別されたマージノードのアドレスを使用するように更新する必要があり、トンネルIDを更新することができる、拡張トンネルIDは、ローカル・ノードのアドレスに設定しなければなりません。保護対象は、インプレース・ビット・セットで更新される(1)。入ってくるPathメッセージ中に存在する任意のRROsとエロスは回復LSPに含んではいけません。新しいEROが動的ローカルノードによって計算されたパス情報に基づいて作成されてもよいです。

The resulting Path message is used to create the recovery LSP. While the recovery LSP exists, the PROTECTION object in the original Path message (unless overridden by local policy) MUST also be updated with the In-Place bit set (1). From this point on, Standard Path message processing is used in processing the resulting and original Path messages.

その結果Pathメッセージは回復LSPを作成するために使用されます。 LSPが存在して回復しながら、元のPathメッセージにおける保護対象は、(ローカルポリシーによって上書きされない限り)はインプレースのビットのセット(1)で更新されなければなりません。この点から、標準パスメッセージ処理は、結果として得られると、元のPathメッセージを処理する際に使用されます。

The merge node of a dynamically controlled recovery LSP SHOULD reset (0) the In-Place bit in the PROTECTION object of the outgoing Path message associated with the terminated recovery LSP.

動的に制御回復LSPのマージノードを終了回復LSPに関連付けられた送信Pathメッセージの保護対象に(0)インプレースのビットをリセットする必要があります。

Unlike with explicit control, if the creation of a dynamically identified recovery LSP fails for any reason, the recovery LSP is removed, and no error message or indication is sent upstream. With this exception, all the other procedures for explicitly controlled recovery LSPs apply to dynamically controlled recovery LSPs. These other procedures are defined above in Sections 4.2.1 through 4.2.4.

動的に識別された回復LSPの作成が何らかの理由で失敗した場合、明示的な制御とは異なり、回復LSPを除去し、エラーメッセージまたは指示は上流送信されません。この例外を除いて、明示的に制御回復のLSPのための他のすべての手順は、動的に回復LSPを制御するために適用されます。これらの他の手順は、セクション4.2.4を介して4.2.1に上記で定義されています。

7. Updated RSVP Message Formats
7.更新RSVPメッセージ形式

This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs.

この文書によって修正されたこのセクションでは、RSVPメッセージに関連するフォーマットを提示します。それらが異なる場合には、単方向のLSPのためのフォーマットは、双方向のLSPとは別に提示されています。

The format of a Path message is as follows:

次のようにPathメッセージの形式は次のとおりです。

   <Path Message> ::=   <Common Header> [ <INTEGRITY> ]
                        [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                        [ <MESSAGE_ID> ]
                        <SESSION> <RSVP_HOP>
                        <TIME_VALUES>
                        [ <EXPLICIT_ROUTE> ]
                         <LABEL_REQUEST>
                         [ <PROTECTION> ]
                         [ <LABEL_SET> ... ]
                         [ <SESSION_ATTRIBUTE> ]
                         [ <NOTIFY_REQUEST> ... ]
                         [ <ADMIN_STATUS> ]
                         [ <ASSOCIATION> ... ]
                         [ <SECONDARY_EXPLICIT_ROUTE> ... ]
                         [ <POLICY_DATA> ... ]
                         <sender descriptor>
        

The format of the sender description for unidirectional LSPs is:

単方向のLSPの送信者の記述の形式は次のとおりです。

   <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                            [ <ADSPEC> ]
                            [ <RECORD_ROUTE> ]
                            [ <SUGGESTED_LABEL> ]
                            [ <RECOVERY_LABEL> ]
                            [ <SECONDARY_RECORD_ROUTE> ... ]
        

The format of the sender description for bidirectional LSPs is:

双方向のLSPの送信者の記述の形式は次のとおりです。

   <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                            [ <ADSPEC> ]
                            [ <RECORD_ROUTE> ]
                            [ <SUGGESTED_LABEL> ]
                            [ <RECOVERY_LABEL> ]
                            <UPSTREAM_LABEL>
                            [ <SECONDARY_RECORD_ROUTE> ... ]
        

The format of a PathErr message is as follows:

以下の通りのPathErrメッセージの形式は次のとおりです。

   <PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <SESSION> <ERROR_SPEC>
                         [ <ACCEPTABLE_LABEL_SET> ... ]
                         [ <SECONDARY_EXPLICIT_ROUTE> ... ]
                         [ <POLICY_DATA> ... ]
                         <sender descriptor>
        

The format of a Resv message is as follows:

次のようにResvメッセージの形式は次のとおりです。

   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                         [ <NOTIFY_REQUEST> ... ]
                         [ <ADMIN_STATUS> ]
                         [ <POLICY_DATA> ... ]
                         <STYLE> <flow descriptor list>
        
   <flow descriptor list> ::= <FF flow descriptor list>
                            | <SE flow descriptor>
        
   <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
                            <LABEL> [ <RECORD_ROUTE> ]
                            [ <SECONDARY_RECORD_ROUTE> ... ]
                            | <FF flow descriptor list>
                            <FF flow descriptor>
        
   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                            [ <RECORD_ROUTE> ]
                            [ <SECONDARY_RECORD_ROUTE> ... ]
        
   <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
        
   <SE filter spec list> ::= <SE filter spec>
                            | <SE filter spec list> <SE filter spec>
        
   <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                            [ <SECONDARY_RECORD_ROUTE> ... ]
        
8. Security Considerations
8.セキュリティの考慮事項

This document introduces new message objects for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane.

この文書は、新しいメッセージが[RFC3473]をGMPLSシグナリングで使用するためにオブジェクトを紹介します。これは、任意の新しいシグナリングメッセージを紹介し、また制御プレーンに隣接するLSRの間の関係は変更されません。

The procedures defined in this document result in an increase in the amount of topology information carried in signaling messages since the presence of SEROs and SRROs necessarily means that there is more information about LSP paths carried than in simple EROs and RROs. Thus, in the event of the interception of a signaling message, slightly more could be deduced about the state of the network than was previously the case, but this is judged to be a very minor security risk as this information is already available via routing.

SEROsとSRROsの存在のでシグナリングメッセージで運ばれたトポロジー情報の量の増加は、この文書の結果で定義された手順は、必ずしも簡単エロスとRROsよりも実施LSPパスの詳細情報があることを意味します。したがって、シグナリングメッセージの傍受の場合には、わずかにより以前にそうであったよりも、ネットワークの状態について推論することができるが、この情報が既にルーティングを介して利用可能であるように、これは非常に軽微なセキュリティ上のリスクがあると判断されます。

Otherwise, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations.

そうでない場合は、この文書には、追加のセキュリティ問題も紹介しません。関連するセキュリティの考慮事項については、[RFC3473]を参照してください。

9. IANA Considerations
9. IANAの考慮事項

IANA has assigned the following values for the namespaces defined in this document and reviewed in this section.

IANAは、この文書で定義された名前空間の次の値を割り当て、このセクションで検討しています。

9.1. New Association Type Assignment
9.1. 新しい関連タイプの割り当て

IANA has made the following assignment to the "GMPLS Signaling Parameters" Registry (see [RFC4872]) located at http://www.iana.org/assignments/gmpls-sig-parameters.

IANAはhttp://www.iana.org/assignments/gmpls-sig-parameters位置「GMPLSシグナリングパラメータ」レジストリ([RFC4872]を参照)、次の割り当てを行っています。

      Value       Type
      -----       ----
        2         Resource Sharing (R) [RFC4873]
        
9.2. Definition of PROTECTION Object Reserved Bits
9.2. 保護対象予約ビットの定義

This document defines bits carried in the Reserved field of the PROTECTION object defined in [RFC4872]. As no IANA registry for these bits is requested in [RFC4872], no IANA action is required related to this definition.

このドキュメントは[RFC4872]で定義された保護対象のReservedフィールドで運ばれたビットを定義します。これらのビットのためのIANAレジストリが[RFC4872]で要求されていないとして、何のIANA動作は、この定義に関連した必要とされません。

9.3. Secondary Explicit Route Object
9.3. 二次明示的なルートオブジェクト

IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.

IANAはhttp://www.iana.org/assignments/rsvp-parametersにある「RSVPパラメータ」レジストリの「クラス名、クラス番号、およびクラスの型」セクションで、次の割り当てを行っています。

A new class named SECONDARY_EXPLICIT_ROUTE has been created in the 11bbbbbb range (200) with the following definition: Class Types or C-types:

クラスの型やC-タイプ:SECONDARY_EXPLICIT_ROUTEという名前の新しいクラスは、次のように定義して11bbbbbb範囲(200)内に作成されています。

Same values as EXPLICIT_ROUTE object (C-Num 20)

EXPLICIT_ROUTEオブジェクトと同じ値(C-民20)

For Class 1, C-Type 1, the following additional Subobject type is defined:

クラス1は、C 1型、次の追加のサブオブジェクトタイプが定義されます。

37 PROTECTION [RFC4873]

37 PROTECTION [RFC4873]

9.4. Secondary Record Route Object
9.4. 二次経路記録オブジェクト

IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.

IANAはhttp://www.iana.org/assignments/rsvp-parametersにある「RSVPパラメータ」レジストリの「クラス名、クラス番号、およびクラスの型」セクションで、次の割り当てを行っています。

A new class named SECONDARY_RECORD_ROUTE has been created in the 11bbbbbb range (201) with the following definition:

SECONDARY_RECORD_ROUTEという名前の新しいクラスは、次のように定義された11bbbbbb範囲(201)内に作成されています。

Class Types or C-types:

クラスの型やC-種類:

Same values as RECORD_ROUTE object (C-Num 21)

RECORD_ROUTEオブジェクトと同じ値(C-民21)

For Class 1, C-Type 1, the following additional Subobject type is defined:

クラス1は、C 1型、次の追加のサブオブジェクトタイプが定義されます。

37 PROTECTION [RFC4873]

37 PROTECTION [RFC4873]

9.5. New Error Code
9.5. 新しいエラーコード

IANA has made the following assignments in the "Routing Problem" subsection of "Error Codes and Values" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.

IANAはhttp://www.iana.org/assignments/rsvp-parametersにある「RSVPパラメータ」レジストリの「エラーコードと値」セクションの「ルーティング問題」のサブセクションでは、次の割り当てを行っています。

21 = LSP Segment Protection Failed [RFC4873]

21 = LSPセグメント保護は[RFC4873]を失敗

9.6. Use of PROTECTION Object C-type
9.6. 保護対象のC型の使用

This document modifies the PROTECTION object, class number 37, C-Type 2 (defined in Section 14.1. of [RFC4872]).

この文書は、保護オブジェクト、クラス番号37を変更し、C-2型(セクション14.1で定義された。の[RFC4872])。

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.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル(RSVP) - バージョン1の機能的な仕様"、RFC 2205、1997年9月。

[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。

[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング(GMPLS)機能説明シグナリング"、RFC 3471、2003年1月。

[RFC3473] Berger, L., Ed., "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月。

[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.

[RFC4872]ラング、JP、エド。、Rekhter、Y.、エド。、およびD. Papadimitriou、エド。、 "エンドツーエンド一般化マルチプロトコルラベルをサポートするRSVP-TE拡張(GMPLS)回復の切り替え" 、RFC 4872、2007年5月。

10.2. Informative References
10.2. 参考文献

[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

[RFC4090]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。

[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification," RFC 4426, March 2006.

[RFC4426]ラング、J.、エド。、Rajagopalan、B.、エド。、およびD. Papadimitriou、エド。、RFC 4426、2006年3月 "一般化マルチプロトコルラベルは(GMPLS)回復機能仕様を、スイッチング"。

[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.

[RFC4427]マニー、E.、エド。、およびD. Papadimitriou、エド。、 "リカバリ(保護と回復)一般化マルチプロトコルラベルスイッチング(GMPLS)のための用語"、RFC 4427、2006月。

Authors' Addresses

著者のアドレス

Lou Berger LabN Consulting, L.L.C.

ルー・バーガーLabnコンサルティング、L.L.C.

Phone: +1 301-468-9228 EMail: lberger@labn.net

電話:+1 301-468-9228電子メール:lberger@labn.net

Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean VA, 22102

イゴールBryskin ADVA光学7926ジョーンズ支店ドライブスイート615マクリーンVA、22102

EMail: IBryskin@advaoptical.com

メールアドレス:IBryskin@advaoptical.com

Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium

ディミトリスPapadimitriouアルカテルフランシスVellesplein 1 B-2018アントワープ、Velgiom

Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be

電話:+32 3 240-8491 Eメール:dimitri.papadimitriou@alcatel-lucent.be

Adrian Farrel Old Dog Consulting

エードリアンファレル古い犬のコンサルティング

Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk

電話:+44(0)1978 860944 Eメール:adrian@olddog.co.uk

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機能のための基金は現在、インターネット協会によって提供されます。