Network Working Group A. Fredette, Ed.
Request for Comments: 4209 Hatteras Networks
Category: Standards Track J. Lang, Ed.
Sonos Inc.
October 2005
Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
高密度波長分割多重（DWDM）光回線システムのリンク管理プロトコル（LMP）
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 Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document.
リンク管理プロトコル（LMP）は、トラフィックエンジニアリング（TE）リンクを管理するために定義されています。その現在の形態では、LMPは、ピア・ノード、すなわち、シグナリングおよび/またはルーティングピアノードに焦点を当てています。この文書は、ピア・ノードと隣接する光回線システム（OLS）の間で使用できるようにLMPへの拡張を提案します。これらの拡張機能は、仲間の文書に記載されている「光リンクインタフェース要件」を満たすことを目的としています。
Networks are being developed with routers, switches, optical cross-connects (OXCs), dense wavelength division multiplexing (DWDM) optical line systems (OLSes), and add-drop multiplexors (ADMs) that use a common control plane (e.g., Generalized MPLS (GMPLS)) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
ネットワークは、共通の制御プレーン（例えば、一般MPLSを使用して、ルータ、スイッチ、光クロスコネクト（のOXC）、高密度波長分割多重（DWDM）光学ラインシステム（OLSes）、およびアドインドロップマルチプレクサ（ADM装置）を用いて開発されています（GMPLS））動的にプロビジョニングリソースへの保護および復元技術を使用して、ネットワークの存続を提供します。
The Link Management Protocol (LMP) is being developed as part of the GMPLS protocol suite to manage traffic engineering (TE) links [RFC4204]. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in Figure 1). In this document, extensions to LMP are proposed to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in [OLI]. It is assumed that the reader is familiar with LMP, as defined in [RFC4204].
リンク管理プロトコル（LMP）は、トラフィックエンジニアリング（TE）リンク[RFC4204]を管理するためのGMPLSプロトコルスイートの一部として開発されています。その現在の形態では、LMPは、すなわち、シグナリングピアノード及び/又はルーティング（例えば、OXCツーOXC、図1に示すように）、ピアノードに焦点を当てています。この文書では、LMPへの拡張は、それがピア・ノードと隣接する光回線システム（OLS）の間で使用されることを可能にすることが提案されています。これらの拡張機能は、[OLI]に記載の「光リンクインタフェース要件」を満たすことを目的としています。 [RFC4204]で定義されるように読者が、LMPに精通しているものとします。
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^
| |
+---------------------LMP---------------------+
Figure 1: LMP Model
図1：LMPモデル
Consider two peer nodes (e.g., two OXCs) interconnected by a wavelength-multiplexed link, i.e., a DWDM optical link (see Figure 1 above). Information about the configuration of this link and its current state is known by the two OLSes (OLS1 and OLS2). Allowing them to communicate this information to the corresponding peer nodes (OXC1 and OXC2) via LMP can improve network usability by reducing required manual configuration and by enhancing fault detection and recovery.
波長多重リンク、即ち、DWDM光リンク（上記図1参照）によって相互接続された2つのピア・ノード（例えば2つのOXC）を考えます。このリンクの構成とその現在の状態についての情報は、二つのOLSes（OLS1とOLS2）で知られています。それらは、LMPを介して対応するピア・ノード（OXC1とOXC2）にこの情報を通信することを可能にする必要な手動設定を低減することによって、障害検出および回復を増強することによって、ネットワークのユーザビリティを向上させることができます。
Information about the state of LSPs using the DWDM optical link is known by the peer nodes (OXC1 and OXC2), and allowing them to communicate this information to the corresponding OLSes (OLS1 and OLS2) is useful for alarm management and link monitoring. Alarm management is important because the administrative state of an LSP, known to the peer nodes (e.g., via the Admin Status object of GMPLS signaling [RFC3471]), can be used to suppress spurious alarm reporting from the OLSes.
DWDM光リンクを使用して、LSPの状態に関する情報は、ピア・ノード（OXC1とOXC2）によって知られており、それらは、対応するOLSes（OLS1とOLS2）にこの情報を通信することを可能にするアラーム管理及びリンクモニタリングのために有用です。ピア・ノードに知られているLSPの管理状態は、（例えば、[RFC3471]をGMPLSシグナリングの管理ステータスオブジェクトを介して）、OLSesから報告偽アラームを抑制するために使用することができるからである。アラーム管理が重要です
The model for extending LMP to OLSes is shown in Figure 2.
OLSesにLMPを拡張するためのモデルは、図2に示されています。
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
| +-----LMP-----+ +-----LMP-----+ |
| |
+----------------------LMP-----------------------+
Figure 2: Extended LMP Model
図2：拡張LMPモデル
In this model, a peer node may have LMP sessions with adjacent OLSes, as well as adjacent peer nodes. In Figure 2, for example, the OXC1- OXC2 LMP session can be used to build traffic-engineering (TE) links for GMPLS signaling and routing, as described in [RFC4204]. The OXC1-OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information about the configuration of the DWDM optical link and its current state and information about the state of LSPs using that link.
このモデルでは、ピア・ノードは、隣接OLSes、ならびに隣接ピア・ノードとのLMPセッションを有していてもよいです。 [RFC4204]に記載されているように、図2において、例えば、OXC1- OXC2 LMPセッションは、GMPLSシグナリングおよびルーティングのためのトラフィックエンジニアリング（TE）リンクを構築するために使用することができます。 OXC1 - OLS1とOXC2-OLS2 LMPセッションは、そのリンクを使用して、LSPの状態についてのDWDM光リンクの構成とその現在の状態情報に関する情報を交換するために使用されます。
The latter type of LMP sessions is discussed in this document. It is important to note that a peer node may have LMP sessions with one or more OLSes and an OLS may have LMP sessions with one or more peer nodes.
LMPセッションの後者のタイプは、この文書に記載されています。ピア・ノードは、1つ以上のOLSesとLMPセッションを有していてもよく、OLSは、1つ以上のピア・ノードとのLMPセッションを有していてもよいことに留意することが重要です。
Although there are many similarities between an LMP session between two peer nodes and an LMP session between a peer node and an OLS, there are some differences as well. The former type of LMP session is used to provide the basis for GMPLS signaling and routing. The latter type of LMP session is used to augment knowledge about the links between peer nodes.
2つのピア・ノードとピアノードとOLSの間のLMPセッションの間のLMPセッションの間に多くの類似点があるが、同様にいくつかの違いがあります。 LMPセッションの前者は、GMPLSシグナリングおよびルーティングのための基礎を提供するために使用されます。 LMPセッションの後者のタイプは、ピア・ノード間のリンクについての知識を増強するために使用されます。
A peer node maintains its peer node-to-OLS LMP sessions and its peer node-to-peer node LMP sessions independently. This means that it MUST be possible for LMP sessions to come up in any order. In particular, it MUST be possible for a peer node-to-peer node LMP session to come up in the absence of any peer node-to-OLS LMP sessions, and vice versa.
ピア・ノードは、独立してそのピアノード対OLS LMPセッションとそのピアノード・ツー・ピアノードLMPセッションを維持します。これは、LMPセッションは、任意の順序で出てくるすることが可能でなければならないことを意味しています。ピア・ノード・ツー・ピアノードLMPセッションは、任意のピア・ノード・ツー・OLS LMPセッションが存在しないこと、およびその逆に思い付くするため、特に、それが可能でなければなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The reader is assumed to be familiar with the terminology in [RFC4204].
読者は[RFC4204]での用語に精通していると仮定されます。
DWDM: Dense wavelength division multiplexing
DWDM：高密度波長分割多重
OLS: Optical line system
OLS：光回線システム
Opaque:
オペーク：
A device is called X-opaque if it examines or modifies the X aspect of the signal while forwarding an incoming signal from input to output.
入力から出力への着信信号を転送しながら、信号のX局面を調べるか、変更する場合、デバイスは、X-不透明と呼ばれています。
OXC: Optical cross-connect
OXC：光クロスコネクト
Transparent:
トランスペアレント：
As defined in [RFC4204], a device is called X-transparent if it forwards incoming signals from input to output without examining or modifying the X aspect of the signal. For example, a Frame Relay switch is network-layer transparent; an all-optical switch is electrically transparent.
[RFC4204]で定義されるように、それが検査や信号のX局面を変更することなく、入力から出力への着信信号を転送する場合、デバイスは、X透明と呼ばれています。例えば、フレームリレースイッチは、透明なネットワーク層です。全光スイッチは、電気的に透明です。
This document focuses on extensions required for use with opaque OLSes. In particular, this document is intended for use with OLSes having SONET, SDH, and Ethernet user ports.
この文書では、不透明なOLSesで使用するために必要な拡張に焦点を当てています。特に、この文書は、SONET、SDH、およびイーサネット・ユーザ・ポートを有するOLSesで使用するために意図されています。
At the time of this writing, work is ongoing in the area of fully transparent wavelength routing; however, it is premature to identify the necessary information to be exchanged between a peer node and an OLS in this context. Nevertheless, the protocol described in this document provides the necessary framework in which to exchange additional information that is deemed appropriate.
この記事の執筆時点では、作業が完全に透明波長ルーティングの分野で進行中です。しかし、ピア・ノード及びこの文脈でOLSの間で交換されるために必要な情報を識別するために時期尚早です。それにもかかわらず、本文書に記載のプロトコルが適切であると考えられる付加的な情報を交換するために必要なフレームワークを提供します。
LMP currently consists of four main procedures, of which the first two are mandatory and the last two are optional:
LMPは、現在、最初の二つは必須であり、そして最後の二つは任意である4つの主要な手順で構成されています。
1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management
1.コントロールチャネル管理2.リンクプロパティ相関3.リンク検証4.障害管理
All four functions are supported in LMP-WDM.
すべての4つの機能は、LMP-WDMでサポートされています。
As in [RFC4204], we do not specify the exact implementation of the control channel; it could be, for example, a separate wavelength, fiber, Ethernet link, an IP tunnel routed over a separate management network, a multi-hop IP network, or the overhead bytes of a data link.
[RFC4204]のように、我々は、制御チャネルの正確な実装を指定しないでください。それは独立した管理ネットワーク、マルチホップIPネットワーク、またはデータ・リンクのオーバーヘッドバイトを介してルーティング、例えば、別々の波長、光ファイバ、イーサネットリンク、IPトンネルであってもよいです。
The control channel management for a peer node-to-OLS link is the same as for a peer node-to-peer node link, as described in [RFC4204].
[RFC4204]に記載されているように、ピア・ノード・ツー・OLSリンクの制御チャネル管理は、ピア・ノード・ツー・ピアノードリンクの場合と同じです。
To distinguish between a peer node-to-OLS LMP session and a peer node-to-peer node LMP session, a new LMP-WDM CONFIG object is defined (C-Type = 2). The format of the CONFIG object is as follows:
ピア・ノード・ツー・OLS LMPセッションとピア・ノード・ツー・ピアノードLMPセッションを区別するために、新しいLMP-WDM CONFIGオブジェクトは、（C-タイプ= 2）で定義されています。次のようにCONFIGオブジェクトの形式は次のとおりです。
Class = 6
クラス= 6
o C-Type = 2, LMP-WDM_CONFIG
O Cタイプ= 2、LMP-WDM_CONFIG
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W|O| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
WDM: 1 bit
WDM：1ビット
This bit indicates support for the LMP-WDM extensions defined
in this document.
OLS: 1 bit
OLS：1ビット
If set, this bit indicates that the sender is an optical line
system (OLS). If clear, this bit indicates that the sender is
a peer node.
The LMP-WDM extensions are designed for peer node-to-OLS LMP sessions. The OLS bit allows a node to identify itself as an OLS or a peer node. This is used to detect misconfiguration of a peer node-to-OLS LMP session between two peer nodes or a peer node-to-peer node LMP session between a peer node and an OLS.
LMP-WDM拡張機能は、ピア・ノード・ツー・OLS LMPセッションのために設計されています。 OLSのビットは、ノードがOLSまたはピア・ノードとして自身を識別することを可能にします。これは、2つのピア・ノード間のピア・ノード・ツー・OLS LMPセッションまたはピア・ノードとOLSの間のピア・ノード・ツー・ピアノードLMPセッションの設定ミスを検出するために使用されます。
If the node does not support the LMP-WDM extensions, it MUST reply to the Config message with a ConfigNack message.
ノードがLMP-WDM拡張をサポートしていない場合、それはConfigNackメッセージでConfigメッセージに返答しなければなりません。
If a peer node that is configured to run LMP-WDM receives a Config message with the OLS bit clear in LMP-WDM_CONFIG object, it MUST reply to the Config message with a ConfigNack message.
LMP-WDMを実行するように構成されたピア・ノードがLMP-WDM_CONFIGオブジェクト内OLSビットでConfigメッセージがクリア受信した場合、それはConfigNackメッセージを構成メッセージに応答しなければなりません。
The Test procedure used with OLSes is the same as described in [RFC4204]. The VerifyTransportMechanism (included in the BeginVerify and BeginVerifyAck messages) is used to allow nodes to negotiate a link verification method and is essential for line systems that have access to overhead bytes rather than the payload. The VerifyId (provided by the remote node in the BeginVerifyAck message and used in all subsequent Test messages) is used to differentiate Test messages from different LMP Link Verification procedures. In addition to the Test procedure described in [RFC4204], the trace monitoring function of [RFC4207] may be used for link verification when the OLS user ports are SONET or SDH.
OLSesと共に使用される試験手順は、[RFC4204]に記載のものと同じです。 （BeginVerifyとBeginVerifyAckメッセージに含まれる）VerifyTransportMechanismノードがリンク検証方法をネゴシエートできるようにするために使用され、オーバーヘッドバイトではなくペイロードへのアクセスを有するラインシステムのために必須です。 VerifyId（BeginVerifyAckメッセージにリモートノードによって提供され、それ以降のすべてのテストメッセージに使用される）は、異なるLMPリンク検証手順からテストメッセージを区別するために使用されます。 OLSのユーザポートがSONETまたはSDHである場合、[RFC4204]に記載の試験手順に加えて、[RFC4207]のトレース監視機能は、リンク検証のために使用することができます。
In a combined LMP and LMP-WDM context, there is an interplay between the data links being managed by peer node-to-peer node LMP sessions and peer node-to-OLS LMP sessions. For example, in Figure 2, the OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1, and the OXC2-OLS2 LMP session manages the data links between OXC2 and OLS2. However, the OXC1-OXC2 LMP session manages the data links between OXC1 and OXC2, which are actually a concatenation of the data links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and the data links between OXC2 and OLS2. It is these concatenated links that comprise the TE links that are advertised in the GMPLS TE link state database.
合わせたLMPとLMP-WDMコンテキストにおいて、ピア・ノード・ツー・ピアノードLMPセッションとピア・ノード・ツー・OLS LMPセッションによって管理されているデータ・リンク間の相互作用があります。例えば、図2において、OXC1 - OLS1 LMPセッションはOXC1とOLS1との間のデータリンクを管理し、OXC2-OLS2 LMPセッションはOXC2とOLS2との間のデータリンクを管理します。しかし、OXC1-OXC2 LMPセッションは、実際にOXC1とOLS1、OLS1とOLS2間のDWDMスパン、およびOXC2とOLS2の間のデータリンク間のデータリンクの連結ですOXC1とOXC2間のデータリンクを管理します。これは、GMPLS TEリンクステートデータベースでアドバタイズされているTEリンクを含み、これらの連結リンクです。
The implication of this is that when the data links between OXC1 and OXC2 are being verified, using the LMP link verification procedure, OLS1 and OLS2 need to make themselves transparent with respect to these concatenated data links. The coordination of verification of OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the responsibility of the peer nodes, OXC1 and OXC2.
これの意味するところはOXC1とOXC2間のデータリンクがLMPリンク検証手順を使用して、検証されているとき、OLS1とOLS2は、これらの連結データリンクに関して自体は透明にする必要があるということです。この透明性を確保するOXC1 - OLS1とOXC2-OLS2データリンクの検証のコーディネートは、ピア・ノード、OXC1とOXC2の責任です。
It is also necessary for these peer nodes to understand the mappings between the data links of the peer node - OLS LMP session and the concatenated data links of the peer node - peer node LMP session.
OLS LMPセッションとピア・ノードの連結データリンク - - ピア・ノードLMPセッションこれらのピア・ノードがピア・ノードのデータリンク間のマッピングを理解することも必要です。
As in [RFC4204], the LinkSummary message is used to synchronize the Interface_Ids and correlate the properties of the TE link. (Note that the term "TE link" originated from routing/signaling applications of LMP, and this concept does not necessarily apply to an OLS. However, the term is used in this document to remain consistent with LMP terminology.) The LinkSummary message includes one or more DATA_LINK objects. The contents of the DATA_LINK object consist of a series of variable-length data items called Data Link sub-objects describing the capabilities of the data links.
[RFC4204]のように、LinkSummaryメッセージはInterface_Idsを同期させ、TEリンクの特性を相関させるために使用されます。 （用語「TEリンクが」LMPのアプリケーションシグナリング/ルーティング由来なお、この概念は、必ずしもOLSには適用されない。しかし、この用語は、LMP用語と一貫性を維持するために、この文書で使用されている。）LinkSummaryメッセージは、一つ以上のDATA_LINKオブジェクト。 DATA_LINKオブジェクトの内容は、データリンクの機能を記述するデータリンクサブオブジェクトと呼ばれる可変長のデータ項目の一連から成ります。
In this document, several additional Data Link sub-objects are defined to describe additional link characteristics. The link characteristics are, in general, those needed by the CSPF to select the path for a particular LSP. These link characteristics describe the specified peer node-to-OLS data link, as well as the associated DWDM span between the two OLSes.
このドキュメントでは、いくつかの追加のデータリンクサブオブジェクトは、追加のリンク特性を記述するために定義されています。リンク特性は、一般的に、特定のLSPのためのパスを選択するCSPFによって必要とされるものです。これらのリンク特性は、二つOLSes間の指定されたピアノード対OLSデータリンク、ならびに関連したDWDMスパンを記述する。
The format of the Data Link sub-objects follows the format described in [RFC4204] and is shown below for readability:
データリンクサブオブジェクトのフォーマットは、[RFC4204]に記述されたフォーマットに従い、読みやすくするために以下に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Sub-object contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
Type: 8 bits
タイプ：8ビット
The Type indicates the type of contents of the sub-object.
タイプサブオブジェクトのコンテンツの種類を示します。
Length: 8 bits
長さ：8ビット
The Length field contains the total length of the sub-object in
bytes, including the Type and Length fields. The Length MUST
be at least 4, and MUST be a multiple of 4.
The following link characteristics are exchanged on a per data link basis.
以下のリンクの特性は、データリンクごとに交換されます。
The main purpose of the Link Group ID is to reduce control traffic during failures that affect many data links. A local ID may be assigned to a group of data links. This ID can be used to reduce the control traffic in the event of a failure by enabling a single ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see Section 2.4.1) to be used for a group of data links instead of individual ChannelStatus messages for each data link. A data link may be a member of multiple groups. This is achieved by including multiple Link Group ID sub-objects in the LinkSummary message.
リンクグループIDの主な目的は、多くのデータリンクに影響を与える障害時の制御トラフィックを削減することです。ローカルIDは、データ・リンクのグループに割り当ててもよいです。このIDは、代わりのための個々のチャネルステータスメッセージのデータリンクのグループに使用される（セクション2.4.1参照）LINK GROUP CHANNEL_STATUSオブジェクトと単一チャネルステータスメッセージを有効にすることによって、障害が発生した場合に制御トラフィックを減少させるために使用することができます各データリンク。データリンクは、複数のグループのメンバであってもよいです。これは、LinkSummaryメッセージに複数のリンクグループIDのサブオブジェクトを含むことによって達成されます。
The Link Group ID feature allows Link Groups to be assigned based on the types of fault correlation and aggregation supported by a given OLS. From a practical perspective, the Link Group ID is used to map (or group) data links into "failable entities" known primarily to the OLS. If one of those failable entities fails, all associated data links are failed and the peer node is notified with a single message.
リンクグループID機能は、リンクグループが指定されたOLSでサポートされている障害の相関関係と集約の種類に基づいて割り当てることができます。実用的な観点から、リンクグループIDは、主OLSに知られている「failable実体」にマッピングするために使用される（またはグループ）のデータリンクされています。これらfailableエンティティの一つに障害が発生した場合、すべての関連するデータリンクが失敗しているとピア・ノードは、単一のメッセージで通知されます。
For example, an OLS could create a Link Group for each laser in the OLS. The data links associated with each laser would then each be assigned the Link Group ID for that laser. If a laser fails, the OLS would then report a single failure affecting all of the data links with a Link Group ID of the failed laser. The peer node that receives the single failure notification then knows which data links are affected. Similarly, an OLS could create a Link Group ID for a fiber, to report a failure affecting all of the data links associated with that fiber if a loss-of-signal (LOS) is detected for that fiber.
例えば、OLSはOLSで各レーザのためのリンクグループを作成することができます。各レーザに関連付けられたデータリンクは、それぞれがそのレーザーのためのリンクグループのIDが割り当てられます。レーザーが失敗した場合、OLSは、失敗したレーザーのリンクグループIDとのデータリンクのすべてに影響を与える一つの失敗を報告します。単一障害通知を受信したピア・ノードは、データリンクが影響を受けているかを知っています。同様に、OLSは、ロスオブシグナル（LOS）が、その繊維のために検出された場合、そのファイバに関連付けられているデータ・リンクのすべてに影響を与える障害を報告するために、繊維のリンクグループIDを作成することができます。
The format of the Link Group ID sub-object (Type = 3, Length = 8) is as follows:
リンクグループIDサブオブジェクトのフォーマット（タイプ= 3、長さ= 8）は以下の通りであります：
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
Link Group ID: 32 bits
リンクグループID：32ビット
Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of Link Group
0xFFFFFFFF by default.
This identifies the SRLGs of which the data link is a member. This information may be configured on an OLS by the user and used for diverse path computation (see [RFC4202]).
これは、データリンクがメンバーであるSRLGsを識別する。この情報は、ユーザによってOLSに構成され、多様な経路計算のために使用することができる（[RFC4202]を参照）。
The format of the SRLG sub-object (Type = 4, Length = (N+1)*4 where N is the number of SRLG values) is as follows:
SRLGサブオブジェクトのフォーマット（タイプ= 4、長さ=（N + 1）* NがSRLG値の数である4）は以下の通りであります：
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #(N-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
Shared Risk Link Group Value: 32 bits
共有リスクリンクグループ値：32ビット
See [RFC4202]. List as many SRLGs as apply.
[RFC4202]を参照してください。適用する限り多くのSRLGsの一覧を表示します。
This object provides an estimate of the BER for the data link.
このオブジェクトは、データリンクのBERの推定値を提供します。
The Bit Error Rate (BER) is the proportion of bits that have errors relative to the total number of bits received in a transmission, usually expressed as ten to a negative power. For example, a transmission might have a BER of "10 to the minus 13", meaning that, out of every 10,000,000,000,000 bits transmitted, one bit may be in error. The BER is an indication of overall signal quality.
ビット誤り率（BER）は、通常、負のパワーに10として表さ送信において受信されたビットの総数に対する相対誤差を有するビットの割合です。例えば、送信は、送信毎10,000,000,000,000ビットのうち、1ビットは誤りであってもよく、つまり、「10マイナス13」のBERを有するかもしれません。 BERは、全体的な信号品質の指標です。
The format of the BER Estimate sub-object (Type = 5; Length = 4) is as follows:
BER推定サブオブジェクト（タイプ= 5;長さ= 4）のフォーマットは以下の通りであります：
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 | BER | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
BER: 8 bits
BER：8ビット
The exponent from the BER representation described above. That
is, if the BER is 10 to the minus X, the BER field is set to X.
This indicates whether the link is protected by the OLS. This information can be used as a measure of link capability. It may be advertised by routing and used by signaling as a selection criterion, as described in [RFC3471].
これは、リンクはOLSによって保護されているかどうかを示します。この情報は、リンク機能の尺度として使用することができます。 [RFC3471]に記載されているように、それは、選択基準としてシグナリングすることによってルーティングによってアドバタイズして用いてもよいです。
The format of the Optical Protection sub-object (Type = 6; Length = 4) is as follows:
光保護サブオブジェクト（タイプ= 6;長さ= 4）のフォーマットは以下の通りであります：
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) | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
Link Flags: 6 bits
リンクフラグ：6ビット
Encoding for Link Flags is defined in Section 7 of [RFC3471].
リンクフラグのエンコードは、[RFC3471]のセクション7で定義されています。
This indicates the total distance of fiber in the OLS. This may be used as a routing metric or to estimate delay.
これは、OLSにおける繊維の総距離を示します。これは、ルーティング・メトリックとして使用してもよいし、遅延を推定します。
The format of the Total Span Length sub-object (Type = 7, Length = 8) is as follows:
総スパン長サブオブジェクトのフォーマット（タイプ= 7、長さ= 8）は以下の通りであります：
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Span Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
Span Length: 32 bits
スパン長さ：32ビット
This value represents the total length of the WDM span in
meters, expressed as an unsigned (long) integer.
The administrative group (or Color) to which the data link belongs.
データリンクが属する管理グループ（またはカラー）。
The format of the Administrative Group sub-object (Type = 8, Length = 8) is as follows:
管理グループのサブオブジェクトのフォーマット（タイプ= 8、長さ= 8）は以下の通りであります：
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
Administrative Group: 32 bits
管理グループ：32ビット
A 32-bit value, as defined in [RFC3630].
[RFC3630]で定義されるように32ビット値、。
The Fault Management procedure used between a peer and an OLS follows the procedures described in [RFC4204]; some further extensions are defined in this section. The information learned from the OLS-peer fault management procedures may be used to trigger peer-peer LMP fault management, or may be used to trigger GMPLS signaling/routing procedures directly.
ピアとOLSの間で使用される障害管理手順は、[RFC4204]に記載の手順に従います。いくつかの更なる拡張は、このセクションで定義されています。 OLSピア障害管理手順から学習した情報は、ピア・ツー・ピアLMP障害管理、または直接GMPLSシグナリング/ルーティング手続きをトリガするために使用されてもよいをトリガするために使用されてもよいです。
Fault management consists of three major functions:
障害管理は、三つの主要な機能で構成されています。
1. Fault Detection 2. Fault Localization 3. Fault Notification
1.障害検出2.障害局在3.障害通知
The fault detection mechanisms are the responsibility of the individual nodes and are not specified as part of this protocol.
障害検出メカニズムは、個々のノードの責任であり、このプロトコルの一部として指定されていません。
Fault detection mechanisms may include a Bit Error Rate (BER) exceeding a threshold, and loss-of-signal (LOS) and SONET/SDH-level errors. It is the responsibility of the OLS to translate these failures into (Signal) OK, Signal Failure (SF), or Signal Degrade (SD), as described in [RFC4204].
検出機構は、閾値、および信号損失（LOS）及びSONET / SDHレベルのエラーを超えるビット誤り率（BER）を含むことができるフォールト。 [RFC4204]で説明したように、（信号）OK、信号障害（SF）、または信号劣化（SD）にこれらの失敗を翻訳するためにOLSの責任です。
That is, an OLS uses the messages defined in the LMP fault localization procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse messages) to inform the adjacent peer node of failures it has detected, in order to initiate the LMP fault localization procedures between peer nodes, but it does not participate in those procedures.
すなわち、OLSは、ピア・ノードとの間のLMP障害ローカライゼーション手順を開始するために、それを検知した障害の隣接ピア・ノードに知らせるためにLMP障害ローカライズ手順（チャネルステータス、ChannelStatusAck、ChannelStatusRequest、及びChannelStatusResponseメッセージ）で定義されたメッセージを使用し、ありますが、それは、これらの手続に参加しません。
The OLS may also execute its own fault localization process to allow it to determine the location of the fault along the DWDM span. For example, the OLS may be able to pinpoint the fault to a particular amplifier in a span of thousands of kilometers in length.
OLSはまた、DWDMスパンに沿った障害の位置を決定することを可能にする独自の故障定位処理を実行してもよいです。例えば、OLSは、長さが数千キロのスパン内の特定の増幅器の故障を特定することができるかもしれません。
To report data link failures and recovery conditions, LMP-WDM uses the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse messages defined in [RFC4204].
データリンク障害と復旧状況を報告するには、LMP-WDMは、[RFC4204]で定義されたチャネルステータス、ChannelStatusAck、ChannelStatusRequest、およびChannelStatusResponseメッセージを使用しています。
Each data link is identified by an Interface_ID. In addition, a Link Group ID may be assigned to a group of data links (see Section 2.3.1). The Link Group ID may be used to reduce the control traffic by providing channel status information for a group of data links. A new LINK GROUP CHANNEL_STATUS object is defined below for this purpose. This object may be used in place of the CHANNEL_STATUS objects described in [RFC4204] in the ChannelStatus message.
各データリンクがInterface_IDによって識別されます。また、リンクグループIDは、データリンクのグループに割り当てることができます（2.3.1項を参照してください）。リンクグループIDは、データリンクのグループのためのチャネル状態情報を提供することにより、制御トラフィックを軽減するために使用することができます。新しいリンクグループCHANNEL_STATUSオブジェクトは、この目的のために、以下に定義されます。このオブジェクトは、チャネルステータスメッセージに[RFC4204]で説明CHANNEL_STATUSオブジェクトの代わりに使用することができます。
The LINK_GROUP CHANNEL_STATUS object is used to indicate the status of the data links belonging to a particular Link Group. The correlation of data links to Group ID is made with the Link Group ID sub-object of the DATA_LINK object.
LINK_GROUP CHANNEL_STATUSオブジェクトは、特定のリンクグループに属するデータリンクの状態を示すために使用されます。グループIDへのデータリンクの相関がDATA_LINKオブジェクトのリンクグループIDサブオブジェクトで作られています。
The format of the LINK_GROUP CHANNEL_STATUS object is as follows (Class = 13, C-Type = 4):
（= 13クラス、Cタイプ= 4）を次のようにLINK_GROUP CHANNEL_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Group ID: 32 bits
リンクグループID：32ビット
The Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of the Link
Group 0xFFFFFFFF by default.
Channel Status: 32 bits
チャンネルステータス：32ビット
The values for the Channel Status field are defined in
[RFC4204].
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
LMP message security uses IPsec, as described in [RFC4204]. This document only defines new LMP objects that are carried in existing LMP messages. As such, this document introduces no other new security considerations not covered in [RFC4204].
[RFC4204]に記載されているようにLMPメッセージセキュリティは、IPsecを使用します。この文書では、既存のLMPメッセージで運ばれる新しいLMPオブジェクトを定義します。そのため、このドキュメントは[RFC4204]で説明されていない他の新しいセキュリティ問題も紹介しません。
LMP [RFC4204] defines the following name spaces and the ways in which IANA can make assignments to these namespaces:
LMP [RFC4204]は、以下の名前空間とIANAはこれらの名前空間への割り当てを行うことができる方法を定義します。
- LMP Message Type - LMP Object Class - LMP Object Class type (C-Type) unique within the Object Class - LMP Sub-object Class type (Type) unique within the Object Class
- LMPメッセージタイプ - LMPオブジェクトクラス - オブジェクト・クラス内で一意LMPオブジェクトクラス型（C型） - オブジェクト・クラス内で一意LMPサブオブジェクトクラス型（タイプ）
This memo introduces the following new assignments:
このメモは、次の新しい割り当てが導入されています。
LMP Object Class Types:
LMPオブジェクトクラスタイプ：
o under CONFIG class name (as defined in [RFC4204]) - LMP-WDM_CONFIG (C-Type = 2)
LMP-WDM_CONFIG（Cタイプ= 2） - CONFIGクラス名（[RFC4204]で定義されるように）下O
o under CHANNEL_STATUS class name (as defined in [RFC4204]) - LINK_GROUP (C-Type = 4)
CHANNEL_STATUSクラス名の下O（[RFC4204]で定義されるように） - LINK_GROUP（C-タイプ= 4）
LMP Sub-Object Class names:
LMPサブオブジェクトのクラス名：
o under DATA_LINK Class name (as defined in [RFC4204]) - Link_GroupId (sub-object Type = 3) - SRLG (sub-object Type = 4) - BER_Estimate (sub-object Type = 5) - Optical_Protection (sub-object Type = 6) - Total_Span_Length (sub-object Type = 7) - Administrative_Group (sub-object Type = 8)
Link_GroupId（サブオブジェクトタイプ= 3） - - SRLG（サブオブジェクトタイプ= 4） - BER_Estimate（サブオブジェクトタイプ= 5） - Optical_Protection（サブオブジェクトタイプ（[RFC4204]で定義されるように）DATA_LINKクラス名の下O = 6） - Total_Span_Length（サブオブジェクトタイプ= 7） - Administrative_Group（サブオブジェクトタイプ= 8）
The authors would like to acknowledge Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake, David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P. Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue, Lucy Yong, and John Yu.
著者は、オサマ・S.のAboul-Magd、スチュアートBrorson、Sudheer Dharanikota、ジョン・ドレイク、デビッド・ドライスデール、WLエドワーズ、エードリアンファレル、アンドレFredette、のRohit Goyal氏、弘和石松、モニカ・イェーガー、ラムクリシュナン、ジョナサンP.ラングを確認したいと思います、ラグーMannam、エリック・マニー、ディミトリPapadimitriou、Jagan Shantigram、エド・スナイダー、ジョージくん、Gopala Tumuluri、龍雪、ルーシー・ヨンジュン、そしてジョン・ユー。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, September 2005.
[RFC4202] Kompella、K.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年9月。
[RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC 4204, September 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年9月。
[RFC4207] Lang, J., and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, September 2005.
[RFC4207]ラング、J.、およびD. Papadimitriou、 "同期光ネットワーク（SONET）リンク管理プロトコル（LMP）テストメッセージ用/同期デジタル階層（SDH）エンコーディング"、RFC 4207、2005年9月。
[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月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[OLI] Fredette, A., Editor, "Optical Link Interface Requirements", Work in Progress.
[OLI] Fredette、A.、エディタ、 "光リンクインタフェース要件" が進行中で働いています。
Editors' Addresses
エディタのアドレス
Andre Fredette Hatteras Networks P.O. Box 110025 Research Triangle Park NC 27709-0025, USA
アンドレFredetteハッテラスネットワーク私書箱110025リサーチトライアングルパークNC 27709から0025、USA箱
EMail: Afredette@HatterasNetworks.com
メールアドレス：Afredette@HatterasNetworks.com
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
ジョナサンP.ラングSonosの、株式会社223 E.デ・ラ・ゲラセントサンタバーバラ、CA 93101
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。