[要約] RFC 4426は、GMPLSネットワークの回復機能の仕様を定義しています。その目的は、ネットワークの障害が発生した場合に、データ転送の継続性を確保するための回復メカニズムを提供することです。
Network Working Group J. Lang, Ed.
Request for Comments: 4426 B. Rajagopalan, Ed.
Category: Standards Track D. Papadimitriou, Ed.
March 2006
Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification
一般化されたマルチプロトコルラベルスイッチング（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents.
このドキュメントでは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）ベースの回復（つまり、保護と修復）をサポートするために必要なプロトコル拡張の機能的説明を示します。プロトコル固有の形式とメカニズムは、コンパニオンドキュメントで説明されています。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 3
2. Span Protection .............................................. 3
2.1. Unidirectional 1+1 Dedicated Protection ................ 4
2.2. Bi-directional 1+1 Dedicated Protection ................ 5
2.3. Dedicated 1:1 Protection with Extra Traffic ............ 6
2.4. Shared M:N Protection .................................. 8
2.5. Messages ............................................... 10
2.5.1. Failure Indication Message ..................... 10
2.5.2. Switchover Request Message ..................... 11
2.5.3. Switchover Response Message .................... 11
2.6. Preventing Unintended Connections ...................... 12
3. End-to-End (Path) Protection and Restoration ................. 12
3.1. Unidirectional 1+1 Protection .......................... 12
3.2. Bi-directional 1+1 Protection .......................... 12
3.2.1. Identifiers .................................... 13
3.2.2. Nodal Information .............................. 14
3.2.3. End-to-End Failure Indication Message .......... 14
3.2.4. End-to-End Failure Acknowledgement Message ..... 15
3.2.5. End-to-End Switchover Request Message .......... 15
3.2.6. End-to-End Switchover Response Message ......... 15
3.3. Shared Mesh Restoration ................................ 15
3.3.1. End-to-End Failure Indication and
Acknowledgement Message ........................ 16
3.3.2. End-to-End Switchover Request Message .......... 16
3.3.3. End-to-End Switchover Response Message ......... 17
4. Reversion and Other Administrative Procedures ................ 17
5. Discussion ................................................... 18
5.1. LSP Priorities During Protection ....................... 18
6. Security Considerations ...................................... 19
7. Contributors ................................................. 20
8. References ................................................... 21
8.1. Normative References ................................... 21
8.2. Informative References ................................. 22
A requirement for the development of a common control plane for both optical and electronic switching equipment is that there must be signaling, routing, and link management mechanisms that support data plane fault recovery. In this document, the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are used only when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery period (see [RFC4427]).
光学および電子スイッチング機器の両方の共通制御プレーンの開発の要件は、データプレーン障害回復をサポートするシグナル、ルーティング、およびリンク管理メカニズムが必要であることです。このドキュメントでは、「回復」という用語は、保護と回復の両方を示すために一般的に使用されます。特定の用語「保護」と「修復」は、分化が必要な場合にのみ使用されます。保護と回復の微妙な区別は、回復期間中に行われたリソース割り当てに基づいて行われます（[RFC4427]を参照）。
A label-switched path (LSP) may be subject to local (span), segment, and/or end-to-end recovery. Local span protection refers to the protection of the link (and hence all the LSPs marked as required for span protection and routed over the link) between two neighboring switches. Segment protection refers to the recovery of an LSP segment (i.e., an SNC in the ITU-T terminology) between two nodes, i.e., the boundary nodes of the segment. End-to-end protection refers to the protection of an entire LSP from the ingress to the egress port. The end-to-end recovery models discussed in this document apply to segment protection where the source and destination refer to the protected segment rather than the entire LSP. Multiple recovery levels may be used concurrently by a single LSP for added resiliency; however, the interaction between levels affects any one direction of the LSP results in both directions of the LSP being switched to a new span, segment, or end-to-end path.
ラベルスイッチパス（LSP）は、ローカル（SPAN）、セグメント、および/またはエンドツーエンドの回復の影響を受ける場合があります。ローカルスパン保護とは、2つの隣接するスイッチ間でリンクの保護（したがって、スパン保護に必要なとマークされ、リンクを介してルーティングされたすべてのLSP）を指します。セグメント保護とは、2つのノード、つまりセグメントの境界ノード間のLSPセグメント（つまり、ITU-T用語のSNC）の回復を指します。エンドツーエンドの保護とは、侵入から出口ポートへのLSP全体の保護を指します。このドキュメントで説明されているエンドツーエンドの回復モデルは、ソースと宛先がLSP全体ではなく保護されたセグメントを参照するセグメント保護に適用されます。複数の回復レベルは、弾力性を高めるために単一のLSPによって同時に使用できます。ただし、レベル間の相互作用は、LSPの1つの方向に影響を与え、LSPの両方向に新しいスパン、セグメント、またはエンドツーエンドパスに切り替えられます。
Unless otherwise stated, all references to "link" in this document indicate a bi-directional link (which may be realized as a pair of unidirectional links).
特に明記しない限り、このドキュメントの「リンク」への参照はすべて、双方向リンク（一対の単方向リンクとして実現される場合がある）を示しています。
Consider the control plane message flow during the establishment of an LSP. This message flow proceeds from an initiating (or source) node to a terminating (or destination) node, via a sequence of intermediate nodes. A node along the LSP is said to be "upstream" from another node if the former occurs first in the sequence. The latter node is said to be "downstream" from the former node. That is, an "upstream" node is closer to the initiating node than a node further "downstream". Unless otherwise stated, all references to "upstream" and "downstream" are in terms of the control plane message flow.
LSPの確立中のコントロールプレーンメッセージフローを考慮してください。このメッセージフローは、中間ノードのシーケンスを介して、開始（またはソース）ノードから終端（または宛先）ノードに進みます。LSPに沿ったノードは、前者がシーケンスで最初に発生した場合、別のノードから「上流」であると言われます。後者のノードは、以前のノードから「下流」であると言われています。つまり、「上流」ノードは、「下流」のノードよりも開始ノードに近いものです。特に明記しない限り、「上流」および「下流」へのすべての言及は、コントロールプレーンのメッセージフローの観点からです。
The flow of the data traffic is defined from ingress (source node) to egress (destination node). Note that for bi-directional LSPs, there are two different data plane flows, one for each direction of the LSP. This document presents a protocol functional description to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol-specific formats, encoding, and mechanisms will be described in companion documents.
データトラフィックのフローは、イングレス（ソースノード）から出口（宛先ノード）に定義されます。双方向LSPの場合、LSPの各方向に1つずつ、2つの異なるデータプレーンフローがあることに注意してください。このドキュメントでは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）ベースの回復（つまり、保護と回復）をサポートするプロトコル機能説明を提示します。プロトコル固有の形式、エンコード、およびメカニズムについては、コンパニオンドキュメントで説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3945], [RFC3471] and referenced as well as [RFC4427].
さらに、読者は[RFC3945]、[RFC3471]で使用されている用語に精通しており、[RFC4427]と同様に参照されていると想定されています。
Consider a (working) link i between two nodes A and B. There are two fundamental models for span protection. The first is referred to as 1+1 protection. Under this model, a dedicated link j is pre-assigned to protect link i. LSP traffic is permanently bridged onto both links i and j at the ingress node, and the egress node selects the signal (i.e., normal traffic) from i or j, based on a selection function (e.g., signal quality). Under unidirectional 1+1 span protection (Section 2.1), each node A and B acts autonomously to select the signal from the working link i or the protection link j. Under bi-directional 1+1 span protection (Section 2.2) the two nodes A and B coordinate the selection function such that they select the signal from the same link, i or j.
2つのノードAとBの間の（動作）リンクIを検討してください。スパン保護のための2つの基本モデルがあります。1つ目は1 1保護と呼ばれます。このモデルでは、専用のリンクJがリンクiを保護するために事前に割り当てられます。LSPトラフィックは、IngressノードのリンクIとJの両方のリンクに永続的に架橋されており、Egressノードは、選択関数（たとえば、信号品質）に基づいて、IまたはJから信号（つまり、通常のトラフィック）を選択します。単方向1 1スパン保護（セクション2.1）では、各ノードAとBは自律的に作用して、作業リンクIまたは保護リンクjから信号を選択します。双方向1 1スパン保護（セクション2.2）では、2つのノードAとBが選択関数を調整して、同じリンク、iまたはjから信号を選択するようにします。
Under the second model, a set of N working links are protected by a set of M protection links, usually with M =< N. A failure in any of the N working links results in traffic being switched to one of the M protection links that is available. This is typically a three-step process: first the data plane failure is detected at the egress node and reported (notification), then a protection link is selected, and finally, the LSPs on the failed link are moved to the protection link. If reversion is supported, a fourth step is included, i.e., return of the traffic to the working link (when the working link has recovered from the failure). In Section 2.3, 1:1 span protection is described. In Section 2.4, M:N span protection is described, where M =< N.
2番目のモデルでは、n作業リンクのセットは、通常はm = <NでM保護リンクのセットによって保護されます。N作業リンクのいずれかの障害は、トラフィックがMプロテクションリンクの1つに切り替えられるようになります。利用可能です。これは通常、3段階のプロセスです。最初に、Data Planeの障害がEgressノードで検出され、報告された（通知）、次に保護リンクが選択され、最後に、失敗したリンクのLSPが保護リンクに移動されます。リバージョンがサポートされている場合、4番目のステップが含まれています。つまり、作業リンクへのトラフィックのリターン（作業リンクが障害から回復した場合）。セクション2.3では、1：1のスパン保護について説明します。セクション2.4では、m：nスパン保護が記載されています。ここで、m = <n。
Suppose a bi-directional LSP is routed over link i between two nodes A and B. Under unidirectional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i. LSP traffic is permanently bridged on both links at the ingress node, and the egress node selects the normal traffic from one of the links, i or j. If a node (A or B) detects a failure of a span, it autonomously invokes a process to receive the traffic from the protection span. Thus, it is possible that node A selects the signal from link i in the B to A direction of the LSP, and node B selects the signal from link j in the A to B direction.
双方向LSPが2つのノードAとBの間のリンクI上にルーティングされているとします。単方向1 1保護下では、作業リンクiを保護するために専用のリンクJが事前に割り当てられています。LSPトラフィックは、イングレスノードの両方のリンクで永続的に架橋されており、Egressノードは、リンクのいずれかから通常のトラフィックを選択します。ノード（aまたはb）がスパンの障害を検出すると、保護スパンからトラフィックを受信するプロセスを自律的に呼び出します。したがって、ノードAは、BのリンクIからLSPの方向への信号を選択し、ノードBはA AのリンクJからB方向への信号を選択する可能性があります。
The following functionality is required for 1+1 unidirectional span protection:
1 1の単方向スパン保護には、次の機能が必要です。
o Routing: A single TE link encompassing both working and protection links SHOULD be announced with a Link Protection Type "Dedicated 1+1", along with the bandwidth parameters for the working link. As the resources are consumed/released, the bandwidth parameters of the TE link are adjusted accordingly. Encoding of the Link Protection Type and bandwidth parameters in IS-IS is specified in [RFC4205]. Encoding of this information in OSPF is specified in [RFC4203].
o ルーティング：作業リンクと保護リンクの両方を含む単一のTEリンクは、作業リンクの帯域幅パラメーターとともに、リンク保護タイプ「専用1 1」で発表する必要があります。リソースが消費/リリースされると、TEリンクの帯域幅パラメーターがそれに応じて調整されます。IS-ISのリンク保護タイプと帯域幅パラメーターのエンコードは、[RFC4205]で指定されています。OSPFでのこの情報のエンコードは、[RFC4203]で指定されています。
o Signaling: The Link Protection object/TLV SHOULD be used to request "Dedicated 1+1" link protection for that LSP. This object/TLV is defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy. No additional signaling is required when a fail-over occurs.
o シグナリング：リンク保護オブジェクト/TLVを使用して、そのLSPの「専用1 1」リンク保護を要求する必要があります。このオブジェクト/TLVは[RFC3471]で定義されています。リンク保護オブジェクト/TLVが使用されない場合、リンク選択はローカルポリシーの問題です。フェールオーバーが発生した場合、追加のシグナル伝達は必要ありません。
o Link management: Both nodes MUST have a consistent view of the link protection association for the spans. This can be done using the Link Management Protocol (LMP) [RFC4204], or if LMP is not used, this MUST be configured manually.
o リンク管理：両方のノードには、スパンのリンク保護アソシエーションの一貫したビューが必要です。これは、Link Management Protocol（LMP）[RFC4204]を使用して実行できます。または、LMPが使用されていない場合は、手動で構成する必要があります。
Suppose a bi-directional LSP is routed over link i between two nodes A and B. Under bi-directional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i. LSP traffic is permanently duplicated on both links, and under normal conditions, the traffic from link i is received by nodes A and B (in the appropriate directions). A failure affecting link i results in both A and B switching to the traffic on link j in the respective directions. Note that some form of signaling is required to ensure that both A and B start receiving traffic from the protection link.
双方向LSPが2つのノードAとBの間のリンクI上にルーティングされているとします。双方向1 1保護下では、作業リンクiを保護するために専用のリンクJが事前に割り当てられます。LSPトラフィックは両方のリンクで永続的に複製され、通常の条件下では、リンクIからのトラフィックはノードAおよびBによって受信されます（適切な方向）。リンクに影響を与える障害Iは、それぞれの方向にリンクJのトラフィックに切り替えるAとBの両方になります。AとBの両方が保護リンクからトラフィックを受信し始めることを確認するために、何らかの形のシグナル伝達が必要であることに注意してください。
The basic steps in 1+1 bi-directional span protection are as follows:
1 1の双方向スパン保護の基本的な手順は次のとおりです。
1. If a node (A or B) detects the failure of the working link (or a degradation of signal quality over the working link), it SHOULD begin receiving on the protection link and send a Switchover Request message reliably to the other node (B or A, respectively). This message SHOULD indicate the identity of the failed working link and provide other relevant information.
1. ノード（aまたはb）が作業リンクの障害（または作業リンクに対する信号品質の分解）を検出した場合、保護リンクで受信し、他のノード（bまたはbまたはbまたはそれぞれA）。このメッセージは、失敗した動作リンクの身元を示し、他の関連情報を提供する必要があります。
2. Upon receipt of the Switchover Request message, a node MUST begin receiving from the protection link and send a Switchover Response message to the other node (A or B, respectively). Because both the working/protect spans are exposed to routing and signaling as a single link, the switchover SHOULD be transparent to routing and signaling.
2. スイッチオーバー要求メッセージを受信すると、ノードは保護リンクから受信を開始し、他のノード（AまたはB）にスイッチオーバー応答メッセージを送信する必要があります。作業/保護スパンの両方がルーティングとシグナリングに単一のリンクとしてさらされているため、スイッチオーバーはルーティングとシグナリングに透過的でなければなりません。
The following functionality is required for 1+1 bi-directional span protection:
1 1の双方向スパン保護には、次の機能が必要です。
o The routing procedures are the same as in 1+1 unidirectional.
o ルーティング手順は、1 1単方向と同じです。
o The signaling procedures are the same as in 1+1 unidirectional.
o シグナル伝達手順は、1 1単方向と同じです。
o In addition to the procedures described in 1+1 (unidirectional), a Switchover Request message MUST be used to signal the Switchover Request. This can be done using LMP [RFC4204]. Note that GMPLS-based mechanisms MAY not be necessary when the underlying span (transport) technology provides such a mechanism.
o 1 1（単方向）に記載されている手順に加えて、スイッチオーバー要求を信号するためにスイッチオーバー要求メッセージを使用する必要があります。これは、LMP [RFC4204]を使用して実行できます。基礎となるスパン（輸送）テクノロジーがそのようなメカニズムを提供する場合、GMPLSベースのメカニズムは必要ない場合があることに注意してください。
Consider two adjacent nodes, A and B. Under 1:1 protection, a dedicated link j between A and B is pre-assigned to protect working link i. Link j may be carrying (pre-emptable) Extra Traffic. A failure affecting link i results in the corresponding LSP(s) being restored to link j. Extra Traffic being routed over link j may need to be pre-empted to accommodate the LSPs that have to be restored.
AとBの2つの隣接するノード、1：1の保護、AとBの間の専用のリンクJが事前に割り当てられ、作業リンクiを保護します。リンクJは、（先制的な）追加のトラフィックを携帯している場合があります。リンクに影響を与える障害Iは、jをリンクするために復元される対応するLSPが復元されます。リンクJを介してルーティングされている余分なトラフィックは、復元する必要があるLSPに対応するために先制する必要がある場合があります。
Once a fault is isolated/localized, the affected LSP(s) must be moved to the protection link. The process of moving an LSP from a failed (working) link to a protection link must be initiated by one of the nodes, A or B. This node is referred to as the "master". The other node is called the "slave". The determination of the master and the slave may be based on configured information or protocol specific requirements.
障害が分離/局所化されると、影響を受けるLSPを保護リンクに移動する必要があります。LSPを失敗した（動作）リンクから保護リンクに移動するプロセスは、ノードAまたはBのいずれかによって開始されなければなりません。このノードは「マスター」と呼ばれます。他のノードは「スレーブ」と呼ばれます。マスターとスレーブの決定は、構成された情報またはプロトコル固有の要件に基づいている場合があります。
The basic steps in dedicated 1:1 span protection (ignoring reversion) are as follows:
専用の1：1スパン保護（復帰を無視）の基本的な手順は次のとおりです。
1. If the master detects/localizes a link failure event, it invokes a process to allocate the protection link to the affected LSP(s).
1. マスターがリンク障害イベントを検出/ローカライズする場合、影響を受けるLSPに保護リンクを割り当てるプロセスを呼び出します。
2. If the slave detects a link failure event, it informs the master of the failure using a failure indication message. The master then invokes the same procedure as (1) to move the LSPs to the protection link. If the protection link is carrying Extra Traffic, the slave stops using the span for the Extra Traffic.
2. スレーブがリンク障害イベントを検出した場合、障害表示メッセージを使用してマスターに障害を通知します。次に、マスターは（1）と同じ手順を呼び出して、LSPを保護リンクに移動します。保護リンクが追加のトラフィックを運んでいる場合、スレーブは余分なトラフィックにスパンを使用して停止します。
3. Once the span protection procedure is invoked in the master, it requests the slave to switch the affected LSP(s) to the protection link. Prior to this, if the protection link is carrying Extra Traffic, the master stops using the span for this traffic (i.e., the traffic is dropped by the master and not forwarded into or out of the protection link).
3. マスターにスパン保護手順が呼び出されると、奴隷に影響を受けるLSPを保護リンクに切り替えるように要求します。これに先立ち、保護リンクが余分なトラフィックを運ぶ場合、マスターはこのトラフィックのスパンの使用を停止します（つまり、マスターによってトラフィックが落とされ、保護リンクに出入りすることはありません）。
4. The slave sends an acknowledgement to the master. Prior to this, the slave stops using the link for Extra Traffic (i.e., the traffic is dropped by the slave and not forwarded into or out of the protection link). It then starts sending the normal traffic on the selected protection link.
4. 奴隷はマスターに謝辞を送ります。これに先立って、奴隷は追加のトラフィックにリンクを使用するのを停止します（つまり、トラフィックは奴隷によって落とされ、保護リンクに出入りすることはありません）。次に、選択した保護リンクで通常のトラフィックの送信を開始します。
5. When the master receives the acknowledgement, it starts sending and receiving the normal traffic over the new link. The switchover of the LSPs is thus completed.
5. マスターが謝辞を受け取ると、新しいリンクを介して通常のトラフィックの送信と受信を開始します。したがって、LSPのスイッチオーバーが完了します。
Note: Although this mechanism implies more traffic dropped than necessary, it is preferred over possible misconnections during the recovery process.
注：このメカニズムは、必要以上に多くのトラフィックが落下することを意味しますが、回復プロセス中に可能な誤った接続よりも好まれます。
From the description above, it is clear that 1:1 span protection may require up to three signaling messages for each failed span: a failure indication message, an LSP Switchover Request message, and an LSP Switchover Response message. Furthermore, it may be possible to switch multiple LSPs from the working span to the protection span simultaneously.
上記の説明から、1：1のスパン保護には、障害表示メッセージ、LSPスイッチオーバーリクエストメッセージ、LSPスイッチオーバー応答メッセージなど、各障害スパンに対して最大3つの信号メッセージが必要になる場合があります。さらに、複数のLSPを作業スパンから保護スパンに同時に切り替えることができる場合があります。
The following functionality is required for dedicated 1:1 span protection:
専用の1：1スパン保護には、次の機能が必要です。
o Pre-emption MUST be supported to accommodate Extra Traffic.
o 追加のトラフィックに対応するために、先制派はサポートする必要があります。
o Routing: A single TE link encompassing both working and protection links is announced with a Link Protection Type "Dedicated 1:1". If Extra Traffic is supported over the protection link, then the bandwidth parameters for the protection link MUST also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms. In other words, the network MUST be configured such that bandwidth at priority X or lower is considered Extra Traffic.
o ルーティング：作業リンクと保護リンクの両方を含む単一のTEリンクが、リンク保護タイプ「専用1：1」で発表されます。保護リンク上で追加のトラフィックがサポートされている場合、保護リンクの帯域幅パラメーターも発表する必要があります。作業と保護リンクの帯域幅の区別は、優先メカニズムを使用して行われます。言い換えれば、優先X以下の帯域幅が追加のトラフィックと見なされるように、ネットワークを構成する必要があります。
If there is a failure on the working link, then the normal traffic is switched to the protection link, pre-empting Extra Traffic if necessary. The bandwidth for the protection link MUST be adjusted accordingly.
作業リンクに障害がある場合、通常のトラフィックは保護リンクに切り替えられ、必要に応じて余分なトラフィックを先取りします。それに応じて、保護リンクの帯域幅を調整する必要があります。
o Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating "Dedicated 1:1" SHOULD be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) SHOULD be used for that LSP. These objects/TLVs are defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy.
o シグナリング：作業リンクにLSPを確立するには、「専用1：1」を示すリンク保護オブジェクト/TLVを、そのLSPのシグナリング要求メッセージに含める必要があります。保護リンクにLSPを確立するには、そのLSPに適切な優先度（余分なトラフィックを示す）を使用する必要があります。これらのオブジェクト/TLVは[RFC3471]で定義されています。リンク保護オブジェクト/TLVが使用されない場合、リンク選択はローカルポリシーの問題です。
o Link management: Both nodes MUST have a consistent view of the link protection association for the spans. This can be done using LMP [RFC4204] or via manual configuration.
o リンク管理：両方のノードには、スパンのリンク保護アソシエーションの一貫したビューが必要です。これは、LMP [RFC4204]または手動構成を使用して実行できます。
o When a link failure is detected at the slave, a failure indication message MUST be sent to the master informing the node of the link failure.
o スレーブでリンク障害が検出された場合、障害表示メッセージをマスターに送信する必要があり、リンク障害のノードに通知する必要があります。
Shared M:N protection is described with respect to two neighboring nodes, A and B. The scenario considered is as follows:
共有M：N保護は、2つの隣接するノード、AとBに関して説明されています。
o At any point in time, there are two sets of links between A and B, i.e., a working set of N (bi-directional) links carrying traffic subject to protection and a protection set of M (bi-directional) links. A protection link may be carrying Extra Traffic. There is no a priori relationship between the two sets of links, but the value of M and N MAY be pre-configured. The specific links in the protection set MAY be pre-configured to be physically diverse to avoid the possibility of failure events affecting a large proportion of protection links (along with working links).
o いつでも、AとBの間に2つのリンクがあります。つまり、保護の対象となるトラフィックを運ぶN（双方向）リンクの作業セットとM（双方向）リンクの保護セットがあります。保護リンクは、余分なトラフィックを運ぶ可能性があります。2つのリンクセット間には先験的な関係はありませんが、MとNの値は事前に構成されている可能性があります。保護セットの特定のリンクは、保護リンクの大部分に影響を与える障害イベントの可能性を回避するために物理的に多様であるように事前に構成されている場合があります（作業リンクとともに）。
o When a link in the working set is affected by a failure, the normal traffic is diverted to a link in the protection set, if such a link is available. Note that such a link might be carrying more than one LSP, e.g., an OC-192 link carrying four STS-48 LSPs.
o 作業セットのリンクが障害の影響を受けると、そのようなリンクが利用可能な場合、通常のトラフィックが保護セットのリンクに迂回されます。このようなリンクは、4つのSTS-48 LSPを運ぶOC-192リンクなど、複数のLSPを搭載している可能性があることに注意してください。
o More than one link in the working set may be affected by the same failure event. In this case, there may not be an adequate number of protection links to accommodate all of the affected traffic carried by failed working links. The set of affected working links that are actually restored over available protection links is then subject to policies (e.g., based on relative priority of working traffic). These policies are not specified in this document.
o 作業セットの複数のリンクが同じ障害イベントの影響を受ける可能性があります。この場合、機能したリンクの失敗によって運ばれるすべての影響を受けるトラフィックに対応するための適切な数の保護リンクがない場合があります。実際に利用可能な保護リンクで復元される影響を受ける作業リンクのセットは、ポリシーの対象となります（たとえば、作業トラフィックの相対的な優先度に基づいて）。これらのポリシーは、このドキュメントでは指定されていません。
o When normal traffic must be diverted from a failed link in the working set to a protection link, the decision as to which protection link is chosen is always made by one of the nodes, A or B. This node is considered the "master" and it is required to both apply any policies and select specific protection links to divert working traffic. The other node is considered the "slave". The determination of the master and the slave MAY be based on configured information, protocol-specific requirements, or as a result of running a neighbor discovery procedure.
o 通常のトラフィックをワーキングセットの失敗したリンクから保護リンクに迂回する必要がある場合、保護リンクが選択されることに関する決定は、常にノードの1つであるAまたはBによって行われます。このノードは「マスター」と見なされ、ポリシーを適用し、特定の保護リンクを選択して、作業トラフィックを迂回する必要があります。他のノードは「スレーブ」と見なされます。マスターとスレーブの決定は、構成された情報、プロトコル固有の要件、または近隣の発見手順を実行した結果として基づいている場合があります。
o Failure events are detected by transport layer mechanisms, if available (e.g., SONET Alarm Indication Signal (AIS)/Remote Defect Indication (RDI)). Since the bi-directional links are formed by a pair of unidirectional links, a failure in the link from A to B is typically detected by B, and a failure in the opposite direction is detected by A. It is possible for a failure to simultaneously affect both directions of the bi-directional link. In this case, A and B will concurrently detect failures, in the B-to-A direction and in the A-to-B direction, respectively.
o 故障イベントは、利用可能な場合は輸送層のメカニズムによって検出されます（例：SONETアラーム表示信号（AIS）/リモート欠陥表示（RDI））。双方向リンクは一方向のリンクによって形成されるため、AからBへのリンクの障害は通常Bによって検出され、反対方向の障害はAによって検出されます。双方向リンクの両方向に影響します。この場合、AとBは、それぞれb-to-a方向とA-b方向で、障害を同時に検出します。
The basic steps in M:N protection (ignoring reversion) are as follows:
M：n保護の基本的な手順（復帰を無視）は次のとおりです。
1. If the master detects a failure of a working link, it autonomously invokes a process to allocate a protection link to the affected traffic.
1. マスターが作業リンクの障害を検出した場合、影響を受けるトラフィックへの保護リンクを割り当てるプロセスを自律的に呼び出します。
2. If the slave detects a failure of a working link, it MUST inform the master of the failure using a failure indication message. The master then invokes the same procedure as above to allocate a protection link. (It is possible that the master has itself detected the same failure, for example, a failure simultaneously affecting both directions of a link.)
2. 奴隷が作業リンクの障害を検出した場合、障害表示メッセージを使用して障害をマスターに通知する必要があります。次に、マスターは上記と同じ手順を呼び出して、保護リンクを割り当てます。（マスター自体が同じ障害を検出した可能性があります。たとえば、リンクの両方の方向に同時に影響する障害が同時に影響します。）
3. Once the master has determined the identity of the protection link, it indicates this to the slave and requests the switchover of the traffic (using a "Switchover Request" message). Prior to this, if the protection link is carrying Extra Traffic, the master stops using the link for this traffic (i.e., the traffic is dropped by the master and not forwarded into or out of the protection link).
3. マスターが保護リンクの身元を決定すると、これをスレーブに示し、トラフィックの切り替えを要求します（「スイッチオーバーリクエスト」メッセージを使用します）。これに先立ち、保護リンクが余分なトラフィックを運ぶ場合、マスターはこのトラフィックのリンクの使用を停止します（つまり、マスターによってトラフィックが落とされ、保護リンクに出入りすることはありません）。
4. The slave sends a "Switchover Response" message back to the master. Prior to this, if the selected protection link is carrying traffic that could be pre-empted, the slave stops using the link for this traffic (i.e., the traffic is dropped by the slave and not forwarded into or out of the protection link). It then starts sending the normal traffic on the selected protection link.
4. スレーブは、「スイッチオーバー応答」メッセージをマスターに送り返します。これに先立ち、選択された保護リンクが先制的なトラフィックを運ぶ場合、奴隷はこのトラフィックのリンクを使用して停止します（つまり、トラフィックは奴隷によって落とされ、保護リンクに出入りしない）。次に、選択した保護リンクで通常のトラフィックの送信を開始します。
5. When the master receives the Switchover Response, it starts sending and receiving the traffic that was previously carried on the now-failed link over the new link.
5. マスターがスイッチオーバー応答を受信すると、以前に新しいリンクを介して販売されていたリンクで以前に運ばれていたトラフィックの送信と受信を開始します。
Note: Although this mechanism implies more traffic dropped than necessary, it is preferred over possible misconnections during the recovery process.
注：このメカニズムは、必要以上に多くのトラフィックが落下することを意味しますが、回復プロセス中に可能な誤った接続よりも好まれます。
From the description above, it is clear that M:N span restoration (involving LSP local recovery) MAY require up to three messages for each working link being switched: a failure indication message, a Switchover Request message, and a Switchover Response message.
上記の説明から、M：N SPANの修復（LSPローカルリカバリを含む）は、障害表示メッセージ、スイッチオーバーリクエストメッセージ、スイッチオーバー応答メッセージのスパンリンクごとに最大3つのメッセージが必要になる場合があります。
The following functionality is required for M:N span restoration:
M：nスパンの復元には、次の機能が必要です。
o Pre-emption MUST be supported to accommodate Extra Traffic.
o 追加のトラフィックに対応するために、先制派はサポートする必要があります。
o Routing: A single TE link encompassing both sets of working and protect links should be announced with a Link Protection Type "Shared M:N". If Extra Traffic is supported over a set of the protection links, then the bandwidth parameters for the set of protection links MUST also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms.
o ルーティング：両方の作業リンクと保護リンクを含む単一のTEリンクは、リンク保護タイプ「共有M：N」で発表する必要があります。保護リンクのセットで追加のトラフィックがサポートされている場合、保護リンクのセットの帯域幅パラメーターも発表する必要があります。作業と保護リンクの帯域幅の区別は、優先メカニズムを使用して行われます。
If there is a failure on a working link, then the affected LSP(s) MUST be switched to a protection link, pre-empting Extra Traffic if necessary. The bandwidth for the protection link MUST be adjusted accordingly.
作業リンクに障害がある場合は、影響を受けるLSPを保護リンクに切り替える必要があり、必要に応じて追加のトラフィックを先取りします。それに応じて、保護リンクの帯域幅を調整する必要があります。
o Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating "Shared M:N" SHOULD be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) SHOULD be used. These objects/TLVs are defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy.
o シグナリング：作業リンクにLSPを確立するには、「共有M：N」を示すリンク保護オブジェクト/TLVを、そのLSPのシグナリング要求メッセージに含める必要があります。保護リンクにLSPを確立するには、適切な優先度（追加のトラフィックを示す）を使用する必要があります。これらのオブジェクト/TLVは[RFC3471]で定義されています。リンク保護オブジェクト/TLVが使用されない場合、リンク選択はローカルポリシーの問題です。
o For link management, both nodes MUST have a consistent view of the link protection association for the links. This can be done using LMP [RFC4204] or via manual configuration.
o リンク管理の場合、両方のノードには、リンクのリンク保護アソシエーションの一貫したビューが必要です。これは、LMP [RFC4204]または手動構成を使用して実行できます。
The following messages are used in local span protection procedures.
次のメッセージは、ローカルスパン保護手順で使用されます。
These messages SHOULD be delivered reliably. Therefore, the protocol mechanisms used to deliver these messages SHOULD provide sequencing, acknowledgement, and retransmission. The protocol SHOULD also handle situations where the message(s) cannot be delivered.
これらのメッセージは確実に配信する必要があります。したがって、これらのメッセージを配信するために使用されるプロトコルメカニズムは、シーケンス、承認、および再送信を提供する必要があります。プロトコルは、メッセージを配信できない状況も処理する必要があります。
The messages described in the following subsections are abstract; their format and encoding will be described in separate documents.
次のサブセクションで説明されているメッセージは要約です。それらの形式とエンコードは、個別のドキュメントで説明されています。
This message is sent from the slave to the master to indicate the identities of one or more failed working links. This message MAY not be necessary when the transport plane technology itself provides for such a notification.
このメッセージは、奴隷からマスターに送信され、1つまたは複数の機能リンクのアイデンティティを示します。このメッセージは、輸送機の技術自体がこのような通知を提供する場合には必要ない場合があります。
The number of links included in the message depends on the number of failures detected within a window of time by the sending node. A node MAY choose to send separate failure indication messages in the interest of completing the recovery for a given link within an implementation-dependent time constraint.
メッセージに含まれるリンクの数は、送信ノードによって時間の窓内で検出された障害の数によって異なります。ノードは、実装依存の時間制約内で特定のリンクの回復を完了するために、個別の障害表示メッセージを送信することを選択できます。
Under bi-directional 1+1 span protection, this message is used to coordinate the selecting function at both nodes. This message originated at the node that detected the failure.
双方向1 1スパン保護の下で、このメッセージは両方のノードで選択関数を調整するために使用されます。このメッセージは、障害を検出したノードで発生しました。
Under dedicated 1:1 and shared M:N span protection, this message is used as an LSP Switchover Request. This message is sent from the master node to the slave node (reliably) to indicate that the LSP(s) on the (failed) working link can be switched to an available protection link. If so, the ID of the protection link, as well as the LSP labels (if necessary), MUST be indicated. These identifiers MUST be consistent with those used in GMPLS signaling.
専用の1：1および共有M：Nスパン保護の下で、このメッセージはLSPスイッチオーバーリクエストとして使用されます。このメッセージは、マスターノードからスレーブノード（確実に）に送信され、（失敗した）作業リンクのLSPが利用可能な保護リンクに切り替えることができることを示します。その場合、保護リンクのIDとLSPラベル（必要に応じて）を示す必要があります。これらの識別子は、GMPLSシグナル伝達で使用されるものと一致する必要があります。
A working link may carry multiple LSPs. Since the normal traffic carried over the working link is switched to the protection link, it MAY be possible for the LSPs on the working link to be mapped to the protection link without re-signaling each individual LSP. For example, if link bundling [RFC4201] is used where the working and protect links are mapped to component links, and the labels are the same on the working and protection links, it MAY be possible to change the component links without needing to re-signal each individual LSP. Optionally, the labels MAY need to be explicitly coordinated between the two nodes. In this case, the Switchover Request message SHOULD carry the new label mappings.
作業リンクは、複数のLSPを運ぶ場合があります。通常のトラフィックが運転リンクを越えて保護リンクに切り替えられるため、作業リンク上のLSPが個々のLSPを再署名せずに保護リンクにマッピングできる場合があります。たとえば、作業リンクと保護リンクがコンポーネントリンクにマッピングされている場合にリンクバンドリング[RFC4201]が使用され、ラベルは動作および保護リンクで同じである場合、再度は再度を変更する必要なくコンポーネントリンクを変更することが可能かもしれません。個々のLSPを通知します。オプションで、ラベルは2つのノード間で明示的に調整する必要がある場合があります。この場合、スイッチオーバー要求メッセージには、新しいラベルマッピングが搭載されている必要があります。
The master may not be able to find protection links to accommodate all failed working links. Thus, if this message is generated in response to a Failure Indication message from the slave, then the set of failed links in the message MAY be a sub-set of the links received in the Failure Indication message. Depending on time constraints, the master may switch the normal traffic from the set of failed links in smaller batches. Thus, a single failure indication message MAY result in the master sending more than one Switchover Request message to the same slave node.
マスターは、失敗したすべての作業リンクに対応するために保護リンクを見つけることができない場合があります。したがって、このメッセージがスレーブからの障害表示メッセージに応じて生成された場合、メッセージ内の故障したリンクのセットは、障害表示メッセージで受信されたリンクのサブセットである可能性があります。時間の制約に応じて、マスターは、故障したリンクのセットから通常のトラフィックを小さなバッチで切り替えることができます。したがって、単一の障害表示メッセージにより、マスターは同じスレーブノードに複数のスイッチオーバー要求メッセージを送信する場合があります。
This message is sent from the slave to the master (reliably) to indicate the completion (or failure) of switchover at the slave. In this message, the slave MAY indicate that it cannot switch over to the corresponding free link for some reason. In this case, the master and slave notify the user (operator) of the failed switchover. A notification of the failure MAY also be used as a trigger in an end-to-end recovery.
このメッセージは、奴隷から（確実に）奴隷からマスターに送信され、奴隷でのスイッチオーバーの完了（または障害）を示します。このメッセージでは、スレーブは、何らかの理由で対応するフリーリンクに切り替えることができないことを示している場合があります。この場合、マスターとスレーブは、失敗したスイッチオーバーをユーザー（オペレーター）に通知します。障害の通知は、エンドツーエンドの回復のトリガーとして使用することもできます。
An unintended connection occurs when traffic from the wrong source is delivered to a receiver. This MUST be prevented during protection switching. This is primarily a concern when the protection link is being used to carry Extra Traffic. In this case, it MUST be ensured that the LSP traffic being switched from the (failed) working link to the protection link is not delivered to the receiver of the pre-empted traffic. Thus, in the message flow described above, the master node MUST disconnect (any) pre-empted traffic on the selected protection link before sending the Switchover Request. The slave node MUST also disconnect pre-empted traffic before sending the Switchover Response. In addition, the master node SHOULD start receiving traffic for the protected LSP from the protection link. Finally, the master node SHOULD start sending protected traffic on the protection link upon receipt of the Switchover Response.
間違ったソースからのトラフィックがレシーバーに配信されると、意図しない接続が発生します。これは、保護の切り替え中に防止する必要があります。これは主に、保護リンクが追加のトラフィックを運ぶために使用されている場合の懸念事項です。この場合、（失敗した）作業リンクから保護リンクへのLSPトラフィックが、先制トラフィックの受信機に配信されないようにする必要があります。したがって、上記のメッセージフローでは、マスターノードは、スイッチオーバーリクエストを送信する前に、選択した保護リンクの（任意の）先制トラフィックを切断する必要があります。スレーブノードは、スイッチオーバー応答を送信する前に、先制的なトラフィックを切断する必要があります。さらに、マスターノードは、保護リンクから保護されたLSPのトラフィックの受信を開始する必要があります。最後に、マスターノードは、スイッチオーバー応答を受け取ると、保護リンクに保護されたトラフィックの送信を開始する必要があります。
End-to-end path protection and restoration refer to the recovery of an entire LSP from the initiator to the terminator. Suppose the primary path of an LSP is routed from the initiator (Node A) to the terminator (Node B) through a set of intermediate nodes.
エンドツーエンドのパス保護と復元は、イニシエーターからターミネーターへのLSP全体の回復を指します。LSPの主要なパスが、中間ノードのセットを介してイニシエーター（ノードA）からターミネーター（ノードB）にルーティングされているとします。
The following subsections describe three previously proposed end-to-end protection schemes and the functional steps needed to implement them.
以下のサブセクションでは、以前に提案されていた3つのエンドツーエンドの保護スキームと、それらを実装するために必要な機能的手順について説明しています。
A dedicated, resource-disjoint alternate path is pre-established to protect the LSP. Traffic is simultaneously sent on both paths and received from one of the functional paths by the end nodes A and B.
LSPを保護するために、専用のリソースディスジョイントの代替パスが事前に確立されています。トラフィックは両方のパスで同時に送信され、エンドノードAとBで機能的なパスの1つから受信されます。
There is no explicit signaling involved with this mode of protection.
この保護モードに関係する明示的なシグナル伝達はありません。
A dedicated, resource-disjoint alternate path is pre-established to protect the LSP. Traffic is simultaneously sent on both paths; under normal conditions, the traffic from the working path is received by nodes A and B (in the appropriate directions). A failure affecting the working path results in both A and B switching to the traffic on the protection path in the respective directions.
LSPを保護するために、専用のリソースディスジョイントの代替パスが事前に確立されています。トラフィックは両方のパスに同時に送信されます。通常の条件下では、作業経路からのトラフィックは、ノードAとB（適切な方向）によって受信されます。作業経路に影響を与える障害により、AとBの両方がそれぞれの方向の保護パスのトラフィックに切り替わります。
Note that this requires coordination between the end nodes to switch to the protection path.
これには、保護パスに切り替えるためにエンドノード間の調整が必要であることに注意してください。
The basic steps in bi-directional 1+1 path protection are as follows:
双方向1 1パス保護の基本的な手順は次のとおりです。
o Failure detection: There are two possibilities for this.
o 障害検出：これには2つの可能性があります。
1. A node in the working path detects a failure event. Such a node MUST send a Failure Indication message toward the upstream or/and downstream end node of the LSP (node A or B). This message MAY be forwarded along the working path or routed over a different path if the network has general routing intelligence.
1. 作業パスのノードは、障害イベントを検出します。このようなノードは、LSP（ノードAまたはB）の上流または下流のエンドノードに向けて障害表示メッセージを送信する必要があります。このメッセージは、ネットワークに一般的なルーティングインテリジェンスがある場合、作業経路に沿って転送されるか、異なるパス上に配線される場合があります。
Mechanisms provided by the data transport plane MAY also be used for this, if available.
データ輸送機によって提供されるメカニズムも、利用可能な場合、これに使用できます。
2. The end nodes (A or B) detect the failure themselves (e.g., loss of signal).
2. 末端ノード（aまたはb）は、障害自体を検出します（たとえば、信号の喪失）。
o Switchover: The action taken when an end node detects a failure in the working path is as follows: Start receiving from the protection path; at the same time, send a Switchover Request message to the other end node to enable switching at the other end.
o スイッチオーバー：エンドノードが作業経路の障害を検出したときに実行されるアクションは次のとおりです。保護パスから受信を開始します。同時に、もう一方の端での切り替えを有効にするために、もう一方の端ノードにスイッチオーバー要求メッセージを送信します。
The action taken when an end node receives a Switchover Request message is as follows:
エンドノードがスイッチオーバー要求メッセージを受信したときに実行されるアクションは次のとおりです。
- Start receiving from the protection path; at the same time, send a Switchover Response message to the other end node.
- 保護パスから受信を開始します。同時に、もう一方のエンドノードにスイッチオーバー応答メッセージを送信します。
GMPLS signaling mechanisms MAY be used to (reliably) signal the Failure Indication message, as well as the Switchover Request and Response message. These messages MAY be forwarded along the protection path if no other routing intelligence is available in the network.
GMPLSシグナリングメカニズムを使用して、障害表示メッセージとスイッチオーバーリクエストと応答メッセージを（確実に）信号することができます。これらのメッセージは、ネットワークで他のルーティングインテリジェンスが利用できない場合、保護パスに沿って転送される場合があります。
LSP Identifier: A unique identifier for each LSP. The LSP identifier is within the scope of the Source ID and Destination ID.
LSP識別子：各LSPの一意の識別子。LSP識別子は、ソースIDおよび宛先IDの範囲内にあります。
Source ID: ID of the source (e.g., IP address).
ソースID：ソースのID（例：IPアドレス）。
Destination ID: ID of the destination (e.g., IP address).
宛先ID：宛先のID（例：IPアドレス）。
Each node that is on the working or protection path of an LSP MUST have knowledge of the LSP identifier. If the network does not provide routing intelligence, nodal information MAY also include previous and next nodes in the LSP so that restoration-related messages can be forwarded properly. When the network provides general routing intelligence, messages MAY be forwarded along paths other than that of the LSP.
LSPの動作または保護パス上にある各ノードには、LSP識別子の知識が必要です。ネットワークがルーティングインテリジェンスを提供していない場合、Nodal情報はLSPに以前のノードと次のノードを含めることができ、復元関連のメッセージを適切に転送できるようにすることもできます。ネットワークが一般的なルーティングインテリジェンスを提供する場合、メッセージはLSP以外のパスに沿って転送される場合があります。
At the end-point nodes, the working and protection paths MUST be associated. The association of these paths MAY be either provisioned using signaling or MAY be configured when LSP provisioning does not involve signaling (e.g., provisioning through a management system). The related association information MUST remain until the LSP is explicitly de-provisioned.
エンドポイントノードでは、作業および保護パスを関連付ける必要があります。これらのパスの関連付けは、シグナリングを使用してプロビジョニングされるか、LSPプロビジョニングにシグナリング（たとえば、管理システムを介したプロビジョニング）が含まれない場合に構成される場合があります。関連する関連情報は、LSPが明示的に解除されるまで残る必要があります。
This message is sent (reliably) by an intermediate node toward the source of an LSP. For instance, such a node might have attempted local span protection and failed. This message MAY not be necessary if the data transport layer provides mechanisms for the notification of LSP failure by the endpoints (i.e., if LSP endpoints are co-located with a corresponding data (transport) maintenance/recovery domain).
このメッセージは、LSPのソースに向かって中間ノードによって（確実に）送信されます。たとえば、このようなノードはローカルスパン保護を試みて失敗した可能性があります。データトランスポートレイヤーがエンドポイントによるLSP障害の通知のメカニズムを提供する場合（つまり、LSPエンドポイントが対応するデータ（輸送）メンテナンス/回復ドメインと共同で配置されている場合）。
Consider a node that detects a link failure. The node MUST determine the identities of all LSPs that are affected by the failure of the link and send an End-to-End Failure Indication message to the source of each LSP. For scalability reasons, Failure Indication messages MAY contain the identity and the status of multiple LSPs rather than a single one. Each intermediate node receiving such a message MUST forward the message to the appropriate next node such that the message would ultimately reach the LSP source. However, there is no requirement that this message flows toward the source along the same path as the failed LSP. Furthermore, if an intermediate node is itself generating a Failure Indication message, there SHOULD be a mechanism to suppress all but one source of Failure Indication messages. Finally, the Failure Indication message MUST be sent reliably from the node detecting the failure to the LSP source. Reliability MAY be achieved, for example, by retransmitting the message until an acknowledgement is received. However, retransmission of Failure Indication messages SHOULD not cause further message drops. This MAY be achieved through the appropriate configuration and use of congestion and flow control mechanisms.
リンク障害を検出するノードを検討してください。ノードは、リンクの障害によって影響を受けるすべてのLSPのアイデンティティを決定し、各LSPのソースにエンドツーエンドの障害表示メッセージを送信する必要があります。スケーラビリティの理由により、障害表示メッセージには、単一のLSPではなく複数のLSPのアイデンティティとステータスが含まれる場合があります。このようなメッセージを受信する各中間ノードは、メッセージが最終的にLSPソースに到達するように、適切な次のノードにメッセージを転送する必要があります。ただし、このメッセージが失敗したLSPと同じパスに沿ってソースに向かって流れるという要件はありません。さらに、中間ノード自体が障害表示メッセージを生成している場合、1つの障害表示メッセージを除くすべてのソースを抑制するメカニズムがあるはずです。最後に、障害表示メッセージは、LSPソースへの障害を検出するノードから確実に送信する必要があります。たとえば、謝辞が受信されるまでメッセージを再送信することにより、信頼性を達成できます。ただし、障害表示メッセージの再送信は、メッセージのドロップをさらに引き起こすことはありません。これは、輻輳およびフロー制御メカニズムの適切な構成と使用によって達成される場合があります。
This message is sent by the source node to acknowledge the receipt of an End-to-End Failure Indication message. This message is sent to the originator of the Failure Indication message. The Acknowledge message SHOULD be sent for each Failure Indication Message received. Each intermediate node receiving the Failure Acknowledgement message MUST forward it toward the destination of the message. However, there is no requirement that this message flows toward the destination along the same path as the failed LSP.
このメッセージは、エンドツーエンドの障害表示メッセージの受信を確認するために、ソースノードによって送信されます。このメッセージは、障害表示メッセージのオリジネーターに送信されます。承認メッセージは、受信した各障害表示メッセージに対して送信する必要があります。障害承認メッセージを受信する各中間ノードは、メッセージの宛先に転送する必要があります。ただし、このメッセージが失敗したLSPと同じパスに沿って宛先に向かって流れるという要件はありません。
This message MAY not be required if other means of ensuring reliable message delivery are used.
信頼できるメッセージ配信を保証する他の手段が使用される場合、このメッセージは必要ない場合があります。
This message is generated by the source node receiving an indication of failure in an LSP. It is sent to the LSP destination, and it carries the identifier of the LSP being restored. The End-to-End Switchover Request message MUST be sent reliably from the source to the destination of the LSP.
このメッセージは、LSPでの障害の表示を受信するソースノードによって生成されます。LSPの宛先に送られ、復元されているLSPの識別子を運びます。エンドツーエンドのスイッチオーバー要求メッセージは、ソースからLSPの宛先に確実に送信する必要があります。
This message is sent by the destination node receiving an End-to-End Switchover Request message toward the source of the LSP. This message SHOULD identify the LSP being switched over. This message MUST be transmitted in response to each End-to-End Switchover Request message received and MAY indicate either a positive or negative outcome.
このメッセージは、LSPのソースに向かってエンドツーエンドのスイッチオーバー要求メッセージを受信する宛先ノードによって送信されます。このメッセージは、LSPが切り替えられていることを識別する必要があります。このメッセージは、受信した各エンドツーエンドのスイッチオーバー要求メッセージに応じて送信する必要があり、肯定的または否定的な結果を示す場合があります。
Shared mesh restoration refers to schemes under which protection paths for multiple LSPs share common link and node resources. Under these schemes, the protection capacity is pre-reserved, i.e., link capacity is allocated to protect one or more LSPs, but explicit action is required to instantiate a specific protection LSP. This requires restoration signaling along the protection path. Typically, the protection capacity is shared only amongst LSPs whose working paths are physically diverse. This criterion can be enforced when provisioning the protection path. Specifically, provisioning-related signaling messages may carry information about the working path to nodes along the protection path. This can be used as call admission control to accept/reject connections along the protection path based on the identification of the resources used for the primary path.
共有メッシュの復元とは、複数のLSPの保護パスが共通リンクとノードリソースを共有するスキームを指します。これらのスキームでは、保護能力は事前に予約されています。つまり、リンク容量は1つ以上のLSPを保護するために割り当てられますが、特定の保護LSPをインスタンス化するには明示的なアクションが必要です。これには、保護パスに沿った修復信号が必要です。通常、保護能力は、作業経路が物理的に多様であるLSPの間でのみ共有されます。この基準は、保護パスをプロビジョニングするときに実施することができます。具体的には、プロビジョニング関連のシグナリングメッセージは、保護パスに沿ってノードへの作業パスに関する情報を伝える場合があります。これは、プライマリパスに使用されるリソースの識別に基づいて、保護パスに沿って接続を受け入れる/拒否するコール入学制御として使用できます。
Thus, shared mesh restoration is designed to protect an LSP after a single failure event, i.e., a failure that affects the working path of at most one LSP sharing the protection capacity. It is possible that a protection path may not be successfully activated when multiple, concurrent failure events occur. In this case, shared mesh restoration capacity may be claimed for more than one failed LSP and the protection path can be activated only for one of them (at most).
したがって、共有メッシュの復元は、単一の障害イベントの後にLSPを保護するように設計されています。つまり、保護能力を共有する最大1つのLSPの作業経路に影響する障害です。複数の同時障害イベントが発生したときに、保護パスが正常にアクティブ化されない可能性があります。この場合、共有メッシュの修復能力は複数のLSPで故障した場合に請求される場合があり、保護パスはそのうちの1つ（せいぜい）でのみアクティブになります。
For implementing shared mesh restoration, the identifier and nodal information related to signaling along the control path are as defined for 1+1 protection in Sections 3.2.1 and 3.2.2. In addition, each node MUST also keep (local) information needed to establish the data plane of the protection path. This information MUST indicate the local resources to be allocated, the fabric cross-connect to be established to activate the path, etc. The precise nature of this information would depend on the type of node and LSP (the GMPLS signaling document describes different type of switches [RFC3471]). It would also depend on whether the information is fine or coarse-grained. For example, fine-grained information would indicate pre-selection of all details pertaining to protection path activation, such as outgoing link, labels, etc. Coarse-grained information, on the other hand, would allow some details to be determined during protection path activation. For example, protection resources may be pre-selected at the level of a TE link, while the selection of the specific component link and label occurs during protection path activation.
共有メッシュの復元を実装するために、コントロールパスに沿ったシグナリングに関連する識別子およびノード情報は、セクション3.2.1および3.2.2で1 1保護に対して定義されています。さらに、各ノードは、保護パスのデータプレーンを確立するために必要な（ローカル）情報を保持する必要があります。この情報は、割り当てられるローカルリソース、パスをアクティブにするために確立される生地の相互接続を示す必要があります。この情報の正確な性質は、ノードとLSPのタイプに依存します（GMPLSシグナル伝達ドキュメントは、異なるタイプのタイプを説明します。スイッチ[RFC3471]）。また、情報が問題であるか粗粒であるかにも依存します。たとえば、細粒の情報は、発信リンク、ラベルなどの保護パスのアクティブ化に関するすべての詳細の事前選択を示します。一方、粗粒の情報は、保護パス中にいくつかの詳細を決定できるようにします。活性化。たとえば、保護リソースはTEリンクのレベルで事前に選択される場合がありますが、特定のコンポーネントリンクとラベルの選択は保護パスの活性化中に発生します。
While the coarser specification allows some flexibility in the selection of the precise resource to activate, it also adds complexity in decision making and signaling during the time-critical restoration phase. Furthermore, the procedures for the assignment of bandwidth to protection paths MUST take into account the total resources in a TE link so that single-failure survivability requirements are satisfied.
粗い仕様により、正確なリソースの選択がアクティブになる柔軟性が可能になりますが、時間批判的な回復段階での意思決定と信号の複雑さも追加されます。さらに、保護パスへの帯域幅の割り当ての手順は、単一の潜入の生存性要件が満たされるように、TEリンクの総リソースを考慮する必要があります。
The End-to-End failure indication and acknowledgement procedures and messages are as defined in Sections 3.2.3 and 3.2.4.
エンドツーエンドの障害の表示および承認手順とメッセージは、セクション3.2.3および3.2.4で定義されています。
This message is generated by the source node receiving an indication of failure in an LSP. It is sent to the LSP destination along the protection path, and it identifies the LSP being restored. If any intermediate node is unable to establish cross-connects for the protection path, then it is desirable that no other node in the path establishes cross-connects for the path. This would allow shared mesh restoration paths to be efficiently utilized.
このメッセージは、LSPでの障害の表示を受信するソースノードによって生成されます。保護パスに沿ってLSP宛先に送られ、復元されているLSPを識別します。中間ノードが保護パスのクロスコネクトを確立できない場合、パス内の他のノードがパスのクロスコネクトを確立することはないことが望ましいです。これにより、共有メッシュの復元パスを効率的に利用できます。
The End-to-End Switchover message MUST be sent reliably from the source to the destination of the LSP along the protection path.
エンドツーエンドのスイッチオーバーメッセージは、保護パスに沿ってLSPの宛先にソースから確実に送信する必要があります。
This message is sent by the destination node receiving an End-to-End Switchover Request message toward the source of the LSP, along the protection path. This message SHOULD identify the LSP that is being switched over. Prior to activating the secondary bandwidth at each hop along the path, Extra Traffic (if used) MUST be dropped and not forwarded.
このメッセージは、保護パスに沿って、LSPのソースに向かってエンドツーエンドのスイッチオーバー要求メッセージを受信する宛先ノードによって送信されます。このメッセージは、切り替えられているLSPを識別する必要があります。パスに沿った各ホップで二次帯域幅をアクティブにする前に、追加のトラフィック（使用する場合）を落とし、転送しない必要があります。
This message MUST be transmitted in response to each End-to-End Switchover Request message received.
このメッセージは、受信した各エンドツーエンドのスイッチオーバー要求メッセージに応じて送信する必要があります。
Reversion refers to the process of moving an LSP back to the original working path after a failure is cleared and the path is repaired. Reversion applies both to local span and end-to-end path-protected LSPs. Reversion is desired for the following reasons. First, the protection path may not be optimal in comparison to the working path from a routing and resource consumption point of view. Second, moving an LSP to its working path allows the protection resources to be used to protect other LSPs. Reversion has the disadvantage of causing a second service disruption. Use of reversion is at the option of the operator. Reversion implies that a working path remains allocated to the LSP that was originally routed over it, even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption to the customer. This can be achieved using a "bridge-and-switch" approach (often referred to as make-before-break).
復帰とは、障害がクリアされ、パスが修復された後、LSPを元の作業経路に戻すプロセスを指します。復帰は、ローカルスパンとエンドツーエンドのパス保護LSPの両方に適用されます。以下の理由により、復帰が望まれます。まず、ルーティングおよびリソース消費の観点からの作業経路と比較して、保護パスが最適ではない場合があります。第二に、LSPをその作業経路に移動すると、保護リソースを使用して他のLSPを保護できます。復帰には、2番目のサービスの混乱を引き起こすという欠点があります。復帰の使用は、オペレーターのオプションにあります。復帰は、作業経路が失敗後でも元々それを越えてルーティングされていたLSPに割り当てられたままであることを意味します。顧客への最小限のサービス破壊で復帰を実行できるメカニズムを持つことが重要です。これは、「ブリッジアンドスイッチ」アプローチ（多くの場合、ブレイク前と呼ばれることが多い）を使用して実現できます。
The basic steps involved in bridge-and-switch are as follows:
橋とスイッチに伴う基本的な手順は次のとおりです。
1. The source node commences the process by "bridging" the normal traffic onto both the working and the protection paths (or links in the case of span protection).
1. ソースノードは、作業パスと保護パス（またはスパン保護の場合のリンク）の両方に通常のトラフィックを「ブリッジ」することにより、プロセスを開始します。
2. Once the bridging process is complete, the source node sends a Bridge and Switch Request message to the destination, identifying the LSP and other information necessary to perform reversion. Upon receipt of this message, the destination selects the traffic from the working path. At the same time, it bridges the transmitted traffic onto both the working and protection paths.
2. ブリッジングプロセスが完了すると、ソースノードはブリッジとスイッチリクエストメッセージを宛先に送信し、リバージョンを実行するために必要なLSPとその他の情報を識別します。このメッセージを受け取ると、宛先は作業経路からトラフィックを選択します。同時に、送信されたトラフィックを作業経路と保護パスの両方に橋渡しします。
3. The destination then sends a Bridge and Switch Response message to the source confirming the completion of the operation.
3. 次に、宛先は、操作の完了を確認するブリッジとスイッチの応答メッセージをソースに送信します。
4. When the source receives this message, it switches to receive from the working path, and stops transmitting traffic on the protection path. The source then sends a Bridge and Switch Completed message to the destination confirming that the LSP has been reverted.
4. ソースがこのメッセージを受信すると、作業経路から受信するように切り替え、保護パスでトラフィックの送信を停止します。その後、ソースはブリッジを送信し、LSPが戻っていることを確認して、完成したメッセージを目的地に切り替えます。
5. Upon receipt of this message, the destination stops transmitting along the protection path and de-activates the LSP along this path. The de-activation procedure should remove the crossed connections along the protection path (and frees the resources to be used for restoring other failures).
5. このメッセージを受け取ると、目的地は保護パスに沿って送信するのを停止し、このパスに沿ってLSPを解除します。脱アクティベーション手順は、保護パスに沿って交差した接続を削除する必要があります（そして、他の障害を復元するために使用するリソースを解放します）。
Administrative procedures other than reversion include the ability to force a switchover (from working to protection or vice versa) and locking out switchover, i.e., preventing an LSP from moving from working to protection administratively. These administrative conditions have to be supported by signaling.
復帰以外の管理手順には、スイッチオーバー（作業から保護、またはその逆」を強制し、スイッチオーバーのロックアウト、つまり、LSPが行政上の作業から保護に移行するのを防ぐ能力が含まれます。これらの管理条件は、シグナリングによってサポートされる必要があります。
Under span protection, a failure event could affect more than one working link and there could be fewer protection links than the number of failed working links. Furthermore, a working link may contain multiple LSPs of varying priority. Under this scenario, a decision must be made as to which working links (and therefore LSPs) should be protected. This decision MAY be based on LSP priorities.
SPAN保護下では、障害イベントは複数の作業リンクに影響を与える可能性があり、動作リンクの失敗の数よりも保護リンクが少ない可能性があります。さらに、作業リンクには、さまざまな優先度の複数のLSPが含まれる場合があります。このシナリオでは、どの作業リンク（したがってLSP）を保護するかについて決定を下す必要があります。この決定は、LSPの優先順位に基づいている場合があります。
In general, a node might detect failures sequentially, i.e., all failed working links may not be detected simultaneously, but only sequentially. In this case, as per the proposed signaling procedures, LSPs on a working link MAY be switched over to a given protection link, but another failure (of a working link carrying higher priority LSPs) may be detected soon afterward. In this case, the new LSPs may bump the ones previously switched over the protection link.
一般に、ノードは障害を順番に検出する可能性があります。つまり、すべての失敗した動作リンクは同時に検出されない可能性がありますが、順次のみが検出される場合があります。この場合、提案されたシグナル伝達手順に従って、作業リンク上のLSPは特定の保護リンクに切り替えることができますが、その後すぐに（より高い優先度の高いLSPを運営する作業リンクの）別の障害が検出される場合があります。この場合、新しいLSPは、以前に保護リンク上に切り替えられたものにぶつかる可能性があります。
In the case of end-to-end shared mesh restoration, priorities MAY be implemented for allocating shared link resources under multiple failure scenarios. As described in Section 3.3, more than one LSP can claim shared resources under multiple failure scenarios. If such resources are first allocated to a lower-priority LSP, they MAY have to be reclaimed and allocated to a higher-priority LSP.
エンドツーエンドの共有メッシュの復元の場合、複数の障害シナリオで共有リンクリソースを割り当てるための優先順位が実装される場合があります。セクション3.3で説明されているように、複数のLSPが複数の障害シナリオで共有リソースを請求できます。そのようなリソースが最初に優先度の低いLSPに割り当てられた場合、それらを回収してより優先順位のLSPに割り当てる必要があるかもしれません。
There are a number of security threats that MAY be experienced due to the exchange of messages and information, as detailed in this document. Some examples include interception, spoofing, modification, and replay of control messages. Therefore, the following security requirements are applicable to the mechanisms of this document.
このドキュメントで詳述されているように、メッセージと情報の交換により経験される可能性のある多くのセキュリティの脅威があります。いくつかの例には、コントロールメッセージの傍受、スプーフィング、変更、およびリプレイが含まれます。したがって、次のセキュリティ要件は、このドキュメントのメカニズムに適用できます。
o Signaling MUST be able to provide authentication, integrity, and protection against replay attacks.
o シグナリングは、リプレイ攻撃に対する認証、完全性、保護を提供できる必要があります。
o Privacy and confidentiality are not required. Only authentication is required to ensure that the signaling messages are originating from the right place and have not been modified in transit.
o プライバシーと機密性は必要ありません。信号メッセージが適切な場所から発信され、輸送中に変更されていないことを確認するには、認証のみが必要です。
o Protection of the identity of the data plane end-points (in Failure Indication messages) is not required
o データプレーンのエンドポイント（障害表示メッセージ）のIDの保護は必要ありません
The consequences of poorly secured protection may increase the risk of triggering recovery actions under false Failure Indication messages, including LSP identifiers that are not under failure. Such information could subsequently trigger the initiation of "false" recovery actions while there are no reasons to do so. Additionally, if the identification of the LSP is tampered with from a Failure Indication message, recovery actions will involve nodes for which the LSPs do not indicate any failure condition or for which no Failure Indication message has been received. The consequences of such actions is unpredictable and MAY lead to de-synchronisation between the control and the data plane, as well as increase the risk of misconnections. Moreover, the consequences of poorly applied protection may increase the risk of misconnection. In particular, when Extra Traffic is involved, it is easily possible to deliver the wrong traffic to the wrong destination. Similarly, an intrusion that sets up what appears to be a valid protection LSP and then causes a fault may be able to divert traffic.
保護が不十分な保護の結果は、故障していないLSP識別子を含む、虚偽の障害表示メッセージの下で回復アクションをトリガーするリスクを高める可能性があります。そのような情報は、その後、「誤った」回復アクションの開始を引き起こす可能性がありますが、その理由はありません。さらに、LSPの識別が障害表示メッセージから改ざんされている場合、回復アクションには、LSPが障害条件を示さないノード、または障害表示メッセージが受信されていないノードが含まれます。このようなアクションの結果は予測不可能であり、コントロールとデータプレーンの間の脱結節につながり、誤解のリスクを高める可能性があります。さらに、適用が不十分な保護の結果は、誤解のリスクを高める可能性があります。特に、余分なトラフィックが関与する場合、間違ったトラフィックを間違った目的地に届けることが簡単に可能になります。同様に、有効な保護LSPと思われるものを設定し、障害を引き起こす侵入は、トラフィックを転用できる可能性があります。
Moreover, tampering with a routing information exchange may also have an effect on traffic engineering. Therefore, any mechanisms used for securing and authenticating the transmission of routing information SHOULD be applied in the present context.
さらに、ルーティング情報交換を改ざんすることも、トラフィックエンジニアリングに影響を与える可能性があります。したがって、ルーティング情報の送信を保護および認証するために使用されるメカニズムは、現在のコンテキストで適用する必要があります。
This document was the product of many individuals working together in the CCAMP WG Protection and Restoration design team. The following are the authors that contributed to this document:
このドキュメントは、CCAMP WG保護および修復設計チームで一緒に働く多くの個人の産物でした。以下は、この文書に貢献した著者です。
Deborah Brungard (AT&T) 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラ・ブランガード（AT＆T）200 S.ローレルアベニュー、ミドルタウン、ニュージャージー州07748、米国
EMail: dbrungard@att.com
Sudheer Dharanikota
Sudheer Dharanikota
EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos) 223 East De La Guerra Street Santa Barbara, CA 93101, USA
ジョナサンP.ラング（ソノス）223イーストデラゲラストリートサンタバーバラ、カリフォルニア州93101、米国
EMail: jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
広州Li（AT＆T）180パークアベニュー、フローハムパーク、ニュージャージー州07932、米国
EMail: gli@research.att.com
Eric Mannie
エリック・マニー
EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou（Alcatel）Francis Wellesplein、1 B-2018 Antwerpen、ベルギー
EMail: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan
Microsoft India Development Center
Hyderabad, India
EMail: balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
Yakov Rekhter（ジュニパー）1194 N. Mathilda Avenue Sunnyvale、CA 94089、米国
EMail: yakov@juniper.net
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4205] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、ed。およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、2005年10月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[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、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の回復（保護および回復）用語」、RFC 4427、2006年3月。
Editors' Addresses
編集者のアドレス
Jonathan P. Lang Sonos, Inc. 223 East De La Guerra Street Santa Barbara, CA 93101
ジョナサンP.ラングソノス社223イーストデラゲラストリートサンタバーバラ、カリフォルニア93101
EMail: jplang@ieee.org
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
Bala Rajagopalan Microsoft India Development Center Hyderabad、インド
Ph: +91-40-5502-7423
EMail: balar@microsoft.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellesplein、1 B-2018 Antwerpen、ベルギー
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。