RFC4872 日本語訳
4872 RSVP-TE Extensions in Support of End-to-End GeneralizedMulti-Protocol Label Switching (GMPLS) Recovery. J.P. Lang, Ed., Y.Rekhter, Ed., D. Papadimitriou, Ed.. May 2007. (Format: TXT=111882 bytes) (Updates RFC3471) (Updated by RFC4873) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J.P. Lang, Ed.
Request for Comments: 4872 Sonos
Updates: 3471 Y. Rekhter, Ed.
Category: Standards Track Juniper
D. Papadimitriou, Ed.
Alcatel
May 2007
ワーキンググループのJ.P.ラング、エドをネットワークでつないでください。コメントのために以下を要求してください。 4872のSonosアップデート: エド3471Y.Rekhter、カテゴリ: エド標準化過程杜松D.Papadimitriou、アルカテル2007年5月
RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Recovery
終わらせる終わりを支持したRSVP-Te拡大はマルチプロトコルラベルスイッチング(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 and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426.
このドキュメントはGeneralized Multi-プロトコルLabel Switching(GMPLS)リソースReSerVationプロトコルのためのプロトコル特有の手順と拡大について説明します--保護と回復を指示する終わりから終わりへのLabel Switched Path(LSP)回復を支持すると合図する交通Engineering(RSVP-TE)。 仲間ドキュメント、RFC4426でGMPLS回復の一般的な機能的な記述を見つけることができます。
Table of Contents
目次
1. Introduction .....................................................3
2. Conventions Used in This Document ...............................5
3. Relationship to Fast Reroute (FRR) ..............................5
4. Definitions .....................................................6
4.1. LSP Identification .........................................6
4.2. Recovery Attributes ........................................7
4.2.1. LSP Status ..........................................7
4.2.2. LSP Recovery ........................................8
4.3. LSP Association ............................................9
5. 1+1 Unidirectional Protection ...................................9
5.1. Identifiers ...............................................10
1. 序論…3 2. このドキュメントで中古のコンベンション…5 3. 速く別ルートで送る関係(FRR)…5 4. 定義…6 4.1. LSP識別…6 4.2. 回復属性…7 4.2.1. LSP状態…7 4.2.2. LSP回復…8 4.3. LSP協会…9 5. 1+1単方向の保護…9 5.1. 識別子…10
Lang, et al. Standards Track [Page 1] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[1ページ]RFC RSVP-Te拡張子
6. 1+1 Bidirectional Protection ...................................10
6.1. Identifiers ...............................................11
6.2. End-to-End Switchover Request/Response ....................11
7. 1:1 Protection with Extra-Traffic ..............................13
7.1. Identifiers ...............................................14
7.2. End-to-End Switchover Request/Response ....................15
7.3. 1:N (N > 1) Protection with Extra-Traffic .................16
8. Rerouting without Extra-Traffic ................................17
8.1. Identifiers ...............................................19
8.2. Signaling Primary LSPs ....................................19
8.3. Signaling Secondary LSPs ..................................19
9. Shared-Mesh Restoration ........................................20
9.1. Identifiers ...............................................22
9.2. Signaling Primary LSPs ....................................22
9.3. Signaling Secondary LSPs ..................................23
10. LSP Preemption ................................................23
11. (Full) LSP Rerouting ..........................................25
11.1. Identifiers ..............................................25
11.2. Signaling Reroutable LSPs ................................26
12. Reversion .....................................................26
13. Recovery Commands .............................................29
14. PROTECTION Object .............................................31
14.1. Format ...................................................31
14.2. Processing ...............................................33
15. PRIMARY_PATH_ROUTE Object .....................................33
15.1. Format ...................................................34
15.2. Subobjects ...............................................34
15.3. Applicability ............................................35
15.4. Processing ...............................................36
16. ASSOCIATION Object ............................................37
16.1. Format ...................................................37
16.2. Processing ...............................................38
17. Updated RSVP Message Formats ..................................39
18. Security Considerations .......................................40
19. IANA Considerations ...........................................41
20. Acknowledgments ...............................................43
21. References ....................................................43
21.1. Normative References .....................................43
21.2. Informative References ...................................44
22. Contributors ..................................................45
6. 1 +1 双方向の保護…10 6.1. 識別子…11 6.2. 終わりから終わりへの転換要求/応答…11 7. 余分な交通との1:1保護…13 7.1. 識別子…14 7.2. 終わりから終わりへの転換要求/応答…15 7.3. 余分な交通との1:N(N>1)保護…16 8. 余分な交通なしでコースを変更します…17 8.1. 識別子…19 8.2. 第一のLSPsに合図します…19 8.3. 二次LSPsに合図します…19 9. 共有されたメッシュ王政復古…20 9.1. 識別子…22 9.2. 第一のLSPsに合図します…22 9.3. 二次LSPsに合図します…23 10. LSP先取り…23 11. (いっぱいに) LSPのコースを変更すること…25 11.1. 識別子…25 11.2. シグナリングReroutable LSPs…26 12. 逆戻り…26 13. 回復は命令します…29 14. 保護物…31 14.1. 形式…31 14.2. 処理…33 15. 第一の_経路_は物を発送します…33 15.1. 形式…34 15.2. Subobjects…34 15.3. 適用性…35 15.4. 処理…36 16. 協会物…37 16.1. 形式…37 16.2. 処理…38 17. RSVPメッセージ・フォーマットをアップデートします…39 18. セキュリティ問題…40 19. IANA問題…41 20. 承認…43 21. 参照…43 21.1. 標準の参照…43 21.2. 有益な参照…44 22. 貢献者…45
Lang, et al. Standards Track [Page 2] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[2ページ]RFC RSVP-Te拡張子
1. Introduction
1. 序論
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to include support for Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) interfaces. GMPLS recovery uses control plane mechanisms (i.e., signaling, routing, and link management mechanisms) to support data plane fault recovery. Note that the analogous (data plane) fault detection mechanisms are required to be present in support of the control plane mechanisms. In this document, the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are only used when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery phase (see [RFC4427]).
一般化されたMulti-プロトコルLabel Switching(GMPLS)は、Layer-2 Switch Capable(L2SC)(Time-事業部Multiplex(TDM)、Lambda Switch Capable(LSC)、およびFiber Switch Capable(FSC)インタフェース)のサポートを含むようにMPLSを広げています。 GMPLS回復は、データ飛行機欠点回復を支持するのに、制御飛行機メカニズム(すなわち、シグナリング、ルーティング、およびリンク管理メカニズム)を使用します。 類似(データ飛行機)の欠点検出メカニズムを制御飛行機メカニズムを支持して存在させているのが必要であることに注意してください。本書では、「回復」という用語は保護と回復の両方を指示するのに一般的に使用されます。 分化が必要であるときにだけ、種の用語「保護」と「回復」は使用されます。 回収段階の間に行われた資源配分に基づいて保護と回復の微細な区別をします([RFC4427]を見てください)。
A functional description of GMPLS recovery is provided in [RFC4426] and should be considered as a companion document. The present document describes the protocol-specific procedures for GMPLS RSVP- TE (Resource ReSerVation Protocol - Traffic Engineering) signaling (see [RFC3473]) to support end-to-end recovery. End-to-end recovery refers to the recovery of an entire LSP from its head-end (ingress node endpoint) to its tail-end (egress node endpoint). With end-to- end recovery, working LSPs are assumed to be resource-disjoint (where a resource is a link, node, or Shared Risk Link Group (SRLG)) in the network so that they do not share any failure probability, but this is not mandatory. With respect to a given set of network resources, a pair of working/protecting LSPs SHOULD be resource disjoint in case of dedicated recovery type (see below). On the other hand, in case of shared recovery (see below), a group of working LSPs SHOULD be mutually resource-disjoint in order to allow for a (single and commonly) shared protecting LSP, itself resource-disjoint from each of the working LSPs. Note that resource disjointness is a necessary (but not sufficient) condition to ensure LSP recoverability.
GMPLS回復の機能的な記述は、[RFC4426]に提供されて、仲間ドキュメントであるとみなされるべきです。 終わりから終わりへの回復を支持すると合図しながら([RFC3473]を見ます)、現在のドキュメントはGMPLS RSVP- TE(リソースReSerVationプロトコル--交通Engineering)のためにプロトコル特有の手順について説明します。 終わりから終わりへの回復はギヤエンド(イングレスノード終点)からの末端(出口ノード終点)への全体のLSPの回復について言及します。 終わりから終わりへの回復で、働くLSPsがネットワークでリソースでばらばらになると(リソースがリンク、ノード、またはShared Risk Link Group(SRLG)であるところ)思われて、彼らは少しの故障確率も共有しませんが、これは義務的ではありません。 リソースがひたむきな回復タイプの場合にばらばらになるという(以下を見てください)aに関する、ことになってくださいネットワーク資源のセット、1組の働き/保護LSPs SHOULDを考えて。 そして、他方では、共有された回復(以下を見る)の場合に働くLSPs SHOULDのグループがaを考慮するために互いにリソースでばらばらになる、(単一である、一般的に)、LSP、それぞれの働きからリソースでそれ自体でばらばらになっているLSPsを保護しながら、共有されます。 リソースばらばらになるのがLSP修復性を確実にするためには必要で(十分でない)の状態であることに注意してください。
The present document addresses four types of end-to-end LSP recovery: 1) 1+1 (unidirectional/bidirectional) protection, 2) 1:N (N >= 1) LSP protection with extra-traffic, 3) pre-planned LSP rerouting without extra-traffic (including shared mesh), and 4) full LSP rerouting.
現在のドキュメントは終わりから終わりへの4つのタイプのLSP回復を記述します: 1) 1 +1 (単方向/双方向)の保護、2) 1:N(N>=1) 余分な交通、余分な交通(共有されたメッシュを含んでいる)なしでコースを変更する3の)あらかじめ計画されたLSP、および4があるLSP保護) 完全なLSPのコースを変更すること。
1) The simplest notion of end-to-end LSP protection is 1+1
unidirectional protection. Using this type of protection, a
protecting LSP is signaled over a dedicated resource-disjoint
alternate path to protect an associated working LSP. Normal
traffic is simultaneously sent on both LSPs and a selector is used
at the egress node to receive traffic from one of the LSPs. If a
failure occurs along one of the LSPs, the egress node selects the
1) 終わりから終わりへのLSP保護の最も簡単な概念は1+1単方向の保護です。 このタイプの保護を使用して、ひたむきなリソースでばらばらになっている代替パスの上で保護LSPが関連働くLSPを保護するように合図されます。 同時に通常の交通を両方のLSPsに送ります、そして、LSPsの1つからの交通を受けるのに出口ノードでセレクタを使用します。 a失敗はLSPsの1つ、ノードが選択する出口に沿って起こります。
Lang, et al. Standards Track [Page 3] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[3ページ]RFC RSVP-Te拡張子
traffic from the valid LSP. No coordination is required between
the end nodes when a failure/switchover occurs.
有効なLSPからの交通。 失敗/転換が起こるとき、コーディネートは全くエンドノードの間で必要ではありません。
In 1+1 bidirectional protection, a protecting LSP is signaled over
a dedicated resource-disjoint alternate path to protect the
working LSP. Normal traffic is simultaneously sent on both LSPs
(in both directions), and a selector is used at both
ingress/egress nodes to receive traffic from the same LSP. This
requires coordination between the end-nodes when switching to the
protecting LSP.
1つの+1双方向の保護では、ひたむきなリソースでばらばらになっている代替パスの上に保護LSPが働くLSPを保護するように示唆されます。 同時に両方のLSPs(両方の方向への)に通常の交通を送ります、そして、同じLSPからの交通を受けるのに両方のイングレス/出口ノードでセレクタを使用します。 保護しているLSPに切り替わるとき、これはエンドノードの間のコーディネートを必要とします。
2) In 1:N (N >= 1) protection with extra-traffic, the protecting LSP
is a fully provisioned and resource-disjoint LSP from the N
working LSPs, that allows for carrying extra-traffic. The N
working LSPs MAY be mutually resource-disjoint. Coordination
between end-nodes is required when switching from one of the
working LSPs to the protecting LSP. As the protecting LSP is
fully provisioned, default operations during protection switching
are specified for a protecting LSP carrying extra-traffic, but
this is not mandatory. Note that M:N protection is out of scope
of this document (though mechanisms it defines may be extended to
cover it).
2) 余分な交通に伴う1:N(N>=1)保護では、保護しているLSPはN働くLSPsからの完全に食糧を供給されて、リソースでばらばらになっているLSPです、とそれは余分な交通を運ぶために許容します。 N働くLSPsが互いにリソースでばらばらになっているかもしれません。 働くLSPsの1つ〜保護しているLSPに切り替わるとき、エンドノードの間のコーディネートが必要です。 保護しているLSPが完全に食糧を供給されるとき、保護の切り換えの間のデフォルト操作は余分な交通を運ぶ保護LSPに指定されますが、これは義務的ではありません。 そのMに注意してください: このドキュメントの範囲の外にN保護があります(それが定義するメカニズムはそれを覆うために広げられるかもしれませんが)。
3) Pre-planned LSP rerouting (or restoration) relies on the
establishment between the same pair of end-nodes of a working LSP
and a protecting LSP that is link/node/SRLG disjoint from the
working one. Here, the recovery resources for the protecting LSP
are pre-reserved but explicit action is required to activate
(i.e., commit resource allocation at the data plane) a specific
protecting LSP instantiated during the (pre-)provisioning phase.
Since the protecting LSP is not "active" (i.e., fully
instantiated), it cannot carry any extra-traffic. This does not
mean that the corresponding resources cannot be used by other
LSPs. Therefore, this mechanism protects against working LSP(s)
failure(s) but requires activation of the protecting LSP after
working LSP failure occurrence. This requires restoration
signaling along the protecting path. "Shared-mesh" restoration
can be seen as a particular case of pre-planned LSP rerouting that
reduces the recovery resource requirements by allowing multiple
protecting LSPs to share common link and node resources. The
recovery resources are pre-reserved but explicit action is
required to activate (i.e., commit resource allocation at the data
plane) a specific protecting LSP instantiated during the (pre-)
provisioning phase. This procedure requires restoration signaling
along the protecting path.
3) あらかじめ計画されたLSPのコースを変更すること(または、回復)は同じ組の働くLSPと保護しているLSPのエンドノードの間の設立に依存します、すなわち、リンク/ノード/SRLGは働くものからばらばらになります。 ここで、あらかじめ予約された保護しているLSPにもかかわらず、明白な動作のための回復リソースがLSPが例示したa特定の保護を動かすこと(すなわち、データ飛行機で資源配分を遂行する)に必要である、(プレ、)、フェーズに食糧を供給します。 保護しているLSPが「アクティブでない」ので(すなわち、完全に例示された)、それは少しの余分な交通も運ぶことができません。 これは、他のLSPsが対応するリソースを使用できないことを意味しません。 したがって、このメカニズムは、働くLSP(s)の故障から守りますが、LSP失敗発生を扱った後に、保護しているLSPの起動を必要とします。 これは保護経路に沿って回復シグナリングを必要とします。 複数の保護LSPsが普通リンクとノードリソースを共有するのを許容することによってそれを別ルートで送るあらかじめ計画されたLSPの特定のケースが回復リソース要件を減らすのに従って、「共有されたメッシュ」回復を見ることができます。 あらかじめ予約された回復リソースにもかかわらず、明白な動作がLSPが例示したa特定の保護を動かすこと(すなわち、データ飛行機で資源配分を遂行する)に必要である、(プレ、)、フェーズに食糧を供給します。 この手順は保護経路に沿って回復シグナリングを必要とします。
Lang, et al. Standards Track [Page 4] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[4ページ]RFC RSVP-Te拡張子
Note that in both cases, bandwidth pre-reserved for a protecting
(but not activated) LSP can be made available for carrying extra
traffic. LSPs for extra-traffic (with lower holding priority than
the protecting LSP) can then be established using the bandwidth
pre-reserved for the protecting LSP. Also, any lower priority LSP
that use the pre-reserved resources for the protecting LSP(s) must
be preempted during the activation of the protecting LSP.
どちらの場合も、保護(しかし、動かされない)LSPのためにあらかじめ控えられた帯域幅は余分な交通を運ぶのに利用可能にすることができることに注意してください。 そして、保護しているLSPのためにあらかじめ控えられた帯域幅を使用することで余分な交通(保護しているLSPより低い把持優先度がある)へのLSPsを設立できます。 また、保護しているLSPの起動の間、保護しているLSP(s)にプレ予約されたリソースを使用するどんな低優先度LSPも先取りしなければなりません。
4) Full LSP rerouting (or restoration) switches normal traffic to an
alternate LSP that is not even partially established until after
the working LSP failure occurs. The new alternate route is
selected at the LSP head-end node, it may reuse resources of the
failed LSP at intermediate nodes and may include additional
intermediate nodes and/or links.
4) 完全なLSPのコースを変更すること(または、回復)は働くLSPの故障が起こった後まで部分的にさえ設立されない交互のLSPに通常の交通を切り換えます。 新しい代替経路がLSPギヤエンドのノードで選択されて、それは、中間的ノードで失敗したLSPに関するリソースを再利用して、追加中間的ノード、そして/または、リンクを含むかもしれません。
Crankback signaling (see [CRANK]) and LSP segment recovery (see [RFC4873]) are further detailed in dedicated companion documents.
Crankbackシグナリング([CRANK]を見る)とLSPセグメント回復([RFC4873]を見る)は専用仲間ドキュメントでさらに詳細です。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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 [RFC3945], [RFC3471], [RFC3473] and referenced as well as in [RFC4427] and [RFC4426].
さらに、読者が[RFC3945]、[RFC3471][RFC3473]で使用されて、参照をつけられる用語と[RFC4427]と[RFC4426]でよく知られさせると思われます。
3. Relationship to Fast Reroute (FRR)
3. 速く別ルートで送る関係(FRR)
There is no impact to RSVP-TE Fast Reroute (FRR) [RFC4090] introduced by end-to-end GMPLS recovery i.e., it is possible to use either method defined in FRR with end-to-end GMPLS recovery.
終わりから終わりへのGMPLS回復によって導入されたRSVP-TE Fast Reroute(FRR)[RFC4090]への影響が全くありません、すなわち、終わりから終わりへのGMPLS回復でFRRで定義された方法を使用するのは可能です。
The objects used and/or newly introduced by end-to-end recovery will be ignored by [RFC4090] conformant implementations, and FRR can operate on a per LSP basis as defined in [RFC4090].
中古の、そして/または、終わりから終わりへの回復によって新たに導入された物は[RFC4090]conformant実現で無視されるでしょう、そして、FRRは[RFC4090]で定義されるようにLSP基礎あたりのaを作動させることができます。
Lang, et al. Standards Track [Page 5] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[5ページ]RFC RSVP-Te拡張子
4. Definitions
4. 定義
4.1. LSP Identification
4.1. LSP識別
This section reviews terms previously defined in [RFC2205], [RFC3209], and [RFC3473]. LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects (see also [RFC3209]). The relevant fields are as follows:
このセクションは以前に[RFC2205]、[RFC3209]、および[RFC3473]で定義された用語を再検討します。 LSPトンネルはSESSIONとSENDER_TEMPLATE物(また[RFC3209]、見る)の組み合わせで特定されます。 関連分野は以下の通りです:
IPv4 (or IPv6) tunnel endpoint address
IPv4(または、IPv6)トンネル終点アドレス
IPv4 (or IPv6) address of the egress node for the tunnel.
トンネルのための出口ノードのIPv4(または、IPv6)アドレス。
Tunnel ID
トンネルID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
16ビットの識別子はトンネルの人生の間、SESSIONでその残り定数を使用しました。
Extended Tunnel ID
拡張Tunnel ID
A 32-bit (or 16-byte) identifier used in the SESSION that
remains constant over the life of the tunnel. Normally set to
all zeros. Ingress nodes that wish to narrow the scope of a
SESSION to the ingress-egress pair MAY place their IPv4 (or
IPv6) address here as a globally unique identifier.
32ビット(または、16バイト)の識別子はトンネルの人生の間、SESSIONでその残り定数を使用しました。 通常、すべてのゼロにセットしてください。 イングレス出口組にSESSIONの範囲を狭くしたがっているイングレスノードはグローバルにユニークな識別子としてそれらのIPv4(または、IPv6)アドレスをここに置くかもしれません。
IPv4 (or IPv6) tunnel sender address
IPv4(または、IPv6)トンネル送付者アドレス
IPv4 (or IPv6) address for a sender node.
送付者ノードのためのIPv4(または、IPv6)アドレス。
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and FILTER_SPEC
that can be changed to allow a sender to share resources with
itself.
16ビットの識別子はSENDER_TEMPLATEとFILTERで_送付者がそれ自体とリソースを共有するのを許容するために変えることができるSPECを使用しました。
The first three fields are carried in the SESSION object (Path and Resv message) and constitute the basic identification of the LSP tunnel.
最初の3つの分野が、SESSION物(経路とResvメッセージ)で運ばれて、LSPトンネルの基本的な識別を構成します。
The last two fields are carried in the SENDER_TEMPLATE (Path message) and FILTER_SPEC objects (Resv message). The LSP ID is used to differentiate LSPs that belong to the same LSP Tunnel (as identified by its Tunnel ID).
最後の2つの野原がSENDER_TEMPLATE(経路メッセージ)とFILTER_SPEC物(Resvメッセージ)で運ばれます。 LSP IDは、同じLSP Tunnelに属すLSPsを微分するのに使用されます(Tunnel IDによって特定されるように)。
Lang, et al. Standards Track [Page 6] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[6ページ]RFC RSVP-Te拡張子
4.2. Recovery Attributes
4.2. 回復属性
The recovery attributes include all the parameters that determine the status of an LSP within the recovery scheme to which it is associated. These attributes are part of the PROTECTION object introduced in Section 14.
回復属性はそれが関連している回復計画の中でLSPの状態を決定するすべてのパラメタを含んでいます。 これらの属性はセクション14で紹介されたPROTECTION物の一部です。
4.2.1. LSP Status
4.2.1. LSP状態
The following bits are used in determining resource allocation and status of the LSP within the group of LSPs forming the protected entity:
以下のビットは保護された実体を形成するLSPsのグループの中でLSPの資源配分と状態を決定する際に使用されます:
- S (Secondary) bit: enables distinction between primary and
secondary LSPs. A primary LSP is a fully established LSP for which
the resource allocation has been committed at the data plane (i.e.,
full cross-connection has been performed). Both working and
protecting LSPs can be primary LSPs. A secondary LSP is an LSP
that has been provisioned in the control plane only, and for which
resource selection MAY have been done but for which the resource
allocation has not been committed at the data plane (for instance,
no cross-connection has been performed). Therefore, a secondary
LSP is not immediately available to carry any traffic (thus
requiring additional signaling to be available). A secondary LSP
can only be a protecting LSP. The (data plane) resources allocated
for a secondary LSP MAY be used by other LSPs until the primary LSP
fails over to the secondary LSP.
- S(二次)に噛み付きました: 第一の、そして、二次のLSPsの区別を可能にします。 第一のLSPは資源配分がデータ飛行機で遂行された完全に確立したLSP(すなわち、完全な交差接続は実行された)です。 ともに、LSPsを扱って、保護するのは、第一のLSPsであるかもしれません。 二次LSPは制御飛行機だけで食糧を供給されて、リソース選択をしたかもしれませんが、資源配分がデータ飛行機で遂行されていないLSP(例えば、交差接続は全く実行されていない)です。 したがって、二次LSPは、すぐに、どんな交通も運ぶために利用可能ではありません(その結果、追加シグナリングが利用可能であることが必要になります)。 二次LSPは保護LSPであるにすぎないかもしれません。 (データは平らにされます)リソースは2番目のためにLSP MAYを割り当てました。第一のLSPが二次のLSPに失敗するまで、他のLSPsによって使用されてください。
- P (Protecting) bit: enables distinction between working and
protecting LSPs. A working LSP must be a primary LSP whilst a
protecting LSP can be either a primary or a secondary LSP. When
protecting LSP(s) are associated with working LSP(s), one also
refers to the latter as protected LSPs.
- P(保護)に噛み付きました: LSPsを扱って、保護するところの区別を可能にします。 保護LSPは予備選挙か二次LSPのどちらかであるかもしれませんが、働くLSPは第一のLSPであるに違いありません。 保護するとき、LSP(s)が働くLSP(s)に関連している、また、人は保護されたLSPsと後者を呼びます。
Note: The combination "secondary working" is not valid (only protecting LSPs can be secondary LSPs). Working LSPs are always primary LSPs (i.e., fully established) whilst primary LSPs can be either working or protecting LSPs.
以下に注意してください。 「二次運用組み合わせ」は有効ではありません(LSPsを唯一の保護するのは、二次LSPsであるかもしれません)。 第一のLSPsがLSPsを扱うか、または保護できる間、働くLSPsはいつも第一のLSPs(すなわち、完全に設立される)です。
- O (Operational) bit: this bit is set when a protecting LSP is
carrying the normal traffic after protection switching (i.e.,
applies only in case of dedicated LSP protection or LSP protection
with extra-traffic; see Section 4.2.2).
- O(操作上の)に噛み付きました: 保護LSPが保護の切り換え(すなわち、単に余分な交通に伴うひたむきなLSP保護かLSP保護; セクション4.2.2を見ることの場合に、適用する)の後に通常の交通を運ぶとき、このビットは設定されます。
In this document, the PROTECTION object uses as a basis the PROTECTION object defined in [RFC3471] and [RFC3473] and defines additional fields within it. The fields defined in [RFC3471] and [RFC3473] are unchanged by this document.
本書では、PROTECTION物は、基礎として[RFC3471]と[RFC3473]で定義されたPROTECTION物を使用して、それの中で追加分野を定義します。 [RFC3471]と[RFC3473]で定義された分野はこのドキュメントで変わりがありません。
Lang, et al. Standards Track [Page 7] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[7ページ]RFC RSVP-Te拡張子
4.2.2. LSP Recovery
4.2.2. LSP回復
The following classification is used to distinguish the LSP Protection Type with which LSPs can be associated at end-nodes (a distinct value is associated with each Protection Type in the PROTECTION object; see Section 14):
以下の分類はエンドノードでLSPsを関連づけることができるLSP Protection Typeを区別するのに使用されます(異なった値はPROTECTION物の各Protection Typeに関連しています; セクション14を見てください):
- Full LSP Rerouting: set if a primary working LSP is dynamically
recoverable using (non pre-planned) head-end rerouting.
- 完全なLSPのコースを変更すること: 第一の働くLSPが(あらかじめ非計画される)のギヤエンドのコースを変更することを使用することでダイナミックに回復可能であるなら、セットしてください。
- Pre-planned LSP Rerouting without Extra-traffic: set if a
protecting LSP is a secondary LSP that allows sharing of the pre-
reserved recovery resources between one or more than one
<sender;receiver> pair. When the secondary LSPs resources are not
pre-reserved for a single <sender;receiver> pair, this type is
referred to as "shared mesh" recovery.
- 余分な交通なしでコースを変更するあらかじめ計画されたLSP: 保護LSPがプレ予約された回復リソースを共有させる二次LSPであるなら設定されて、1人の<送付者; 受信機>1つか以上が対にされます。 二次LSPsリソースが独身の<送付者のためにあらかじめ予約されないときの; 受信機>組、このタイプは「共有されたメッシュ」回復と呼ばれます。
- LSP Protection with Extra-traffic: set if a protecting LSP is a
dedicated primary LSP that allows for extra-traffic transport and
thus precludes any sharing of the recovery resources between more
than one <sender;receiver> pair. This type includes 1:N LSP
protection with extra-traffic.
- 余分な交通に伴うLSP保護: 保護LSPが余分な交通輸送を考慮して、その結果1人以上の<送付者の間の回復リソースのどんな共有も排除する専用第一のLSPであるなら、セットしてください; 受信機>組。 このタイプは1を入れます: 余分な交通に伴うN LSP保護。
- Dedicated LSP Protection: set if a protecting LSP does not allow
sharing of the recovery resources nor the transport of extra-
traffic (implying in the present context, duplication of the signal
over both working and protecting LSPs as in 1+1 dedicated
protection). Note also that this document makes a distinction
between 1+1 unidirectional and bidirectional dedicated LSP
protection.
- ひたむきなLSP保護: 保護LSPが回復リソースを共有させないなら、セットしてください。または、余分な交通(現在の文脈、1のようにともにLSPsを扱って、保護する上の信号の複製では、+1が保護を捧げたのを含意する)の輸送。 また、このドキュメントが1+1単方向、双方向のひたむきなLSP保護の間で区別をすることに注意してください。
For LSP protection, in particular, when the data plane provides automated protection-switching capability (see for instance ITU-T [G.841] Recommendation), a Notification (N) bit is defined in the PROTECTION object. It allows for distinction between protection switching signaling via the control plane or the data plane.
データ飛行機が自動化された保護スイッチング能力を提供するとき(例えばITU-T[G.841]推薦を見てください)、LSP保護において、特に、Notification(N)ビットはPROTECTION物で定義されます。 それは制御飛行機かデータ飛行機を通して保護切り換えシグナリングの区別を考慮します。
Note: this document assumes that Protection Type values have end-to- end significance and that the same value is sent over the protected and the protecting path. In this context, shared-mesh (for instance) appears from the end-nodes perspective as being simply an LSP rerouting without extra-traffic services. The net result of this is that a single bit (the S bit alone) does not allow determining whether resource allocation should be performed with respect to the status of the LSP within the protected entity. The introduction of the P bit solves this problem unambiguously. These bits MUST be processed on a hop-by-hop basis (independently of the LSP Protection Type context). This allows for an easier implementation of reversion
以下に注意してください。 このドキュメントは、Protection Type値には終わりから終わりへの意味があって、同じ値が保護と保護経路の上に送られると仮定します。 このような関係においては、(例えば)共有されたメッシュは単に余分な交通サービスなしでコースを変更するLSPであるとしてエンドノード見解から現れます。 この最終結果は1ビット(Sビットだけ)が、資源配分が保護された実体の中でLSPの状態に関して実行されるべきであるかどうか決定するのを許容しないということです。 Pビットの挿入は明白にこの問題を解決します。 ホップごとのベース(LSP Protection Type文脈の如何にかかわらず)でこれらのビットを処理しなければなりません。 これは逆戻りの、より簡単な実現を考慮します。
Lang, et al. Standards Track [Page 8] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[8ページ]RFC RSVP-Te拡張子
signaling (see Section 12) but also facilitates the transparent delivery of protected services since any intermediate node is not required to know the semantics associated with the incoming LSP Protection Type value.
また、どんな中間的ノードも入って来るLSP Protection Type値に関連している意味論を知るのに必要でないので、しかし、合図するのは(セクション12を見ます)保護されたサービスのわかりやすい配送を容易にします。
4.3. LSP Association
4.3. LSP協会
The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs.
セクション16で紹介されたASSOCIATION物は、働いて保護しているLSPsを関連づけるのに使用されます。
When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP.
働くLSPに合図するのに使用されると、ASSOCIATION物(セクション16を見る)のAssociation IDは保護しているLSPを特定します。 保護しているLSPに合図するのに使用されると、この分野は保護しているLSPによって保護されたLSPを特定します。
5. 1+1 Unidirectional Protection
5. 1+1単方向の保護
One of the simplest notions of end-to-end LSP protection is 1+1 unidirectional protection.
終わりから終わりへのLSP保護の最も簡単な概念の1つは1+1単方向の保護です。
Consider the following network topology:
以下のネットワーク形態を考えてください:
A---B---C---D
\ /
E---F---G
A---B---C---D\/E---F---G
The paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. A 1+1 protected path is established from A to D over [A,B,C,D] and [A,E,F,G,D], and traffic is transmitted simultaneously over both component paths (i.e., LSPs).
経路[A、B、C、D]と[A、E、F、G、D]は+1 ノードとリンクがばらばらになって、イングレス/出口ノードAとD.A1を無視して、保護された経路が[A、B、C、D]と[A、E、F、G、D]の上でAからDまで確立されるということです、そして、交通は同時に、両方のコンポーネント経路(すなわち、LSPs)の上に送られます。
During the provisioning phase, both LSPs are fully instantiated (and thus activated) so that no resource sharing can be done along the protecting LSP (nor can any extra-traffic be transported). It is also RECOMMENDED to set the N bit since no protection-switching signaling is assumed in this case.
食糧を供給する段階の間、両方のLSPsは保護に沿ってリソース・シェアリングが全くできないように完全に例示された(そして、このようにして動かされます)LSP(少しの余分な交通も輸送できない)です。 また、それはノー・プロテクションを切り換えるシグナリングがこの場合想定されるのでNビットを設定するRECOMMENDEDです。
When a failure occurs (say, at node B) and is detected at end-node D, the receiver at D selects the normal traffic from the other LSP. From this perspective, 1+1 unidirectional protection can be seen as an uncoordinated protection-switching mechanism acting independently at both endpoints. Also, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation.
失敗が起こって(たとえばノードBで)、エンドノードDで検出されるとき、Dの受信機はもう片方のLSPからの通常の交通を選択します。 この見解から、1+1単方向の保護を非調整された保護スイッチ開閉装置と両方の終点で単独行動を取ると考えることができます。 また、失敗状態のLSPに関して、それは_ERROR_SPEC物([RFC3473]を見る)のPath_州Removed FlagをPathErrメッセージ世代に設定しないRECOMMENDEDです。
Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
以下に注意してください。 両方の経路がSRLGが修復性を確実にするためにばらばらになるということであることが必要です。 さもなければ、ただ一つの失敗は、LSPsを扱って、保護しながら、両方に影響を与えるかもしれません。
Lang, et al. Standards Track [Page 9] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[9ページ]RFC RSVP-Te拡張子
5.1. Identifiers
5.1. 識別子
To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the two LSPs.
協会操作を簡素化するために、両方のLSPsは同じセッションに属します。 したがって、両方のLSPsに、SESSION物は同じであるに違いありません。 しかしながら、LSP IDは、2LSPsを見分けるために異なっていなければなりません。
A new PROTECTION object (see Section 14) is included in the Path message. This object carries the desired end-to-end LSP Protection Type -- in this case, "1+1 Unidirectional". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
新しいPROTECTION物(セクション14を見る)はPathメッセージに含まれています。 この物は終わりから終わりへの必要なLSP Protection Typeを運びます--この場合「1+1単方向。」 このLSP Protection Type値はuniと双方向のLSPsの両方に適切です。
To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.
保護しているLSPと働くLSP(信号が取られる)を区別するのを許容するために、PROTECTION物に0、0、およびASSOCIATION物(保護LSP_IDへのAssociation ID)のPビットにSビットを設定することによって、働くLSPは合図されます。 PROTECTION物に0、1、およびASSOCIATION物(関連保護されたLSP_IDへのAssociation ID)のPビットにSビットを設定することによって、保護しているLSPは合図されます。
After protection switching completes, and after reception of the PathErr message, to keep track of the LSP from which the signal is taken, the protecting LSP SHOULD be signaled with the O bit set. The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]). This process assumes the tail- end node has notified the head-end node that traffic selection switchover has occurred.
切り換えが終了する保護の後、およびPathErrメッセージのレセプションの後に、信号がどれであるかから取られたLSP、保護しているLSP SHOULDの動向をおさえるには、Oビットがセットした状態で、合図されてください。 以前LSP MAYを扱って、ADMIN_STATUS物に設定されたAビットで合図されてください([RFC3473]を見てください)。 この過程は、テールエンドノードが、交通選択転換が起こったことをギヤエンドのノードに通知したと仮定します。
6. 1+1 Bidirectional Protection
6. 1 +1 双方向の保護
1+1 bidirectional protection is a scheme that provides end-to-end protection for bidirectional LSPs.
1 +1 双方向の保護は終わりから終わりへの保護を双方向のLSPsに供給する計画です。
Consider the following network topology:
以下のネットワーク形態を考えてください:
A---B---C---D
\ /
E---F---G
A---B---C---D\/E---F---G
The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. A bidirectional LSP is established from A to D over each path, and traffic is transmitted simultaneously over both LSPs. In this scheme, both endpoints must receive traffic over the same LSP. Note also that both LSPs are fully instantiated (and thus activated) so that no resource sharing can be done along the protection path (nor can any extra-traffic be transported).
LSPs[A、B、C、D]と[A、E、F、G、D]はノードです、そして、リンクはばらばらになります、そして、イングレス/出口ノードAとD.のA双方向のLSPを無視するのは各経路にわたってAからDまで設立されます、そして、交通は同時に、両方のLSPsの上に伝えられます。 この計画では、両方の終点は同じLSPの上に交通を受けなければなりません。 また、両方のLSPsが保護経路に沿ってリソース・シェアリングが全くできない(少しの余分な交通も輸送できない)ように完全に例示されていて(その結果、活性)であることに注意してください。
Lang, et al. Standards Track [Page 10] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[10ページ]RFC RSVP-Te拡張子
When a failure is detected by one or both endpoints of the LSP, both endpoints must select traffic from the other LSP. This action must be coordinated between node A and D. From this perspective, 1+1 bidirectional protection can be seen as a coordinated protection- switching mechanism between both endpoints.
失敗がLSPの1か終点の両方によって検出されるとき、両方の終点はもう片方のLSPからの交通を選択しなければなりません。 ノードAとD.Fromの間でこれほど透視していた状態でこの動作を調整しなければならなくて、aが両方の終点の間の保護スイッチ開閉装置を調整したので、1つの+1双方向の保護は見ることができます。
Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
以下に注意してください。 両方の経路がSRLGが修復性を確実にするためにばらばらになるということであることが必要です。 さもなければ、ただ一つの失敗は、LSPsを扱って、保護しながら、両方に影響を与えるかもしれません。
6.1. Identifiers
6.1. 識別子
To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the two LSPs.
協会操作を簡素化するために、両方のLSPsは同じセッションに属します。 したがって、両方のLSPsに、SESSION物は同じであるに違いありません。 しかしながら、LSP IDは、2LSPsを見分けるために異なっていなければなりません。
A new PROTECTION object (see Section 14) is included in the Path message. This object carries the desired end-to-end LSP Protection Type -- in this case, "1+1 Bidirectional". This LSP Protection Type value is only applicable to bidirectional LSPs.
新しいPROTECTION物(セクション14を見る)はPathメッセージに含まれています。 この物がこの場合終わりから終わりへの必要なLSP Protection Typeを運ぶ、「1、+1 双方向、」 このLSP Protection Type値は単に双方向のLSPsに適切です。
It is also desirable to allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP. This is achieved for the working LSP by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object the Association ID to the associated protected LSP_ID.
また、保護しているLSPと働くLSP(信号が取られる)を区別するのを許容するのも望ましいです。 これは、働くLSPのためにPROTECTION物に0、0、およびASSOCIATION物(保護LSP_IDへのAssociation ID)のPビットにSビットを設定することによって、達成されます。 PROTECTION物にSビットを0に設定することによって、保護しているLSPは合図されて、Pは1、およびASSOCIATION物で関連保護されたLSP_IDにAssociation IDに噛み付きました。
6.2. End-to-End Switchover Request/Response
6.2. 終わりから終わりへの転換要求/応答
To coordinate the switchover between endpoints, an end-to-end switchover request/response exchange is needed since a failure affecting one of the LSPs results in both endpoints switching to the other LSP (resulting in receiving traffic from the other LSP) in their respective directions.
LSPsの1つに影響する失敗がそれらのそれぞれの指示に基づきもう片方のLSP(もう片方のLSPからの交通を受けるようになる)に切り替わる両方の終点をもたらすので、終点の間の転換を調整するのに、終わりから終わりへの転換要求/応答交換が必要です。
The procedure is as follows:
手順は以下の通りです:
1. If an end-node (A or D) detects the failure of the working LSP
(or a degradation of signal quality over the working LSP) or
receives a Notify message including its SESSION object within
the <upstream/downstream session list> (see [RFC3473]), and the
new error code/sub-code "Notify Error/ LSP Locally Failed" in
the (IF_ID)_ERROR_SPEC object, it MUST begin receiving on the
protecting LSP. Note that the <sender descriptor> or <flow
1. 働くLSP(または、働くLSPの上の信号品質の低下)の失敗を検出するか、<上流/川下セッションリスト>([RFC3473]を見る)中にSESSION物を含むNotifyメッセージを受け取って、またはエンドノード(AかD)は(_IDであるなら)_ERROR_SPEC物に新しいサブエラーコード/コード「局所的に失敗された誤り/LSPに通知してください」を受け取るなら、それは、保護しているLSPで受信し始めなければなりません。 <送付者記述子の>か<が流れることに注意してください。
Lang, et al. Standards Track [Page 11] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[11ページ]RFC RSVP-Te拡張子
descriptor> is also present in the Notify message that resolves
any ambiguity and race condition since identifying (together
with the SESSION object) the LSP under failure condition.
また、記述子>も失敗条件のもとでLSPを特定する(SESSION物と共に)以来どんなあいまいさと競合条件も取り除くNotifyメッセージに存在しています。
Note: (IF_ID)_ERROR_SPEC indicates that either the
ERROR_SPEC (C-Type 1/2) or the ERROR_SPEC (C-Type 3/4,
defined in [RFC3473]) can be used.
以下に注意してください。 (_IDであるなら)_ERROR_SPECは、ERROR_SPEC(C-タイプ1/2)かERROR_SPEC([RFC3473]で定義されたC-タイプ3/4)のどちらかを使用できるのを示します。
This node MUST reliably send a Notify message, including the
MESSAGE_ID object, to the other end-node (D or A, respectively)
with the new error code/sub-code "Notify Error/LSP Failure"
(Switchover Request) indicating the failure of the working LSP.
This Notify message MUST be sent with the ACK_Desired flag set
in the MESSAGE_ID object to request the receiver to send an
acknowledgment for the message (see [RFC2961]).
このノードはNotifyメッセージを確かに送らなければなりません、MESSAGE_ID物を含んでいて、新しいサブエラーコード/コード「誤り/LSPの故障に通知してください」(転換Request)が働くLSPの失敗を示しているもう片方のエンドノード(それぞれDかA)に。 メッセージのための承認を送るよう受信機に要求するためにMESSAGE_ID物に設定されたACK_Desired旗でこのNotifyメッセージを送らなければなりません([RFC2961]を見てください)。
This (switchover request) Notify message MAY indicate the
identity of the failed link or any other relevant information
using the IF_ID ERROR_SPEC object (see [RFC3473]). In this
case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC
object in the Notify message; otherwise, the corresponding
(data plane) information SHOULD be received in the
PathErr/ResvErr message.
これが失敗したリンクかいかなる他の関連情報使用のアイデンティティも示すかもしれない、(転換要求)が、メッセージに通知する_ID ERROR_SPECが反対するなら([RFC3473]を見てください)。 この場合、__ID ERROR_SPEC物がERRORを取り替えるなら、SPECはNotifyメッセージで反対します。 そうでなければ、対応する(データ飛行機)情報SHOULD、PathErr/ResvErrメッセージに受け取ってください。
2. Upon receipt of the (switchover request) Notify message, the
end-node (D or A, respectively) MUST begin receiving from the
protecting LSP.
2. を受け取り次第、(転換要求)はメッセージに通知して、エンドノード(それぞれDかA)は、保護しているLSPから受信し始めなければなりません。
This node MUST reliably send a Notify message, including the
MESSAGE_ID object, to the other end-node (A or D,
respectively). This (switchover response) Notify message MUST
also include a MESSAGE_ID_ACK object to acknowledge reception
of the (switchover request) Notify message.
このノードはもう片方のエンドノード(それぞれAかD)にMESSAGE_ID物を含むNotifyメッセージを確かに送らなければなりません。 また、これがレセプションを承認するMESSAGE_ID_ACK物を含まなければならない、(転換応答)が、メッセージに通知する(転換要求) メッセージに通知してください。
This (switchover response) Notify message MAY indicate the
identity of the failed link or any other relevant information
using the IF_ID ERROR_SPEC object (see [RFC3473]).
これが失敗したリンクかいかなる他の関連情報使用のアイデンティティも示すかもしれない、(転換応答)が、メッセージに通知する_ID ERROR_SPECが反対するなら([RFC3473]を見てください)。
Note: upon receipt of the (switchover response) Notify message,
the end-node (A or D, respectively) MUST send an Ack message to
the other end-node to acknowledge its reception.
以下に注意してください。 を受け取り次第、(転換応答)はメッセージに通知して、エンドノード(それぞれAかD)は、レセプションを承認するためにAckメッセージをもう片方のエンドノードに送らなければなりません。
Since the intermediate nodes (B, C, E, F, and G) are assumed to be GMPLS RSVP-TE signaling capable, each node adjacent to the failure MAY generate a Notify message directed either to the LSP head-end (upstream direction), or the LSP tail-end (downstream direction), or even both. Therefore, it is expected that these LSP terminating nodes (that MAY also detect the failure of the LSP from the data
中間的ノード(B、C、E、F、およびG)ができるGMPLS RSVP-TEシグナリングであると思われるので、失敗に隣接した各ノードはLSPギヤエンド(上流の指示)、またはLSP末端に向けられたNotifyメッセージ(川下の指示)、または両方さえ発生させるかもしれません。 したがって、それが予想される、それ、これらのLSP終わりノード、(また、それはデータからLSPの失敗を検出するかもしれません。
Lang, et al. Standards Track [Page 12] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[12ページ]RFC RSVP-Te拡張子
plane) provide either the right correlation mechanism to avoid repetition of the above procedure or just discard subsequent Notify messages corresponding to the same Session. In addition, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_ Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation.
飛行機) 正しい相関関係メカニズムを提供して、上の手順の反復を避けるか、またはただ同じSessionに対応するその後のNotifyメッセージを捨ててください。 さらに、失敗状態のLSPに関して、それは_ERROR_SPEC物([RFC3473]を見る)のPath_州Removed FlagをPathErrメッセージ世代に設定しないRECOMMENDEDです。
After protection switching completes (step 2), and after reception of the PathErr message, to keep track of the LSP from which the signal is taken, the protecting LSP SHOULD be signaled with the O bit set. The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).
保護の切り換えが(ステップ2)を完成した後、およびPathErrメッセージのレセプションの後に、信号がどれであるかから取られたLSP、保護しているLSP SHOULDの動向をおさえるには、Oビットがセットした状態で、合図されてください。 以前LSP MAYを扱って、ADMIN_STATUS物に設定されたAビットで合図されてください([RFC3473]を見てください)。
Note: when the N bit is set, the end-to-end switchover request/ response exchange described above only provides control plane coordination (no actions are triggered at the data plane level).
以下に注意してください。 Nビットが設定されるとき、上で説明された終わりから終わりへの転換要求/応答交換はコントロール飛行機コーディネートを提供するだけです(動作は全くデータ飛行機レベルで引き起こされません)。
7. 1:1 Protection with Extra-Traffic
7. 余分な交通との1:1保護
The most common case of end-to-end 1:N protection is to establish, between the same endpoints, an end-to-end working LSP (thus, N = 1) and a dedicated end-to-end protecting LSP that are mutually link/ node/SRLG disjoint. This protects against working LSP failure(s).
終わりから終わりへの1:N保護の最も一般的なケースがLSP(その結果、N=1)を扱いながら同じ終点の間で終わりから終わりを確立することであり、ひたむきな互いにそうであるLSPを保護する終わりから終わりへのリンク/ノード/SRLGはばらばらになります。 これは働くLSPの故障から守ります。
The protecting LSP is used for switchover when the working LSP fails. GMPLS RSVP-TE signaling allows for the pre-provisioning of protecting LSPs by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type protecting. Here, working and protecting LSPs are signaled as primary LSPs; both are fully instantiated during the provisioning phase.
働くLSPが失敗すると、保護しているLSPは転換に使用されます。 GMPLS RSVP-TEシグナリングはPathメッセージ(PROTECTION物で; セクション14を見る)でLSPsがタイプ保護のものであることを示すことによってLSPsを保護することのプレの食糧を供給することを考慮します。 ここで、LSPsを扱って、保護するのは第一のLSPsとして合図されます。 両方が食糧を供給する段階の間、完全に例示されます。
Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP. Thus, the protecting LSP is capable of carrying extra-traffic with the caveat that this traffic will be preempted if the working LSP fails.
保護しているLSPのためのリソースをあらかじめ割り当てますが、運ばれたこのLSPを使用する終わりから先取り可能交通は終わりであるかもしれません。 したがって、この交通が警告でなる余分な交通にもかかわらず、働くLSPであるなら先取りされて、LSPが運ぶことができる保護は失敗します。
The setup of the working LSP SHOULD indicate that the LSP head-end and tail-end node wish to receive Notify messages using the NOTIFY REQUEST object. The node upstream to the failure (upstream in terms of the direction an Path message traverses) SHOULD send a Notify message to the LSP head-end node, and the node downstream to the failure SHOULD send an Notify message to the LSP tail-end node. Upon receipt of the Notify messages, both the end-nodes MUST switch the (normal) traffic from the working LSP to the pre-configured protecting LSP (see Section 7.2). Moreover, some coordination is required if extra-traffic is carried over the end-to-end protecting
働くLSP SHOULDのセットアップは、LSPギヤエンドと末端ノードがNOTIFY REQUEST物を使用することでNotifyメッセージを受け取りたがっているのを示します。 LSPギヤエンドのノードにNotifyメッセージを発信させて、ノードの失敗への上流(Pathメッセージが横断する指示上流の)のSHOULDはSHOULDがLSP末端ノードへのNotifyメッセージを送る失敗にノード川下を発信させます。 Notifyメッセージを受け取り次第、両方のエンドノードは(正常)の働くLSPからあらかじめ設定された保護LSPまでの交通を切り換えなければなりません(セクション7.2を見てください)。 そのうえ、余分な交通が終わりから終わりへの保護の上まで運ばれるなら、何らかのコーディネートが必要です。
Lang, et al. Standards Track [Page 13] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[13ページ]RFC RSVP-Te拡張子
LSP. Note that if the working and the protecting LSP are established between the same end-nodes, no further notification is required to indicate that the working LSPs are no longer protected.
LSP。 働きと保護しているLSPが同じエンドノードの間に設立されるなら、さらなる通知は全く働くLSPsがもう保護されないのを示すのに必要でないことに注意してください。
Consider the following topology:
以下のトポロジーを考えてください:
A---B---C---D
\ /
E---F---G
A---B---C---D\/E---F---G
The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Both LSPs are fully instantiated (resources are allocated for both working and protecting LSPs) and no resource sharing can be done along the protection path since the primary protecting LSP can carry extra-traffic.
保護LSP[A、E、F、G、D]は働くLSP[A、B、C、D]を保護できました。 両方のLSPsを完全に例示します、そして、(両方のためにLSPsを扱って、保護しながら、リソースを割り当てます)LSPを保護する予備選挙が余分な交通を運ぶことができるので、保護経路に沿ってリソース・シェアリングが全くできません。
Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
以下に注意してください。 両方の経路がSRLGが修復性を確実にするためにばらばらになるということであることが必要です。 さもなければ、ただ一つの失敗は、LSPsを扱って、保護しながら、両方に影響を与えるかもしれません。
7.1. Identifiers
7.1. 識別子
To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the protecting LSP that can carry extra-traffic.
協会操作を簡素化するために、両方のLSPsは同じセッションに属します。 したがって、両方のLSPsに、SESSION物は同じであるに違いありません。 しかしながら、LSP IDは、働く交通を運ぶ保護されたLSPと余分な交通を運ぶことができる保護しているLSPを見分けるために異なっていなければなりません。
A new PROTECTION object (see Section 14) is included in the Path message used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "1:N Protection with Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
新しいPROTECTION物(セクション14を見る)は2LSPsをセットアップするのに使用されるPathメッセージに含まれています。 この物は終わりから終わりへの必要なLSP Protection Typeを運びます--この場合「余分な交通との1:N保護。」 このLSP Protection Type値はuniと双方向のLSPsの両方に適切です。
The working LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID.
新しいPROTECTION物に0、0、およびASSOCIATION物(保護LSP_IDへのAssociation ID)のPビットにSビットを設定することによって、働くLSPは合図されます。
The protecting LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.
新しいPROTECTION物に0、1、およびASSOCIATION物(関連保護されたLSP_IDへのAssociation ID)のPビットにSビットを設定することによって、保護しているLSPは合図されます。
Lang, et al. Standards Track [Page 14] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[14ページ]RFC RSVP-Te拡張子
7.2. End-to-End Switchover Request/Response
7.2. 終わりから終わりへの転換要求/応答
To coordinate the switchover between endpoints, an end-to-end switchover request/response is needed such that the affected LSP is moved to the protecting LSP. Protection switching from the working to the protecting LSP (implying preemption of extra-traffic carried over the protecting LSP) must be initiated by one of the end-nodes (A or D).
終点の間の転換を調整するのに、終わりから終わりへの転換要求/応答が必要であるので、影響を受けるLSPは保護しているLSPに動かされます。 エンドノード(AかD)の1つで働きから保護LSP(余分な交通の先取りが保護しているLSPを引き継いだのを含意する)に切り替わる保護を開始しなければなりません。
The procedure is as follows:
手順は以下の通りです:
1. If an end-node (A or D) detects the failure of the working LSP
(or a degradation of signal quality over the working LSP) or
receives a Notify message including its SESSION object within
the <upstream/downstream session list> (see [RFC3473]), and the
new error code/sub-code "Notify Error/LSP Locally Failed" in
the (IF_ID)_ERROR_SPEC object, it disconnects the extra-traffic
from the protecting LSP. Note that the <sender descriptor> or
<flow descriptor> is also present in the Notify message that
resolves any ambiguity and race condition since identifying
(together with the SESSION object) the LSP under failure
condition.
1. 働くLSP(または、働くLSPの上の信号品質の低下)の失敗を検出するか、<上流/川下セッションリスト>([RFC3473]を見る)中にSESSION物を含むNotifyメッセージを受け取って、またはエンドノード(AかD)は(_IDであるなら)_ERROR_SPEC物に新しいサブエラーコード/コード「局所的に失敗された誤り/LSPに通知してください」を受け取るなら、それは保護しているLSPからの余分な交通を外します。 また、<送付者記述子の>か<流れ記述子>も失敗条件のもとでLSPを特定する(SESSION物と共に)以来どんなあいまいさと競合条件も取り除くNotifyメッセージに存在していることに注意してください。
This node MUST reliably send a Notify message, including the
MESSAGE_ID object, to the other end-node (D or A, respectively)
with the new error code/sub-code "Notify Error/LSP Failure"
(Switchover Request) indicating the failure of the working LSP.
This Notify message MUST be sent with the ACK_Desired flag set
in the MESSAGE_ID object to request the receiver to send an
acknowledgment for the message (see [RFC2961]).
このノードはNotifyメッセージを確かに送らなければなりません、MESSAGE_ID物を含んでいて、新しいサブエラーコード/コード「誤り/LSPの故障に通知してください」(転換Request)が働くLSPの失敗を示しているもう片方のエンドノード(それぞれDかA)に。 メッセージのための承認を送るよう受信機に要求するためにMESSAGE_ID物に設定されたACK_Desired旗でこのNotifyメッセージを送らなければなりません([RFC2961]を見てください)。
This (switchover request) Notify message MAY indicate the
identity of the failed link or any other relevant information
using the IF_ID ERROR_SPEC object (see [RFC3473]). In this
case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC
object in the Notify message; otherwise, the corresponding
(data plane) information SHOULD be received in the
PathErr/ResvErr message.
これが失敗したリンクかいかなる他の関連情報使用のアイデンティティも示すかもしれない、(転換要求)が、メッセージに通知する_ID ERROR_SPECが反対するなら([RFC3473]を見てください)。 この場合、__ID ERROR_SPEC物がERRORを取り替えるなら、SPECはNotifyメッセージで反対します。 そうでなければ、対応する(データ飛行機)情報SHOULD、PathErr/ResvErrメッセージに受け取ってください。
2. Upon receipt of the (switchover request) Notify message, the
end-node (D or A, respectively) MUST disconnect the extra-
traffic from the protecting LSP and begin sending/receiving
normal traffic out/from the protecting LSP.
2. を受け取り次第、(転換要求)がメッセージに通知して、エンドノード(それぞれDかA)は、保護しているLSPから保護しているLSPから余分な交通を外して、/から通常の交通を送るか、または受け始めなければなりません。
This node MUST reliably send a Notify message, including the
MESSAGE_ID object, to the other end-node (A or D,
respectively). This (switchover response) Notify message MUST
このノードはもう片方のエンドノード(それぞれAかD)にMESSAGE_ID物を含むNotifyメッセージを確かに送らなければなりません。 (転換応答)がメッセージに通知するこれはそうしなければなりません。
Lang, et al. Standards Track [Page 15] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[15ページ]RFC RSVP-Te拡張子
also include a MESSAGE_ID_ACK object to acknowledge reception
of the (switchover request) Notify message.
また、レセプションを承認するMESSAGE_ID_ACK物を含めてください、(転換要求) メッセージに通知してください。
This (switchover response) Notify message MAY indicate the
identity of the failed link or any other relevant information
using the IF_ID ERROR_SPEC object (see [RFC3473]).
これが失敗したリンクかいかなる他の関連情報使用のアイデンティティも示すかもしれない、(転換応答)が、メッセージに通知する_ID ERROR_SPECが反対するなら([RFC3473]を見てください)。
Note: since the Notify message generated by the other end-node
(A or D, respectively) is distinguishable from the one
generated by an intermediate node, there is no possibility of
connecting the extra-traffic to the working LSP due to the
receipt of a Notify message from an intermediate node.
以下に注意してください。 もう片方のエンドノード(それぞれAかD)で発生するNotifyメッセージが中間的ノードで発生するものから区別可能であるので、中間的ノードからのNotifyメッセージの領収書のため働くLSPへの余分な交通をつなげる可能性が全くありません。
3. Upon receipt of the (switchover response) Notify message, the
end-node (A or D, respectively) MUST begin receiving normal
traffic from or sending normal traffic out the protecting LSP.
3. を受け取り次第、エンドノード(それぞれAかD)は、(転換応答)はメッセージに通知して、保護しているLSPから通常の交通を受けるか、または通常の交通を送り始めなければなりません。
This node MUST also send an Ack message to the other end-node
(D or A, respectively) to acknowledge the reception of the
(switchover response) Notify message.
また、このノードがレセプションを承認するもう片方のエンドノード(それぞれDかA)にAckメッセージを送らなければならない、(転換応答) メッセージに通知してください。
Note 1: a 2-phase protection-switching signaling is used in the present context; a 3-phase signaling (see [RFC4426]) that would imply a notification message, a switchover request, and a switchover response messages is not considered here. Also, when the protecting LSPs do not carry extra-traffic, protection-switching signaling (as defined in Section 6.2) MAY be used instead of the procedure described in this section.
注意1: 2フェーズの保護を切り換えるシグナリングは現在の文脈で使用されます。 通知メッセージ、転換要求、および転換応答メッセージを含意する3フェーズのシグナリング([RFC4426]を見る)はここで考えられません。 また、保護しているLSPsが余分な交通を運ばないとき、保護を切り換えるシグナリング(セクション6.2で定義されるように)はこのセクションで説明された手順の代わりに使用されるかもしれません。
Note 2: when the N bit is set, the above end-to-end switchover request/response exchange only provides control plane coordination (no actions are triggered at the data plane level).
注意2: Nビットが設定されるとき、終わりから終わりへの転換上の要求/応答交換はコントロール飛行機コーディネートを提供するだけです(動作は全くデータ飛行機レベルで引き起こされません)。
After protection switching completes (step 3), and after reception of the PathErr message, to keep track of the LSP from which the normal traffic is taken, the protecting LSP SHOULD be signaled with the O bit set. In addition, the formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).
保護の切り換えが(ステップ3)を完成した後、およびPathErrメッセージのレセプションの後に、通常の交通がどれであるかから取られたLSP、保護しているLSP SHOULDの動向をおさえるには、Oビットがセットした状態で、合図されてください。 添加で合図する、以前LSP MAYを扱って、ADMIN_STATUS物に設定されたAビットで合図されてください([RFC3473]を見てください)。
7.3. 1:N (N > 1) Protection with Extra-Traffic
7.3. 1: 余分な交通とのN(N>1)保護
1:N (N > 1) protection with extra-traffic assumes that the fully provisioned protecting LSP is resource-disjoint from the N working LSPs. This protecting LSP thereby allows for carrying extra-traffic. Note that the N working LSPs and the protecting LSP are all between the same pair of endpoints. In addition, the N working LSPs (considered as identical in terms of traffic parameters) MAY be
余分な交通に伴う1:N(N>1)保護は、完全に食糧を供給された保護LSPがN働くLSPsからリソースでばらばらになると仮定します。 その結果、この保護LSPは、余分な交通を運ぶと考慮します。 同じ組の終点の間には、N働くLSPsと保護しているLSPがあることに注意してください。 さらに、N働くLSPs(交通パラメタが同じであるとみなされる)がそうです。
Lang, et al. Standards Track [Page 16] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[16ページ]RFC RSVP-Te拡張子
mutually resource-disjoint. Coordination between end-nodes is required when switching from one of the working to the protecting LSP.
互いにリソースでばらばらになってください。 働きのものから保護しているLSPに切り替わるとき、エンドノードの間のコーディネートが必要です。
Each working LSP is signaled with both S bit and P bit set to 0. The LSP Protection Type is set to 0x04 (1:N Protection with Extra- Traffic) during LSP setup. Each Association ID points to the protecting LSP ID.
それぞれの働くLSPは0に設定されたSビットとPビットの両方で合図されます。 LSP Protection TypeはLSPセットアップの間の0×04(Extra交通を伴う1:N Protection)へのセットです。 それぞれのAssociation IDは保護しているLSP IDを示します。
The protecting LSP (carrying extra-traffic) is signaled with the S bit set to 0 and the P bit set to 1. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1.
保護LSP(余分な交通を運ぶ)は0に設定されたSビットで合図されました、そして、Pビットは1にセットしました。 LSP Protection TypeはLSPセットアップの間の0×04(Extra-交通を伴う1:N Protection)へのセットです。 デフォルトでN=1に対応する保護されたLSPのLSP IDにAssociation IDを設定しなければなりません。
Any signaling procedure applicable to 1:1 protection with extra- traffic equally applies to 1:N protection with extra-traffic.
余分な交通で1:1保護に適切などんなシグナリング手順も余分な交通で等しく1:N保護に適用されます。
8. Rerouting without Extra-Traffic
8. 余分な交通なしでコースを変更します。
End-to-end (pre-planned) rerouting without extra-traffic relies on the establishment between the same pair of end-nodes of a working LSP and a protecting LSP that is link/node/SRLG disjoint from the working LSP. However, in this case the protecting LSP is not fully instantiated; thus, it cannot carry any extra-traffic (note that this does not mean that the corresponding resources cannot be used by other LSPs). Therefore, this mechanism protects against working LSP failure(s) but requires activation of the protecting LSP after failure occurrence.
余分な交通のない(あらかじめ計画される)のコースを変更するのが同じように設立を当てにする終わりから終わりへの働くLSPと保護しているLSPのエンドノードのリンク/ノード/SRLGである組は働くLSPからばらばらになります。 しかしながら、この場合、保護しているLSPは完全に例示されるというわけではありません。 したがって、それは少しの余分な交通も運ぶことができません(これが、他のLSPsが対応するリソースを使用できないことを意味しないことに注意してください)。 したがって、このメカニズムは、働くLSPの故障から守りますが、失敗発生の後に保護しているLSPの起動を必要とします。
Signaling is performed by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type working and protecting, respectively. Protecting LSPs are used for fast switchover when working LSPs fail. In this case, working and protecting LSPs are signaled as primary LSP and secondary LSP, respectively. Thus, only the working LSP is fully instantiated during the provisioning phase, and for the protecting LSPs, no resources are committed at the data plane level (they are pre- reserved at the control plane level only). The setup of the working LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in Section 4 of [RFC3473]) that the LSP head-end node (and possibly the tail-end node) wish to receive a Notify message upon LSP failure occurrence. Upon receipt of the Notify message, the head-end node MUST switch the (normal) traffic from the working LSP to the protecting LSP after its activation. Note that since the working and the protecting LSPs are established between the same end-nodes, no further notification is required to indicate that the working LSPs are without protection.
Pathメッセージ(PROTECTION物で; セクション14を見る)でLSPsがタイプの働きとそれぞれ保護するものであることを示すことによって、シグナリングは実行されます。 働くLSPsが失敗すると、保護LSPsは速い転換に使用されます。 この場合、LSPsを扱って、保護するのは第一のLSPと二次LSPとしてそれぞれ合図されます。 働くLSPだけが食糧を供給する段階の間、完全に例示されます、そして、保護しているLSPsに関して、リソースは全くデータ飛行機レベルで遂行されません(それらはコントロール飛行機レベルだけであらかじめ予約されます)。 働くLSP SHOULDのセットアップは、LSPギヤエンドのノード(そして、ことによると末端ノード)がLSP失敗発生に関するNotifyメッセージを受け取りたがっているのを示します([RFC3473]のセクション4の指定されるとしてのNOTIFY REQUEST物を使用します)。 Notifyメッセージを受け取り次第、ギヤエンドのノードは起動の後に(正常)の働くLSPから保護しているLSPまでの交通を切り換えなければなりません。 働きと保護しているLSPsが同じエンドノードの間に設立されるのでさらなる通知は全く働くLSPsが保護なしであるのを示すのに必要でないことに注意してください。
Lang, et al. Standards Track [Page 17] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[17ページ]RFC RSVP-Te拡張子
To make bandwidth pre-reserved for a protecting (but not activated) LSP available for extra-traffic, this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP), and the Holding Priority field to at least X+1. Also, if the resources pre- reserved for the protecting LSP are used by lower-priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10).
余分な交通に利用可能な保護(しかし、動かされない)LSPのために帯域幅をあらかじめ控えさせるために、広告を出しているUnreserved Bandwidthに保護しているLSPのHolding Priorityより低さ(数の上でより高いことを意味する)にこの帯域幅を優先権で含むことができました。 さらに、Interface Switching Capability DescriptorサブTLVのマックスLSP Bandwidth分野は保護しているLSPのためにあらかじめ控えられた帯域幅が余分な交通に利用可能であるという事実を反映するべきです。 そして、X(Xが保護しているLSPのSetup Priorityであるところ)にSESSION_ATTRIBUTE物のSetup Priority分野を設定することによって(Pathメッセージで)保護しているLSPのためにあらかじめ控えられた帯域幅、およびHolding Priority分野を少なくともX+1に使用することで余分な交通へのLSPsを設立できます。 また、保護しているLSPのためにあらかじめ予約されたリソースが低優先度LSPsによって使用されるなら、保護しているLSPが活性であるときに(セクション10を見てください)、これらのLSPsを先取りしなければなりません。
Consider the following topology:
以下のトポロジーを考えてください:
A---B---C---D
\ /
E---F---G
A---B---C---D\/E---F---G
The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources are only allocated for the working LSP). Therefore, the protecting LSP cannot carry any extra-traffic. When a failure is detected on the working LSP (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP instantiated during the (pre-)provisioning phase. This requires:
保護LSP[A、E、F、G、D]は働くLSP[A、B、C、D]を保護できました。 保護されたLSPだけが完全に例示されます(働くLSPのためにリソースを割り当てるだけです)。 したがって、保護しているLSPは少しの余分な交通も運ぶことができません。 失敗が働くLSP(たとえばBで)に検出されるとき、誤りは、イングレスノード(A)に伝播される、そして/または、通知されます((_IDであるなら)_ERROR_SPEC物で「局所的に失敗された誤り/LSPに通知してください」という新しいサブエラーコード/コードがあるNotifyメッセージを使用します)。 レセプションでは、後者がLSPが例示した二次保護を動かす、(プレ、)、フェーズに食糧を供給します。 これは以下を必要とします。
(1) the ability to identify a "secondary protecting LSP" (hereby
called the "secondary LSP") used to recover another primary
working LSP (hereby called the "protected LSP")
(2) the ability to associate the secondary LSP with the protected
LSP
(3) the capability to activate a secondary LSP after failure
occurrence.
(1) 「二次保護LSP」(これにより「二次LSP」と呼ばれる)を特定する能力は以前はよく別の第一の働くLSPを回収していました。(これにより、「保護されたLSP」) (2) 保護されたLSP(3)に二次LSPを関連づける能力を失敗発生の後に二次LSPを動かす能力と呼びました。
In the following subsections, these features are described in more detail.
以下の小区分では、これらの特徴はさらに詳細に説明されます。
Lang, et al. Standards Track [Page 18] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[18ページ]RFC RSVP-Te拡張子
8.1. Identifiers
8.1. 識別子
To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra- traffic.
協会操作を簡素化するために、両方のLSPs(すなわち、保護と二次LSPs)は同じセッションに属します。 したがって、両方のLSPsに、SESSION物は同じであるに違いありません。 しかしながら、LSP IDは、働く交通を運ぶ保護されたLSPと余分な交通を運ぶことができない二次LSPを見分けるために異なっていなければなりません。
A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type (in this case, "Rerouting without Extra-Traffic"). This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
新しいPROTECTION物(セクション14を見る)は、2LSPsをセットアップするのに使用されます。 この物は終わりから終わりへの必要なLSP Protection Type(この場合「余分な交通のないコースを変更する」)を運びます。 このLSP Protection Type値はuniと双方向のLSPsの両方に適切です。
8.2. Signaling Primary LSPs
8.2. 第一のLSPsに合図します。
The new PROTECTION object is included in the Path message during signaling of the primary working LSP, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
新しいPROTECTION物は第一の働くLSPのシグナリングの間、Pathメッセージに含まれています、終わりから終わりへのLSP Protection Type「コースを変更する余分な交通なしで」であることへの選択値群で。
Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.
新しいPROTECTION物に0、0、およびASSOCIATION物(関連二次保護LSP_IDへのAssociation ID)のPビットにSビットを設定することによって、第一の働くLSPsは合図されます。
8.3. Signaling Secondary LSPs
8.3. 二次LSPsに合図します。
The new PROTECTION object is included in the Path message during signaling of secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
新しいPROTECTION物は終わりから終わりへのLSP Protection TypeとLSPsが「余分な交通なしでコースを変更し」始めるのを評価する二次保護のシグナリングの間、Pathメッセージに含まれています。
Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP.
1、およびASSOCIATION物、二次LSPのシグナリングの前に知っていなければならない関連第一の働くLSP_IDへのAssociation IDに新しいPROTECTION物にSビットとPビットを設定することによって、二次保護LSPsは合図されます。
With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this secondary LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).
この設定で、二次LSP SHOULDのためのリソースがあらかじめ予約されますが、データ飛行機レベルでは遂行されないで、スイッチのインターナルが明白な動作まで確立される必要はないことを意味するのをこの二次LSPを動かすために取ります。 二次LSPの起動はPROTECTION物で0に設定されたSビットで変更されたPathメッセージを使用し終わっています。 ここに、第一のLSP(通常の交通を運ぶのにおいて準備ができる)になるこのLSPのためにリンクとノードリソースを割り当てなければなりません。
Lang, et al. Standards Track [Page 19] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[19ページ]RFC RSVP-Te拡張子
From [RFC3945], the secondary LSP is set up with resource pre- reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).
[RFC3945]から、二次LSPはリソースプレの予約にもかかわらず、ラベル前選択のあるなしにかかわらずセットアップされます(回復リソースを共有するのをともに許容して)。 前の場合(デフォルトと定義される)では、[RFC3473]と比べて、二次LSPシグナリングの間のラベル配分はどんな特定の手順も必要としません。 しかしながら、後者の場合では、二次LSP起動の間、ラベル(そして、その結果、リソース)再配分は起こるかもしれません。 これは、LSP活性化相の間ラベルが再選任されるかもしれないことを意味します(既存のラベル課題の上により高い先行がある状態で; また、[RFC3471]を見てください)。
Note: under certain circumstances (e.g., when pre-reserved protecting resources are used by lower-priority LSPs), it MAY be desirable to perform the activation of the secondary LSP in the upstream direction (Resv trigger message) instead of using the default downstream activation. In this case, any mis-ordering and any mis- interpretation between a refresh Resv (along the lower-priority LSP) and a trigger Resv message (along the secondary LSP) MUST be avoided at any intermediate node. For this purpose, upon reception of the Path message, the egress node MAY include the PROTECTION object in the Resv message. The latter is then processed on a hop-by-hop basis to activate the secondary LSP until reaching the ingress node. The PROTECTION object included in the Path message MUST be set as specified in this section. In this case, the PROTECTION object with the S bit MUST be set to 0 and included in the Resv message sent in the upstream direction. The upstream activation behavior SHOULD be configurable on a local basis. Details concerning lower-priority LSP preemption upon secondary LSP activation are provided in Section 10.
Note: under certain circumstances (e.g., when pre-reserved protecting resources are used by lower-priority LSPs), it MAY be desirable to perform the activation of the secondary LSP in the upstream direction (Resv trigger message) instead of using the default downstream activation. In this case, any mis-ordering and any mis- interpretation between a refresh Resv (along the lower-priority LSP) and a trigger Resv message (along the secondary LSP) MUST be avoided at any intermediate node. For this purpose, upon reception of the Path message, the egress node MAY include the PROTECTION object in the Resv message. The latter is then processed on a hop-by-hop basis to activate the secondary LSP until reaching the ingress node. The PROTECTION object included in the Path message MUST be set as specified in this section. In this case, the PROTECTION object with the S bit MUST be set to 0 and included in the Resv message sent in the upstream direction. The upstream activation behavior SHOULD be configurable on a local basis. Details concerning lower-priority LSP preemption upon secondary LSP activation are provided in Section 10.
9. Shared-Mesh Restoration
9. Shared-Mesh Restoration
An approach to reduce recovery resource requirements is to have protection LSPs sharing network resources when the working LSPs that they protect are physically (i.e., link, node, SRLG, etc.) disjoint. This mechanism is referred to as shared mesh restoration and is described in [RFC4426]. Shared-mesh restoration can be seen as a particular case of pre-planned LSP rerouting (see Section 8) that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. Here also, the recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, thus an explicit signaling action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This requires restoration signaling along the protecting LSP.
An approach to reduce recovery resource requirements is to have protection LSPs sharing network resources when the working LSPs that they protect are physically (i.e., link, node, SRLG, etc.) disjoint. This mechanism is referred to as shared mesh restoration and is described in [RFC4426]. Shared-mesh restoration can be seen as a particular case of pre-planned LSP rerouting (see Section 8) that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. Here also, the recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, thus an explicit signaling action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This requires restoration signaling along the protecting LSP.
To make bandwidth pre-reserved for a protecting (but not activated) LSP, available for extra-traffic this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means
To make bandwidth pre-reserved for a protecting (but not activated) LSP, available for extra-traffic this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means
Lang, et al. Standards Track [Page 20] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 20] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP) and the Holding Priority field to at least X+1. Also, if the resources pre- reserved for the protecting LSP are used by lower priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10). Further, if the recovery resources are shared between multiple protecting LSPs, the corresponding working LSPs head-end nodes must be informed that they are no longer protected when the protecting LSP is activated to recover the normal traffic for the working LSP under failure.
numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP) and the Holding Priority field to at least X+1. Also, if the resources pre- reserved for the protecting LSP are used by lower priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10). Further, if the recovery resources are shared between multiple protecting LSPs, the corresponding working LSPs head-end nodes must be informed that they are no longer protected when the protecting LSP is activated to recover the normal traffic for the working LSP under failure.
Consider the following topology:
Consider the following topology:
A---B---C---D
\ /
E---F---G
/ \
H---I---J---K
A---B---C---D \ / E---F---G / \ H---I---J---K
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they must have the same Tunnel Endpoint Address (as part of their SESSION object). However, these addresses are not the same in this example. Resource sharing along E, F, and G can only be achieved if the nodes E, F, and G recognize that the LSP Protection Type of the secondary LSP is set to "Rerouting without Extra-Traffic" (see PROTECTION object, Section 14) and acts accordingly. In this case, the protecting LSPs are not merged (which is useful since the paths diverge at G), but the resources along E, F, G can be shared.
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they must have the same Tunnel Endpoint Address (as part of their SESSION object). However, these addresses are not the same in this example. Resource sharing along E, F, and G can only be achieved if the nodes E, F, and G recognize that the LSP Protection Type of the secondary LSP is set to "Rerouting without Extra-Traffic" (see PROTECTION object, Section 14) and acts accordingly. In this case, the protecting LSPs are not merged (which is useful since the paths diverge at G), but the resources along E, F, G can be shared.
When a failure is detected on one of the working LSPs (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP (see Section 8). At this point, it is important that a failure on the other LSP (say, at J) does not cause the other ingress (H) to send the data down the protecting LSP since the resources are already in use. This can be achieved by node E using the following procedure. When the capacity is first reserved for the protecting LSP, E should verify that the LSPs being protected ([A,B,C,D] and [H,I,J,K], respectively) do not
When a failure is detected on one of the working LSPs (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP (see Section 8). At this point, it is important that a failure on the other LSP (say, at J) does not cause the other ingress (H) to send the data down the protecting LSP since the resources are already in use. This can be achieved by node E using the following procedure. When the capacity is first reserved for the protecting LSP, E should verify that the LSPs being protected ([A,B,C,D] and [H,I,J,K], respectively) do not
Lang, et al. Standards Track [Page 21] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 21] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
share any common resources. Then, when a failure occurs (say, at B) and the protecting LSP [A,E,F,G,D] is activated, E should notify H that the resources for the protecting LSP [H,E,F,G,K] are no longer available.
share any common resources. Then, when a failure occurs (say, at B) and the protecting LSP [A,E,F,G,D] is activated, E should notify H that the resources for the protecting LSP [H,E,F,G,K] are no longer available.
The following subsections detail how shared mesh restoration can be implemented in an interoperable fashion using GMPLS RSVP-TE extensions (see [RFC3473]). This includes:
The following subsections detail how shared mesh restoration can be implemented in an interoperable fashion using GMPLS RSVP-TE extensions (see [RFC3473]). This includes:
(1) the ability to identify a "secondary protecting LSP" (hereby
called the "secondary LSP") used to recover another primary
working LSP (hereby called the "protected LSP")
(2) the ability to associate the secondary LSP with the protected
LSP
(3) the capability to include information about the resources used
by the protected LSP while instantiating the secondary LSP.
(4) the capability to instantiate during the provisioning phase
several secondary LSPs in an efficient manner.
(5) the capability to activate a secondary LSP after failure
occurrence.
(1) the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP") (2) the ability to associate the secondary LSP with the protected LSP (3) the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP. (4) the capability to instantiate during the provisioning phase several secondary LSPs in an efficient manner. (5) the capability to activate a secondary LSP after failure occurrence.
In the following subsections, these features are described in detail.
In the following subsections, these features are described in detail.
9.1. Identifiers
9.1. Identifiers
To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra- traffic.
To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra- traffic.
A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "Rerouting without Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "Rerouting without Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
9.2. Signaling Primary LSPs
9.2. Signaling Primary LSPs
The new PROTECTION object is included in the Path message during signaling of the primary working LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
The new PROTECTION object is included in the Path message during signaling of the primary working LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.
Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.
Lang, et al. Standards Track [Page 22] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 22] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
9.3. Signaling Secondary LSPs
9.3. Signaling Secondary LSPs
The new PROTECTION object is included in the Path message during signaling of the secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
The new PROTECTION object is included in the Path message during signaling of the secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see Section 15) that further allows for recovery resource sharing at each intermediate node along the secondary path.
Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see Section 15) that further allows for recovery resource sharing at each intermediate node along the secondary path.
With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).
With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).
From [RFC3945], the secondary LSP is set up with resource pre- reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that, during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).
From [RFC3945], the secondary LSP is set up with resource pre- reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that, during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).
10. LSP Preemption
10. LSP Preemption
When protecting resources are only pre-reserved for the secondary LSPs, they MAY be used to set up lower-priority LSPs. In this case, these resources MUST be preempted when the protecting LSP is activated. An additional condition raises from misconnection avoidance between the secondary protecting LSP being activated and the low-priority LSP(s) being preempted. Procedure to be applied when the secondary protecting LSP (i.e., the preempting LSP) Path message reaches a node using the resources for lower-priority LSP(s) (i.e., preempted LSP(s)) is as follows:
When protecting resources are only pre-reserved for the secondary LSPs, they MAY be used to set up lower-priority LSPs. In this case, these resources MUST be preempted when the protecting LSP is activated. An additional condition raises from misconnection avoidance between the secondary protecting LSP being activated and the low-priority LSP(s) being preempted. Procedure to be applied when the secondary protecting LSP (i.e., the preempting LSP) Path message reaches a node using the resources for lower-priority LSP(s) (i.e., preempted LSP(s)) is as follows:
Lang, et al. Standards Track [Page 23] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 23] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
1. De-allocate resources to be used by the preempting LSP and release
the cross-connection. Note that if the preempting LSP is
bidirectional, these resources may come from one or two lower-
priority LSPs, and if from two LSPs, they may be uni- or bi-
directional. The preempting node SHOULD NOT send the Path message
before the de-allocation of resources has completed since this may
lead to the downstream path becoming misconnected if the
downstream node is able to reassign the resources more quickly.
1. De-allocate resources to be used by the preempting LSP and release the cross-connection. Note that if the preempting LSP is bidirectional, these resources may come from one or two lower- priority LSPs, and if from two LSPs, they may be uni- or bi- directional. The preempting node SHOULD NOT send the Path message before the de-allocation of resources has completed since this may lead to the downstream path becoming misconnected if the downstream node is able to reassign the resources more quickly.
2. Send PathTear and PathErr messages with the new error code/sub-
code "Policy Control failure/Hard preempted" and the
Path_State_Removed flag set for the preempted LSP(s).
2. Send PathTear and PathErr messages with the new error code/sub- code "Policy Control failure/Hard preempted" and the Path_State_Removed flag set for the preempted LSP(s).
3. Reserve the preempted resources for the protecting LSP. The
preempting node MUST NOT cross-connect the upstream resources of a
bidirectional preempting LSP.
3. Reserve the preempted resources for the protecting LSP. The preempting node MUST NOT cross-connect the upstream resources of a bidirectional preempting LSP.
4. Send the Path message.
4. Send the Path message.
5. Upon reception of a trigger Resv message from the downstream node,
cross-connect the downstream path resources, and if the preempting
LSP is bidirectional, perform cross-connection for the upstream
path resources.
5. Upon reception of a trigger Resv message from the downstream node, cross-connect the downstream path resources, and if the preempting LSP is bidirectional, perform cross-connection for the upstream path resources.
Note that step 1 may cause alarms to be raised for the preempted LSP. If alarm suppression is desired, the preempting node MAY insert the following steps before step 1.
Note that step 1 may cause alarms to be raised for the preempted LSP. If alarm suppression is desired, the preempting node MAY insert the following steps before step 1.
1a. Before de-allocating resources, send a Resv message, including an
ADMIN_STATUS object, to disable alarms for the preempted LSP.
1b. Receive a Path message indicating that alarms are disabled.
1a. Before de-allocating resources, send a Resv message, including an ADMIN_STATUS object, to disable alarms for the preempted LSP. 1b. Receive a Path message indicating that alarms are disabled.
At the downstream node (with respect to the preempting LSP), the processing is RECOMMENDED to be as follows:
At the downstream node (with respect to the preempting LSP), the processing is RECOMMENDED to be as follows:
1. Receive PathTear (and/or PathErr) message for the preempted
LSP(s).
1. Receive PathTear (and/or PathErr) message for the preempted LSP(s).
2a. Release the resources associated with the LSP on the interface to
the preempting LSP, remove any cross-connection, and release all
other resources associated with the preempted LSP.
2b. Forward the PathTear (and/or PathErr) message per [RFC3473].
2a. Release the resources associated with the LSP on the interface to the preempting LSP, remove any cross-connection, and release all other resources associated with the preempted LSP. 2b. Forward the PathTear (and/or PathErr) message per [RFC3473].
3. Receive the Path message for the preempting LSP and process as
normal, forwarding it to the downstream node.
3. Receive the Path message for the preempting LSP and process as normal, forwarding it to the downstream node.
4. Receive the Resv message for the preempting LSP and process as
normal, forwarding it to the upstream node.
4. Receive the Resv message for the preempting LSP and process as normal, forwarding it to the upstream node.
Lang, et al. Standards Track [Page 24] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 24] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
11. (Full) LSP Rerouting
11. (Full) LSP Rerouting
LSP rerouting, on the other hand, switches normal traffic to an alternate LSP that is fully established only after failure occurrence. The new (alternate) route is selected at the LSP head- end and may reuse intermediate nodes included in the original route; it may also include additional intermediate nodes. For strict-hop routing, TE requirements can be directly applied to the route computation, and the failed node or link can be avoided. However, if the failure occurred within a loose-routed hop, the head-end node may not have enough information to reroute the LSP around the failure. Crankback signaling (see [CRANK]) and route exclusion techniques (see [RFC4874]) MAY be used in this case.
LSP rerouting, on the other hand, switches normal traffic to an alternate LSP that is fully established only after failure occurrence. The new (alternate) route is selected at the LSP head- end and may reuse intermediate nodes included in the original route; it may also include additional intermediate nodes. For strict-hop routing, TE requirements can be directly applied to the route computation, and the failed node or link can be avoided. However, if the failure occurred within a loose-routed hop, the head-end node may not have enough information to reroute the LSP around the failure. Crankback signaling (see [CRANK]) and route exclusion techniques (see [RFC4874]) MAY be used in this case.
The alternate route MAY be either computed on demand (that is, when the failure occurs; this is referred to as full LSP rerouting) or pre-computed and stored for use when the failure is reported. The latter offers faster restoration time. There is, however, a risk that the alternate route will become out of date through other changes in the network; this can be mitigated to some extent by periodic recalculation of idle alternate routes.
The alternate route MAY be either computed on demand (that is, when the failure occurs; this is referred to as full LSP rerouting) or pre-computed and stored for use when the failure is reported. The latter offers faster restoration time. There is, however, a risk that the alternate route will become out of date through other changes in the network; this can be mitigated to some extent by periodic recalculation of idle alternate routes.
(Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code "Notify Error/LSP Locally Failed" for this LSP. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up before the old LSP is torn down. This is done by using the mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit (SE) reservation style (see [RFC3209]). Both the new and old LSPs can share resources at common nodes.
(Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code "Notify Error/LSP Locally Failed" for this LSP. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up before the old LSP is torn down. This is done by using the mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit (SE) reservation style (see [RFC3209]). Both the new and old LSPs can share resources at common nodes.
Note that the make-before-break mechanism is not used to avoid disruption to the normal traffic flow (the latter has already been broken by the failure that is being repaired). However, it is valuable to retain the resources allocated on the original LSP that will be reused by the new alternate LSP.
Note that the make-before-break mechanism is not used to avoid disruption to the normal traffic flow (the latter has already been broken by the failure that is being repaired). However, it is valuable to retain the resources allocated on the original LSP that will be reused by the new alternate LSP.
11.1. Identifiers
11.1. Identifiers
The Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address uniquely identify both the old and new LSPs. Only the LSP_ID value differentiates the old from the new alternate LSP. The new alternate LSP is set up before the old LSP is torn down using Shared-Explicit (SE) reservation style. This ensures that the new (alternate) LSP is established without double-counting resource requirements along common segments.
The Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address uniquely identify both the old and new LSPs. Only the LSP_ID value differentiates the old from the new alternate LSP. The new alternate LSP is set up before the old LSP is torn down using Shared-Explicit (SE) reservation style. This ensures that the new (alternate) LSP is established without double-counting resource requirements along common segments.
Lang, et al. Standards Track [Page 25] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 25] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
The alternate LSP MAY be set up before any failure occurrence with SE-style resource reservation, the latter shares the same Tunnel End Point Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address with the original LSP (i.e., only the LSP ID value MUST be different).
The alternate LSP MAY be set up before any failure occurrence with SE-style resource reservation, the latter shares the same Tunnel End Point Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address with the original LSP (i.e., only the LSP ID value MUST be different).
In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP.
In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP.
11.2. Signaling Reroutable LSPs
11.2. Signaling Reroutable LSPs
A new PROTECTION object is included in the Path message during signaling of dynamically reroutable LSPs, with the end-to-end LSP Protection Type value set to "Full Rerouting". These LSPs that can be either uni- or bidirectional are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and the Association ID value to the LSP_ID value of the signaled LSP. Any specific action to be taken during the provisioning phase is up to the end- node local policy.
A new PROTECTION object is included in the Path message during signaling of dynamically reroutable LSPs, with the end-to-end LSP Protection Type value set to "Full Rerouting". These LSPs that can be either uni- or bidirectional are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and the Association ID value to the LSP_ID value of the signaled LSP. Any specific action to be taken during the provisioning phase is up to the end- node local policy.
Note: when the end-to-end LSP Protection Type is set to "Unprotected", both S and P bit MUST be set to 0, and the LSP SHOULD NOT be rerouted at the head-end node after failure occurrence. The Association_ID value MUST be set to the LSP_ID value of the signaled LSP. This does not mean that the Unprotected LSP cannot be re- established for other reasons such as path re-optimization and bandwidth adjustment driven by policy conditions.
Note: when the end-to-end LSP Protection Type is set to "Unprotected", both S and P bit MUST be set to 0, and the LSP SHOULD NOT be rerouted at the head-end node after failure occurrence. The Association_ID value MUST be set to the LSP_ID value of the signaled LSP. This does not mean that the Unprotected LSP cannot be re- established for other reasons such as path re-optimization and bandwidth adjustment driven by policy conditions.
12. Reversion
12. Reversion
Reversion refers to a recovery switching operation, where the normal traffic returns to (or remains on) the working LSP when it has recovered from the failure. Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption and reconfiguration.
Reversion refers to a recovery switching operation, where the normal traffic returns to (or remains on) the working LSP when it has recovered from the failure. Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption and reconfiguration.
For "1+1 bidirectional Protection", reversion to the recovered LSP occurs by using the following sequence:
For "1+1 bidirectional Protection", reversion to the recovered LSP occurs by using the following sequence:
1. Clear the A bit of the ADMIN_STATUS object if set for the
recovered LSP.
1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
2. Then, apply the method described below to switch normal traffic
back from the protecting to the recovered LSP. This is performed
by using the new error code/sub-code "Notify Error/LSP Recovered"
(Switchback Request).
2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).
Lang, et al. Standards Track [Page 26] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 26] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
The procedure is as follows:
The procedure is as follows:
1) The initiating (source) node sends the normal traffic onto both
the working and the protecting LSPs. Once completed, the
source node sends reliably a Notify message to the destination
with the new error code/sub-code "Notify Error/LSP Recovered"
(Switchback Request). This Notify message includes the
MESSAGE_ID object. The ACK_Desired flag MUST be set in this
object to request the receiver to send an acknowledgment for
the message (see [RFC2961]).
1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
2) Upon receipt of this message, the destination selects the
traffic from the working LSP. At the same time, it transmits
the traffic onto both the working and protecting LSP.
2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.
The destination then sends reliably a Notify message to the
source confirming the completion of the operation. This
message includes the MESSAGE_ID_ACK object to acknowledge
reception of the received Notify message. This Notify message
also includes the MESSAGE_ID object. The ACK_Desired flag MUST
be set in this object to request the receiver to send an
acknowledgment for the message (see [RFC2961]).
The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
3) When the source node receives this Notify message, it switches
to receive traffic from the working LSP.
3) When the source node receives this Notify message, it switches to receive traffic from the working LSP.
The source node then sends an Ack message to the destination
node confirming that the LSP has been reverted.
The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.
3. Finally, clear the O bit of the PROTECTION object sent over the
protecting LSP.
3. Finally, clear the O bit of the PROTECTION object sent over the protecting LSP.
For "1:N Protection with Extra-traffic", reversion to the recovered LSP occurs by using the following sequence:
For "1:N Protection with Extra-traffic", reversion to the recovered LSP occurs by using the following sequence:
1. Clear the A bit of the ADMIN_STATUS object if set for the
recovered LSP.
1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
2. Then, apply the method described below to switch normal traffic
back from the protecting to the recovered LSP. This is performed
by using the new error code/sub-code "Notify Error/LSP Recovered"
(Switchback Request).
2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).
The procedure is as follows:
The procedure is as follows:
1) The initiating (source) node sends the normal traffic onto both
the working and the protecting LSPs. Once completed, the
source node sends reliably a Notify message to the destination
1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination
Lang, et al. Standards Track [Page 27] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 27] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
with the new error code/sub-code "Notify Error/LSP Recovered"
(Switchback Request). This Notify message includes the
MESSAGE_ID object. The ACK_Desired flag MUST be set in this
object to request the receiver to send an acknowledgment for
the message (see [RFC2961]).
with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
2) Upon receipt of this message, the destination selects the
traffic from the working LSP. At the same time, it transmits
the traffic onto both the working and protecting LSP.
2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.
The destination then sends reliably a Notify message to the
source confirming the completion of the operation. This
message includes the MESSAGE_ID_ACK object to acknowledge
reception of the received Notify message. This Notify message
also includes the MESSAGE_ID object. The ACK_Desired flag MUST
be set in this object to request the receiver to send an
acknowledgment for the message (see [RFC2961]).
The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
3) When the source node receives this Notify message, it switches
to receive traffic from the working LSP, and stops transmitting
traffic on the protecting LSP.
3) When the source node receives this Notify message, it switches to receive traffic from the working LSP, and stops transmitting traffic on the protecting LSP.
The source node then sends an Ack message to the destination
node confirming that the LSP has been reverted.
The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.
4) Upon receipt of this message, the destination node stops
transmitting traffic along the protecting LSP.
4) Upon receipt of this message, the destination node stops transmitting traffic along the protecting LSP.
3. Finally, clear the O bit of the PROTECTION object sent over the
protecting LSP.
3. Finally, clear the O bit of the PROTECTION object sent over the protecting LSP.
For "Rerouting without Extra-traffic" (including the shared recovery case), reversion implies that the formerly working LSP has not been torn down by the head-end node upon PathErr message reception, i.e., the head-end node kept refreshing the working LSP under failure condition. This ensures that the exact same resources are retrieved after reversion switching (except if the working LSP required re- signaling). Re-activation is performed using the following sequence:
For "Rerouting without Extra-traffic" (including the shared recovery case), reversion implies that the formerly working LSP has not been torn down by the head-end node upon PathErr message reception, i.e., the head-end node kept refreshing the working LSP under failure condition. This ensures that the exact same resources are retrieved after reversion switching (except if the working LSP required re- signaling). Re-activation is performed using the following sequence:
1. Clear the A bit of the ADMIN_STATUS object if set for the
recovered LSP.
1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
2. Then, apply the method described below to switch normal traffic
back from the protecting to the recovered LSP. This is performed
by using the new error code/sub-code "Notify Error/LSP Recovered"
(Switchback Request).
2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).
Lang, et al. Standards Track [Page 28] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
Lang, et al. Standards Track [Page 28] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
The procedure is as follows:
The procedure is as follows:
1) The initiating (source) node sends the normal traffic onto both
the working and the protecting LSPs. Once completed, the
source node sends reliably a Notify message to the destination
with the new error code/sub-code "Notify Error/LSP Recovered"
(Switchback Request). This Notify message includes the
MESSAGE_ID object. The ACK_Desired flag MUST be set in this
object to request the receiver to send an acknowledgment for
the message (see [RFC2961]).
1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
2) Upon receipt of this message, the destination selects the
traffic from the working LSP. At the same time, it transmits
the traffic onto both the working and protecting LSP.
2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.
The destination then sends reliably a Notify message to the
source confirming the completion of the operation. This
message includes the MESSAGE_ID_ACK object to acknowledge
reception of the received Notify message. This Notify message
also includes the MESSAGE_ID object. The ACK_Desired flag MUST
be set in this object to request the receiver to send an
acknowledgment for the message (see [RFC2961]).
The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
3) When the source node receives this Notify message, it switches
to receive traffic from the working LSP, and stops transmitting
traffic on the protecting LSP.
3) When the source node receives this Notify message, it switches to receive traffic from the working LSP, and stops transmitting traffic on the protecting LSP.
The source node then sends an Ack message to the destination
node confirming that the LSP has been reverted.
The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.
4) Upon receipt of this message, the destination node stops
transmitting traffic along the protecting LSP.
4) このメッセージを受け取り次第、目的地ノードは、保護しているLSPに沿ってトラフィックを伝えるのを止めます。
3. Finally, de-activate the protecting LSP by setting the S bit to 1
in the PROTECTION object sent over the protecting LSP.
3. 最終的に、反-保護しているLSPの上に送られたPROTECTIONオブジェクトに1へのSビットをはめ込むことによって、保護しているLSPを動かしてください。
13. Recovery Commands
13. 回復コマンド
This section specifies the control plane behavior when using several commands (see [RFC4427]) that can be used to influence the recovery operations.
回復動作に影響を及ぼすのに使用できるいくつかのコマンド([RFC4427]を見る)を使用するとき、このセクションはコントロール飛行機の振舞いを指定します。
A. Lockout of recovery LSP:
回復LSPのA.ロックアウト:
The Lockout (L) bit of the ADMIN_STATUS object is used following the rules defined in Section 8 of [RFC3471] and Section 7 of [RFC3473]. The L bit must be set together with the Reflect (R) bit in the ADMIN_STATUS object sent in the Path message. Upon reception of the
[RFC3471]のセクション8と[RFC3473]のセクション7で定義された規則に従って、ADMIN_STATUSオブジェクトのLockout(L)ビットは使用されています。 LビットはPathメッセージで送られたADMIN_STATUSオブジェクトのReflect(R)ビットと共にセットであるに違いありません。 レセプション
Lang, et al. Standards Track [Page 29] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[29ページ]RFC RSVP-Te拡張子
Resv message with the L bit set, this forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra-traffic). Unlock is performed by clearing the L bit, following the rules defined in Section 7 of [RFC3473]. This procedure is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection).
LビットがセットしたことでのResvメッセージ、これは回復LSPがトラフィックを輸送するのにおいて一時入手できないのを(正常であるか付加的なトラフィックの)強制します。 アンロックは、[RFC3473]のセクション7で定義された規則に従って、Lビットをきれいにすることによって、実行されます。 この手順は、適切なだけのLSP Protection Type Flagが0×04に用意ができていると(Extra-トラフィックがある1:N Protection)0×08(1+1Unidirectional Protection)、または0×10(1+1Bidirectional Protection)です。
The updated format of the ADMIN_STATUS object to include the L bit is as follows:
Lビットを含むADMIN_STATUSオブジェクトのアップデートされた形式は以下の通りです:
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(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(196)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|L|I|C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lockout (L): 1 bit
ロックアウト(L): 1ビット
When set, forces the recovery LSP to be temporarily unavailable
to transport traffic (either normal or extra traffic).
いつが、セットして、回復LSPがトラフィック(正常であるか付加的なトラフィック)を輸送するのにおいて一時入手できないのを強制しますか?
The R (Reflect), T (Testing), A (Administratively down), and D (Deletion in progress) bits are defined in [RFC3471]. The C (Call control) bit is defined in [GMPLS-CALL], and the I (Inhibit alarm communication) bit in [RFC4783].
R(反射する)、T(テスト)、A(行政上下がっている)、およびD(進行中の削除)ビットは[RFC3471]で定義されます。 C(コントロールと呼ぶ)ビットは[RFC4783]で[GMPLS-CALL]、およびI(アラームコミュニケーションを禁止する)ビットで定義されます。
B. Lockout of normal traffic:
正常なトラフィックのB.ロックアウト:
The O bit of the PROTECTION object is set to 1 to force the recovery LSP to be temporarily unavailable to transport normal traffic. This operation MUST NOT occur unless the working LSP is carrying the normal traffic. Unlock is performed by clearing the O bit over the protecting LSP. This procedure is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection).
1にPROTECTIONオブジェクトのOビットが、回復LSPが正常なトラフィックを輸送するのにおいて一時入手できないのを強制するように設定されます。 働くLSPが正常なトラフィックを運ばない場合、この操作は起こってはいけません。 アンロックは、保護しているLSPの上でOビットをきれいにすることによって、実行されます。 この手順は、適切なだけのLSP Protection Type Flagが0×04に用意ができていると(Extra-トラフィックがある1:N Protection)0×08(1+1Unidirectional Protection)、または0×10(1+1Bidirectional Protection)です。
C. Forced switch for normal traffic:
正常なトラフィックのためのC.の無理矢理のスイッチ:
Recovery signaling is initiated that switches normal traffic to the recovery LSP following the procedures defined in Section 6, 7, 8, and 9.
手順に従うのがセクション6、7、8、および9で定義した回復LSPに正常なトラフィックを切り換える回復シグナリングが開始されます。
Lang, et al. Standards Track [Page 30] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[30ページ]RFC RSVP-Te拡張子
D. Requested switch for normal traffic:
正常なトラフィックのためのD.の要求されたスイッチ:
Recovery signaling is initiated that switches normal traffic to the recovery LSP following the procedures defined in Section 6, 7, 8, and 9. This happens unless a fault condition exists on other LSPs or spans (including the recovery LSP), or a switch command of equal or higher priority is in effect.
手順に従うのがセクション6、7、8、および9で定義した回復LSPに正常なトラフィックを切り換える回復シグナリングが開始されます。 欠点状態が他のLSPsに存在しているか、またはわたらない場合(回復LSPを含んでいて)、これが起こるか、または等しいか、より高い優先度のスイッチコマンドは有効です。
E. Requested switch for recovery LSP:
回復LSPのためのE.の要求されたスイッチ:
Recovery signaling is initiated that switches normal traffic to the working LSP following the procedure defined in Section 12. This request is executed except if a fault condition exists on the working LSP or an equal or higher priority switch command is in effect.
手順に従うのがセクション12で定義した働くLSPに正常なトラフィックを切り換える回復シグナリングが開始されます。 欠点状態が働くLSPに存在しているか、そして、同輩を除いて、この要求が実行されるか、または、より高い優先権スイッチコマンドは有効です。
14. PROTECTION Object
14. 保護オブジェクト
This section describes the extensions to the PROTECTION object to broaden its applicability to end-to-end LSP recovery.
このセクションは、終わりから終わりへのLSP回復への適用性を広くするためにPROTECTIONオブジェクトに拡大を説明します。
14.1. Format
14.1. 形式
The format of the PROTECTION Object (Class-Num = 37, C-Type = 2) is as follows:
PROTECTION Object(クラスヌムは37、C-タイプ=2と等しい)の形式は以下の通りです:
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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旗| 予約されます。| リンク旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S): 1 bit
セカンダリ(S): 1ビット
When set to 1, this bit indicates that the requested LSP is a
secondary LSP. When set to 0 (default), it indicates that the
requested LSP is a primary LSP.
1に設定されると、このビットは、要求されたLSPがセカンダリLSPであることを示します。 0(デフォルト)に設定されると、それは、要求されたLSPがプライマリLSPであることを示します。
Protecting (P): 1 bit
(p)を保護します: 1ビット
When set to 1, this bit indicates that the requested LSP is a
protecting LSP. When set to 0 (default), it indicates that the
requested LSP is a working LSP. The combination, S set to 1
with P set to 0 is not valid.
1に設定されると、このビットは、要求されたLSPが保護LSPであることを示します。 0(デフォルト)に設定されると、それは、要求されたLSPが働くLSPであることを示します。 組み合わせ、0に設定されたPと共に1に設定されたSは有効ではありません。
Lang, et al. Standards Track [Page 31] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[31ページ]RFC RSVP-Te拡張子
Notification (N): 1 bit
通知(N): 1ビット
When set to 1, this bit indicates that the control plane
message exchange is only used for notification during
protection switching. When set to 0 (default), it indicates
that the control plane message exchanges are used for
protection-switching purposes. The N bit is only applicable
when the LSP Protection Type Flag is set to either 0x04 (1:N
Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional
Protection), or 0x10 (1+1 Bidirectional Protection). The N bit
MUST be set to 0 in any other case.
1に設定されると、このビットは、コントロール飛行機交換処理が通知に保護の切り換えの間使用されるだけであるのを示します。 0(デフォルト)に設定されると、それは、コントロール飛行機交換処理が保護を切り換える目的に使用されるのを示します。 Nビットは、適切なだけのLSP Protection Type Flagが0×04に用意ができていると(Extra-トラフィックがある1:N Protection)0×08(1+1Unidirectional Protection)、または0×10(1+1Bidirectional Protection)です。 いかなる他の場合でもNビットを0に設定しなければなりません。
Operational (O): 1 bit
操作上の(o): 1ビット
When set to 1, this bit indicates that the protecting LSP is
carrying the normal traffic after protection switching. The O
bit is only applicable when the P bit is set to 1, and the LSP
Protection Type Flag is set to either 0x04 (1:N Protection with
Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10
(1+1 Bidirectional Protection). The O bit MUST be set to 0 in
any other case.
1に設定されると、このビットは、保護しているLSPが保護の切り換えの後に正常なトラフィックを運ぶのを示します。 Oビットは、適切なだけのPビットが1に設定されて、LSP Protection Type Flagが0×04に用意ができていると(Extra-トラフィックがある1:N Protection)0×08(1+1Unidirectional Protection)か0×10(1+1Bidirectional Protection)です。 いかなる他の場合でもOビットを0に設定しなければなりません。
Reserved: 5 bits
予約される: 5ビット
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. These bits SHOULD be passed
through unmodified by transit nodes.
この分野は予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。 これらのビットSHOULD、変更されていなく、トランジットノードで通り抜けてください。
LSP (Protection Type) Flags: 6 bits
LSP(保護タイプ)は弛みます: 6ビット
Indicates the desired end-to-end LSP recovery type. A value of
0 implies that the LSP is "Unprotected". Only one value SHOULD
be set at a time. The following values are defined. All other
values are reserved.
終わりから終わりへのLSP回復必要なタイプを示します。 0の値は、LSPが「保護がありません」を含意します。 人はaにおけるセットが時間であった場合にだけSHOULDを評価します。 以下の値は定義されます。 他のすべての値が予約されています。
0x00 Unprotected
0x01 (Full) Rerouting
0x02 Rerouting without Extra-Traffic
0x04 1:N Protection with Extra-Traffic
0x08 1+1 Unidirectional Protection
0x10 1+1 Bidirectional Protection
付加的なトラフィックのない0×00保護のない0×01(完全)コースを変更する0×02のコースを変更する、0×04、1:N、保護、付加的なトラフィック0×08 1+1単方向の保護0x10 1の+1双方向の保護
Reserved: 10 bits
予約される: 10ビット
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. These bits SHOULD be passed
through unmodified by transit nodes.
この分野は予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。 これらのビットSHOULD、変更されていなく、トランジットノードで通り抜けてください。
Lang, et al. Standards Track [Page 32] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[32ページ]RFC RSVP-Te拡張子
Link Flags: 6 bits
旗をリンクしてください: 6ビット
Indicates the desired link protection type (see [RFC3471]).
必要なリンク保護タイプ([RFC3471]を見る)を示します。
Reserved field: 32 bits
予約された分野: 32ビット
Encoding of this field is detailed in [RFC4873].
この分野のコード化は[RFC4873]で詳細です。
14.2. Processing
14.2. 処理
Intermediate and egress nodes processing a Path message containing a PROTECTION object MUST verify that the requested LSP Protection Type can be satisfied by the incoming interface. If it cannot, the node MUST generate a PathErr message, with the new error code/sub-code "Routing problem/Unsupported LSP Protection".
PROTECTIONオブジェクトを含むPathメッセージを処理する中間介在物と出口ノードは、要求されたLSP Protection Typeが入って来るインタフェースで満足することができることを確かめなければなりません。 そうすることができないなら、ノードは新しいサブエラーコード/コード「ルート設定の問題/サポートされないLSP保護」でPathErrメッセージを生成しなければなりません。
Intermediate nodes processing a Path message containing a PROTECTION object with the LSP Protection Type 0x02 (Rerouting without Extra- Traffic) value set and a PRIMARY_PATH_ROUTE object (see Section 15) MUST verify that the requested LSP Protection Type can be supported by the outgoing interface. If it cannot, the node MUST generate a PathErr message with the new error code/sub-code "Routing problem/Unsupported LSP Protection".
LSP Protection Type0x02(Extraトラフィックなしでコースを変更します)選択値群とPRIMARY_PATH_ROUTEオブジェクト(セクション15を見る)でPROTECTIONオブジェクトを含むPathメッセージを処理する中間的ノードは、外向的なインタフェースで要求されたLSP Protection Typeをサポートすることができることを確かめなければなりません。 そうすることができないなら、ノードは新しいサブエラーコード/コード「ルート設定の問題/サポートされないLSP保護」でPathErrメッセージを生成しなければなりません。
15. PRIMARY_PATH_ROUTE Object
15. プライマリ_経路_ルートオブジェクト
The PRIMARY_PATH_ROUTE object (PPRO) is defined to inform nodes along the path of a secondary protecting LSP about which resources (link/nodes) are being used by the associated primary protected LSP (as specified by the Association ID field). If the LSP Protection Type value is set to 0x02 (Rerouting without Extra-Traffic), this object SHOULD be present in the Path message for the pre-provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 9). This document does not assume or preclude any other usage for this object.
PRIMARY_PATH_ROUTEオブジェクト(PPRO)は、関連予備選挙で使用されるのがリソース(リンク/ノード)がどれであるかに関してLSPを保護したかを(Association ID分野によって指定されるように)セカンダリ保護LSPの経路に沿ったノードに知らせるために定義されます。 セカンダリ保護のプレの食糧を供給するLSPが回復を可能にするPathメッセージでのプレゼントが1つを平等に割り当てるリソースであったなら、LSP Protection Type値は0×02(Extra-トラフィックなしでコースを変更する)、このオブジェクトSHOULDへのセットであるか、そして、よりセカンダリの保護LSPs(セクション9を見ます)。 このドキュメントは、このオブジェクトのためにいかなる他の用法も仮定もしませんし、排除もしません。
PRIMARY_PATH_ROUTE objects carry information extracted from the EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary working LSPs they protect. Selection of the PPRO content is up to local policy of the head-end node that initiates the request. Therefore, the information included in these objects can be used as policy-based admission control to ensure that recovery resources are only shared between secondary protecting LSPs whose associated primary LSPs have link/node/SRLG disjoint paths.
PRIMARY_PATH_ROUTEオブジェクトは彼らが保護するプライマリ働くLSPsのEXPLICIT ROUTEオブジェクト、そして/または、RECORD ROUTEオブジェクトから抜粋された情報を運びます。 PPRO内容の選択は要求を開始するギヤエンドのノードのローカルの方針に上がっています。 したがって、回復リソースが関連プライマリLSPsがリンク/ノード/SRLGに経路をばらばらにならせるセカンダリ保護LSPsの間で共有されるだけであるのを保証するのに方針ベースの入場コントロールとしてこれらのオブジェクトに情報を含んでいるのを使用できます。
Lang, et al. Standards Track [Page 33] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[33ページ]RFC RSVP-Te拡張子
15.1. Format
15.1. 形式
The primary path route is specified via the PRIMARY_PATH_ROUTE object (PPRO). The Primary Path Route Class Number (Class-Num) of form 0bbbbbbb 38.
プライマリ経路ルートはPRIMARY_PATH_ROUTEオブジェクト(PPRO)を通して指定されます。 フォーム0bbbbbbb38のPrimary Path Route Class Number(クラスヌム)。
Currently one C-Type (Class-Type) is defined, Type 1, Primary Path Route. The PRIMARY_PATH_ROUTE object has the following format:
現在、1つのC-タイプ(クラスタイプ)が定義されたType1、Primary Path Routeです。 PRIMARY_PATH_ROUTEオブジェクトには、以下の形式があります:
Class-Num = 38 (of the form 0bbbbbbb), C-Type = 1
クラスヌムは38(フォーム0bbbbbbbの)、C-タイプ=1と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //(Subobjects)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of a PRIMARY_PATH_ROUTE object are a series of variable-length data items called subobjects (see Section 15.3).
PRIMARY_PATH_ROUTEオブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長のデータ項目(セクション15.3を見る)です。
To signal a secondary protecting LSP, the Path message MAY include one or multiple PRIMARY_PATH_ROUTE objects, where each object is meaningful. The latter is useful when a given secondary protecting LSP must be link/node/SRLG disjoint from more than one primary LSP (i.e., is protecting more than one primary LSP).
セカンダリ保護LSPに合図するために、Pathメッセージは1か複数のPRIMARY_PATH_ROUTEオブジェクトを含むかもしれません。そこでは、それぞれのオブジェクトが重要です。 後者は与えられたセカンダリ保護LSPであるなら役に立つのが、リンク/ノード/SRLGが1プライマリLSP(すなわち、1プライマリLSPを保護している)からばらばらになるということであるに違いないということです。
15.2. Subobjects
15.2. Subobjects
The PRIMARY_PATH_ROUTE object is defined as a list of variable-length data items called subobjects. These subobjects are derived from the subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the primary working LSP(s).
PRIMARY_PATH_ROUTEオブジェクトは「副-オブジェクト」と呼ばれる可変長のデータ項目のリストと定義されます。 プライマリ働くLSP(s)のEXPLICIT ROUTE、そして/または、RECORD ROUTEオブジェクトの「副-オブジェクト」からこれらの「副-オブジェクト」を得ます。
Each subobject has its own length field. The length contains the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4.
各「副-オブジェクト」には、それ自身の長さの分野があります。 長さはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつも長さは4、および少なくとも4の倍数であるに違いありません。
The following subobjects are currently defined for the PRIMARY_PATH_ROUTE object:
以下の「副-オブジェクト」は現在、PRIMARY_PATH_ROUTEオブジェクトのために定義されます:
- Sub-Type 1: IPv4 Address (see [RFC3209]) - Sub-Type 2: IPv6 Address (see [RFC3209]) - Sub-Type 3: Label (see [RFC3473]) - Sub-Type 4: Unnumbered Interface (see [RFC3477])
- サブタイプ1: IPv4アドレス([RFC3209]を見る)--サブタイプ2: IPv6アドレス([RFC3209]を見る)--サブタイプ3: ラベル([RFC3473]を見る)--サブタイプ4: 無数のインタフェース([RFC3477]を見ます)
Lang, et al. Standards Track [Page 34] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[34ページ]RFC RSVP-Te拡張子
An empty PPRO with no subobjects is considered illegal. If there is no first subobject, the corresponding Path message is also in error, and the receiving node SHOULD return a PathErr message with the new error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".
「副-オブジェクト」のない空のPPROは不法であると考えられます。 「副-オブジェクト」、また、1番目が全くなければ、対応するPathメッセージも間違っています、そして、受信ノードSHOULDは新しいサブエラーコード/コード「ルート設定Problem/悪いPRIMARY_PATH_ROUTEオブジェクト」でPathErrメッセージを返します。
Note: an intermediate node processing a PPRO can derive SRLG identifiers from the local IGP-TE database using its Type 1, 2, or 4 subobject values as pointers to the corresponding TE Links (assuming each of them has an associated SRLG TE attribute).
以下に注意してください。 PPROを処理する中間的ノードが、SRLG識別子にローカルのIGP-TEデータベースに指針としてType1、2、または4「副-オブジェクト」値を対応するTEリンクスに使用することで由来できます(それぞれのそれらを仮定するのにおいて、関連SRLG TE属性があります)。
15.3. Applicability
15.3. 適用性
The PRIMARY_PATH_ROUTE object MAY only be used when all GMPLS nodes along the path support the PRIMARY_PATH_ROUTE object and a secondary protecting LSP is being requested. The PRIMARY_PATH_ROUTE object is assigned a class value of the form 0bbbbbbb. Receiving GMPLS nodes along the path that do not support this object MUST return a PathErr message with the "Unknown Object Class" error code (see [RFC2205]).
経路に沿ったすべてのGMPLSノードがPRIMARY_PATH_ROUTEオブジェクトを支えるときだけ、PRIMARY_PATH_ROUTEオブジェクトは使用されるかもしれません、そして、セカンダリ保護LSPは要求されています。 フォーム0bbbbbbbの階級値はPRIMARY_PATH_ROUTEオブジェクトに割り当てられます。 経路に沿ったこのオブジェクトを支えないGMPLSノードを受け取ると、「未知のオブジェクトのクラス」エラーコードがあるPathErrメッセージは返らなければなりません([RFC2205]を見てください)。
Also, the following restrictions MUST be applied with respect to the PPRO usage:
また、PPRO用法に関して以下の制限を適用しなければなりません:
- PPROs MAY only be included in Path messages when signaling
secondary protecting LSPs (S bit = 1 and P bit = 1) and when the
LSP Protection Type value is set to 0x02 (without Rerouting Extra-
Traffic) in the PROTECTION object (see Section 14).
- シグナリングのセカンダリ保護LSPs(Sは=1に噛み付きました、そして、Pは=1に噛み付いた)といつLSP Protection Type値がPROTECTIONの0×02(Rerouting Extraトラフィックのない)へのセットであるかが反対するときだけ(セクション14を見てください)、PPROsはPathメッセージに含まれるかもしれません。
- PRROs SHOULD be present in the Path message for the pre-
provisioning of the secondary protecting LSP to enable recovery
resource sharing between one or more secondary protecting LSPs (see
Section 15.4).
- PRROs SHOULD、セカンダリ保護のプレの食糧を供給するLSPが1セカンダリ保護LSPsの間の回復リソース・シェアリングを可能にするPathメッセージに存在してください(セクション15.4を見てください)。
- PPROs MUST NOT be used in any other conditions. In particular, if
a PPRO is received when the S bit is set to 0 in the PROTECTION
object, the receiving node MUST return a PathErr message with the
new error code/sub-code "Routing Problem/PRIMARY_PATH_ROUTE object
not applicable".
- いかなる他の状態でもPPROsを使用してはいけません。 SビットがPROTECTIONオブジェクトの0に設定されるとき、PPROが受け取られているなら、特に、受信ノードは「適切でなくProblem/PRIMARY_PATH_ROUTEオブジェクトを発送する」新しいサブエラーコード/コードでPathErrメッセージを返さなければなりません。
- Crossed exchanges of PPROs over primary LSPs are forbidden (i.e.,
their usage is restricted to a single set of protected LSPs).
- プライマリLSPsの上のPPROsの交差している交換は禁じられます(すなわち、彼らの用法は保護されたLSPsの1セットに制限されます)。
- The PPRO's content MUST NOT include subobjects coming from other
PPROs. In particular, received PPROs MUST NOT be reused to
establish other working or protecting LSPs.
- PPROの内容は他のPPROsから来る「副-オブジェクト」を含んではいけません。 特に、他の働くか保護しているLSPsを証明するために容認されたPPROsを再利用してはいけません。
Lang, et al. Standards Track [Page 35] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[35ページ]RFC RSVP-Te拡張子
15.4. Processing
15.4. 処理
The PPRO enables sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG) disjoint paths. Consider a node N through which n secondary protecting LSPs (say, P[1],...,P[n]) have already been established that protect n primary working LSPs (say, P'[1],...,P'[n]). Suppose also that these n secondary working LSPs share a given outgoing link resource (say r).
PPROが与えられたセカンダリ保護LSPと1の間で共有している回復リソースを可能にするか、または彼らの対応するプライマリ働くLSPsに(リンク/ノード/SRLG)が互いにあるなら、よりセカンダリの保護LSPsは経路をばらばらにならせます。 … たとえば、P[1]、nプライマリ働くLSPsを保護するP[n])が既に設立されました。どのnセカンダリ保護LSPsを通してノードがNであると考えてくださいか、((たとえば、P'[1]、…、P'[n])。 また、これらのnセカンダリ働くLSPsが与えられた送信するリンクリソースを共有すると仮定してください(rを言ってください)。
Now, suppose that node N receives a Path message for an additional secondary protecting LSP (say, Q, protecting Q'). The PPRO carried by this Path message is processed as follows:
'今度は、ノードNがLSP(たとえば、Q'を保護するQ)を保護する追加2番目のためにPathメッセージを受け取ると仮定してください。 このPathメッセージによって運ばれたPPROは以下の通り処理されます:
- N checks whether the primary working LSPs P'[1],...,P'[n]
associated with the LSPs P[1],...,P[n], respectively, have any
link, node, and SLRG in common with the primary working Q'
(associated with Q) by comparing the stored PPRO subobjects
associated with P'[1],...,P'[n] with the PPRO subobjects associated
with Q' received in the Path message.
- Nがチェックする、'LSPs P'[1]を扱う予備選挙、…'LSPs P[1]、…に関連しているP'[n]''P[n]はそれぞれ保存されたPPRO subobjectsを比較するのによるQ'(Qに関連している)がP'[1]に関連づけたプライマリ運用と共用してどんなリンク、ノード、およびSLRGも持っています、…Pathメッセージに受け取るQ'に関連しているPPRO subobjectsがあるP'[n]。
- If this is the case, N SHOULD NOT attempt to share the outgoing
link resource r between P[1],...,P[n] and Q. However, upon local
policy decision, N MAY allocate another available (shared) link
other than r for use by Q. If this is not the case (upon the local
policy decision that no other link is allowed to be allocated for
Q) or if no other link is available for Q, N SHOULD return a
PathErr message with the new error code/sub-code "Admission Control
Failure/LSP Admission Failure".
- これがそうであるなら、N SHOULD NOTは、P[1]の間の送信するリンクリソースrを共有するのを試みます…P[n]とQ.However、ローカルの政策決定、5月がQ.Ifによる使用のためにr以外の別の利用可能な(分配している)リンクを割り当てるNでは、これはそう(他のどんなリンクもQのために割り当てることができないというローカルの方針決定での)か他のどんなリンクもQ(SHOULDが新しいサブエラーコード/コード「入場コントロール失敗/LSP入場の故障」があるPathErrメッセージを返すN)に利用可能でないかどうかということではありません。
- Otherwise (if P'[1],...,P'[n] and Q' are fully disjoint), the link
r selected by N for the LSP Q MAY be exactly the same as the one
selected for the LSPs P[1],...,P[n]. This happens after verifying
(from the node's local policy) that the selected link r can be
shared between these LSPs. If this is not the case (for instance,
the sharing ratio has reached its maximum for that link), and if
upon local policy decision, no other link is allowed to be
allocated for Q, N SHOULD return a PathErr message with the error
code/sub-code "Admission Control Failure/Requested Bandwidth
Unavailable" (see [RFC2205]). Otherwise (if no other link is
available), N SHOULD return a PathErr message with the new error
code/sub-code "Admission Control Failure/LSP Admission Failure".
- 'そうでなければ、(P'[1]、…、P'[n]、およびQ'が完全にそうである、ばらばらになる、)、LSP QのためにNによって選択されたリンクrはまさにLSPs P[1]のために選択されたものと同じであるかもしれません、…P[n]。 これはこれらのLSPsの間で選択されたリンクrを共有できることを確かめた(ノードのローカルの方針から)後に、起こります。 これがそう(例えば、共有比はそのリンクへの最大に達した)でなく、他のどんなリンクもローカルの政策決定のときにQのために割り当てることができないなら、N SHOULDは「入手できない入場コントロール失敗/要求された帯域幅」をサブエラーコード/コードがあるPathErrメッセージに返します([RFC2205]を見てください)。 さもなければ(他のどんなリンクも利用可能でないなら)、N SHOULDは新しいサブエラーコード/コード「入場コントロール失敗/LSP入場の故障」があるPathErrメッセージを返します。
Note that the process, through which m out of the n (m =< n) secondary protecting LSPs' PPROs may be selected on a local basis to perform the above comparison and subsequent link selection, is out of scope of this document.
このドキュメントの範囲の外にn(m=<n)セカンダリ保護LSPsのPPROsからのどのmが上の比較とその後のリンク選択を実行する地方ベースで選択されるかもしれないかを通してプロセスがあることに注意してください。
Lang, et al. Standards Track [Page 36] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[36ページ]RFC RSVP-Te拡張子
16. ASSOCIATION Object
16. 協会オブジェクト
The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. The object uses an object class number of the form 11bbbbbb to ensure compatibility with non- supporting nodes.
ASSOCIATIONオブジェクトは、LSPsを互いに関連づけるのに使用されます。 終わりから終わりへのLSP回復の文脈では、協会は同じトンネル送付者アドレスとトンネル終点アドレスと同様に同じTunnel IDをサポートするLSPsを特定するだけでよいです。 Association Type、Association Source、および一緒にオブジェクトのAssociation ID分野は唯一協会を特定します。 オブジェクトは、非サポートしているノードとの互換性を確実にするのにフォーム11bbbbbbのオブジェクトクラス番号を使用します。
The ASSOCIATION object is used to associate LSPs with each other.
ASSOCIATIONオブジェクトは、LSPsを互いに関連づけるのに使用されます。
16.1. Format
16.1. 形式
The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format:
IPv4 ASSOCIATIONオブジェクト(値があるフォーム11bbbbbbのクラスヌムは199、C-タイプ=1と等しい)には、形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(199)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 協会タイプ| 協会ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4協会ソース| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 2) has the format:
IPv6 ASSOCIATIONオブジェクト(値があるフォーム11bbbbbbのクラスヌムは199、C-タイプ=2と等しい)には、形式があります:
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(199)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(199)| C-タイプ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 協会タイプ| 協会ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6協会ソース| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lang, et al. Standards Track [Page 37] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[37ページ]RFC RSVP-Te拡張子
Association Type: 16 bits
協会タイプ: 16ビット
Indicates the type of association being identified. Note that
this value is considered when determining association. The
following are values defined in this document.
特定される協会のタイプを示します。 協会を決定するとき、この値が考えられることに注意してください。 ↓これは本書では定義された値です。
Value Type
----- ----
0 Reserved
1 Recovery (R)
値のタイプ----- ---- 0 予約された1つの回復(R)
Association ID: 16 bits
協会ID: 16ビット
A value assigned by the LSP head-end. When combined with the
Association Type and Association Source, this value uniquely
identifies an association.
LSPギヤエンドまでに割り当てられた値。 Association TypeとAssociation Sourceに結合されると、この値は唯一協会を特定します。
Association Source: 4 or 16 bytes
協会ソース: 4バイトか16バイト
An IPv4 or IPv6 address, respectively, that is associated to
the node that originated the association.
協会を溯源したノードに関連づけられて、IPv4かIPv6がすなわち、それぞれと、扱います。
16.2. Processing
16.2. 処理
In the end-to-end LSP recovery context, the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) it is protecting or a protected LSP(s) with its recovery LSP. The object is carried in Path messages. More than one object MAY be carried in a single Path message.
終わらせる終わりのLSP回復文脈、ASSOCIATIONオブジェクトは、回復LSPと共にそれが保護しているLSP(s)か保護されたLSP(s)に回復LSPを関連づけるのに使用されます。 オブジェクトはPathメッセージで運ばれます。 1個以上のオブジェクトがただ一つのPathメッセージで運ばれるかもしれません。
Transit nodes MUST transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message.
トランジットノードは対応する送信するPathメッセージで変更なしでどんな容認されたASSOCIATIONオブジェクトも伝えなければなりません。
An ASSOCIATION object with an Association Type set to the value "Recovery" is used to identify an LSP-Recovery-related association. Any node associating a recovery LSP MUST insert an ASSOCIATION object with the following setting:
値の「回復」に用意ができているAssociation TypeがあるASSOCIATIONオブジェクトは、LSP回復関連の協会を特定するのに使用されます。 以下がセットしている状態でASSOCIATIONが反対させる回復LSP MUST差し込みを関連づけるどんなノードも:
- The Association Type MUST be set to the value "Recovery" in the
Path message of the recovery LSP.
- Association Typeは回復LSPに関するPathメッセージにおける値の「回復」に用意ができなければなりません。
- The (IPv4/IPv6) Association Source MUST be set to the tunnel sender
address of the LSP being protected.
- (IPv4/IPv6)協会Sourceは保護されるLSPのトンネル送付者アドレスに用意ができなければなりません。
Lang, et al. Standards Track [Page 38] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[38ページ]RFC RSVP-Te拡張子
- The Association ID MUST be set to the LSP ID of the LSP being
protected by this LSP or the LSP protecting this LSP. If unknown,
this value is set to its own signaled LSP_ID value (default).
Also, the value of the Association ID MAY change during the
lifetime of the LSP.
- このLSPによって保護されるLSPかこのLSPを保護するLSPのLSP IDにAssociation IDを設定しなければなりません。 未知であるなら、この値はそれ自身の合図されたLSP_ID値(デフォルト)に設定されます。 また、Association IDの値はLSPの生涯変化するかもしれません。
Terminating nodes use received ASSOCIATION object(s) with the Association Type set to the value "Recovery" to associate a recovery LSP with its matching working LSP. This information is used to bind the appropriate working and recovery LSPs together. Such nodes MUST ensure that the received Path messages, including ASSOCIATION object(s), are processed with the appropriate PROTECTION object settings, if present (see Section 14 for PROTECTION object processing). Otherwise, this node MUST return a PathErr message with the new error code/sub-code "LSP Admission Failure/Bad Association Type". Similarly, terminating nodes receiving a Path message with a
ノード使用を終えると、ASSOCIATIONオブジェクトは合っている働くLSPと共にAssociation Typeセットで回復を関連づける値の「回復」LSPに受けられました。 この情報は、適切な運用と回復LSPsを一緒にくくるのに使用されます。 そのようなノードは、ASSOCIATIONオブジェクトを含む受信されたPathメッセージが適切なPROTECTIONオブジェクト設定で処理されていて、存在しているのを確実にしなければなりません(PROTECTIONオブジェクト処理に関してセクション14を見てください)。 さもなければ、このノードは新しいサブエラーコード/コード「LSP入場の故障/悪い協会タイプ」でPathErrメッセージを返さなければなりません。 同様に、Pathを受ける終わりノードがaで通信します。
PROTECTION object requiring association between working and recovery LSPs MUST include an ASSOCIATION object. Otherwise, such nodes MUST return a PathErr message with the new error code/sub-code "Routing Problem/PROTECTION object not Applicable".
働いていることの間の協会を必要とするPROTECTION目的と回復LSPsはASSOCIATIONオブジェクトを含まなければなりません。 さもなければ、そのようなノードは新しいサブエラーコード/コード「ルート設定Problem/PROTECTIONオブジェクトApplicableでない」と共にPathErrメッセージを返さなければなりません。
17. Updated RSVP Message Formats
17. アップデートされたRSVPメッセージ・フォーマット
This section presents the RSVP message-related formats as modified by this document. Unmodified RSVP message formats are not listed.
このセクションは変更されるとしてのこのドキュメントによるRSVPのメッセージ関連の形式を提示します。 変更されていないRSVPメッセージ・フォーマットは記載されていません。
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> ... ]
[ <PRIMARY_PATH_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<経路メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<の明白な_ルート>]<ラベル_要求>[<保護>]を評価します[<ラベル_は>を…設定しました]。 [<セッション_属性>] [<は_要求>に通知します…] [<アドミン_状態>] [<協会>] [<のプライマリ_経路_は>を発送します…] [<方針_データ>] <送付者記述子>。
The format of the <sender descriptor> for unidirectional and bidirectional LSPs is not modified by the present document.
<送付者記述子の単方向の間の>と双方向のLSPsの形式は現在のドキュメントによって変更されません。
Lang, et al. Standards Track [Page 39] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[39ページ]RFC RSVP-Te拡張子
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> ]
[ <PROTECTION> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<Resvメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>を評価します[<RESV_は>を確認します][<範囲>][<保護>][<は_要求>に通知します][<アドミン_状態>][<方針_データ>…]。 <様式><流れ記述子リスト>。
<flow descriptor list> is not modified by this document.
<流れ記述子リスト>はこのドキュメントによって変更されません。
18. Security Considerations
18. セキュリティ問題
The security threats identified in [RFC4426] may be experienced due to the exchange of RSVP messages and information as detailed in this document. The following security mechanisms apply.
[RFC4426]で特定された軍事的脅威はRSVPメッセージと情報の交換のため本書では詳しく述べられるように経験されるかもしれません。 以下のセキュリティー対策は適用されます。
RSVP signaling MUST be able to provide authentication and integrity. Authentication is required to ensure that the signaling messages are originating from the right place and have not been modified in transit.
RSVPシグナリングは認証と保全を提供できなければなりません。 認証が、シグナリングメッセージが適当な場所から発しているのを確実にして、トランジットで変更されていないように必要です。
For this purpose, [RFC2747] provides the required RSVP message authentication and integrity for hop-by-hop RSVP message exchanges. For non hop-by-hop RSVP message exchanges the standard IPsec-based integrity and authentication can be used as explained in [RFC3473].
このために、[RFC2747]は必要なRSVP通報認証と保全をホップごとのRSVP交換処理に提供します。 非ホップごとのRSVP交換処理のために、[RFC3473]で説明されるように標準のIPsecベースの保全と認証を使用できます。
Moreover, this document makes use of the Notify message exchange. This precludes RSVP's hop-by-hop integrity and authentication model. In the case, when the same level of security provided by [RFC2747] is desired, the standard IPsec based integrity and authentication can be used as explained in [RFC3473].
そのうえ、このドキュメントはNotify交換処理を利用します。 これはRSVPのホップごとの保全と認証モデルを排除します。 [RFC2747]によって提供された同じレベルのセキュリティが望まれているときの場合では、標準のIPsecは保全を基礎づけました、そして、[RFC3473]で説明されるように認証は使用できます。
To prevent the consequences of poorly applied protection and the increased risk of misconnection, in particular, when extra-traffic is involved, that would deliver the wrong traffic to the wrong destination, specific mechanisms have been put in place as described in Section 7.2, 8.3, and 10.
余分な交通がかかわるとき、不十分に適用された保護の結果と付け違いの増加する危険を特に防ぐために、それは間違った交通を間違った送付先に届けて、特定のメカニズムはセクション7.2、8.3、および10で説明されるように適所に置かれました。
Lang, et al. Standards Track [Page 40] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[40ページ]RFC RSVP-Te拡張子
19. IANA Considerations
19. IANA問題
IANA assigns values to RSVP protocol parameters. Within the current document, a PROTECTION object (new C-Type), a PRIMARY_PATH_ROUTE object, and an ASSOCIATION object are defined. In addition, new Error code/sub-code values are defined in this document. Finally, registration of the ADMIN_STATUS object bits is requested.
IANAはRSVPプロトコルパラメタに値を割り当てます。 現在のドキュメントの中では、PROTECTION物(新しいC-タイプ)、PRIMARY_PATH_ROUTE物、およびASSOCIATION物は定義されます。 さらに、新しいErrorサブコード/コード値は本書では定義されます。 最終的に、ADMIN_STATUS物のビットの登録は要求されています。
Two RSVP Class Numbers (Class-Num) and three Class Types (C-Types) values have to be defined by IANA in registry:
2つのRSVP Class民数記(クラスヌム)と3Class Types(C-タイプ)の値が登録でIANAによって定義されなければなりません:
http://www.iana.org/assignments/rsvp-parameters
http://www.iana.org/assignments/rsvp-parameters
1) PROTECTION object (defined in Section 14.1)
1) PROTECTION物(セクション14.1では、定義されます)
o PROTECTION object: Class-Num = 37
o PROTECTIONは反対します: クラスヌム=37
- Type 2: C-Type = 2
- 2はタイプします: C-タイプ=2
2) PRIMARY_PATH_ROUTE object (defined in Section 15.1)
2) PRIMARY_PATH_ROUTE物(セクション15.1では、定義されます)
o PRIMARY_PATH_ROUTE object: Class-Num = 38 (of the form 0bbbbbbb),
o PRIMARY_PATH_ROUTEは反対します: クラスヌム=38(フォーム0bbbbbbbの)
- Primary Path Route: C-Type = 1
- 第一の経路ルート: C-タイプ=1
3) ASSOCIATION object (defined in Section 16.1)
3) ASSOCIATION物(セクション16.1では、定義されます)
o ASSOCIATION object: Class-Num = 199 (of the form 11bbbbbb)
o ASSOCIATIONは反対します: クラスヌム=199(フォーム11bbbbbbの)
- IPv4 Association: C-Type = 1 - IPv6 Association: C-Type = 2
- IPv4協会: C-タイプ=1--IPv6協会: C-タイプ=2
o Association Type
o 協会タイプ
The following values defined for the Association Type (16 bits) field of the ASSOCIATION object.
ASSOCIATION物のAssociation Type(16ビット)分野と定義された以下の値。
Value Type
----- ----
0 Reserved
1 Recovery (R)
値のタイプ----- ---- 0 予約された1つの回復(R)
Assignment of values (from 2 to 65535) by IANA are subject to IETF expert review process, i.e., IETF Standards Track RFC Action.
IANAによる値(2〜65535までの)の課題はIETFの専門の吟味の過程(すなわち、IETF Standards Track RFC Action)を受けることがあります。
Lang, et al. Standards Track [Page 41] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[41ページ]RFC RSVP-Te拡張子
4) Error Code/Sub-code values
4) 誤りサブCode/コード値
The following Error code/sub-code values are defined in this document:
以下のErrorサブコード/コード値は本書では定義されます:
Error Code = 01: "Admission Control Failure" (see [RFC2205])
誤りコード=01: 「入場コントロール失敗」([RFC2205]を見ます)
o "Admission Control Failure/LSP Admission Failure" (4) o "Admission Control Failure/Bad Association Type" (5)
o 「入場Control Failure/LSP Admission Failure」(4)o「入場コントロール失敗/悪い協会タイプ」(5)
Error Code = 02: "Policy Control Failure" (see [RFC2205])
誤りコード=02: 「方針コントロール失敗」([RFC2205]を見ます)
o "Policy Control failure/Hard Pre-empted" (20)
o 「方針は一生懸命先取りされていた状態で失敗/を制御します」(20)
Error Code = 24: "Routing Problem" (see [RFC3209])
誤りコード=24: 「ルート設定問題」([RFC3209]を見ます)
o "Routing Problem/Unsupported LSP Protection" (17) o "Routing Problem/PROTECTION object not applicable" (18) o "Routing Problem/Bad PRIMARY_PATH_ROUTE object" (19) o "Routing Problem/PRIMARY_PATH_ROUTE object not applicable" (20)
o (19) ○ 「Problem/サポートされないLSP Protectionを発送し」て、(17) ○ 「適切でなくProblem/PROTECTION物を発送し」て、(18) ○ 「Problem/悪いPRIMARY_PATH_ROUTE物を発送し」て、「ルート設定Problem/PRIMARY_PATH_ROUTEは適切でない状態で反対します」。(20)
Error Code = 25: "Notify Error" (see [RFC3209])
誤りコード=25: 「誤りに通知してください」([RFC3209]を見ます)
o "Notify Error/LSP Failure" (9) o "Notify Error/LSP Recovered" (10) o "Notify Error/LSP Locally Failed" (11)
o (9)o「回復されていた状態で誤り/LSPに通知してください」(10)oは、「Error/LSP Failureに通知してください。」ように「局所的に失敗された誤り/LSPに通知します」。(11)
5) Registration of the ADMIN_STATUS object bits
5) ADMIN_STATUS物のビットの登録
The ADMIN_STATUS object (Class-Num = 196, C-Type = 1) is defined in [RFC3473].
ADMIN_STATUS物(クラスヌムは196、C-タイプ=1と等しい)は[RFC3473]で定義されます。
IANA is also requested to track the ADMIN_STATUS bits extended by this document. For this purpose, the following new registry entries have been created:
また、IANAがこのドキュメントによって広げられたADMIN_STATUSビットの跡をつけるよう要求されています。 このために、以下の新しい登録エントリーを作成してあります:
http://www.iana.org/assignments/gmpls-sig-parameters
http://www.iana.org/assignments/gmpls-sig-parameters
- ADMIN_STATUS bits:
- ADMIN_STATUSビット:
Name: ADMIN_STATUS bits
Format: 32-bit vector of bits
Position:
[0] Reflect (R) bit defined in [RFC3471]
[1..25] To be assigned by IANA via IETF Standards
Track RFC Action.
[26] Lockout (L) bit is defined in Section 13
[27] Inhibit alarm communication (I) in [RFC4783]
以下を命名してください。 ADMIN_STATUSビットFormat: ビットPositionの32ビットのベクトル: [0] IETF Standards Track RFC Actionを通してIANAによって割り当てられるように[RFC3471][1 .25]で定義された(R)ビットを反映してください。 [26] ロックアウト(L)ビットは[27]がアラームコミュニケーション(I)を禁止するセクション13で定義されます。[RFC4783]
Lang, et al. Standards Track [Page 42] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[42ページ]RFC RSVP-Te拡張子
[28] Call control (C) bit is defined in
[GMPLS-CALL]
[29] Testing (T) bit is defined in [RFC3471]
[30] Administratively down (A) bit is defined in
[RFC3471]
[31] Deletion in progress (D) bit is defined in
[RFC3471]
[28] コントロール(C)ビットが[29] (T)をテストしながら[GMPLS-CALL]で定義されて、ビットが[RFC3471]で[30] 行政上(A)ビットの下側と定義されるということであるという要求は進行中の(D)ビットが定義される[RFC3471][31]削除で定義されます。[RFC3471]
20. Acknowledgments
20. 承認
The authors would like to thank John Drake for his active collaboration, Adrian Farrel for his contribution to this document (in particular, to the Section 10 and 11) and his thorough review of the document, Bart Rousseau (for editorial review), Dominique Verchere, and Stefaan De Cnodder. Thanks also to Ichiro Inoue for his valuable comments.
作者は彼の積極的な協力のためのジョン・ドレイク、彼の貢献のためのこのドキュメント(セクション10と11に特定の)と彼のドキュメント、バード・ルソー(社説のレビューのための)、ドミニクVerchere、およびStefaan De Cnodderの徹底的なレビューへのエードリアン・ファレルに感謝したがっています。 また、彼の貴重なコメントを井上一郎をありがとうございます。
The authors would also like to thank Lou Berger for the time and effort he spent together with the design team, in contributing to the present document.
また、作者は、彼がデザインチームと共に現在のドキュメントに貢献するのに費やしたのを時間と努力のためのルウ・バーガーに感謝したがっています。
21. References
21. 参照
21.1. Normative References
21.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月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC2961] バーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(2001年4月)。
[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., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
Lang, et al. Standards Track [Page 43] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[43ページ]RFC RSVP-Te拡張子
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.、およびY.Rekhter、「資源予約に基づく合図の無数のリンクは議定書を作ります--交通工学(RSVP-Te)」、RFC3477、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3945、2004年10月。
[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
"Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March
2006.
[RFC4426] ラング、J.、Rajagopalan、B.、およびD.Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)の回復の機能的な仕様」、RFC4426、2006年3月。
[RFC4873] Berger, L., Bryskin, I., Papdimitriou, D., and A.
Farrel, "GMPLS Segment Recovery," RFC 4873, May 2007.
[RFC4873] バーガー、L.、Bryskin、I.、Papdimitriou、D.、およびA.ファレル、「GMPLSセグメント回復」、RFC4873は2007がそうするかもしれません。
21.2. Informative References
21.2. 有益な参照
[RFC4783] Berger, L., "GMPLS - Communication of Alarm
Information", RFC 4783, December 2006.
[RFC4783]バーガー、L.、「GMPLS--、アラーム情報に関するコミュニケーション、」、RFC4783、12月2006日
[CRANK] Farrel, A., Ed., "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", Work in Progress, January
2007.
[クランク]ファレル、A.、エド「CrankbackはMPLSのための拡大とGMPLS RSVP-Teに合図すること」での進行中の仕事、2007年1月。
[GMPLS-CALL] Papadimitriou, D., Ed., and A. Farrel, Ed., "Generalized
MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
Calls", Work in Progress, January 2007.
[GMPLS-CALL]Papadimitriou(D.(エド)、およびA.ファレル(エド))は「Callsを支持してMPLS(GMPLS)RSVP-TE Signaling Extensionsを一般化しました」、ProgressのWork、2007年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC
4090, May 2005.
[RFC4090]なべ、P.(エド)、ツバメ、G.(エド)、およびA.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、2005年5月。
[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月)。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes
- Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]リー(CY)、ファレル、A.、およびS.De Cnodderは「資源予約プロトコル交通工学(RSVP-Te)までルート--拡大を除きます」、RFC4874、2007年4月。
Lang, et al. Standards Track [Page 44] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[44ページ]RFC RSVP-Te拡張子
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, October
1998, available from http://www.itu.int.
[G.841]ITU-T、「SDHのタイプと特性は保護構造をネットワークでつなぐ」1998年10月に http://www.itu.int から利用可能なRecommendation G.841。
22. Contributors
22. 貢献者
This document is the result of the CCAMP Working Group Protection and Restoration design team joint effort. The following are the authors that contributed to the present document:
このドキュメントはCCAMP作業部会Protectionの結果であり、王政復古デザインチームは共同努力です。 ↓これは現在のドキュメントに貢献した作者です:
Deborah Brungard (AT&T) Rm. D1-3C22 - 200, S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
デボラBrungard(AT&T)Rm。 D1-3C22--200 S.ローレルAve。 ミドルタウン、ニュージャージー 07748、米国はメールされます: dbrungard@att.com
Sudheer Dharanikota EMail: sudheer@ieee.org
Sudheer Dharanikotaはメールします: sudheer@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue Florham Park, NJ 07932, USA EMail: gli@research.att.com
Guangzhi李(AT&T)180パーク・アベニューFlorham公園、ニュージャージー 07932、米国はメールされます: gli@research.att.com
Eric Mannie (Perceval) Rue Tenbosch, 9 1000 Brussels, Belgium Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
エリックマニー(Perceval)はTenbosch、1000ブリュッセル(ベルギー)が電話をする9を悔悟します: +32-2-6409194はメールされます: eric.mannie@perceval.net
Bala Rajagopalan (Intel Broadband Wireless Division) 2111 NE 25th Ave. Hillsboro, OR 97124, USA EMail: bala.rajagopalan@intel.com
Bala Rajagopalanの(インテルの広帯域の無線の師団)2111年のNeの第25Ave。 ヒルズバロ、または97124、米国がメールされます: bala.rajagopalan@intel.com
Lang, et al. Standards Track [Page 45] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[45ページ]RFC RSVP-Te拡張子
Editors' Addresses
エディタのアドレス
Jonathan P. Lang Sonos 506 Chapala Street Santa Barbara, CA 93101, USA
サンタバーバラ、カリフォルニア 93101、ジョナサンP.ラングSonos506チャパラ通り米国
EMail: jplang@ieee.org
メール: jplang@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
ヤコフRekhter Juniper1194N.マチルダ・Avenueサニーベル、カリフォルニア 94089、米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
Dimitri Papadimitriou Alcatel Copernicuslaan 50 B-2018, Antwerpen, Belgium
B-2018、ディミトリPapadimitriouアルカテルCopernicuslaan50アントウェルペン(ベルギー)
EMail: dimitri.papadimitriou@alcatel-lucent.be
メール: dimitri.papadimitriou@alcatel-lucent.be
Lang, et al. Standards Track [Page 46] RFC 4872 RSVP-TE Extensions for E2E GMPLS Recovery May 2007
ラング、他 GMPLS回復2007年5月の2EのEの4872の標準化過程[46ページ]RFC RSVP-Te拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lang, et al. Standards Track [Page 47]
ラング、他 標準化過程[47ページ]
一覧
スポンサーリンク
