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.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
経路計算エレメント（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.
ポリシーベースの管理（PBM）は、[RFC3198]を参照して、自動的に事前に確立されたルールに基づいてネットワークイベントや条件に応じてアクションを実行するためにネットワークを可能にするネットワーク管理アプローチである、また、ネットワーク管理者から、政策として示します。 PBMは、ルールベースの戦略を介してハイレベルの方法で動作するようにネットワーク管理者を可能にする（ポリシーは、規則及びアクションのセットとして定義することができます）。後者は（すなわち、動的に、人間の干渉なしに）個々のデバイス設定ディレクティブに、全体としてのネットワーク制御を目的とした自動翻訳されています。リソース割り当てプロトコル（RAP）ワーキンググループとポリシーフレームワークワーキンググループ：二つのIETFワーキンググループは、過去にネットワークのポリシーと考えています。
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）の間に使用するためのプロトコルが指定された：共通オープンポリシーサービス（COPS）[RFC2748]。この文書では、PEPとPDPはCOPSコンテキストで定義された関数を参照するための用語を使用します。この文書では、仮定を行いませんまたそれは、実際のCOPSプロトコルを使用する必要がありません。任意の適切なポリシー交換プロトコル（例えば、シンプルオブジェクトアクセスプロトコル（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はまた、代表管理、共有、ベンダーに依存し、相互運用性、およびスケーラブルな方法でポリシーを再利用するための一般的なフレームワークを作成しました。また、QoS管理の必要性に対処する方針コア情報モデル（PCIM）[RFC3060]、およびこのモデルへの拡張と呼ばれる、ポリシーを表現するための拡張可能な情報モデルを定義したQoS（Quality of Service）を方針情報モデルと呼ばれています（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].
BEEP：ブロック拡張可能交換プロトコル、[RFC3080]を参照してください。 CIM：共通情報モデルは、[DMTF]を参照してください。 COPS：一般的なオープンポリシーサービス、[RFC2748]を参照してください。 CSPF：第1の制約ベースの最短パス、[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：シンプルオブジェクトアクセスプロトコル、[W3CSOAP]を参照してください。 TE：トラフィックエンジニアリングは、[RFC3209]と[RFC3473]を参照してください。 TED：トラフィックエンジニアリングデータベース、[RFC3209]と[RFC3473]を参照してください。 TE LSP：トラフィックエンジニアリングMPLSラベルスイッチパスは、[RFC3209]と[RFC3473]を参照してください。 WDM：Wavelength Division Multiplexing：波長分割多重
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およびコスト/性能比の目標に応じて、経路計算要求が異なるサービスに対して別々に発行することができます。サービスBのためのリンクディスジョイント経路は十分かもしれないが、所与のサービスAは、例えば、2つの共有リスクリンクグループ（SRLG）エンドツーエンドの回復スキームを構築するための-disjoint経路を必要とするかもしれません。サービスBは、最短（最小コスト）経路を探しているかもしれないが、サービスAは、最小のエンドツーエンド遅延を有するパスを必要とするかもしれません。異なる制約緩和戦略等サービス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アーキテクチャ内でポリシーをサポートするための追加の動機を説明することができます。歴史的には、経路計算エンティティは、固有の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のソフトウェアのいずれかを変更する必要なく、新しい経路計算機能を導入する方法を見つけることが非常に望ましいです。この目的を達成するための一つの方法は、経路計算要求固有のポリシーとして、パス選択の制約、彼らの緩和、および目的関数を考慮することです。さらに、そのようなポリシーが設定され、他のポリシーなどのネットワークオペレータによって管理さのPCCとのPCEによってリアルタイムで解釈されることができます。
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とのPCEは、他の（つまり、リクエスト固有ではない、である）ポリシーを処理する必要があります。すべてのタイプの経路計算に関連するポリシーは、同じポリシーリポジトリ内に置かれた同一のポリシー管理ツールで管理され、同じメカニズムを使用して解釈することができます。また、ポリシーは[PCEP]を参照のPCC及び特定PCC-PCE通信プロトコルの特殊性とは無関係のPCEによってサポートされる必要があります。したがって、ポリシー記述制約および経路計算要求の他の要素の新しい（リクエスト固有の）タイプを導入することは、ポリシー設定経路計算アーキテクチャに対する自然かつ比較的安価なだけでなくなります。
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ヘッドエンド - LSP先 - PCC - PCE
LSP identifiers
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）で受信したような透明ポリシー情報-TE
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ポリシーフレームワークを使用して適用することができる方法の例のシナリオを提供します。実際のネットワークは議論のシナリオのいずれか、提示されたシナリオ、又は他のシナリオ（議論されていない）のいくつかの組み合わせを展開することができます。このセクションでは、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を使用することであろう。構成されたパスは、[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.
ポリシーの例：10.132.12.1 10.125.13.1 => 10.125.15.1 =>：（service_destinationは10.132.12.0/24に一致する）パスを使用します。他に動的にパスを計算します。
----------------------
| ----- |
| | 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とPCE
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.
経路計算ポリシーは、（おそらくの形で、構成されたパスはPCCで処理した後、PCE要求とともにPCEに渡されるPCCの場合には図1を参照して、PCC又は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を参照）にも使用することができます。そこに限られたTEの視認性があり、独立のPCEは、TEの可視性の各領域内のパス（複数可）を決定するために使用される場合、例えば、ケースを考えます。このような場合には、単一のPCEに全体の明示的なパス（複数可）を構成することができる（または望ましい）でなくてもよいです。しかし、TEの可視性の各領域と各責任PCEの明示的なパス（複数可）を設定することが可能です。 1つずつのPCEは、次いで、設定されたパス（複数可）を適切に着信シグナリング要求をマップすることになります。このようなシナリオを動作させるためになお、おそらく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.
今日の典型的な経路計算過程では、TEの到達可能性、可用性、およびメトリックは、経路選択のための基本的な基準です。しかし、政策は決定プロセスにおける重要な追加検討を提供することができます。例えば、トランジットドメイン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は、提供するサービスのレベルを決定するUSER-、要求固有のポリシーを使用することができます。ソースドメイン内の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.
ポリシーの例（出典：ドメイン内のPCCによって発行された経路計算要求）であればルートトランジットドメインA.他のルートを通るパストランジットドメインBを通るパス
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要求に制約を提供するためのポリシーを使用することです。ネットワーク - ネットワークインタフェース（NNI）またはユーザネットワークインターフェース（UNI）の基準点上を含む、シグナリングを介してサービス要求を受信し、または上に構成要求を受信し、図1に示すように、ポリシーを使用してLSRを検討は、PCCを有効管理インターフェイスは、サービスを確立します。いずれの場合においても、サービスをサポートするために必要なパス（複数可）は、明示的メッセージ/要求で指定されていない、従って経路計算が必要です。
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は、パス選択プロセスが制約されるべきかを決定するUSER-やサービス固有のポリシーを適用することができる、それは、その制約、多様性、最適化基準、および制約緩和戦略はサービスLSPために適用されるべきです（s）は正常に確立される可能性を有しており、ネットワーク障害に対して必要なQoSと弾力性を提供します。制約のセットを決定する際に、PCCは、入力として、それはそのような受信されたメッセージの内容とユーザとサービス、知っているすべての情報を使用して、ポートIDがどのメッセージを介して受信し、関連のVPN ID、シグナリング/参照ポイントタイプ、等、時間を要求制約や必要なパス計算の他のパラメータが決定されると、PCCは、どのように示す制約最適化の決定されたセットを記述するリクエスト固有のポリシー、および他のパラメータを含むパス計算要求を生成します要求は、経路計算プロセスにおいて考慮されるべきです。
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）と、波長連続性制約のパスを計算する場合。他の場合、最小のエンドツーエンド遅延を有する経路を計算（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はまた、既知の（すなわち、検出または構成）のPCEのセットから使用するPCE選択するために、サーバ固有のポリシーを適用してもよいです。 PCCはまた、要求が拒否され、効率的な方法で満足しているのより高い可能性がありますされないようにPCEの機能を一致する要求を形成するために、サーバ固有のポリシーを使用することができます。サーバ固有のポリシーの結果として要求修飾の例は、PCEによってサポートされていない制約を除去します。ポリシーの処理がで完了すると
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に送信されます。
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.
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.
ポリシーの例：経路計算要求に見出さ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は、経路計算を実行することによって要求を満たすことを決定した場合、それは他のPCEの協力を必要とし、ローカルおよびリモートで実行されるパス計算のためのパラメータを定義する場合、それが決定します。その後、PCEは、ローカルパス計算（単数または複数）を実行するために同じ場所に配置経路計算エンジンに指示し、必要に応じて、一の以上の他の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の間の結合から生じる問題を示しています。データセンター（または顧客ネットワーク）宛てのトラフィックの大部分が1 ASからPCE対応ネットワークに入り、すべてのIGPリンクの重みが同じであれば、PE3とPE4の両方を使用してデータセンターに到達することを好むだろうPE2によってアドバタイズされたルート。 PE5は、タイを破るためにPE1とPE2のルータIDを使用し、したがって、（PE2のルータIDは、PE1のそれよりも小さい場合）PE2通る経路を使用することを選択するかもしれません。どちらにしても、最終的な結果は、PE1およびカスタマーエッジ（CE）との間のリンクはほとんどアイドル状態になりながら、PE2と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レコードの分析、典型的な日に大規模なISPのネットワークがマルチホームのお客様の71.8パーセントのために、ほとんどのロードされたリンクは、すべてのトラフィックを運び、最も負荷の完全なアンバランスがあることが示されているため、[IRSCP]参照リンクは、どれを運びません。
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に、PCEポリシーは、トラフィック負荷を監視するように構成することができる（例えば、NetFlowデータに基づいて）データセンターに向かってPE7の入口ルータPE3では、出口ルータPE1とPE2によってサービスプレフィックス。有効PCE方針に基づいて、PCEによって返されるパスの計算を、この与えられた負荷情報を使用して、当たりの入口ルータごとに、適切な出口ルータにトラフィックを誘導することができます。例えば、PCEの経路計算は、このように、デフォルトのIGP基づいて選択をオーバーライドし、PE4とPE5の両方から出PE1へのトラフィックを指示することがあります。また、各出口リンクへの各入口ルータからのトラフィックは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.
ポリシーの例：ルートPE1上の流れ（PE3、PE4、またはPE5のフローingresses）の場合（すべてのトラフィックが流れて顧客ネットワーク宛て）のために。他のルート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パス計算固有のメカニズムが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.
- メカニズムは等ネットワーク管理システム（NMS）、ネットワークプランナー、などの非（G）MPLS（LSR）クライアントをサポートするために十分に汎用でなければならない非（G）のMPLSのPCCをサポート
- 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用のPEPからPCC / PCEのPDPを分離するような通信におけるPCC / PCEのプラズマディスプレイパネルの障害、破壊等の障害事例からフォールトトレランスおよび回復のための規定を含まなければなりません。
- 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.
- メカニズムのための重要な要件のスケーラビリティ一つは、スケーラビリティです。メカニズムは、RSVP-TEは、LSPの経路内に複数のLSPとネットワークノードを収容するという点でスケールをシグナリングすることを、少なくとも同程度に拡張しなければなりません。ポリシーベースの経路計算制御のスケーラビリティの面でいくつかの敏感な部分があります。まず、インフラストラクチャ内のすべての政策対応のノードは、リモート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およびインター面積要件間AS [RFC4927]で説明したポリシーに関連した[RFC4216]で議論要件と[RFC5376]、およびエリア間の政策関連の要件。これらの要件は、政策対応の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.
方針コア情報モデル（PCIM）[RFC3060]で導入されて、[RFC3460]に拡大し、一般的なポリシー情報を表現するためのオブジェクト指向の情報モデルを提示します。
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.
これらのクラスは、種々の具体的な実装には、例えば、そのアクセスプロトコルとしてライトウェイトディレクトリアクセスプロトコルバージョン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を延長することができます。好ましい方法は、直接ポリシー情報を表すと通信するための基盤としてのPolicyGroup、PolicyRuleの、及びPolicyTimePeriodConditionクラスを使用することです。その後、PolicyConditionとPolicyAction由来の特定のサブクラスが条件とポリシーのアクションのアプリケーション固有の定義をキャプチャすることができます。
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]の方針品質はさらに大規模なポリシー・ドメインのためのQoSポリシー情報を表すためにPCIMを拡張します。新しいクラスは、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ポリシーリポジトリPCE方針がPCPIMクラスのインスタンスの形で利用可能であるから、データベース。 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（単数または複数）に情報を配信することが可能な論理エンティティ。
- 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-PDPとPCC-PEP：政策の観点からPCCは、論理的に二つの部分に分解されます。 PCC-PEPが存在する場合、リモート経路計算を必要とする経路計算サービスユーザエンティティと同じ場所に配置（例えば、LSRのGMPLS制御プレーン）。 PCC-PEPおよびPCC-PDPは、物理的に（[RFC2748]に従って）同じ場所に配置又は分離することができます。後者の場合、それらは、SOAP [W3CSOAP]またはBEEP [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-PEPとPCE-PDP：同様に、PCEは、論理的に二つの部分に分解されます。存在する場合、PCE-PEPは（すなわち、経路計算アルゴリズムを実行する）実際のパス計算サービスを提供する経路計算エンジンエンティティと同じ場所に配置されます。 PCE-PEPとPCE-PDPは、物理的に同じ場所に配置又は分離することができます。後者の場合、それらは、SOAP及び/又はBEEPなどのプロトコルを使用して通信します。
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）を使用します。プラズマディスプレイパネルのタスクがリポジトリ（またはリポジトリ）からポリシーを取得し、迷惑な方法でまたは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、（S）からだけでなく、ポリシー情報を受信することができます。同様に、PCE-PEPは[PCEP] PCC-PCE通信プロトコルを介して、PCE-PDP（S）からだけでなく、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のタスクは、PCEを選択し、PCC-PDPが提供するサービス固有のポリシーを適用する経路計算要求を構築することです。 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に適用されたポリシーをサポートしています。アーキテクチャは、両方に適用されたポリシーをサポートしていますが、常にどちらかでもで両方に適用される、またはされるポリシーのための必要はありません。ネットワーク内のポリシーを使用することは、のPCCに、とのPCEに、特定のネットワーク設計上の選択です。一部のネットワークのみのPCCとのPCE（図9）の両方でのPCC（図7）、のPCEでいくつかの（図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のいずれかまたは両方に適用することができます。ポリシーのみのPCCで、またはのPCEに印加されたとき、明らかに、ネットワークで使用されるすべての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は、PCEには、経路計算要求（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とPCEの両方に適用されてもよいが、要求 - 及びクライアント固有のポリシーは、PCEに適用することができます。
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は、例えばUSER-、service-、サーバ - 、ドメイン固有のポリシーのために、必要なポリシーのすべてのタイプを適用しなければなりません。 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とPCEとの関係を示しています。平行関係は、実際には、この関係はのPCCとPCEとの間の関係と同じように見ることができる、協働のPCEの間に存在し、そして。 1つの顕著な違いは、のPCEは異なるエンティティによって管理されているときに共有PCEポリシーリポジトリを持つことが、例えば、望ましいことではないだろう例があるだろうということです。ポリシーは、使用可能なパスを識別するためにドメイン間で一貫しているため、この場合には、それはまだ必要ままであることに注意してください。他の顕著な違いは、経路計算リクエストを処理している間PCEは、他の協働PCE（S）にそれを送信する前に要求を修正するために要求者固有の（つまり、クライアント固有の）ポリシーを適用する必要があることです。 PCEアーキテクチャは、すべての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.
PCCとのPCEによって使用される経路計算ポリシー情報の管理は、主に記載のフレームワークの範囲外です。フレームワークは、このような情報は、インストール除去し、そうでなければ一般的なポリシー管理技術を使用して管理されていることを前提としています。ポリシーリポジトリは、人口と静的な構成、標準および独自のポリシー管理ツール、あるいは動的ポリシー管理/ディスカバリプロトコルおよびアプリケーションを経由して管理することができます。
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.
一つの追加複雑さは、PCE通信プロトコルを適用することができる様々なポリシータイプをサポートするための特定の情報を搬送しなければならないことです。例えば、ポリシーのみPCEで適用される場合に、PCC-PCE要求がservice-またはユーザ固有のポリシーを適用する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に適用USER-またはサービス固有のポリシーは、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のペアは[PCEP]、即ち、要求 - 応答型PCC-PCE通信プロトコルを介して通信します。この文書では、正確なプロトコルは、この通信をサポートするために使用されるものに何も仮定しません。この文書では、経路計算要求のセマンティクスを十分に抽象的で一般的であると仮定し、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>
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)).
注意：この文書は、明示的にすることができます（ただし、必須ではありません）PCCは、当該サービスのための経路の計算に関連するすべての必要な制約、目的関数などが計算を実行するPCEによって決定されることを決定します。この場合、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:
PCCとのPCEは自動的に（PCEの選択に必要な情報を含む）のPCEのセットを発見するための動的PCEの発見ができます。 PCCとのPCEは、動的に新しいのPCEかのPCEの状態のいずれかの変更を検出することもできます。ポリシーは、この文脈では二つの方法で適用することができます。
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発見プロトコル（S）またはPCC-PCE通信プロトコル（単数または複数）のいずれかを使用してこの情報を配信することができますので、後者は、ポリシーの対象となります。この文脈での一つの重要な政策決定は、この情報は厳密にPCEの状態変化、むしろ、「発見」の情報を話していないときに、特に、配信される情報の性質です。この情報が配布されるべきかどうかを決定するとき、クライアント固有のドメイン固有のポリシーを適用することができるためにどの経路計算サービスのクライアント（つまり、どののPCC及び/又はのPCE）。
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は、互いに及び行政境界を越えて通信します。このような場合には、ドメイン固有のポリシーは、すべてのセキュリティポリシーによって許可されている場合、ほとんどの場合、最小限に（ディスカバリプロセス中にピアリングのPCEの間で交換される情報をフィルタリングする）1に適用される）、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と共存A 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など）など。経路計算要求が構築された後、[PCEP]、例えば、PCC-PCE通信プロトコルを使用して、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.
次インチェーンPCEに送信されるE）経路計算要求。
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-PEPは、PCC-PCE通信プロトコルを使用して次インチェーンPCEへの経路計算リクエストを送信し、必要に応じてローカルパス計算（S）とを、実行するために同じ場所に配置経路計算エンジンに指示します。次いで、それは、局所経路計算エンジンとリモートPCEからの応答を待つ得パスを結合し、そしてPCC-を用いたPCC-PEPに戻す送ります
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通信プロトコル。応答が得られた経路ならびに（制約のため、表彰された却下された、そしてリラックスしてどのようにそのうち例えば、）いくつかの追加の情報を記述したポリシーを含みます。
- 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は無知な政策であるとしてUSER-、サービス固有のポリシーは、PCEに適用されるべきです。 GMPLS LSRは上流のLSRからセットアップ（RSVPパス）メッセージを受信したときに再度、LSRは、非同一位置の経路計算エンティティを使用することを決定することができます。次の一連のイベントは、この場合に発生します。
- 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などの他のサービス固有の情報で見つかった情報を使用して、PCE要求、関連付けられたVPN ID、基準点タイプ（UNI、E-NNIを構築しますなど）など。この情報は、政策変数の形で要求でエンコードされています。要求が構築された後、それは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を検証し、それ以外の要求と実際の経路計算要求を構築するために、service-、クライアント - 、およびドメイン固有のポリシーを適用するUSER-で見つかった政策変数を解釈し、要求を処理します。ポリシーは、再び、静的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.
次インチェーンPCEに送信されるE）経路計算要求。
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とのPCEは、任意の変更を要求してはなりません。
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).
以前ドメインでサポートされていなかったこと、PCEは、偏波モード分散（PMD）などの光物理的障害の制約をサポートするソフトウェアでアップグレードされた場合を考えます。この場合、1つ以上の新しいポリシーは、PCEポリシーリポジトリ（PCEに関連付けられている）制約を定義する（アプリケーションの基準、政策変数のセット、条件、アクション、などを決定する規則）とその緩和戦略（にインストールされます。または戦略）。新しいポリシーは、また発見と同期プロトコルを介して、またはローカル設定を経由して、ドメイン内の他のPCE方針リポジトリに反映されます。 PCE-のPDP及びPCC-PDPは、次いで、リポジトリ（またはリポジトリ）から、対応するポリシーを取得します。それ以降、PCC-PDPは（例えば、光チャネル（OCH）層でプロビジョニングサービスのための）特定のパラメータを持つサービスのための経路計算要求に新しいポリシー情報を追加するために、関連するPCC-のPEPに指示します。
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は、新しい制約をサポートするために開始したとします。リポジトリにインストールされ、対応するポリシーは、それが自動的にすべてのリポジトリのユーザーに利用できるようになると、それは、のPCCです。マルチリポジトリの場合に、いくつかのポリシー同期が提供されなければなりません。しかし、この問題はすでに解決されている管理プレーンの一つです。
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;
- それはリポジトリから取得されたポリシー情報の傍受及び/又はのPEPへのPDPから搬送。
- 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;
ポリシー情報および/またはPCE能力の改ざんO;
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.
エードリアンファレルは、この文書に大きく貢献しました。私たちは、PBMと政策主導の経路計算上の実りある議論をベラBerdeに感謝したいと思います。また、PCEポリシーの適用に関する見識と例を提供するためのKobusファンデ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.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、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]ムーア、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460]ムーア、B.、エド。、 "方針コア情報モデル（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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.、コーエン、R.、およびB.ムーア、 "サービスの方針品質（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]張、R.、編、及びJ.-P. Vasseur、エド。、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]ル・ルー、J.-L.、エド。、 "パス計算要素通信プロトコル（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のhttp://www.dmtf.org/standards/standard_cim.php：分散管理タスクフォース社は、CIMのバージョン2.xスキーマのコンポーネントには、次のDMTFのWebページ上のリンクからダウンロードできます。
[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]ファンデMerwe、J.ら、「インテリジェントルートサービス制御ポイントとのダイナミック接続の管理、」インターネットネットワーク管理（INM）、ピサ、イタリア、2006年9月11日にACM SIGCOMMワークショップ。
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", Work in Progress, November 2008.
[PCEP] Vasseur、JP。、エド。そしてJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、進歩、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]ダラム、D.、編、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.、およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748 、2000年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]ローズ、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.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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]ビタール、N.、張、R.、およびK.熊木、RFC 5376、 "パス計算要素通信プロトコル（PCECP）のためのInter-ASの要件" 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]ハドリー、M.、メンデルゾーン、N.、モロー、J.、ニールセン、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
イゴールBryskin ADVA光学7926ジョーンズ支店ドライブスイート615マクリーン、VA 22102 Eメール：ibryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
ディミトリPapadimitriouアルカテルブロック。 Vellesplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 240から8491 Eメール：δημήτρη.παπαδημητρίου@αλκατελ.βε
Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、LLC電話：+1 301 468 9228 Eメール：lberger@labn.net
Jerry Ash AT&T EMail: gash5107@yahoo.com
ジェリー・アッシュAT＆T Eメール：gash5107@yahoo.com