[要約] RFC 7025は、PCE（Path Computation Element）のGMPLS（Generalized Multiprotocol Label Switching）アプリケーションの要件を定義しています。このRFCの目的は、PCEを使用してGMPLSネットワークの経路計算を効率化し、ネットワークの制御と管理を向上させることです。
Internet Engineering Task Force (IETF) T. Otani
Request for Comments: 7025 K. Ogaki
Category: Informational KDDI
ISSN: 2070-1721 D. Caviglia
Ericsson
F. Zhang
Huawei Technologies
C. Margaria
Coriant R&D GmbH
September 2013
Requirements for GMPLS Applications of PCE
PCEのGMPLSアプリケーションの要件
Abstract
概要
The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.
PCE（Path Computation Element）WGの最初の取り組みは、主にMPLSに焦点を当てました。次のステップとして、このドキュメントではPCEのGMPLSアプリケーションの機能要件について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7025.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7025で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. GMPLS Applications of PCE . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation in GMPLS Networks . . . . . . . . . . . . 3
2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . . 5
2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 5
3. Requirements for GMPLS Applications of PCE . . . . . . . . . . 6
3.1. Requirements on Path Computation Request . . . . . . . . . 6
3.2. Requirements on Path Computation Reply . . . . . . . . . . 7
3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
The initial effort of the PCE (Path Computation Element) WG focused mainly on solving the path computation problem within a domain or over different domains in MPLS networks. As with MPLS, service providers (SPs) have also come up with requirements for path computation in GMPLS-controlled networks [RFC3945], such as those based on Wavelength Division Multiplexing (WDM), Time Division Multiplexing (TDM), or Ethernet.
PCE（Path Computation Element）WGの初期の取り組みは、主に、ドメイン内またはMPLSネットワークのさまざまなドメインにわたるパス計算問題の解決に焦点を当てていました。 MPLSと同様に、サービスプロバイダー（SP）も、波長分割多重（WDM）、時分割多重（TDM）、またはイーサネットに基づくものなど、GMPLS制御ネットワーク[RFC3945]でのパス計算の要件を考え出しました。
[RFC4655] and [RFC4657] discuss the framework and requirements for PCE on both packet MPLS networks and GMPLS-controlled networks. This document complements those RFCs by providing considerations of GMPLS applications in the intradomain and interdomain networking environments and indicating a set of requirements for the extended definition of PCE-related protocols.
[RFC4655]と[RFC4657]は、パケットMPLSネットワークとGMPLS制御ネットワークの両方でのPCEのフレームワークと要件について説明しています。このドキュメントは、ドメイン内およびドメイン間ネットワーク環境でのGMPLSアプリケーションの考慮事項を提供し、PCE関連プロトコルの拡張定義の一連の要件を示すことにより、これらのRFCを補完します。
Note that the requirements for interlayer and inter-area traffic engineering (TE) described in [RFC6457] and [RFC4927] are outside of the scope of this document.
[RFC6457]および[RFC4927]で説明されている中間層およびエリア間トラフィックエンジニアリング（TE）の要件は、このドキュメントの範囲外であることに注意してください。
Constrained Shortest Path First (CSPF) computation within a domain or over domains for signaling GMPLS Label Switched Paths (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216], because the additional constraints, e.g., interface switching capability, link encoding, link protection capability, Shared Risk Link Group (SRLG) [RFC4202], and so forth, need to be considered to establish GMPLS LSPs. The GMPLS signaling protocol [RFC3473] is designed taking into account bidirectionality, switching type, encoding type, and protection attributes of the TE links spanned by the path, as well as LSP encoding and switching type of the endpoints, appropriately.
GMPLSラベルスイッチドパス（LSP）をシグナリングするためのドメイン内またはドメイン全体のConstrained Shortest Path First（CSPF）計算は、通常、MPLS TE LSP [RFC4216]よりも厳格です。 、リンク保護機能、共有リスクリンクグループ（SRLG）[RFC4202]などは、GMPLS LSPを確立するために検討する必要があります。 GMPLSシグナリングプロトコル[RFC3473]は、パスにまたがるTEリンクの双方向性、スイッチングタイプ、エンコーディングタイプ、保護属性、およびエンドポイントのLSPエンコーディングとスイッチングタイプを適切に考慮して設計されています。
This document provides requirements for GMPLS applications of PCE in support of GMPLS path computation, included are requirements for both intradomain and interdomain environments.
このドキュメントでは、GMPLSパス計算をサポートするPCEのGMPLSアプリケーションの要件について説明します。これには、ドメイン内環境とドメイン間環境の両方の要件が含まれます。
Figure 1 depicts a model GMPLS network, consisting of an ingress link, a transit link, as well as an egress link. We will use this model to investigate consistent guidelines for GMPLS path computation. Each link at each interface has its own switching capability, encoding type, and bandwidth.
図1は、入力リンク、中継リンク、および出力リンクで構成されるモデルGMPLSネットワークを示しています。このモデルを使用して、GMPLSパス計算の一貫したガイドラインを調査します。各インターフェイスの各リンクには、独自のスイッチング機能、エンコーディングタイプ、および帯域幅があります。
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 1: Path Computation in GMPLS Networks
図1：GMPLSネットワークのパス計算
For the simplicity in consideration, the following basic assumptions are made when the LSP is created.
単純化を考慮して、LSPの作成時に次の基本的な仮定が行われます。
(1) Switching capabilities of outgoing links from the ingress and egress nodes (link1-2 and link4-3 in Figure 1) are consistent with each other.
（1）入力ノードと出力ノード（図1のlink1-2およびlink4-3）からの発信リンクのスイッチング機能は、互いに一貫しています。
(2) Switching capabilities of all transit links, including incoming links to the ingress and egress nodes (link2-1 and link3-4) are consistent with switching type of an LSP to be created.
（2）入力ノードと出力ノード（link2-1とlink3-4）への着信リンクを含むすべてのトランジットリンクのスイッチング機能は、作成されるLSPのスイッチングタイプと一致しています。
(3) Encoding types of all transit links are consistent with the encoding type of an LSP to be created.
（3）すべてのトランジットリンクのエンコーディングタイプは、作成されるLSPのエンコーディングタイプと一致しています。
GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are usually responsible for transmitting data for the client layer. These GMPLS-controlled networks can provide different types of connections for customer services based on different service bandwidth requests.
GMPLSで制御されるネットワーク（GMPLSベースのTDMネットワークなど）は、通常、クライアント層のデータの送信を担当します。これらのGMPLS制御ネットワークは、さまざまなサービス帯域幅要求に基づいて、カスタマーサービスにさまざまなタイプの接続を提供できます。
The applications and the corresponding additional requirements for applying PCE to GMPLS-based TDM networks are described in this section. In order to simplify the description, this document only discusses the scenario in Synchronous Digital Hierarchy (SDH) networks as an example (see Figure 2). The scenarios in Synchronous Optical Network (SONET) or Optical Transport Network (OTN) are similar.
このセクションでは、PCEをGMPLSベースのTDMネットワークに適用するためのアプリケーションと対応する追加要件について説明します。説明を簡単にするため、このドキュメントでは、例として同期デジタル階層（SDH）ネットワークのシナリオのみを説明します（図2を参照）。 Synchronous Optical Network（SONET）またはOptical Transport Network（OTN）のシナリオは似ています。
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
Figure 2: A Simple TDM (SDH) Network
図2：シンプルなTDM（SDH）ネットワーク
Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, N4, and N5 are all SDH switches; A1 and A2 are client devices (e.g., Ethernet switches). Assume that one Ethernet service with 100 Mbit/s bandwidth is required from A1 to A2 over this network. The client Ethernet service could be provided by a Virtual Container 4 (VC-4) container from N1 to N4; it could also be provided by three concatenated VC-3s (contiguous or virtual concatenation) from N1 to N4.
図2は、単純なTDM（SDH）ネットワークトポロジを示しています。N1、N2、N3、N4、およびN5はすべてSDHスイッチです。 A1とA2はクライアントデバイス（イーサネットスイッチなど）です。このネットワーク上で、100 Mbit / s帯域幅の1つのイーサネットサービスがA1からA2に必要であると想定します。クライアントイーサネットサービスは、N1からN4までのVirtual Container 4（VC-4）コンテナーによって提供できます。 N1からN4までの3つの連結されたVC-3（連続または仮想連結）によって提供することもできます。
In this scenario, when the ingress node (e.g., N1) receives a client service transmitting request, the type of containers (one VC-4 or three concatenated VC-3s) could be determined by the PCC (Path Computation Client), e.g., N1 or Network Management System (NMS). However, it could also be determined automatically by the PCE based on policy [RFC5394]. If it is determined by the PCC, then the PCC should be capable of specifying the ingress node and egress node, signal type, the type of the concatenation, and the number of the concatenation in a PCReq (Path Computation Request) message. The PCE should consider those parameters during path computation. The route information (co-routing or diverse routing) should be specified in a PCRep (Path Computation Reply) message if path computation is performed successfully.
このシナリオでは、入口ノード（たとえば、N1）がクライアントサービス送信要求を受信すると、コンテナのタイプ（1つのVC-4または3つの連結されたVC-3）がPCC（パス計算クライアント）によって決定されます。 N1またはネットワーク管理システム（NMS）。ただし、ポリシー[RFC5394]に基づいてPCEが自動的に決定することもできます。 PCCによって決定される場合、PCCはPCReq（Path Computation Request）メッセージ内の入力ノードと出力ノード、信号タイプ、連結のタイプ、および連結の数を指定できる必要があります。 PCEは、パスの計算中にこれらのパラメーターを考慮する必要があります。パス計算が正常に実行された場合、ルート情報（コルーティングまたはダイバーシティルーティング）をPCRep（パス計算応答）メッセージで指定する必要があります。
As described above, the PCC should be capable of specifying TE attributes defined in the next section, and the PCE should compute a path accordingly.
上記のように、PCCは次のセクションで定義されるTE属性を指定できる必要があり、PCEはそれに応じてパスを計算する必要があります。
Where a GMPLS network consists of interdomain (e.g., inter-AS or inter-area) GMPLS-controlled networks, requirements on the path computation follow [RFC5376] and [RFC4726].
GMPLSネットワークがドメイン間（AS間やエリア間など）のGMPLS制御ネットワークで構成される場合、パス計算の要件は[RFC5376]および[RFC4726]に従います。
GMPLS supports unnumbered interface IDs as defined in [RFC3477]; this means that the endpoints of the path may be unnumbered. It should also be possible to request a path consisting of the mixture of numbered links and unnumbered links, or a P2MP (Point-to-Multipoint) path with different types of endpoints. Therefore, the PCC should be capable of indicating the unnumbered interface ID of the endpoints in the PCReq message.
GMPLSは、[RFC3477]で定義されている番号なしのインターフェイスIDをサポートしています。これは、パスの端点が番号付けされていない可能性があることを意味します。番号付きリンクと番号なしリンクが混在するパス、またはエンドポイントの種類が異なるP2MP（ポイントツーマルチポイント）パスを要求することも可能です。したがって、PCCは、PCReqメッセージでエンドポイントの番号なしインターフェイスIDを示すことができる必要があります。
Per [RFC6387], GMPLS signaling can be used for setting up an asymmetric bandwidth bidirectional LSP. If a PCE is responsible for path computation, it should be capable of computing a path for the bidirectional LSP with asymmetric bandwidth. This means that the PCC should be able to indicate the asymmetric bandwidth requirements in forward and reverse directions in the PCReq message.
[RFC6387]に従い、GMPLSシグナリングは非対称帯域幅双方向LSPのセットアップに使用できます。 PCEがパス計算を担当する場合は、非対称帯域幅の双方向LSPのパスを計算できる必要があります。これは、PCCがPCReqメッセージで順方向と逆方向の非対称帯域幅要件を示すことができる必要があることを意味します。
As for path computation in GMPLS-controlled networks as discussed in Section 2, the PCE should appropriately consider the GMPLS TE attributes listed below once a PCC or another PCE requests a path computation. The path calculation request message from the PCC or the PCE must contain the information specifying appropriate attributes. According to [RFC5440], [PCE-WSON-REQ], and RSVP procedures such as explicit label control (ELC), the additional attributes introduced are as follows:
セクション2で説明したGMPLS制御ネットワークのパス計算については、PCCまたは別のPCEがパス計算を要求すると、PCEは以下にリストされているGMPLS TE属性を適切に考慮する必要があります。 PCCまたはPCEからのパス計算要求メッセージには、適切な属性を指定する情報が含まれている必要があります。 [RFC5440]、[PCE-WSON-REQ]、および明示的ラベル制御（ELC）などのRSVP手順に従って、導入された追加の属性は次のとおりです。
(1) Switching capability/type: as defined in [RFC3471], [RFC4203], and all current and future values.
（1）スイッチング機能/タイプ：[RFC3471]、[RFC4203]、および現在および将来のすべての値で定義されています。
(2) Encoding type: as defined in [RFC3471], [RFC4203], and all current and future values.
（2）エンコードタイプ：[RFC3471]、[RFC4203]、および現在および将来のすべての値で定義されています。
(3) Signal type: as defined in [RFC4606] and all current and future values.
（3）信号タイプ：[RFC4606]で定義されているとおり、現在および将来のすべての値。
(4) Concatenation type: In SDH/SONET and OTN, two kinds of concatenation modes are defined: contiguous concatenation, which requires co-routing for each member signal and that all the interfaces along the path support this capability, and virtual concatenation, which allows diverse routing for member signals and requires that only the ingress and egress interfaces support this capability. Note that for the virtual concatenation, it may also specify co-routing or diverse routing. See [RFC4606] and [RFC4328] about concatenation information.
（4）連結タイプ：SDH / SONETおよびOTNでは、2種類の連結モードが定義されています。連続した連結は、各メンバー信号のコルーティングを必要とし、パスに沿ったすべてのインターフェイスがこの機能をサポートします。仮想連結は、メンバー信号の多様なルーティングを可能にし、入力および出力インターフェイスのみがこの機能をサポートすることを要求します。仮想連結の場合、コルーティングまたは多様なルーティングを指定することもあります。連結情報については[RFC4606]と[RFC4328]を見てください。
(5) Concatenation number: Indicates the number of signals that are requested to be contiguously or virtually concatenated. Also see [RFC4606] and [RFC4328].
（5）連結数：連続的または仮想的に連結するように要求されたシグナルの数を示します。 [RFC4606]と[RFC4328]も参照してください。
(6) Technology-specific label(s): as defined in [RFC4606], [RFC6060], [RFC6002], or [RFC6205].
（6）テクノロジー固有のラベル：[RFC4606]、[RFC6060]、[RFC6002]、または[RFC6205]で定義されています。
(7) End-to-End (E2E) path protection type: as defined in [RFC4872], e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting, etc.
（7）End-to-End（E2E）UPSR保護タイプ：[RFC4872]で定義されているとおり（1 + 1保護、1：1保護、（事前に計画された）再ルーティングなど）
(8) Administrative group: as defined in [RFC3630].
（8）管理グループ：[RFC3630]で定義されています。
(9) Link protection type: as defined in [RFC4203].
（9）リンク保護タイプ：[RFC4203]で定義されています。
(10) Support for unnumbered interfaces: as defined in [RFC3477].
（10）アンナンバードインターフェイスのサポート：[RFC3477]で定義されています。
(11) Support for asymmetric bandwidth requests: as defined in [RFC6387].
（11）非対称帯域幅要求のサポート：[RFC6387]で定義されています。
(12) Support for explicit label control during the path computation.
（12）パス計算中の明示的なラベル制御のサポート。
(13) Support of label restrictions in the requests/responses, similar to RSVP-TE ERO (Explicit Route Object) and XRO (Exclude Route Object), as defined in [RFC3473] and [RFC4874].
（13）[RFC3473]および[RFC4874]で定義されている、RSVP-TE ERO（明示的ルートオブジェクト）およびXRO（除外ルートオブジェクト）と同様の、要求/応答でのラベル制限のサポート。
As described above, a PCE should compute the path that satisfies the constraints specified in the PCReq message. Then, the PCE should send a PCRep message, including the computation result, to the PCC. For a Path Computation Reply message (PCRep) in GMPLS networks, there are some additional requirements. The PCEP (PCE communication protocol) PCRep message must be extended to meet the following requirements.
上記のように、PCEはPCReqメッセージで指定された制約を満たすパスを計算する必要があります。次に、PCEは、計算結果を含むPCRepメッセージをPCCに送信する必要があります。 GMPLSネットワークのパス計算応答メッセージ（PCRep）の場合、いくつかの追加要件があります。 PCEP（PCE通信プロトコル）PCRepメッセージは、以下の要件を満たすように拡張する必要があります。
(1) Path computation with concatenation
（1）連結によるパス計算
In the case of path computation involving concatenation, when a PCE receives the PCReq message specifying the concatenation constraints described in Section 3.1, the PCE should compute a path accordingly.
連結を含むパス計算の場合、PCEがセクション3.1で説明した連結制約を指定するPCReqメッセージを受信すると、PCEはそれに応じてパスを計算する必要があります。
For path computation involving contiguous concatenation, a single route is required, and all the interfaces along the route should support contiguous concatenation capability. Therefore, the PCE should compute a path based on the contiguous concatenation capability of each interface and only one ERO that should carry the route information for the response.
連続した連結を含むパス計算の場合、単一のルートが必要であり、ルートに沿ったすべてのインターフェイスが連続した連結機能をサポートする必要があります。したがって、PCEは、各インターフェイスの連続した連結機能と、応答のルート情報を伝送する必要がある1つのEROのみに基づいてパスを計算する必要があります。
For path computation involving virtual concatenation, only the ingress/egress interfaces need to support virtual concatenation capability, and there may be diverse routes for the different member signals. Therefore, multiple EROs may be needed for the response. Each ERO may represent the route of one or multiple member signals. When one ERO represents multiple member signals, the number must be specified.
仮想連結を含むパス計算では、入力/出力インターフェイスのみが仮想連結機能をサポートする必要があり、異なるメンバー信号にはさまざまなルートが存在する場合があります。したがって、応答には複数のEROが必要になる場合があります。各EROは、1つまたは複数のメンバー信号のルートを表す場合があります。 1つのEROが複数のメンバーシグナルを表す場合、番号を指定する必要があります。
(2) Label constraint
（2）ラベル制約
In the case that a PCC does not specify the exact label(s) when requesting a label-restricted path and the PCE is capable of performing the route computation and label assignment computation procedure, the PCE needs to be able to specify the label of the path in a PCRep message.
PCCがラベル制限パスを要求するときに正確なラベルを指定しておらず、PCEがルート計算およびラベル割り当て計算手順を実行できる場合、PCEはのラベルを指定できる必要があります。 PCRepメッセージ内のパス。
Wavelength restriction is a typical case of label restriction. More generally, label switching and selection constraints may apply in GMPLS-controlled networks, and a PCC may request a PCE to take label constraint into account and return an ERO containing the label or set of labels that fulfill the PCC request.
波長制限は、ラベル制限の典型的なケースです。より一般的には、ラベルスイッチングと選択の制約がGMPLS制御ネットワークに適用される場合があり、PCCはPCEにラベルの制約を考慮に入れて、PCC要求を満たすラベルまたはラベルのセットを含むEROを返すように要求できます。
(3) Roles of the routes
（3）ルートの役割
When a PCC specifies the protection type of an LSP, the PCE should compute the working route and the corresponding protection route(s). Therefore, the PCRep should allow to distinguish the working (nominal) and the protection routes. According to these routes, the RSVP-TE procedure appropriately creates both the working and the protection LSPs, for example, with the ASSOCIATION object [RFC6689].
PCCがLSPの保護タイプを指定する場合、PCEは現用ルートと対応する保護ルートを計算する必要があります。したがって、PCRepは、作業（公称）ルートと保護ルートを区別できるようにする必要があります。これらのルートに従って、RSVP-TE手順は、たとえば、ASSOCIATIONオブジェクト[RFC6689]を使用して、現用LSPと保護LSPの両方を適切に作成します。
This document does not change any of the management or operational details for networks that utilize PCE. (Please refer to [RFC4655] for manageability considerations for a PCE-based architecture.) However, this document proposes the introduction of several PCEP objects and data for the better integration of PCE with GMPLS networks. Those protocol elements will need to be visible in any management tools that apply to the PCE, PCC, and PCEP. That includes, but is not limited to, adding appropriate objects to existing PCE MIB modules that are used for modeling and monitoring PCEP deployments [PCEP-MIB]. Ideas for what objects are needed may be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB [RFC4802].
このドキュメントは、PCEを利用するネットワークの管理または運用の詳細を変更しません。 （PCEベースのアーキテクチャの管理性に関する考慮事項については、[RFC4655]を参照してください。）ただし、このドキュメントでは、PCEとGMPLSネットワークをより適切に統合するためのいくつかのPCEPオブジェクトとデータの紹介を提案します。これらのプロトコル要素は、PCE、PCC、およびPCEPに適用される管理ツールで表示される必要があります。これには、PCEP展開のモデリングとモニタリングに使用される既存のPCE MIBモジュールへの適切なオブジェクトの追加が含まれますが、これに限定されません[PCEP-MIB]。必要なオブジェクトのアイデアは、GMPLS-TE-STD-MIB [RFC4802]の関連するGMPLS拡張機能によって導かれる場合があります。
PCEP extensions to support GMPLS should be considered under the same security as current PCE work, and this extension will not change the underlying security issues. Section 10 of [RFC5440] describes the list of security considerations in PCEP. At the time [RFC5440] was published, TCP Authentication Option (TCP-AO) had not been fully specified for securing the TCP connections that underlie PCEP sessions. TCP-AO [RFC5925] has now been published, and PCEP implementations should fully support TCP-AO according to [RFC6952].
GMPLSをサポートするPCEP拡張機能は、現在のPCE作業と同じセキュリティの下で検討する必要があります。この拡張機能は、根本的なセキュリティ問題を変更しません。 [RFC5440]のセクション10では、PCEPのセキュリティに関する考慮事項のリストについて説明しています。 [RFC5440]が公開された時点では、PCEPセッションの基礎となるTCP接続を保護するためのTCP認証オプション（TCP-AO）は完全には指定されていませんでした。 TCP-AO [RFC5925]が公開され、PCEP実装は[RFC6952]に従ってTCP-AOを完全にサポートするはずです。
The authors would like to express thanks to Ramon Casellas, Julien Meuric, Adrian Farrel, Yaron Sheffer, and Shuichi Okamoto for their comments.
コメントを提供してくれたRamon Casellas、Julien Meuric、Adrian Farrel、Yaron Sheffer、Shuichi Okamotoに感謝します。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「Resource ReSerVation Protocol-Traffic Engineering（RSVP-TE）のUnnumberedリンクのシグナリング」、RFC 3477、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、2004年10月。
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K。およびY. Rekhter、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、2005年10月。
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
[RFC4328] Papadimitriou、D。、「G.709光トランスポートネットワーク制御のための一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング拡張機能」、RFC 4328、2006年1月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606] Mannie、E。、およびD. Papadimitriou、「同期光ネットワーク（SONET）および同期デジタル階層（SDH）制御用の汎用マルチプロトコルラベルスイッチング（GMPLS）拡張」、RFC 4606、2006年8月。
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]ナドー、T。およびA.ファレル、「一般化マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Rekhter、Y。、およびD. Papadimitriou、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリーをサポートするRSVP-TE拡張機能」、RFC 4872、2007年5月。
[RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4927] Le Roux、J。、「Path Computation Element Communication Protocol（PCECP）Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering」、RFC 4927、2007年6月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376] Bitar、N.、Zhang、R。、およびK. Kumaki、「パス計算要素通信プロトコル（PCECP）のInter-AS要件」、RFC 5376、2008年11月。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。とJL。 Le Roux、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", RFC 6002, October 2010.
[RFC6002] Berger、L.およびD. Fedyk、「Generalized MPLS（GMPLS）Data Channel Switching Capable（DCSC）and Channel Set Label Extensions」、RFC 6002、2010年10月。
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011.
[RFC6060] Fedyk、D.、Shah、H.、Bitar、N。、およびA. Takacs、「イーサネットプロバイダーバックボーントラフィックエンジニアリング（PBB-TE）の汎用マルチプロトコルラベルスイッチング（GMPLS）制御」、RFC 6060、2011年3月。
[RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, March 2011.
[RFC6205] Otani、T. and D. Li、 "Generalized Labels for Lambda-Switch-Capable（LSC）Label Switching Routers"、RFC 6205、March 2011。
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, September 2011.
[RFC6387] Takacs、A.、Berger、L.、Caviglia、D.、Fedyk、D。、およびJ. Meuric、「GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths（LSPs）」、RFC 6387、2011年9月。
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, July 2012.
[RFC6689] Berger、L。、「RSVP ASSOCIATIONオブジェクトの使用」、RFC 6689、2012年7月。
[PCE-WSON-REQ] Lee, Y., Bernstein, G., Martensson, J., Takeda, T., Tsuritani, T., and O. Dios, "PCEP Requirements for WSON Routing and Wavelength Assignment", Work in Progress, June 2013.
[PCE-WSON-REQ] Lee、Y.、Bernstein、G.、Martensson、J.、Takeda、T.、Turitani、T。、およびO. Dios、「WSONルーティングおよび波長割り当てのPCEP要件」、Work in進捗状況、2013年6月。
[PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2013.
[PCEP-MIB] Koushik、K.、Stephan、E.、Zhao、Q.、King、D.、and J. Hardwick、 "PCE Communication Protocol（PCEP）Management Information Base"、Work in Progress、2013年7月。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R。およびJ. Vasseur、「MPLS Inter-Autonomous System（AS）Traffic Engineering（TE）Requirements」、RFC 4216、2005年11月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J。およびJ. Le Roux、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、2006年9月。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J。、およびA. Ayyangar、「A Framework for Inter-domain Multiprotocol Label Switching Traffic Engineering」、RFC 4726、2006年11月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874] Lee、CY。、Farrel、A。、およびS. De Cnodder、「Exclude Routes-Extension to Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）」、RFC 4874、2007年4月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「Policy-Enabled Path Computation Framework」、RFC 5394、2008年12月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", RFC 6457, December 2011.
[RFC6457] Takeda、T.およびA. Farrel、「PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering」、RFC 6457、2011年12月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの分析によるルーティングプロトコルのキーイングおよび認証（KARP）設計ガイド」、RFC 6952、5月2013。
Authors' Addresses
著者のアドレス
Tomohiro Otani KDDI Corporation 2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo Japan Phone: +81-(3) 3347-6006 EMail: tm-otani@kddi.com
ともひろ おたに Ｋっぢ こｒぽらちおん ２ー３ー２ にしーしんじゅく しんじゅくーく、 ときょ じゃぱん Ｐほね： ＋８１ー（３） ３３４７ー６００６ えまいｌ： ｔｍーおたに＠ｋっぢ。こｍ
Kenichi Ogaki KDDI Corporation 3-10-10 Iidabashi Chiyoda-ku, Tokyo Japan Phone: +81-(3) 6678-0284 EMail: ke-oogaki@kddi.com
けにち おがき Ｋっぢ こｒぽらちおん ３ー１０ー１０ いいだばし ちよだーく、 ときょ じゃぱん Ｐほね： ＋８１ー（３） ６６７８ー０２８４ えまいｌ： けーおおがき＠ｋっぢ。こｍ
Diego Caviglia Ericsson 16153 Genova Cornigliano Italy Phone: +390106003736 EMail: diego.caviglia@ericsson.com
ディエゴカビリアエリクソン16153ジェノバコルニリアーノイタリア電話：+390106003736メール：diego.caviglia@ericsson.com
Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District, Shenzhen 518129 P.R. China Phone: +86-755-28972912 EMail: zhangfatai@huawei.com
Fatai Zhang Huawei Technologies Co.、Ltd. F3-5-B R＆D Center、Huawei Base Bantian、Longgang District、Shenzhen 518129 P.R. China電話：+ 86-755-28972912メール：zhangfatai@huawei.com
Cyril Margaria Coriant R&D GmbH St Martin Strasse 76 Munich 81541 Germany Phone: +49 89 5159 16934 EMail: cyril.margaria@coriant.com
Cyril Margaria Coriant R＆D GmbH St Martin Strasse 76 Munich 81541 Germany電話：+49 89 5159 16934メール：cyril.margaria@coriant.com