[要約] RFC 4783は、GMPLSネットワークでのアラーム情報の通信に関する標準化されたプロトコルを提供します。このRFCの目的は、GMPLSネットワークでのアラーム情報の効果的な共有と管理を可能にすることです。
Network Working Group L. Berger, Ed.
Request for Comments: 4783 LabN
Updates: 3473 December 2006
Category: Standards Track
GMPLS - Communication of Alarm Information
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 IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.
このドキュメントでは、一般化されたMPLS（マルチプロトコルラベルスイッチング）への拡張が、アラーム情報の通信をサポートするためのシグナル伝達について説明します。GMPLSシグナリングは、アラームレポートの制御を既にサポートしていますが、アラーム情報の通信はサポートしていません。このドキュメントは、このような拡張機能の機能的説明とGMPLS-RSVPの詳細の両方を示しています。このドキュメントでは、RSVP Error_Specオブジェクトの変更も提案しています。
This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473.
このドキュメントは、新しいオプションのプロトコル要素の追加を通じて、RFC 3473を更新します。RFC 3473で指定された手順とは、変更されず、完全に後方互換性があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
2. Alarm Information Communication .................................4
3. GMPLS-RSVP Details ..............................................5
3.1. ALARM_SPEC Objects .........................................5
3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ..............5
3.1.2. Procedures ..........................................9
3.1.3. Error Codes and Values .............................10
3.1.4. Backwards Compatibility ............................11
3.2. Controlling Alarm Communication ...........................11
3.2.1. Updated Admin_Status Object ........................11
3.2.2. Procedures .........................................11
3.3. Message Formats ...........................................12
3.4. Relationship to GMPLS UNI .................................13
3.5. Relationship to GMPLS E-NNI ...............................14
4. Security Considerations ........................................14
5. IANA Considerations ............................................15
5.1. New RSVP Object ...........................................15
5.2. New Interface ID Types ....................................16
5.3. New Registry for Admin-Status Object Bit Fields ...........16
5.4. New RSVP Error Code .......................................16
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................17
7. Acknowledgments ................................................18
8. Contributors ...................................................18
GMPLS signaling provides mechanisms that can be used to control the reporting of alarms associated with a label switched path (LSP). This support is provided via Administrative Status Information [RFC3471] and the Admin_Status object [RFC3473]. These mechanisms only control if alarm reporting is inhibited. No provision is made for communication of alarm information within GMPLS.
GMPLSシグナリングは、ラベルスイッチ付きパス（LSP）に関連付けられたアラームのレポートを制御するために使用できるメカニズムを提供します。このサポートは、管理ステータス情報[RFC3471]およびAdmin_Statusオブジェクト[RFC3473]を介して提供されます。これらのメカニズムは、アラーム報告が阻害された場合にのみ制御します。GMPL内のアラーム情報の通信に関する規定はありません。
The extension described in this document defines how the alarm information associated with a GMPLS LSP may be communicated along the path of the LSP. Communication both upstream and downstream is supported. The value in communicating such alarm information is that this information is then available at every node along the LSP for display and diagnostic purposes. Alarm information may also be useful in certain traffic protection scenarios, but such uses are out of the scope of this document. Alarm communication is supported via a new object, new error/alarm information TLVs, and a new Administrative Status Information bit.
このドキュメントで説明されている拡張機能は、GMPLS LSPに関連付けられたアラーム情報がLSPの経路に沿って伝達される方法を定義しています。上流と下流の両方のコミュニケーションがサポートされています。このようなアラーム情報の通信における値は、この情報が表示および診断の目的でLSPに沿ったすべてのノードで利用可能になることです。アラーム情報は、特定の交通保護シナリオでも役立つ場合がありますが、このような用途はこのドキュメントの範囲外です。アラーム通信は、新しいオブジェクト、新しいエラー/アラーム情報TLV、および新しい管理ステータス情報ビットを介してサポートされます。
The communication of alarms, as described in this document, is controllable on a per-LSP basis. Such communication may be useful within network configurations where not all nodes support communication to a user for reporting of alarms and/or communication is needed to support specific applications. The support of this functionality is optional.
このドキュメントに記載されているように、アラームの通信は、LSPごとに制御可能です。このような通信は、特定のアプリケーションをサポートするためにアラームや通信のレポートのためにすべてのノードがユーザーへの通信をサポートしているわけではないネットワーク構成内で役立つ場合があります。この機能のサポートはオプションです。
The communication of alarms within GMPLS does not imply any modification in behavior of processing of alarms, or for the communication of alarms outside of GMPLS. Additionally, the extension described in this document is not intended to replace any (existing) data plane fault propagation techniques.
GMPLS内のアラームの通信は、アラームの処理の動作や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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Problems with data plane state can often be detected by associated data plane hardware components. Such data plane problems are typically filtered based on elapsed time and local policy. Problems that pass the filtering process are normally raised as alarms. These alarms are available for display to operators. They also may be collected centrally through means that are out of the scope of this document.
データプレーンの状態の問題は、関連するデータプレーンハードウェアコンポーネントによってしばしば検出できます。このようなデータプレーンの問題は、通常、経過時間とローカルポリシーに基づいてフィルタリングされます。フィルタリングプロセスに合格する問題は、通常、アラームとして提起されます。これらのアラームは、オペレーターに表示できます。また、このドキュメントの範囲外である平均を通じて中央に収集される場合があります。
Not all data plane problems cause the LSP to be immediately torn down. Further, there may be a desire, particularly in optical transport networks, to retain an LSP and communicate relevant alarm information even when the data plane state has failed completely.
すべてのデータプレーンの問題により、LSPがすぐに取り壊されるわけではありません。さらに、特に光学輸送ネットワークには、データプレーンの状態が完全に失敗した場合でも、LSPを保持し、関連するアラーム情報を通信することを望んでいる可能性があります。
Although error information can be reported using PathErr, ResvErr, and Notify messages, these messages typically indicate a problem in signaling state and can only report one problem at a time. This makes it hard to correlate all of the problems that may be associated with a single LSP and to allow an operator examining the status of an LSP to view a full list of current problems. This situation is exacerbated by the absence of any way to communicate that a problem has been resolved and a corresponding alarm cleared.
Patherr、Resverr、および通知メッセージを使用してエラー情報を報告できますが、これらのメッセージは通常、シグナリング状態の問題を示し、一度に1つの問題しか報告できません。これにより、単一のLSPに関連付けられている可能性のあるすべての問題を相関させ、LSPのステータスを調べるオペレーターが現在の問題の完全なリストを表示できるようにすることを困難にします。この状況は、問題が解決され、対応するアラームがクリアされたことを伝える方法がないことによって悪化します。
The extensions defined in this document allow an operator or a software component to obtain a full list of current alarms associated with all of the resources used to support an LSP. The extensions also ensure that this list is kept up-to-date and synchronized with the real alarm status in the network. Finally, the extensions make the list available at every node traversed by an LSP.
このドキュメントで定義されている拡張機能により、オペレーターまたはソフトウェアコンポーネントは、LSPをサポートするために使用されるすべてのリソースに関連付けられた現在のアラームの完全なリストを取得できます。また、拡張機能は、このリストが最新の状態に保たれ、ネットワーク内の実際のアラームステータスと同期されることを保証します。最後に、拡張機能により、LSPによって移動されたすべてのノードでリストを利用可能にします。
A new object is introduced to carry alarm information details. The details of alarm information are much like the error information carried in the existing ERROR_SPEC objects. For this reason the communication of alarm information uses a format that is based on the communication of error information.
アラーム情報の詳細を伝えるために新しいオブジェクトが導入されています。アラーム情報の詳細は、既存のERROR_SPECオブジェクトに掲載されているエラー情報とよく似ています。このため、アラーム情報の通信は、エラー情報の通信に基づいた形式を使用します。
The new object introduced to carry alarm information details is called an ALARM_SPEC object. This object has the same format as the ERROR_SPEC object, but uses a new C-Num to avoid the semantics of error processing. Also, additional TLVs are defined for the IF_ID ALARM_SPEC objects to support the communication of information related to a specific alarm. These TLVs may also be useful when included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is carried within a Notify message.
アラーム情報の詳細を掲載するために導入された新しいオブジェクトは、alarm_specオブジェクトと呼ばれます。このオブジェクトは、ERROR_SPECオブジェクトと同じ形式を持っていますが、新しいC-Numを使用してエラー処理のセマンティクスを回避します。また、特定のアラームに関連する情報の通信をサポートするために、IF_ID ALARM_SPECオブジェクトに対して追加のTLVが定義されています。これらのTLVは、ERROR_SPECオブジェクトに含まれる場合、たとえばERROR_SPECオブジェクトが通知メッセージ内に携帯される場合にも役立ちます。
While the details of alarm information are like the details of existing error communication, the semantics of processing differ. Alarm information will typically relate to changes in data plane state, without changes in control state. Alarm information will always be associated with in-place LSPs. Such information will also typically be most useful to operators and applications other than control plane protocol processing. Finally, while error information is communicated within PathErr, ResvErr, and Notify messages [RFC3473], alarm information will be carried within Path and Resv messages.
アラーム情報の詳細は既存のエラー通信の詳細に似ていますが、処理のセマンティクスは異なります。アラーム情報は、通常、制御状態に変化がなく、データプレーン状態の変化に関連します。アラーム情報は常にインプレースLSPに関連付けられます。このような情報は、通常、コントロールプレーンのプロトコル処理以外のオペレーターやアプリケーションにとっても最も有用です。最後に、Patherr、Resverr、および通知メッセージ[RFC3473]内でエラー情報が通知されますが、アラーム情報はパスおよびRESVメッセージ内で実行されます。
Path messages are used to carry alarm information to downstream nodes, and Resv messages are used to carry alarm information to upstream nodes. The intent of sending alarm information both upstream and downstream is to provide the same visibility to alarm information at any point along an LSP. The communication of multiple alarms associated with an LSP is supported. In this case, multiple ALARM_SPEC objects will be carried in the Path or Resv messages.
パスメッセージは、アラーム情報をダウンストリームノードに伝達するために使用され、RESVメッセージはアラーム情報を上流ノードに運ぶために使用されます。上流と下流の両方でアラーム情報を送信する目的は、LSPに沿った任意の時点でアラーム情報を同じ可視性を提供することです。LSPに関連付けられた複数のアラームの通信がサポートされています。この場合、複数のalarm_specオブジェクトがパスまたはRESVメッセージに携帯されます。
The addition of alarm information to Path and Resv messages is controlled via a new Administrative Status Information bit. Administrative Status Information is carried in the Admin_Status object.
パスおよびRESVメッセージへのアラーム情報の追加は、新しい管理ステータス情報ビットを介して制御されます。Adminterativeステータス情報は、Admin_Statusオブジェクトに掲載されています。
This section provides the GMPLS-RSVP [RFC3473] specification for communication of alarm information. The communication of alarm information is OPTIONAL. This section applies to nodes that support communication of alarm information.
このセクションでは、アラーム情報の通信のためのGMPLS-RSVP [RFC3473]仕様を提供します。アラーム情報の通信はオプションです。このセクションは、アラーム情報の通信をサポートするノードに適用されます。
The ALARM_SPEC objects use the same format as the ERROR_SPEC object, but with class number of 198 (assigned by IANA in the form 11bbbbbb, per Section 3.1.4).
alarm_specオブジェクトは、error_specオブジェクトと同じ形式を使用しますが、クラス番号は198（セクション3.1.4に従ってフォーム11bbbbbbbのianaによって割り当てられています）。
o Class = 198, C-Type = 1 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o class = 198、c-type = 1予約。（ERROR_SPECで定義されたCタイプの値ですが、ALARM_SPECで使用するために定義されていません。）
o Class = 198, C-Type = 2 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o class = 198、c-type = 2予約。（ERROR_SPECで定義されたCタイプの値ですが、ALARM_SPECで使用するために定義されていません。）
o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
o IPv4 if_id alarm_specオブジェクト：class = 198、c-type = 3定義IPv4 if_id error_spec [rfc3473]。
o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
o IPv6 if_id alarm_specオブジェクト：class = 198、c-type = 4定義IPv6と同じif_id error_spec [rfc3473]。
The following new TLVs are defined for use with the IPv4 and IPv6 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] Section 9.1.1 for the original definition of these values. Note the length provided below is for the total TLV. All TLVs defined in this section are OPTIONAL.
次の新しいTLVは、IPv4およびIPv6 IF_ID ALARM_SPECオブジェクトで使用するために定義されています。また、IPv4およびIPv6 IF_ID ERROR_SPECオブジェクトで使用することもできます。これらの値の元の定義については、[RFC3471]セクション9.1.1を参照してください。注以下の長さは、合計TLV用です。このセクションで定義されているすべてのTLVはオプションです。
The defined TLVs MUST follow any interface identifying TLVs. No rules apply to the relative ordering of the TLVs defined in this section.
定義されたTLVは、TLVを識別するインターフェイスに従う必要があります。このセクションで定義されているTLVの相対的な順序付けには規則は適用されません。
Type Length Description
----------------------------------
512 8 REFERENCE_COUNT
513 8 SEVERITY
514 8 GLOBAL_TIMESTAMP
515 8 LOCAL_TIMESTAMP
516 variable ERROR_STRING
The Reference Count TLV has the following format:
参照カウントTLVには、次の形式があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reference Count: 32 bits
参照カウント：32ビット
The number of times this alarm has been repeated as determined by the reporting node. This field MUST NOT be set to zero, and TLVs received with this field set to zero MUST be ignored.
このアラームの回数は、レポートノードによって決定されているように繰り返されています。このフィールドをゼロに設定してはならず、このフィールドをゼロに設定して受信したTLVは無視する必要があります。
Only one Reference Count TLV may be included in an object.
オブジェクトに含めることができる参照カウントTLVのみが含まれます。
The Severity TLV has the following format:
重大度TLVには次の形式があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Impact | Severity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 20 bits
予約済み：20ビット
This field is reserved. It MUST be set to zero on generation, MUST be ignored on receipt, and MUST be forwarded unchanged and unexamined by transit nodes.
このフィールドは予約されています。生成時にゼロに設定する必要があり、受領時に無視する必要があり、変化せずに転送され、輸送ノードによって未検証を行う必要があります。
Impact: 4 bits
影響：4ビット
Indicates the impact of the alarm indicated in the TLV. See [M.20] for a general discussion on classification of failures. The following values are defined in this document. The details of the semantics may be found in [M.20].
TLVに示されているアラームの影響を示します。障害の分類に関する一般的な議論については、[M.20]を参照してください。このドキュメントでは、次の値が定義されています。セマンティクスの詳細は[M.20]に記載されています。
Value Definition
----- ---------------------
0 Unspecified impact
1 Non-Service Affecting (Data traffic not interrupted)
2 Service Affecting (Data traffic is interrupted)
Severity: 8 bits
重大度：8ビット
Indicates the impact of the alarm indicated in the TLV. See [RFC3877] and [M.3100] for more information on severity. The following values are defined in this document. The details of the semantics may be found in [RFC3877] and [M.3100]:
TLVに示されているアラームの影響を示します。重大度の詳細については、[RFC3877]および[M.3100]を参照してください。このドキュメントでは、次の値が定義されています。セマンティクスの詳細は、[RFC3877]および[M.3100]にあります。
Value Definition
----- ----------
0 Cleared
1 Indeterminate
2 Critical
3 Major
4 Minor
5 Warning
Only one Severity TLV may be included in an object.
オブジェクトに含めることができる重大度TLVは1つだけです。
The Global Timestamp TLV has the following format:
グローバルタイムスタンプTLVには、次の形式があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Global Timestamp: 32 bits
An unsigned fixed-point integer that indicates the number of seconds since 00:00:00 UT on 1 January 1970 according to the clock on the node that originates this TLV. This time MAY include leap seconds if they are used by the local clock and SHOULD contain the same time value as used by the node when the alarm is reported through other systems (such as within the Management Plane) if global time is used in those reports.
1970年1月1日の00:00:00 UT以降の秒数を示す署名されていない固定点整数。このTLVを発信するノードの時計に応じて。今回は、ローカルクロックで使用されている場合は跳躍秒が含まれる場合があり、他のシステム（管理プレーン内など）を介してアラームが報告されている場合にノードで使用されるのと同じ時間値を含める必要があります。。
Only one Global Timestamp TLV may be included in an object.
オブジェクトに含まれるグローバルタイムスタンプTLVは1つだけです。
The Local Timestamp TLV has the following format:
ローカルタイムスタンプTLVには、次の形式があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Timestamp: 32 bits
ローカルタイムスタンプ：32ビット
Number of seconds reported by the local system clock at the time the associated alarm was detected on the node that originates this TLV. This number is expected to be meaningful in the context of the originating node. For example, it may indicate the number of seconds since the node rebooted or may be a local representation of an unsynchronized real-time clock.
関連するアラームがこのTLVを発信するノードで検出された時点で、ローカルシステムクロックによって報告された秒数。この数値は、発信元ノードのコンテキストで意味があると予想されます。たとえば、ノードが再起動されてから秒数を示す場合がある場合や、非シンデーロー化されたリアルタイムクロックのローカル表現である場合があります。
Only one Local Timestamp TLV may be included in an object.
オブジェクトに含めることができるローカルタイムスタンプTLVは1つだけです。
The Error String TLV has the following format:
エラー文字列TLVには次の形式があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Error String (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error String: 32 bits minimum (variable)
A string of characters in US-ASCII, representing the type of error/alarm. This string is padded to the next largest 4-byte boundary using null characters. Null padding is not required when the string is 32-bit aligned. The contents of error string are implementation dependent. See the condition types listed in Appendices of [GR833] for a list of example strings. Note length includes padding.
エラー/アラームのタイプを表す、us-asciiの一連の文字。この文字列は、null文字を使用して、次の最大の4バイトの境界にパッドで埋められています。文字列が32ビットアラインされている場合、ヌルパディングは必要ありません。エラー文字列の内容は実装に依存します。[GR833]の付録に記載されている条件タイプを参照してください。文字列のリストについては。メモの長さにはパディングが含まれています。
Multiple Error String TLVs may be included in an object.
複数のエラー文字列TLVがオブジェクトに含まれる場合があります。
This section applies to nodes that support the communication of alarm information. ALARM_SPEC objects are carried in Path and Resv messages. Multiple ALARM_SPEC objects MAY be present.
このセクションは、アラーム情報の通信をサポートするノードに適用されます。Alarm_Specオブジェクトは、パスおよびRESVメッセージで運ばれます。複数のalarm_specオブジェクトが存在する場合があります。
Nodes that support the extensions defined in this document SHOULD store any alarm information from received ALARM_SPEC objects for future use. All ALARM_SPEC objects received in Path messages SHOULD be passed unmodified downstream in the corresponding Path messages. All ALARM_SPEC objects received in Resv messages SHOULD be passed unmodified upstream in the corresponding Resv messages. ALARM_SPEC objects are merged in transmitted Resv messages by including a copy of all ALARM_SPEC objects received in corresponding Resv Messages.
このドキュメントで定義されている拡張機能をサポートするノードは、将来の使用のために受信したALARM_SPECオブジェクトからアラーム情報を保存する必要があります。パスメッセージで受信したすべてのALARM_SPECオブジェクトは、対応するパスメッセージで下流の下流に渡す必要があります。RESVメッセージで受信したすべてのALARM_SPECオブジェクトは、対応するRESVメッセージで上流の上流に渡す必要があります。ALARM_SPECオブジェクトは、対応するRESVメッセージで受信したすべてのALARM_SPECオブジェクトのコピーを含めることにより、送信されたRESVメッセージにマージされます。
To advertise local alarm information, a node generates an ALARM_SPEC object for each alarm and adds it to both the Path and Resv messages for the impacted LSP.
ローカルアラーム情報を宣伝するために、ノードは各アラームのALARM_SPECオブジェクトを生成し、影響を受けたLSPのパスメッセージとRESVメッセージの両方に追加します。
In all cases, appropriate Error Node Address, Error Code, and Error Values MUST be set (see below for a discussion on Error Code and Error Values). As the InPlace and NotGuilty flags only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. TLVs SHOULD be included in the ALARM_SPEC object to identify the interface, if any, associated with the alarm. The TLVs defined in [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object [RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD NOT be used. TLVs SHOULD also be included to indicate the severity (Severity TLV), the time (Global Timestamp and/or Local Timestamp TLVs), and a (brief) string (Error String TLV) associated with the alarm. The reference count TLV MAY also be included to indicate the number of times an alarm has been repeated at the reporting node. ALARM_SPEC objects received from other nodes are not impacted by the addition of local ALARM_SPEC objects, i.e., they continue to be processed as described above. The choice of which alarm or alarms to advertise and which to omit is a local policy matter, and may be configurable by the user.
すべての場合において、適切なエラーノードアドレス、エラーコード、およびエラー値を設定する必要があります（エラーコードとエラー値に関する説明については、以下を参照してください）。内部およびnotguiltyフラグは、error_specオブジェクトにのみ意味があるため、設定しないでください。TLVをALARM_SPECオブジェクトに含めて、アラームに関連付けられたインターフェイスがある場合は識別する必要があります。if_id error_specオブジェクト[RFC3473]のインターフェイスを識別するために[RFC3471]で定義されているTLVは、この目的のために使用する必要がありますが、TLVSタイプ4および5（コンポーネントインターフェイス）は[RFC4201]によって非難され、使用してはなりません。TLVは、重症度（重大度TLV）、時間（グローバルタイムスタンプおよび/またはローカルタイムスタンプTLV）、およびアラームに関連する（概要）弦（エラー文字列TLV）を示すために含める必要があります。参照カウントTLVは、レポートノードでアラームが繰り返された回数を示すために含めることもできます。他のノードから受信したALARM_SPECオブジェクトは、ローカルALARM_SPECオブジェクトの追加によって影響を受けません。つまり、上記のように処理され続けます。どのアラームまたはアラームを宣伝するか、どのアラームを省略するかは、ローカルポリシーの問題であり、ユーザーが構成できる場合があります。
There are two ways to indicate time. A global timestamp TLV is used to provide an absolute time reference for the occurrence of an alarm. The local timestamp TLV is used to provide time reference for the occurrence of an alarm that is relative to other information advertised by the node. The global timestamp SHOULD be used on nodes that maintain an absolute time reference. Both timestamp TLVs MAY be used simultaneously.
時間を示すには2つの方法があります。グローバルタイムスタンプTLVは、アラームの発生のための絶対時間参照を提供するために使用されます。ローカルタイムスタンプTLVは、ノードによって宣伝されている他の情報に関連するアラームの発生のための時間参照を提供するために使用されます。グローバルタイムスタンプは、絶対時間参照を維持するノードで使用する必要があります。両方のタイムスタンプTLVを同時に使用できます。
Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv states of LSPs that are in "alarm communication inhibited" state. ALARM_SPEC objects MAY be added to the state of LSPs that are in an "administratively down" state. These states are indicated by the I and A bits of the Admin_Status object; see Section 3.2.
ALARM_SPECオブジェクトは、「アラーム通信が阻害された」状態にあるLSPのパスおよびRESV状態に追加されないでください。alarm_specオブジェクトは、「管理上」状態にあるLSPの状態に追加される場合があります。これらの状態は、iおよびadmin_statusオブジェクトのビットによって示されています。セクション3.2を参照してください。
To remove local alarm information, a node simply removes the matching locally generated ALARM_SPEC objects from the outgoing Path and Resv messages. A node MAY modify a locally generated ALARM_SPEC object.
ローカルアラーム情報を削除するために、ノードは、発信パスとRESVメッセージから一致するローカルで生成されたAlarm_Specオブジェクトを単純に削除します。ノードは、ローカルに生成されたalarm_specオブジェクトを変更する場合があります。
Normal refresh and trigger message processing applies to Path or Resv messages that contain ALARM_SPEC objects. Note that changes in ALARM_SPEC objects from one message to the next may include a modification in the contents of a specific ALARM_SPEC object, or a change in the number of ALARM_SPEC objects present. All changes in ALARM_SPEC objects SHOULD be processed as trigger messages.
通常の更新およびトリガーメッセージ処理は、ALARM_SPECオブジェクトを含むPATHまたはRESVメッセージに適用されます。ALARM_SPECオブジェクトの変更は、あるメッセージから次のメッセージへの変更には、特定のAlarm_Specオブジェクトの内容の変更、または存在するAlarm_Specオブジェクトの数の変更が含まれる場合があることに注意してください。alarm_specオブジェクトのすべての変更は、トリガーメッセージとして処理する必要があります。
Failure to follow the above directives, in particular the ones labeled "SHOULD" and "SHOULD NOT", may result in the alarm information not being properly or fully communicated.
上記の指令に従わないこと、特に「すべきだ」と「すべきでない」というラベルの付いたディレクティブは、アラーム情報が適切にまたは完全に通信されないようになる可能性があります。
The Error Codes and Values used in ALARM_SPEC objects are the same as those used in ERROR_SPEC objects. New Error Code values for use with both ERROR_SPEC and ALARM_SPEC objects may be assigned to support alarm types defined by other standards.
Alarm_Specオブジェクトで使用されるエラーコードと値は、ERROR_SPECオブジェクトで使用されているオブジェクトと同じです。ERROR_SPECとALARM_SPECオブジェクトの両方で使用する新しいエラーコード値は、他の標準で定義されたアラームタイプをサポートするように割り当てられる場合があります。
In this document we define one new Error Code. The Error Code uses the value 31 and is referred to as "Alarms". The values used in the Error Values field when the Error Code is "Alarms" are the same as the values defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note that these values are managed by IANA; see http://www.iana.org.
このドキュメントでは、1つの新しいエラーコードを定義します。エラーコードは値31を使用し、「アラーム」と呼ばれます。エラーコードが「アラーム」であるときにエラー値フィールドで使用される値は、アラームMIB [RFC3877]のIANA-ITU-ALARM-TC-MIBのテキスト条約のためにIanaituprobablecual条約で定義された値と同じです。これらの値はIANAによって管理されていることに注意してください。http://www.iana.orgを参照してください。
The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes will (according to the rules defined in [RFC2205]) pass the objects through the node unmodified, because the ALARM_SPEC object has a C-Num of the form 11bbbbbb.
alarm_specオブジェクトのサポートはオプションです。非サポートノードは（[RFC2205]で定義されているルールに従って）Alarm_Specオブジェクトにはフォーム11bbbbbbbのCナムがあるため、オブジェクトを修正されていないノードに渡します。
This allows alarm information to be collected and examined in a network built from a collection of nodes some of which support the communication of alarm information, and some of which do not.
これにより、アラーム情報を収集して、ノードのコレクションから構築されたネットワークで調べることができ、その一部はアラーム情報の通信をサポートし、その一部はそうではありません。
Alarm information communication is controlled via Administrative Status Information as carried in the Admin_Status object. A new bit is defined, called the I bit, that indicates when alarm communication is to be inhibited. The definition of this bit does not modify the procedures defined in Section 7 of [RFC3473].
アラーム情報通信は、Admin_Statusオブジェクトに掲載されているAdminterative Status Informationを介して制御されます。アラーム通信が阻害される時期を示す新しいビットがiビットと呼ばれます。このビットの定義は、[RFC3473]のセクション7で定義されている手順を変更しません。
The format of the Admin_Status object is updated to include the I bit:
admin_statusオブジェクトの形式は更新され、i bit：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |I| |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inhibit Alarm Communication (I): 1 bit When set, indicates that alarm communication is disabled for the LSP and that nodes SHOULD NOT add local alarm information.
アラーム通信を阻害する（i）：1ビット設定の場合、LSPのアラーム通信が無効になり、ノードがローカルアラーム情報を追加しないことを示します。
See Section 7.1 of [RFC3473] for the definition of the remaining bits.
残りのビットの定義については、[RFC3473]のセクション7.1を参照してください。
The I bit may be set and cleared using the procedures defined in Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or generates) an Admin_Status object with the A or I bits set (1), SHOULD remove all locally generated alarm information from the matching LSP's outgoing Path and Resv messages. When a node receives (or generates) an Admin_Status object with the A and I bits clear (0) and there is local alarm information present, it SHOULD add the local alarm information to the matching LSP's outgoing Path and Resv messages.
[RFC3473]のセクション7.2および7.3で定義されている手順を使用して、Iビットを設定およびクリアすることができます。AまたはIビットセット（1）を使用してAdmin_Statusオブジェクトを受信（または生成）するノードは、一致するLSPの発信パスおよびRESVメッセージからローカルに生成されたすべてのアラーム情報を削除する必要があります。ノードがa admin_statusオブジェクトをA a bits clear（0）で受信（または生成）し、ローカルアラーム情報が存在する場合、一致するLSPの発信パスとRESVメッセージにローカルアラーム情報を追加する必要があります。
The processing of non-locally generated ALARM_SPEC objects MUST NOT be impacted by the contents of the Admin_Status object; that is, received ALARM_SPEC objects MUST be forwarded unchanged regardless of the received or transmitted settings of the I and A bits. Note that, per [RFC3473], the absence of the Admin_Status object is equivalent to receiving an object containing values all set to zero (0).
非典型的に生成されたALARM_SPECオブジェクトの処理は、admin_statusオブジェクトの内容によって影響を受ける必要はありません。つまり、受信したalarm_specオブジェクトは、iおよびaビットの受信または送信された設定に関係なく、変更されずに転送する必要があります。[rfc3473]によると、admin_statusオブジェクトが存在しないことは、すべてゼロ（0）に設定された値を含むオブジェクトを受信することと同等であることに注意してください。
I bit related processing behavior MAY be overridden locally based on configuration.
関連する処理動作は、構成に基づいてローカルにオーバーライドする場合があります。
When generating Notify messages for LSPs with the I bit set, the TLVs described in this document MAY be added to the ERROR_SPEC object sent in the Notify message.
I BIT SETを使用してLSPのNotifyメッセージを生成すると、このドキュメントで説明されているTLVが通知メッセージで送信されたERROR_SPECオブジェクトに追加される場合があります。
This section presents the RSVP message-related formats as modified by this document. The formats specified in [RFC3473] served as the basis of these formats. The objects are listed in suggested ordering.
このセクションでは、このドキュメントで変更されたRSVPメッセージ関連形式を示します。[RFC3473]で指定された形式は、これらの形式の基礎として機能しました。オブジェクトは、提案された順序でリストされています。
The format of a Path message is as follows:
パスメッセージの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
[ <ALARM_SPEC> ... ]
<sender descriptor>
<sender descriptor> is not modified by this document.
<sender descriptor>は、このドキュメントで変更されていません。
The format of a Resv message is as follows:
RESVメッセージの形式は次のとおりです。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
[ <ALARM_SPEC> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document.
<フロー記述子リスト>は、このドキュメントで変更されていません。
[RFC4208] defines how GMPLS may be used in an overlay model to provide a user-to-network interface (UNI). In this model, restrictions may be applied to the information that is signaled between an edge-node and a core-node. This restriction allows the core network to limit the information that is visible outside of the core. This restriction may be made for confidentiality, privacy, or security reasons. It may also be made for operational reasons, for example, if the information is only applicable within the core network.
[RFC4208]は、オーバーレイモデルでGMPLを使用する方法を定義して、ユーザー間インターフェイス（UNI）を提供します。このモデルでは、制限は、エッジノードとコアノードの間で通知される情報に適用される場合があります。この制限により、コアネットワークはコアの外側に表示される情報を制限できます。この制限は、機密性、プライバシー、またはセキュリティ上の理由で行われる場合があります。また、情報がコアネットワーク内でのみ適用可能である場合、運用上の理由で作成される場合があります。
The extensions described in this document are candidates for filtering as described in [RFC4208]. In particular, the following observations apply.
このドキュメントで説明されている拡張機能は、[RFC4208]で説明されているように、フィルタリングの候補です。特に、次の観察結果が適用されます。
o An ingress or egress core-node MAY filter alarms from the GMPLS core to a client-node UNI LSP. This may be to protect information about the core network, or to indicate that the core network is performing or has completed recovery actions for the GMPLS LSP.
o 侵入または出口コアノードは、GMPLSコアからクライアントノードUNI LSPにアラームをフィルタリングする場合があります。これは、コアネットワークに関する情報を保護するか、コアネットワークが実行中であるか、GMPLS LSPの回復アクションを完了していることを示すためです。
o An ingress or egress core-node MAY modify alarms from the GMPLS core when sending to a client-node UNI LSP. This may facilitate the UNI client's ability to understand the failure and its effect on the data plane, and enable the UNI client to take corrective actions in a more appropriate manner.
o 侵入または出口コアノードは、クライアントノードUNI LSPに送信するときに、GMPLSコアからアラームを変更する場合があります。これにより、UNIクライアントの障害とデータプレーンへの影響を理解する能力が容易になり、UNIクライアントがより適切な方法で是正措置を講じることができます。
o Similarly, an egress core-node MAY choose not to request alarm reporting on Path messages that it sends downstream to the overlay network.
o 同様に、出力コアノードは、オーバーレイネットワークに下流を送信するパスメッセージのアラームレポートを要求しないことを選択できます。
GMPLS may be used at the external network-to-network interface (E-NNI); see [ASON-APPL]. At this interface, restrictions may be applied to the information that is signaled between an egress and an ingress core-node.
GMPLは、外部ネットワーク間インターフェイス（E-NNI）で使用できます。[ason-appl]を参照してください。このインターフェースでは、制限は、出口と侵入コアノードの間に通知される情報に適用される場合があります。
This restriction allows the ingress core network to limit the information that is visible outside of its core network. This restriction may be made for confidentiality, privacy, or security reasons. It may also be made for operational reasons, for example, if the information is only applicable within the core network.
この制限により、Ingressコアネットワークは、コアネットワークの外側に表示される情報を制限できます。この制限は、機密性、プライバシー、またはセキュリティ上の理由で行われる場合があります。また、情報がコアネットワーク内でのみ適用可能である場合、運用上の理由で作成される場合があります。
The extensions described in this document are candidates for filtering as described in [ASON-APPL]. In particular, the following observations apply.
このドキュメントで説明されている拡張機能は、[ASON-APPL]で説明されているように、フィルタリングの候補です。特に、次の観察結果が適用されます。
o An ingress or egress core-node MAY filter internal core network alarms. This may be to protect information about the internal network or to indicate that the core network is performing or has completed recovery actions for this LSP.
o 侵入または出口コアノードは、内部コアネットワークアラームをフィルタリングする場合があります。これは、内部ネットワークに関する情報を保護したり、コアネットワークが実行されているか、このLSPの回復アクションを完了していることを示すことです。
o An ingress or egress core-node MAY modify internal core network alarms. This may facilitate the peering E-NNI (i.e., the egress core-node) to understand the failure and its effect on the data plane, and take corrective actions in a more appropriate manner or prolong the generated alarms upstream/downstream as appropriated.
o 侵入または出口コアノードは、内部コアネットワークアラームを変更する場合があります。これにより、ピアリングE-NNI（つまり、出口コアノード）が障害とその効果を理解し、より適切な方法で是正措置を講じるか、上流/下流の生成アラームを延長します。
o Similarly, an egress/ingress core-node MAY choose not to request alarm reporting on Path messages that it sends downstream.
o 同様に、出力/イングレスコアノードは、下流に送信するパスメッセージのアラームレポートを要求しないように選択する場合があります。
Some operators may consider alarm information as sensitive. To support environments where this is the case, implementations SHOULD allow the user to disable the generation of ALARM_SPEC objects, or to filter or correlate them at domain boundaries.
一部のオペレーターは、アラーム情報を機密性があると考える場合があります。これが当てはまる環境をサポートするには、実装では、ユーザーがALARM_SPECオブジェクトの生成を無効にするか、ドメインの境界でそれらをフィルタリングまたは相関させることができます。
This document introduces no additional security considerations. See [RFC3473] for relevant security considerations.
このドキュメントでは、追加のセキュリティ上の考慮事項は紹介されていません。関連するセキュリティに関する考慮事項については、[RFC3473]を参照してください。
It may be noted that if the security considerations of [RFC3473] are breached, alarm information may be spoofed. Such spoofing would be at most annoying and cause slight degradation of control plane performance since the details are provided for information only and do not result in protocol actions beyond the exchange of messages to convey the information. If the protocol security is able to be breached sufficiently to allow spoofing of alarm information then considerably more interesting and exciting damage can be caused by spoofing other elements of the protocol messages.
[RFC3473]のセキュリティ上の考慮事項が侵害されている場合、アラーム情報がスプーフィングされる可能性があることに注意してください。このようなスプーフィングは、ほとんど迷惑であり、詳細が情報のみを提供され、情報を伝えるためにメッセージの交換を超えてプロトコルアクションをもたらさないため、コントロールプレーンのパフォーマンスのわずかな劣化を引き起こします。プロトコルのセキュリティがアラーム情報のスプーフィングを可能にするために十分に侵害できる場合、プロトコルメッセージの他の要素をスプーフィングすることにより、かなり興味深くエキサイティングなダメージを引き起こす可能性があります。
IANA administered assignment of new values for namespaces defined in this document and reviewed in this section.
IANAは、このドキュメントで定義され、このセクションでレビューされた名前空間の新しい値の割り当てを管理しました。
IANA made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANAは、http：//www.iana.org/assignments/rsvp-parametersにある「rsvpパラメーター」レジストリの「クラス名、クラス番号、クラスの種類」セクションで次の割り当てを行いました。
A new class named ALARM_SPEC (198) was created in the 11bbbbbb range with following values
alarm_spec（198）という名前の新しいクラスが11bbbbbbの範囲で作成されました。
o Class = 198, C-Type = 1 RFC 4783 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o class = 198、c-type = 1 RFC 4783予約。（ERROR_SPECで定義されたCタイプの値ですが、ALARM_SPECで使用するために定義されていません。）
o Class = 198, C-Type = 2 RFC 4783 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o class = 198、c-type = 2 RFC 4783予約。（ERROR_SPECで定義されたCタイプの値ですが、ALARM_SPECで使用するために定義されていません。）
o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 RFC 4783 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
o IPv4 if_id alarm_specオブジェクト：class = 198、c-type = 3 rfc 4783定義IPv4 if_id error_spec [rfc3473]と同じ。
o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 RFC 4783 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
o IPv6 if_id alarm_specオブジェクト：class = 198、c-type = 4 rfc 4783定義ipv6 if_id error_spec [rfc3473]と同じ。
The ALARM_SPEC object uses the Error Code and Error Values from the ERROR_SPEC object.
alarm_specオブジェクトは、error_specオブジェクトからエラーコードとエラー値を使用します。
IANA made the following assignments in the "Interface_ID Types" section of the "GMPLS Signaling Parameters" registry located at http://www.iana.org/assignments/gmpls-sig-parameters.
IANAは、http：//www.iana.org/assignments/gmpls-sig-parametersにある「gmpls信号パラメーター」レジストリの「interface_id型」セクションで次の割り当てを行いました。
512 8 REFERENCE_COUNT RFC 4783 513 8 SEVERITY RFC 4783 514 8 GLOBAL_TIMESTAMP RFC 4783 515 8 LOCAL_TIMESTAMP RFC 4783 516 variable ERROR_STRING RFC 4783
512 8 Reference_Count RFC 4783 513 8重大度RFC 4783 514 8 Global_Timestamp RFC 4783 515 8 Local_Timestamp RFC 4783 516変数エラー
IANA created a new section titled "Administrative Status Information Flags" in the "GMPLS Signaling Parameters" registry located at http://www.iana.org/assignments/gmpls-sig-parameters and made the following assignments:
IANAは、http://www.iana.org/assignments/gmpls-sig-parametersにある「Gmpls Signalingパラメーター」レジストリに「管理ステータス情報フラグ」というタイトルの新しいセクションを作成しました。
Value Name Reference
----------- -------------------------------- -----------------
0x80000000 Reflect (R) [RFC3473/RFC3471]
0x00000010 Inhibit Alarm Communication (I) RFC 4783
0x00000004 Testing (T) [RFC3473/RFC3471]
0x00000002 Administratively down (A) [RFC3473/RFC3471]
0x00000001 Deletion in progress (D) [RFC3473/RFC3471]
IANA made the following assignments in the "Error Codes and Values" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANAは、http://www.iana.org/assignments/rsvp-parametersにある「RSVPパラメーター」レジストリの「エラーコードと値」セクションで次の割り当てを行いました。
31 Alarms RFC 4783
31アラームRFC 4783
The Error Value sub-codes for this Error Code have values and meanings identical to the values and meanings defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note that these values are already managed the IANA.
このエラーコードのエラー値サブコードには、アラームMIB [RFC3877]におけるIANA-ITU-ALARM-TC-MIBのテキスト条約のために、Ianaituprobablecualで定義された値と意味と同一の値と意味があります。これらの値はすでにIANAに管理されていることに注意してください。
[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月。
[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年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[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月。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3877] Chisholm、S。およびD. Romascanu、「Alarm Management Information Base（MIB）」、RFC 3877、2004年9月。
[M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995.
[M.3100] ITU推奨M.3100、「ジェネリックネットワーク情報モデル」、1995。
[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月。
[M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION NETWORKS", Recommendation M.20, October 1992.
[M.20] ITU-T、「通信ネットワークのメンテナンス哲学」、推奨M.20、1992年10月。
[GR833] Bellcore, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 3, February 1999.
[GR833] Bellcore、「ネットワークメンテナンス：ネットワーク要素と輸送監視メッセージ」（GR-833-CORE）、1999年2月2日。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[ASON-APPL] Papadimitriou, D., et al., "Generalized MPLS (GMPLS) RSVP-TE signaling usage in support of Automatically Switched Optical Network (ASON)", Work in Progress, July 2005.
[Ason-Appl] Papadimitriou、D.、et al。、「Generalized MPLS（GMPLS）RSVP-TEシグナリングの使用は、自動化された光ネットワーク（ASON）をサポートする」、2005年7月の作業。
Valuable comments and input were received from a number of people, including Wes Doonan, Bert Wijnen for the DISMAN reference, and Tom Petch for getting the DISMAN WG interactions started. We also thank David Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus Westerlund for their valuable comments.
Disman ReferenceのためにWes Doonan、Bert Wijnen、Disman WGの相互作用を開始するためのTom Petchを含む多くの人々から貴重なコメントと意見が受けられました。また、David Black、Lars Eggert、Russ Housley、Dan Romascanu、Magnus Westerlundの貴重なコメントに感謝します。
Contributors are listed in alphabetical order:
貢献者はアルファベット順にリストされています。
Deborah Brungard AT&T Labs, Room MT D1-3C22 200 Laurel Avenue Middletown, NJ 07748, USA Phone: (732) 420-1573 EMail: dbrungard@att.com
Deborah Brungard AT＆T Labs、ルームMT D1-3C22 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国電話：（732）420-1573メール：dbrungard@att.com
Igor Bryskin Adrian Farrel
Movaz Networks, Inc. Old Dog Consulting
7926 Jones Branch Drive
Suite 615
McLean VA, 22102, USA Phone: +44 (0) 1978 860944
EMail: ibryskin@movaz.com EMail: adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel) Arun Satyanarayana
Francis Wellesplein 1 Cisco Systems, Inc
B-2018 Antwerpen, Belgium 170 West Tasman Dr.
San Jose, CA 95134 USA
Phone: +32 3 240-8491 Phone: +1 408 853-3206
EMail: dimitri.papadimitriou@alcatel.be EMail: asatyana@cisco.com
Editor's Address
編集者のアドレス
Lou Berger LabN Consulting, L.L.C.
Lou Berger Labn Consulting、L.L.C。
Phone: +1 301-468-9228
EMail: lberger@labn.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。