[要約] RFC 8780は、Wavelength Switched Optical Network（WSON）の経路計算要素通信プロトコル（PCEP）拡張に関するものであり、経路計算と波長割り当て（RWA）をサポートします。このRFCの目的は、WSONネットワークでの経路計算と波長割り当ての効率的な実装を提供することです。
Internet Engineering Task Force (IETF) Y. Lee, Ed.
Request for Comments: 8780 Samsung Electronics
Category: Standards Track R. Casellas, Ed.
ISSN: 2070-1721 CTTC
July 2020
The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)
Path Computation Element Communication Protocol（PCEP）Extension for Wavelength Switched Optical Network（WSON）Routing and Wavelength Assignment（RWA）
Abstract
概要
This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs). Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.
このドキュメントでは、波長交換光ネットワーク（WSON）でのルーティングと波長割り当て（RWA）のサポートのためのパス計算要素通信プロトコル（PCEP）拡張について説明します。 WSONでのパスのプロビジョニングには、RWAプロセスが必要です。パス計算の観点から見ると、波長割り当ては、パスの各ホップで使用できる波長を決定するプロセスであり、光パス計算に追加のルーティング制約を形成します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8780.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8780で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 2. Terminology 3. Requirements Language 4. Encoding of an RWA Path Request 4.1. Wavelength Assignment (WA) Object 4.2. Wavelength Selection TLV 4.3. Wavelength Restriction TLV 4.3.1. Link Identifier Field 4.3.2. Wavelength Constraint Field 4.4. Signal Processing Capability Restrictions 4.4.1. Signal Processing Exclusion 4.4.2. Signal Processing Inclusion 5. Encoding of an RWA Path Reply 5.1. Wavelength Allocation TLV 5.2. Error Indicator 5.3. NO-PATH Indicator 6. Manageability Considerations 6.1. Control of Function and Policy 6.2. Liveness Detection and Monitoring 6.3. Verifying Correct Operation 6.4. Requirements on Other Protocols and Functional Components 6.5. Impact on Network Operation 7. Security Considerations 8. IANA Considerations 8.1. New PCEP Object: Wavelength Assignment Object 8.2. WA Object Flag Field 8.3. New PCEP TLV: Wavelength Selection TLV 8.4. New PCEP TLV: Wavelength Restriction TLV 8.5. Wavelength Restriction TLV Action Values 8.6. New PCEP TLV: Wavelength Allocation TLV 8.7. Wavelength Allocation TLV Flag Field 8.8. New PCEP TLV: Optical Interface Class List TLV 8.9. New PCEP TLV: Client Signal Information TLV 8.10. New Bit Flag for NO-PATH-VECTOR TLV 8.11. New Error-Types and Error-Values 8.12. New Subobjects for the Exclude Route Object 8.13. New Subobjects for the Include Route Object 8.14. Request for Updated Note for LMP TE Link Object Class Type 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Contributors Authors' Addresses
1. はじめに2.用語3.要件言語4. RWAパス要求のエンコーディング4.1。波長割り当て（WA）オブジェクト4.2。波長選択TLV 4.3。波長制限TLV 4.3.1。リンク識別子フィールド4.3.2。波長制約フィールド4.4。信号処理機能の制限4.4.1。信号処理の除外4.4.2。信号処理の包含5. RWAパス応答のエンコード5.1。波長割り当てTLV 5.2。エラーインジケーター5.3。 NO-PATHインジケーター6.管理性に関する考慮事項6.1。機能とポリシーの制御6.2。活性検出とモニタリング6.3。正しい動作の確認6.4。その他のプロトコルと機能コンポーネントの要件6.5。ネットワーク運用への影響7.セキュリティに関する考慮事項8. IANAに関する考慮事項8.1。新しいPCEPオブジェクト：波長割り当てオブジェクト8.2。 WAオブジェクトフラグフィールド8.3。新しいPCEP TLV：波長選択TLV 8.4。新しいPCEP TLV：波長制限TLV 8.5。波長制限TLVアクション値8.6。新しいPCEP TLV：波長割り当てTLV 8.7。波長割り当てTLVフラグフィールド8.8。新しいPCEP TLV：光インターフェースクラスリストTLV 8.9。新しいPCEP TLV：クライアント信号情報TLV 8.10。 NO-PATH-VECTOR TLV 8.11の新しいビットフラグ。新しいエラータイプとエラー値8.12。除外ルートオブジェクトの新しいサブオブジェクト8.13。インクルードルートオブジェクトの新しいサブオブジェクト8.14。 LMP TEリンクオブジェクトクラスタイプ9の更新されたノートのリクエスト。規範的な参考文献9.2。有益な参考文献謝辞寄稿者著者のアドレス
[RFC5440] specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include Path Computation Requests (PCReqs) and Path Computation Replies (PCReps) as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE).
[RFC5440]は、パス計算クライアント（PCC）とPCE間、または2つのPCE間の通信用のパス計算要素通信プロトコル（PCEP）を指定します。そのような相互作用には、パス計算要求（PCReq）とパス計算応答（PCReps）、およびマルチプロトコルラベルスイッチング（MPLS）と汎用MPLS（GMPLS）トラフィックエンジニアリング（TE）のコンテキストでのPCEの使用に関連する特定の状態の通知が含まれます。 ）。
A PCC is said to be any network component that makes such a request and may be, for instance, an optical switching element within a Wavelength Division Multiplexing (WDM) network. The PCE, itself, can be located anywhere within the network and may be within an optical switching element, a Network Management System (NMS), or an Operational Support System (OSS), or it may be an independent network server.
PCCは、このような要求を行う任意のネットワークコンポーネントであると言われ、たとえば、波長分割多重（WDM）ネットワーク内の光スイッチング要素である場合があります。 PCE自体は、ネットワーク内のどこにでも配置でき、光スイッチング要素、ネットワーク管理システム（NMS）、または運用サポートシステム（OSS）内に配置することも、独立したネットワークサーバーにすることもできます。
This document provides the PCEP extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) based on the requirements specified in [RFC6163] and [RFC7449].
このドキュメントは、[RFC6163]と[RFC7449]で指定された要件に基づいて、波長切り替え光ネットワーク（WSON）でルーティングと波長割り当て（RWA）をサポートするためのPCEP拡張機能を提供します。
WSON refers to WDM-based optical networks in which switching is performed selectively based on the wavelength of an optical signal. The devices used in WSONs that are able to switch signals based on signal wavelength are known as Lambda Switch Capable (LSC). WSONs can be transparent or translucent. A transparent optical network is made up of optical devices that can switch but not convert from one wavelength to another, all within the optical domain. On the other hand, translucent networks include 3R regenerators (reamplification, reshaping, and retiming) that are sparsely placed. The main function of the 3R regenerators is to convert one optical wavelength to another.
WSONは、スイッチングが光信号の波長に基づいて選択的に実行されるWDMベースの光ネットワークを指します。信号波長に基づいて信号を切り替えることができるWSONで使用されるデバイスは、ラムダスイッチ対応（LSC）と呼ばれます。 WSONは透明または半透明にすることができます。トランスペアレント光ネットワークは、すべて光ドメイン内で、1つの波長から別の波長に切り替えることはできるが変換できない光デバイスで構成されています。一方、半透明ネットワークには、まばらに配置された3R再生器（再増幅、再形成、およびリタイミング）が含まれます。 3R再生器の主な機能は、1つの光波長を別の光波長に変換することです。
An LSC Label Switched Path (LSP) may span one or several transparent segments, which are delimited by 3R regenerators typically with electronic regenerator and optional wavelength conversion. Each transparent segment or path in WSON is referred to as an optical path. An optical path may span multiple fiber links, and the path should be assigned the same wavelength for each link. In a case, the optical path is said to satisfy the wavelength-continuity constraint. Figure 1 illustrates the relationship between an LSC LSP and transparent segments (optical paths).
LSCラベルスイッチドパス（LSP）は、通常は電子再生器とオプションの波長変換を備えた3R再生器によって区切られている1つまたは複数の透過セグメントにまたがることがあります。 WSONの各透過セグメントまたはパスは、光パスと呼ばれます。光パスは複数のファイバリンクにまたがることがあり、パスには各リンクに同じ波長を割り当てる必要があります。ある場合、光路は波長連続性の制約を満たすと言われています。図1は、LSC LSPと透過セグメント（光パス）の関係を示しています。
+---+ +-----+ +-----+ +-----+ +-----+
| |I1 | | | | | | I2| |
| |o------| |-------[(3R) ]------| |--------o| |
| | | | | | | | | |
+---+ +-----+ +-----+ +-----+ +-----+
(X LSC) (LSC LSC) (LSC LSC) (LSC X)
<-------> <-------> <-----> <------->
<-----------------------><---------------------->
Transparent Segment Transparent Segment
<------------------------------------------------->
LSC LSP
Figure 1: Illustration of an LSC LSP and Transparent Segments
図1：LSC LSPと透過セグメントの図
Note that two transparent segments within a WSON LSP do not need to operate on the same wavelength (due to wavelength conversion capabilities). Two optical channels that share a common fiber link cannot be assigned the same wavelength; otherwise, the two signals would interfere with each other. Note that advanced additional multiplexing techniques such as polarization-based multiplexing are not addressed in this document since the physical-layer aspects are not currently standardized. Therefore, assigning the proper wavelength on a path is an essential requirement in the optical path computation process.
WSON LSP内の2つの透過セグメントは、（波長変換機能により）同じ波長で動作する必要がないことに注意してください。共通のファイバリンクを共有する2つの光チャネルに同じ波長を割り当てることはできません。そうしないと、2つの信号が互いに干渉します。物理層の側面は現在標準化されていないため、偏波ベースの多重化などの高度な追加の多重化手法については、このドキュメントでは扱いません。したがって、パスに適切な波長を割り当てることは、光パス計算プロセスの必須要件です。
When a switching node has the ability to perform wavelength conversion, the wavelength-continuity constraint can be relaxed, and an LSP may use different wavelengths on different links along its route from origin to destination. It is, however, to be noted that wavelength converters may be limited due to their relatively high cost, while the number of WDM channels that can be supported in a fiber is also limited. As a WSON can be composed of network nodes that cannot perform wavelength conversion, nodes with limited wavelength conversion, and nodes with full wavelength conversion abilities, wavelength assignment is an additional routing constraint to be considered in all optical path computation.
スイッチングノードに波長変換を実行する機能がある場合、波長連続性の制約を緩和でき、LSPは起点から終点へのルートに沿った異なるリンクで異なる波長を使用できます。ただし、ファイバでサポートできるWDMチャネルの数も制限されている一方で、比較的コストが高いため、波長変換器が制限される場合があることに注意してください。 WSONは、波長変換を実行できないネットワークノード、波長変換が制限されたノード、および完全な波長変換機能を備えたノードで構成できるため、波長割り当ては、すべての光パス計算で考慮される追加のルーティング制約です。
For example (see Figure 1), within a translucent WSON, an LSC LSP may be established between interfaces I1 and I2, spanning two transparent segments (optical paths) where the wavelength continuity constraint applies (i.e., the same unique wavelength must be assigned to the LSP at each TE link of the segment). If the LSC LSP induced a Forwarding Adjacency / TE link, the switching capabilities of the TE link would be (X X), where X refers to the switching capability of I1 and I2. For example, X can be Packet Switch Capable (PSC), Time-Division Multiplexing (TDM), etc.
たとえば（図1を参照）、半透明のWSON内で、インターフェースI1とI2の間にLSC LSPが確立され、波長の連続性の制約が適用される2つの透明なセグメント（光パス）にまたがります（つまり、同じ一意の波長をセグメントの各TEリンクのLSP）。 LSC LSPがForwarding Adjacency / TEリンクを誘発した場合、TEリンクのスイッチング機能は（X X）になります。XはI1とI2のスイッチング機能を指します。たとえば、Xはパケットスイッチ対応（PSC）、時分割多重（TDM）などです。
This document aligns with [RFC8779] for generic properties such as label, label set, and label assignment, noting that a wavelength is a type of label. Wavelength restrictions and constraints are also formulated in terms of labels per [RFC7579].
このドキュメントは、波長がラベルのタイプであることに注意して、ラベル、ラベルセット、ラベル割り当てなどの一般的なプロパティの[RFC8779]に対応しています。 [RFC7579]に従って、波長制限と制約もラベルの観点から定式化されています。
The optical modulation properties, which are also referred to as signal compatibility, are already considered in the signaling in [RFC7581] and [RFC7688]. In order to improve the signal quality and limit some optical effects, several advanced modulation processing capabilities are used by the mechanisms specified in this document. These modulation capabilities not only contribute to optical signal quality checks but also constrain the selection of sender and receiver, as they should have matching signal processing capabilities. This document includes signal compatibility constraints as part of RWA path computation. That is, the signal processing capabilities (e.g., modulation and Forward Error Correction (FEC)) indicated by means of the Optical Interface Class (OIC) must be compatible between the sender and the receiver of the optical path across all optical elements.
信号の互換性とも呼ばれる光変調特性は、[RFC7581]および[RFC7688]のシグナリングですでに考慮されています。信号品質を向上させ、一部の光学効果を制限するために、このドキュメントで指定されているメカニズムでは、いくつかの高度な変調処理機能が使用されています。これらの変調機能は、光信号の品質チェックに貢献するだけでなく、送信側と受信側の選択を制限します。これらは、一致する信号処理機能を備えている必要があるためです。このドキュメントには、RWAパス計算の一部として信号互換性の制約が含まれています。つまり、光インターフェースクラス（OIC）によって示される信号処理機能（変調および転送エラー訂正（FEC）など）は、すべての光エレメントの光パスの送信側と受信側の間で互換性がなければなりません。
This document, however, does not address optical impairments as part of RWA path computation. See [RFC6566] for the framework for optical impairments.
ただし、このドキュメントでは、RWAパス計算の一部として光学的障害については扱いません。光学障害のフレームワークについては、[RFC6566]を参照してください。
This document uses the terminology defined in [RFC4655] and [RFC5440].
このドキュメントでは、[RFC4655]と[RFC5440]で定義されている用語を使用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Figure 2 shows one typical PCE-based implementation, which is referred to as the Combined Process (R&WA). With this architecture, the two processes of routing and wavelength assignment are accessed via a single PCE. This architecture is the base architecture specified in [RFC6163], and the PCEP extensions that are specified in this document are based on this architecture.
図2は、典型的なPCEベースの実装を示しています。これは、Combined Process（R＆WA）と呼ばれています。このアーキテクチャでは、ルーティングと波長割り当ての2つのプロセスに単一のPCEを介してアクセスします。このアーキテクチャは[RFC6163]で指定されている基本アーキテクチャであり、このドキュメントで指定されているPCEP拡張機能はこのアーキテクチャに基づいています。
+----------------------------+
+-----+ | +-------+ +--+ |
| | | |Routing| |WA| |
| PCC |<----->| +-------+ +--+ |
| | | |
+-----+ | PCE |
+----------------------------+
Figure 2: Combined Process (R&WA) Architecture
図2：複合プロセス（R＆WA）アーキテクチャ
Wavelength allocation can be performed by the PCE by means of:
PCEは、次の方法で波長割り当てを実行できます。
(a) Explicit Label Control [RFC3471] where the PCE allocates which label to use for each interface/node along the path. The allocated labels MAY appear after an interface route subobject.
（a）明示的ラベル制御[RFC3471] PCEは、パスに沿った各インターフェイス/ノードに使用するラベルを割り当てます。割り当てられたラベルは、インターフェースルートサブオブジェクトの後に表示される場合があります。
(b) A Label Set where the PCE provides a range of potential labels to be allocated by each node along the path.
（b）PCEがパスに沿って各ノードによって割り当てられる一連の潜在的なラベルを提供するラベルセット。
Option (b) allows distributed label allocation (performed during signaling) to complete wavelength assignment.
オプション（b）を使用すると、（シグナリング中に実行される）分散ラベル割り当てで波長割り当てを完了することができます。
Additionally, given a range of potential labels to allocate, a PCReq SHOULD convey the heuristic or mechanism used for the allocation.
さらに、割り当てる可能性のあるラベルの範囲が指定されている場合、PCReqは割り当てに使用されるヒューリスティックまたはメカニズムを伝える必要があります（SHOULD）。
Per [RFC5440], the format of a PCReq message after incorporating the Wavelength Assignment (WA) object is as follows:
[RFC5440]によると、Wavelength Assignment（WA）オブジェクトを組み込んだ後のPCReqメッセージのフォーマットは次のとおりです。
<PCReq Message> ::= <Common Header>
[<svec-list>]
[<svec-list>]
<request-list>
<リクエストリスト>
Where:
どこ：
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
<WA>
＜和＞
[other optional objects...]
[その他のオプションオブジェクト...]
If the WA object is present in the request, it MUST be encoded after the END-POINTS object as defined in [RFC8779]. The WA object is mandatory in this document. Orderings for the other optional objects are irrelevant.
WAオブジェクトがリクエストに存在する場合、[RFC8779]で定義されているように、END-POINTSオブジェクトの後にエンコードする必要があります。このドキュメントではWAオブジェクトが必須です。他のオプションのオブジェクトの順序は関係ありません。
For the WA object, the Object-Class is 42, and the Object-Type is 1.
WAオブジェクトの場合、Object-Classは42、Object-Typeは1です。
The format of the WA object body is as follows:
WAオブジェクト本体の形式は次のとおりです。
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 | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: WA Object
ふぃぐれ ３： わ おｂじぇｃｔ
Reserved (16 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt.
予約済み（16ビット）：将来の使用のために予約されており、受信時にゼロにして無視する必要があります（SHOULD）。
Flags field (16 bits): One flag bit is allocated as follows:
フラグフィールド（16ビット）：次のように1つのフラグビットが割り当てられます。
M (1 bit): Wavelength Allocation Mode. The M bit is used to indicate the mode of wavelength assignment. When the M bit is set to 1, this indicates that the label assigned by the PCE must be explicit. That is, the selected way to convey the allocated wavelength is by means of Explicit Label Control for each hop of a computed LSP. Otherwise (M bit is set to 0), the label assigned by the PCE need not be explicit (i.e., it can be suggested in the form of Label Set objects in the corresponding response, to allow distributed WA. If M is 0, the PCE MUST return a Label Set Field as described in Section 2.6 of [RFC7579] in the response. See Section 5 of this document for the encoding discussion of a Label Set Field in a PCRep message.
M（1ビット）：波長割り当てモード。 Mビットは、波長割り当てのモードを示すために使用されます。 Mビットが1に設定されている場合、これは、PCEによって割り当てられたラベルが明示的でなければならないことを示します。つまり、割り当てられた波長を伝達するための選択された方法は、計算されたLSPの各ホップの明示的なラベル制御によるものです。それ以外の場合（Mビットは0に設定されます）、PCEによって割り当てられたラベルは明示的である必要はありません（つまり、対応する応答でラベルセットオブジェクトの形式で提案され、分散WAを許可します。Mが0の場合、 PCEは、[RFC7579]のセクション2.6で説明されているように、ラベルセットフィールドを応答で返す必要があります。PCRepメッセージのラベルセットフィールドのエンコードについては、このドキュメントのセクション5を参照してください。
All unused flags SHOULD be zeroed. IANA has created a new registry to manage the Flags field of the WA object.
未使用のフラグはすべてゼロにする必要があります。 IANAは、WAオブジェクトのFlagsフィールドを管理するための新しいレジストリを作成しました。
TLVs (variable): In the TLVs field, the following two TLVs are defined. At least one TLV MUST be present.
TLVs（variable）：TLVsフィールドでは、次の2つのTLVが定義されています。少なくとも1つのTLVが存在する必要があります。
Wavelength Selection TLV: The type of this TLV is 8, and it has a fixed length of 32 bits. This TLV indicates the wavelength selection. See Section 4.2 for details.
波長選択TLV：このTLVのタイプは8で、32ビットの固定長です。このTLVは波長の選択を示します。詳細については、セクション4.2を参照してください。
Wavelength Restriction TLV: The type of this TLV is 9, and it has a variable length. This TLV indicates wavelength restrictions. See Section 4.3 for details.
波長制限TLV：このTLVのタイプは9で、可変長です。このTLVは波長制限を示します。詳細については、セクション4.3を参照してください。
The Wavelength Selection TLV is used to indicate the wavelength selection constraint in regard to the order of wavelength assignment to be returned by the PCE. This TLV is only applied when the M bit is set in the WA object specified in Section 4.1. This TLV MUST NOT be used when the M bit is cleared.
波長選択TLVは、PCEによって返される波長割り当ての順序に関する波長選択制約を示すために使用されます。このTLVは、セクション4.1で指定されたWAオブジェクトにMビットが設定されている場合にのみ適用されます。このTLVは、Mビットがクリアされている場合は使用してはなりません。
The encoding of this TLV is specified as the WavelengthSelection sub-TLV in Section 4.2.2 of [RFC7689]. IANA has allocated a new TLV type for the Wavelength Selection TLV (Type 8).
このTLVのエンコーディングは、[RFC7689]のセクション4.2.2でWavelengthSelectionサブTLVとして指定されています。 IANAは、波長選択TLV（タイプ8）に新しいTLVタイプを割り当てました。
For any request that contains a wavelength assignment, the requester (PCC) MUST specify a restriction on the wavelengths to be used. This restriction is to be interpreted by the PCE as a constraint on the tuning ability of the origination laser transmitter or on any other maintenance-related constraints. Note that if the LSC LSP spans different segments, the PCE must have mechanisms to know the tunability restrictions of the involved wavelength converters/ regenerators, e.g., by means of the Traffic Engineering Database (TED) via either IGP or NMS. Even if the PCE knows the tunability of the transmitter, the PCC must be able to apply additional constraints to the request.
波長の割り当てを含む要求の場合、リクエスター（PCC）は使用する波長の制限を指定する必要があります。この制限は、PCEによって、発信レーザートランスミッターの調整能力またはその他のメンテナンス関連の制約として解釈されます。 LSC LSPが異なるセグメントにまたがる場合、PCEには、IGPまたはNMSを介したトラフィックエンジニアリングデータベース（TED）などを使用して、関連する波長コンバーター/再生器の調整可能性の制限を知るメカニズムが必要です。 PCEが送信機の調整可能性を知っている場合でも、PCCは要求に追加の制約を適用できなければなりません。
The format of the Wavelength Restriction TLV is as follows:
波長制限TLVのフォーマットは次のとおりです。
<Wavelength Restriction> ::=
(<Action> <Count> <Reserved>
<Link Identifiers> <Wavelength Constraint>)...
<リンク識別子> <波長制約>）...
Where:
どこ：
<Link Identifiers> ::= <Link Identifier> [<Link Identifiers>]
See Section 4.3.1 for the encoding of the Link Identifier field.
リンク識別子フィールドのエンコーディングについては、セクション4.3.1を参照してください。
These fields (i.e., <Action>, <Link Identifiers>, and <Wavelength Constraint>, etc.) MAY appear together more than once to be able to specify multiple actions and their restrictions.
これらのフィールド（つまり、<Action>、<Link Identifiers、および<Wavelength Constraint>など）は、複数のアクションとその制限を指定できるように、複数回一緒に表示される場合があります。
IANA has allocated a new TLV type for the Wavelength Restriction TLV (Type 9).
IANAは、波長制限TLV（タイプ9）に新しいTLVタイプを割り当てました。
The TLV data is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers |
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Constraint |
// . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifiers |
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength Constraint |
// . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Wavelength Restriction TLV Encoding
図4：波長制限TLVエンコーディング
Action (8 bits): 0: Inclusive List. Indicates that one or more link identifiers are included in the Link Set. Each identifies a separate link that is part of the set.
アクション（8ビット）：0：包含リスト。リンクセットに1つ以上のリンク識別子が含まれていることを示します。それぞれが、セットの一部である個別のリンクを識別します。
1: Inclusive Range. Indicates that the Link Set defines a range of links. It contains two link identifiers. The first identifier indicates the start of the range (inclusive). The second identifier indicates the end of the range (inclusive). All links with numeric values between the bounds are considered to be part of the set. A value of zero in either position indicates that there is no bound on the corresponding portion of the range.
1：包括的範囲。リンクセットがリンクの範囲を定義することを示します。 2つのリンク識別子が含まれています。最初の識別子は、範囲の開始（両端を含む）を示します。 2番目の識別子は、範囲の終わり（両端を含む）を示します。境界の間に数値があるリンクはすべて、セットの一部と見なされます。どちらかの位置の値がゼロの場合は、範囲の対応する部分に制限がないことを示しています。
2-255: Unassigned.
2-255：未割り当て。
IANA has created a new registry to manage the Action values of the Wavelength Restriction TLV.
IANAは、波長制限TLVのアクション値を管理するための新しいレジストリを作成しました。
If a PCE receives an unrecognized Action value, the PCE MUST send a PCEP Error (PCErr) message with a PCEP-ERROR object with Error-Type=27 and an Error-value=3. See Section 5.2 for details.
PCEが認識されないアクション値を受信した場合、PCEは、Error-Type = 27およびError-value = 3のPCEP-ERRORオブジェクトを含むPCEPエラー（PCErr）メッセージを送信する必要があります。詳細については、セクション5.2を参照してください。
Note that "links" are assumed to be bidirectional.
「リンク」は双方向であると想定されていることに注意してください。
Count (8 bits): The number of the link identifiers.
カウント（8ビット）：リンクIDの数。
Note that a PCC MAY add a Wavelength restriction that applies to all links by setting the Count field to zero and specifying just a set of wavelengths.
PCCは、Countフィールドをゼロに設定し、波長のセットのみを指定することにより、すべてのリンクに適用される波長制限を追加できることに注意してください。
Note that all link identifiers in the same list MUST be of the same type.
同じリスト内のすべてのリンク識別子は同じタイプでなければならないことに注意してください。
Reserved (16 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt.
予約済み（16ビット）：将来の使用のために予約されており、受信時にゼロにして無視する必要があります（SHOULD）。
Link Identifiers: Identifies each link ID for which restriction is applied. The length is dependent on the link format and the Count field. See Section 4.3.1 for encoding of the Link Identifier field.
リンクID：制限が適用される各リンクIDを識別します。長さは、リンク形式とCountフィールドに依存します。リンク識別子フィールドのエンコーディングについては、セクション4.3.1を参照してください。
Wavelength Constraint: See Section 4.3.2 for the encoding of the Wavelength Constraint field.
波長制約：波長制約フィールドのエンコーディングについては、セクション4.3.2を参照してください。
Various encoding errors are possible with this TLV (e.g., not exactly two link identifiers with the range case, unknown identifier types, no matching link for a given identifier, etc.). To indicate errors associated with this encoding, a PCEP speaker MUST send a PCErr message with Error-Type=27 and Error-value=3. See Section 5.2 for details.
このTLVを使用すると、さまざまなエンコーディングエラーが発生する可能性があります（たとえば、範囲の大文字小文字が区別された2つのリンク識別子、不明な識別子タイプ、特定の識別子に一致するリンクがないなど）。このエンコーディングに関連するエラーを示すために、PCEPスピーカーはError-Type = 27およびError-value = 3のPCErrメッセージを送信する必要があります。詳細については、セクション5.2を参照してください。
The Link Identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329], or unnumbered interface ID [RFC4203].
Link Identifierフィールドには、IPv4 [RFC3630]、IPv6 [RFC5329]、または番号なしのインターフェイスID [RFC4203]を使用できます。
<Link Identifier> ::=
<IPv4 Address> | <IPv6 Address> | <Unnumbered IF ID>
The encoding of each case 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 = 1 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv4 Address Field
図5：IPv4アドレスフィールド
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 = 2 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv6 Address Field
図6：IPv6アドレスフィールド
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 = 3 | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Node ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Unnumbered Interface ID Address Field
図7：アンナンバードインターフェイスIDアドレスフィールド
Type (8 bits): Indicates the type of the link identifier.
タイプ（8ビット）：リンクIDのタイプを示します。
Reserved (24 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt.
予約済み（24ビット）：将来の使用のために予約されており、受信時にゼロにして無視する必要があります。
Link Identifier: When the Type field is 1, a 4-byte IPv4 address is encoded; when the Type field is 2, a 16-byte IPv6 address is encoded; and when the Type field is 3, a tuple of a 4-byte TE node ID and a 4-byte interface ID is encoded.
リンク識別子：Typeフィールドが1の場合、4バイトのIPv4アドレスがエンコードされます。 Typeフィールドが2の場合、16バイトのIPv6アドレスがエンコードされます。 Typeフィールドが3の場合、4バイトのTEノードIDと4バイトのインターフェースIDのタプルがエンコードされます。
The Type field is extensible and matches the "TE_LINK Object Class type name space (Value 11)" registry created for the Link Management Protocol (LMP) [RFC4204] (see [LMP-PARAM]). IANA has added an introductory note before the aforementioned registry stating that the values have additional usage for the Link Identifier Type field. See Section 8.14.
Typeフィールドは拡張可能であり、リンク管理プロトコル（LMP）[RFC4204]（[LMP-PARAM]を参照）用に作成された「TE_LINK Object Class type name space（Value 11）」レジストリと一致します。 IANAは、前述のレジストリの前に、値にリンク識別子タイプフィールドの追加の使用法があることを説明する導入ノートを追加しました。セクション8.14を参照してください。
The Wavelength Constraint field of the Wavelength Restriction TLV is encoded as a Label Set Field as specified in Section 2.6 of [RFC7579] with the base label encoded as a 32-bit LSC label, as defined in [RFC6205]. The Label Set format is repeated here for convenience, with the base label internal structure included. See [RFC6205] for a description of Grid, Channel Spacing (C.S.), Identifier, and n, and see [RFC7579] for the details of each action.
Wavelength Restriction TLVのWavelength Constraintフィールドは、[RFC6205]で定義されているように、ベースラベルが32ビットLSCラベルとしてエンコードされ、[RFC7579]のセクション2.6で指定されているラベルセットフィールドとしてエンコードされます。ここでは、便宜上、ラベルセット形式を繰り返し、基本ラベルの内部構造を含めています。グリッド、チャネル間隔（C.S.）、識別子、およびnの説明については[RFC6205]を参照し、各アクションの詳細については[RFC7579]を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action| Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Identifier | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional fields as necessary per action |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Wavelength Constraint Field
図8：波長制約フィールド
Action (4 bits): 0: Inclusive List
アクション（4ビット）：0：包含リスト
1: Exclusive List
1：排他リスト
2: Inclusive Range
2：包括的範囲
3: Exclusive Range
3：排他的範囲
4: Bitmap Set
4：ビットマップセット
Num Labels (12 bits): It is generally the number of labels. It has a specific meaning depending on the action value.
ラベルの数（12ビット）：通常はラベルの数です。アクションの値によって特定の意味があります。
Length (16 bits): It is the length in bytes of the entire Wavelength Constraint field.
長さ（16ビット）：波長制約フィールド全体のバイト単位の長さです。
Identifier (9 bits): The Identifier is always set to 0. If PCC receives the value of the identifier other than 0, it will ignore.
識別子（9ビット）：識別子は常に0に設定されます。PCCが0以外の識別子の値を受け取った場合、それは無視されます。
See Sections 2.6.1-2.6.3 of [RFC7579] for details on additional field discussion for each action.
各アクションの追加のフィールドディスカッションの詳細については、[RFC7579]のセクション2.6.1-2.6.3を参照してください。
Path computation for WSON includes the checking of signal processing capabilities at each interface against requested capability; the PCE MUST have mechanisms to know the signal processing capabilities at each interface, e.g., by means of (TED) via either IGP or NMS. Moreover, a PCC should be able to indicate additional restrictions to signal processing compatibility, on either the endpoint or any given link.
WSONのパス計算には、要求された機能に対する各インターフェイスでの信号処理機能のチェックが含まれます。 PCEは、IGPまたはNMSのいずれかを介して（TED）などを使用して、各インターフェイスの信号処理機能を認識するメカニズムを備えている必要があります。さらに、PCCは、エンドポイントまたは特定のリンクのいずれかで、信号処理の互換性に対する追加の制限を示すことができる必要があります。
The supported signal processing capabilities considered in the RWA Information Model [RFC7446] are:
RWA情報モデル[RFC7446]で考慮されているサポートされている信号処理機能は次のとおりです。
* Optical Interface Class List
* 光インターフェイスクラスリスト
* Bit Rate
* ビットレート
* Client Signal
* クライアント信号
The bit rate restriction is already expressed in the BANDWIDTH object in [RFC8779].
ビットレート制限はすでに[RFC8779]のBANDWIDTHオブジェクトで表現されています。
In order to support the optical interface class information and the client signal information, new TLVs are introduced as endpoint restrictions in the END-POINTS type Generalized Endpoint:
光インターフェイスクラス情報とクライアント信号情報をサポートするために、新しいTLVがエンドポイント制限としてEND-POINTSタイプGeneralized Endpointに導入されています。
* Client Signal Information TLV
* クライアント信号情報TLV
* Optical Interface Class List TLV
* 光インターフェイスクラスリストTLV
The END-POINTS type Generalized Endpoint is extended as follows:
END-POINTSタイプのGeneralized Endpointは、次のように拡張されています。
<endpoint-restriction> ::=
<LABEL-REQUEST> <label-restriction-list>
<label-restriction-list> ::= <label-restriction>
[<label-restriction-list>]
<label-restriction> ::= (<LABEL-SET>|
[<Wavelength Restriction>]
[<signal-compatibility-restriction>])
Where:
どこ：
<signal-compatibility-restriction> ::=
[<Optical Interface Class List>] [<Client Signal Information>]
The Wavelength Restriction TLV is defined in Section 4.3.
波長制限TLVはセクション4.3で定義されています。
A new Optical Interface Class List TLV (Type 11) is defined; the encoding of the value part of this TLV is described in Section 4.1 of [RFC7581].
新しい光インターフェイスクラスリストTLV（タイプ11）が定義されています。このTLVの値部分のエンコーディングについては、[RFC7581]のセクション4.1で説明されています。
A new Client Signal Information TLV (Type 12) is defined; the encoding of the value part of this TLV is described in Section 4.2 of [RFC7581].
新しいクライアント信号情報TLV（タイプ12）が定義されています。このTLVの値の部分のエンコードについては、[RFC7581]のセクション4.2で説明されています。
The PCC/PCE should be able to exclude particular types of signal processing along the path in order to handle client restriction or multi-domain path computation. [RFC5521] defines how the Exclude Route Object (XRO) subobject is used. In this document, we add two new XRO Signal Processing Exclusion subobjects.
PCC / PCEは、クライアント制限またはマルチドメインパス計算を処理するために、パスに沿った特定のタイプの信号処理を除外できる必要があります。 [RFC5521]は、ルートオブジェクトの除外（XRO）サブオブジェクトの使用方法を定義します。このドキュメントでは、2つの新しいXRO信号処理除外サブオブジェクトを追加します。
The first XRO subobject type (8) is the Optical Interface Class List, which is defined as follows:
最初のXROサブオブジェクトタイプ（8）はOptical Interface Class Listで、次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=8 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optical Interface Class List //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Optical Interface Class List XRO Subobject
図9：光インターフェースクラスリストXROサブオブジェクト
Refer to [RFC5521] for the definitions of X, Length, and Attribute.
X、長さ、および属性の定義については、[RFC5521]を参照してください。
Type (7 bits): The type of the Signaling Processing Exclusion field. IANA has assigned value 8 for the Optical Interface Class List XRO subobject type.
タイプ（7ビット）：シグナリング処理除外フィールドのタイプ。 IANAは、Optical Interface Class List XROサブオブジェクトタイプに値8を割り当てています。
Reserved bits (8 bits): These are for future use and SHOULD be zeroed and ignored on receipt.
予約ビット（8ビット）：これらは将来使用するためのものであり、受信時にゼロにして無視する必要があります（SHOULD）。
Attribute (8 bits): [RFC5521] defines several Attribute values; the only permitted Attribute values for this field are 0 (Interface) or 1 (Node).
属性（8ビット）：[RFC5521]はいくつかの属性値を定義します。このフィールドに許可される属性値は0（インターフェース）または1（ノード）のみです。
Optical Interface Class List: This field is encoded as described in Section 4.1 of [RFC7581].
光インターフェースクラスリスト：このフィールドは、[RFC7581]のセクション4.1で説明されているようにエンコードされます。
The second XRO subobject type (9) is the Client Signal Information, which is defined as follows:
2番目のXROサブオブジェクトタイプ（9）は、次のように定義されるクライアント信号情報です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=9 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Client Signal Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Client Signal Information XRO Subobject
図10：クライアント信号情報XROサブオブジェクト
Refer to [RFC5521] for the definitions of X, Length, and Attribute.
X、長さ、および属性の定義については、[RFC5521]を参照してください。
Type (7 bits): The type of the Signaling Processing Exclusion field. IANA has assigned value 9 for the Client Signal Information XRO subobject type.
タイプ（7ビット）：シグナリング処理除外フィールドのタイプ。 IANAは、クライアント信号情報XROサブオブジェクトタイプに値9を割り当てています。
Reserved bits (8 bits): These are for future use and SHOULD be zeroed and ignored on receipt.
予約ビット（8ビット）：これらは将来使用するためのものであり、受信時にゼロにして無視する必要があります（SHOULD）。
Attribute (8 bits): [RFC5521] defines several Attribute values; the only permitted Attribute values for this field are 0 (Interface) or 1 (Node).
属性（8ビット）：[RFC5521]はいくつかの属性値を定義します。このフィールドに許可される属性値は0（インターフェース）または1（ノード）のみです。
Client Signal Information: This field is encoded as described in Section 4.2 of [RFC7581].
クライアント信号情報：このフィールドは、[RFC7581]のセクション4.2で説明されているようにエンコードされます。
The XRO needs to support the new Signaling Processing Exclusion XRO subobject types:
XROは、新しいSignaling Processing Exclusion XROサブオブジェクトタイプをサポートする必要があります。
8: Optical Interface Class List
8：光インターフェースクラスリスト
9: Client Signal Information
9：クライアント信号情報
Similar to the XRO subobject, the PCC/PCE should be able to include particular types of signal processing along the path in order to handle client restriction or multi-domain path computation. [RFC5440] defines how the Include Route Object (IRO) subobject is used. In this document, we add two new Signal Processing Inclusion subobjects.
XROサブオブジェクトと同様に、PCC / PCEは、クライアント制限またはマルチドメインパス計算を処理するために、パスに沿って特定のタイプの信号処理を含めることができる必要があります。 [RFC5440]は、ルートオブジェクトを含む（IRO）サブオブジェクトの使用方法を定義します。このドキュメントでは、2つの新しいSignal Processing Inclusionサブオブジェクトを追加します。
The IRO needs to support the new IRO subobject types (8 and 9) for the PCEP IRO object [RFC5440]:
IROは、PCEP IROオブジェクト[RFC5440]の新しいIROサブオブジェクトタイプ（8および9）をサポートする必要があります。
8: Optical Interface Class List
8：光インターフェースクラスリスト
9: Client Signal Information
9：クライアント信号情報
The encoding of the Signal Processing Inclusion subobjects is similar to the process in Section 4.4.1 where the 'X' field is replaced with the 'L' field; all the other fields remain the same. The 'L' field is described in [RFC3209].
信号処理包含サブオブジェクトのエンコーディングは、セクション4.4.1のプロセスに似ていますが、「X」フィールドが「L」フィールドに置き換えられます。他のすべてのフィールドは同じままです。 'L'フィールドは[RFC3209]で説明されています。
This section provides the encoding of an RWA Path Reply for a wavelength allocation request as discussed in Section 4.
このセクションでは、セクション4で説明した波長割り当て要求に対するRWAパス応答のエンコードについて説明します。
Recall that wavelength allocation can be performed by the PCE by means of:
PCEは次の方法で波長割り当てを実行できることを思い出してください。
(a) Explicit Label Control (ELC) where the PCE allocates which label to use for each interface/node along the path.
（a）明示的ラベル制御（ELC）。PCEは、パスに沿った各インターフェース/ノードに使用するラベルを割り当てます。
(b) A Label Set where the PCE provides a range of potential labels to be allocated by each node along the path.
（b）PCEがパスに沿って各ノードによって割り当てられる一連の潜在的なラベルを提供するラベルセット。
Option (b) allows distributed label allocation (performed during signaling) to complete wavelength allocation.
オプション（b）では、（シグナリング中に実行される）分散ラベル割り当てで波長割り当てを完了することができます。
The type for the Wavelength Allocation TLV is 10 (see Section 8.4). Note that this TLV is used for both (a) and (b) above. The TLV data is defined as follows:
波長割り当てTLVのタイプは10です（セクション8.4を参照）。このTLVは、上記の（a）と（b）の両方に使用されることに注意してください。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier |
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Allocated Wavelength(s) |
// . . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Wavelength Allocation TLV Encoding
図11：波長割り当てTLVエンコーディング
Reserved (16 bits): Reserved for future use.
予約済み（16ビット）：将来の使用のために予約されています。
Flags field (16 bits): One flag bit is allocated as follows:
フラグフィールド（16ビット）：次のように1つのフラグビットが割り当てられます。
M (1 bit): Wavelength Allocation Mode.
M（1ビット）：波長割り当てモード。
0: Indicates the allocation relies on the use of Label Sets.
0：割り当てがラベルセットの使用に依存していることを示します。
1: Indicates the allocation is done using Explicit Label Control.
1：明示的なラベル制御を使用して割り当てが行われたことを示します。
IANA has created a new registry to manage the Flags field of the Wavelength Allocation TLV.
IANAは、波長割り当てTLVのフラグフィールドを管理するための新しいレジストリを作成しました。
Link Identifier: Identifies the interface to which the assignment wavelength(s) is applied. See Section 4.3.1 for encoding of the Link Identifier field.
リンク識別子：割り当て波長が適用されるインターフェースを識別します。リンク識別子フィールドのエンコーディングについては、セクション4.3.1を参照してください。
Allocated Wavelength(s): Indicates the allocated wavelength(s) to be associated with the link identifier. See Section 4.3.2 for encoding details.
割り当てられた波長：リンク識別子に関連付けられる割り当てられた波長を示します。エンコーディングの詳細については、セクション4.3.2を参照してください。
This TLV is carried in a PCRep message as an Attribute TLV [RFC5420] in the Hop Attribute subobjects [RFC7570] in the Explicit Route Object (ERO) [RFC5440].
このTLVは、明示ルートオブジェクト（ERO）[RFC5440]のホップ属性サブオブジェクト[RFC7570]の属性TLV [RFC5420]としてPCRepメッセージで伝達されます。
To indicate errors associated with the RWA request, a new Error-Type 27 (WSON RWA Error) and subsequent Error-values are defined as follows for inclusion in the PCEP-ERROR object:
RWA要求に関連するエラーを示すために、PCEP-ERRORオブジェクトに含めるために、新しいエラータイプ27（WSON RWAエラー）および後続のエラー値が次のように定義されています。
* Error-Type=27; Error-value=1: If a PCE receives an RWA request and the PCE is not capable of processing the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP-ERROR object with Error-Type=27 and Error-value=1. The PCE stops processing the request. The corresponding RWA request MUST be canceled at the PCC.
* Error-Type = 27; Error-value = 1：PCEがRWA要求を受信し、メモリ不足のためにPCEが要求を処理できない場合、PCEは、Error-Type = 27およびError-Type = 27のPCEP-ERRORオブジェクトを含むPCErrメッセージを送信する必要があります。値= 1。 PCEは要求の処理を停止します。対応するRWA要求はPCCでキャンセルする必要があります。
* Error-Type=27; Error-value=2: If a PCE receives an RWA request and the PCE is not capable of RWA computation, the PCE MUST send a PCErr message with a PCEP-ERROR object with Error-Type=27 and Error-value=2. The PCE stops processing the request. The corresponding RWA computation MUST be canceled at the PCC.
* Error-Type = 27; Error-value = 2：PCEがRWA要求を受信し、PCEがRWA計算に対応していない場合、PCEは、Error-Type = 27およびError-value = 2のPCEP-ERRORオブジェクトを持つPCErrメッセージを送信する必要があります。 PCEは要求の処理を停止します。対応するRWA計算は、PCCでキャンセルする必要があります。
* Error-Type=27; Error-value=3: If a PCE receives an RWA request and there are syntactical encoding errors (e.g., not exactly two link identifiers with the range case, unknown identifier types, no matching link for a given identifier, unknown Action value, etc.), the PCE MUST send a PCErr message with a PCEP-ERROR object with Error-Type=27 and Error-value=3.
* Error-Type = 27; Error-value = 3：PCEがRWAリクエストを受信し、構文エンコードエラーがある場合（たとえば、範囲の大文字小文字が区別された2つのリンク識別子、不明な識別子タイプ、特定の識別子に一致するリンクがない、不明なアクション値など）。 ）、PCEは、Error-Type = 27およびError-value = 3のPCEP-ERRORオブジェクトを含むPCErrメッセージを送信する必要があります。
To communicate the reason(s) for not being able to find RWA for the path request, the NO-PATH object can be used in the corresponding response. The format of the NO-PATH object body is defined in [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed.
パス要求のRWAが見つからない理由を伝えるために、対応する応答でNO-PATHオブジェクトを使用できます。 NO-PATHオブジェクト本体の形式は、[RFC5440]で定義されています。オブジェクトには、パス計算が失敗した理由に関する追加情報を提供するNO-PATH-VECTOR TLVが含まれる場合があります。
This document defines a new bit flag to be carried in the Flags field in the NO-PATH-VECTOR TLV, which is carried in the NO-PATH object:
このドキュメントでは、NO-PATHオブジェクトで伝送されるNO-PATH-VECTOR TLVのFlagsフィールドで伝送される新しいビットフラグを定義します。
Bit 23: When set, the PCE indicates no feasible route was found that meets all the constraints (e.g., wavelength restriction, signal compatibility, etc.) associated with RWA.
ビット23：セットされている場合、PCEは、RWAに関連付けられたすべての制約（たとえば、波長制限、信号の互換性など）を満たす実現可能なルートが見つからなかったことを示します。
Manageability of WSON RWA with PCE must address the considerations in the following subsections.
PCEを使用したWSON RWAの管理性は、以下のサブセクションの考慮事項に対処する必要があります。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuration of the following PCEP session parameters on a PCC:
[RFC5440]のセクション8.1にすでにリストされているパラメーターに加えて、PCEP実装では、PCCで次のPCEPセッションパラメーターを構成できる必要があります（SHOULD）。
* The ability to send a WSON RWA request.
* WSON RWAリクエストを送信する機能。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuration of the following PCEP session parameters on a PCE:
[RFC5440]のセクション8.1にすでにリストされているパラメーターに加えて、PCEP実装では、PCEで次のPCEPセッションパラメーターを構成できる必要があります（SHOULD）。
* The support for WSON RWA.
* WSON RWAのサポート。
* A set of WSON-RWA-specific policies (authorized sender, request rate limiter, etc).
* WSON-RWA固有のポリシーのセット（承認された送信者、リクエストレートリミッターなど）。
These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or they may apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers.
これらのパラメーターは、PCEPスピーカーが参加するPCEPセッションのデフォルトパラメーターとして構成するか、特定のPCEPピアとの特定のセッションまたはPCEPピアの特定のグループとの特定のセッショングループに適用できます。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements, aside from those already listed in Section 8.3 of [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]のセクション8.3にすでにリストされているものを除いて、新しい活性検出と監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new verification requirements, aside from those already listed in Section 8.4 of [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]のセクション8.4にすでにリストされているものを除いて、新しい検証要件を意味するものではありません。
The PCEP Link-State mechanism [PCEP-LS] may be used to advertise WSON RWA path computation capabilities to PCCs.
PCEPリンク状態メカニズム[PCEP-LS]は、WSON RWAパス計算機能をPCCに通知するために使用できます。
Mechanisms defined in this document do not imply any new network operation requirements, aside from those already listed in Section 8.6 of [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]のセクション8.6にすでにリストされているものを除いて、新しいネットワーク操作要件を意味するものではありません。
The security considerations discussed in [RFC5440] are relevant for this document; this document does not introduce any new security issues. If an operator wishes to keep the information distributed by WSON private, PCEPS (Usage of TLS to Provide a Secure Transport for PCEP) [RFC8253] SHOULD be used.
[RFC5440]で説明されているセキュリティの考慮事項は、このドキュメントに関連しています。このドキュメントでは、新しいセキュリティの問題は紹介されていません。オペレーターがWSONによって配布された情報を非公開にしたい場合は、PCEPS（PCEPにセキュアなトランスポートを提供するためのTLSの使用）[RFC8253]を使用する必要があります。
IANA maintains a registry of PCEP parameters. IANA has made allocations from the subregistries as described in the following sections.
IANAはPCEPパラメータのレジストリを維持しています。 IANAは、以下のセクションで説明するように、サブレジストリから割り当てを行いました。
As described in Section 4.1, a new PCEP object is defined to carry wavelength-assignment-related constraints. IANA has allocated the following in the "PCEP Objects" subregistry [PCEP-NUMBERS]:
セクション4.1で説明したように、新しいPCEPオブジェクトは、波長割り当て関連の制約を運ぶように定義されています。 IANAは、「PCEPオブジェクト」サブレジストリ[PCEP-NUMBERS]で以下を割り当てました。
+====================+======+==========================+===========+
| Object-Class Value | Name | Object-Type | Reference |
+====================+======+==========================+===========+
| 42 | WA | 0: Reserved | RFC 8780 |
+--------------------+------+--------------------------+-----------+
| | | 1: Wavelength Assignment | RFC 8780 |
+--------------------+------+--------------------------+-----------+
Table 1
表1
As described in Section 4.1, IANA has created the "WA Object Flag Field" subregistry under the "Path Computation Element Protocol (PCEP) Numbers" registry [PCEP-NUMBERS] to manage the Flags field of the WA object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
セクション4.1で説明したように、IANAは「パス計算要素プロトコル（PCEP）番号」レジストリ[PCEP-NUMBERS]の下に「WAオブジェクトフラグフィールド」サブレジストリを作成して、WAオブジェクトのフラグフィールドを管理しています。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとしてカウント）
* Capability description
* 機能の説明
* Defining RFC
* RFCの定義
The initial contents of this registry are shown below. One bit has been allocated for the flag defined in this document:
このレジストリの初期の内容を以下に示します。このドキュメントで定義されているフラグには、1ビットが割り当てられています。
+======+============================+===========+
| Bit | Description | Reference |
+======+============================+===========+
| 0-14 | Unassigned | |
+------+----------------------------+-----------+
| 15 | Wavelength Allocation Mode | RFC 8780 |
+------+----------------------------+-----------+
Table 2
表2
In Section 4.2, a new PCEP TLV is defined to indicate wavelength selection constraints. IANA has made the following allocation in the "PCEP TLV Type Indicators" subregistry [PCEP-NUMBERS]:
セクション4.2では、新しいPCEP TLVが定義され、波長選択の制約を示します。 IANAは、「PCEP TLVタイプインジケーター」サブレジストリ[PCEP-NUMBERS]で次の割り当てを行いました。
+=======+======================+===========+
| Value | Description | Reference |
+=======+======================+===========+
| 8 | Wavelength Selection | RFC 8780 |
+-------+----------------------+-----------+
Table 3
表3
In Section 4.3, a new PCEP TLV is defined to indicate wavelength restrictions. IANA has made the following allocation in the "PCEP TLV Type Indicators" subregistry [PCEP-NUMBERS]:
セクション4.3では、波長制限を示す新しいPCEP TLVが定義されています。 IANAは、「PCEP TLVタイプインジケーター」サブレジストリ[PCEP-NUMBERS]で次の割り当てを行いました。
+=======+========================+===========+
| Value | Description | Reference |
+=======+========================+===========+
| 9 | Wavelength Restriction | RFC 8780 |
+-------+------------------------+-----------+
Table 4
表4
As described in Section 4.3, IANA has created the new "Wavelength Restriction TLV Action Values" subregistry under the "Path Computation Element Protocol (PCEP) Numbers" registry [PCEP-NUMBERS] to manage the Action values of the Action field of the Wavelength Restriction TLV. New values are assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities:
セクション4.3で説明したように、IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ[PCEP-NUMBERS]の下に新しい「波長制限TLVアクション値」サブレジストリを作成して、波長制限のアクションフィールドのアクション値を管理しますTLV。新しい値は、標準アクション[RFC8126]によって割り当てられます。各値は、次の品質で追跡する必要があります。
* Value
* 値
* Meaning
* 意味
* Defining RFC
* RFCの定義
The initial contents of this registry are shown below:
このレジストリの初期の内容は次のとおりです。
+=======+=================+===========+
| Value | Meaning | Reference |
+=======+=================+===========+
| 0 | Inclusive List | RFC 8780 |
+-------+-----------------+-----------+
| 1 | Inclusive Range | RFC 8780 |
+-------+-----------------+-----------+
| 2-255 | Unassigned | |
+-------+-----------------+-----------+
Table 5
表5
In Section 5.1, a new PCEP TLV is defined to indicate the allocation of the wavelength(s) by the PCE in response to a request by the PCC. IANA has made the following allocation in "PCEP TLV Type Indicators" subregistry [PCEP-NUMBERS]:
セクション5.1では、PCCからの要求に応じてPCEが波長を割り当てることを示すために、新しいPCEP TLVが定義されています。 IANAは、「PCEP TLVタイプインジケーター」サブレジストリ[PCEP-NUMBERS]で次の割り当てを行いました。
+=======+=======================+===========+
| Value | Description | Reference |
+=======+=======================+===========+
| 10 | Wavelength Allocation | RFC 8780 |
+-------+-----------------------+-----------+
Table 6
表6
As described in Section 5.1, IANA has created a new "Wavelength Allocation TLV Flag Field" subregistry under the "Path Computation Element Protocol (PCEP) Numbers" registry [PCEP-NUMBERS] to manage the Flags field of the Wavelength Allocation TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
セクション5.1で説明したように、IANAは、「パス計算エレメントプロトコル（PCEP）番号」レジストリ[PCEP-NUMBERS]の下に新しい「波長割り当てTLVフラグフィールド」サブレジストリを作成して、波長割り当てTLVのフラグフィールドを管理します。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとしてカウント）
* Capability description
* 機能の説明
* Defining RFC
* RFCの定義
One bit is defined for the flag defined in this document. The initial contents of this registry are shown below:
このドキュメントで定義されているフラグには1ビットが定義されています。このレジストリの初期の内容は次のとおりです。
+======+============================+===========+
| Bit | Description | Reference |
+======+============================+===========+
| 0-14 | Unassigned | |
+------+----------------------------+-----------+
| 15 | Wavelength Allocation Mode | RFC 8780 |
+------+----------------------------+-----------+
Table 7
表7
In Section 4.4, a new PCEP TLV is defined to indicate the Optical Interface Class List. IANA has made the following allocation in the "PCEP TLV Type Indicators" subregistry [PCEP-NUMBERS]:
セクション4.4では、新しいPCEP TLVが定義され、光インターフェースクラスリストを示します。 IANAは、「PCEP TLVタイプインジケーター」サブレジストリ[PCEP-NUMBERS]で次の割り当てを行いました。
+=======+==============================+===========+
| Value | Description | Reference |
+=======+==============================+===========+
| 11 | Optical Interface Class List | RFC 8780 |
+-------+------------------------------+-----------+
Table 8
表8
In Section 4.4, a new PCEP TLV is defined to indicate the Client Signal Information. IANA has made the following allocation in the "PCEP TLV Type Indicators" subregistry [PCEP-NUMBERS]:
セクション4.4では、クライアント信号情報を示すために新しいPCEP TLVが定義されています。 IANAは、「PCEP TLVタイプインジケーター」サブレジストリ[PCEP-NUMBERS]で次の割り当てを行いました。
+=======+===========================+===========+
| Value | Description | Reference |
+=======+===========================+===========+
| 12 | Client Signal Information | RFC 8780 |
+-------+---------------------------+-----------+
Table 9
表9
In Section 5.3, a new bit flag is defined to be carried in the Flags field in the NO-PATH-VECTOR TLV, which is carried in the NO-PATH object. This flag, when set, indicates that no feasible route was found that meets all the RWA constraints (e.g., wavelength restriction, signal compatibility, etc.) associated with an RWA path computation request.
セクション5.3では、NO-PATHオブジェクトで伝送されるNO-PATH-VECTOR TLVのFlagsフィールドで伝送される新しいビットフラグが定義されています。このフラグが設定されている場合、RWAパス計算要求に関連付けられているすべてのRWA制約（たとえば、波長制限、信号の互換性など）を満たす実行可能なルートが見つからなかったことを示します。
IANA has made the following allocation for this new bit flag in the "NO-PATH-VECTOR TLV Flag Field" subregistry [PCEP-NUMBERS]:
IANAは、「NO-PATH-VECTOR TLVフラグフィールド」サブレジストリ[PCEP-NUMBERS]で、この新しいビットフラグに次の割り当てを行いました。
+=====+========================+===========+
| Bit | Description | Reference |
+=====+========================+===========+
| 23 | No RWA constraints met | RFC 8780 |
+-----+------------------------+-----------+
Table 10
表10
In Section 5.2, new PCEP error codes are defined for WSON RWA errors. IANA has made the following allocations in the "PCEP-ERROR Object Error Types and Values" subregistry [PCEP-NUMBERS]:
セクション5.2では、新しいPCEPエラーコードがWSON RWAエラーに対して定義されています。 IANAは、「PCEP-ERRORオブジェクトのエラータイプと値」サブレジストリ[PCEP-NUMBERS]で次の割り当てを行いました。
+============+================+========================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+================+========================+===========+
| 27 | WSON RWA error | 0: Unassigned | RFC 8780 |
+------------+----------------+------------------------+-----------+
| | | 1: Insufficient memory | RFC 8780 |
+------------+----------------+------------------------+-----------+
| | | 2: RWA computation not | RFC 8780 |
| | | supported | |
+------------+----------------+------------------------+-----------+
| | | 3: Syntactical | RFC 8780 |
| | | encoding error | |
+------------+----------------+------------------------+-----------+
| | | 4-255: Unassigned | RFC 8780 |
+------------+----------------+------------------------+-----------+
Table 11
表11
The "Path Computation Element Protocol (PCEP) Numbers" registry contains a subregistry titled "XRO Subobjects" [PCEP-NUMBERS]. Per Section 4.4.1, IANA has added the following subobjects that can be carried in the XRO:
「パス計算要素プロトコル（PCEP）番号」レジストリには、「XROサブオブジェクト」[PCEP-NUMBERS]というサブレジストリが含まれています。セクション4.4.1に従って、IANAはXROで運ぶことができる次のサブオブジェクトを追加しました：
+=======+==============================+===========+
| Value | Description | Reference |
+=======+==============================+===========+
| 8 | Optical Interface Class List | RFC 8780 |
+-------+------------------------------+-----------+
| 9 | Client Signal Information | RFC 8780 |
+-------+------------------------------+-----------+
Table 12
表12
The "Path Computation Element Protocol (PCEP) Numbers" registry contains a subregistry titled "IRO Subobjects" [PCEP-NUMBERS]. Per Section 4.4.2, IANA has added the following subobjects that can be carried in the IRO:
「Path Computation Element Protocol（PCEP）Numbers」レジストリには、「IRO Subobjects」[PCEP-NUMBERS]というサブレジストリが含まれています。セクション4.4.2に従って、IANAはIROで運ぶことができる次のサブオブジェクトを追加しました。
+=======+==============================+===========+
| Value | Description | Reference |
+=======+==============================+===========+
| 8 | Optical Interface Class List | RFC 8780 |
+-------+------------------------------+-----------+
| 9 | Client Signal Information | RFC 8780 |
+-------+------------------------------+-----------+
Table 13
表13
The "TE_LINK Object Class type name space (Value 11)" registry was created for the Link Management Protocol (LMP) [RFC4204]. As discussed in Section 4.3.1, IANA has added the following note at the top of the "TE_LINK Object Class type name space (Value 11)" registry [LMP-PARAM]:
「TE_LINK Object Class type name space（Value 11）」レジストリは、Link Management Protocol（LMP）[RFC4204]用に作成されました。セクション4.3.1で説明したように、IANAは「TE_LINKオブジェクトクラスタイプの名前空間（値11）」レジストリ[LMP-PARAM]の先頭に次のメモを追加しました。
These values have additional usage for the Link Identifier Type field.
これらの値には、リンク識別子タイプフィールドの追加の使用法があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A.、and A. Lindem、Ed。、 "Traffic Engineering Extensions to OSPF Version 3"、RFC 5329、DOI 10.17487 / RFC5329、September 2008、<https： //www.rfc-editor.org/info/rfc5329>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、Ed。、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011, <https://www.rfc-editor.org/info/rfc6205>.
[RFC6205] Otani、T.、Ed。およびD. Li、編、「Lambda-Switch-Capable（LSC）ラベルスイッチングルーターの一般化されたラベル」、RFC 6205、DOI 10.17487 / RFC6205、2011年3月、<https://www.rfc-editor.org/info / rfc6205>。
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <https://www.rfc-editor.org/info/rfc7570>.
[RFC7570] Margaria、C.、Ed。、Martinelli、G.、Balls、S。、およびB. Wright、「明示的なルートオブジェクト（ERO）のラベルスイッチドパス（LSP）属性」、RFC 7570、DOI 10.17487 / RFC7570、2015年7月、<https://www.rfc-editor.org/info/rfc7570>。
[RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015, <https://www.rfc-editor.org/info/rfc7579>.
[RFC7579] Bernstein、G.、Ed。、Lee、Y.、Ed。、Li、D.、Imajuku、W.、and J. Han、 "General Network Element Constraint Encoding for GMPLS-Controlled Networks"、RFC 7579、 DOI 10.17487 / RFC7579、2015年6月、<https://www.rfc-editor.org/info/rfc7579>。
[RFC7581] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", RFC 7581, DOI 10.17487/RFC7581, June 2015, <https://www.rfc-editor.org/info/rfc7581>.
[RFC7581] Bernstein、G.、Ed。、Lee、Y.、Ed。、Li、D.、Imajuku、W.、and J. Han、 "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks"、RFC 7581 、DOI 10.17487 / RFC7581、2015年6月、<https://www.rfc-editor.org/info/rfc7581>。
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, DOI 10.17487/RFC7688, November 2015, <https://www.rfc-editor.org/info/rfc7688>.
[RFC7688]リー、Y、エド。およびG.バーンスタイン編、「波長スイッチ光ネットワークの信号およびネットワーク要素互換性のためのGMPLS OSPF拡張機能」、RFC 7688、DOI 10.17487 / RFC7688、2015年11月、<https://www.rfc-editor.org/info / rfc7688>。
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., and H. Harai, "Signaling Extensions for Wavelength Switched Optical Networks", RFC 7689, DOI 10.17487/RFC7689, November 2015, <https://www.rfc-editor.org/info/rfc7689>.
[RFC7689] Bernstein、G.、Ed。、Xu、S.、Lee、Y.、Ed。、Martinelli、G.、and H. Harai、 "Signaling Extensions for Wavelength Switched Optical Networks"、RFC 7689、DOI 10.17487 / RFC7689、2015年11月、<https://www.rfc-editor.org/info/rfc7689>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（PCEP）のセキュアなトランスポートの提供」、RFC 8253 、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F. Zhang, Ed., "Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS", RFC 8779, DOI 10.17487/RFC8779, July 2020, <https://www.rfc-editor.org/info/rfc8779>.
[RFC8779] Margaria、C。、編、Gonzalez de Dios、O。、編、およびF. Zhang、編、「GMPLSのパス計算要素通信プロトコル（PCEP）拡張機能」、RFC 8779、DOI 10.17487 / RFC8779 、2020年7月、<https://www.rfc-editor.org/info/rfc8779>。
[LMP-PARAM] IANA, "Link Management Protocol (LMP) Parameters", <https://www.iana.org/assignments/lmp-parameters/>.
[LMP-PARAM] IANA、「Link Management Protocol（LMP）Parameters」、<https://www.iana.org/assignments/lmp-parameters/>。
[PCEP-LS] Lee, Y., Zheng, H., Ceccarelli, D., Wang, W., Park, P., and B. Yoon, "PCEP Extension for Distribution of Link-State and TE information for Optical Networks", Work in Progress, Internet-Draft, draft-lee-pce-pcep-ls-optical-09, 9 March 2020, <https://tools.ietf.org/html/draft-lee-pce-pcep-ls-optical-09>.
[PCEP-LS] Lee、Y.、Zheng、H.、Ceccarelli、D.、Wang、W.、Park、P。、およびB. Yoon、「光ネットワークのリンク状態およびTE情報の配布のためのPCEP拡張"、Work in Progress、Internet-Draft、draft-lee-pce-pcep-ls-optical-09、2020年3月9日、<https://tools.ietf.org/html/draft-lee-pce-pcep-ls -optical-09>。
[PCEP-NUMBERS] IANA, "Path Computation Element Protocol (PCEP) Numbers", <https://www.iana.org/assignments/pcep/>.
[PCEP-NUMBERS] IANA、「Path Computation Element Protocol（PCEP）Numbers」、<https://www.iana.org/assignments/pcep/>。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<https://www.rfc-editor.org/ info / rfc3471>。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, DOI 10.17487/RFC4204, October 2005, <https://www.rfc-editor.org/info/rfc4204>.
[RFC4204] Lang、J。、編、「リンク管理プロトコル（LMP）」、RFC 4204、DOI 10.17487 / RFC4204、2005年10月、<https://www.rfc-editor.org/info/rfc4204>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangar, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>.
[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangar、「リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<https://www.rfc-editor.org/info/rfc5420>。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, <https://www.rfc-editor.org/info/rfc5521>.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「Extensions to the Path Computation Element Communication Protocol（PCEP）for Route Exclusions」、RFC 5521、DOI 10.17487 / RFC5521、2009年4月、<https：/ /www.rfc-editor.org/info/rfc5521>。
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <https://www.rfc-editor.org/info/rfc6163>.
[RFC6163] Lee、Y.、Ed。、Bernstein、G.、Ed。、およびW. Imajuku、「GMPLSおよびPath Computation Element（PCE）Control for Wavelength Switched Optical Networks（WSONs）」、RFC 6163、DOI 10.17487 / RFC6163、2011年4月、<https://www.rfc-editor.org/info/rfc6163>。
[RFC6566] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments", RFC 6566, DOI 10.17487/RFC6566, March 2012, <https://www.rfc-editor.org/info/rfc6566>.
[RFC6566] Lee、Y.、Ed。、Bernstein、G.、Ed。、Li、D。、およびG. Martinelli、「障害のある波長スイッチ光ネットワーク（WSON）の制御のフレームワーク」、RFC 6566、 DOI 10.17487 / RFC6566、2012年3月、<https://www.rfc-editor.org/info/rfc6566>。
[RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, DOI 10.17487/RFC7446, February 2015, <https://www.rfc-editor.org/info/rfc7446>.
[RFC7446] Lee、Y.、Ed。、Bernstein、G.、Ed。、Li、D。、およびW. Imajuku、「Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks」、RFC 7446、DOI 10.17487 / RFC7446 、2015年2月、<https://www.rfc-editor.org/info/rfc7446>。
[RFC7449] Lee, Y., Ed., Bernstein, G., Ed., Martensson, J., Takeda, T., Tsuritani, T., and O. Gonzalez de Dios, "Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment", RFC 7449, DOI 10.17487/RFC7449, February 2015, <https://www.rfc-editor.org/info/rfc7449>.
[RFC7449] Lee、Y.、Ed。、Bernstein、G.、Ed。、Martensson、J.、Takeda、T.、Turitani、T。、およびO. Gonzalez de Dios、「Path Computation Element Communication Protocol（PCEP） Wavelength Switched Optical Network（WSON）Routing and Wavelength Assignment」、RFC 7449、DOI 10.17487 / RFC7449、2015年2月、<https://www.rfc-editor.org/info/rfc7449>の要件。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgments
謝辞
The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv Dhody, and Benjamin Kaduk for many helpful comments that greatly improved the contents of this document.
このドキュメントの内容を大幅に改善してくれた多くの役立つコメントを提供してくれたAdrian Farrel、Julien Meuric、Dhruv Dhody、Benjamin Kadukに感謝します。
Contributors
貢献者
Fatai Zhang Huawei Technologies
fa too Zhang hu Aはテクノロジーです
Email: zhangfatai@huawei.com
Cyril Margaria Nokia Siemens Networks St. Martin Strasse 76 81541 Munich Germany
Cyril Margaria Nokia Siemens Networks St. Martin Strasse 76 81541ミュンヘンドイツ
Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com
Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo C/ Emilio Vargas 6 28043 Madrid Spain
Oscar Gonzalez de Dios Telefonica Research and Development C / Emilio Vargas 6 28043マドリードスペイン
Phone: +34 91 3374013
Email: ogondio@tid.es
Greg Bernstein Grotto Networking Fremont, CA United States of America
グレッグバーンスタイングロットネットワーキングフリーモント、カリフォルニア州アメリカ合衆国
Phone: +1 510 573 2237
Email: gregb@grotto-networking.com
Authors' Addresses
著者のアドレス
Young Lee (editor) Samsung Electronics
ヤング・リー（編集者）サムスン電子
Email: younglee.tx@gmail.com
Ramon Casellas, Editor (editor) CTTC Carl Friedrich Gauss 7 PMT Ed B4 Av. 08860 Castelldefels Barcelona Spain
Ramon Casellas、編集者（編集者）CTTC Carl Friedrich Gauss 7 PMT Ed B4 Av。 08860 Castelldefelsバルセロナスペイン
Phone: +34 936452916
Email: ramon.casellas@cttc.es