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.
このドキュメントでは、データチャネルの状態を確認し、管理を通知するためのトリガを提供するために、隣接するラベルスイッチングルータ（LSRの）を可能にすることにより、二本鎖のリソースの場所を支援することができ、コントロールプレーンツールを提供するために、リンク管理プロトコル（LMP）への単純な追加を定義します平面不一致が検出された場合。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）ネットワークはラベルスイッチングルータを接続するトラフィックエンジニアリング（TE）リンク（のLSR）から構成されています。 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で使用するために割り当てることはできません。管理プレーンアプリケーションが本鎖のリソースを見つけるために、それらを解放するために、すべてのネットワークリソースを監査することが理論的には可能ですが、このプロセスはほとんどが異なるため、エレメント管理システムを調整することの難しさ（のEMS）と偶然イン解放するのに関連するリスクを実行されませんリソースを使用します。リソースを検出して報告が本鎖の制御プレーンメカニズムを有することが望ましいです。
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.
この文書は、隣接のLSRは、データチャネルの状態を確認し、もしあれば、管理プレーンを通知するためのトリガーを提供できるようにすることで、一本鎖のリソースの位置を助けることができるコントロールプレーンのツールを提供するリンク管理プロトコル（LMP）[RFC4204]に簡単な追加を定義します不一致が発見されています。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、TEリンクのBの端にリソースが利用可能であるので、データチャネル状態が不一致であるTEリンクのAの端部におけるリソースが、手動で設定を介して割り当てられているノードAとBとの間のデータチャネルを示しています。
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削除処理は、（おそらくための一時的な制御プレーン障害の）プロセスの途中で中止された場合、上流ノードにおけるクロスコネクト下流ノードがまだ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ノードBが異常リセット横切ります。これは、ノードAのクロスコネクトをもたらし、Cが除去されるが、ノードBのクロスコネクトはまだ使用中です。したがって、ノードAとBとの間、およびノードBとCの間のデータ・チャネル・ステータスが両方一致しません。
<---------LSP--------->
+-+-------+-+-------+-+
| | |X| | |
+-+-------+-+-------+-+
A B C
Figure 2. Mismatch Caused by LSP Deletion
LSP欠失によって引き起こさ図2不一致
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.
状況は一般的ではないとしても、一端で失敗したとして、もう一方の端に、それはOKと見られている間、TEリンクの終端点が、見られることが起こるかもしれません。この問題は、ハードウェアまたは終端点の状態検出のいずれかで何らかの障害を生じる可能性があります。
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]に単純な添加により本書で提供されます。これは、隣接のLSRは、データチャネルの状態を確認できるようにすることで、二本鎖のリソースの場所を支援することができます。
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]で定義されるようにバッカスナウア記法（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への拡張は、以下に記載されています。 （理由は利用できないリソースで、オペレータコマンドとして、設定タイマー、またはLSPセットアップメッセージの拒否）データチャネルのステータスを確認するために、新しいLMPメッセージを定期的に隣接するノード間で送信されるか、またはいくつかのイベントによって駆動されます。新しいLMPメッセージはLMPポート番号とUDPでカプセル化し、「リンク管理プロトコル（LMP）」[RFC4204]で定義されているIPアドレス指定、制御チャネルを介して実行します。
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.
ConfirmDataChannelStatus、ConfirmDataChannelStatusAck、およびConfirmDataChannelStatusNack：三件の新しいメッセージがデータチャネルの状態を確認するために定義されています。これらのメッセージは、以下のサブセクションで詳細に記載されています。メッセージタイプ番号は、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リンクの送信者から受信した最大のMESSAGE_ID値未満である場合、メッセージはアウト・オブ・オーダーとして扱われるべきです。
The ConfirmDataChannelStatusAck message is sent back to the node that originated the ConfirmDataChannelStatus message to return the requested data channel statuses.
ConfirmDataChannelStatusAckメッセージは、要求されたデータ・チャネル・ステータスを返すようにConfirmDataChannelStatusメッセージを発信したノードに送り返されます。
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.
ConfirmDataChannelStatusAckメッセージが受信されると、ノードは、ローカル・エンド（ConfirmDataChannelStatusメッセージの受信機によって実行されるのと同じ操作）におけるものとリモートエンドで受信されたデータチャネルの状態を比較します。データチャネル状態の不一致が見つかった場合、不一致の結果は、さらなる行動のための管理プレーンに報告されることが期待されます。
<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オブジェクトの内容が承認されてConfirmDataChannelStatusメッセージから得なければなりません。
Note that the ConfirmDataChannelStatusAck message is used both when the data channel statuses match and when they do not match.
それらが一致しないときに、データ・チャネル・ステータスが一致してたときに両方ConfirmDataChannelStatusAckメッセージが使用されていることに注意してください。
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.
ノードがConfirmDataChannelStatusメッセージを受信すると、データチャネルステータス確認手順がサポートされていないが、メッセージが認識された場合、「サポートされていないチャンネル状態確認手順」を示すERROR_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.
データチャネルステータス確認手順がサポートされているが、ノードが手順を開始することができない場合は、「確認に不本意」を示すERROR_CODEを含むConfirmDataChannelStatusNackメッセージを送らなければなりません。 ConfirmDataChannelStatusNackメッセージは、ERROR_CODE、設定された時間後ConfirmDataChannelStatusメッセージの再送信をスケジュールすることができるConfirmDataChannelStatusメッセージを発信したノードで受信された場合。 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オブジェクトの内容が拒否さConfirmDataChannelStatusメッセージから得なければなりません。
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.
0000：チャンネルは無料/使用可能です。 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.
これは、データ・チャネルを特定します。このフィールドの長さは、サブオブジェクトにLengthフィールドから推定することができます。すべてのサブオブジェクトは、後続ゼロを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.
このようにパディングが必要な場合は、Lengthフィールドは、サブオブジェクトまでの長さを示す必要がありますが、パディングの最初のバイト、含みません。このように、パディングの量を推定し、Lengthフィールドに表示されていません。
Note that the Data Channel ID is given in the context of the sender of the ConfirmChannelStatus message.
データチャネルIDがConfirmChannelStatusメッセージの送信者のコンテキスト内で与えられていることに注意してください。
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）、ラムダなど）が、使用される符号化方法は異なるであろう。 SONET / SDHのために、ラベル値は[RFC4606]に従って符号化されます。
Data_Link Class (as defined in Section 13.12 of [RFC4204]) is included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck messages.
（[RFC4204]のセクション13.12で定義されるように）Data_LinkクラスはConfirmDataChannelStatusとConfirmDataChannelStatusAckメッセージに含まれています。
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で定義されたデータチャネルステータスサブオブジェクトによって実行されなければなりません。新しいサブオブジェクトは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メッセージタイプを、サポートする場合があります。この文書で定義されたLMPメッセージの3つの新しいタイプは、これらのノードが認識することはできません。未知のメッセージを受信した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.
。最初は、送信者が一つ以上のDATA_LINKオブジェクトを含まなければならないConfirmDataChannelStatusメッセージを構築します。 DATA_LINKオブジェクトは[RFC4204]で定義されています。各DATA_LINKオブジェクトは、1つのまたは複数のデータ・チャンネル・ステータス・サブオブジェクトを含まなければなりません。データ・チャンネル・ステータス・サブオブジェクトにおけるデータチャネルIDフィールドは、確認する必要のあるデータチャネルを示してしなければならない、とSENDERのデータチャネルのステータスを報告しなければなりません。 ConfirmDataChannelStatusメッセージが受信者に送信されます。
. 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.
。 ConfirmDataChannelStatusメッセージを受信すると、受信機はConfirmDataChannelStatusメッセージからデータ・チャネル・ステータスを抽出する必要がありそして報告されたデータ・チャネルのためにそのデータ・チャネル・ステータスとこれらを比較する必要があります。データチャネル状態の不一致が見つかった場合、不一致の結果がさらなる行動のための管理プレーンに報告してください。また、受信機は、送信者に要求されたデータ・チャネルのすべてのローカルエンドステータスを運ばなければなりませんConfirmDataChannelStatusAckメッセージを送るべきです。
. 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を含むConfirmDataChannelStatusNackメッセージを送らなければなりません。
. 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.
ConfirmDataChannelStatusメッセージが受信機によって認識されない場合、受信者はこのメッセージを無視し、送信者に確認メッセージを送信しません。
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]信頼性のある伝送メカニズムを用いて送信されるべきです。再試行限度に達した後、ConfirmDataChannelStatusAckメッセージまたは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メッセージタイプ」と呼ばれる副登録を持っている「リンク管理プロトコル（LMP）」レジストリを維持します。 IANAは、このレジストリから以下の三つの新しい割り当てを行いました。
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型）」と呼ばれる副登録を持っている「リンク管理プロトコル（LMP）」レジストリを維持します。この副登録はDATA_LINKオブジェクトのエントリを持ち、「DATA_LINKサブオブジェクトクラスの名前空間」と呼ばれるさらに組み込みレジストリがあります。 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型）」と呼ばれる副登録を持っている「リンク管理プロトコル（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.
作者は彼らの役に立つコメントをエードリアンファレル、ディミトリPapadimitriou、およびルー・バーガーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（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]ファレル、A.、エド、「ルーティングバッカス記法（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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[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]マニー、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.編、およびR.ラーマン、エド。、RFC 5063、2007年10月、 "GMPLSリソース予約プロトコル（RSVP）グレースフルリスタートへの拡張"。
[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.、エド。、およびY. Rekhter、エド。、 "IS-ISの拡張一般化マルチプロトコルラベルスイッチング（GMPLS）の支援で"、RFC 5307、2008年10月。
Contributor's Address
寄稿者の住所
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
張HU AがあまりにもFA技術F3-5-BR＆Dセンターで、HU Aは、拠点518129中国についても同様です
Phone: +86 755-289-72912 EMail: zhangfatai@huawei.com
電話：+86 755-289-72912 Eメール：zhangfatai@huawei.com
Authors' Addresses
著者のアドレス
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
ダンL IH UA技術F3-5-BR＆Dセンターとして、HU Aは塩基518129中国についても同様です
Phone: +86 755-289-70230 EMail: danli@huawei.com
電話：+86 755-289-70230 Eメール：danli@huawei.com
Huiying Xu Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
ホイハードXええとUAは技術F3-5-BR＆Dセンターで、HU Aは、拠点518129中国についても同様です
Phone: +86 755-289-72910 EMail: xuhuiying@huawei.com
電話：+86 755-289-72910 Eメール：xuhuiying@huawei.com
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082, USA
Snigdho C. Bardalai富士通ネットワークコミュニケーションズ2801テレコムパークウェイリチャードソン、テキサス州75082、USA
Phone: +1 972 479 2951 EMail: snigdho.bardalai@us.fujitsu.com
電話：+1 972 479 2951 Eメール：snigdho.bardalai@us.fujitsu.com
Julien Meuric France Telecom Orange Labs 2, avenue Pierre Marzin 22307 Lannion Cedex, France
ジュリアンMeuricフランステレコム、オレンジLabsの2、大通りピエールMarzin 22307ラニオンセデックス、フランス
Phone: +33 2 96 05 28 28 EMail: julien.meuric@orange-ftgroup.com
電話：+33 2 96 05 28 28 Eメール：julien.meuric@orange-ftgroup.com
Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy
ディエゴ・Cavigliaエリクソン経由A. Negrone 16153分の1ジェノアイタリア
Phone: +39 010 600 3736 EMail: diego.caviglia@ericsson.com
電話：+39 010 600 3736 Eメール：diego.caviglia@ericsson.com