RFC4783 日本語訳
4783 GMPLS - Communication of Alarm Information. L. Berger, Ed.. December 2006. (Format: TXT=42068 bytes) (Updates RFC3473) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Berger, Ed. Request for Comments: 4783 LabN Updates: 3473 December 2006 Category: Standards Track
ワーキンググループのL.バーガー、エドをネットワークでつないでください。コメントのために以下を要求してください。 4783のLabNアップデート: 3473 2006年12月のカテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
アラーム情報に関するコミュニケーションをサポートすると合図しながら、このドキュメントはGeneralized MPLS(マルチプロトコルLabel Switching)に拡大について説明します。 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.
このドキュメントはRFC3473をアップデートします、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示し」て、新しくて、任意のプロトコル要素の追加を通して。 それは、後方に完全に変化しないで、あります。互換性があるので、手順はRFC3473で指定しました。
Berger Standards Track [Page 1] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[1ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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
1. 序論…3 1.1. バックグラウンド…3 2. 情報コミュニケーションを驚かせてください…4 3. GMPLS-RSVPの詳細…5 3.1. _仕様オブジェクトを驚かせてください…5 3.1.1. _IDであるなら、_仕様(そして、誤り_仕様)TLVsを驚かせてください…5 3.1.2. 手順…9 3.1.3. エラーコードと値…10 3.1.4. 遅れている互換性…11 3.2. アラームコミュニケーションを制御します…11 3.2.1. アドミン_状態オブジェクトをアップデートします…11 3.2.2. 手順…11 3.3. メッセージ形式…12 3.4. GMPLS UNIとの関係…13 3.5. GMPLSへの電子NNIの関係…14 4. セキュリティ問題…14 5. IANA問題…15 5.1. 新しいRSVPは反対します…15 5.2. 新しいインタフェースIDはタイプされます…16 5.3. アドミン状態オブジェクトビット分野への新しい登録…16 5.4. 新しいRSVPエラーコード…16 6. 参照…17 6.1. 標準の参照…17 6.2. 有益な参照…17 7. 承認…18 8. 貢献者…18
Berger Standards Track [Page 2] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[2ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
1. Introduction
1. 序論
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)を供給します。 Administrative Status情報[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に沿ったあらゆるノードで利用可能であるということです。 また、アラーム情報もあるトラフィック保護シナリオで役に立つかもしれませんが、このドキュメントの範囲の外にそのような用途があります。 アラームコミュニケーションは新しいオブジェクト、新しい誤り/アラーム情報TLVs、および新しいAdministrative Status情報ビットでサポートされます。
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.
本書では説明されるアラームのコミュニケーションは1LSPあたり1個のベースで制御可能です。 すべてのノードがアラームについて報告するためにユーザにコミュニケーションを支えるというわけではないところでそのようなコミュニケーションはネットワーク・コンフィギュレーションの中で役に立つかもしれません、そして、コミュニケーションが、特定のアプリケーションをサポートするのに必要です。 この機能性のサポートは任意です。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Background
1.1. バックグラウンド
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.
関連データ飛行機ハードウェアの部品はしばしばデータ飛行機状態に関する問題を検出できます。 そのようなデータ飛行機問題は経過時間とローカルの方針に基づいて通常フィルターにかけられます。 通常、ろ過過程を通過する問題がアラームとして提起されます。オペレータにとって、これらのアラームはディスプレイに利用可能です。 また、それらはこのドキュメントの範囲の外にある手段で中心に集められるかもしれません。
Berger Standards Track [Page 3] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[3ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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、およびNotifyメッセージを使用することでエラー情報を報告できますが、これらのメッセージは、シグナリング状態で問題を通常示して、一度に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によって横断されたあらゆるノードで利用可能になります。
2. Alarm Information Communication
2. アラーム情報コミュニケーション
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-ヌムを使用します。 また、追加TLVsが定義される、_ID ALARM_SPECがサポートに反対するなら、情報に関するコミュニケーションは特定のアラームに関連しました。 また、ERROR_SPECオブジェクトに含まれていると、これらのTLVsも役に立つかもしれません、例えば、ERROR_SPECオブジェクトがNotifyメッセージの中で運ばれるとき。
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.
アラーム情報の詳細が既存の誤りコミュニケーションの詳細に似ている間、処理の意味論は異なります。 アラーム情報はコントロール状態の変化なしでデータ飛行機状態の変化に通常関連するでしょう。 アラーム情報はいつも適所に関連するでしょう。LSPs。 また、そのような情報も通常オペレータとコントロール飛行機プロトコル処理以外のアプリケーションの最も役に立ちます。 最終的に、エラー情報がPathErr、ResvErr、およびNotifyメッセージ[RFC3473]の中で伝えられている間、アラーム情報はPathとResvメッセージの中で運ばれるでしょう。
Berger Standards Track [Page 4] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[4ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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オブジェクトがPathか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.
Pathへのアラーム情報とResvメッセージの追加は新しいAdministrative Status情報ビットで制御されます。 管理Status情報はAdmin_Statusオブジェクトで運ばれます。
3. GMPLS-RSVP Details
3. GMPLS-RSVPの詳細
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]に供給します。 アラーム情報に関するコミュニケーションはOPTIONALです。 このセクションはアラーム情報に関するそのサポートコミュニケーションをノードに適用します。
3.1. ALARM_SPEC Objects
3.1. アラーム_仕様オブジェクト
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あたりのフォーム11bbbbbbでの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 クラスは198、=1が予約したC-タイプと等しいです。 (C-タイプ値は、ERRORのために_SPECを定義しますが、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 クラスは198、=2が予約したC-タイプと等しいです。 (C-タイプ値は、ERRORのために_SPECを定義しますが、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は_ID ALARM_SPECであるなら反対します: クラスは_ID ERROR_SPEC[RFC3473]であるならIPv4と同じ3 198、C-タイプ=Definitionと等しいです。
o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4
Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
o IPv6は_ID ALARM_SPECであるなら反対します: クラスは_ID ERROR_SPEC[RFC3473]であるならIPv6と同じ4 198、C-タイプ=Definitionと等しいです。
3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs
3.1.1. _IDであるなら、_仕様(そして、誤り_仕様)TLVsを驚かせてください。
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.
_ID ALARM_SPECが反対するなら、以下の新しいTLVsはIPv4とIPv6との使用のために定義されます。 また、_ID ERROR_SPECが反対するなら、それらはIPv4とIPv6と共に使用されるかもしれません。 これらの値のオリジナルの定義に関して[RFC3471]セクション9.1.1を見てください。 TLVが合計のために以下にあるなら、長さに注意してください。 このセクションで定義されたすべてのTLVsがOPTIONALです。
Berger Standards Track [Page 5] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[5ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
The defined TLVs MUST follow any interface identifying TLVs. No rules apply to the relative ordering of the TLVs defined in this section.
定義されたTLVsはTLVsを特定するどんなインタフェースにも続かなければなりません。 規則は全くこのセクションで定義されたTLVsを注文する親類に適用されません。
Type Length Description
----------------------------------
512 8 REFERENCE_COUNT
513 8 SEVERITY
514 8 GLOBAL_TIMESTAMP
515 8 LOCAL_TIMESTAMP
516 variable ERROR_STRING
長さの記述をタイプしてください。---------------------------------- 512 8REFERENCE_COUNT513 8SEVERITY514 8GLOBAL_TIMESTAMP515 8LOCAL_TIMESTAMP516の可変ERROR_STRING
The Reference Count TLV has the following format:
Reference Count 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照カウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
このアラームが報告ノードで決定するように繰り返されたという回の数。 この分野をゼロに設定してはいけません、そして、この分野セットでゼロに受け取られたTLVsを無視しなければなりません。
Only one Reference Count TLV may be included in an object.
オブジェクトに1Reference Count TLVだけを含んでもよいです。
The Severity TLV has the following format:
Severity 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|影響| 厳しさ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
この分野は予約されています。 それは、トランジットノードによって世代のときにゼロに設定しなければならなくて、領収書の上で無視しなければならなくて、変わりがない状態で進めなければならなくて、非審査されました。
Berger Standards Track [Page 6] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[6ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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)
値の定義----- --------------------- 0 不特定の影響の1つのNon-サービスのAffecting(データ通信量は中断しなかった)2Service Affecting(データ通信量は中断されます)
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
値の定義----- ---------- 0 1人のクリアされた不確定の2重要な3主要な4未成年者5の警告
Only one Severity TLV may be included in an object.
オブジェクトに1Severity TLVだけを含んでもよいです。
The Global Timestamp TLV has the following format:
Global Timestamp 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グローバルなタイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berger Standards Track [Page 7] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[7ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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時0分0秒以来の秒数を示します。 それらが地方の時計によって使用されるなら、今回は飛躍秒を含むかもしれません、そして、SHOULDはグローバルな時間がそれらのレポートで費やされるならアラームが他のシステム(Management Planeなどの)を通して報告されるときノードによって使用されるのと同じ時間的価値を含んでいます。
Only one Global Timestamp TLV may be included in an object.
オブジェクトに1Global Timestamp TLVだけを含んでもよいです。
The Local Timestamp TLV has the following format:
Local Timestamp 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのタイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
オブジェクトに1Local Timestamp TLVだけを含んでもよいです。
The Error String TLV has the following format:
Error String 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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //誤りString(NULLはディスプレイストリングを水増しした)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berger Standards Track [Page 8] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[8ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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.
誤り/アラームのタイプの代理をする米国-ASCIIにおける一連のキャラクタ。 このストリングは、ヌル文字を使用することで次の最も大きい4バイトの境界に水増しされます。 並べられた状態でストリングが32ビットであるときに、ヌル詰め物は必要ではありません。 誤りストリングの内容は実装に依存しています。 状態タイプが例のストリングのリストのために[GR833]のAppendicesに記載されているのを見てください。 注意の長さは、そっと歩くのを含んでいます。
Multiple Error String TLVs may be included in an object.
複数のError String TLVsがオブジェクトに含まれるかもしれません。
3.1.2. Procedures
3.1.2. 手順
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オブジェクトはPathと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.
このドキュメントSHOULDで定義された拡大を支えるノードは今後の使用のために容認されたALARM_SPECオブジェクトからのどんなアラーム情報も保存します。 すべてのALARM_SPECオブジェクトが対応するPathの通っている変更されていない川下がメッセージであったならPathメッセージSHOULDで受信されました。 すべてのALARM_SPECオブジェクトが対応するResvの通っている変更されていない上流がメッセージであったならResvメッセージSHOULDで受信されました。 ALARM_SPECオブジェクトは、伝えられたResvメッセージで対応するResv Messagesに受け取られたすべてのALARM_SPECオブジェクトのコピーを含んでいることによって、合併されています。
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のためにPathと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
全部で、ケース、適切なError Node Address、Error Code、およびError Valuesは用意ができなければなりません(Error CodeとError Valuesについての議論に関して以下を見てください)。 InPlaceとNotGuilty旗が中に意味を持っているだけであるとき、ERROR_SPECは反対して、それらはSHOULD NOTです。設定されます。 TLVs SHOULDはALARM_SPECが反対する含まれているコネがもしあればインタフェースを特定するということであり、アラームと交際しました。 TLVsが中でインタフェースを特定するために中で[RFC3471]を定義した、_ID ERROR_SPECが反対するなら、[RFC3473]SHOULDは、このために使用されますが、タイプ4と5(コンポーネントインタフェース)が推奨しないTLVs[RFC4201]とSHOULD NOTが使用されることに注意します。 また、TLVs SHOULDが厳しさ(厳しさTLV)を示すために含まれていて、時間(グローバルなTimestamp、そして/または、Local Timestamp TLVs)、および(要約)はアラームに関連している(誤りString TLV)を結びます。 参照はTLV MAYを数えます、また、含まれていて、回数を示すために、アラームが報告ノードで繰り返されました。 他のノードから受け取られたALARM_SPECオブジェクトは地方のALARM_SPECオブジェクトの追加によって影響を与えられません、すなわち、それらが上で説明されるように処理され続けています。 それの選択は、驚かせるか、または驚かせます。
Berger Standards Track [Page 9] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[9ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
advertise and which to omit is a local policy matter, and may be configurable by the user.
広告を出す、どれを省略するか、ローカルの方針問題であり、ユーザは構成可能であるかもしれません。
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は、ノードによって広告に掲載された他の情報に比例しているアラームの発生の時間参照を提供するのに使用されます。 グローバルなタイムスタンプSHOULD、絶対時間参照を維持するノードの上で使用されてください。 ともに、タイムスタンプTLVsは同時に、使用されるかもしれません。
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オブジェクトSHOULD NOT、「コミュニケーションが禁止したアラーム」状態にあるLSPsのPathとResv州に追加されてください。 ALARM_SPECオブジェクトは「行政上ダウンしてください」という状態にあるLSPsの州に追加されるかもしれません。 これらの州はAdmin_StatusオブジェクトのIとAビットによって示されます。 セクション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.
ローカルのアラーム情報を取り除くために、ノードは出発しているPathと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メッセージに適用されます。 1つのメッセージから次までのALARM_SPECオブジェクトにおける変化が特定のALARM_SPECオブジェクトのコンテンツ、またはオブジェクトが提示するALARM_SPECの数における変化に変更を含むかもしれないことに注意してください。 すべてがALARM_SPECオブジェクトSHOULDで変化します。引き金のメッセージとして、処理されます。
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.
そして、上の指示に続かないこと、特に、ものが“SHOULD"をラベルした、「」 適切に存在ではなく、アラーム情報をもたらすべきであるかもしれないか、または完全にコミュニケートしているべきです。
3.1.3. Error Codes and Values
3.1.3. エラーコードと値
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 CodesとValuesはものがERROR_SPECでオブジェクトを使用したのと同じです。 ERROR_SPECとALARM_SPECオブジェクトの両方がある使用のための新しいError Code値は、他の規格によって定義されたアラームタイプをサポートするために割り当てられるかもしれません。
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新しいError Codeを定義します。 Error Codeは値31を使用して、「アラーム」と呼ばれます。 Error Codeが「アラーム」であるときにError Values分野で使用される値は値がAlarm MIBのIANA ITU ALARM-TC-MIBのIANAItuProbableCause Textual Conventionで[RFC3877]を定義したのと同じです。 これらの値がIANAによって管理されることに注意してください。 http://www.iana.org を見てください。
Berger Standards Track [Page 10] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[10ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
3.1.4. Backwards Compatibility
3.1.4. 遅れている互換性
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オブジェクトのサポートはOPTIONALです。 非サポートノードはノードに変更されていなくオブジェクトを通すでしょう([RFC2205]で定義された規則に従って)、ALARM_SPECオブジェクトにはフォーム11bbbbbbの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.
これは、アラーム情報がそれの或るものがアラーム情報、およびいくつかに関するコミュニケーションをサポートするノードの収集から造られたネットワークで集められて、調べられるのをどれが許容しないか許します。
3.2. Controlling Alarm Communication
3.2. アラームコミュニケーションを制御します。
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オブジェクトで運ばれるようにAdministrative Status情報で制御されます。 アラームコミュニケーションが抑制的であることであるときに、それは、Iビットと呼ばれて、新しいビットが定義されるのを示します。 このビットの定義は[RFC3473]のセクション7で定義された手順を変更しません。
3.2.1. Updated Admin_Status Object
3.2.1. アップデートされたアドミン_状態オブジェクト
The format of the Admin_Status object is updated to include the I bit:
Iビットを含むようにAdmin_Statusオブジェクトの形式をアップデートします:
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム(196)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|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ビットのWhenは、セットして、アラームコミュニケーションがLSPのために無効にされて、ノードSHOULD NOTがローカルのアラーム情報を加えるのを示します。
See Section 7.1 of [RFC3473] for the definition of the remaining
bits.
残っているビットの定義に関して[RFC3473]のセクション7.1を見てください。
3.2.2. Procedures
3.2.2. 手順
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
Iビットは、[RFC3473]のセクション7.2と7.3で定義された手順を用いることで設定されて、きれいにされるかもしれません。 受信するノード、(発生、)、AかIビットがあるAdmin_Status物は(1)を設定して、SHOULDは合っているLSPの出発しているPathからすべての局所的に発生したアラーム情報を取り除いて、Resvは通信します。 ノードが受信する、(発生、)、Admin_StatusがAと共に反対して、Iビットが(0)をクリアして、存在しているローカルのアラーム情報があって、それがSHOULDである、地方を加えてください。
Berger Standards Track [Page 11] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[11ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
alarm information to the matching LSP's outgoing Path and Resv messages.
合っているLSPの出発しているPathと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).
Admin_Status物のコンテンツは非局所的に発生したALARM_SPEC物の処理に影響を与えてはいけません。 IとAビットの受け取られていているか伝えられた設定にかかわらず変わりがない状態ですなわち、容認されたALARM_SPEC物を進めなければなりません。 Admin_Status物の欠如が[RFC3473]単位ですべてが(0)のゼロを合わせるように設定する値を含む物を受けるのに同等であることに注意してください。
I bit related processing behavior MAY be overridden locally based on configuration.
振舞いを処理しながら関係づけられたIビットは構成に基づいて局所的にくつがえされるかもしれません。
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ビットがセットした状態でLSPsへのNotifyメッセージを発生させるとき、本書では説明されたTLVsはNotifyメッセージで送られたERROR_SPEC物に追加されるかもしれません。
3.3. Message Formats
3.3. メッセージ・フォーマット
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>
<経路メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<の明白な_ルート>]<ラベル_要求>[<保護>]を評価します[<ラベル_は>を…設定しました]。 [<セッション_属性>] [<は_要求>に通知します] [<アドミン_状態>] [<方針_データ>] [<アラーム_仕様>] <送付者記述子>。
<sender descriptor> is not modified by this document.
<送付者記述子>はこのドキュメントによって変更されません。
Berger Standards Track [Page 12] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[12ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
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>
<Resvメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>を評価します[<RESV_は>を確認します][<範囲>][<は_要求>に通知します][<アドミン_状態>][<方針_データ>…]。 [<アラーム_仕様>] <様式><流れ記述子リスト>。
<flow descriptor list> is not modified by this document.
<流れ記述子リスト>はこのドキュメントによって変更されません。
3.4. Relationship to GMPLS UNI
3.4. GMPLS UNIとの関係
[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 イングレスか出口コアノード5月のフィルタが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 同様に、出口コアノードは、川下に発信するというPathメッセージに関してオーバレイネットワークに報告するアラームを要求しないのを選ぶかもしれません。
Berger Standards Track [Page 13] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[13ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
3.5. Relationship to GMPLS E-NNI
3.5. GMPLS電子NNIとの関係
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.
本書では説明された拡大は[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 同様に、イングレスコア出口/ノードは、川下に発信するというPathメッセージに関して報告するアラームを要求しないのを選ぶかもしれません。
4. Security Considerations
4. セキュリティ問題
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.
オペレータの中には敏感であるとしてアラームが情報であると考える人もいるかもしれません。 これがそうである環境を支持するために、実現SHOULDはユーザにドメイン境界でそれらを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
[RFC3473]のセキュリティ問題が破られるなら、アラーム情報がだまされるかもしれないことに注意されるかもしれません。 詳細が情報だけに提供されて、情報を伝えるメッセージの交換を超えてプロトコル動作をもたらさないので、そのようなスプーフィングは、高々煩わしく、コントロール飛行機性能のわずかな退行を引き起こすでしょう。 だますのを許容できるくらいセキュリティが破ることができるプロトコルがその時情報を驚かせるなら
Berger Standards Track [Page 14] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[14ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
considerably more interesting and exciting damage can be caused by spoofing other elements of the protocol messages.
プロトコルメッセージの他の要素をだますことによって、かなりよりおもしろくておもしろい損害をもたらすことができます。
5. IANA Considerations
5. IANA問題
IANA administered assignment of new values for namespaces defined in this document and reviewed in this section.
IANAは本書では定義されて、このセクションで見直された名前空間のために新しい値の課題を管理しました。
5.1. New RSVP Object
5.1. 新しいRSVP物
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は「RSVPパラメタ」登録のセクションが http://www.iana.org/assignments/rsvp-parameters で場所を見つけた「クラス名、クラス番号、およびクラスタイプ」で以下の課題をしました。
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、1RFC4783が予約したC-タイプ=と等しいです。 (C-タイプ値は、ERRORのために_SPECを定義しますが、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、=2RFC4783が予約したC-タイプと等しいです。 (C-タイプ値は、ERRORのために_SPECを定義しますが、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は_ID ALARM_SPECであるなら反対します: クラス=198、C-タイプは_ID ERROR_SPEC[RFC3473]であるならIPv4として3RFCと4783Definition同じ状態で等しいです。
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は_ID ALARM_SPECであるなら反対します: クラス=198、C-タイプは_ID ERROR_SPEC[RFC3473]であるならIPv6として4RFCと4783Definition同じ状態で等しいです。
The ALARM_SPEC object uses the Error Code and Error Values from the ERROR_SPEC object.
ALARM_SPEC物はERROR_SPEC物からError CodeとError Valuesを使用します。
Berger Standards Track [Page 15] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[15ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
5.2. New Interface ID Types
5.2. 新しいインタフェースIDはタイプされます。
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は「GMPLSシグナリングパラメタ」登録のセクションが http://www.iana.org/assignments/gmpls-sig-parameters で場所を見つけた「インタフェース_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 8REFERENCE_COUNT RFC4783 513 8SEVERITY RFC4783 514 8GLOBAL_TIMESTAMP RFC4783 515 8LOCAL_TIMESTAMP RFC4783 516の可変ERROR_STRING RFC4783
5.3. New Registry for Admin-Status Object Bit Fields
5.3. アドミン状態物のビット分野への新しい登録
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]
値の名前参照----------- -------------------------------- ----------------- 0×80000000は進行中(D)で(R) [RFC3473/RFC3471]0x00000010Inhibit Alarm Communication(I)RFC4783 0×00000004Testing(T)[RFC3473/RFC3471]0×00000002Administrativelyを(A)[RFC3473/RFC3471]0×00000001Deletionの下側に反映します。[RFC3473/RFC3471]
5.4. New RSVP Error Code
5.4. 新しいRSVPエラーコード
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のアラームRFC4783
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.
このError CodeのためのサブコードのError Valueには、Alarm MIB[RFC3877]でIANA ITU ALARM-TC-MIBのIANAItuProbableCause Textual Conventionで定義された値と意味と同じ値と意味があります。 管理されて、これらの値が既にそうであることに注意してください。IANA。
Berger Standards Track [Page 16] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[16ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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の機能的な仕様」、RFC2205、1997年9月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
[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.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, September 2004.
[RFC3877] チスホルムとS.とD.Romascanu、「アラーム管理情報ベース(MIB)」、RFC3877、2004年9月。
[M.3100] ITU Recommendation M.3100, "Generic Network Information
Model", 1995.
[M.3100]ITU推薦M.3100、「一般的なネットワーク情報モデル」、1995。
6.2. Informative References
6.2. 有益な参照
[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)におけるリンクバンドリング」、RFC4201、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、「維持をネットワークでつないでください」 3は、1999年2月に「要素と輸送監視メッセージをネットワークでつないでください。」(GR833コア)と発行します。
[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.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、2005年10月。
Berger Standards Track [Page 17] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[17ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
[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.(他)は「Automatically Switched Optical Network(ASON)を支持してMPLS(GMPLS)RSVP-TEシグナリング用法を広めました」、ProgressのWork、2005年7月。
7. Acknowledgments
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.
多くの人々から貴重なコメントと入力を受け取りました、ウェスDoonan、DISMAN参照のためのバートWijnen、およびDISMAN WG相互作用を開始させるためのトムPetchを含んでいて。 また、私たちは彼らの貴重なコメントについてデヴィッドBlack、ラース・エッゲルト、ラスHousley、ダンRomascanu、およびマグヌスWesterlundに感謝します。
8. Contributors
8. 貢献者
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研究室、ニュージャージー 07748、米国が電話をする余地のMT D1-3C22 200ローレルアベニューミドルタウン: (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
イーゴリBryskinエードリアンファレルMovazはInc.の古い犬のコンサルティング7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニア、22102をネットワークでつなぎます、米国電話: +44 (0) 1978 860944はメールされます: ibryskin@movaz.com メール: 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
西タスマン博士カリフォルニア95134サンノゼ(米国)が電話をするディミトリPapadimitriou(アルカテル)アルンSatyanarayanaフランシスWellesplein1シスコシステムズ、Inc B-2018アントウェルペン(ベルギー)170: +32 3 240-8491電話: +1 408 853-3206 メールしてください: dimitri.papadimitriou@alcatel.be メール: asatyana@cisco.com
Editor's Address
エディタのアドレス
Lou Berger LabN Consulting, L.L.C.
ルウバーガーLabN Consulting、L.L.C。
Phone: +1 301-468-9228 EMail: lberger@labn.net
以下に電話をしてください。 +1 301-468-9228 メールしてください: lberger@labn.net
Berger Standards Track [Page 18] RFC 4783 GMPLS - Communication of Alarm Information December 2006
バーガー標準化過程[18ページ]RFC4783GMPLS--アラーム情報2006年12月に関するコミュニケーション
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Berger Standards Track [Page 19]
バーガー標準化過程[19ページ]
一覧
スポンサーリンク
