[要約] RFC 5818は、リンク管理プロトコルのためのデータチャネルの状態確認拡張に関するものです。このRFCの目的は、データチャネルの状態を確認するための拡張機能を提供することです。
Internet Engineering Task Force (IETF) D. Li
Request for Comments: 5818 H. Xu
Category: Standards Track Huawei
ISSN: 2070-1721 S. Bardalai
Fujitsu
J. Meuric
France Telecom
D. Caviglia
Ericsson
April 2010
Data Channel Status Confirmation Extensions for the Link Management Protocol
リンク管理プロトコルのデータチャネルステータス確認拡張機能
Abstract
概要
This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
このドキュメントでは、リンク管理プロトコル（LMP）への簡単な追加を定義して、隣接するラベルスイッチングルーター（LSR）がデータチャネルのステータスを確認し、管理に通知するトリガーを提供することにより、ストランドリソースの位置を支援できるコントロールプレーンツールを提供します。矛盾が見つかった場合は平面。LMPはすでにデータプレーンの接続を検証するために使用されているため、この機能をサポートするための適切な候補であると考えられています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5818.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5818で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................4
3. Problem Explanation .............................................4
3.1. Mismatch Caused by Manual Configuration ....................4
3.2. Mismatch Caused by LSP Deletion ............................5
3.3. Failed Resources ...........................................6
4. Motivation ......................................................6
5. Extensions to LMP ...............................................7
5.1. Confirm Data Channel Status Messages .......................7
5.1.1. ConfirmDataChannelStatus Messages ...................8
5.1.2. ConfirmDataChannelStatusAck Messages ................8
5.1.3. ConfirmDataChannelStatusNack Messages ...............8
5.2. Data Channel Status Subobject ..............................9
5.3. Message Construction ......................................10
5.4. Backward Compatibility ....................................10
6. Procedures .....................................................11
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
8.1. LMP Message Types .........................................12
8.2. LMP Data Link Object Subobject ............................13
8.3. LMP Error_Code Class Type .................................13
9. Acknowledgments ................................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Contributor's Address .............................................14
Generalized Multiprotocol Label Switching (GMPLS) networks are constructed from Traffic Engineering (TE) links connecting Label Switching Routers (LSRs). The TE links are constructed from a set of data channels. In this context, a data channel corresponds to a resource label in a non-packet technology (such as a timeslot or a lambda).
一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークは、ラベルスイッチングルーター（LSR）を接続するトラフィックエンジニアリング（TE）リンクから構築されています。TEリンクは、一連のデータチャネルから構成されています。これに関連して、データチャネルは、パケット以外のテクノロジー（タイムスロットやラムダなど）のリソースラベルに対応します。
A data channel status mismatch exists if the LSR at one end of a TE link believes that the data channel is assigned to carry data, but the LSR at the other end does not. The term "ready to carry data" means cross-connected or bound to an end-point for the receipt or delivery of data.
TEリンクの一方の端にあるLSRがデータチャネルがデータをキャリーするように割り当てられていると考えているが、もう一方の端のLSRはそうではない場合、データチャネルステータスの不一致が存在します。「データをキャリーする準備ができている」という用語は、データの受領または配信のために相互接続またはエンドポイントにバインドされることを意味します。
Data channel mismatches cannot be detected from the TE information advertised by the routing protocols [RFC4203], [RFC5307]. The existence of some data channel mismatch problems may be detected by a mismatch in the advertised bandwidths where bidirectional TE links and bidirectional services are in use. However, where unidirectional services exist, or where multiple data channel mismatches occur, it is not possible to detect such errors through the routing protocol-advertised TE information. In any case, there is no mechanism to isolate the mismatches by determining which data channels are at fault.
データチャネルの不一致は、ルーティングプロトコル[RFC4203]、[RFC5307]によって宣伝されているTE情報から検出できません。いくつかのデータチャネルの不一致の問題の存在は、双方向のTEリンクと双方向サービスが使用されている広告帯域幅の不一致によって検出される場合があります。ただし、単方向サービスが存在する場合、または複数のデータチャネルの不一致が発生する場所では、ルーティングプロトコルが広告されたTE情報を介してそのようなエラーを検出することはできません。いずれにせよ、どのデータチャネルが故障しているかを決定することにより、不一致を分離するメカニズムはありません。
If a data channel mismatch exists, any attempt to use the data channel for a new Label Switched Path (LSP) will fail. One end of the TE link may attempt to assign the TE link for use, but the other end will report the data channel as unavailable when the control plane or management plane attempts to assign it to an LSP.
データチャネルの不一致が存在する場合、新しいラベルスイッチ付きパス（LSP）にデータチャネルを使用しようとすると、失敗します。TEリンクの一方の端は、使用のためにTEリンクを割り当てようとする場合がありますが、もう一方の端は、コントロールプレーンまたは管理プレーンがLSPに割り当てようとする場合、データチャネルを利用できないと報告します。
Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up. When many LSPs are to be set up, and when there are many data channel mismatches, such inefficiencies become significant. It is desirable to avoid the additional signaling overhead, and to report the problems to the management plane so that they can be resolved to improve the efficiency of LSP setup.
このような状況は、GMPLSシグナル伝達[RFC3473]で許容可能なラベルセットオブジェクトを使用して解決できますが、セットアップされた各LSPの追加のシグナリング交換が必要になる可能性があるため、このような手順は非効率的です。多くのLSPがセットアップされ、多くのデータチャネルの不一致がある場合、そのような非効率性が重要になります。追加のシグナリングオーバーヘッドを回避し、問題を管理プレーンに報告して、LSPセットアップの効率を改善するために解決できるようにすることが望ましいです。
Correspondingly, such a mismatch situation may give rise to misconnections in the data plane, especially when LSPs are set up using management plane operations.
それに対応して、このような不一致の状況は、特に管理プレーンの操作を使用してLSPが設定されている場合、データプレーンの誤接続を引き起こす可能性があります。
Resources (data channels) that are in a mismatched state are often described as "stranded resources". They are not in use for any LSP, but they cannot be assigned for use by a new LSP because they appear to be in use. Although it is theoretically possible for management plane applications to audit all network resources to locate stranded resources and to release them, this process is rarely performed because of the difficulty of coordinating different Element Management Systems (EMSs) and the associated risks of accidentally releasing in-use resources. It is desirable to have a control plane mechanism that detects and reports stranded resources.
不一致の状態にあるリソース（データチャネル）は、しばしば「立ち往生したリソース」と呼ばれます。それらはいかなるLSPでも使用されていませんが、それらが使用されているように見えるため、新しいLSPで使用するために割り当てることはできません。管理プレーンアプリケーションがすべてのネットワークリソースを監査して、ストランドリソースを見つけてそれらをリリースすることは理論的には可能ですが、このプロセスは、異なる要素管理システム（EMSS）を調整するのが難しく、偶然にリリースされる関連するリスクが誤っているため、このプロセスはめったに実行されません。リソースを使用します。立ち往生したリソースを検出および報告するコントロールプレーンメカニズムを持つことが望ましいです。
This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
このドキュメントでは、Link Management Protocol（LMP）[RFC4204]への簡単な追加を定義して、隣接するLSRがデータチャネルステータスを確認し、管理プレーンに通知するトリガーを提供できるようにすることで、ストランドリソースの位置を支援できる制御プレーンツールを提供します。不一致が見つかりました。LMPはすでにデータプレーンの接続を検証するために使用されているため、この機能をサポートするための適切な候補であると考えられています。
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]に記載されているように解釈される。
Examples of data channel mismatches are described in the following three scenarios.
データチャネルの不一致の例については、次の3つのシナリオで説明しています。
In all of the scenarios, the specific channel resource of a data link will be unavailable because of the data channel status mismatch, and this channel resource will be wasted. Furthermore, a data channel status mismatch may reduce the possibility of successful LSP establishment, because a data channel status mismatch may result in failure when establishing an LSP.
すべてのシナリオで、データチャネルステータスの不一致のためにデータリンクの特定のチャネルリソースが利用できなくなり、このチャネルリソースは無駄になります。さらに、データチャネルステータスの不一致がLSPを確立するときに障害につながる可能性があるため、データチャネルステータスの不一致により、LSP確立の成功の可能性が低下する可能性があります。
So it is desirable to confirm the data channel statuses as early as possible.
したがって、データチャネルのステータスをできるだけ早く確認することが望ましいです。
The operator may have configured a cross-connect at only one end of a TE link using an EMS. The resource at one end of the data channel is allocated, but the corresponding resource is still available at the other end of the same data channel. In this case, the data channel may appear to be available for use by the control plane when viewed from one end of the TE link but, will be considered to be unavailable by the other end of the TE link. Alternatively, the available end of the data channel may be cross-connected by the management plane, and a misconnection may result from the fact that the other end of the data channel is already cross-connected.
オペレーターは、EMSを使用してTEリンクの片端でのみクロスコネクトを構成している可能性があります。データチャネルの一方の端にあるリソースは割り当てられますが、同じデータチャネルのもう一方の端で対応するリソースは引き続き使用できます。この場合、TEリンクの一方の端から表示されると、データチャネルが制御プレーンが使用できるように見える場合がありますが、TEリンクのもう一方の端では利用できないと見なされます。あるいは、データチャネルの使用可能な端は、管理プレーンによってクロス接続されている場合があり、データチャネルのもう一方の端がすでに相互接続されているという事実から、誤った接続が生じる場合があります。
Figure 1 shows a data channel between nodes A and B. The resource at A's end of the TE link is allocated through manual configuration, while the resource at B's end of the TE link is available, so the data channel status is mismatched.
図1は、ノードAとBの間のデータチャネルを示しています。TEリンクのAの端にあるリソースは手動構成を介して割り当てられ、BのTEリンクの端にあるリソースが利用可能であるため、データチャネルステータスは不一致です。
allocated available
+-+------------+-+
A |x| | | B
+-+------------+-+
data channel
Figure 1. Mismatch Caused by Manual Configuration
図1.手動構成による不一致
The channel status of a data link may become mismatched during the LSP deletion process. If the LSP deletion process is aborted in the middle of the process (perhaps because of a temporary control plane failure), the cross-connect at the upstream node may be removed while the downstream node still keeps its cross-connect, if the LSP deletion was initiated by the source node.
データリンクのチャネルステータスは、LSP削除プロセス中に不一致になる場合があります。LSPの削除プロセスがプロセスの途中で中止されている場合（おそらく一時的な制御プレーンの故障のため）、上流ノードのクロスコネクトが削除される場合がありますが、下流ノードは依然としてクロスコネクトを維持します。ソースノードによって開始されました。
For example, in Figure 2, an LSP traverses nodes A, B, and C. Node B resets abnormally when the LSP is being deleted. This results in the cross-connects of nodes A and C being removed, but the cross-connect of node B still being in use. So, the data channel statuses between nodes A and B, and between nodes B and C are both mismatched.
たとえば、図2では、LSPはLSPが削除されているときに異常にノードA、B、およびC.ノードをトラバースします。これにより、ノードAとCのクロスコネクトが削除されますが、ノードBのクロスコネクトはまだ使用されています。したがって、ノードAとBの間、およびノードBとCの間のデータチャネルステータスは両方とも不一致です。
<---------LSP--------->
+-+-------+-+-------+-+
| | |X| | |
+-+-------+-+-------+-+
A B C
Figure 2. Mismatch Caused by LSP Deletion
図2. LSPの削除によって引き起こされる不一致
In [RFC2205] and [RFC3209], a "soft state" mechanism was defined to prevent state discrepancies between LSRs. Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473], [RFC5063]) have been defined: adjacent LSRs may resynchronize their control plane state to reinstate information about LSPs that have persisted in the data plane. Both mechanisms aim at keeping state consistency among nodes and allow LSRs to detect mismatched data plane states. The data plane handling of such mismatched states can be treated as a local policy decision. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use.
[RFC2205]および[RFC3209]では、LSR間の状態の不一致を防ぐために「ソフト状態」メカニズムが定義されました。リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）再起動プロセス（[RFC3473]、[RFC5063]）が定義されています。隣接するLSRは、データプレーンの状態を再同期させて、データプレーンに持続したLSPに関する情報を回復させることができます。どちらのメカニズムも、ノード間の状態の一貫性を維持し、LSRが不一致のデータプレーン状態を検出できるようにすることを目的としています。このような不一致状態のデータプレーンの取り扱いは、現地の政策決定として扱うことができます。一部の展開は、データプレーンの状態を自動的にクリーンアップしてコントロールプレーンの状態と一致することを決定する場合がありますが、他の展開は、使用中の場合に備えて、管理プレーンにアラートを上げてデータプレーンを触れておくことを選択する場合があります。
In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures.
そのような場合、データチャネルの不一致は再起動後に発生する可能性があり、再起動手順によってクリアされない場合があります。
Even if the situation is not common, it might happen that a termination point of a TE link is seen as failed by one end, while on the other end it is seen as OK. This problem may arise due to some failure either in the hardware or in the status detection of the termination point.
状況が一般的でない場合でも、TEリンクの終了点は一方の端で失敗したと見なされ、もう一方の端ではOKと見なされます。この問題は、ハードウェアまたは終端ポイントのステータス検出のいずれかの障害により発生する可能性があります。
This mismatch in the termination point status can lead to failure in the case of bidirectional LSP setup.
終端ポイントステータスでのこの不一致は、双方向LSPセットアップの場合に障害につながる可能性があります。
Good Failed
+-+------------+-+
A | | |X| B
+-+------------+-+
data channel
Path Message with Upstream Label---->
Figure 3. Mismatch Caused by Resource Failure
図3.リソースの障害による不一致
In this case, the upstream node chooses to use termination point A in order to receive traffic from the downstream node. From the upstream node's point of view, the resource is available and thus usable; however, in the downstream node, the corresponding termination point (resource B) is broken. This leads to a setup failure.
この場合、上流のノードは、下流ノードからトラフィックを受信するために終端ポイントAを使用することを選択します。上流のノードの観点から、リソースが利用可能であるため、使用可能です。ただし、下流ノードでは、対応する終了点（リソースB）が壊れています。これにより、セットアップの障害が発生します。
The requirement does not come from a lack in GMPLS specifications themselves but rather from operational concerns because, in most cases, GMPLS-controlled networks will co-exist with legacy networks and legacy procedures.
この要件は、GMPLS仕様自体の欠如からではなく、ほとんどの場合、GMPLS制御ネットワークがレガシーネットワークとレガシー手順と共存するためです。
The protocol extensions defined in this document are intended to detect data plane problems resulting from misuse or misconfigurations triggered by user error, or resulting from failure to clean up the data plane after control plane disconnection. It is anticipated that human mistakes are probably the major source of errors to deal with.
このドキュメントで定義されているプロトコル拡張は、ユーザーエラーによってトリガーされる誤用または誤解に起因するデータプレーンの問題を検出することを目的としています。人間の間違いは、おそらく対処すべき主要なエラーの原因であると予想されています。
This document is not intened to provide a protocol mechanism to deal with broken implementations.
このドキュメントは、壊れた実装に対処するためのプロトコルメカニズムを提供することを意図したものではありません。
The procedures defined in this document are designed to be performed on a periodic or on-demand basis. It is NOT RECOMMENDED that the procedures be used to provide a continuous and on-line monitoring process.
このドキュメントで定義されている手順は、定期的またはオンデマンドベースで実行されるように設計されています。手順を使用して、連続的かつオンライン監視プロセスを提供することをお勧めしません。
As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
LMPはすでにデータプレーンの接続を検証するために使用されているため、この機能をサポートするための適切な候補であると考えられています。
A control plane tool to detect and isolate data channel mismatches is provided in this document by simple additions to the Link Management Protocol (LMP) [RFC4204]. It can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses.
このドキュメントでは、リンク管理プロトコル（LMP）[RFC4204]に簡単に追加することにより、データチャネルの不一致を検出および隔離するためのコントロールプレーンツールがこのドキュメントで提供されます。隣接するLSRSがデータチャネルのステータスを確認できるようにすることにより、ストランドリソースの位置を支援できます。
Outline procedures are described in this section. More detailed procedures are found in Section 6.
アウトライン手順については、このセクションで説明します。より詳細な手順はセクション6にあります。
The message formats in the subsections that follow use Backus-Naur Form (BNF) encoding as defined in [RFC5511].
[RFC5511]で定義されているように、以下のサブセクションのメッセージ形式は、Backus-Naurフォーム（BNF）エンコードを使用します。
Extensions to LMP to confirm a data channel status are described below. In order to confirm a data channel status, the new LMP messages are sent between adjacent nodes periodically or driven by some event (such as an operator command, a configurable timer, or the rejection of an LSP setup message because of an unavailable resource). The new LMP messages run over the control channel, encapsulated in UDP with an LMP port number and IP addressing as defined in "Link Management Protocol (LMP)" [RFC4204].
データチャネルのステータスを確認するためのLMPへの拡張については、以下に説明します。データチャネルのステータスを確認するために、新しいLMPメッセージは、隣接するノード間で定期的に送信されるか、いくつかのイベント（オペレーターコマンド、設定可能なタイマー、または利用できないリソースのためにLSPセットアップメッセージの拒否など）によって駆動されます。新しいLMPメッセージは、「リンク管理プロトコル（LMP）」[RFC4204]で定義されているように、LMPポート番号とIPアドレス指定でUDPにカプセル化されたコントロールチャネル上で実行されます。
Three new messages are defined to check data channel status: ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, and ConfirmDataChannelStatusNack. These messages are described in detail in the following subsections. Message Type numbers are found in Section 8.1.
データチャネルのステータスを確認するために3つの新しいメッセージが定義されています：confirmdatachannelstatus、ConfideDatachannelstatusack、およびConfideDatachannelstatusnack。これらのメッセージについては、次のサブセクションで詳しく説明しています。メッセージタイプ番号はセクション8.1にあります。
The ConfirmDataChannelStatus message is used to provide the remote end of the data channel with the status of the local end of the data channel and to ask the remote end to report its data channel. The message may report on (and request information about) more than one data channel.
ConfirmDatachannelStatusメッセージは、データチャネルのリモートエンドにデータチャネルのローカルエンドのステータスを提供し、リモートエンドにデータチャネルを報告するように依頼するために使用されます。メッセージは、複数のデータチャネルについて報告する（および情報を要求する）ことができます。
<ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID>
<MESSAGE_ID>
<DATA_LINK>[<DATA_LINK>...]
When a node receives the ConfirmDataChannelStatus message, and the data channel status confirmation procedure is supported at the node, the node compares its own data channel statuses with all of the data channel statuses sent by the remote end in the ConfirmDataChannelStatus message. If a data channel status mismatch is found, this mismatch result is expected to be reported to the management plane for further action. Management plane reporting procedures and actions are outside the scope of this document.
ノードがConfirmDatachannelStatusメッセージを受信し、データチャネルステータス確認手順がノードでサポートされている場合、ノードは独自のデータチャネルステータスを、ConfirmDatachannelStatusメッセージのリモートエンドによって送信されたすべてのデータチャネルステータスを比較します。データチャネルステータスの不一致が見つかった場合、この不一致の結果は、さらなるアクションのために管理プレーンに報告されると予想されます。管理プレーンの報告手順とアクションは、このドキュメントの範囲外です。
If the message is a Confirm Data Channel Status message, and the MESSAGE_ID value is less than the largest MESSAGE_ID value previously received from the sender for the specified TE link, then the message SHOULD be treated as being out-of-order.
メッセージがデータチャネルステータスメッセージの確認であり、Message_ID値が指定されたTEリンクの送信者から以前に受信した最大のメッセージ_ID値よりも小さい場合、メッセージはオーダーの外で扱われる必要があります。
The ConfirmDataChannelStatusAck message is sent back to the node that originated the ConfirmDataChannelStatus message to return the requested data channel statuses.
confilmdatachannelstatusackメッセージは、要求されたデータチャネルステータスを返すために、datachannelstatusの確認メッセージを発信したノードに送り返されます。
When the ConfirmDataChannelStatusAck message is received, the node compares the received data channel statuses at the remote end with those at the local end (the same operation as performed by the receiver of the ConfirmDataChannelStatus message). If a data channel status mismatch is found, the mismatch result is expected to be reported to the management plane for further action.
confilmdatachannelstatusackメッセージが受信されると、ノードは、リモートエンドの受信したデータチャネルステータスをローカルエンドのデータチャネルステータスと比較します（datachannelstatusのconfismentachannelstatusメッセージの受信者によって実行されるのと同じ操作）。データチャネルステータスの不一致が見つかった場合、さらにアクションのために不一致の結果が管理プレーンに報告されると予想されます。
<ConfirmDataChannelStatusAck Message> ::= <Common Header>
<MESSAGE_ID_ACK>
<DATA_LINK>[<DATA_LINK>...]
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being acknowledged.
Message_id_ackオブジェクトの内容は、確認されているconfilmdatachannelstatusメッセージから取得する必要があります。
Note that the ConfirmDataChannelStatusAck message is used both when the data channel statuses match and when they do not match.
Data Channel Statusが一致するときと一致しないときの両方で、datachannelstatusackのConfismandacannelstatusackメッセージが使用されることに注意してください。
When a node receives the ConfirmDataChannelStatus message, if the data channel status confirmation procedure is not supported but the message is recognized, a ConfirmDataChannelStatusNack message containing an ERROR_CODE indicating "Channel Status Confirmation Procedure not supported" MUST be sent.
NodeがConfirmDatachannelStatusメッセージを受信すると、データチャネルステータス確認手順がサポートされていないがメッセージが認識されている場合、「チャネルステータス確認手順がサポートされていない」を示すエラー_Codeを含むconfirmDatachannelstatusNackメッセージを送信する必要があります。
If the data channel status confirmation procedure is supported, but the node is unable to begin the procedure, a ConfirmDataChannelStatusNack message containing an ERROR_CODE indicating "Unwilling to Confirm" MUST be sent. If a ConfirmDataChannelStatusNack message is received with such an ERROR_CODE, the node that originated the ConfirmDataChannelStatus message MAY schedule the ConfirmDataChannelStatus message retransmission after a configured time. A default value of 10 minutes is suggested for this timer.
データチャネルのステータス確認手順がサポートされているが、ノードが手順を開始できない場合、「確認したくない」を示すエラー_codeを含むdatachannelstatusnackメッセージを送信する必要があります。confilmdatachannelstatusnackメッセージがこのようなエラー_codeで受信された場合、datachannelstatusの確認メッセージを発信したノードは、構成された時間の後にdatachannelstatusメッセージの再送信をスケジュールする場合があります。このタイマーでは、10分のデフォルト値が提案されています。
<ConfirmDataChannelStatusNack Message> ::= <Common Header>
[<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK>
<ERROR_CODE>
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being rejected.
message_id_ackオブジェクトの内容は、拒否されているconfilmdatachannelstatusメッセージから取得する必要があります。
The ERROR_CODE object in this message has a new Class Type (see Section 8.3), but is formed as the ERROR_CODE object defined in [RFC4204]. The following Error Codes are defined:
このメッセージのERROR_CODEオブジェクトには、新しいクラスタイプがあります（セクション8.3を参照）が、[RFC4204]で定義されたERROR_CODEオブジェクトとして形成されます。次のエラーコードが定義されています。
0x01 = Channel Status Confirmation Procedure not supported 0x02 = Unwilling to Confirm
0x01 =チャネルステータス確認手順サポートされていない0x02 =確認したくない
A new Data Channel Status subobject type is introduced to the DATA LINK object to hold the Data Channel Status and Data Channel ID.
新しいデータチャネルステータスサブオブジェクトタイプがデータリンクオブジェクトに導入され、データチャネルステータスとデータチャネルIDが保持されます。
See Section 8.2 for the Subobject Type value.
サブオブジェクトタイプの値については、セクション8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Data Channel ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Channel Status:
データチャネルステータス：
This is a series of bit flags to indicate the status of the data channel. The following values are defined.
これは、データチャネルのステータスを示す一連のビットフラグです。次の値が定義されています。
0x0000 : The channel is available/free. 0x0001 : The channel is unavailable/in-use.
0x0000：チャネルは利用可能/無料です。0x0001：チャネルは利用できません/使用されていません。
Data Channel ID
データチャネルID
This identifies the data channel. The length of this field can be deduced from the Length field in the subobject. Note that all subobjects must be padded to a four-byte boundary with trailing zeros.
これにより、データチャネルが識別されます。このフィールドの長さは、サブオブジェクトの長さフィールドから推定できます。すべてのサブオブジェクトは、後続のゼロを備えた4バイトの境界にパッドで埋められる必要があることに注意してください。
If such padding is required, the Length field MUST indicate the length of the subobject up to, but not including, the first byte of padding. Thus, the amount of padding is deduced and not represented in the Length field.
そのようなパディングが必要な場合、長さのフィールドは、パディングの最初のバイトを含むが含まれていないサブオブジェクトの長さを示す必要があります。したがって、パディングの量は推定され、長さフィールドには表されません。
Note that the Data Channel ID is given in the context of the sender of the ConfirmChannelStatus message.
Data Channel IDは、ConfismChannelStatusメッセージの送信者のコンテキストで指定されていることに注意してください。
The Data Channel ID must be encoded as a label value. Based on the type of signal (e.g., Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Lambda, etc.), the encoding methodology used will be different. For SONET/SDH, the label value is encoded as per [RFC4606].
データチャネルIDは、ラベル値としてエンコードする必要があります。信号のタイプ（例：同期光ネットワーク/同期デジタル階層（SONET/SDH）、Lambdaなど）に基づいて、使用されるエンコーディング方法論は異なります。SONET/SDHの場合、ラベル値は[RFC4606]に従ってエンコードされます。
Data_Link Class (as defined in Section 13.12 of [RFC4204]) is included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck messages.
data_linkクラス（[rfc4204]のセクション13.12で定義されている）は、confirmdatachannelstatusおよびconfidedatachannelstatusackメッセージに含まれています。
The status of the TE link end MUST be carried by the Data Channel Status subobject, which is defined in Section 5.2 of this document. The new subobject MUST be part of Data_Link Class.
TEリンク端のステータスは、このドキュメントのセクション5.2で定義されているデータチャネルステータスSubObjectによって実行される必要があります。新しいサブオブジェクトは、data_linkクラスの一部でなければなりません。
In the case of SONET/SDH, the Data Channel ID in the new subobject SHOULD be used to identify each timeslot of the data link.
SONET/SDHの場合、新しいサブオブジェクトのデータチャネルIDを使用して、データリンクの各タイムスロットを識別する必要があります。
Some nodes running in the network might only support the LMP Message Types, which are already defined in [RFC4204]. The three new types of LMP messages defined in this document cannot be recognized by these nodes. The behavior of an LMP node that receives an unknown message is not specified in [RFC4204] and will be clarified in a separate document.
ネットワークで実行されている一部のノードは、[RFC4204]ですでに定義されているLMPメッセージタイプのみをサポートする場合があります。このドキュメントで定義されている3つの新しいタイプのLMPメッセージは、これらのノードでは認識できません。未知のメッセージを受信するLMPノードの動作は[RFC4204]で指定されておらず、別のドキュメントで明確にされます。
Since the behavior of legacy nodes must be assumed to be unknown, this document assumes that a deployment intended to support the function described in this document will consist completely of nodes that support the protocol extensions also described in this document.
レガシーノードの動作は不明であると想定する必要があるため、このドキュメントは、このドキュメントで説明されている関数をサポートすることを目的とした展開が、このドキュメントで説明されているプロトコル拡張をサポートするノードで完全に構成されると想定しています。
In the future, it may be the case that LMP will be extended to allow function support to be detected. In that case, it may become possible to deploy this function in a mixed environment.
将来的には、関数サポートを検出できるようにLMPが拡張される場合があります。その場合、この機能を混合環境に展開することが可能になる場合があります。
Adjacent nodes MAY send data channel status confirmation-related LMP messages. Periodical timers or some other events requesting the confirmation of channel status for the data link may trigger these messages. It's a local policy decision to start the data channel status confirmation process. The procedure is described below:
隣接するノードは、データチャネルステータス確認関連のLMPメッセージを送信する場合があります。定期的なタイマーまたはデータリンクのチャネルステータスの確認を要求するその他のイベントは、これらのメッセージをトリガーする場合があります。データチャネルステータス確認プロセスを開始することは、ローカルポリシーの決定です。手順を以下に説明します。
. Initially, the SENDER constructs a ConfirmDataChannelStatus message that MUST contain one or more DATA_LINK objects. The DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object MUST contain one or more Data Channel Status subobjects. The Data Channel ID field in the Data Channel Status subobject MUST indicate which data channel needs to be confirmed, and MUST report the data channel status at the SENDER. The ConfirmDataChannelStatus message is sent to the RECEIVER.
。最初に、送信者は、1つ以上のdata_linkオブジェクトを含める必要があるconfilmdatachannelstatusメッセージを構築します。data_linkオブジェクトは[RFC4204]で定義されています。各data_linkオブジェクトには、1つ以上のデータチャネルステータスサブオブジェクトを含める必要があります。Data Channel Status subobjectのデータチャネルIDフィールドは、どのデータチャネルを確認する必要があるかを示し、送信者のデータチャネルステータスを報告する必要があります。confilmdatachannelstatusメッセージが受信機に送信されます。
. Upon receipt of a ConfirmDataChannelStatus message, the RECEIVER MUST extract the data channel statuses from the ConfirmDataChannelStatus message and SHOULD compare these with its data channel statuses for the reported data channels. If a data channel status mismatch is found, the mismatch result SHOULD be reported to the management plane for further action. The RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message, which MUST carry all the local end statuses of the requested data channels to the SENDER.
。confilmdatachannelstatusメッセージを受信すると、受信者はconfilmdatachannelstatusメッセージからデータチャネルステータスを抽出する必要があり、報告されたデータチャネルのデータチャネルステータスと比較する必要があります。データチャネルステータスの不一致が見つかった場合、さらにアクションのために不一致の結果を管理プレーンに報告する必要があります。また、受信者は、要求されたデータチャネルのすべてのローカルエンドステータスを送信者に携帯する必要があるConfismDatachannelStatusackメッセージを送信する必要があります。
. If the RECEIVER is not able to support or to begin the confirmation procedure, the RECEIVER MUST send a ConfirmDataChannelStatusNack message containing the ERROR_CODE that indicates the reason for rejection.
。受信者が確認手順をサポートまたは開始できない場合、受信者は、拒否の理由を示すERROR_CODEを含むdatachannelstatusnackメッセージを送信する必要があります。
. Upon receipt of a ConfirmDataChannelStatusAck message, the SENDER MUST compare the received data channel statuses at the remote end with the data channel statuses at the local end. If a data channel status mismatch is found, the mismatch result SHOULD be reported to the management plane for further action.
。ConfirmDatachannelStatusackメッセージを受信すると、送信者は、リモートエンドの受信したデータチャネルステータスをローカルエンドのデータチャネルステータスと比較する必要があります。データチャネルステータスの不一致が見つかった場合、さらにアクションのために不一致の結果を管理プレーンに報告する必要があります。
The data channel status mismatch issue identified by LMP may be automatically resolved by RSVP restart. For example, the restarting node may also have damaged its data plane. This leaves the data channels mismatched. However, RSVP restart will re-install the data plane state in the restarting node. The issue may also be resolved via RSVP soft state timeout.
LMPによって特定されたデータチャネルステータスの不一致の問題は、RSVP再起動によって自動的に解決される場合があります。たとえば、再起動ノードはデータプレーンに損傷を与えている可能性もあります。これにより、データチャネルが不一致になります。ただし、RSVP再起動は、再起動ノードのデータプレーン状態を再インストールします。この問題は、RSVPソフトステートタイムアウトを介して解決することもできます。
If the ConfirmDataChannelStatus message is not recognized by the RECEIVER, the RECEIVER ignores this message and will not send out an acknowledgment message to the SENDER.
confilmdatachannelstatusメッセージが受信者によって認識されない場合、受信者はこのメッセージを無視し、送信者に確認メッセージを送信しません。
Due to the message loss problem, the SENDER may not be able to receive the acknowledgment message.
メッセージの損失の問題により、送信者は確認メッセージを受信できない場合があります。
ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable transmission mechanisms. If, after the retry limit is reached, a ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack message is not received by the SENDER, the SENDER SHOULD terminate the data channel confirmation procedure and SHOULD raise an alert to the management plane.
ConfirmDatachannelstatusは、LMP [RFC4204]信頼できる伝播メカニズムを使用して送信する必要があります。再試行制限に到達した後、datachannelstatusackの確認メッセージまたはconfirmdatachannelstatusnackメッセージが送信者によって受信されない場合、送信者はデータチャネル確認手順を終了し、管理プレーンにアラートを上げる必要があります。
[RFC4204] describes how LMP messages between peers can be secured, and these measures are equally applicable to the new messages defined in this document.
[RFC4204]は、ピア間のLMPメッセージを保護する方法を説明しており、これらの測定値は、このドキュメントで定義されている新しいメッセージに等しく適用できます。
The operation of the procedures described in this document does not of itself constitute a security risk because it does not cause any change in network state. It would be possible, if the messages were intercepted or spoofed, to cause bogus alerts in the management plane, and so the use of LMP security measures described in [RFC4204] is RECOMMENDED.
このドキュメントで説明されている手順の操作自体は、ネットワーク状態に変化を引き起こさないため、セキュリティリスクを構成するものではありません。メッセージが傍受またはスプーフィングされている場合、管理面で偽のアラートを引き起こす可能性があるため、[RFC4204]で説明されているLMPセキュリティ対策の使用が推奨されます。
Note that performing the procedures described in this document may provide a useful additional security measure to verify that data channels have not been illicitly modified.
このドキュメントで説明されている手順を実行すると、データチャネルが違法に変更されていないことを確認するための有用な追加セキュリティ測定値を提供する場合があることに注意してください。
IANA maintains the "Link Management Protocol (LMP)" registry, which has a subregistry called "LMP Message Type". IANA has made the following three new allocations from this registry.
IANAは、「LMPメッセージタイプ」と呼ばれるサブレジストリを備えた「Link Management Protocol（LMP）」レジストリを維持しています。IANAは、このレジストリから次の3つの新しい割り当てを行いました。
Value Description
------ ---------------------------------
32 ConfirmDataChannelStatus
33 ConfirmDataChannelStatusAck
34 ConfirmDataChannelStatusNack
IANA maintains the "Link Management Protocol (LMP)" registry, which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the DATA_LINK object, and there is a further embedded registry called "DATA_LINK Sub-object Class name space". IANA has made the following allocation from this embedded registry.
IANAは、「LMPオブジェクトクラス名スペースとクラスタイプ（Cタイプ）」と呼ばれるサブレジストリを備えた「Link Management Protocol（LMP）」レジストリを維持しています。このサブレジストリには、data_linkオブジェクトのエントリがあり、「data_link sub-objectクラス名スペース」と呼ばれるさらに組み込みレジストリがあります。IANAは、この組み込みレジストリから次の割り当てを行いました。
Value Description
------ ---------------------------------
9 Data Channel Status
IANA maintains the "Link Management Protocol (LMP)" registry, which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the ERROR_CODE object. IANA has allocated the following new value for an ERROR_CODE class type.
IANAは、「LMPオブジェクトクラス名スペースとクラスタイプ（Cタイプ）」と呼ばれるサブレジストリを備えた「Link Management Protocol（LMP）」レジストリを維持しています。このサブレジストリには、error_codeオブジェクトのエントリがあります。IANAは、ERROR_CODEクラスタイプに次の新しい値を割り当てました。
C-Type Description Reference
------ ---------------------------- ---------
4 ConfirmDataChannelStatusNack [This RFC]
The authors would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou Berger for their useful comments.
著者は、エイドリアン・ファレル、ディミトリ・パパジミトリウ、ルー・バーガーの有用なコメントに感謝したいと思います。
[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月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511] Farrel、A.、ed。、「Routing Backus-Naur Form（RBNF）：さまざまなルーティングプロトコル仕様でエンコードルールを形成するために使用される構文」、RFC 5511、2009年4月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[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。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロールの拡張機能」、RFC 4606、2006年8月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063] Satyanarayana、A.、ed。、およびR. Rahman、ed。、「GMPLSリソース予約プロトコル（RSVP）Graceful Restartへの拡張」、RFC 5063、2007年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
Contributor's Address
貢献者の住所
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
Fatai Zhang Huawei Technologies F3-5-B R＆D Center、Huawei Base Shenzhen 518129 China
Phone: +86 755-289-72912
EMail: zhangfatai@huawei.com
Authors' Addresses
著者のアドレス
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
Dan Li Huawei Technologies F3-5-B R＆D Center、Huawei Base Shenzhen 518129 China
Phone: +86 755-289-70230
EMail: danli@huawei.com
Huiying Xu Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
Huiying Xu Huawei Technologies F3-5-B R＆D Center、Huawei Base Shenzhen 518129 China
Phone: +86 755-289-72910
EMail: xuhuiying@huawei.com
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082, USA
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson、Texas 75082、米国
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com
Julien Meuric France Telecom Orange Labs 2, avenue Pierre Marzin 22307 Lannion Cedex, France
Julien Meuric France Telecom Orange Labs 2、Avenue Pierre Marzin 22307 Lannion Cedex、フランス
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange-ftgroup.com
Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy
Diego Caviglia Ericssonを介してA. Negrone 1/A 16153 Genoa Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@ericsson.com