RFC4873 日本語訳
4873 GMPLS Segment Recovery. L. Berger, I. Bryskin, D. Papadimitriou,A. Farrel. May 2007. (Format: TXT=56919 bytes) (Updates RFC3473, RFC4872) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループL.バーガー要求をネットワークでつないでください: 4873のLabNコンサルティングアップデート: 3473、4872I.Bryskinカテゴリ: 犬のコンサルティング2007年5月に年取った標準化過程の光学D.PapadimitriouアルカテルのA.ADVAファレル
GMPLS Segment Recovery
GMPLSセグメント回復
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 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(Multi-プロトコルLabel Switchingを一般化する)RSVP-TE(リソースReserVationプロトコル--トラフィックEngineering)のためにラベル切り換えられた経路(LSP)セグメント保護と回復をサポートするために拡大に合図しながら、プロトコルの特定の手順について説明します。 Endから終わりへのGMPLS Recovery(RFC4872)において補足となって、これらの拡大がRSVP-TE Extensionsと一致させていることを意図します。 含意と相互作用は速いことでコースを変更します。また、扱われます。 また、このドキュメントはNOTIFY_REQUESTオブジェクトの取り扱いをアップデートします。
Berger, et al. Standards Track [Page 1] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[1ページ]。
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. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. セグメント回復…4 2.1. セグメント保護…6 2.2. セグメントのコースを変更するのと王政復古…6 3. 協会オブジェクト…6 3.1. 形式…7 3.2. 手順…7 3.2.1. 回復タイプ処理…7 3.2.2. リソース・シェアリング協会タイプ処理…7 4. LSPセグメント回復の明白なコントロール…8 4.1. セカンダリ明白なルートオブジェクト形式…8 4.1.1. 保護Subobject…8 4.2. 明白なコントロール手順…9 4.2.1. 支店失敗取り扱い…10 4.2.2. Resvメッセージ処理…11 4.2.3. アドミン状態変化…12 4.2.4. 回復LSP分解…12 4.3. 非イングレスノードからの分解…12 4.3.1. 変更されて、_要求オブジェクト処理に通知してください…13 4.3.2. そして、変更されて、通知してください、エラーメッセージ処理…14 5. セカンダリ記録的なルートオブジェクト…14 5.1. 形式…14 5.2. 経路処理…15 5.3. Resv処理…15 6. LSPセグメント回復の動的制御…16 6.1. 保護オブジェクト形式を変更します…16 6.2. 動的制御手順…17 7. RSVPメッセージ・フォーマットをアップデートします…18 8. セキュリティ問題…20 9. IANA問題…21 9.1. 新連合タイプ課題…21 9.2. 保護オブジェクトの定義はビットを予約しました…21 9.3. セカンダリ明白なルートオブジェクト…21 9.4. セカンダリ記録的なルートオブジェクト…21 9.5. 新しいエラーコード…22 9.6. 保護オブジェクトC-タイプの使用…22 10. 参照…23 10.1. 標準の参照…23 10.2. 有益な参照…23
Berger, et al. Standards Track [Page 2] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[2ページ]。
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]は終わらせる終わりとセグメントベースのアプローチを含む複数のタイプの保護をカバーしています。 「Endから終わりへのGeneralized Multi-プロトコルLabel Switching(GMPLS)回復のSupportのRSVP-TE Extensions」[RFC4872]は、複数のタイプの回復をサポートするために1セットの拡大を定義します。 サポートしているタイプは+1 双方向の保護(付加的なトラフィック(付加的なトラフィックがある1:N保護を含んでいる)があるLSP保護)が付加的なトラフィックなしでLSP再ルーティングをあらかじめ計画していた(共有されたメッシュを含んでいて)1+1単方向/1、完全な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ネットワークに提供します。 速いことのメソッドが別ルートで送る2は[RFC4090]で定義されます。 1〜1つのバックアップメソッドがそれぞれの保護されたLSPのためにそれぞれの潜在的ポイントの局部的修繕で回り道LSPsを作成します。 施設バックアップメソッドは、複数のLSPsによって共有されて、ラベルの積み重ねを使用する起こりうる失敗ポイントを保護するために迂回トンネルを作成します。 どちらのアプローチも[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(基礎)の一部でそうします。 (d) 拡大は(a) 必要なLSPセグメント保護タイプのシグナリングを許容します、セグメント保護が始まって、止まる任意に特定する(b)上流ノード、ホップの任意の識別が保護セグメントで使用した(c)、経路の報告は以前はよく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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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]と同様に。
Berger, et al. Standards Track [Page 3] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[3ページ]。
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
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が[A、B、C、D、E、F]の働く経路を使用するなら、経路[C、G、I、E]に沿ってa保護か回復LSPを確立できます。 このLSPは長さC、Dの上で失敗から守ります、そして、D、保護/回復のノードD.Thisフォームの失敗と同様にEはSegment ProtectionとSegment王政復古、またはSegment Recoveryとまとめて呼ばれます。 保護か回復を提供するLSPはセグメント保護と呼ばれたLSPであるかセグメント回復がLSPです。 存在というセグメントをカバーするのにおいて中古の用語「セグメント回復LSP」保護LSPかセグメント回復LSP。 「ブランチノード」という用語は、回復LSPを開始するノード、例えば上の図のノードCを参照するのに使用されます。 これは[RFC4090]で使用される局部的修繕(PLR)まで同等です。 [RFC4090]のように、「ノードを合併する」という用語は、回復LSPを終えるノード、例えば上の図のノードEを参照するのに使用されます。
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つ以上のセグメントの回復LSPsを使用することでセグメント保護か回復が合図されます。 それぞれのセグメント回復LSPは独立しているLSPとして合図されます。 明確に、Sender_Templateオブジェクトは回復経路を溯源するノードのIPアドレスを使用します、例えば、上のトポロジーのノードC、そして、Sessionオブジェクトが回復経路(例えば上で見せられたノードE)を終えるノードのIPアドレスを含んでいます。 決められた一定の要求が全くLSP ID値、Tunnel ID、およびExtended Tunnel IDにありません。 -通常、これらの分野への値は選択されて、以前造のための考慮を含んでいて、概念を知らせてください([RFC3209]で説明されるように)。 セグメント回復LSPsを処理するとき、中間的ノードは標準のシグナリング手順に従います。 セグメント回復LSPは、終わりまでのセグメントか終わりの保護/回復を使用することでそれ自体で保護されるかもしれません。 PSC環境で、[RFC4090]あたりのSender_TemplateとSessionオブジェクトを組み立てるのが望ましいかもしれないことに注意してください。
Berger, et al. Standards Track [Page 4] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[4ページ]。
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]が使用されていないとき、他のLSPsとセグメント回復LSPsの間の協会は、[RFC4872]で定義されたASSOCIATIONオブジェクトを使用することで示されます。 ASSOCIATIONオブジェクトは、彼らが保護しているLSPに回復LSPsを関連づけるのに使用されます。 LSPs、およびプライマリの、そして、セカンダリのLSPsを扱って、保護するのは、[RFC4872]で説明されるようにLSP Statusを使用することで特定されます。 PROTECTIONオブジェクトの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セグメント保護ビットをPROTECTIONオブジェクトにはめ込むことによってダイナミックにブランチを特定して、ポイントを合併することを許可できます。 これらのビットは以下で定義されます。
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の終点を特定できます。 これは新しいオブジェクトを使用するのに優れています。 このオブジェクトは、Explicit Route Object(ERO)と同じ形式を使用して、Secondary Explicit Routeオブジェクト(SERO)と呼ばれます。 セクション4.1を見てください。 また、SEROsは、提供するために保護か回復のタイプを示すために新しい「副-オブジェクト」をサポートします。 最小限では、SEROは回復LSPの創始者、保護/回復タイプ、およびターミネータを示すでしょう。 任意に、ERO意味論([RFC3209]を見る)を使用できる規格と明らかに回復LSPを制御するSERO。 Secondary Record Routeオブジェクト(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のためにPROTECTIONオブジェクトを作成するのに新しい保護「副-オブジェクト」を使用します。 また、回復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はPathメッセージで回復LSPを終えるノードと、マージノードと、出口の間まで運ばれます。 SRROsはブランチノードとイングレスの間のResvメッセージで使用されます。 関連回復LSPに関するPathメッセージを新しいSRROオブジェクトにRROを回避するLSPがSRROを作成する回復のマージノード。 また、回復LSPのPathメッセージの現在のどんなSRROsもコピーされます。 関連回復LSPに関するResvメッセージを新しいSRROオブジェクトにRROを回避するLSPが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]に従って、1個のNOTIFY_REQUESTオブジェクトだけが、重要であり、伝播されるべきです。 追加NOTIFY_REQUESTオブジェクトは、回復LSPブランチノードを特定するのに使用されます。
Berger, et al. Standards Track [Page 5] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[5ページ]。
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.
終わりから終わりへの保護のための3つのアプローチが[RFC4872]で定義されます: 1+1単方向の保護(セクション5)、1つの+1双方向の保護(セクション6)、および付加的なトラフィックとの1:1保護(セクション7)。 これらの保護アプローチのセグメント保護フォームは終わりから終わりへの彼らの対応者のようにすべて作動します。 それぞれがまさしく終わりから終わりへの対応者のように振る舞って、保護LSPが保護する例外と共に、aだけが働くLSPを分配します。 セグメント保護LSPのときに使用されるべき保護のタイプは示されます、保護LSPのイングレスに、セクション4.1で定義された保護SERO subobjectを使用して。
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+1Bidirectional保護と1:1Protection With Extra-トラフィックのためのオーバースイッチ処理は終わりから終わりへの保護フォームと同じ手順に従います。 詳細に関して[RFC4872]のセクション6.2と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.
3つのコースを変更するのと回復アプローチが[RFC4872]で定義されます: 付加的なトラフィックなしで(セクション8)、共有されたメッシュ王政復古(セクション9)が(セクション11)を別ルートで送る(完全)のLSPであると別ルートで送ります。 保護のように、これらのアプローチはセグメントベースでサポートされます。 コースを変更するのと回復のフォームがちょうど終わりから終わりへの彼らの対応者のように操作するセグメント、回復LSPが回復する例外と共に、aだけが働くLSPを分配します。 セグメント回復LSPのときに使用されるべきコースを変更するか回復のタイプは示されます、回復LSPのイングレスに、新しい保護SERO subobjectを使用して。
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オブジェクトはセグメント保護LSPsの協会に使用されます。 ASSOCIATIONオブジェクトは[RFC4872]で定義されます。 本書では、私たちは以前開閉していた状態でサポートする新しいAssociation Type分野価値を定義します。 [RFC4872]で定義された書式と手順は別の方法で変更されません。
Berger, et al. Standards Track [Page 6] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[6ページ]。
3.1. Format
3.1. 形式
Association Type: 16 bits
協会タイプ: 16ビット
Value Type
----- ----
2 Resource Sharing (R)
値のタイプ----- ---- 2 リソース・シェアリング(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].
ASSOCIATIONオブジェクトは、異なったLSPsを互いに関連づけるのに使用されます。 保護と回復文脈では、オブジェクトは、それが保護しているLSPに回復LSPを関連づけるのに使用されます。 また、ASSOCIATIONオブジェクトは、以前開閉している間、リソース・シェアリングをサポートするのに使用されます。 [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]で定義されたものと同じですが、処理と識別はセグメント回復LSPsに関して起こります。 これが、タイプ回復の複数のASSOCIATIONオブジェクトが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.
値のResource SharingとAssociation TypeがあるASSOCIATIONオブジェクトは、休みの前に造の間、リソース・シェアリングを可能にするのに使用されます。 以前開閉している間のリソース・シェアリングは[RFC3209]で定義されます。 定義されたサポートは同じLSP出口を共有するLSPsと共に働いているだけです。 セグメント回復LSPsの導入では、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.
LSPsの関連セットの向こう側にリソース・シェアリングを示したがっているとき、ノードはResource Sharing Association Typeが送信するPathメッセージにあるASSOCIATIONオブジェクトを含んでいます。 Association Sourceは起因するノードのルータアドレスに用意ができています。 唯一LSPsの協会を特定する値にAssociation IDを設定しなければなりません。 これは働くLSPのLSP IDに設定されるかもしれません。 いったん含まれていると、Resource Sharing Association Type SHOULDがLSPに関連しているPathメッセージから取り外されていない状態で、ASSOCIATIONオブジェクトです。
Berger, et al. Standards Track [Page 7] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[7ページ]。
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.
Resource SharingタイプがあるASSOCIATIONオブジェクトを含むノードには合っている状態がないPathメッセージを処理するどんなノードも合っているAssociation Type、Association Source、およびAssociation ID値がないかどうか既存のLSPsを調べます。 何かマッチが見つけられるなら、[RFC3209]はリソース・シェアリングSHOULDを流行に合わせます。新しくて古いLSPsの間に提供します。 追加詳細に関して[RFC3209]を見てください。
4. Explicit Control of LSP Segment Recovery
4. LSPセグメント回復の明白なコントロール
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.
セカンダリExplicit Routeオブジェクト、またはSEROsが本書では定義されます。 それらは、ブランチを示して、回復LSPsのノードを合併するのに使用されるかもしれません。 また、彼らは回復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オブジェクトのクラスは200(フォーム11bbbbbbの)です。
4.1.1. Protection Subobject
4.1.1. 保護Subobject
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のためにPROTECTIONオブジェクトを作成するのに使用されます。 保護「副-オブジェクト」に関連する特定の手順をセクション4.2に提供します。 保護「副-オブジェクト」は、ExplicitとRecord Routeオブジェクトによる使用には有効でなく、それらのオブジェクトに含まれてはいけません。
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| 予約されます。| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 保護オブジェクトコンテンツ| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L-bit
L-ビット
This is defined in [RFC3209] and MUST be set to zero for
protection subobjects.
これを[RFC3209]で定義されて、保護のために「副-オブジェクト」のゼロを合わせるように設定しなければなりません。
Berger, et al. Standards Track [Page 8] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[8ページ]。
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.
含まれているPROTECTIONのC-タイプは反対します。
PROTECTION Object Contents
保護オブジェクトコンテンツ
The contents of the PROTECTION object, with the format matching
the indicated C-Type, excluding the object header.
オブジェクトヘッダーを除いて、形式が示されたC-タイプに合っているPROTECTIONオブジェクトのコンテンツ。
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 MAYよりいてください。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.
SEROは、ブランチを示して、回復LSPのノードを合併するために、回収される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 SHOULDは少なくとも3「副-オブジェクト」を含んでいます。 最初の「副-オブジェクト」は回復LSP、すなわち、セグメントブランチノードを溯源することになっているノードを示さなければなりません。 アドレスはSHOULDを使用しました、また、EROか別のSEROに記載されてください。 これは、LSP経路に沿ってブランチノードがあるのを確実にします。 第2subobject SHOULDは、保護「副-オブジェクト」であり、回復LSPによって提供されるように、保護か回復を示すはずです。 保護「副-オブジェクト」が存在しているとき、保護「副-オブジェクト」におけるLSP Segment Recovery Flagsを無視しなければなりません。 SERO MUSTの最終的な「副-オブジェクト」は、回復LSPのマージノードであり、L-ビットを設定させるかもしれません。 標準のERO subobjectsは保護「副-オブジェクト」と最終的な「副-オブジェクト」の間に挿入されるかもしれません。 これらの「副-オブジェクト」は、ゆるいか、または厳しいかもしれません。
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
1つを含むPathメッセージを受け取るノードかSEROs SHOULDがそれであるなら見るために各SEROを調べる以上が地方支店ポイントを示します。 これ
Berger, et al. Standards Track [Page 9] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[9ページ]。
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.
それぞれの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を作成するために回収されるLSPに関するPathメッセージと共に情報を提供します。 回復LSPへのPathメッセージは、ブランチノードで保護されるLSPの入って来るPathメッセージで運ばれたオブジェクトのクローンを作ることによって、作成されます。 回復LSPの送信するPathメッセージで、あるオブジェクトを取り替えるか、または変更します。 ローカルのノード、およびLSP ID MUSTでアドレスを使用する(Tunnel Sender Address分野で)ためにSender_テンプレートオブジェクトをアップデートしなければなりません。ユニークさを確実にするのをアップデートします。 トンネル終点アドレス、トンネルIDをアップデートするかもしれなくて、ローカルのノードアドレスに拡張トンネルIDを設定しなければならないのでSEROの最終的な「副-オブジェクト」で示されたアドレスを使用するためにSessionオブジェクトをアップデートしなければなりません。 存在しているとき、PROTECTIONオブジェクトを合っているSERO保護「副-オブジェクト」のコンテンツに取り替えます。 すべての場合では、新しいPROTECTIONオブジェクトのR-ビットはリセット(0)です。 回復LSPに入って来るPathメッセージの現在の少しのRROsとEROsも含んではいけません。 新しいERO MUSTが含まれていて、SEROのコンテンツで、それは地方支店を示しました。 すべてのEROsのように、どんなローカルの情報(ローカルアドレスとどんな保護「副-オブジェクト」も)も回復LSPの送信するPathメッセージで運ばれたEROで運ばれません。 回復LSPの送信するPathメッセージから地方支店を示したSEROを省略しなければなりません。 デフォルトで他のすべての容認されたSEROsが回復LSPの送信するPathメッセージで渡されることに注意してください。 SEROsは省略されるかもしれません、保護されるLSPへの送信するPathメッセージと同様に回復LSPの送信するPathメッセージから、SEROが送信する経路メッセージに関連しないと。
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を作成するのに使用されます。 この地点から先は、Standard Pathメッセージ処理は結果として起こる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
失敗か受信されたPathErrメッセージが保護されるLSPに関連しているとき、出来事は最初に、標準の処理単位で処理されます。
Berger, et al. Standards Track [Page 10] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[10ページ]。
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メッセージの世代を含んでいます。 局所制御不能かPathErrメッセージのためPath_州_Removed旗のセット(1)でLSP状態を取り除くとき、ノードは他のすべてのブランチで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_に加えてRで噛み付いている州_Removedは弛みます。 すべての場合では、受信されたPathErrメッセージは最初に標準の処理規則単位で処理されます、そして、失敗か受信されたPathErrメッセージSHOULDが保護されるLSPのために上流へPathErrメッセージの世代の引き金となります。 送信するPathErrメッセージSHOULDは「ルート設定問題/LSPセグメント保護は失敗した」誤りを示します。 送信するPathErrメッセージは受信されたPathErrメッセージで運ばれたどんなSEROsも含まなければなりません。 どんなSEROも受信されたPathErrメッセージに存在していないか、または失敗が地方であるなら、errored 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_州_Removed旗があるPathErrメッセージがクリアされたとき、(0)は受け取られています、送信する(上流の)PathErrメッセージSHOULD。_Pathと共に送って、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).
回復へのPathErrメッセージであるときに、Path_州_Removed旗のセット(1)があるLSPが受け取られている、処理ノードは保護されるLSPのR-ビット(以下で定義されるように)を調べなければなりません。 R-ビットは回復LSPの開始の引き金となったPROTECTION物で運ばれます。 R-ビットがいつかが(0)、送信する(上流の)PathErrメッセージSHOULDを設定しません。_Pathと共に送って、Removedが旗を揚げさせる州_が(0)をクリアしたということになってください。 R-ビットがセット(1)であるときに、Path_州_Removed旗のセット(1)で送信する(上流の)PathErrメッセージを送らなければなりません。
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_州_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.
支店ノードは回復LSPsと保護されるLSPsの両方へのResvメッセージを処理するでしょう。 保護されたLSPのためにResvメッセージを受け取った後にだけResvメッセージはブランチノードの伝播された上流です。 回復LSPsに関するResvメッセージは通常上流のResvメッセージ(保護されるLSPのための)の伝達の引き金とならないでしょう。 これへの例外は、いつ、RROs/SRROsが集められてあるADMIN_STATUS物の処理の間、あるかを含んでいます。 関連する処理の詳しい情報に関して以下を見てください。
Berger, et al. Standards Track [Page 11] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[11ページ]。
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の上のPathの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物における変化を処理します。 大部分が最近設定させる_STATUSがRビットを反対させる上流のADMINを受けたとき、ブランチノードは、対応する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メッセージを受け取る各ノードは、標準の処理([RFC3209]と[RFC2205]を見る)単位でPathTearメッセージを処理して、また、あらゆる回復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
どんなLSPならも、回復LSPに沿ったどんなノードも回復LSPの解任を開始するかもしれません。 これをするために、分解を起こすノードは適切なError CodeがあるPathErrメッセージを送ります、そして、Path_州_Removed旗はLSPイングレスに向かって(0)をクリアしました。 説明された上、イングレスが誤りを伝播する回復LSPとして
Berger, et al. Standards Track [Page 12] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[12ページ]。
the LSP ingress, which can then signal the removal of the recovery 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.
また、分解を起こすノードに、非優雅な方法でRecovery LSPを取り外すのも可能です。 この場合、創始者は「確認」指示と共にPathTearメッセージ川下とPathErrメッセージを送ります、そして、(エラーコードと値はゼロにセットしました)Path_州_Removed旗はLSPイングレスノードに向かって(1)を設定しました。 いくつかの場合保護されるLSPの解任をもたらすことができるので、非イングレスノード分解のこの方法はNOT RECOMMENDEDです。
4.3.1. Modified NOTIFY_REQUEST Object Processing
4.3.1. 変更されて、_要求物の処理に通知してください。
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.
平行なセットの規則は、ブランチかマージノードが保護されるのと回復LSPsに関するPathとResvメッセージにNOTIFY_REQUEST物を追加するのを可能にするために支店で当てはまられていて、ノードを合併します。 支店ノードはNOTIFY_REQUEST物をPathメッセージに追加します、そして、マージノードはNOTIFY_REQUEST物をResvメッセージに追加します。
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であるときに、ノードSHOULDは回復LSPに関するPathメッセージに単一のNOTIFY_REQUEST物を含んでいます、ブランチノードに関するケース、または回復LSPに関するResvメッセージで、マージノードの場合で。 ルータへのセットが処理ノードのアドレスであったに違いないならノードアドレスに通知してください。
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.
分岐してください。そうすれば、また、マージノードSHOULDはNOTIFY_REQUEST物を保護されるLSPに加えます。 ノードアドレスに通知してください。ブランチノードのために設定する、関連回復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メッセージを発行しなければならない、最初の記載されたNOTIFY_REQUEST物のアドレスに通知してください。 また、地方の方針コントロールの下では、Notifyメッセージを発行するノードは最終で示されたNotify Node Address、またはいかなる他の(PathかResvメッセージで運ばれたNOTIFY_REQUEST物)もNotifyメッセージを送るかもしれません。
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
回復LSPは合併します、そして、ブランチノードは回復ブランチかマージノードによって保護されるLSPへの出発しているPathとResvメッセージから加えられた物を取り除きます。 マージノードの場合で合っているNOTIFY_REQUEST物を取り除くことによって、これをします。
Berger, et al. Standards Track [Page 13] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[13ページ]。
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のマッチ。 通常、合っているNOTIFY_REQUEST物は記載されたNOTIFY_REQUEST物の1番目でしょう。 互換性シナリオ、NOTIFY_REQUEST物のSHOULD NOTがそれが唯一の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物を含んでいるなら、最初の物だけが重要です。 _REQUESTが無視されるかもしれないのを反対させるその後のNOTIFYとSHOULD NOT、伝播されてください。
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.
支店とマージノードはNotifyメッセージ処理への以下の変更を支えなければなりません。 ブランチかマージノードがLSPの故障の通知を受け取って、その失敗から回復できないとき、それはLSPに関連しているPathメッセージ(ブランチノードのための)かResvメッセージ(マージノードのための)に受け取られた最初のNOTIFY_REQUEST物で示されたノードに通知しなければなりません。
5. Secondary Record Route Objects
5. 二次記録的なルート物
Secondary Record Route objects, or SRROs, are used to record the path used by recovery LSPs.
二次Record Route物、またはSRROsが、回復LSPsによって使用された経路を記録するのに使用されます。
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物の形式はRECORD_ROUTE物、Class No.21と同じです。 これはRECORD_ROUTE物のために定義された「副-物」の定義を含んでいます。 SECONDARY_RECORD_ROUTE物のクラスは201(フォーム11bbbbbbの)です。
The protection subobject defined above can also be used in SECONDARY_RECORD_ROUTE objects.
また、SECONDARY_RECORD_ROUTE物で上で定義された保護「副-物」は使用できます。
Berger, et al. Standards Track [Page 14] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[14ページ]。
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メッセージで運ばれて、上流の回復LSPsの存在を示すかもしれません。 1SRRO MAYが加えられて、Pathにメッセージを提示します。
Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Path message.
どんな容認されたSRRO MUSTもトランジットノードによって変更なしで伝えられて、対応する出発しているPathでは、通信してください。
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は、回復LSPによって新しいSRRO物に受け取られた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メッセージで運ばれて、川下の回復LSPsの存在を示すかもしれません。 1SRRO MAYが加えられて、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.
どんな容認されたSRRO MUSTもトランジットノードによって変更なしで伝えられて、対応する出発しているResvでは、通信してください。 Resvメッセージが合併されているとき、結果として起こる合併しているResv SHOULDは川下の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は回復LSPsのブランチノードによってResvメッセージに挿入されます。 SRRO SHOULDがローカルのノードアドレスである最初の2個の物で作成されて、回復のコンテンツで保護「副-物」によって続かれて、LSPのPROTECTIONは反対します。 残り、SRRO SHOULDでは、回復LSPによって受け取られたRROのコンテンツをコピーすることによって、作成されてください。 このSRRO SHOULD、回復している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 subobjects SHOULDをうまくはめ込むには、あらゆる現在のSRROsから、取り除いてください。 SRRO MUST NOTで「副-物」、最初の2個の「副-物」、および最後の「副-物」を取り外すときには、取り除いてください。 L-ビットセット(1)で取り外された「副-物」に続いた「副-物」をアップデートしなければならないことに注意してください。 それでも、すべてのSRROsで1番目と最後の「副-物」以外のすべてを取り除いた後に結果として起こるメッセージが合うことができないくらい大きくて、当時の全体のSRROs SHOULDであるなら、メッセージが合うまで、取り除いてください。
Berger, et al. Standards Track [Page 15] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[15ページ]。
6. Dynamic Control of LSP Segment Recovery
6. LSPセグメント回復の動的制御
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.
ブランチとマージノードのダイナミックな識別はPROTECTION物で運ばれたLSP Segment Recovery Flagsを通して支持されます。 LSP Segment Recovery Flagsは[RFC4872]で定義されたPROTECTION物で定義されたReserved分野の1つの中で運ばれます。 LSP Segment Recovery Flagsは、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 Segment Recovery Flagsは[RFC4872]で定義された同じC-タイプのPROTECTION物で運ばれます。 旗の形式は以下の通りです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(37)| C-タイプ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|P|N|O| 予約されます。| LSP旗| 予約されます。| リンク旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|R| 予約されます。| Seg.Flags| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Segment Recovery Flagで示された必要なセグメント回復タイプが関連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 Segment回復が可能であるところでダイナミックに起こされることを望んでいるかを示すのに使用されます。 この分野で使用される値はLSP Flagsのために定義された値と同じです。 [RFC4872]を見てください。
Berger, et al. Standards Track [Page 16] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[16ページ]。
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 Segment Recovery FlagsはLSPセグメント回復が合図されるLSPのために望まれているのを示すように用意ができています。 望まれていた回復のタイプは旗で示されます。 地域にかかわる事柄とこのドキュメントの範囲の外にLSP Segment Recovery Flagsを設定するという決定があります。 (0)がない値は、セグメント回復ブランチノードをどんなダイナミックな識別も関連LSPに必要でないことを意味します。 In-場所ビットが設定されるとき、それは、必要なタイプの回復がその特定の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のための適切なマージノードを特定できるなら、非ゼロLSP Segment Recovery Flags価値でPROTECTION物を含むPathメッセージを受け取るトランジットノードとIn場所ビットはSHOULDが考える(0)をクリアします。 SEROのブランチノードとして処理ノードを特定するとき、ダイナミックな識別をしてはいけません。 ノードが示された回復タイプを提供するか、またはマージノードを特定できないなら、通常、Pathメッセージを処理しなければなりません、そして、LSP Segment Recovery Flagsは変更されてはいけません。
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 Segment Recovery Flagsで示された回復のタイプのためにマージノードを特定するとき、それは、回復LSPをセットアップするのを試みます。 ダイナミックに特定された情報は、回復LSPを作成するのに回収されるLSPに関するPathメッセージと共に使用されます。
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メッセージで、ある物を取り替えるか、または変更します。 ローカルのノード、およびLSP ID MUSTでアドレスを使用する(Tunnel Sender Address分野で)ためにSender_テンプレート物をアップデートしなければなりません。ユニークさを確実にするのをアップデートします。 トンネル終点アドレスとしてダイナミックに特定されたマージノードのアドレスを使用するためにSession物をアップデートしなければなりません、そして、トンネルIDをアップデートするかもしれません、そして、ローカルのノードアドレスに拡張トンネルIDを設定しなければなりません。 In-場所の噛み付いているセット(1)でPROTECTION物をアップデートします。 回復LSPに入って来るPathメッセージの現在の少しのRROsとEROsも含んではいけません。 新しいERO MAY、ローカルのノードによってダイナミックに計算されたどんな経路情報に基づいて、作成されてください。
Berger, et al. Standards Track [Page 17] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[17ページ]。
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が存在している間、In-場所の噛み付いているセット(1)でオリジナルのPathメッセージ(ローカルの方針でくつがえされない場合)のPROTECTION物をアップデートしなければなりません。 この地点から先は、Standard Pathメッセージ処理は結果になっていてオリジナルの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.
送信するPathメッセージのPROTECTION物のIn-場所ビットが終えられた回復LSPに関連づけたダイナミックに制御された回復LSP SHOULDリセット(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を取り外します、そして、上流へどんなエラーメッセージも指示も送りません。 これは例外として、明らかに制御された回復LSPsのための他のすべての手順がダイナミックに制御された回復LSPsに適用されます。 これらの他の手順は上でセクション4.2で.1〜4.2に.4に定義されます。
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メッセージに提示します。 彼らが異なるところでは、単方向LSPsの間の形式は別々に双方向のLSPsから提示されます。
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>
<経路メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<の明白な_ルート>]<ラベル_要求>[<保護>]を評価します[<ラベル_は>を…設定しました]。 [<セッション_属性>] [<は_要求>に通知します…] [<アドミン_状態>] [<協会>] [<の二次_明白な_ルート>] [<方針_データ>] <送付者記述子>。
Berger, et al. Standards Track [Page 18] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[18ページ]。
The format of the sender description for unidirectional LSPs is:
単方向LSPsの間の送付者記述の形式は以下の通りです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>[<ADSPEC>][<記録_ルート>][<は_ラベル>を示しました][<回復_ラベル>][<の二次_記録_は>を発送します…]
The format of the sender description for bidirectional LSPs is:
双方向のLSPsのための送付者記述の形式は以下の通りです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
[ <SECONDARY_RECORD_ROUTE> ... ]
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>[<ADSPEC>][<記録_ルート>][<は_ラベル>を示しました][<回復_ラベル>]<上流_ラベル>。[<の二次_記録_は>を発送します…]
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>
<PathErrメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション><誤り_仕様>[<の許容できる_ラベル_は>を…設定します] [<の二次_明白な_ルート>] [<方針_データ>] <送付者記述子>。
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>
<Resvメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>を評価します[<RESV_は>を確認します][<範囲>][<は_要求>に…通知します]。 [<アドミン_状態>] [<方針_データ>] <様式><流れ記述子リスト>。
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<流れ記述子リスト>:、:= <FF流れ記述子リスト>。| <SE流れ記述子>。
Berger, et al. Standards Track [Page 19] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[19ページ]。
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF流れ記述子リスト>:、:= <FLOWSPEC><フィルタ_仕様><ラベル>[<記録_ルート>][<の二次_記録_ルート>…] | <FF流れ記述子リスト><FF流れ記述子>。
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<FF流れ記述子>:、:= [<FLOWSPEC>]<フィルタ_仕様><ラベル>[<記録_ルート>][<の二次_記録_は>を発送します…]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE流れ記述子>:、:= <FLOWSPEC><SEフィルタ仕様リスト>。
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SEは仕様リスト>をフィルターにかけます:、:= <SEフィルタ仕様>。| <SEフィルタ仕様リスト><SEフィルタ仕様>。
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<SEは仕様>をフィルターにかけます:、:= <フィルタ_仕様><ラベル>[<記録_ルート>][<の二次_記録_は>を発送します…]
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.
このドキュメントはGMPLSシグナリング[RFC3473]における使用のために新しいメッセージ物を紹介します。 それは、制御飛行機で隣接しているLSRsの間でどんな新しいシグナリングメッセージも紹介して、関係を変えません。
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の存在が、必ず経路が運んだLSPの簡単なEROsとRROsより多くの情報があることを意味するのでメッセージに合図しながら、運び込みました。 したがって、シグナリングメッセージの妨害の場合、わずかに以上は、この情報がルーティングで既に利用可能であるので非常に小さい方の危険人物になるように以前にしかし、ケース、これが判断されるということであったよりネットワークの事情に関して推論されるかもしれません。
Otherwise, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations.
さもなければ、このドキュメントは追加担保問題を全く紹介しません。 関連セキュリティ問題に関して[RFC3473]を見てください。
Berger, et al. Standards Track [Page 20] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[20ページ]。
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は「GMPLSシグナリングパラメタ」への以下の課題を http://www.iana.org/assignments/gmpls-sig-parameters に位置するRegistry([RFC4872]を見る)にしました。
Value Type
----- ----
2 Resource Sharing (R) [RFC4873]
値のタイプ----- ---- 2 リソース・シェアリング(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]で定義されたPROTECTION物の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は「RSVPパラメタ」登録のセクションが http://www.iana.org/assignments/rsvp-parameters で場所を見つけた「クラス名、クラス番号、およびクラスタイプ」で以下の課題をしました。
A new class named SECONDARY_EXPLICIT_ROUTE has been created in the
11bbbbbb range (200) with the following definition:
Class Types or C-types:
SECONDARY_EXPLICIT_ROUTEという新しいクラスは11bbbbbb範囲(200)に以下の定義で創設されました: クラスタイプかC-タイプ:
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:
Class1、C-タイプ1において、以下の追加Subobjectタイプは定義されます:
37 PROTECTION [RFC4873]
37 保護[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は「RSVPパラメタ」登録のセクションが http://www.iana.org/assignments/rsvp-parameters で場所を見つけた「クラス名、クラス番号、およびクラスタイプ」で以下の課題をしました。
Berger, et al. Standards Track [Page 21] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[21ページ]。
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:
Class1、C-タイプ1において、以下の追加Subobjectタイプは定義されます:
37 PROTECTION [RFC4873]
37 保護[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は「RSVPパラメタ」登録のセクションが http://www.iana.org/assignments/rsvp-parameters で場所を見つけた「エラーコードと値」の「ルート設定問題」小区分における以下の課題をしました。
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]).
このドキュメントはPROTECTION物、クラス番号37、C-タイプ2([RFC4872]のセクション14.1では、定義される)を変更します。
Berger, et al. Standards Track [Page 22] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[22ページ]。
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月。
[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の機能的な仕様」、RFC2205、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
[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)拡大」、RFC3473、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]ラング、J.P.(エド)、Rekhter、Y.(エド)、およびD.Papadimitriou(エド)、「終わるEndを支持したRSVP-TE ExtensionsはLabel Switching(GMPLS)回復についてGeneralized Multi議定書の中で述べます」、RFC4872、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.Atlas(「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください」、RFC4090)は2005がそうするかもしれません。
[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(エド))は「マルチプロトコルラベルスイッチング(GMPLS)の回復の機能的な仕様を広めました」、RFC4426、2006年3月。
[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)を切り換えること」でのRFC4427(2006年3月)。
Berger, et al. Standards Track [Page 23] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[23ページ]。
Authors' Addresses
作者のアドレス
Lou Berger LabN Consulting, L.L.C.
ルウバーガーLabN Consulting、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
光学イーゴリの7926ジョーンズ支店ドライブBryskin ADVAスイート615マクリーン・ヴァージニア、22102
EMail: IBryskin@advaoptical.com
メール: IBryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellesplein1B-2018アントウェルペン(ベルギー)
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
以下に電話をしてください。 +44 (0) 1978 860944はメールされます: adrian@olddog.co.uk
Berger, et al. Standards Track [Page 24] RFC 4873 GMPLS Segment Recovery May 2007
バーガー、他 規格はGMPLSセグメント回復2007年5月にRFC4873を追跡します[24ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Berger, et al. Standards Track [Page 25]
バーガー、他 標準化過程[25ページ]
一覧
スポンサーリンク
