[要約] RFC 8282は、PCEPを拡張し、異なるレイヤー間のMPLSおよびGMPLSトラフィックエンジニアリングをサポートするためのものです。目的は、ネットワークの効率性と柔軟性を向上させ、異なるレイヤー間のトラフィック制御を可能にすることです。
Internet Engineering Task Force (IETF) E. Oki
Request for Comments: 8282 Kyoto University
Category: Standards Track T. Takeda
ISSN: 2070-1721 NTT
A. Farrel
Juniper Networks
F. Zhang
Huawei Technologies Co., Ltd.
December 2017
Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
レイヤー間MPLSおよびGMPLSトラフィックエンジニアリングのためのパス計算要素通信プロトコル（PCEP）の拡張
Abstract
概要
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
パス計算要素（PCE）は、マルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークでのトラフィックエンジニアリングをサポートするパス計算機能を提供します。
MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.
MPLSおよびGMPLSネットワークは、階層化されたサービスネットワークから構築できます。レイヤー間トラフィックエンジニアリングと呼ばれるプロセスを通じて、複数のネットワークレイヤーにわたってエンドツーエンドのトラフィックエンジニアリングを提供することは、ネットワーク全体の効率にとって有利です。 PCEは、このような要件に対するソリューションの候補です。
The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.
PCE通信プロトコル（PCEP）は、パス計算クライアント（PCC）とPCE間の通信プロトコルとして設計されています。このドキュメントでは、レイヤ間のトラフィックエンジニアリングのためのPCEP拡張について説明します。
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コミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8282.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8282で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of PCE-Based Inter-Layer Path Computation . . . . . 4
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
3.1. INTER-LAYER Object . . . . . . . . . . . . . . . . . . . 5
3.2. SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . . 8
3.3. REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . . 9
3.4. New Metric Types . . . . . . . . . . . . . . . . . . . . 10
3.5. SERVER-INDICATION Object . . . . . . . . . . . . . . . . 11
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Path Computation Request . . . . . . . . . . . . . . . . 11
4.2. Path Computation Reply . . . . . . . . . . . . . . . . . 12
4.3. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . 13
5. Updated Format of PCEP Messages . . . . . . . . . . . . . . . 14
6. Manageability Considerations . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. New PCEP Objects . . . . . . . . . . . . . . . . . . . . 16
7.2. New Registry for INTER-LAYER Object Flags . . . . . . . . 17
7.3. New Metric Types . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed, and a PCE may initiate or modify services in a network by supplying new paths [RFC8231] [RFC8281].
[RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算制約を適用できるエンティティです。パス計算クライアント（PCC）は、計算するパスをPCEに要求し、PCEは新しいパス[RFC8231] [RFC8281]を提供することにより、ネットワーク内のサービスを開始または変更します。
A network may comprise multiple layers. These layers may represent separation of technologies (e.g., packet switch capable (PSC), time division multiplex (TDM), and lambda switch capable (LSC)) [RFC3945]; separation of data-plane switching granularity levels (e.g., Virtual Circuit 4 (VC4) and VC12) [RFC5212]; or a distinction between client and server networking roles (e.g., commercial or administrative separation of client and server networks). In this multi-layer network, Label Switched Paths (LSPs) in lower layers are used to carry higher-layer LSPs. The network topology formed by lower-layer LSPs and advertised as traffic engineering links (TE links) in the higher layer is called a Virtual Network Topology (VNT) [RFC5212]. Discussion of other ways that network layering can be supported such that connectivity in a higher-layer network can be provided by LSPs in a lower-layer network is provided in [RFC7926].
ネットワークは複数の層で構成されます。これらの層は、テクノロジーの分離を表す場合があります（たとえば、パケットスイッチ対応（PSC）、時分割多重（TDM）、ラムダスイッチ対応（LSC））[RFC3945]。データプレーンスイッチングの粒度レベルの分離（例：Virtual Circuit 4（VC4）およびVC12）[RFC5212];または、クライアントとサーバーのネットワークの役割の違い（たとえば、クライアントとサーバーのネットワークの商用または管理上の分離）。このマルチレイヤーネットワークでは、下位レイヤーのラベルスイッチドパス（LSP）を使用して、上位レイヤーのLSPを伝送します。下位層のLSPによって形成され、上位層でトラフィックエンジニアリングリンク（TEリンク）としてアドバタイズされるネットワークトポロジは、仮想ネットワークトポロジ（VNT）[RFC5212]と呼ばれます。 [RFC7926]には、下位層ネットワークのLSPによって上位層ネットワークの接続を提供できるように、ネットワーク階層化をサポートできる他の方法の説明があります。
It is important to optimize network resource utilization globally, i.e., taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved. This is what we call inter-layer traffic engineering. This includes mechanisms allowing the computation of end-to-end paths across layers (known as inter-layer path computation) and mechanisms for control and management of the VNT by setting up and releasing LSPs in the lower layers [RFC5212].
各層でのリソース使用率を個別に最適化するのではなく、ネットワークリソースの使用率をグローバルに最適化すること、つまりすべての層を考慮に入れることが重要です。これにより、ネットワーク効率が向上します。これは、層間トラフィックエンジニアリングと呼ばれるものです。これには、レイヤー間のエンドツーエンドパスの計算を可能にするメカニズム（レイヤー間パス計算と呼ばれます）と、下位レイヤーでLSPを設定および解放することによるVNTの制御と管理のメカニズムが含まれます[RFC5212]。
PCE can provide a suitable mechanism for resolving inter-layer path computation issues. The framework for applying the PCE-based path computation architecture to inter-layer traffic engineering is described in [RFC5623].
PCEは、レイヤー間パス計算の問題を解決するための適切なメカニズムを提供できます。 PCEベースのパス計算アーキテクチャをレイヤ間のトラフィックエンジニアリングに適用するためのフレームワークは、[RFC5623]で説明されています。
The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [RFC5440]. A set of requirements for PCEP extensions to support inter-layer traffic engineering is described in [RFC6457].
PCE通信プロトコル（PCEP）は、PCCとPCE間の通信プロトコルとして設計されており、[RFC5440]で定義されています。レイヤ間トラフィックエンジニアリングをサポートするPCEP拡張機能の一連の要件は、[RFC6457]で説明されています。
This document presents PCEP extensions for inter-layer traffic engineering that satisfy the requirements described in [RFC6457].
このドキュメントでは、[RFC6457]で説明されている要件を満たす、レイヤ間トラフィックエンジニアリング用のPCEP拡張について説明します。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
[RFC4206] defines a way to signal a higher-layer LSP, which has an explicit route that includes hops traversed by LSPs in lower layers. The computation of end-to-end paths across layers is called inter-layer path computation.
[RFC4206]は、下位層のLSPが通過するホップを含む明示的なルートを持つ上位層LSPに信号を送る方法を定義します。レイヤー間のエンドツーエンドパスの計算は、レイヤー間パス計算と呼ばれます。
A Label Switching Router (LSR) in the higher layer might not have information on the lower-layer topology, particularly in an overlay or augmented model [RFC3945]; hence, it may not be able to compute an end-to-end path across layers.
上位層のラベルスイッチングルーター（LSR）には、特にオーバーレイモデルまたは拡張モデル[RFC3945]の下位層トポロジに関する情報がない可能性があります。したがって、レイヤー間のエンドツーエンドパスを計算できない場合があります。
PCE-based inter-layer path computation consists of using one or more PCEs to compute an end-to-end path across layers. This could be achieved by relying on a single PCE that has topology information about multiple layers and can directly compute an end-to-end path across layers considering the topology of all of the layers. Alternatively, the inter-layer path computation could be performed using multiple cooperating PCEs where each PCE has information about the topology of one or more layers (but not all layers) and where the PCEs collaborate to compute an end-to-end path.
PCEベースのレイヤー間パス計算は、1つ以上のPCEを使用して、レイヤー間のエンドツーエンドパスを計算することで構成されます。これは、複数のレイヤーに関するトポロジー情報を持ち、すべてのレイヤーのトポロジーを考慮してレイヤー間のエンドツーエンドパスを直接計算できる単一のPCEに依存することで実現できます。または、複数の協調するPCEを使用してレイヤー間パス計算を実行することもできます。各PCEは1つ以上のレイヤー（すべてのレイヤーではない）のトポロジーに関する情報を持ち、PCEは共同でエンドツーエンドパスを計算します。
As described in [RFC5339], a hybrid node may advertise a single TE link with multiple switching capabilities. Normally, those TE links exist at the layer/region boarder. In this case, a PCE needs to be capable of specifying the server-layer path information when the server-layer path information is required to be returned to the PCC.
[RFC5339]で説明されているように、ハイブリッドノードは複数のスイッチング機能を備えた単一のTEリンクをアドバタイズします。通常、それらのTEリンクはレイヤー/リージョン境界に存在します。この場合、サーバー層のパス情報をPCCに返す必要がある場合、PCEはサーバー層のパス情報を指定できる必要があります。
[RFC5623] describes models for inter-layer path computation in more detail. It introduces the Virtual Network Topology Manager (VNTM), a functional element that controls the VNT, and sets out three distinct models (and a fourth hybrid model) for inter-layer control involving a PCE, triggered signaling, and a Network Management System (NMS).
[RFC5623]は、レイヤー間パス計算のモデルをより詳細に説明しています。これは、VNTを制御する機能要素である仮想ネットワークトポロジマネージャー（VNTM）を紹介し、PCE、トリガーされたシグナリング、およびネットワーク管理システム（ NMS）。
This section describes PCEP extensions for inter-layer path computation. Four new objects are defined: the INTER-LAYER object, the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER-INDICATION object. Also, two new metric types are defined.
このセクションでは、レイヤー間パス計算のためのPCEP拡張機能について説明します。 INTER-LAYERオブジェクト、SWITCH-LAYERオブジェクト、REQ-ADAP-CAPオブジェクト、およびSERVER-INDICATIONオブジェクトの4つの新しいオブジェクトが定義されています。また、2つの新しいメトリックタイプが定義されています。
The INTER-LAYER object is optional and can be used in Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages, and also in Path Computation State Report (PCRpt), Path Computation Update Request (PCUpd), and Path Computation LSP Initiate Request (PCInitiate) messages.
INTER-LAYERオブジェクトはオプションであり、パス計算要求（PCReq）およびパス計算応答（PCRep）メッセージで使用できます。また、パス計算状態レポート（PCRpt）、パス計算更新要求（PCUpd）、およびパス計算LSPでも使用できます。要求の開始（PCInitiate）メッセージ。
In a PCReq message, the INTER-LAYER object indicates whether inter-layer path computation is allowed, the type of path to be computed, and whether triggered signaling (hierarchical LSPs per [RFC4206] or stitched LSPs per [RFC5150] depending on physical network technologies) is allowed. When the INTER-LAYER object is absent from a PCReq message, the receiving PCE MUST process as though inter-layer path computation had been explicitly disallowed (I-bit set to zero -- see below).
PCReqメッセージでは、INTER-LAYERオブジェクトは、レイヤー間パス計算が許可されるかどうか、計算されるパスのタイプ、およびトリガーされたシグナリング（[RFC4206]ごとの階層型LSPまたは物理的ネットワークに応じて[RFC5150]ごとのステッチされたLSP）を示しますテクノロジー）が許可されています。 INTER-LAYERオブジェクトがPCReqメッセージにない場合、受信PCEは、レイヤー間パス計算が明示的に禁止されているかのように処理する必要があります（Iビットがゼロに設定されています-下記を参照）。
In a PCRep message, the INTER-LAYER object indicates whether inter-layer path computation has been performed, the type of path that has been computed, and whether triggered signaling is used.
PCRepメッセージでは、INTER-LAYERオブジェクトは、レイヤー間パス計算が実行されたかどうか、計算されたパスのタイプ、およびトリガーされたシグナリングが使用されているかどうかを示します。
When a PCReq message includes more than one request, an INTER-LAYER object is used per request. When a PCRep message includes more than one path per request that is responded to, an INTER-LAYER object is used per path.
PCReqメッセージに複数のリクエストが含まれている場合、リクエストごとにINTER-LAYERオブジェクトが使用されます。 PCRepメッセージに応答する要求ごとに複数のパスが含まれる場合、パスごとにINTER-LAYERオブジェクトが使用されます。
The applicability of this object to PCRpt and PCUpd messages is the same as for other objects on those messages as described in [RFC8231]. The applicability of this object to the PCInitiate message is the same as for other objects on those messages as described in [RFC8281]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions, so the <attribute-list> as extended in Section 5 can be used to include the INTER-LAYER object on these messages.
このオブジェクトのPCRptおよびPCUpdメッセージへの適用可能性は、[RFC8231]で説明されているように、これらのメッセージの他のオブジェクトと同じです。このオブジェクトのPCInitiateメッセージへの適用性は、[RFC8281]で説明されているように、これらのメッセージの他のオブジェクトの場合と同じです。これらのメッセージは、[RFC5440]で定義され、さらにPCEP拡張によって拡張された<attribute-list>を使用するため、セクション5で拡張された<attribute-list>を使用して、これらのメッセージにINTER-LAYERオブジェクトを含めることができます。
INTER-LAYER Object-Class is 36.
INTER-LAYERオブジェクトクラスは36です。
Inter-layer Object-Type is 1.
層間オブジェクトタイプは1です。
The format of the INTER-LAYER object body is shown in Figure 1.
INTER-LAYERオブジェクト本体のフォーマットを図1に示します。
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 |T|M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The INTER-LAYER Object
図1：INTER-LAYERオブジェクト
I flag (1 bit): The I flag is used by a PCC in a PCReq message to indicate to a PCE whether an inter-layer path is allowed. When the I flag is set (one), the PCE MAY perform inter-layer path computation and return an inter-layer path. When the flag is clear (zero), the path that is returned MUST NOT be an inter-layer path.
Iフラグ（1ビット）：Iフラグは、PCCがPCReqメッセージで使用して、レイヤー間パスが許可されているかどうかをPCEに示します。 Iフラグが1に設定されている場合、PCEはレイヤー間パス計算を実行して、レイヤー間パスを返すことができます（MAY）。フラグがクリア（ゼロ）の場合、返されるパスはレイヤー間パスであってはなりません（MUST NOT）。
The I flag is used by a PCE in a PCRep message to indicate to a PCC whether the path returned is an inter-layer path. When the I flag is set (one), the path is an inter-layer path. When it is clear (zero), the path is contained within a single layer because either inter-layer path computation was not performed or a mono-layer path (without any virtual TE link and without any loose hop that spans the lower-layer network) was found notwithstanding the use of inter-layer path computation.
Iフラグは、PCReがPCRepメッセージ内で使用して、返されたパスがレイヤー間パスであるかどうかをPCCに示します。 Iフラグが1に設定されている場合、パスはレイヤー間パスです。クリア（ゼロ）の場合、レイヤー間パス計算が実行されなかったか、または単一レイヤーパス（仮想TEリンクがなく、下位レイヤーネットワークにまたがるルーズホップがない）のため、パスは単一レイヤー内に含まれます。 ）は、レイヤー間パス計算を使用しているにもかかわらず見つかりました。
M flag (1 bit): The M flag is used by a PCC in a PCReq message to indicate to a PCE whether a mono-layer path or multi-layer path is requested. When the M flag is set (one), a multi-layer path is requested. When it is clear (zero), a mono-layer path is requested.
Mフラグ（1ビット）：Mフラグは、PCReqメッセージでPCCによって使用され、単層パスと多層パスのどちらが要求されているかをPCEに示します。 Mフラグが設定されている場合（1）、マルチレイヤーパスが要求されます。クリア（ゼロ）の場合、単層パスが要求されます。
The M flag is used by a PCE in a PCRep message to indicate to a PCC whether a mono-layer path or multi-layer path is returned. When the M flag is set (one), a multi-layer path is returned. When the M flag is clear (zero), a mono-layer path is returned.
Mフラグは、PCRepメッセージ内のPCEによって使用され、PCCに単層パスと多層パスのどちらが返されるかを示します。 Mフラグが設定されている場合（1）、マルチレイヤーパスが返されます。 Mフラグがクリア（ゼロ）の場合、単層パスが返されます。
If the I flag is clear (zero), the M flag has no meaning and MUST be ignored.
Iフラグがクリア（ゼロ）の場合、Mフラグは意味がなく、無視する必要があります。
[RFC6457] describes two sub-options for mono-layer path.
[RFC6457]は、単層パスの2つのサブオプションについて説明しています。
o A mono-layer path that is specified by strict hops. The path may include virtual TE links.
o 厳密なホップで指定される単層パス。パスには仮想TEリンクが含まれる場合があります。
o A mono-layer path that includes loose hops that span the lower-layer network.
o 下位層ネットワークにまたがるルーズホップを含む単層パス。
The choice of this sub-option can be specified by the use of the O flag in the Request Parameter (RP) object specified in [RFC5440].
このサブオプションの選択は、[RFC5440]で指定されたリクエストパラメータ（RP）オブジェクトのOフラグを使用して指定できます。
T flag (1 bit): The T flag is used by a PCC in a PCReq message to indicate to a PCE whether triggered signaling is allowed. When the T flag is set (one), triggered signaling is allowed. When it is clear (zero), triggered signaling is not allowed.
Tフラグ（1ビット）：Tフラグは、PCEがPCReqメッセージで使用し、トリガーされたシグナリングが許可されているかどうかをPCEに示します。 Tフラグが設定されている場合（1）、トリガーされたシグナリングが許可されます。クリア（ゼロ）の場合、トリガーされたシグナリングは許可されません。
The T flag is used by a PCE in a PCRep message to indicate to a PCC whether triggered signaling is required to support the returned path. When the T flag is set (one), triggered signaling is required. When it is clear (zero), triggered signaling is not required.
TフラグはPCRepメッセージでPCEによって使用され、返されたパスをサポートするためにトリガーされたシグナリングが必要かどうかをPCCに示します。 Tフラグが設定されている場合（1）、トリガーされたシグナリングが必要です。クリア（ゼロ）の場合、トリガーされたシグナリングは不要です。
Note that triggered signaling is used to support hierarchical [RFC4206] or stitched [RFC5150] LSPs according to the physical attributes of the network layers.
トリガーされたシグナリングは、ネットワーク層の物理属性に応じて、階層型[RFC4206]またはステッチ[RFC5150] LSPをサポートするために使用されることに注意してください。
If the I flag is clear (zero), the T flag has no meaning and MUST be ignored.
Iフラグがクリア（ゼロ）の場合、Tフラグは意味がなく、無視する必要があります。
Note that the I and M flags differ in the following ways. When the I flag is clear (zero), virtual TE links must not be used in path computation. In addition, loose hops that span the lower-layer network must not be specified. Only regular TE links from the same layer may be used.
IフラグとMフラグは次の点で異なることに注意してください。 Iフラグがクリア（ゼロ）の場合、仮想TEリンクをパス計算に使用しないでください。さらに、下位層ネットワークにまたがるルーズホップを指定してはなりません。同じレイヤからの通常のTEリンクのみを使用できます。
o When the I flag is set (one), the M flag is clear (zero), and the T flag is set (one), virtual TE links are allowed in path computation. In addition, when the O flag of the RP object is set, loose hops that span the lower-layer network may be specified. This will initiate lower-layer LSP setup; thus, the inter-layer path is set up even though the path computation result from a PCE to a PCC includes hops from the same layer only.
o Iフラグが設定されている（1）、Mフラグがクリアされている（ゼロ）、およびTフラグが設定されている（1）場合、パスの計算で仮想TEリンクが許可されます。また、RPオブジェクトのOフラグが設定されている場合、下位ネットワークにまたがるルーズホップが指定されることがあります。これにより、下位層のLSPセットアップが開始されます。したがって、PCEからPCCへのパス計算結果に同じレイヤーからのホップのみが含まれている場合でも、レイヤー間パスが設定されます。
o However, when the I flag is set (one), the M flag is clear (zero), and the T flag is clear (zero), since triggered signaling is not allowed, virtual TE links that have not been pre-signaled MUST NOT be used in path computation. In addition, loose hops that span the lower-layer network MUST NOT be specified. Therefore, this is equivalent to the I flag being clear (zero).
o ただし、Iフラグが設定されている（1）、Mフラグがクリア（ゼロ）、およびTフラグがクリア（ゼロ）の場合、トリガーされたシグナリングは許可されないため、事前シグナリングされていない仮想TEリンクはパス計算に使用されます。さらに、下位層ネットワークにまたがるルーズホップを指定してはなりません（MUST NOT）。したがって、これはIフラグがクリア（ゼロ）であることと同じです。
Reserved bits of the INTER-LAYER object sent between a PCC and PCE in the same domain MUST be transmitted as zero and SHOULD be ignored on receipt. A PCE that forwards a path computation request to other PCEs MUST preserve the settings of reserved bits in the PCReq messages it sends and in the PCRep messages it forwards to PCCs.
同じドメイン内のPCCとPCEの間で送信されるINTER-LAYERオブジェクトの予約ビットは、ゼロとして送信する必要があり、受信時に無視する必要があります（SHOULD）。パス計算要求を他のPCEに転送するPCEは、送信するPCReqメッセージとPCCに転送するPCRepメッセージの予約ビットの設定を保持する必要があります。
Note that the flags in the PCRpt message indicate the state of an LSP, whereas the flags in the PCUpd and the PCInitiate messages indicate the intended/desired state as determined by the PCE.
PCRptメッセージ内のフラグはLSPの状態を示し、PCUpdおよびPCInitiateメッセージ内のフラグは、PCEによって決定された意図された/望ましい状態を示すことに注意してください。
The SWITCH-LAYER object is optional on a PCReq message and specifies switching layers in which a path MUST, or MUST NOT, be established. A switching layer is expressed as a switching type and encoding type.
SWITCH-LAYERオブジェクトはPCReqメッセージではオプションであり、パスを確立する必要がある、または確立してはならないスイッチングレイヤーを指定します。スイッチング層は、スイッチングタイプとエンコーディングタイプで表現されます。
When a SWITCH-LAYER object is used on a PCReq, it is interpreted in the context of the INTER-LAYER object on the same message. If no INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER object as though inter-layer path computation had been explicitly disallowed. In such a case, the SWITCH-LAYER object MUST NOT have more than one LSP Encoding Type and Switching Type with the I flag set.
SWeqCH-LAYERオブジェクトがPCReqで使用されると、同じメッセージのINTER-LAYERオブジェクトのコンテキストで解釈されます。 INTER-LAYERオブジェクトが存在しない場合、PCEは、レイヤー間パス計算が明示的に禁止されているかのように、SWITCH-LAYERオブジェクトを処理する必要があります。このような場合、SWITCH-LAYERオブジェクトには、Iフラグが設定された複数のLSPエンコーディングタイプとスイッチングタイプを含めることはできません。
The SWITCH-LAYER object is optional on a PCRep message, where it is used with the NO-PATH object in the case of unsuccessful path computation to indicate the set of constraints that could not be satisfied.
SWepch-LAYERオブジェクトはPCRepメッセージではオプションです。PCRepメッセージでは、パス計算が失敗した場合にNO-PATHオブジェクトとともに使用され、満たされていない制約のセットを示します。
The SWITCH-LAYER object may be used on a PCRpt message consistent with how properties of existing LSPs are reported on that message [RFC8231]. The PCRpt message uses the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. This message can use the <attribute-list> as extended in Section 5 to carry the SWITCH-LAYER object. The SWITCH-LAYER object is not used on a PCUpd or PCInitiate messages.
SWITCH-LAYERオブジェクトは、既存のLSPのプロパティがそのメッセージ[RFC8231]で報告される方法と一致するPCRptメッセージで使用できます。 PCRptメッセージは、[RFC5440]で定義され、さらにPCEP拡張機能によって拡張された<attribute-list>を使用します。このメッセージでは、セクション5で拡張された<attribute-list>を使用して、SWITCH-LAYERオブジェクトを伝達できます。 SWITCH-LAYERオブジェクトは、PCUpdまたはPCInitiateメッセージでは使用されません。
SWITCH-LAYER Object-Class is 37.
SWITCH-LAYERオブジェクトクラスは37です。
Switch-layer Object-Type is 1.
Switch-layer Object-Typeは1です。
The format of the SWITCH-LAYER object body is shown in Figure 2.
SWITCH-LAYERオブジェクト本体のフォーマットを図2に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
// . //
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SWITCH-LAYER Object
図2：SWITCH-LAYERオブジェクト
Each row indicates a switching type and encoding type that must or must not be used for a specified layer(s) in the computed path.
各行は、計算されたパスの指定されたレイヤーで使用する必要がある、または使用できないスイッチングタイプとエンコーディングタイプを示します。
The format is based on [RFC3471] and has equivalent semantics.
形式は[RFC3471]に基づいており、同等のセマンティクスがあります。
LSP Encoding Type (8 bits): see [RFC3471] for a description of parameters.
LSPエンコーディングタイプ（8ビット）：パラメータの説明については、[RFC3471]を参照してください。
Switching Type (8 bits): see [RFC3471] for a description of parameters.
スイッチングタイプ（8ビット）：パラメータの説明については、[RFC3471]を参照してください。
I flag (1 bit): the I flag indicates whether a layer with the specified switching type and encoding type must or must not be used by the computed path. When the I flag is set (one), the computed path MUST traverse a layer with the specified switching type and encoding type. When the I flag is clear (zero), the computed path MUST NOT enter or traverse any layer with the specified switching type and encoding type.
Iフラグ（1ビット）：Iフラグは、指定されたスイッチングタイプとエンコーディングタイプのレイヤーを計算パスで使用する必要があるかどうかを示します。 Iフラグが1に設定されている場合、計算されたパスは、指定されたスイッチングタイプとエンコーディングタイプのレイヤーを通過する必要があります。 Iフラグがクリア（ゼロ）の場合、計算されたパスは、指定されたスイッチングタイプとエンコーディングタイプのレイヤーに進入または通過してはなりません（MUST NOT）。
When a combination of switching type and encoding type is not included in the SWITCH-LAYER object, the computed path MAY traverse a layer with that combination of switching type and encoding type.
スイッチングタイプとエンコーディングタイプの組み合わせがSWITCH-LAYERオブジェクトに含まれていない場合、計算されたパスは、スイッチングタイプとエンコーディングタイプのその組み合わせでレイヤを通過できます。
A PCC may want to specify only a Switching Type and not an LSP Encoding Type. In this case, the LSP Encoding Type is set to zero.
PCCは、LSPエンコーディングタイプではなく、スイッチングタイプのみを指定する場合があります。この場合、LSPエンコーディングタイプはゼロに設定されます。
The REQ-ADAP-CAP object is optional and is used to specify a requested adaptation capability for both ends of the lower-layer LSP. The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE communication, where the PCE that is responsible for computing higher-layer paths acts as a PCC to request a path computation from a PCE that is responsible for computing lower-layer paths.
REQ-ADAP-CAPオブジェクトはオプションであり、下位層LSPの両端に要求された適応機能を指定するために使用されます。 REQ-ADAP-CAPオブジェクトは、PCE間通信のPCReqメッセージで使用されます。この場合、上位層のパスの計算を担当するPCEはPCCとして機能し、下位層の計算を担当するPCEからパス計算を要求します。レイヤーパス。
The REQ-ADAP-CAP object is used in a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the REQ-ADAP-CAP object is used to indicate the set of constraints that could not be satisfied).
REQ-ADAP-CAPオブジェクトは、パス計算が失敗した場合にPCRepメッセージで使用されます（この場合、PCRepメッセージにはNO-PATHオブジェクトも含まれ、REQ-ADAP-CAPオブジェクトは、満たすことができなかった制約）。
The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-layer network to specify a requested adaptation capability for both ends of the LSP. In this case, it MAY be carried without an INTER-LAYER object.
REQ-ADAP-CAPオブジェクトは、LSPの両端に要求された適応機能を指定するために、単層ネットワークのPCReqメッセージで使用される場合があります。この場合、それはINTER-LAYERオブジェクトなしで運ぶことができます。
The applicability of this object to PCRpt and PCUpd messages is the same as for other objects on those messages as described in [RFC8231]. The applicability of this object to the PCInitiate message is the same as for other objects on those messages as described in [RFC8281]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. These messages can use the <attribute-list> as extended in Section 5 to carry the REQ-ADAP-CAP object.
このオブジェクトのPCRptおよびPCUpdメッセージへの適用可能性は、[RFC8231]で説明されているように、これらのメッセージの他のオブジェクトと同じです。このオブジェクトのPCInitiateメッセージへの適用性は、[RFC8281]で説明されているように、これらのメッセージの他のオブジェクトの場合と同じです。これらのメッセージは、[RFC5440]で定義され、さらにPCEP拡張機能によって拡張された<attribute-list>を使用します。これらのメッセージは、セクション5で拡張された<attribute-list>を使用して、REQ-ADAP-CAPオブジェクトを運ぶことができます。
REQ-ADAP-CAP Object-Class is 38.
REQ-ADAP-CAPオブジェクトクラスは38です。
Req-Adap-Cap Object-Type is 1.
Req-Adap-Cap Object-Typeは1です。
The format of the REQ-ADAP-CAP object body is shown in Figure 3.
REQ-ADAP-CAPオブジェクト本体のフォーマットを図3に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The REQ-ADAP-CAP Object
図3：REQ-ADAP-CAPオブジェクト
The format is based on [RFC6001] and has equivalent semantics as the Interface Adjustment Capability Descriptor (IACD) Upper Switching Capability and Lower Switching Capability fields.
このフォーマットは[RFC6001]に基づいており、Interface Adjustment Capability Descriptor（IACD）Upper Switching CapabilityおよびLower Switching Capabilityフィールドと同等のセマンティクスを持っています。
Switching Capability (8 bits): see [RFC4203] for a description of parameters.
スイッチング機能（8ビット）：パラメータの説明については、[RFC4203]を参照してください。
Encoding (8 bits): see [RFC3471] for a description of parameters.
エンコーディング（8ビット）：パラメータの説明については[RFC3471]を参照してください。
A PCC may want to specify a Switching Capability, but not an Encoding. In this case, the Encoding MUST be set to zero.
PCCは、エンコーディングではなくスイッチング機能を指定する必要がある場合があります。この場合、エンコーディングはゼロに設定する必要があります。
This document defines two new metric types for use in the PCEP METRIC object.
このドキュメントでは、PCEP METRICオブジェクトで使用する2つの新しいメトリックタイプを定義します。
IANA has assigned the value 18 to indicate the metric "Number of adaptations on a path".
IANAは値18を割り当て、メトリック「パス上の適応数」を示します。
IANA has assigned the value 19 to indicate the metric "Number of layers on a path".
IANAは値「19」を割り当てて、「パス上のレイヤーの数」というメトリックを示しています。
See Sections 4.1, 4.2, and 4.3 for a description of how these metrics are applied.
これらのメトリックがどのように適用されるかについては、セクション4.1、4.2、および4.3を参照してください。
The SERVER-INDICATION is optional and is used to indicate that path information included in the Explicit Route Object (ERO) is server-layer information, and it specifies the characteristics of the server layer, e.g., the switching capability and encoding of the server-layer path.
SERVER-INDICATIONはオプションであり、明示的ルートオブジェクト（ERO）に含まれるパス情報がサーバー層情報であることを示すために使用され、サーバー層の特性（スイッチング機能やサーバーのエンコードなど）を指定します。レイヤーパス。
The format of the SERVER-INDICATION object body is shown in Figure 4.
SERVER-INDICATIONオブジェクト本体のフォーマットを図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SERVER-INDICATION Object
図4：SERVER-INDICATIONオブジェクト
SERVER-INDICATION Object-Class is 39.
SERVER-INDICATION Object-Classは39です。
Server-indication Object-Type is 1.
サーバー表示オブジェクトタイプは1です。
Switching Capability (8 bits): see [RFC4203] for a description of parameters.
スイッチング機能（8ビット）：パラメータの説明については、[RFC4203]を参照してください。
Encoding (8 bits): see [RFC3471] for a description of parameters.
エンコーディング（8ビット）：パラメータの説明については[RFC3471]を参照してください。
Optional TLVs: Optional TLVs MAY be included within the object to specify more specific server-layer path information (e.g., traffic parameters). Such TLVs will be defined by other documents.
オプションのTLV：オプションのTLVをオブジェクト内に含めて、より具体的なサーバーレイヤーパス情報（トラフィックパラメーターなど）を指定できます。このようなTLVは他のドキュメントで定義されます。
A PCC requests or allows inter-layer path computation in a PCReq message by including the INTER-LAYER object with the I flag set. The INTER-LAYER object indicates whether inter-layer path computation is allowed, which path type is requested, and whether triggered signaling is allowed.
PCCは、Iフラグが設定されたINTER-LAYERオブジェクトを含めることにより、PCReqメッセージ内のレイヤー間パス計算を要求または許可します。 INTER-LAYERオブジェクトは、レイヤー間パス計算が許可されるかどうか、要求されるパスタイプ、およびトリガーされたシグナリングが許可されるかどうかを示します。
The SWITCH-LAYER object, which MUST NOT be present unless the INTER-LAYER object is also present, is optionally used to specify the switching types and encoding types that define layers that must, or must not, be used in the computed path. When the SWITCH-LAYER object is used with the INTER-LAYER object I flag clear (zero), inter-layer path computation is not allowed, but constraints specified in the SWITCH-LAYER object apply. Example usage includes path computation in a single-layer GMPLS network.
INTER-LAYERオブジェクトも存在しない限り、存在してはならないSWITCH-LAYERオブジェクトをオプションで使用して、計算パスで使用する必要がある、または使用してはならないレイヤーを定義するスイッチングタイプとエンコーディングタイプを指定します。 SWITCH-LAYERオブジェクトをINTER-LAYERオブジェクトと共に使用して、フラグをクリア（ゼロ）すると、レイヤー間パスの計算は許可されませんが、SWITCH-LAYERオブジェクトで指定された制約が適用されます。使用例には、単層GMPLSネットワークでのパス計算が含まれます。
The REQ-ADAP-CAP object is optionally used to specify the interface switching capability of both ends of the lower-layer LSP. The REQ-ADAP-CAP object is used in inter-PCE communication, where the PCE that is responsible for computing higher-layer paths makes a request as a PCC to a PCE that is responsible for computing lower-layer paths. Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that is responsible for computing lower-layer paths.
REQ-ADAP-CAPオブジェクトは、下位層LSPの両端のインターフェイススイッチング機能を指定するためにオプションで使用されます。 REQ-ADAP-CAPオブジェクトは、PCE間通信で使用されます。この場合、上位層パスの計算を担当するPCEは、下位層パスの計算を担当するPCEへのPCCとして要求を行います。あるいは、REQ-ADAP-CAPオブジェクトをNMS-VNTMモデルで使用することもできます。この場合、VNTMは、下位層パスの計算を担当するPCEにPCCとして要求を行います。
The METRIC object is optionally used to specify metric types to be optimized or bounded. When metric type 18 is used, it indicates that path computation MUST minimize or bound the number of adaptations on a path. When metric type 19 is used, it indicates that path computation MUST minimize or bound the number of layers to be involved on a path.
METRICオブジェクトは、最適化または制限されるメトリックタイプを指定するためにオプションで使用されます。メトリックタイプ18が使用される場合、それはパス計算がパス上の適応の数を最小化または制限する必要があることを示します。メトリックタイプ19が使用される場合、それはパス計算がパスに関与するレイヤーの数を最小化または制限する必要があることを示します。
Furthermore, in order to allow different Objective Functions (OFs) to be applied within different network layers, multiple OF objects [RFC5541] MAY be present. In such a case, the first OF object specifies an objective function for the higher-layer network, and subsequent OF objects specify objection functions of the subsequent lower-layer networks.
さらに、異なるネットワーク層内で異なる目的関数（OF）を適用できるようにするために、複数のOFオブジェクト[RFC5541]が存在してもよい（MAY）。このような場合、最初のOFオブジェクトは上位層ネットワークの目的関数を指定し、後続のOFオブジェクトは後続の下位層ネットワークの反対関数を指定します。
In the case of successful path computation, the requested PCE replies to the requesting PCC for the inter-layer path computation result in a PCRep message that MAY include the INTER-LAYER object. When the INTER-LAYER object is included in a PCRep message, the I, M, and T flags indicate semantics of the path as described in Section 3.1. Furthermore, when the C flag of the METRIC object in a PCReq is set, the METRIC object MUST be included in the PCRep to provide the computed metric value, as specified in [RFC5440].
パス計算が成功した場合、要求されたPCEは要求元のPCCに応答して、レイヤー間パス計算の結果として、INTERLAYERオブジェクトを含む可能性のあるPCRepメッセージを生成します。 INTER-LAYERオブジェクトがPCRepメッセージに含まれている場合、セクション3.1で説明されているように、I、M、およびTフラグはパスのセマンティクスを示します。さらに、PCReq内のMETRICオブジェクトのCフラグが設定されている場合、[RFC5440]で指定されているように、計算されたメトリック値を提供するために、METRICオブジェクトをPCRepに含める必要があります。
The PCE MAY specify the server-layer path information in the ERO. In this case, the requested PCE replies with a PCRep message that includes at least two sets of ERO information in the path-list: one is for the client-layer path information, and another one is the server-layer path information. When SERVER-INDICATION is included in a PCRep message, it indicates that the path in the ERO is the server-layer path information. The server-layer path specified in the ERO could be loose or strict. On receiving the replied path, the PCC (e.g., NMS and ingress node) can trigger the signaling to set up the LSPs according to the computed paths.
PCEは、EROのサーバー層パス情報を指定してもよい（MAY）。この場合、要求されたPCEは、パスリストに少なくとも2セットのERO情報を含むPCRepメッセージで応答します。1つはクライアント層のパス情報用で、もう1つはサーバー層のパス情報です。 SERVER-INDICATIONがPCRepメッセージに含まれている場合、EROのパスがサーバー層のパス情報であることを示しています。 EROで指定されたサーバー層のパスは、緩いか、厳密である可能性があります。応答されたパスを受信すると、PCC（NMSや入力ノードなど）はシグナリングをトリガーして、計算されたパスに従ってLSPをセットアップできます。
In the case of unsuccessful path computation, the PCRep message also contains a NO-PATH object, and the SWITCH-TYPE object and/or REQ-ADAP-CAP MAY be used to indicate the set of constraints that could not be satisfied.
パス計算が失敗した場合、PCRepメッセージにはNO-PATHオブジェクトも含まれており、SWITCH-TYPEオブジェクトやREQ-ADAP-CAPを使用して、満たされていない制約のセットを示すことができます（MAY）。
Processing for stateful PCEs is described in [RFC8231]. That document defines the PCRpt message to allow a PCC to report to a PCE that an LSP already exists in the network and to delegate control of that LSP to the PCE.
ステートフルPCEの処理については、[RFC8231]で説明されています。そのドキュメントでは、PCCがLSPがネットワークにすでに存在することをPCEに報告し、そのLSPの制御をPCEに委任できるようにするPCRptメッセージを定義しています。
When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCRpt to describe an LSP that is delegated to the PCE so that the PCE may process the LSP.
LSPがマルチレイヤLSP（または特定の適応が存在するモノレイヤLSP）である場合、このドキュメントで定義されているメッセージオブジェクトは、PCEに委任されるLSPを記述するためにPCRptで使用され、PCEがLSPを処理します。
Furthermore, [RFC8231] defines the PCUpd message to allow a PCE to modify an LSP that has been delegated to it. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCUpd to describe the new attributes of the modified LSP.
さらに、[RFC8231]はPCUpdメッセージを定義して、PCEが委任されたLSPを変更できるようにします。 LSPがマルチレイヤLSP（または特定の適応が存在するモノレイヤLSP）である場合、このドキュメントで定義されているメッセージオブジェクトは、変更されたLSPの新しい属性を記述するためにPCUpdで使用されます。
Processing for PCE-initiated LSPs is described in [RFC8281]. That document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCInitiate to describe the attributes of the new LSP.
PCEによって開始されたLSPの処理は、[RFC8281]で説明されています。そのドキュメントは、PCEがPCCに新しいLSPのセットアップを要求するために使用するPCInitiateメッセージを定義します。 LSPがマルチレイヤーLSP（または特定の適応が存在するモノレイヤーLSP）である場合、このドキュメントで定義されているメッセージオブジェクトはPCInitiateで使用され、新しいLSPの属性を記述します。
The new metric types defined in this document can also be used with the stateful PCE extensions. The format of PCEP messages described in [RFC8231] and [RFC8281] uses <attribute-list> (which is extended in Section 5 for the purpose of including the new metrics).
このドキュメントで定義されている新しいメトリックタイプは、ステートフルPCE拡張機能でも使用できます。 [RFC8231]と[RFC8281]で説明されているPCEPメッセージのフォーマットは、<attribute-list>を使用します（これは、新しいメトリックを含めるためにセクション5で拡張されています）。
The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Section 5 to also enable the use of inter-layer parameters during passive stateful operations, using the LSP object.
ステートフルPCE実装は、セクション5で定義されているPCReqおよびPCRepメッセージの拡張を使用して、LSPオブジェクトを使用するパッシブステートフル操作中にレイヤー間パラメーターを使用できるようにすることもできます（MAY）。
Message formats in this section, as those in [RFC5440], are presented using Routing Backus-Naur Format (RBNF) as specified in [RFC5511].
このセクションのメッセージ形式は、[RFC5440]のメッセージ形式と同様に、[RFC5511]で指定されているRouting Backus-Naur Format（RBNF）を使用して表示されます。
The format of the PCReq message is updated as shown in Figure 5.
PCReqメッセージのフォーマットは、図5に示すように更新されます。
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<of-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<INTER-LAYER> [<SWITCH-LAYER>]]
[<REQ-ADAP-CAP>]
where:
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 5: The Updated PCReq Message
図5：更新されたPCReqメッセージ
The format of the PCRep message is updated as shown in Figure 6.
PCRepメッセージのフォーマットは、図6に示すように更新されます。
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 6: The Updated PCRep Message
図6：更新されたPCRepメッセージ
Implementations of this specification should provide a mechanism to configure any optional features (such as whether a PCE supports inter-layer computation and which metrics are supported).
この仕様の実装は、オプションの機能（PCEがレイヤー間計算をサポートするかどうか、サポートされるメトリックなど）を構成するメカニズムを提供する必要があります。
A Management Information Base (MIB) module for modeling PCEP is described in [RFC7420]. Systems that already use a MIB module to manage their PCEP implementations might want to augment that module to provide controls and indicators for support of inter-layer features defined in this document and to add counters of messages sent and received containing the objects defined here.
PCEPをモデリングするための管理情報ベース（MIB）モジュールは、[RFC7420]で説明されています。 PCEP実装を管理するためにすでにMIBモジュールを使用しているシステムは、このモジュールを拡張して、このドキュメントで定義されている層間機能をサポートするためのコントロールとインジケーターを提供し、ここで定義されているオブジェクトを含む送受信されたメッセージのカウンターを追加します。
However, the preferred mechanism for configuration is through a YANG model. Work has started on a YANG model for PCEP [PCEP-YANG], and this could be enhanced as described for the MIB module, above.
ただし、推奨される構成メカニズムは、YANGモデルによるものです。 PCEPのYANGモデル[PCEP-YANG]の作業が開始されました。これは、上記のMIBモジュールで説明されているように拡張できます。
Additional policy configuration might be provided to allow a PCE to discriminate between the computation services offered to different PCCs.
PCEが異なるPCCに提供される計算サービスを区別できるように、追加のポリシー構成が提供される場合があります。
A set of monitoring tools for the PCE-based architecture are provided in [RFC5886]. Systems implementing this specification and PCE monitoring should consider defining extensions to the mechanisms defined in [RFC5886] to help monitor inter-layer path computation requests.
PCEベースのアーキテクチャ用の一連の監視ツールが[RFC5886]で提供されています。この仕様とPCE監視を実装するシステムは、[RFC5886]で定義されたメカニズムの拡張を定義して、レイヤー間パス計算要求の監視を支援することを検討する必要があります。
IANA maintains a registry called "Path Computation Element Protocol (PCEP) Numbers". Per this document, IANA has carried out actions on subregistries of that registry.
IANAは、「パス計算要素プロトコル（PCEP）番号」と呼ばれるレジストリを維持しています。このドキュメントに従って、IANAはそのレジストリのサブレジストリに対してアクションを実行しました。
IANA has made the following assignments in the "PCEP Objects" subregistry.
IANAは、「PCEPオブジェクト」サブレジストリで次の割り当てを行いました。
Object-Class Value | Name | Object-Type | Reference
-------------------+-------+-----------------------+-----------
INTER-LAYER | 36 | 0: Reserved | RFC 8282
| | 1: Inter-layer |
| | 2-15: Unassigned |
| | |
SWITCH-LAYER | 37 | 0: Reserved | RFC 8282
| | 1: Switch-layer |
| | 2-15: Unassigned |
| | |
REQ-ADAP-CAP | 38 | 0: Reserved | RFC 8282
| | 1: Req-Adap-Cap |
| | 2-15: Unassigned |
| | |
SERVER-INDICATION | 39 | 0: Reserved | RFC 8282
| | 1: Server-indication |
Figure 7: New PCEP Objects
図7：新しいPCEPオブジェクト
IANA has created a new subregistry to manage the Flag field of the INTER-LAYER object called the "Inter-Layer Object Path Property Bits" registry.
IANAは、「レイヤー間オブジェクトパスプロパティビット」レジストリと呼ばれるINTER-LAYERオブジェクトのフラグフィールドを管理するための新しいサブレジストリを作成しました。
New bit numbers may be allocated only by "IETF Review" [RFC8126]. Each bit should be tracked with the following qualities:
新しいビット番号は、「IETFレビュー」[RFC8126]によってのみ割り当てられます。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit up to a maximum of bit 31)
o ビット番号（ビット0を最上位ビットとしてカウントし、ビット31の最大値まで）
o Capability Description
o 機能の説明
o Defining RFC
o RFCの定義
IANA has populated the registry as follows:
IANAは次のようにレジストリにデータを入力しました。
Bit | Flag | Multi-Layer Path Property | Reference
----+------+-------------------------------+------------
0-28| | Unassigned |
29 | T | Triggered Signaling Allowed | RFC 8282
30 | M | Multi-Layer Requested | RFC 8282
31 | I | Inter-Layer Allowed | RFC 8282
Figure 8: New Registry for INTER-LAYER Object Flags
図8：INTER-LAYERオブジェクトフラグの新しいレジストリ
Two new metric types are defined in this document for the METRIC object (specified in [RFC5440]). IANA has made the following allocations from the "Metric Object T Field" registry.
このドキュメントでは、METRICオブジェクト（[RFC5440]で指定）に対して2つの新しいメトリックタイプが定義されています。 IANAは、「Metric Object T Field」レジストリから次の割り当てを行いました。
Value | Description | Reference
------+---------------------------------+------------
18 | Number of adaptations on a path | RFC 8282
19 | Number of layers on a path | RFC 8282
Figure 9: New Metric Types
図9：新しいメトリックタイプ
IANA has updated the registry to show the registration procedure of "IETF Review" as already documented in [RFC5440].
[RFC5440]ですでに文書化されているように、IANAはレジストリを更新して「IETFレビュー」の登録手順を示しています。
Inter-layer traffic engineering with PCE may raise new security issues when PCE-PCE communication is done between different layer networks for inter-layer path computation. Security issues may also exist when a single PCE is granted full visibility of TE information that applies to multiple layers.
PCEを使用したレイヤー間トラフィックエンジニアリングでは、レイヤー間パス計算のために異なるレイヤーネットワーク間でPCE-PCE通信が行われると、新しいセキュリティ問題が発生する可能性があります。複数のレイヤーに適用されるTE情報の完全な可視性が単一のPCEに付与されている場合にも、セキュリティの問題が存在する可能性があります。
The Path-Key-based mechanism defined in [RFC5520] MAY be applied to address the topology confidentiality between different layers.
[RFC5520]で定義されているパスキーベースのメカニズムを適用して、異なるレイヤ間のトポロジの機密性に対処できます。
[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>。
[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>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487 / RFC3945、2004年10月、<https://www.rfc-editor.org/info/ rfc3945>。
[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>。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4206] Kompella、K。およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、DOI 10.17487 / RFC4206、2005年10月、<https ：//www.rfc-editor.org/info/rfc4206>。
[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、March 2009、<https://www.rfc-editor.org/info/rfc5440>
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<https://www.rfc-editor.org/info/rfc5520>。
[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>。
[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>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <http://www.rfc-editor.org/info/rfc20>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（PCEP）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<http://www.rfc-editor.org/info/rfc20>。
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
[PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V.、j。 jefftant@gmail.com、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、draft-ietf-pce-pcep-yang-05、2017年6月。
[RFC4655] Farrel, A., Vasseur, J., 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。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, <https://www.rfc-editor.org/info/rfc5150>.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、JP。、およびA. Farrel、「Generalized Multiprotocol Label Switching Traffic Engineering（GMPLS TE）によるラベルスイッチドパスステッチング」、RFC 5150、DOI 10.17487 / RFC5150、2月2008、<https://www.rfc-editor.org/info/rfc5150>。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, DOI 10.17487/RFC5212, July 2008, <https://www.rfc-editor.org/info/rfc5212>.
[RFC5212]塩本K.、パパディミトリウ、D。、ルルー、JL。、ヴィグールー、M。、およびD.ブルガード、「GMPLSベースのマルチリージョンおよびマルチレイヤーネットワーク（MRN / MLN）の要件」、 RFC 5212、DOI 10.17487 / RFC5212、2008年7月、<https://www.rfc-editor.org/info/rfc5212>。
[RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, DOI 10.17487/RFC5339, September 2008, <https://www.rfc-editor.org/info/rfc5339>.
[RFC5339] Le Roux、JL。、Ed。およびD. Papadimitriou、編、「マルチレイヤーおよびマルチリージョンネットワーク（MLN / MRN）に対する既存のGMPLSプロトコルの評価」、RFC 5339、DOI 10.17487 / RFC5339、2008年9月、<https：//www.rfc- editor.org/info/rfc5339>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。 rfc-editor.org/info/rfc5511>。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541] Le Roux、JL。、Vasseur、JP。、and Y. Lee、 "Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）"、RFC 5541、DOI 10.17487 / RFC5541、June 2009、<https： //www.rfc-editor.org/info/rfc5541>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖E.、武田T.、ルルーJL、およびA.ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、DOI 10.17487 / RFC5623、2009年9月、<https://www.rfc-editor.org/info/rfc5623>。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, <https://www.rfc-editor.org/info/rfc5886>.
[RFC5886] Vasseur、JP。、Ed。、Le Roux、JL。、and Y. Ikejiri、 "A Set Monitoring Tools for Path Computation Element（PCE）-Based Architecture"、RFC 5886、DOI 10.17487 / RFC5886、June 2010 、<https://www.rfc-editor.org/info/rfc5886>。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, <https://www.rfc-editor.org/info/rfc6001>.
[RFC6001] Papadimitriou、D.、Vigoureux、M.、Siomoto、K.、Brungard、D。、およびJL。 Le Roux、「Multilayer- Multi-Region Networks（MLN / MRN）用のGeneralized MPLS（GMPLS）Protocol Extensions」、RFC 6001、DOI 10.17487 / RFC6001、2010年10月、<https://www.rfc-editor.org / info / rfc6001>。
[RFC6457] Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", RFC 6457, DOI 10.17487/RFC6457, December 2011, <https://www.rfc-editor.org/info/rfc6457>.
[RFC6457]武田、T。、エド。およびA. Farrel、「層間トラフィックエンジニアリングのためのPCC-PCE通信およびPCE検出の要件」、RFC 6457、DOI 10.17487 / RFC6457、2011年12月、<https://www.rfc-editor.org/info/rfc6457> 。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.
[RFC7926] Farrel、A.、Ed。、Drake、J.、Bitar、N.、Swallow、G.、Ceccarelli、D。、およびX. Zhang、「相互接続されたトラフィックエンジニアリングネットワーク間の情報交換のための問題ステートメントとアーキテクチャ"、BCP 206、RFC 7926、DOI 10.17487 / RFC7926、2016年7月、<https://www.rfc-editor.org/info/rfc7926>。
Acknowledgments
謝辞
The authors would like to thank Cyril Margaria for his valuable comments. Helpful comments and suggested text were offered by Dhruv Dhody, who also fixed the RBNF. Jonathan Hardwick provided a helpful review as document shepherd.
著者は、Cyril Margaria氏の貴重なコメントに感謝します。役立つコメントと提案されたテキストは、同じくRBNFを修正したDhruv Dhodyによって提供されました。 Jonathan Hardwickがドキュメントシェパードとして役立つレビューを提供しました。
Contributors
貢献者
Jean-Louis Le Roux France Telecom R&D Av Pierre Marzin Lannion 22300 France
Jean-Louis Le Roux France Telecom R＆D Av Pierre Marzin Lannion 22300 France
Email: jeanlouis.leroux@orange.com
Authors' Addresses
著者のアドレス
Eiji Oki Kyoto University Yoshida-honmachi, Sakyo-ku, Kyoto Japan
えいじ おき きょと うにゔぇｒしｔｙ よしだーほんまち、 さきょーく、 きょと じゃぱん
Email: oki@i.kyoto-u.ac.jp
Tomonori Takeda NTT 3-9-11 Midori-cho Musashino-shi, Tokyo Japan
とものり たけだ んっｔ ３ー９ー１１ みどりーちょ むさしのーし、 ときょ じゃぱん
Email: tomonori.takeda@ntt.com
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
Email: afarrel@juniper.net
Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District, Shenzhen 518129 China
fa too Zhang hu Aはテクノロジーズ株式会社です。F3-5-br＆Dセンター、hu Aはベース禁止日、長いギャング地区、Sは非常にリアルな518129中国です
Phone: +86-755-28972912
Email: zhangfatai@huawei.com