[要約] RFC 4209は、DWDM光ファイバーネットワークのリンク管理プロトコル（LMP）に関するものであり、DWDM光線システムの効率的な管理と制御を目的としています。
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).
Copyright（c）The Internet Society（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はピアノード、つまりシグナリングやルーティングでピアがピアするノードに焦点を当てています。このドキュメントでは、LMPへの拡張機能を提案して、ピアノードと隣接する光線システム（OLS）の間で使用できるようにします。これらの拡張機能は、コンパニオンドキュメントで説明されている「光リンクインターフェイス要件」を満たすことを目的としています。
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.
ネットワークは、ルーター、スイッチ、光学クロスコネクト（OXCS）、密な波長分割多重化（DWDM）光線システム（OLSE）、および一般的なコントロールプレーンを使用するアドロップマルチプレクサ（ADM）を使用して開発されています（例：一般化されたMPLS（（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）リンクを管理するためのGMPLSプロトコルスイートの一部として開発されています[RFC4204]。現在の形式では、LMPはピアノード、つまり、シグナリングやルーティングでピアをピアに焦点を当てています（図1に示すように、OXC-to-OXCなど）。このドキュメントでは、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光学リンクによって相互接続された2つのピアノード（2つのOXC）を考えてみましょう（上記の図1を参照）。このリンクとその現在の状態の構成に関する情報は、2つのOLS（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）で知られており、対応するOLSE（OLS1およびOLS2）にこの情報を伝達できるようにすることは、アラーム管理とリンクの監視に役立ちます。アラーム管理は重要です。なぜなら、ピアノードに知られているLSPの管理状態（たとえば、GMPLSシグナル[RFC3471]の管理ステータスオブジェクトを介して）を使用して、OLSEからのスプリアスアラーム報告を抑制できるためです。
The model for extending LMP to OLSes is shown in Figure 2.
LMPをOLSEに拡張するためのモデルを図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.
このモデルでは、ピアノードには、隣接するOLSEと隣接するピアノードを備えたLMPセッションがあります。たとえば、図2では、[RFC4204]に記載されているように、GMPLSシグナルとルーティングのトラフィックエンジニアリング（TE）リンクを構築するために、OXC1-OXC2 LMPセッションを使用できます。OXC1-OLS1およびOXC2-OLS2 LMPセッションは、DWDM光リンクの構成とその現在の状態とそのリンクを使用してLSPの状態に関する情報を交換するために使用されます。
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つ以上のOLSEを使用した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.
ピアノードは、ピアノードからオールのLMPセッションとピアノード間ノードLMPセッションを独立して維持します。これは、LMPセッションが任意の順序で登場することが可能であることを意味します。特に、ピアノードからピアへのノードへのノードセッションが、ピアノードからオールスの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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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-Opaqueと呼ばれます。
OXC: Optical cross-connect Transparent:
OXC：光学クロスコネクト透明：
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-Transparentと呼ばれます。たとえば、フレームリレースイッチはネットワーク層透明です。すべての光学スイッチは電気的に透明です。
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.
このドキュメントは、不透明なOLSで使用するために必要な拡張機能に焦点を当てています。特に、このドキュメントは、SONET、SDH、およびイーサネットユーザーポートを備えたOLSEで使用することを目的としています。
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つの主要な手順で構成されており、そのうち最初の2つは必須であり、最後の2つはオプションです。
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: Class = 6
ピアノードからオールスのLMPセッションとピアノードからピアへのノードLMPセッションを区別するために、新しいLMP-WDM構成オブジェクトが定義されています（C-Type = 2）。構成オブジェクトの形式は次のとおりです。
o C-Type = 2, LMP-WDM_CONFIG
o c-type = 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.
このビットは、このドキュメントで定義されているLMP-WDM拡張機能のサポートを示しています。
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.
設定されている場合、このビットは、送信者が光線システム（OLS）であることを示します。明確な場合、このビットは、送信者がピアノードであることを示します。
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拡張機能は、ピアノードからオールスのLMPセッション用に設計されています。OLSビットにより、ノードは自分自身をOLSまたはピアノードとして識別できます。これは、2つのピアノード間のピアノードからOLS-OLS LMPセッションの誤解またはピアノードからピアへのノードLMPセッションの間のピアノードとOLSの間の誤解を検出するために使用されます。
If the node does not support the LMP-WDM extensions, it MUST reply to the Config message with a ConfigNack message.
ノードがLMP-WDM拡張機能をサポートしていない場合は、confingメッセージを使用して構成メッセージに返信する必要があります。
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 Bit Clearを使用して構成メッセージを受信する場合、Condignackメッセージで構成メッセージに返信する必要があります。
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.
OLSEで使用されるテスト手順は、[RFC4204]で説明されているものと同じです。verifytransportmechanism（beginverifyおよびbeginifyackメッセージに含まれる）は、ノードがリンク検証方法をネゴシエートできるようにするために使用され、ペイロードではなくオーバーヘッドバイトにアクセスできるラインシステムに不可欠です。VerifyID（BeginVerifyAckメッセージのリモートノードによって提供され、その後のすべてのテストメッセージで使用されます）は、さまざまなLMPリンク検証手順からテストメッセージを区別するために使用されます。[RFC4204]で説明されているテスト手順に加えて、OLSユーザーポートがSONETまたはSDHである場合、[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セッションとピアノード間LMPセッションによって管理されているデータリンクの間に相互作用があります。たとえば、図2では、OXC1-OLS1 LMPセッションはOXC1とOLS1の間のデータリンクを管理し、OXC2-OLS2 LMPセッションはOXC2とOLS2の間のデータリンクを管理します。ただし、OXC1-OXC2 LMPセッションは、OXC1とOXC2の間のデータリンクを管理します。これは、実際にはOXC1とOLS1の間のデータリンクの連結であり、OLS1とOLS2の間のDWDMスパン、およびOXC2とOLS2の間のデータリンクを管理します。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.
これの意味は、LMPリンク検証手順を使用して、OXC1とOXC2の間のデータリンクが検証されている場合、OLS1とOLS2はこれらの連結データリンクに関して自分自身を透明にする必要があるということです。この透明性がピアノード、OXC1およびOXC2の責任であることを確認するために、OXC1-OLS1およびOXC2-OLS2データリンクの検証の調整。
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メッセージは、インターフェイス_IDSを同期し、TEリンクのプロパティを相関させるために使用されます。（「TEリンク」という用語は、LMPのルーティング/シグナリングアプリケーションに由来し、この概念は必ずしもOLSに適用されるわけではありません。ただし、この用語はLMP用語と一致し続けるために使用されます。）LinkSummaryメッセージには含まれます。1つ以上の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が必要とするものです。これらのリンク特性は、指定されたピアノードからOLSデータリンク、および2つのOLSE間の関連する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.
長さフィールドには、タイプと長さのフィールドを含む、バイトのサブオブジェクトの全長が含まれます。長さは少なくとも4でなければならず、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は、リンクグループチャンネル_STATUSオブジェクト（セクション2.4.1を参照）を使用して単一のチャンネルStatusメッセージを有効にすることにより、個々のChannelStatusメッセージの代わりにデータリンクのグループに使用されることにより、障害が発生した場合に制御トラフィックを減らすために使用できます。各データリンク。データリンクは、複数のグループのメンバーである場合があります。これは、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に知られている「故障可能なエンティティ」にデータリンクをマッピング（またはグループ）するために使用されます。これらの故障可能なエンティティのいずれかが失敗した場合、関連するすべてのデータリンクが失敗し、ピアノードに単一のメッセージが通知されます。
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はファイバーのリンクグループIDを作成して、そのファイバーに対して署名の喪失（LOS）が検出された場合、そのファイバーに関連付けられたすべてのデータリンクに影響を与えるすべての障害を報告することができます。
The format of the Link Group ID sub-object (Type = 3, Length = 8) is as follows:
リンクグループIDサブオブジェクト（type = 3、length = 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.
リンクグループID 0xffffffffffは予約されており、TEリンク内のすべてのデータリンクを示します。すべてのデータリンクは、デフォルトでリンクグループ0xffffffffのメンバーです。
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]).
これは、データリンクがメンバーであるSRLGを識別します。この情報は、ユーザーによって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:
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]を参照してください。適用されるのと同じくらい多くのSRLGをリストします。
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からマイナス13」のBERがある場合があります。つまり、送信される10,000,000,000,000ビットごとに、1ビットが誤っている可能性があります。BERは、全体的な信号の品質を示しています。
The format of the BER Estimate sub-object (Type = 5; Length = 4) is as follows:
BER推定サブオブジェクト（Type = 5; length = 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.
上記のBER表現からの指数。つまり、BERがマイナスXの10の場合、BERフィールドは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:
光保護サブオブジェクト（Type = 6; length = 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:
合計スパン長サブオブジェクト（Type = 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.
この値は、メートル単位のWDMスパンの総長さを表し、署名されていない（長い）整数として表されます。
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:
管理グループのサブオブジェクト（Type = 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-PEER障害管理手順から学んだ情報は、ピアピアLMP障害管理をトリガーするために使用される場合があります。または、GMPLSシグナリング/ルーティング手順を直接トリガーするために使用できます。
Fault management consists of three major functions:
障害管理は、3つの主要な機能で構成されています。
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].
障害検出メカニズムには、しきい値を超えるビットエラー率（BER）、および署名の損失（LOS）およびSONET/SDHレベルのエラーが含まれる場合があります。[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障害のローカリゼーション手順（ChannelStatus、ChannelStatusack、ChannelStatusRequest、およびChannelStatusResponseメッセージ）で定義されたメッセージを使用して、Peer Nodesの間のLMP障害ローカリゼーション手順を開始するために、検出された障害の隣接ピアノードに通知します。、しかし、それらの手順には参加しません。
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]で定義されたChannelStatus、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オブジェクトを以下に定義します。このオブジェクトは、channelStatusメッセージの[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):
link_group channel_statusオブジェクトの形式は次のとおりです（class = 13、c-type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
リンクグループID 0xffffffffffは予約されており、TEリンク内のすべてのデータリンクを示します。すべてのデータリンクは、デフォルトでリンクグループ0xffffffffのメンバーです。
Channel Status: 32 bits
チャネルステータス：32ビット
The values for the Channel Status field are defined in [RFC4204].
チャネルステータスフィールドの値は[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)
o config class name（[rfc4204]で定義されています）-LMP-WDM_CONFIG（c-type = 2）
o under CHANNEL_STATUS class name (as defined in [RFC4204]) - LINK_GROUP (C-Type = 4)
o Channel_statusクラス名（[rfc4204]で定義されている） - link_group（c -type = 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)
o data_linkクラス名（[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）-shingrative_group（sub -object type = 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・アブール・マグド、スチュアート・ブルソンソン、スディア・ダラニコタ、ジョン・ドレイク、デビッド・ドレスデール、W。L。エドワーズ、エイドリアン・ファレル、アンドレ・フレデット、ロヒト・ゴイアル、ヒロカズ・イシマツ、モニカ・ジェガー、ラム・クリシュナン、ジョナサンP.ランガン、Raghu Mannam、Eric Mannie、Dimitri Papadimitriou、Jagan Shantigram、Ed Snyder、George Swallow、Gopala Tumuluri、Yong Xue、Lucy Yong、およびJohn Yu。
[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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年9月。
[RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC 4204, September 2005.
[RFC4204] Lang、J.、ed。、「The Link Management Protocol（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] Lang、J。、およびD. Papadimitriou、「同期光学ネットワーク（SONET）/同期デジタル階層（SDH）リンク管理プロトコル（LMP）テストメッセージのエンコード」、RFC 4207、2005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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
Andre Fredette Hatteras Networks P.O.Box 110025 Research Triangle Park NC 27709-0025、米国
EMail: Afredette@HatterasNetworks.com
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
Jonathan P. Lang Sonos、Inc。223 E. de la Guerra St. Santa Barbara、CA 93101
EMail: jplang@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。