Network Working Group L. Berger, Ed.
Request for Comments: 4783 LabN
Updates: 3473 December 2006
Category: Standards Track
GMPLS - Communication of Alarm Information
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).
著作権（C）IETFトラスト（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、新しい、オプションのプロトコル要素を追加することによって、「一般化されたマルチプロトコルラベル（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）拡張機能を切り替えます」。これは、変更、および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]を介して提供されます。アラーム報告が抑制されている場合は、これらのメカニズムはのみを制御します。いかなる引当金はGMPLS内のアラーム情報の通信のために作られていません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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を使用して報告し、メッセージを通知することができますが、これらのメッセージは、通常の状態をシグナルに問題を示しているし、一度に一つの問題を報告することができます。これは、ハード、単一の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を使用しています。また、追加のTLVは、特定のアラームに関連した情報の通信をサポートするIF_ID ALARM_SPECオブジェクトのために定義されています。 ERROR_SPECオブジェクトに含まれる場合、これらのTLVはまた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.
Pathメッセージを下流ノードへのアラーム情報を運ぶために使用され、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メッセージにアラーム情報の追加は、新しい管理ステータス情報ビットを介して制御されます。管理ステータス情報は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オブジェクト（セクション3.1.4あたり、フォーム11bbbbbbでIANAによって割り当てられた）ERROR_SPECオブジェクトとしてではなく、198のクラス番号と同じ形式を使用します。
o Class = 198, C-Type = 1 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
Oクラス= 198、C-タイプ= 1予約。 （ERROR_SPECに対して定義されたC-Type値が、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.)
クラス= 198、C-タイプ= 2 O予約。 （ERROR_SPECに対して定義されたC-Type値が、ALARM_SPECで使用するために定義されていません。）
o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
IPv4のIF_ID ALARM_SPECオブジェクトO：クラス= 198のIPv4 IF_ID ERROR_SPECと同じ、Cタイプ= 3の定義[RFC3473]。
o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
IPv6のIF_ID ALARM_SPECオブジェクトO：クラス= 198のIPv6 IF_ID ERROR_SPECと同じ、Cタイプ= 4の定義[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は対象に含まれていてもよいです。
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
グローバルタイムスタンプ：32ビット
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.
このTLVを発信するノードのクロックに応じて1970年1月1日0時00分00秒でUTからの秒数を示す符号なしの固定小数点整数。それらはローカルクロックによって使用され、アラームがグローバル時間は、これらのレポートで使用されている場合（たとえば、管理プレーン内のような）他のシステムを通じて報告されたときにノードによって使用されるのと同じ時間値が含まれている必要がある場合は、この時間はうるう秒を含んでもよい（MAY） 。
Only one Global Timestamp TLV may be included in an object.
唯一のグローバルタイムスタンプTLVオブジェクトに含まれてもよいです。
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は対象に含まれていてもよいです。
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)
エラー文字列：32ビットの最小値（変数）
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の文字の文字列。この文字列はヌル文字を使用して、次の最大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オブジェクトから任意のアラーム情報を格納する必要があります。 Pathメッセージで受信した全てALARM_SPECオブジェクトは、対応するPathメッセージの下流未修飾渡す必要があります。 ALARM_SPECオブジェクトがRESVメッセージにおいて受信されたすべての対応するRESVメッセージ上流未修飾渡す必要があります。 ALARM_SPECオブジェクトはALARM_SPECオブジェクトはRESVメッセージを対応して受信したすべてのコピーを含むによって送信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は、この目的のために使用される、しかしのTLVタイプ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.
時間を示すには二つの方法があります。グローバルタイムスタンプ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オブジェクトを含む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のIANAItuProbableCauseテキストの表記法で定義された値と同じです。これらの値は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オブジェクトのサポートはオプションです。 ALARM_SPECオブジェクトがフォーム11bbbbbbのC-民を有するので（[RFC2205]で定義されたルールに従って）であろうノードが、未修飾のノードを介してオブジェクトを渡す非サポート。
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オブジェクトで運ばとしてアラーム情報通信は、管理ステータス情報を介して制御されます。新しいビットが定義され、アラーム通信が阻害される場合を示している、Iビットと呼ばれます。このビットの定義は、[RFC3473]のセクション7で定義された手順を修正しません。
The format of the Admin_Status object is updated to include the I bit:
ADMIN_STATUSオブジェクトの形式はIビットを含むように更新されます。
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.
Iビットが設定され、セクション7.2で定義された手順と[RFC3473]の7.3を使用してクリアすることができます。受信（又は生成）は、ノードA又はI（1）、マッチングLSPの送信パスとRESVメッセージからすべての局所的に生成されたアラーム情報を削除する必要が設定されたビットとADMIN_STATUSオブジェクト。ノードが受信する（又は生成）するときA及びIビットでADMIN_STATUSオブジェクトクリア（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とビットの受信または送信設定の不変転送されなければならない受信されます。 [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ビットが設定されたLSPのためのメッセージを通知生成時の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メッセージの形式は次のとおりです。
<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.
<送信者記述子>は、このドキュメントでは変更されません。
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]はGMPLSはユーザ対ネットワークインタフェース（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入口または出口コアノードは、クライアントノードUNI LSPへGMPLSコアからアラームをフィルタリングすることができます。これは、コアネットワークに関する情報を保護するためであってもよいし、コアネットワークが実行しているか、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.
クライアント・ノードUNI LSPに送信するときにO入力または出力コア・ノードは、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同様に、出口コアノードは、それがオーバーレイネットワークに下流送信Pathメッセージのアラームレポートを要求しないこともできます。
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.
GMPLSは、外部ネットワーク・ツー・ネットワークインタフェース（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.
この制限は、コアネットワークの外に表示される情報を制限するために、入力コアネットワークを可能にします。この制限は、機密性、プライバシー、またはセキュリティ上の理由のために行うことができます。情報は、コアネットワーク内でのみ適用可能である場合、それはまた、例えば、操作上の理由のために作られてもよいです。
The extensions described in this document are candidates for filtering as described in [ASON-APPL]. In particular, the following observations apply.
[AN-APPLE]で説明したように、このドキュメントで説明する機能拡張は、フィルタリングのための候補です。具体的には、以下の観察が適用されます。
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同様に、出口/入口コア・ノードは、それが下流の送信Pathメッセージにアラーム通知を要求しないこともできます。
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クラス= 198、C-タイプ= 1つのRFC 4783リザーブ。 （ERROR_SPECに対して定義されたC-Type値が、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クラス= 198、C-タイプ= 2 RFC 4783リザーブ。 （ERROR_SPECに対して定義されたC-Type値が、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オブジェクト：IPv4のIF_ID ERROR_SPEC同じクラス= 198、C-タイプ= 3 RFC 4783の定義[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オブジェクト：IPv6のIF_ID ERROR_SPEC同じクラス= 198、C-タイプ= 4 RFC 4783の定義[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可変ERROR_STRINGのRFC 4783
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シグナリングパラメータ」レジストリで「管理ステータス情報フラグ」というタイトルの新しいセクションを作成し、次の割り当てを行いました。
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.
[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月。
[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。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3877]チザム、S.およびD. Romascanu、 "アラーム管理情報ベース（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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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の、 "ネットワークのメンテナンス：ネットワーク要素と交通監視メッセージ"（GR833-CORE）、3号、1999年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]ツバメ、G.、ドレイク、J.、石松、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.、ら、 "自動交換光ネットワーク（ASON）の支持に一般化MPLS（GMPLS）RSVP-TEシグナリング用法"、進歩、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 WG相互作用を開始するためのウェス・ドゥーナン、バートWijnen DISMAN参照のため、そしてトム・ペッチ含めた人の数、から受け取りました。我々はまた、彼らの貴重なコメントのためにデビッド・ブラック、ラースEggertの、ラスHousley、ダンRomascanu、およびマグヌスウェスターに感謝します。
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
デボラBrungard AT＆T Labs社、ルームMT D1-3C22 200ローレルアベニューミドルタウン、NJ 07748、USA電話：（732）420から1573 Eメール：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
イゴールBryskinエードリアンファレルMovazネットワークス株式会社老犬のコンサルティング7926ジョーンズ支店ドライブスイート615マクリーンVA、22102、USA電話：+44（0）1978 860944 Eメール：ibryskin@movaz.com Eメール：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
ディミトリPapadimitriou（アルカテル）アルンSatyanarayanaフランシスWellesplein 1シスコシステムズ、株式会社B-2018アントワープ、ベルギー170西タスマン博士サンノゼ、CA 95134 USA電話：+32 3 240から8491まで電話：+1 408 853から3206 Eメール：ディミトリ.papadimitriou @ alcatel.be Eメール：asatyana@cisco.com
Editor's Address
編集者の住所
Lou Berger LabN Consulting, L.L.C.
ルー・バーガーLabnコンサルティング、L.L.C.
Phone: +1 301-468-9228 EMail: lberger@labn.net
電話：+1 301-468-9228電子メール：lberger@labn.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。