[要約] RFC 5394は、ポリシーに基づいた経路計算フレームワークに関するものであり、ネットワークの経路計算を制御するためのポリシーの適用方法を提供します。その目的は、ネットワークの効率性と柔軟性を向上させることです。
Network Working Group I. Bryskin
Request for Comments: 5394 Adva Optical
Category: Informational D. Papadimitriou
Alcatel
L. Berger
LabN Consulting
J. Ash
AT&T
December 2008
Policy-Enabled Path Computation Framework
ポリシー対応のパス計算フレームワーク
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy.
PATH計算要素（PCE）アーキテクチャは、パス計算のコンテキストでポリシーの概念を紹介します。このドキュメントは、PCEアーキテクチャ内のポリシーに関する追加の詳細を提供し、PCEポリシーのサポートのコンテキストも提供します。このドキュメントでは、パス計算ポリシーをサポートするためのフレームワークとして、ポリシーコア情報モデル（PCIM）の使用を紹介します。このドキュメントは、PCEポリシーをサポートするための代表的なシナリオも提供します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Background ......................................................4
2.1. Motivation .................................................4
2.2. Policy Attributes ..........................................6
2.3. Representative Policy Scenarios ............................7
2.3.1. Scenario: Policy Configured Paths ...................7
2.3.2. Scenario: Provider Selection Policy ................10
2.3.3. Scenario: Policy Based Constraints .................12
2.3.4. Scenario: Advanced Load Balancing (ALB) Example ....14
3. Requirements ...................................................16
4. Path Computation Policy Information Model (PCPIM) ..............18
5. Policy-Enabled Path Computation Framework Components ...........20
6. Policy Component Configurations ................................21
6.1. PCC-PCE Configurations ....................................21
6.2. Policy Repositories .......................................24
6.3. Cooperating PCE Configurations ............................25
6.4. Policy Configuration Management ...........................27
7. Inter-Component Communication ..................................27
7.1. Policy Communication ......................................27
7.2. PCE Discovery Policy Considerations .......................29
8. Path Computation Sequence of Events ............................29
8.1. Policy-Enabled PCC, Policy-Enabled PCE ....................29
8.2. Policy-Ignorant PCC, Policy-Enabled PCE ...................31
9. Introduction of New Constraints ................................32
10. Security Considerations .......................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................34
The Path Computation Element (PCE) Architecture is introduced in [RFC4655]. This document describes the impact of policy-based decision making when incorporated into the PCE architecture and provides additional details on, and context for, applying policy within the PCE architecture.
パス計算要素（PCE）アーキテクチャは[RFC4655]に導入されています。このドキュメントでは、PCEアーキテクチャに組み込まれた場合のポリシーベースの意思決定の影響について説明し、PCEアーキテクチャ内のポリシーを適用するための追加の詳細とコンテキストを提供します。
Policy-based Management (PBM), see [RFC3198], is a network management approach that enables a network to automatically perform actions in response to network events or conditions based on pre-established rules, also denoted as policies, from a network administrator. PBM enables network administrators to operate in a high-level manner through rule-based strategy (policies can be defined as a set of rules and actions); the latter are translated automatically (i.e., dynamically, without human interference) into individual device configuration directives, aimed at controlling a network as a whole. Two IETF Working Groups have considered policy networking in the past: The Resource Allocation Protocol (RAP) working group and the Policy Framework working group.
[RFC3198]を参照するポリシーベースの管理（PBM）は、ネットワーク管理者からもポリシーとして示される事前に確立されたルールに基づいて、ネットワークイベントまたは条件に応じてアクションを自動的に実行できるようにするネットワーク管理アプローチです。PBMにより、ネットワーク管理者はルールベースの戦略を通じて高レベルで動作することができます（ポリシーは、一連のルールとアクションとして定義できます）。後者は、ネットワーク全体を制御することを目的とした個々のデバイス構成指示に自動的に（つまり、動的に、人間の干渉なしに）翻訳されます。2つのIETFワーキンググループは、過去にポリシーネットワーキングを検討してきました。リソース割り当てプロトコル（RAP）ワーキンググループとポリシーフレームワークワーキンググループです。
A framework for policy-based admission control [RFC2753] was defined and a protocol for use between Policy Enforcement Points (PEP) and Policy Decision Points (PDP) was specified: Common Open Policy Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to refer to the functions defined in the COPS context. This document makes no assumptions nor does it require that the actual COPS protocol be used. Any suitable policy exchange protocol (for example, Simple Object Access Protocol (SOAP) [W3CSOAP]) may be substituted.
ポリシーベースの入場管理のフレームワーク[RFC2753]が定義され、ポリシー執行ポイント（PEP）とポリシー決定ポイント（PDP）の間で使用するプロトコルが指定されました。このドキュメントでは、PEPとPDPという用語を使用して、COPSコンテキストで定義された関数を参照しています。このドキュメントは、実際のCOPプロトコルを使用することを要求することも、仮定もしません。適切なポリシー交換プロトコル（たとえば、Simple Object Access Protocol（SOAP）[W3CSOAP]）はすべて置き換えられる場合があります。
The IETF has also produced a general framework for representing, managing, sharing, and reusing policies in a vendor-independent, interoperable, and scalable manner. It has also defined an extensible information model for representing policies, called the Policy Core Information Model (PCIM) [RFC3060], and an extension to this model to address the need for QoS management, called the Quality of Service (QoS) Policy Information Model (QPIM) [RFC3644]. However, additional mechanisms are needed in order to specify policies related to the path computation logic as well as its control.
IETFは、ベンダーに依存しない、相互運用可能、およびスケーラブルな方法でポリシーを表現、管理、共有、再利用するための一般的なフレームワークを作成しました。また、ポリシーコア情報モデル（PCIM）[RFC3060]と呼ばれるポリシーを表現するための拡張可能な情報モデルと、QOS管理の必要性に対処するためのこのモデルの拡張機能も定義しています。（QPIM）[RFC3644]。ただし、パス計算ロジックとその制御に関連するポリシーを指定するためには、追加のメカニズムが必要です。
In Section 2, this document presents policy-related background and scenarios to provide a context for this work. Section 3 provides requirements that must be addressed by mechanisms and protocols that enable policy-based control over path computation requests and decisions. Section 4 introduces PCIM as a core component in a framework for providing policy-enabled path computation. Section 5 introduces a set of components that may be used to support policy-enabled path computation. Sections 6, 7, and 8 provide details on possible component configurations, communication, and events. Section 10 discusses the ability to introduce new constraints with minimal impact. It should be noted that this document, in Section 4, only introduces PCIM; specific PCIM definitions to support path computation will be discussed in a separate document.
セクション2では、このドキュメントでは、この作業のコンテキストを提供するためのポリシー関連の背景とシナリオを示しています。セクション3には、パスの計算要求と決定に対するポリシーベースの制御を可能にするメカニズムとプロトコルによって対処する必要がある要件があります。セクション4では、ポリシー対応のパス計算を提供するためのフレームワークのコアコンポーネントとしてPCIMを紹介します。セクション5では、ポリシー対応のパス計算をサポートするために使用できるコンポーネントのセットを紹介します。セクション6、7、および8は、可能なコンポーネントの構成、通信、およびイベントの詳細を提供します。セクション10では、最小限の影響で新しい制約を導入する機能について説明します。このドキュメントは、セクション4でPCIMのみを導入することに注意する必要があります。パス計算をサポートする特定のPCIM定義については、別のドキュメントで説明します。
The reader is assumed to be familiar with the following terms:
読者は、次の用語に精通していると想定されています。
BEEP: Blocks Extensible Exchange Protocol, see [RFC3080]. CIM: Common Information Model, see [DMTF]. COPS: Common Open Policy Service, see [RFC2748]. CSPF: Constraint-based Shortest Path First, see [RFC3630].
ビープ音：拡張可能な交換プロトコルをブロックします。[RFC3080]を参照してください。CIM：一般的な情報モデル、[DMTF]を参照してください。警官：一般的なオープンポリシーサービス、[RFC2748]を参照してください。CSPF：最初に制約ベースの最短パス、[RFC3630]を参照してください。
LSP: Label Switched Path, see [RFC3031]. LSR: Label Switching Router, see [RFC3031]. PBM: Policy-Based Management, see [RFC3198]. PC: Path Computation. PCC: Path Computation Client, see [RFC4655]. PCCIM: Path Computation Core Information Model. PCE: Path Computation Element, see [RFC4655]. PCEP: Path Computation Element Communication Protocol, see [PCEP]. PCIM: Policy Core Information Model, see [RFC3060]. PDP: Policy Decision Point, see [RFC2753]. PEP: Policy Enforcement Point, see [RFC2753]. QPIM: QoS Policy Information Model, see [RFC3644]. SLA: Service Level Agreement. SOAP: Simple Object Access Protocol, see [W3CSOAP]. TE: Traffic Engineering, see [RFC3209] and [RFC3473]. TED: Traffic Engineering Database, see [RFC3209] and [RFC3473]. TE LSP: Traffic Engineering MPLS Label Switched Path, see [RFC3209] and [RFC3473]. WDM: Wavelength Division Multiplexing
LSP：ラベルスイッチ付きパス、[RFC3031]を参照してください。LSR：ラベルスイッチングルーター、[RFC3031]を参照してください。PBM：ポリシーベースの管理、[RFC3198]を参照してください。PC：パス計算。PCC：パス計算クライアント、[RFC4655]を参照してください。PCCIM：パス計算コア情報モデル。PCE：パス計算要素、[RFC4655]を参照してください。PCEP：パス計算要素通信プロトコル、[PCEP]を参照してください。PCIM：ポリシーコア情報モデル、[RFC3060]を参照してください。PDP：ポリシー決定ポイント、[RFC2753]を参照してください。PEP：政策執行ポイント、[RFC2753]を参照してください。QPIM：QoSポリシー情報モデル、[RFC3644]を参照してください。SLA：サービスレベル契約。SOAP：Simple Object Access Protocol、[w3csoap]を参照してください。TE：トラフィックエンジニアリング、[RFC3209]および[RFC3473]を参照してください。TED：トラフィックエンジニアリングデータベース、[RFC3209]および[RFC3473]を参照してください。TE LSP：トラフィックエンジニアリングMPLSラベルスイッチパス、[RFC3209]および[RFC3473]を参照してください。WDM：波長分割多重化
This section provides some general background on the use of policies within the PCE architecture. It presents the rationale behind the use of policies in the TE path computation process, as well as representative policies usage scenarios. This information is intended to provide context for the presented PCE policy framework. This section does not attempt to present an exhaustive list of rationales or scenarios.
このセクションでは、PCEアーキテクチャ内のポリシーの使用に関する一般的な背景を説明します。TEパス計算プロセスでのポリシーの使用の背後にある根拠と、代表的なポリシーの使用シナリオを提示します。この情報は、提示されたPCEポリシーフレームワークのコンテキストを提供することを目的としています。このセクションでは、理論的またはシナリオの徹底的なリストを提示しようとはしていません。
The PCE architecture as introduced in [RFC4655] includes policy as an integral part of the PCE architecture. This section presents some of the rationale for this inclusion.
[RFC4655]で導入されたPCEアーキテクチャには、PCEアーキテクチャの不可欠な部分としてのポリシーが含まれています。このセクションでは、この包含の理論的根拠の一部を示します。
Network operators require a certain level of flexibility to shape the TE path computation process, so that the process can be aligned with their business and operational needs. Many aspects of the path computation may be governed by policies. For example, a PCC may use policies configured by the operator to decide which optimization criteria, constraints, diversities and their relaxation strategies to request while computing path(s) for a particular service. Depending on SLAs, TE and cost/performance ratio goals, path computation requests may be issued differently for different services. A given Service A, for instance, may require two Shared Risk Link Group (SRLG)-disjoint paths for building end-to-end recovery scheme, while for a Service B link-disjoint paths may be sufficient. Service A may need paths with minimal end-to-end delay, while Service B may be looking for shortest (minimal-cost) paths. Different constraint relaxation strategies may be applied while computing paths for Service A and for Service B, and so forth. So, based on distinct service requirements, distinct or similar policies may be adopted when issuing/handling path computation requests.
ネットワークオペレーターは、TEパス計算プロセスを形作るために一定レベルの柔軟性を必要とし、そのため、プロセスをビジネスおよび運用上のニーズと一致させることができます。パス計算の多くの側面は、ポリシーによって支配される場合があります。たとえば、PCCは、オペレーターによって構成されたポリシーを使用して、特定のサービスのパスを計算しながらリクエストする最適化基準、制約、多様性、リラクゼーション戦略を決定することができます。SLA、TE、およびコスト/パフォーマンス比率の目標に応じて、サービスごとにパス計算リクエストが異なる方法で発行される場合があります。たとえば、特定のサービスAには、エンドツーエンドの回復スキームを構築するために2つの共有リスクリンクグループ（SRLG）-disjointパスが必要になる場合がありますが、サービスBリンク - ディスジョイントパスは十分です。サービスAには、最小限のエンドツーエンド遅延でパスが必要になる場合がありますが、サービスBは最短（最小コスト）パスを探している場合があります。サービスAやサービスBなどのパスを計算する際には、さまざまな制約リラクゼーション戦略を適用できます。したがって、異なるサービス要件に基づいて、パス計算リクエストを発行/処理する際に、異なるまたは同様のポリシーが採用される場合があります。
Likewise, a PCE may apply policies to decide which algorithm(s) to use while performing path computations requested from a particular PCC or for a particular domain, see [RFC4927]; whether to seek the cooperation of other PCEs to satisfy a particular request or to handle a request on its own (possibly responding with non-explicit paths), or how the request should be modified before being sent to other member(s) of a group of cooperating PCEs, etc.
同様に、PCEは、特定のPCCまたは特定のドメインに対して要求されたパス計算の実行中に使用するアルゴリズムを決定するためのポリシーを適用する場合があります。[RFC4927]を参照してください。特定のリクエストを満たすために他のPCEの協力を求めるか、それ自体でリクエストを処理する（おそらく非推測パスで応答する）か、グループの他のメンバーに送信する前にリクエストを変更する方法協力するpceなど。
Additional motivation for supporting policies within the PCE architecture can be described as follows. Historically, a path computation entity was an intrinsic part of an LSR's control plane and always co-located with the LSR's signaling and routing subsystems. This approach allowed for unlimited flexibility in providing various path computation enhancements, such as: adding new types of constraints, diversities and their relaxation strategies, adopting new objective functions and optimization criteria, etc. All that had to be done to support an enhancement was to upgrade the control plane software of a particular LSR (and no other LSRs or any other network elements).
PCEアーキテクチャ内のポリシーをサポートするための追加の動機は、次のように説明できます。歴史的に、PATH計算エンティティはLSRのコントロールプレーンの本質的な部分であり、常にLSRのシグナリングおよびルーティングサブシステムと共同で共同で開催されました。このアプローチにより、新しいタイプの制約、多様性、リラクゼーション戦略の追加、新しい目的機能と最適化基準の採用など、さまざまなパス計算の強化を提供する際の無制限の柔軟性が可能になりました。特定のLSRのコントロールプレーンソフトウェアをアップグレードします（および他のLSRまたは他のネットワーク要素はありません）。
With the introduction of the PCE architecture, the introduction of new PCE capabilities becomes more complicated: it isn't enough for a PCE to upgrade its own software. In order to take advantage of a PCE's new capabilities, new advertising and signaling objects may need to be standardized, all PCCs may need to be upgraded with new software, and new interoperability problems may need to be resolved, etc.
PCEアーキテクチャの導入により、新しいPCE機能の導入はより複雑になります。PCEが独自のソフトウェアをアップグレードするだけでは不十分です。PCEの新しい機能を活用するには、新しい広告およびシグナリングオブジェクトを標準化する必要がある場合があり、すべてのPCCを新しいソフトウェアでアップグレードする必要があり、新しい相互運用性の問題を解決する必要がある場合があります。
Within the context of the PCE architecture, it is therefore highly desirable to find a way to introduce new path computation capabilities without requiring modifying either the discovery/communication protocols or the PCC software. One way to achieve this objective is to consider path selection constraints, their relaxations, and objective functions, as path computation request-specific policies. Furthermore, such policies may be configured and managed by a network operator as any other policies and may be interpreted in real time by PCCs and PCEs.
したがって、PCEアーキテクチャのコンテキスト内では、発見/通信プロトコルまたはPCCソフトウェアのいずれかを変更することなく、新しいパス計算機能を導入する方法を見つけることが非常に望ましいです。この目的を達成する1つの方法は、パス計算要求固有のポリシーとして、パス選択の制約、それらの緩和、および目的関数を考慮することです。さらに、そのようなポリシーは、ネットワークオペレーターによって他のポリシーとして構成および管理され、PCCSおよびPCESによってリアルタイムで解釈される場合があります。
There are a number of advantages and useful by-products of such an approach:
このようなアプローチには、多くの利点と有用な副産物があります。
- New path computation capabilities may be introduced without changing PCE-PCC communication and discovery protocols or PCC software. Only the PCE module providing the path computation capabilities (referred to in this document as a path computation engine) needs to be updated.
- PCE-PCC通信および発見プロトコルまたはPCCソフトウェアを変更せずに、新しいパス計算機能を導入できます。パス計算機能（このドキュメントではパス計算エンジンと呼ばれる）を提供するPCEモジュールのみを更新する必要があります。
- Existing constraints, objective functions and their relaxations may be aggregated and otherwise associated, thus producing new, more complex objective functions that do not require a change of code even on the PCEs supporting the functions.
- 既存の制約、目的関数、およびそれらの弛緩が集約され、そうでなければ関連する可能性があるため、機能をサポートするPCEでもコードの変更を必要としない、より複雑なより複雑な目的関数を生成します。
- Different elements such as conditions, actions, variables, etc., may be reused by multiple constraints, diversities, and optimizations.
- 条件、アクション、変数などのさまざまな要素は、複数の制約、多様性、および最適化によって再利用される場合があります。
- PCCs and PCEs need to handle other (that is, not request-specific) policies. Path computation-related policies of all types can be placed within the same policy repositories, managed by the same policy management tools, and interpreted using the same mechanisms. Also, policies need to be supported by PCCs and PCEs independent of the peculiarities of a specific PCC-PCE communication protocol, see [PCEP]. Thus, introducing a new (request-specific) type of policy describing constraints and other elements of a path computation request will be a natural and relatively inexpensive addition to the policy-enabled path computation architecture.
- PCCとPCESは、他の（つまり、リクエスト固有ではない）ポリシーを処理する必要があります。すべてのタイプのパス計算関連ポリシーは、同じポリシー管理ツールによって管理され、同じメカニズムを使用して解釈される同じポリシーリポジトリ内に配置できます。また、特定のPCC-PCE通信プロトコルの特性とは無関係に、PCCSおよびPCESによってポリシーをサポートする必要があります。[PCEP]を参照してください。したがって、パス計算要求の制約やその他の要素を説明する新しい（リクエスト固有の）タイプのポリシーを導入することは、ポリシー対応のパス計算アーキテクチャに自然で比較的安価な追加になります。
This section provides a summary listing of the policy attributes that may be included in the policy exchanges described in the scenarios that follow. This list is provided for guidance and is not intended to be exclusive. Implementation of this framework might include additional policy attributes not listed here.
このセクションでは、以下のシナリオで説明されているポリシー交換に含まれる可能性のあるポリシー属性の要約リストを示します。このリストはガイダンスのために提供されており、排他的であることを意図していません。このフレームワークの実装には、ここにリストされていない追加のポリシー属性が含まれる場合があります。
Identities
アイデンティティ
- LSP head-end - LSP destination - PCC - PCE LSP identifiers
- LSPヘッドエンド-LSP宛先-PCC -PCE LSP識別子
- LSP head-end - LSP destination - Tunnel identifier - Extended tunnel identifier - LSP ID - Tunnel name
- LSPヘッドエンド - LSP宛先 - トンネル識別子 - 拡張トンネル識別子-LSP ID-トンネル名
Requested LSP qualities
LSPの品質を要求しました
- bandwidth - traffic parameters - LSP attributes - explicit path inclusions - explicit path exclusions - link protection level - setup priority - holding priority - preexisting LSP route
- 帯域幅 - トラフィックパラメーター-LSP属性 - 明示的なパス包有物 - 明示的なパス除外 - リンク保護レベル - セットアップ優先度 - 優先度を保持 - 既存のLSPルート
Requested path computation behavior
要求されたパス計算動作
- objective function - other LSPs to be considered
- 目的関数 - 考慮される他のLSP
Additional policy information
追加のポリシー情報
- Transparent policy information as received in Resource Reservation Protocol (RSVP)-TE
- リソース予約プロトコル（RSVP）で受け取った透明なポリシー情報
This section provides example scenarios of how policies may be applied using the PCE policy framework within the PCE architecture context. Actual networks may deploy one of the scenarios discussed, some combination of the presented scenarios, or other scenarios (not discussed). This section should not be viewed as limiting other applications of policies within the PCE architecture.
このセクションでは、PCEアーキテクチャコンテキスト内のPCEポリシーフレームワークを使用して、ポリシーを適用する方法の例のシナリオを示します。実際のネットワークは、議論されているシナリオの1つ、提示されたシナリオの組み合わせ、または他のシナリオ（議論されていない）を展開する場合があります。このセクションは、PCEアーキテクチャ内のポリシーの他のアプリケーションを制限すると見なされるべきではありません。
A very simple usage scenario for PCE policy would be to use PCE to centrally administer configured paths. Configured paths are composed of strict and loose hops in the form of Explicit Route Objects (EROs), see [RFC3209], and are used by one or more LSPs. Typically, such paths are configured at the LSP ingress. In the context of policy-enabled path computation, an alternate approach is possible.
PCEポリシーの非常にシンプルな使用シナリオは、PCEを使用して構成されたパスを中央に管理することです。構成されたパスは、明示的なルートオブジェクト（EROS）の形での厳密なホップとルーズホップで構成され、[RFC3209]を参照し、1つ以上のLSPで使用されます。通常、そのようなパスはLSPイングレスで構成されます。ポリシー対応のパス計算のコンテキストでは、別のアプローチが可能です。
In particular, service-specific policies can be installed that will provide configured path(s) for a specific service request. The request may be identified based on service parameters such as endpoints, requested QoS, or even a token that identifies the initiator of a service request. The configured path(s) would then be used as input to the path computation process, which would return explicit routes by expanding of all specified loose hops.
特に、特定のサービス要求に合わせて構成されたパスを提供するサービス固有のポリシーをインストールできます。リクエストは、エンドポイント、要求されたQoS、またはサービス要求の開始者を識別するトークンなどのサービスパラメーターに基づいて識別される場合があります。構成されたパスは、パス計算プロセスへの入力として使用され、指定されたすべてのルーズホップを拡張することにより明示的なルートを返します。
Example of policy: if(service_destination matches 10.132.12.0/24) Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1. else Compute path dynamically.
ポリシーの例：if（service_destinationマッチ10.132.12.0/24）パスを使用します：10.125.13.1 => 10.125.15.1 => 10.132.12.1。それ以外の場合は、パスを動的に計算します。
----------------------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (e.g., routing protocol)
| | |
| v |
| ------ ----- | Inter-PCE Request/Response
| |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- |
----------------------
^
| Request/
| Response
v
Service ------------- Signaling
Request |[PCC][Policy]| Protocol
<------>| Node |<------->
or Signaling -------------
Protocol
Figure 1: Policy Enabled PCC and PCE
図1：ポリシーがPCCとPCCを可能にしました
Path computation policies may be applied at either a PCC or a PCE, see Figure 1. In the PCC case, the configured path would be processed at the PCC and then passed to the PCE along with the PCE request, probably in the form of (inclusion) constraints. When applied at the PCE, the configured path would be used locally. Both cases require some method to configure and manage policies. In the PCC case, the real benefit would come when there is an automated policy distribution mechanism.
PATH計算ポリシーは、PCCまたはPCEのいずれかで適用できます。図1を参照してください。PCCの場合、構成されたパスはPCCで処理され、おそらくPCE要求とともにPCEに渡されます。包含）制約。PCEで適用すると、構成されたパスがローカルで使用されます。どちらの場合も、ポリシーを構成および管理するための方法が必要です。PCCの場合、自動化されたポリシー配布メカニズムがある場合、実際の利点が生まれます。
------------------ -------------------
| | | |
| PCE | | PCE |
| | | |
| ------ ----- | | ----- ------ |
| |Policy| | TED | | | | TED | |Policy| |
| ------ ----- | | ----- ------ |
------------------ -------------------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request|Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 2: Multiple PCE Path Computation
図2：複数のPCEパス計算
------------------ ------------------
| | Inter-PCE Request/Response | |
| PCE |<-------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 3: Multiple PCE Path Computation with Inter-PCE Communication
図3：PCE間通信による複数のPCEパス計算
Policy-configured paths may also be used in environments with multiple (more than one) cooperating PCEs (see Figures 2 and 3). For example, consider the case when there is limited TE visibility and independent PCEs are used to determine path(s) within each area of the TE visibility. In such a case, it may not be possible (or desirable) to configure entire explicit path(s) on a single PCE. However, it is possible to configure explicit path(s) for each area of the TE visibility and each responsible PCE. One by one, the PCEs would then map an incoming signaling request to appropriate configured path(s). Note that to make such a scenario work, it would likely be necessary to start and finish the configured paths on TE domain boundary nodes. Clearly, consistent PCE Policy Repositories are also critical in this example.
ポリシーが構成されたパスは、複数（複数の）協力PCEを持つ環境でも使用できます（図2および3を参照）。たとえば、視認性が限られている場合を考慮し、独立したPCEが使用されている場合を使用して、視認性の各領域内のパスを決定します。そのような場合、単一のPCEで明示的なパス全体を構成することは不可能（または望ましい）場合があります。ただし、TEの可視性と各責任PCEの各領域に明示的なパスを構成することができます。次に、PCESは、着信シグナリングリクエストを適切な構成パスにマッピングします。このようなシナリオを機能させるには、TEドメイン境界ノードの構成されたパスを起動および終了する必要がある可能性が高いことに注意してください。明らかに、この例では、一貫したPCEポリシーリポジトリも重要です。
A potentially more interesting scenario is applying PC policies in multi-provider topologies. There are numerous interesting policy applications in such topologies. A rudimentary example is simple access control, that is, deciding which PCCs are permitted to request inter-domain path computation.
より興味深いシナリオは、マルチプロバイダートポロジにPCポリシーを適用することです。このようなトポロジーには、多くの興味深いポリシーアプリケーションがあります。初歩的な例は、単純なアクセス制御、つまり、どのPCCがドメイン間パス計算を要求することを許可されているかを決定することです。
A more complicated example is applying policy to determine which domain or network provider will be used to support a particular PCE request. Consider the topology presented in Figure 4. In this example, there are multiple transit domains available to provide a path from a source domain to a destination domain. Furthermore, each transit domain may have one or more options for reaching a particular domain. Each domain will need to select which of the multiple available paths will be used to satisfy a particular PCE request.
より複雑な例は、特定のPCE要求をサポートするために使用されるドメインまたはネットワークプロバイダーを決定するポリシーを適用することです。図4に示すトポロジを考えてみましょう。この例では、ソースドメインから宛先ドメインへのパスを提供するために、複数のトランジットドメインが利用可能です。さらに、各トランジットドメインには、特定のドメインに到達するための1つ以上のオプションがある場合があります。各ドメインは、特定のPCEリクエストを満たすために使用できる複数のパスのどれを使用するかを選択する必要があります。
In today's typical path computation process, TE reachability, availability, and metric are the basic criteria for path selection. However, policies can provide an important added consideration in the decision process. For example, transit domain A may be more expensive and provide lower delay or loss than transit domain B. Likewise, a transit domain may wish to treat PCE requests from its own customers differently than requests from other providers. In both cases, computation based on traffic engineering databases will result in multiple transit domains that provide reachability, and policies can be used to govern which PCE requests get better service.
今日の典型的なパス計算プロセスでは、到達可能性、可用性、およびメトリックがパス選択の基本的な基準です。ただし、ポリシーは、決定プロセスにおいて重要な追加考慮事項を提供できます。たとえば、トランジットドメインAは高価であり、トランジットドメインBよりも低い遅延または損失を提供する場合があります。同様に、トランジットドメインは、他のプロバイダーからの要求とは異なる顧客からのPCEリクエストを扱うことをお勧めします。どちらの場合も、トラフィックエンジニアリングデータベースに基づいた計算により、到達可能性を提供する複数のトランジットドメインが生じ、ポリシーを使用してどのPCEリクエストがより良いサービスを受けるかを管理できます。
+-------+
+----------+Transit+----------+
+---+---+ | Domain| +---+---+
|Transit| | C | |Transit|
+--------+ Domain| +---+---+ | Domain+--------+
| | A +--+ | +--+ F | |
+--+---+ +---+---+ | | | +---+---+ +--+---+
|Source| | | +---+---+ | | |Target|
|Domain| | +---+Transit+---+ | |Domain|
+--+---+ | +---+ Domain|---+ | +--+---+
| +---+---+ | | D | | +---+---+ |
| |Transit| | +---+---+ | |Transit| |
+--------+ Domain+--+ | +--+ Domain+--------+
| B | | | G |
+---+---+ +---+---+ +---+---+
| |Transit| |
+----------+ Domain+----------+
| E |
+-------+
Figure 4: Multi-Domain Network with Multiple Transit Options
図4：複数のトランジットオプションを備えたマルチドメインネットワーク
There are multiple options for differentiating which PCE requests use a particular transit domain and get a particular (better or worse) level of service. For example, a PCE in the source domain may use user- and request-specific policies to determine the level of service to provide. A PCE in the source domain may also use domain-specific policies to choose which transit domains are acceptable. A PCE in a transit domain may use request-specific policies to determine if a request is from a direct customer or another provider, and then use domain-specific policies to identify how the request should be processed.
どのPCE要求が特定のトランジットドメインを使用し、特定の（良くも悪くも）サービスを取得するかを区別するための複数のオプションがあります。たとえば、ソースドメインのPCEは、ユーザーおよびリクエスト固有のポリシーを使用して、提供するサービスのレベルを決定することができます。ソースドメインのPCEは、ドメイン固有のポリシーを使用して、どのトランジットドメインが許容できるかを選択することもできます。トランジットドメインのPCEは、リクエスト固有のポリシーを使用して、リクエストが直接顧客または別のプロバイダーからのものかどうかを判断し、ドメイン固有のポリシーを使用して、リクエストの処理方法を特定することができます。
Example of policy: if(path computation request issued by a PCC within Source Domain) Route the path through Transit Domain A. else Route the path through Transit Domain B.
ポリシーの例：if（ソースドメイン内のPCCによって発行されたパス計算リクエスト）トランジットドメインAを通るパスをルーティングします。
Another usage scenario is the use of policy to provide constraints in a PCE request. Consider an LSR with a policy enabled PCC, as shown in Figure 1, which receives a service request via signaling, including over a Network-Network Interface (NNI) or User Network Interface (UNI) reference point, or receives a configuration request over a management interface to establish a service. In either case, the path(s) needed to support the service are not explicitly specified in the message/request, and hence path computation is needed.
別の使用シナリオは、PCE要求に制約を提供するためのポリシーの使用です。図1に示すように、ポリシー対応のPCCを持つLSRを検討してください。これは、ネットワークネットワークインターフェイス（NNI）またはユーザーネットワークインターフェイス（UNI）参照ポイントを含むシグナリングを介してサービス要求を受信するか、またはの構成要求を受信します。サービスを確立するための管理インターフェイス。どちらの場合でも、サービスをサポートするために必要なパスは、メッセージ/リクエストで明示的に指定されていないため、パス計算が必要です。
In this case, the PCC may apply user- or service-specific policies to decide how the path selection process should be constrained, that is, which constraints, diversities, optimization criterion, and constraint relaxation strategies should be applied in order for the service LSP(s) to have a likelihood to be successfully established and provide necessary QoS and resilience against network failures. When deciding on the set of constraints, the PCC uses as an input all information it knows about the user and service, such as the contents of the received message, port ID over which message was received, associated VPN ID, signaling/reference point type, request time, etc. Once the constraints and other parameters of the required path computation are determined, the PCC generates a path computation request that includes the request-specific policies that describe the determined set of constraints, optimizations, and other parameters that indicate how the request is to be considered in the path computation process.
この場合、PCCはユーザーまたはサービス固有のポリシーを適用して、パス選択プロセスの制約、つまり、どの制約、多様性、最適化基準、および制約緩和戦略を適用する必要があるかを決定することができます。（S）正常に確立され、ネットワーク障害に対する必要なQOと回復力を提供する可能性がある。制約のセットを決定するとき、PCCは、受信したメッセージの内容、受信したメッセージ、関連するVPN ID、信号/参照ポイントタイプなど、ユーザーとサービスについて知っているすべての情報を入力として使用します。、リクエスト時間などリクエストは、パス計算プロセスで考慮されます。
Example of policy: if(LSP belongs to a WDM layer network) Compute the path with wavelength continuity constraint with the maximum Optical Signal Noise Ratio (OSNR) at the path end optimization. else if(LSP belongs to a connection oriented Ethernet layer network) Compute the path with minimum end-to-end delay. else Compute the shortest path.
ポリシーの例：（LSPがWDMレイヤーネットワークに属している場合）パスエンド最適化での最大光信号ノイズ比（OSNR）を使用して、波長連続性制約でパスを計算します。else（lspは、接続指向のイーサネットレイヤーネットワークに属している）の場合、最小エンドツーエンド遅延でパスを計算します。それ以外の場合は、最短パスを計算します。
The PCC may also apply server-specific policies in order to select which PCE to use from the set of known (i.e., discovered or configured) PCEs. The PCC may also use server-specific policies to form the request to match the PCE's capabilities so that the request will not be rejected and has a higher likelihood of being satisfied in an efficient way. An example of a request modification as the result of a server-specific policy is removing a constraint not supported by the PCE. Once the policy processing is completed at the PCC, and the path computation request resulting from the original service request is updated by the policy processing, the request is sent to the PCE.
PCCは、既知の（つまり、発見または構成された）PCEのセットから使用するPCEを選択するために、サーバー固有のポリシーを適用することもできます。PCCは、サーバー固有のポリシーを使用して、PCEの機能と一致するリクエストを形成して、リクエストが拒否されず、効率的な方法で満たされる可能性が高いようにすることもできます。サーバー固有のポリシーの結果としての要求変更の例は、PCEによってサポートされていない制約を削除することです。PCCでポリシー処理が完了し、元のサービス要求から生じるパス計算要求がポリシー処理によって更新されると、リクエストはPCEに送信されます。
Example of policy: if(LSP belongs to a WDM layer network) Identify a PCE supporting wavelength continuity and optical impairment constraints; Send a request to such PCE, requesting path computation with the following constraints: a) wavelength continuity; b) maximum Polarization Mode Dispersion (PMD) at the path end. if(the path computation fails) remove the maximum PMD constraint and try the computation again.
ポリシーの例：（LSPがWDMレイヤーネットワークに属している場合）は、波長の連続性と光学障害の制約をサポートするPCEを識別します。そのようなPCEにリクエストを送信し、次の制約でパス計算を要求します。a）波長の連続性。b）パスエンドでの最大偏光モード分散（PMD）。（パス計算が失敗する）場合、最大PMD制約を削除し、計算を再試行してください。
The PCE that receives the request validates and otherwise processes the request, applying the policies found in the request as well as any policies that are available at the PCE, e.g., client- and domain-specific policies. As a result of the policy processing, the PCE may decide to reject the request.
リクエストを受信するPCEは、リクエストを検証し、その他の方法で処理し、リクエストにあるポリシーと、PCEで利用可能なポリシー、たとえばクライアントおよびドメイン固有のポリシーを適用します。ポリシー処理の結果、PCEはリクエストを拒否することを決定する場合があります。
Example of policy: Authenticate the PCC requesting the path computation using the PCC ID found in the path computation request; Reject the request if the authentication fails.
ポリシーの例：PATH計算要求で見つかったPCC IDを使用してパス計算を要求するPCCを認証します。認証が失敗した場合、リクエストを拒否します。
The PCE also may decide to respond with one or several pre-computed paths if user- or client-specific policies instruct the PCE to do so. If the PCE decides to satisfy the request by performing a path computation, it determines if it needs the cooperation of other PCEs and defines parameters for path computations to be performed locally and remotely. After that, the PCE instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends path computation requests to one or more other PCEs. It then waits for the responses from the local path computation engine and, when used, the remote PCE. It then combines the resulting paths and sends the result back to the requesting PCC. The response may indicate policies describing the resulting paths, their characteristics (summary cost, expected end-to-end delay, etc.), as well as additional information related to the request, e.g., which constraints were honored, which were dismissed, and which were relaxed and in what way.
また、PCEは、ユーザーまたはクライアント固有のポリシーがPCEにそうするように指示する場合、1つまたは複数の事前計算されたパスで応答することを決定する場合があります。PCEがパス計算を実行してリクエストを満たすことを決定した場合、他のPCESの協力が必要かどうかを判断し、パス計算のパラメーターをローカルおよびリモートで実行するパラメーターを定義します。その後、PCEは、共同配置されたパス計算エンジンにローカルパス計算を実行するよう指示し、必要に応じて、1つ以上の他のPCEにパス計算要求を送信します。次に、ローカルパス計算エンジンからの応答と、使用するとリモートPCEを待ちます。次に、結果のパスを組み合わせて、結果を要求のPCCに送り返します。応答は、結果のパス、それらの特性（概要コスト、予想されるエンドツーエンド遅延など）を説明するポリシー、および要求に関連する追加情報、たとえば、どの制約が却下されたか、却下された制約があります。リラックスしていて、どのようにして。
Example of policy:
if(the path destination belongs to domain A)
Instruct local path computation engine to perform the path
computation;
else
Identify the PCE supporting the destination domain;
Send path computation request to such PCE;
Wait for and process the response.
Send the path computation response to the requesting PCC.
The PCC processes the response and instructs the LSR to encode the received path(s) into the outgoing signaling message(s).
PCCは応答を処理し、LSRに受信パスを発信シグナリングメッセージにエンコードするよう指示します。
Figure 5 illustrates a problem that stems from the coupling between BGP and IGP in the BGP decision process. If a significant portion of the traffic destined for the data center (or customer network) enters a PCE-enabled network from AS 1 and all IGP links' weights are the same, then both PE3 and PE4 will prefer to reach the data center using the routes advertised by PE2. PE5 will use the router-IDs of PE1 and PE2 to break the tie and might therefore also select to use the path through PE2 (if the router ID of PE2 is smaller than that of PE1). Either way, the net result is that the link between PE2 and CE will carry most of the traffic while the link between PE1 and the Customer Edge (CE) will be mostly idle.
図5は、BGP決定プロセスにおけるBGPとIGPの間の結合に起因する問題を示しています。データセンター（またはカスタマーネットワーク）に向けられたトラフィックのかなりの部分がAS 1からPCE対応ネットワークに入力し、すべてのIGPリンクの重みが同じである場合、PE3とPE4の両方がデータセンターに到達することを好みます。PE2によって宣伝されたルート。PE5は、PE1とPE2のルーターIDを使用してネクタイを破壊するため、PE2を介してパスを使用することも選択できます（PE2のルーターIDがPE1のルーターIDよりも小さい場合）。いずれにせよ、最終的な結果は、PE2とCEの間のリンクがほとんどのトラフィックを運ぶ一方で、PE1と顧客エッジ（CE）の間のリンクはほとんどアイドル状態になることです。
..............................
. AS 1 .
. .
. +---+ +---+ +----+ .
....|PE8|...|PE9|...|PE10|....
+---+ +---+ +----+
| | |
+---+ +---+ +---+
......|PE3|...|PE4|...|PE5|......
. +---+ +---+ +---+ .
.............. +---+ \ / ___/ +---+
. . _|PE2|_____+--+__/ / _|PE6|
. +--+ / +---+ |P1|_____+--+_______/ +---+
. Customer |CE|= . +--+ |P2| .
. Network +--+ \_+---+ \ +--+ .
. . |PE1|________+--+___/| x===x . PCE used
.............. +---+ |P3| | |PCE| . by all
. +--+ | x===x . AS0 nodes
. AS 0 +---+ .
..................|PE7|..........
+---+
Figure 5: Advanced Load Balancing
図5：高度な負荷分散
This is a common problem for providers and customers alike. Analysis of Netflow records, see [IRSCP], for a large ISP network on a typical day has shown that for 71.8% of multi-homed customers, there is a complete imbalance, where the most loaded link carries all the traffic and the least loaded link carries none.
これは、プロバイダーと顧客にとっても一般的な問題です。Netflow Recordsの分析、[IRSCP]を参照してください。典型的な1日の大規模なISPネットワークについては、マルチホームの顧客の71.8％には、最も負荷のないリンクがすべてのトラフィックを運ぶ完全な不均衡があり、ロードされていない完全な不均衡があることが示されています。リンクにはありません。
PCE policies can address this problem by basing the routing decision at the ingress routers on the offered load towards the multi-homed customer. For example, in Figure 5, PCE policies could be configured such that traffic load is monitored (e.g., based on Netflow data) at ingress routers PE3 to PE7 towards the data center prefixes served by egress routers PE1 and PE2. Using this offered load information, the path computations returned by PCE, based on the enabled PCE policies, can direct traffic to the appropriate egress router, on a per-ingress router basis. For example, the PCE path computation might direct traffic from both PE4 and PE5 to egress PE1, thus overriding the default IGP based selection. Alternatively, traffic from each ingress router to each egress link could be split 50-50.
PCEポリシーは、マルチホームの顧客に向けて提供された負荷のイングレスルーターにルーティング決定に基づいて、この問題に対処できます。たとえば、図5では、EgressルーターPE1およびPE2が提供するデータセンタープレフィックスに向けて、IngressルーターPE3からPE3へのトラフィック負荷が監視されるように、PCEポリシーを構成することができます。この提供された負荷情報を使用して、有効なPCEポリシーに基づいてPCEによって返されるパス計算は、履行者ごとのルーターベースで適切な出力ルーターにトラフィックを向けることができます。たとえば、PCEパス計算は、PE4とPE5の両方からトラフィックを誘導してPE1を出力し、デフォルトのIGPベースの選択をオーバーライドする可能性があります。または、各侵入ルーターから各出口リンクへのトラフィックを50〜50に分割できます。
This scenario is a good example of how a policy-governed PCE can account for some information that was not or cannot be advertised as TE link/node attributes, and, therefore, cannot be subject for explicit path computation constraints. More generally, such information can be pretty much anything. For example, traffic demand forecasts, flow monitoring feedback, any administrative policies, etc. Further examples are described in [IRSCP] of how PCE policies might address certain network routing problems, such as selective distributed denial-of-service (DDoS) blackholing, planned maintenance, and VPN gateway selection.
このシナリオは、ポリシーガバーンPCEがTEリンク/ノード属性として宣伝されていない、または宣伝できないいくつかの情報をどのように説明できるかの良い例であり、したがって、明示的なパス計算制約の対象となることはできません。より一般的には、そのような情報はほとんど何でもかまいません。たとえば、トラフィックの需要予測、フロー監視フィードバック、管理ポリシーなど。PCEポリシーが選択的分布拒否拒否（DDOS）ブラックホリングなどの特定のネットワークルーティングの問題に対処する方法の[IRSCP]で説明されています。計画されたメンテナンス、およびVPNゲートウェイの選択。
Example of policy: for(all traffic flows destined to Customer Network) if(flow ingresses on PE3, PE4, or PE5) Route the flow over PE1. else Route the flow over PE2.
ポリシーの例：（すべてのトラフィックフローが顧客ネットワークに導かれる）の場合（PE3、PE4、またはPE5での流れが侵入する）FlowをPE1の上にルーティングします。それ以外の場合は、PE2の上の流れをルーティングします。
The following requirements must be addressed by mechanisms and protocols that enable policy-based control over path computation requests and decisions:
次の要件は、パスの計算要求と決定に対するポリシーベースの制御を可能にするメカニズムとプロトコルによって対処する必要があります。
- (G)MPLS path computation-specific The mechanisms must meet the policy-based control requirements specific to the problem of path computation using RSVP-TE as the signaling protocol on MPLS and GMPLS LSRs.
- （g）MPLS PATH計算固有のメカニズムは、MPLSおよびGMPLS LSRのシグナル伝達プロトコルとしてRSVP-TEを使用したパス計算の問題に固有のポリシーベースの制御要件を満たす必要があります。
- Support for non-(G)MPLS PCCs The mechanisms must be sufficiently generic to support non-(G)MPLS (LSR) clients such as a Network Management System (NMS), or network planner, etc.
- 非（g）MPLS PCCSのサポートメカニズムは、ネットワーク管理システム（NMS）やネットワークプランナーなどの非（G）MPLS（LSR）クライアントをサポートするのに十分な一般的でなければなりません。
- Support for many policies The mechanisms must include support for many policies and policy configurations. In general, the determination and configuration of viable policies are the responsibility of the service provider.
- 多くのポリシーのサポートメカニズムには、多くのポリシーとポリシー構成のサポートを含める必要があります。一般に、実行可能なポリシーの決定と構成は、サービスプロバイダーの責任です。
- Provision for monitoring and accounting information The mechanisms must include support for monitoring policy state and provide access information. In particular, mechanisms must provide usage and access information that may be used for accounting purposes.
- 監視および会計情報の提供メカニズムには、ポリシー状態の監視のサポートを含め、アクセス情報を提供する必要があります。特に、メカニズムは、会計目的で使用される可能性のある使用およびアクセス情報を提供する必要があります。
- Fault tolerance and recovery The mechanisms must include provisions for fault tolerance and recovery from failure cases such as failure of PCC/PCE PDPs, disruption in communication that separate a PCC/PCE PDP from its associated PCC/PCE PEPs.
- フォールトトレランスと回復メカニズムには、PCC/PCE PDPの故障、PCC/PCE PDPが関連するPCC/PCE PEPSを分離する通信の混乱などの失敗ケースからのフォールトトレランスおよび回復に関する規定を含める必要があります。
- Support for policy-ignorant nodes The mechanisms should not be mandatory for every node in a network. Policy-based path computation control may be enforced at a subset of nodes, for example, on boundary nodes within an administrative domain. These policy-capable nodes will function as trusted nodes from the point of view of the policy-ignorant nodes in that administrative domain. Alternatively, policy may be applied solely on PCEs with all PCCs being policy-ignorant nodes.
- ポリシーに固有のノードのサポートメカニズムは、ネットワーク内のすべてのノードに対して必須であってはなりません。ポリシーベースのパス計算制御は、たとえば、管理ドメイン内の境界ノードのノードのサブセットで実施される場合があります。これらのポリシー対応ノードは、その管理ドメインにおけるポリシーに無敵のノードの観点から信頼できるノードとして機能します。あるいは、ポリシーは、すべてのPCCがポリシー無視ノードであるPCEにのみ適用される場合があります。
- Scalability One of the important requirements for the mechanisms is scalability. The mechanisms must scale at least to the same extent that RSVP-TE signaling scales in terms of accommodating multiple LSPs and network nodes in the path of an LSP. There are several sensitive areas in terms of scalability of policy-based path computation control. First, not every policy-aware node in an infrastructure should be expected to contact a remote PDP. This would cause potentially long delays in verifying requests. Additionally, the policy control architecture must scale at least as well as RSVP-TE protocol based on factors such as the size of RSVP-TE messages, the time required for the network to service an RSVP-TE request, local processing time required per node, and local memory consumed per node. These scaling considerations are of particular importance during re-routing of a set of LSPs.
- スケーラビリティメカニズムの重要な要件の1つは、スケーラビリティです。メカニズムは、少なくともLSPの経路で複数のLSPとネットワークノードを収容するという点で、RSVP-TEシグナル伝達スケールと同じ程度までスケーリングする必要があります。ポリシーベースのパス計算制御のスケーラビリティに関しては、いくつかの機密領域があります。まず、インフラストラクチャ内のすべてのポリシー認識ノードがリモートPDPに連絡すると予想されるわけではありません。これにより、リクエストの確認が潜在的に長い遅延が発生します。さらに、ポリシー制御アーキテクチャは、RSVP-TEメッセージのサイズ、ネットワークがRSVP-TE要求をサービスするために必要な時間、ノードごとのローカル処理時間などの要因に基づいて、少なくともRSVP-TEプロトコルをスケーリングする必要があります。、およびノードごとに消費されるローカルメモリ。これらのスケーリングの考慮事項は、LSPのセットの再ルーティング中に特に重要です。
- Security and denial-of-service considerations The policy control architecture, protocols, and mechanisms must be secure as far as the following aspects are concerned:
- セキュリティとサービスの拒否に関する考慮事項ポリシー管理アーキテクチャ、プロトコル、およびメカニズムは、次の側面に関する限り安全でなければなりません。
o First, the mechanisms proposed must minimize theft and denial-of-service threats.
o まず、提案されたメカニズムは、盗難とサービスの脅威を最小限に抑える必要があります。
o Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating.
o 第二に、政策管理に関与するエンティティ（PEPやPDPなど）が、通信する前に互いの身元を検証し、必要な信頼を確立できるようにする必要があります。
- Inter-AS and inter-area requirements There are several inter-AS policy-related requirements discussed in [RFC4216] and [RFC5376], and inter-area policy-related requirements discussed in [RFC4927]. These requirements must be addressed by policy-enabled PCE mechanisms and protocols.
- AS間およびエリア間の要件[RFC4216]および[RFC5376]で議論されているいくつかのポリシー関連要件と、[RFC4927]で議論されているエリア間のポリシー関連の要件があります。これらの要件は、ポリシー対応のPCEメカニズムとプロトコルによって対処する必要があります。
It should be noted that this document only outlines the communication elements and mechanisms needed to allow a wide variety of possible policies to be applied for path computation control. It does not include any discussion of any specific policy behavior, nor does it define or require use of specific policies.
このドキュメントは、さまざまな可能なポリシーをパス計算制御に適用できるようにするために必要な通信要素とメカニズムのみを概説していることに注意する必要があります。特定のポリシー行動に関する議論は含まれておらず、特定のポリシーの使用を定義または必要としません。
The Policy Core Information Model (PCIM) introduced in [RFC3060] and expanded in [RFC3460] presents the object-oriented information model for representing general policy information.
[RFC3060]で導入され、[RFC3460]で拡張されたポリシーコア情報モデル（PCIM）は、一般的なポリシー情報を表すためのオブジェクト指向の情報モデルを提示します。
This model defines two hierarchies of object classes:
このモデルは、オブジェクトクラスの2つの階層を定義します。
- Structural classes representing policy information and control of policies.
- ポリシー情報とポリシーの制御を表す構造クラス。
- Association classes that indicate how instances of the structural classes are related to each other.
- 構造クラスのインスタンスが互いにどのように関連しているかを示す関連クラス。
These classes can be mapped to various concrete implementations, for example, to a directory that uses Lightweight Directory Access Protocol version 3 (LDAPv3) as its access protocol.
これらのクラスは、たとえば、さまざまな具体的な実装に、Lightweight Directory Access Protocolバージョン3（LDAPV3）をアクセスプロトコルとして使用するディレクトリにマッピングできます。
Figure 6 shows an abstract from the class inheritance hierarchy for PCIM.
図6は、PCIMのクラス継承階層からの要約を示しています。
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicySet (abstract)
| | |
| | +---PolicyGroup
| | |
| | +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| | |
| | +---SimplePolicyCondition
| | |
| | +---CompoundPolicyCondition
| | |
| | +---CompoundFilterCondition
| |
| +---PolicyAction (abstract)
| | |
| | +---VendorPolicyAction
| | |
| | +---SimplePolicyAction
| | |
| | +---CompoundPolicyAction
| |
| +---PolicyVariable (abstract)
| | |
| | +---PolicyExplicitVariable
| | |
| | +---PolicyImplicitVariable
| | |
| | +---(subtree of more specific classes)
| |
| +---PolicyValue (abstract)
| |
| +---(subtree of more specific classes)
Figure 6: PCIM Class Inheritance
図6：PCIMクラスの継承
The policy classes and associations defined in PCIM are sufficiently generic to allow them to represent policies related to anything.
PCIMで定義されているポリシークラスと協会は、あらゆるものに関連するポリシーを表すことができるほど十分に汎用的です。
Policy models for application-specific areas such as the Path Computation Service may extend the PCIM in several ways. The preferred way is to use the PolicyGroup, PolicyRule, and PolicyTimePeriodCondition classes directly as a foundation for representing and communicating policy information. Then, specific subclasses derived from PolicyCondition and PolicyAction can capture application-specific definitions of conditions and actions of policies.
パス計算サービスなどのアプリケーション固有の領域のポリシーモデルは、いくつかの方法でPCIMを拡張する場合があります。好みの方法は、ポリシーグループ、PolicyTirule、およびPolicyTimeperiodConditionクラスを、ポリシー情報を表現および伝達するための基盤として直接使用することです。次に、PolicyconditionとPolicationから派生した特定のサブクラスは、ポリシーの条件とアクションのアプリケーション固有の定義をキャプチャできます。
The Policy Quality of Service Information Model [RFC3644] further extends the PCIM to represent QoS policy information for large-scale policy domains. New classes introduced in this document describing QoS- and RSVP-related variables, conditions, and actions can be used as a foundation for the PCPIM.
ポリシーサービス情報モデル[RFC3644]は、PCIMをさらに拡張して、大規模なポリシードメインのQoSポリシー情報を表すようにします。QoSおよびRSVP関連の変数、条件、およびアクションを説明するこのドキュメントで導入された新しいクラスは、PCPIMの基礎として使用できます。
Detailed description of the PCPIM will be provided in a separate document.
PCPIMの詳細な説明は、別のドキュメントで提供されます。
The following components are defined as part of the framework to support policy-enabled path computation:
次のコンポーネントは、ポリシー対応のパス計算をサポートするフレームワークの一部として定義されています。
- PCE Policy Repository A database from which PCE policies are available in the form of instances of PCPIM classes. PCE Policies are configured and managed by PCE Policy Management Tools;
- PCEポリシーリポジトリPCPIMクラスのインスタンスの形でPCEポリシーが利用可能なデータベース。PCEポリシーは、PCEポリシー管理ツールによって構成および管理されています。
- PCE Policy Decision Point (PCE-PDP) A logical entity capable of retrieving relevant path computation policies from one or more Policy Repositories and delivering the information to associated PCE-PEP(s);
- PCEポリシー決定ポイント（PCE-PDP）1つ以上のポリシーリポジトリから関連するパス計算ポリシーを取得し、関連するPCE-PEPに情報を配信できる論理エンティティ。
- PCE Policy Enforcement Point (PCE-PEP) A logical entity capable of issuing device-specific Path Computation Engine configuration requests for the purpose of enforcing the policies;
- PCEポリシー施行ポイント（PCE-PEP）ポリシーを施行する目的で、デバイス固有のパス計算エンジン構成要求を発行できる論理エンティティ。
- PCC Policy Decision Point (PCC-PDP) A logical entity capable of retrieving relevant path computation policies from one or more Policy Repositories and delivering the information to associated PCC-PEP(s);
- PCCポリシー決定ポイント（PCC-PDP）1つ以上のポリシーリポジトリから関連するパス計算ポリシーを取得し、関連するPCC-PEP（s）に情報を配信できる論理的エンティティ。
- PCC Policy Enforcement Point (PCC-PEP) A logical entity capable of issuing device-specific Path Computation Service User configuration requests for the purpose of enforcing the policies.
- PCCポリシー施行ポイント（PCC-PEP）ポリシーを施行する目的で、デバイス固有のパス計算サービスユーザー構成要求を発行できる論理エンティティ。
From the policy perspective a PCC is logically decomposed into two parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located with a Path Computation Service User entity that requires remote path computation (for example, the GMPLS control plane of an LSR). The PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) or separated. In the latter case, they talk to each other via such protocols as SOAP [W3CSOAP] or BEEP [RFC3080].
ポリシーの観点から、PCCは論理的に2つの部分に分解されます：PCC-PDPとPCC-PEP。存在する場合、PCC-PEPは、リモートパス計算（たとえば、LSRのGMPLSコントロールプレーン）を必要とするPATH計算サービスユーザーエンティティと共同で配置されます。PCC-PEPとPCC-PDPは、物理的に共同配置されている場合があります（[RFC2748]に従って）または分離します。後者の場合、彼らはSOAP [W3CSOAP]またはビープ音[RFC3080]などのプロトコルを介して互いに話し合います。
Likewise, a PCE is logically decomposed into two parts: PCE-PEP and PCE-PDP. When present, PCE-PEP is co-located with a Path Computation Engine entity that actually provides the Path Computation Service (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may be physically co-located or separated. In the later case, they communicate using such protocols as SOAP and/or BEEP.
同様に、PCEは論理的に2つの部分に分解されます：PCE-PEPとPCE-PDP。存在する場合、PCE-PEPは、実際にパス計算サービスを提供するパス計算エンジンエンティティ（つまり、パス計算アルゴリズムを実行します）と共同で配置されます。PCE-PEPおよびPCE-PDPは、物理的に共同配置または分離されている場合があります。後の場合、彼らはそのようなプロトコルを石鹸やビープ音などのプロトコルを使用して通信します。
PCC-PDP/PCE-PDP may be co-located with, or separated from, an associated PCE Policy Repository. In the latter case, the PDPs use some access protocol (for example, LDAPv3 or SNMP). The task of PDPs is to retrieve policies from the repository (or repositories) and convey them to respective PEPs either in an unsolicited way or upon the PEP's requests.
PCC-PDP/PCE-PDPは、関連するPCEポリシーリポジトリと共同で、または分離される場合があります。後者の場合、PDPはいくつかのアクセスプロトコル（たとえば、LDAPV3またはSNMP）を使用します。PDPのタスクは、リポジトリ（またはリポジトリ）からポリシーを取得し、未承諾の方法またはPEPの要求に応じて、それぞれのPEPにそれらを伝えることです。
A PCC-PEP may receive policy information not only from PCC-PDP(s) but also from PCE-PEP(s) via PCC-PCE communication and/or PCE discovery protocols. Likewise, a PCE-PEP may receive policy information not only from PCE-PDP(s) but also from PCC-PEP(s), via the PCC-PCE communication protocol [PCEP].
PCC-PEPは、PCC-PDP（S）からだけでなく、PCC-PCE通信および/またはPCEディスカバリープロトコルを介してPCE-PEPからポリシー情報を受け取る場合があります。同様に、PCE-PEPは、PCC-PCE通信プロトコル[PCEP]を介して、PCC-PDPだけでなく、PCC-PEP（S）からポリシー情報を受け取る場合があります。
Any given policy can be interpreted (that is, translated into a sequence of concrete device specific configuration requests) either on a PDP or on the associated PEP or partly on the PDP and partly on the PEP.
特定のポリシーは、PDPまたは関連するPEPで、またはPDP上および部分的にPEPで、すべてのポリシーを解釈できます（つまり、コンクリートデバイス固有の構成要求のシーケンスに変換されます）。
Generally speaking, the task of the PCC-PEP is to select the PCE and build path computation requests applying service-specific policies provided by the PCC-PDP. The task of the PCE-PEP is to control path computations by applying request-specific policies found in the requests as well as client-specific and domain-specific policies supplied by the PCE-PDP.
一般的に言えば、PCC-PEPのタスクは、PCC-PDPが提供するサービス固有のポリシーを適用するPCEを選択し、パス計算要求を構築することです。PCE-PEPのタスクは、PCE-PDPが提供するクライアント固有およびドメイン固有のポリシーと同様に、リクエストにあるリクエスト固有のポリシーを適用することにより、パス計算を制御することです。
The PCE policy architecture supports policy being applied at a PCC and at a PCE. While the architecture supports policy being applied at both, there is no requirement for policy to always be applied at both, or even at either. The use of policy in a network, on PCCs, and on PCEs, is a specific network design choice. Some networks may choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure 8), and others at both PCCs and PCEs (Figure 9). Regardless of where policy is applied, it must be applied in a consistent fashion in order to achieve the intended results.
PCEポリシーアーキテクチャは、PCCおよびPCEで適用されるポリシーをサポートしています。アーキテクチャは両方で適用されるポリシーをサポートしていますが、ポリシーが常に両方、またはどちらでも適用される必要はありません。ネットワーク、PCCS、およびPCESでのポリシーの使用は、特定のネットワーク設計の選択です。一部のネットワークは、PCCS（図7）、PCS（図8）でのみポリシーを適用することを選択する場合があります。ポリシーが適用される場所に関係なく、意図した結果を達成するためには、一貫した方法で適用する必要があります。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy -----------------------
| PCC-PDP |<--------- | PCE Policy Repository |
--------- -----------------------
^
| e.g., SOAP
v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol ---------
Figure 7: Policies Applied on PCC Only
図7：PCCのみに適用されるポリシー
Along with supporting flexibility in where policy may be applied, the PCE architecture is also flexible in terms of where specific types of policies may be applied. Also, the PCE architecture allows for the application of only a subset of policy types. [RFC4655] defines several PC policy types. Each of these may be applied at either a PCC or a PCE or both. Clearly, when policy is only applied at PCCs or at PCEs, all PCE policy types used in the network must be applied at those locations.
ポリシーを適用できる場所での柔軟性をサポートすることに加えて、PCEアーキテクチャは、特定の種類のポリシーを適用できる場所に関しても柔軟です。また、PCEアーキテクチャにより、ポリシータイプのサブセットのみを適用できます。[RFC4655]は、いくつかのPCポリシータイプを定義します。これらのそれぞれは、PCCまたはPCE、またはその両方で適用できます。明らかに、ポリシーがPCCSまたはPCESでのみ適用される場合、ネットワークで使用されるすべてのPCEポリシータイプをそれらの場所に適用する必要があります。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
----------------------- Policy ---------
| PCE Policy Repository | -------->| PCE-PDP |
----------------------- ---------
^
e.g., SOAP |
v
--------- PCEP ---------
| PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 8: Policies Applied on Only
図8：適用されるポリシーのみ
In the case where policy is only applied at a PCE, it is expected that the PCC will pass to the PCE all information about the service that it can gather in the path computation request (most likely in the form of PCPIM policy variables). The PCE is expected to understand this information and apply appropriate policies while defining the actual parameters of the path computation to be performed. Note that in this scenario, the PCC cannot apply server-specific or any other policies, and PCE selection is static.
ポリシーがPCEでのみ適用される場合、PCCはPATH計算リクエストで収集できるサービスに関するすべての情報にPCCに渡されることが予想されます（PCPIMポリシー変数の形式で最も可能性が高い）。PCEは、この情報を理解し、適切なポリシーを適用しながら、実行するパス計算の実際のパラメーターを定義することが期待されています。このシナリオでは、PCCはサーバー固有またはその他のポリシーを適用できず、PCE選択は静的であることに注意してください。
When applying policy at both the PCC and PCE, it is necessary to select which types of policies are applied at each. In such configurations, it is likely that the application of policy types will be distributed across the PCC and PCE rather than applying all of them at both. For example, user-specific and server-specific policies may be applied at a PCC, request- and client-specific policies may be applied at a PCE, while domain-specific policies may be applied at both the PCC and PCE.
PCCとPCEの両方でポリシーを適用する場合、それぞれに適用されるポリシーの種類を選択する必要があります。このような構成では、ポリシータイプのアプリケーションが両方ですべてを適用するのではなく、PCCとPCEに分配される可能性があります。たとえば、ユーザー固有およびサーバー固有のポリシーはPCCで適用される場合があり、PCCとPCCとPCCの両方でドメイン固有のポリシーが適用される場合があります。
In the case when policy is only applied at a PCC, the PCC must apply all the types of required policies, for example user-, service-, server-, and domain-specific policies. The PCC uses the policies to construct a path computation request that appropriately represents the applied policies. The request will necessarily be limited to the set of "basic" (that is, non-policy capable) constraints explicitly defined by the PCC-PCE communication protocol.
ポリシーがPCCでのみ適用される場合、PCCは、ユーザー、サービス、サーバー、およびドメイン固有のポリシーなど、必要なすべてのタイプのポリシーを適用する必要があります。PCCは、ポリシーを使用して、適用されたポリシーを適切に表すパス計算要求を作成します。リクエストは、必然的に、PCC-PCE通信プロトコルによって明示的に定義された「基本」（つまり、非ポリシー対応）制約のセットに限定されます。
Within the policy-enabled path computation framework policy repositories may be used in a single or multiple PCE policy repository configuration:
ポリシー対応のパス計算フレームワークポリシーリポジトリは、単一または複数のPCEポリシーリポジトリ構成で使用できます。
o) Single PCE Policy Repository
o) 単一のPCEポリシーリポジトリ
In this configuration, there is a single PCE Policy Repository shared between PCCs and PCEs.
この構成には、PCCとPCEの間で共有される単一のPCEポリシーリポジトリがあります。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 9: Single PCC/PCE Policy Repository
図9：単一のPCC/PCEポリシーリポジトリ
o) Multiple PCE Policy Repositories
o) 複数のPCEポリシーリポジトリ
The repositories in this case may be fully or partially synchronized by some discovery/synchronization management protocol or may be completely independent. Note that the situation when PCE Policy Repository A exactly matches PC Policy Repository B, results in the single PCE Policy Repository configuration case.
この場合のリポジトリは、いくつかの発見/同期管理プロトコルによって完全または部分的に同期される場合があるか、完全に独立している場合があります。PCEポリシーリポジトリAがPCポリシーリポジトリBと正確に一致する状況は、単一のPCEポリシーリポジトリ構成のケースになることに注意してください。
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCC-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 10: Multiple PCE/PCC Policy Repositories
図10：複数のPCE/PCCポリシーリポジトリ
The previous section shows the relationship between PCCs and PCEs. A parallel relationship exists between cooperating PCEs, and, in fact, this relationship can be viewed as the same as the relationship between PCCs and PCEs. The one notable difference is that there will be cases where having a shared PCE Policy Repository will not be desirable, for example, when the PCEs are managed by different entities. Note that in this case, it still remains necessary for the policies to be consistent across the domains in order to identify usable paths. The other notable difference is that a PCE, while processing a path computation request, may need to apply requester-specific (that is, client-specific) policies in order to modify the request before sending it to other cooperating PCE(s). This relationship is particularly important as the PCE architecture allows for configuration where all PCCs are not policy-enabled.
前のセクションでは、PCCとPCESの関係を示しています。協力PCEの間には並行関係が存在し、実際、この関係はPCCとPCEの関係と同じと見なすことができます。注目すべき違いの1つは、PCEが異なるエンティティによって管理されている場合など、共有PCEポリシーリポジトリを共有することが望ましくない場合があることです。この場合、使用可能なパスを特定するために、ポリシーがドメイン全体で一貫している必要があることに注意してください。もう1つの顕著な違いは、PCHがパス計算リクエストの処理中に、リクエストを協力するPCE（s）に送信する前にリクエストを変更するために、リクエスター固有の（クライアント固有の）ポリシーを適用する必要がある可能性があることです。この関係は、すべてのPCCがポリシー対応ではない構成を許可するため、特に重要です。
The following are example configurations. These examples do not represent an exhaustive list and other configurations are expected.
以下は構成の例です。これらの例は網羅的なリストを表しておらず、他の構成が予想されます。
o) Single Policy Repository
o) 単一のポリシーリポジトリ
In this configuration, there is a single PCE Policy Repository shared between PCEs. This configuration is likely to be useful within a single administrative domain where multiple PCEs are provided for redundancy or load distribution purposes.
この構成には、PCE間で共有される単一のPCEポリシーリポジトリがあります。この構成は、冗長または負荷分布の目的で複数のPCEが提供される単一の管理ドメイン内で有用である可能性があります。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol ---------
Figure 11: Single PCC Policy Repository
図11：単一のPCCポリシーリポジトリ
o) Multiple Policy Repositories
o) 複数のポリシーリポジトリ
The repositories in this case may be fully or partially synchronized by some discovery/synchronization management protocol(s) or may be completely independent. In the multi-domain case, it is expected that the repositories will be distinct, providing, however, consistent policies.
この場合のリポジトリは、いくつかの発見/同期管理プロトコルによって完全または部分的に同期される場合があるか、完全に独立している場合があります。マルチドメインの場合、リポジトリは明確になり、一貫したポリシーを提供することが予想されます。
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCE-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 12: Multiple PCC Policy Repositories
図12：複数のPCCポリシーリポジトリ
The management of path computation policy information used by PCCs and PCEs is largely out of scope of the described framework. The framework assumes that such information is installed, removed, and otherwise managed using typical policy management techniques. Policy Repositories may be populated and managed via static configuration, standard and proprietary policy management tools, or even dynamically via policy management/discovery protocols and applications.
PCCSおよびPCESが使用するPATH計算ポリシー情報の管理は、記載されているフレームワークの範囲外です。このフレームワークは、そのような情報が典型的なポリシー管理手法を使用してインストール、削除、およびその他の方法で管理されることを想定しています。ポリシーリポジトリは、静的な構成、標準および独自のポリシー管理ツールを介して、またはポリシー管理/発見プロトコルとアプリケーションを介して動的にも存在し、管理される場合があります。
Flexibility in the application of policy types is imperative from the architecture perspective. However, this commodity implies added complexity on the part of the PCE-related communication protocols.
ポリシータイプの適用における柔軟性は、アーキテクチャの観点からも不可欠です。ただし、この商品は、PCE関連の通信プロトコルの側面に複雑さが追加されることを意味します。
One added complexity is that PCE communication protocols must carry certain information to support various policy types that may be applied. For example, in the case where policy is only applied at a PCE, a PCC-PCE request must carry sufficient information for the PCE to apply service- or user-specific policies. This does imply that a PCC must have sufficient understanding of what policies can be applied at the PCE. Such information may be obtained via local configuration, static coding, or even via a PCE discovery mechanism. The PCC must also have sufficient understanding to properly encode the required information for each policy type.
複雑さの1つは、PCE通信プロトコルが適用される可能性のあるさまざまなポリシータイプをサポートするために特定の情報を運ぶ必要があることです。たとえば、ポリシーがPCEでのみ適用される場合、PCC-PCEリクエストは、サービスまたはユーザー固有のポリシーを適用するためにPCEに十分な情報を提供する必要があります。これは、PCCがPCEでどのポリシーを適用できるかを十分に理解している必要があることを意味します。このような情報は、ローカル構成、静的コーディング、またはPCE発見メカニズムを介して取得できます。また、PCCは、各ポリシータイプに必要な情報を適切にエンコードするのに十分な理解を持っている必要があります。
Another added complexity is that PCE communication protocols must also be able to carry information that may result from a policy decision. For example, user- or service-specific policy applied at a PCC may result in policy-related information that must be carried along with the request for use by a PCE. This complexity is particularly important as it may be used to introduce new path computation parameters (e.g., constraints, objection functions, etc.) without modification of the core PCC and PCE. This communication will likely simply require the PCE communication protocols to support opaque policy-related information elements.
別の追加された複雑さは、PCE通信プロトコルもポリシー決定から生じる可能性のある情報を運ぶことができなければならないことです。たとえば、PCCに適用されるユーザーまたはサービス固有のポリシーにより、PCEによる使用の要求とともに実施する必要があるポリシー関連の情報が得られる場合があります。この複雑さは、コアPCCとPCEを変更せずに新しいパス計算パラメーター（制約、異議機能など）を導入するために使用される可能性があるため、特に重要です。この通信は、不透明なポリシー関連情報要素をサポートするために、PCE通信プロトコルが単に必要とする可能性が高いでしょう。
A final added complexity is that PCE communication protocols must also be able to support updated or unsolicited responses from a PCE. For example, changes in PCE policy may force a change to a previously provided path. Such updated or unsolicited responses may contain information that the PCC must act on, and may contain policy information that must be provided to a PCC.
最後に追加された複雑さは、PCE通信プロトコルがPCEからの更新または未承諾の応答をサポートできる必要があることです。たとえば、PCEポリシーの変更により、以前に提供されたパスへの変更が強制される場合があります。このような更新または未承諾の回答には、PCCが行動する必要がある情報が含まれている場合があり、PCCに提供する必要があるポリシー情報が含まれている場合があります。
PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request-response type PCC-PCE Communication Protocol, i.e., [PCEP]. This document makes no assumptions as to what exact protocol is used to support this communication. This document does assume that the semantics of a path computation request are sufficiently abstract and general, and support both PCE-PCC and PCE-PCE communication.
PCC-PEPとPCE-PEPまたはPCE-PEPのペアは、リクエスト応答タイプのPCC-PCE通信プロトコル、つまり[PCEP]を介して通信します。このドキュメントは、この通信をサポートするために使用される正確なプロトコルについての仮定を行いません。このドキュメントでは、パス計算要求のセマンティクスは十分に抽象的かつ一般的であると想定しており、PCE-PCCとPCE-PCE通信の両方をサポートしています。
From a policy perspective, a path computation request should include at a minimum:
ポリシーの観点から見ると、パス計算要求には少なくとも以下を含める必要があります。
o One or more source addresses; o One or more destination addresses; o Computation type (P2P (point to point), P2MP (point to multipoint), MP2P (multipoint to point), etc.); o Number of required paths; o Zero or more policy descriptors in the following format: <policy name>, <policy variable1 name>, <param11>, <param12>,...,<param1N> <policy variable2 name>, <param21>, <param12>,...,<param2N> ... <policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>
o 1つ以上のソースアドレス。o 1つ以上の宛先アドレス。o計算タイプ（P2P（ポイントトゥポイント）、P2MP（マルチポイントへのポイント）、MP2P（マルチポイントからポイント）など）;o必要なパスの数。o次の形式のゼロ以上のポリシー記述子：<ポリシー名>、<ポリシー変数名>、<param11>、<param12>、...、<param1n> <ポリシー変数名>、<param21>、<param12>、...、<param2n> ... <ポリシー変動名>、<paramm1>、<paramm2>、...、<parammn>
A successful path computation response, at minimum, should include the list of computed paths and may include policies (in the form of policy descriptors as in path computation request, see above) for use in evaluating and otherwise applying the computed paths.
成功したパス計算応答には、少なくとも計算されたパスのリストを含める必要があり、計算されたパスの評価と適用に使用するために、ポリシー（上記を参照）を含めることができます。
PCC-PCE Communication Protocol provides transport for policy information and should not understand nor make any assumptions about the semantics of policies specified in path computation requests and responses.
PCC-PCE通信プロトコルは、ポリシー情報の輸送を提供し、パスの計算要求と応答で指定されたポリシーのセマンティクスについて理解したり、仮定したりするべきではありません。
Note: This document explicitly allows for (but does not require) the PCC to decide that all necessary constraints, objective functions, etc. pertinent to the computation of paths for the service in question are to be determined by the PCE performing the computation. In this case, the PCC will use a set of policies (more precisely, PCPIM policy variables) describing the service-specific information. These policies may be placed within the path computation request and delivered to the PCE via a PCC-PCE communication protocol such as [PCEP]. The PCE (more precisely, PCE-PEP) is expected to understand this information and use it to determine the constraints and optimization functions applying local policies (that is, policies locally configured or provided by the associated PCE-PDP(s)).
注：このドキュメントでは、問題のサービスのパスの計算に関連するすべての必要な制約、目的関数などが、計算を実行するPCEによって決定されることをPCCが決定することがPCCを明示的に許可しています（ただし要求しません）。この場合、PCCは、サービス固有の情報を説明する一連のポリシー（より正確にはPCPIMポリシー変数）を使用します。これらのポリシーは、パス計算要求内に配置され、[PCEP]などのPCC-PCE通信プロトコルを介してPCEに配信される場合があります。PCE（より正確には、PCE-PEP）はこの情報を理解し、それを使用して、ローカルポリシー（つまり、関連するPCE-PDP（S）によってローカルに構成または提供されるポリシー）を適用する制約と最適化関数を決定することが期待されます。
Dynamic PCE discovery allows for PCCs and PCEs to automatically discover a set of PCEs (including information required for the PCE selection). It also allows for PCCs and PCEs to dynamically detect new PCEs or any modification of PCEs status. Policy can be applied in two ways in this context:
動的なPCE発見により、PCCSとPCESがPCEのセット（PCE選択に必要な情報を含む）を自動的に発見することができます。また、PCCSとPCESが新しいPCESまたはPCESステータスの変更を動的に検出することもできます。このコンテキストでは、ポリシーを2つの方法で適用できます。
1. Restricting the scope of information distribution for the mandatory set of information (in particular the PCE presence and location).
1. 必須の情報セット（特にPCEの存在と場所）の情報分布の範囲を制限します。
2. Restricting the type and nature of the optional information distributed by the discovery protocol. The latter is also subject to policy since the PCE architecture allows for distributing this information using either PCE discovery protocol(s) or PCC-PCE communication protocol(s). One important policy decision in this context is the nature of the information to be distributed, especially, when this information is not strictly speaking "discovery" information, rather, the PCE state changes. Client-specific and domain-specific policies may be applied when deciding whether this information should be distributed and to which clients of the path computation service (that is, which PCCs and/or PCEs).
2. ディスカバリープロトコルによって配布されたオプションの情報のタイプと性質を制限します。後者は、PCEアーキテクチャがPCE Discovery ProtocolまたはPCC-PCE通信プロトコルのいずれかを使用してこの情報を配信できるため、ポリシーの対象となります。この文脈における重要な政策決定の1つは、特にこの情報が厳密に「発見」情報を語っていない場合、PCE状態が変更されていない場合、配布される情報の性質です。クライアント固有のドメイン固有のポリシーは、この情報を配信する必要があるかどうか、およびパス計算サービスのクライアント（つまり、PCCおよび/またはPCES）のクライアントを決定する際に適用される場合があります。
Another place where policy applies is at the administrative boundaries. In multi-domain networks, multiple PCEs will communicate with each other and across administrative boundaries. In such cases, domain-specific policies would be applied to 1) filter the information exchanged between peering PCEs during the discovery process (to the bare minimum in most cases if at all allowed by the security policy) and 2) limit the content of information being passed in path computation request and responses.
ポリシーが適用される別の場所は、管理境界にあります。マルチドメインネットワークでは、複数のPCEが互いに、および管理境界を越えて通信します。そのような場合、ドメイン固有のポリシーは、1）発見プロセス中にピアリングPCE間で交換される情報をフィルタリングします（ほとんどの場合、セキュリティポリシーで許可されている場合はほとんどの場合）、2）情報の内容を制限します。パス計算要求と応答で渡されます。
This section presents a non-exhaustive list of representative scenarios.
このセクションでは、代表的なシナリオの非網羅的なリストを紹介します。
When a GMPLS LSR receives a Setup (RSVP Path) message from an upstream LSR, the LSR may decide to use a remote Path Computation Entity. The following sequence of events occurs in this case:
GMPLS LSRが上流のLSRからセットアップ（RSVPパス）メッセージを受信すると、LSRはリモートパス計算エンティティを使用することを決定する場合があります。この場合、次の一連のイベントが発生します。
- A PCC-PEP co-located with the LSR applies the service-specific policies to select a PCE for the service path computation as well as to build the path computation request (that is, to select a list of policies, their variables, conditions and actions expressing constraints, diversities, objective functions and relaxation strategies appropriate for the service path computation). The policies may be:
- LSRと共同住宅されたPCC-PEPは、サービスパス計算のPCEを選択するためにサービス固有のポリシーを適用し、パス計算リクエストを構築する（つまり、ポリシー、その変数、条件、および」のリストを選択するためにサービスパスの計算に適した制約、多様性、目的関数、リラクゼーション戦略を表すアクション）。ポリシーは次のとおりです。
a) Statically configured on the PCC-PEP;
a) PCC-PEPで静的に構成されています。
b) Communicated to the PCC-PEP by a remote or local PCC-PDP via protocol such as SOAP either proactively (most of the cases) or upon an explicit request by the PCC-PEP in cases when some specifics of the new service have not been covered yet by the policies so far known to the PCC-PEP).
b) SOAPなどのプロトコルを介してリモートまたはローカルPCC-PDPによってPCC-PEPに伝達されます（ほとんどの場合）または新しいサービスのいくつかの詳細がカバーされていない場合にPCC-PEPによる明示的な要求に応じてしかし、これまでPCC-PEPに知られているポリシーによって）。
The input for the decision process on the PCC-PEP is the information found in the signaling message as well as any other service-specific information such as port ID over which the message was received, associated VPN ID, the reference point type (UNI, E-NNI, etc.) and so forth. After the path computation request is built, it is sent directly to the PCE-PEP using the PCC-PCE Communication Protocol, e.g., [PCEP].
PCC-PEPの決定プロセスの入力は、シグナルメッセージに見られる情報と、メッセージが受信されたポートID、関連するVPN ID、参照ポイントタイプ（UNI、e-nniなど）など。PATH計算要求が構築された後、PCC-PCE通信プロトコル（PCEP]を使用してPCE-PEPに直接送信されます。
- PCE-PEP validates and otherwise processes the request applying the policies found in the request- as well as client- and domain-specific policies. The latter, again, may be either statically configured on the PCE-PEP or provided by the associated local or remote PCE-PDP via a protocol such as SOAP. The outcome of the decision process is the following information:
- PCE-PEPは、リクエストおよびドメイン固有のポリシーと同様に、リクエストで見つかったポリシーを適用するリクエストを検証および処理します。後者は、再び、PCE-PEPで静的に構成されているか、SOAPなどのプロトコルを介して関連するローカルまたはリモートPCE-PDPによって提供される場合があります。決定プロセスの結果は次の情報です。
a) Whether the request should be satisfied, rejected, or dismissed.
a) リクエストを満たすか、拒否するか、却下する必要があるかどうか。
b) The sets of sources and destinations for which paths should be locally computed.
b) パスをローカルで計算する必要があるソースと目的地のセット。
c) The set of constraints, diversities, optimization functions, and relaxations to be considered in each of locally performed path computation.
c) ローカルに実行されたパス計算のそれぞれで考慮される制約、多様性、最適化関数、および緩和のセット。
d) The address of the next-in-chain PCE.
d) チェーンの次のPCEのアドレス。
e) The path computation request to be sent to the next-in-chain PCE.
e) チェーン隣のPCEに送信されるパス計算要求。
The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using a PCC-PCE Communication Protocol. Then, it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths, and sends them back to the PCC-PEP using the PCC- PCE Communication Protocol. The response contains the resulting paths as well as policies describing some additional information (for example, which of constraints were honored, which were dismissed, and which were relaxed and in what way).
PCE-PEPは、共同配置されたパス計算エンジンにローカルパス計算を実行するよう指示し、必要に応じて、PCC-PCE通信プロトコルを使用してPATH In-Chain PCEにパス計算要求を送信します。次に、ローカルパス計算エンジンとリモートPCEからの応答を待機し、結果のパスを組み合わせて、PCC-PCE通信プロトコルを使用してPCC-PEPに送り返します。応答には、結果のパスと、いくつかの追加情報を説明するポリシーが含まれています（たとえば、どの制約が尊重され、却下され、リラックスしたもので、どのような方法でどのような制約がありましたか）。
- PCC-PEP instructs the signaling subsystem of the GMPLS LSR to encode the received path(s) into the outgoing Setup message(s).
- PCC-PEPは、GMPLS LSRの信号サブシステムに、受信パスを発信セットアップメッセージにエンコードするよう指示します。
This case parallels the previous example, but the user- and service-specific policies should be applied at the PCE as the PCC is policy ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) message from an upstream LSR, the LSR may decide to use a non-co-located Path Computation Entity. The following sequence of events occurs in this case:
このケースは前の例を類似していますが、PCCがポリシーに無知であるため、ユーザーおよびサービス固有のポリシーをPCEに適用する必要があります。繰り返しますが、GMPLS LSRが上流のLSRからセットアップ（RSVPパス）メッセージを受信した場合、LSRは非Co-Located Path計算エンティティを使用することを決定する場合があります。この場合、次の一連のイベントが発生します。
- The PCC constructs a PCE request using information found in the signaling/provisioning message as well as any other service-specific information such as port ID over which the message was received, associated VPN ID, the reference point type (UNI, E-NNI, etc.) and so forth. This information is encoded in the request in the form of policy variables. After the request is built, it is sent directly to the PCE-PEP using a PCC-PCE Communication Protocol.
- PCCは、信号/プロビジョニングメッセージにある情報と、メッセージが受信されたポートID、関連するVPN ID、参照ポイントタイプ（UNI、eNNI、（UNI、eNNI、）などのその他のサービス固有の情報を使用してPCE要求を構築します。など）など。この情報は、リクエストでポリシー変数の形式でエンコードされています。リクエストが作成された後、PCC-PCE通信プロトコルを使用してPCE-PEPに直接送信されます。
- PCE-PEP validates and otherwise processes the request interpreting the policy variables found in the request and applying user-, service-, client-, and domain-specific policies to build the actual path computation request. The policies, again, may be either statically configured on the PCE-PEP or provided by the associated local or remote PCE-PDP via a protocol such as SOAP. The outcome of the decision process is the following information:
- PCE-PEPは、リクエストで見つかったポリシー変数を解釈し、ユーザー、サービス、クライアント、およびドメイン固有のポリシーを適用して、実際のパス計算リクエストを構築するリクエストを検証および処理します。再び、ポリシーは、PCE-PEPで静的に構成されているか、SOAPなどのプロトコルを介して関連するローカルまたはリモートPCE-PDPによって提供される場合があります。決定プロセスの結果は次の情報です。
a) Whether the request should be satisfied, rejected, or dismissed.
a) リクエストを満たすか、拒否するか、却下する必要があるかどうか。
b) The sets of sources and destinations for which paths should be locally computed.
b) パスをローカルで計算する必要があるソースと目的地のセット。
c) The set of constraints, diversities, optimization functions, and relaxations to be considered in each of locally performed path computation.
c) ローカルに実行されたパス計算のそれぞれで考慮される制約、多様性、最適化関数、および緩和のセット。
d) The address of the next-in-chain PCE.
d) チェーンの次のPCEのアドレス。
e) The path computation request to be sent to the next-in-chain PCE.
e) チェーン隣のPCEに送信されるパス計算要求。
The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using the PCC-PCE Communication Protocol. Then, it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths, and sends them back to the PCC-PEP using the PCC-PCE Communication Protocol. The response contains the resulting paths as well as policies describing some additional information (for example, which of constraints were honored, which were dismissed, and which were relaxed and in what way)
PCE-PEPは、共同配置されたパス計算エンジンにローカルパス計算を実行するよう指示し、必要に応じて、PCC-PCE通信プロトコルを使用してパス計算リクエストをチェーン隣のPCEに送信します。次に、ローカルパス計算エンジンとリモートPCEからの応答を待ち、結果のパスを組み合わせて、PCC-PCE通信プロトコルを使用してPCC-PEPに送り返します。応答には、結果のパスと、いくつかの追加情報を説明するポリシーが含まれています（たとえば、どの制約が尊重され、却下され、リラックスしたもので、どのような方法でどのように制約がありましたか）
- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to encode the received path(s) into the outgoing Setup message(s).
- PCC-PEPは、GMPLS LSRの信号サブシステムに、受信パスを発信セットアップメッセージにエンコードするよう指示します。
An important aspect of the policy-enabled path computation framework discussed above is the ability to introduce new constraints with minimal impact. In particular, only those components and mechanisms that will use a new constraint need to be updated in order to support the new constraint. Importantly, those components and mechanisms that will not use the new constraint must not require any change in order for the new constraint to be utilized. For example, the PCE communication protocols must not require any changes to support new constraints. Likewise, PCC and PCEs that will not process new constraints must not require any modification.
上記で説明したポリシー対応のパス計算フレームワークの重要な側面は、最小限の影響で新しい制約を導入できることです。特に、新しい制約をサポートするために、新しい制約を使用するコンポーネントとメカニズムを更新する必要があります。重要なことに、新しい制約を使用しないコンポーネントとメカニズムは、新しい制約を利用するために変更を必要としない必要があります。たとえば、PCE通信プロトコルは、新しい制約をサポートするために変更を必要としないはずです。同様に、新しい制約を処理しないPCCおよびPCSは、変更を必要としないはずです。
Consider the case where a PCE has been upgraded with software supporting optical physical impairment constraint, such as Polarization Mode Dispersion (PMD), that previously was not supported in the domain. In this case, one or more new policies will be installed in the PCE Policy Repository (associated with the PCE) defining the constraint (rules that determine application criteria, set of policy variables, conditions, actions, etc.) and its relaxation strategy (or strategies). The new policies will be also propagated into other PCE Policy Repositories within the domain via discovery and synchronization protocols or via local configuration. PCE-PDPs and PCC-PDPs will then retrieve the corresponding policies from the repository (or repositories). From then on, PCC-PDPs will instruct associated PCC-PEPs to add the new policy information into path computation requests for services with certain parameters (for example, for services provisioned in the optical channel (OCh) layer).
以前はドメインでサポートされていなかった偏光モード分散（PMD）など、光学的障害の制約をサポートするソフトウェアでPCEがアップグレードされた場合を考えてみましょう。この場合、制約を定義するPCEポリシーリポジトリ（PCEに関連付けられている）に1つ以上の新しいポリシーがインストールされます（アプリケーション基準、ポリシー変数、条件、アクションなどのセットを決定するルール）およびその緩和戦略（または戦略）。新しいポリシーは、発見および同期プロトコルまたはローカル構成を介して、ドメイン内の他のPCEポリシーリポジトリにも伝播されます。PCE-PDPSおよびPCC-PDPSは、リポジトリ（またはリポジトリ）から対応するポリシーを取得します。それ以降、PCC-PDPSは、関連するPCC-PEPSに、特定のパラメーターを持つサービスのパス計算要求に新しいポリシー情報を追加するように指示します（たとえば、光チャネル（OCH）レイヤーで提供されたサービス）。
It is important to note that policy-enabled path computation model naturally solves the PCE capability discovery issues. Suppose a PCE working in a single PCE Policy Repository configuration starts to support a new constraint. Once a corresponding policy installed in the repository, it automatically becomes available for all repository users, that is, PCCs. In the multi-repository case some policy synchronization must be provided; however, this problem is one of the management plane which is solved already.
ポリシー対応のパス計算モデルは、PCE機能発見の問題を自然に解決することに注意することが重要です。単一のPCEポリシーリポジトリ構成で動作するPCEが新しい制約をサポートし始めるとします。リポジトリに対応するポリシーがインストールされると、すべてのリポジトリユーザー、つまりPCCSが自動的に使用できるようになります。マルチレポジトリのケースでは、いくつかのポリシー同期を提供する必要があります。ただし、この問題は、すでに解決されている管理プレーンの1つです。
This document adds to the policy security considerations mentioned in [RFC4655]. In particular, it is now necessary to consider the security issues related to policy information maintained in PCE Policy Repositories and policy-related transactions. The most notable issues, some of which are also listed in [RFC4655], are:
このドキュメントは、[RFC4655]に記載されている政策セキュリティ上の考慮事項に追加されます。特に、PCEポリシーリポジトリとポリシー関連トランザクションで維持されているポリシー情報に関連するセキュリティ問題を考慮する必要があります。[RFC4655]にもリストされている最も注目すべき問題は次のとおりです。
- Unauthorized access to the PCE Policy Repositories;
- PCEポリシーリポジトリへの不正アクセス。
- Interception of policy information when it is retrieved from the repositories and/or transported from PDPs to PEPs;
- ポリシー情報の傍受は、リポジトリから取得された場合、および/またはPDPからPEPSに輸送された場合。
- Interception of policy-related information in path computation requests and responses;
- パス計算要求と応答におけるポリシー関連情報の傍受。
o Impersonation of user and client identities;
o ユーザーおよびクライアントのアイデンティティのなりすまし。
o Falsification of policy information and/or PCE capabilities;
o ポリシー情報および/またはPCE機能の改ざん。
o Denial-of-service attacks on policy-related communication mechanisms.
o 政策関連のコミュニケーションメカニズムに対するサービス拒否攻撃。
As with [RFC4655], it is expected that PCE solutions will address the PCE aspects of these issues in detail.
[RFC4655]と同様に、PCEソリューションはこれらの問題のPCEの側面に詳細に対処することが予想されます。
Adrian Farrel contributed significantly to this document. We would like to thank Bela Berde for fruitful discussions on PBM and policy-driven path computation. We would also like to thank Kobus Van der Merwe for providing insights and examples regarding PCE policy applications.
Adrian Farrelはこの文書に大きく貢献しました。PBMとポリシー主導のパス計算に関する実り多い議論について、Bela Berdeに感謝します。また、PCEポリシーアプリケーションに関する洞察と例を提供してくれたKobus van der Merweに感謝します。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[RFC3060] Moore、B.、Ellesson、E.、Strassner、J。、およびA. Westerinen、「ポリシーコア情報モデル - バージョン1仕様」、RFC 3060、2001年2月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460] Moore、B.、ed。、「ポリシーコア情報モデル（PCIM）拡張機能」、RFC 3460、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[RFC3644] Snir、Y.、Ramberg、Y.、Strassner、J.、Cohen、R。、およびB. Moore、「ポリシーサービスの品質（QoS）情報モデル」、RFC 3644、2003年11月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R.、ed。、およびJ.-P。Vasseur、ed。、「MPLS Inter-autonomous System（AS）Traffic Engineering（TE）要件」、RFC 4216、2005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4927] Le Roux, J.-L., Ed., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4927] Le Roux、J.-L.、ed。、「Path Computation Element Communication Protocol（PCECP）エリア間MPLSおよびGMPLSトラフィックエンジニアリングの特定の要件」、RFC 4927、2007年6月。
[DMTF] Common Information Model (CIM) Schema, version 2.x. Distributed Management Task Force, Inc. The components of the CIM v2.x schema are available via links on the following DMTF web page: http://www.dmtf.org/standards/standard_cim.php.
[DMTF]共通情報モデル（CIM）スキーマ、バージョン2.x.分散管理タスクフォース、Inc。CIM V2.Xスキーマのコンポーネントは、次のDMTF Webページのリンクを介して利用できます：http：//www.dmtf.org/standards/standard_cim.php。
[IRSCP] Van der Merwe, J., et al., "Dynamic Connectivity Management with an Intelligent Route Service Control Point," ACM SIGCOMM Workshop on Internet Network Management (INM), Pisa, Italy, September 11, 2006.
[IRSCP] Van Der Merwe、J.、et al。、「インテリジェントルートサービスコントロールポイントを備えた動的接続管理」、ACM Sigcomm Workshop on Internet Network Management（INM）、PISA、イタリア、2006年9月11日。
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", Work in Progress, November 2008.
[PCEP] Vasseur、jp。、ed。とjl。Le Roux、ed。、「Path Computation Element（PCE）通信プロトコル（PCEP）」、Work in Progress、2008年11月。
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748] Durham、D.、Ed。、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、2000年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J。、およびS。Waldbusser、「政策ベースの管理の用語」、RFC 3198、2001年11月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[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、「Path Computation Element Communication Protocol（PCECP）の要件」、RFC 5376、2008年11月。
[W3CSOAP] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and Gudgin, M., "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, June 2003.
[W3CSOAP] Hadley、M.、Mendelsohn、N.、Moreau、J.、Nielsen、H。、およびGudgin、M。、「SOAPバージョン1.2パート1：メッセージングフレームワーク」、W3C Rec Rec-Soap12-Part1-20030624、2003年6月。
Authors' Addresses
著者のアドレス
Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
Igor Bryskin Adva Optical 7926 Jones Branch Drive Suite 615 McLean、VA 22102メール：ibryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
Dimitri Papadimitriou Alcatel Fr.Wellesplein 1、B-2018 Antwerpen、ベルギー電話：32 3 240-8491メール：dimitri.papadimitriou@alcatel.be
Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、LLC電話：1 301 468 9228メール：lberger@labn.net
Jerry Ash AT&T EMail: gash5107@yahoo.com
Jerry Ash AT＆Tメール：gash5107@yahoo.com