RFC5394 日本語訳
5394 Policy-Enabled Path Computation Framework. I. Bryskin, D.Papadimitriou, L. Berger, J. Ash. December 2008. (Format: TXT=82226 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Bryskinがコメントのために要求するワーキンググループI.をネットワークでつないでください: 5394年のAdvaの光学カテゴリ: J.灰のAT&T2008年12月に相談する情報のD.PapadimitriouアルカテルL.バーガーLabN
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)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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 Computation Element(PCE)アーキテクチャは経路計算の文脈の方針の概念を紹介します。 このドキュメントは、PCEアーキテクチャの中で方針に関する追加詳細を明らかにして、また、PCE Policyのサポートに文脈を提供します。 このドキュメントは経路計算方針をサポートするためのフレームワークとしてPolicy Core情報Model(PCIM)の使用を導入します。 また、このドキュメントは代表しているシナリオをPCE Policyのサポートに提供します。
Bryskin, et al. Informational [Page 1] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [1ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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
1. 序論…2 1.1. 用語…3 2. バックグラウンド…4 2.1. 動機…4 2.2. 方針属性…6 2.3. 代表している方針シナリオ…7 2.3.1. シナリオ: 方針は経路を構成しました…7 2.3.2. シナリオ: プロバイダー選択方針…10 2.3.3. シナリオ: 方針は規制を基礎づけました…12 2.3.4. シナリオ: ロードバランシング(アルバ)の例を進めます…14 3. 要件…16 4. 経路計算方針情報モデル(PCPIM)…18 5. 方針で可能にされた経路計算フレームワークコンポーネント…20 6. 方針コンポーネント構成…21 6.1. PCC-PCE構成…21 6.2. 方針倉庫…24 6.3. 協力関係を持っているPCE構成…25 6.4. 方針構成管理…27 7. 相互コンポーネントコミュニケーション…27 7.1. 方針コミュニケーション…27 7.2. PCE発見方針問題…29 8. イベントの経路計算系列…29 8.1. 方針で可能にされたPCC、方針で可能にされたPCE…29 8.2. 方針無知なPCC、方針で可能にされたPCE…31 9. 新しい規制の導入…32 10. セキュリティ問題…33 11. 承認…33 12. 参照…34 12.1. 標準の参照…34 12.2. 有益な参照…34
1. Introduction
1. 序論
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.
Path Computation Element(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.,
[RFC3198]は、方針ベースのManagement(PBM)がネットワークが自動的にネットワークイベントに対応して動作を実行するのを可能にするネットワークマネージメントアプローチかプレ定則に基づいていて、また方針として指示された状態であると考えます、ネットワーク管理者から。 PBMは、ネットワーク管理者が規則ベースの戦略を通してハイレベルの方法で働いているのを可能にします(1セットの規則と機能と方針を定義できます)。 すなわち後者が自動的に翻訳される、(。
Bryskin, et al. Informational [Page 2] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [2ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
ダイナミックである、人間の干渉) 個々の全体でネットワークを制御するのが目的とされたデバイス構成指示に。 2IETF Working Groupsが過去に方針ネットワークを考えました: Resource Allocationプロトコル(RAP)ワーキンググループとPolicy Frameworkワーキンググループ。
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]のためのフレームワークは定義されました、そして、Policy Enforcement Points(PEP)とPolicy Decision Points(PDP)の間の使用のためのプロトコルは指定されました: 一般的なオープンポリシーサービス(巡査)[RFC2748]。 このドキュメントは、COPS文脈で定義された機能について言及するのに用語のPEPとPDPを使用します。 このドキュメントは仮定を全くしません、そして、それは実際のCOPSプロトコルが使用されるのを必要としません。 どんな適当な方針交換プロトコル(例えば、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は、ベンダーから独立していて、共同利用できて、スケーラブルな方法で方針を表して、管理して、共有して、再利用するために一般的なフレームワークを生産しました。 Service(QoS)方針情報Model(QPIM)[RFC3644]のQualityは、また、Policy Core情報Model(PCIM)[RFC3060]と呼ばれる方針を表して、このモデルへの拡大がQoS管理の必要性を扱うようにそれが広げることができる情報モデルを定義したと呼びました。 しかしながら、追加メカニズムが、コントロールと同様に経路計算論理に関連する方針を指定するのに必要です。
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は方針の可能にされた経路計算をサポートするのに使用されるかもしれない1セットの部品を導入します。 セクション6、7、および8可能なコンポーネント構成、コミュニケーション、およびイベントに関する詳細を明らかにしてください。 セクション10は最小量の影響で新しい規制を導入する能力について論じます。 このドキュメントがセクション4でPCIMを導入するだけであることに注意されるべきです。 別々のドキュメントで経路計算をサポートする特定のPCIM定義について議論するでしょう。
1.1. Terminology
1.1. 用語
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].
ビープ音: Extensible Exchangeプロトコルを妨げて、[RFC3080]を見ます。 CIM: 一般的な情報Model、[DMTF]を見てください。 巡査: 一般的なオープンPolicy Service、[RFC2748]を見てください。 CSPF: 規制ベースのShortest Path First、[RFC3630]を見てください。
Bryskin, et al. Informational [Page 3] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [3ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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: Switched Pathをラベルしてください、そして、[RFC3031]を見てください。 LSR: Switching Routerをラベルしてください、そして、[RFC3031]を見てください。 PBM: ベースの方針Management、[RFC3198]を見てください。 PC: 経路計算。 PCC: 経路Computation Client、[RFC4655]を見てください。 PCCIM: 経路計算コア情報モデル。 PCE: 経路Computation Element、[RFC4655]を見てください。 PCEP: 経路Computation Element Communicationプロトコル、[PCEP]を見てください。 PCIM: 方針Core情報Model、[RFC3060]を見てください。 PDP: 方針Decision Point、[RFC2753]を見てください。 気力: 方針Enforcement Point、[RFC2753]を見てください。 QPIM: QoS Policy情報Model、[RFC3644]を見てください。 SLA: 平らな協定を修理してください。 SOAP: Simple Object Access Protocol、[W3CSOAP]を見てください。 Te: トラフィックEngineering、[RFC3209]と[RFC3473]を見てください。 テッド: トラフィックEngineering Database、[RFC3209]と[RFC3473]を見てください。 Te LSP: トラフィックEngineering MPLS Label Switched Path、[RFC3209]と[RFC3473]を見てください。 WDM: 波長分割多重
2. Background
2. バックグラウンド
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方針フレームワークに文脈を提供することを意図します。 このセクションは、原理かシナリオに関する完全なりストを提示するのを試みません。
2.1. Motivation
2.1. 動機
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
ネットワーク・オペレータはTE経路計算プロセスを形成するためにあるレベルの柔軟性を必要とします、プロセスが彼らのビジネスと操作上の必要性と提携できるように。 経路計算の多くの局面が方針で決定されるかもしれません。 例えば、PCCは特定のサービスのために経路を計算している間に要求するどの最適化評価基準について決めるかためにオペレータによって構成された方針、規制、相違、およびそれらの緩和戦略を使用するかもしれません。 SLA、TE、および費用/性能比率目標によって、経路計算要求は異なったサービスのために異なって出されるかもしれません。 例えば、与えられたService AはShared Risk Link Group(SRLG)が終わりから終わりへの回復体系を築き上げながら経路をばらばらにならせる2を必要とするかもしれません。
Bryskin, et al. Informational [Page 4] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [4ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
Service Bでは、リンクでばらばらになっている経路は十分であるかもしれません。 Service Bが最も短い(最小量の費用)経路を探しているかもしれない間、サービスAは終わりから終わりへの最小量の遅れがある経路を必要とするかもしれません。 異なった規制緩和戦略はService A Service 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]は見ます。 協力PCEsのグループの他のメンバーに送る前に特定の要求を満たす他のPCEsの協力を求めるか、またはそれ自身(ことによると、非明白な経路で、応じる)、またはどのようにに関する要求を扱うように要求を変更するべきであるかか否かに関係なくなど。
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(そして、他のLSRsがないいかなる他のネットワーク要素も)の制御飛行機ソフトウェアをアップグレードさせることでした。
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の新しい能力を利用するために、新しい広告とオブジェクトに合図するのは、標準化される必要があるかもしれません、そして、すべてのPCCsが、新しいソフトウェアでアップグレードする必要があるかもしれません、そして、新しい相互運用性問題は決議されているなど必要があるかもしれません。
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によって解釈されるかもしれません。
Bryskin, et al. Informational [Page 5] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [5ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
- 既存の規制、目的関数、およびそれらの緩和は、集められて、別の方法で関連づけられるかもしれません、その結果、新しい状態で生産します、機能をサポートしながらPCEsでさえコードの変化を必要としないより複雑な目的関数。
- 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.
- PCCsとPCEsは、方針を別(すなわち、要求詳細でない)に扱う必要があります。 同じメカニズムを使用することですべてのタイプの経路の計算関連の方針を同じ方針倉庫の中に置いて、同じ政策管理ツールによって管理されて、解釈できます。また、方針は、特定のPCC-PCE通信プロトコルのユニークさの如何にかかわらずPCCsとPCEsによってサポートされる必要があります、と[PCEP]は見ます。 したがって、新しい(要求特有の)タイプの方針説明を経路計算の規制と他の要素が要求する導入するのは方針で可能にされた経路計算アーキテクチャへの自然で比較的安価な追加になるでしょう。
2.2. Policy Attributes
2.2. 方針属性
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
Bryskin, et al. Informational [Page 6] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [6ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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
- 目的関数--他の考えられるべきLSPs
Additional policy information
追加方針情報
- Transparent policy information as received in Resource
Reservation Protocol (RSVP)-TE
- Resource予約プロトコル(RSVP)-TEに受け取られる見え透いた方針情報
2.3. Representative Policy Scenarios
2.3. 代表している方針シナリオ
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アーキテクチャの中で方針の他のアプリケーションを制限するとこのセクションを見なすべきではありません。
2.3.1. Scenario: Policy Configured Paths
2.3.1. シナリオ: 方針の構成された経路
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を使用するだろうことです。 構成された経路は、Explicit Route Objects(EROs)の形で厳しくてゆるいホップで構成されて、[RFC3209]を見て、1LSPsによって使用されます。 通常、そのような経路はLSPイングレスで構成されます。 方針で可能にされた経路計算の文脈では、代替のアプローチは可能です。
Bryskin, et al. Informational [Page 7] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [7ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.0/24)が経路を使用するなら: 10.125 .13 .1はダイナミックに>10.125.15.1=>10.132.12の.1のほかのCompute経路と等しいです。
----------------------
| ----- |
| | 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
---------------------- | ----- | | | テッド| <、-+------------>| ----- | TED同期| | | メカニズム(例えば、ルーティング・プロトコル)| | | | v| | ------ ----- | 相互PCE要求/応答| |方針| <-->、| PCE|<+…>(存在しているとき)| ------ ----- | ---------------------- ^ | 要求/| 応答対Service------------- シグナリング要求|[PCC][方針]| プロトコル<。------>| ノード| <、-、-、-、-、-、-->かシグナリング------------- プロトコル
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.
図1は、経路計算方針がPCCかPCEのどちらかに適用されるかもしれないのを見ます。 PCC場合では、構成された経路は、PCCに処理されて、次に、PCE要求に伴うPCEに通り過ぎられるでしょう、たぶん(包含)規制の形で。 PCEに適用されると、構成された経路は局所的に使用されるでしょう。 両方のケースは方針を構成して、管理する何らかのメソッドを必要とします。 PCC場合では、自動化された方針分配メカニズムがあるとき、本当の利益は来るでしょう。
Bryskin, et al. Informational [Page 8] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [8ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
------------------ -------------------
| | | |
| 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 |
-------- ------------ ------------
------------------ ------------------- | | | | | PCE| | PCE| | | | | | ------ ----- | | ----- ------ | | |方針| | テッド| | | | テッド| |方針| | | ------ ----- | | ----- ------ | ------------------ ------------------- ^ ^ | 要求/| 要求/| 応答| 応答v対Service-------- シグナリング------------ シグナリング------------ 要求|ギヤエンド| プロトコル|中間的| プロトコル|中間的| ---->| ノード| <、-、-、-、-、-、-、-、--、>| ノード| <、-、-、-、-、-、-、-、--、>| ノード| -------- ------------ ------------
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 |
---------- ---------- ----------
------------------ ------------------ | | 相互PCE要求/応答| | | PCE| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| PCE| | | | | | ------ ----- | | ------ ----- | | |方針| | テッド| | | |方針| | テッド| | | ------ ----- | | ------ ----- | ------------------ ------------------ ^ | 要求/| 応答対Service---------- シグナリング---------- シグナリング---------- 要求| ギヤエンド| プロトコル| 隣接| プロトコル| 隣接| ---->| ノード| <、-、-、-、-、-、-、-、-、--、>| ノード| <、-、-、-、-、-、-、-、-、--、>| ノード| ---------- ---------- ----------
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
また、方針で構成された経路は複数の(1以上)協力PCEsと共に環境で使用されるかもしれません(図2と3を見てください)。 例えば、限られたTE目に見えることがあって、独立しているPCEsがTE目に見えることの各領域の中で経路を決定するのに使用されたらケースを考えてください。 このような場合には、独身のPCEの上の全体の明白な経路を構成するのは、可能、そして、(望ましい。)でないかもしれません。 しかしながら、TE目に見えることの各領域とそれぞれの責任があるPCEのために明白な経路を構成するのは可能です。 そして、ひとつずつ、PCEsは構成された経路を当てるという入って来るシグナリング要求を写像するでしょう。 そのようなシナリオを働かせるように、そうすることに注意してください。
Bryskin, et al. Informational [Page 9] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [9ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
始まって、TEドメイン境界ノードの上の構成された経路を終えるのにおそらく必要であってください。 また、明確に、一貫したPCE Policy Repositoriesもこの例で重要です。
2.3.2. Scenario: Provider Selection Policy
2.3.2. シナリオ: プロバイダー選択方針
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.
潜在的によりおもしろいシナリオはマルチプロバイダーtopologiesのPC方針を当てはまっています。 頻繁なおもしろい方針利用がそのようなtopologiesにあります。 初歩的な例は簡単なアクセスコントロール、すなわち、PCCsが相互ドメイン経路計算を要求することが許可されている決定です。
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.Likewiseより高価であり、下側の遅れか損失を供給するかもしれなくて、トランジットドメインは他のプロバイダーからの要求と異なってそれ自身の顧客からPCE要求を扱いたがっているかもしれません。 どちらの場合も、交通工学データベースに基づく計算は可到達性を提供する複数のトランジットドメインをもたらすでしょう、そして、どのPCE要求が、より良いサービスを得るかを治めるのに方針は使用できます。
Bryskin, et al. Informational [Page 10] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [10ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
+-------+
+----------+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 |
+-------+
+-------+ +----------+ トランジット+----------+ +---+---+ | ドメイン| +---+---+ |トランジット| | C| |トランジット| +--------+ ドメイン| +---+---+ | ドメイン+--------+ | | +--+| +--+ F| | +--+---+ +---+---+ | | | +---+---+ +--+---+ |ソース| | | +---+---+ | | |目標| |ドメイン| | +---+ トランジット+---+ | |ドメイン| +--+---+ | +---+ ドメイン|---+ | +--+---+ | +---+---+ | | D| | +---+---+ | | |トランジット| | +---+---+ | |トランジット| | +--------+ ドメイン+--+| +--+ ドメイン+--------+ | B| | | G| +---+---+ +---+---+ +---+---+ | |トランジット| | +----------+ ドメイン+----------+ | 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.
方針に関する例: (経路計算要求はTransit Domain Bを通してTransit DomainのA.のほかのRouteを通したSource Domainの中のPCC) ルートによる経路に経路を発行しました。
Bryskin, et al. Informational [Page 11] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [11ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
2.3.3. Scenario: Policy Based Constraints
2.3.3. シナリオ: 方針は規制を基礎づけました。
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要求における規制を提供する方針の使用です。 方針があるLSRがPCCを有効にしたと考えてください、図1(Network-ネットワークの上のInterface(NNI)かUser Network Interface(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は、経路選択の過程がどう抑制されるべきであるか、そして、すなわち、どの規制、相違、最適化評価基準、および規制緩和戦略がネットワーク失敗に対して首尾よく確立されて、必要なQoSと弾力を提供するためにサービスLSP(s)には見込みがある命令で適用されるべきであるかと決めるためにユーザかサービス特有の方針を適用するかもしれません。 規制のセット、入力としての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層のネットワークのものです) 経路終わりの最適化における最大のOptical Signal Noise Ratio(OSNR)との波長連続規制がある経路を計算してください、ほか、終わりから終わりへの最小の遅れほかのComputeがある経路を計算する、(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は、知られている(すなわち、発見されるか、または構成される)PCEsのセットからどのPCEを使用したらよいかを選択するためにサーバ特定保険証券を適用するかもしれません。 PCCはまた、要求が拒絶されないようにPCEの能力を合わせるという要求を形成するのにサーバ特定保険証券を使用するかもしれなくて、効率的な方法で満たされるというより高い見込みを持っています。 サーバ特定保険証券の結果としての要求変更に関する例はPCEによって支持されなかった規制を取り除いています。 かつての処理が終了している方針
Bryskin, et al. Informational [Page 12] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [12ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
方針に関する例: (LSPはWDM層のネットワークのものです) 波長の連続と光の損傷規制を支持するPCEを特定してください。 以下の規制で経路計算を要求して、そのようなPCEに要求を送ってください: a) 波長の連続。 経路のb)最大のPolarization Modeディアスポラ(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.
方針に関する例: 経路計算要求で見つけられた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は地方の経路計算を実行するよう共同見つけられた経路演算処理エンジンに命令して、必要なら、経路計算要求を他の1PCEsに送ります。 そして、それは地方の経路演算処理エンジンと使用されるときのリモートPCEから応答を待っています。 それは、次に、結果として起こる経路を結合して、要求しているPCCに結果を送り返します。 応答は結果として起こる経路について説明する方針を示すかもしれません、それらの特性(概要費用、終わりから終わりへの予想された遅れなど)、追加情報が例えば、それの規制が光栄に思っていて、捨てられて、リラックスした要求によく関係づけてどんな風のように。
Bryskin, et al. Informational [Page 13] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [13ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
方針に関する例: (経路の目的地はドメインAに属します) 経路計算を実行するよう地方の経路演算処理エンジンに命令してください。 目的地ドメインを支持するほかのIdentify PCE。 経路計算要求をそのようなPCEに送ってください。 応答を待って、処理してください。 要求への経路計算応答にPCCを送ってください。
The PCC processes the response and instructs the LSR to encode the received path(s) into the outgoing signaling message(s).
PCCは、応答を処理して、送信するシグナリングメッセージに容認された経路をコード化するようLSRに命令します。
2.3.4. Scenario: Advanced Load Balancing (ALB) Example
2.3.4. シナリオ: 高度なロードバランシング(アルバ)の例
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の間のカップリングからの軸が処理するという問題を例証します。 データセンター(または、顧客ネットワーク)に運命づけられた交通の重要な部分がAS1からPCEによって可能にされたネットワークに入って、すべてのIGPリンクの重りが同じであるなら、PE3とPE4の両方が、PE2によって広告に掲載されたルートを使用することでデータセンターに達するのを好むでしょう。 PE5は繋がりを壊すのにPE1とPE2のルータIDを使用して、したがって、また、PE2を通して経路を使用するために選んだ状態で使用するかもしれません(PE2のルータIDがPE1のものより小さいなら)。 いずれにせよ、最終結果はPE1とCustomer Edge(CE)とのリンクがほとんど使用されていなくなる間PE2とCEとのリンクが交通の大部分を運ぶということです。
Bryskin, et al. Informational [Page 14] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [14ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
..............................
. 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|..........
+---+
.............................. . 1として…、+---+ +---+ +----+ . ....|PE8|...|PE9|...|PE10|.... +---+ +---+ +----+ | | | +---+ +---+ +---+ ......|PE3|...|PE4|...|PE5|...... . +---+ +---+ +---+ . .............. +---+ \ / ___/ +---+ . . _|PE2|_____+--+__/ / _|PE6| . +--+ / +---+ |P1|_____+--+_______/ +---+ . 顧客|Ce|= . +--+ |P2| . . Network +--+ \_+---+ \ +--+ . . . |PE1|________+--+___/| x===x使用されるPCE… +---+ |P3| | |PCE| . . +--+で| x===x AS0ノードAS0+---+ . ..................|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の分析は記録します、と[IRSCP]は見ます、典型的な日の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では、PCE方針を構成できたので、トラヒック負荷はイングレスルータPE3で出口ルータのPE1とPE2によって役立たれたデータセンター接頭語に向かったPE7にモニターされます(例えば、Netflowデータに基づいています)。 この提供された負荷情報を使用して、可能にされたPCE方針に基づくPCEによって返された経路計算は適切な出口ルータに交通整理できます、1イングレスあたり1個のルータベースで。 例えば、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
このシナリオは方針で治められたPCEがどうそうしない何らかの情報を説明できるか、またはTEリンク/ノード属性として広告を出すことができないで、明白な経路計算規制において、したがって、受けることがあるはずがないかに関する好例です。 より一般に、そのような情報はほとんど何かであるかもしれません。 例えば、交通需要
Bryskin, et al. Informational [Page 15] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [15ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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方針がどうそのあるネットワークルーティング問題を訴えるかもしれないかに関する[IRSCP]で説明されます、選択している分配されたサービスの否定(DDoS)blackholingや、計画された維持や、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.
方針に関する例: (Customer Networkに運命づけられたすべての交通の流れ) (PE3、PE4、またはPE5の上の流れ進入)がPE1の上に流れを発送するならほかのRoute、PE2の上の流れ。
3. Requirements
3. 要件
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で議定書を作るのでRSVP-TEを使用する経路計算の問題に特定の方針ベースのコントロール要件とGMPLS LSRs。
- 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、サポート、非、-、(G) Network Management System(NMS)、またはネットワーク立案者などの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 PDPsの失敗、コミュニケーションにおける分裂などの失敗事件からの関連PCC/PCE PEPsとPCC/PCE PDPを切り離す寛容と回復をとがめます。
Bryskin, et al. Informational [Page 16] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [16ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
- 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.
- 方針無知なノードのためにメカニズムをサポートしてください。ネットワークにおけるあらゆるノードに義務的であるべきであるというわけではありません。 例えば、方針ベースの経路計算コントロールは管理ドメインの中の境界ノードでノードの部分集合で励行されるかもしれません。 これらの方針できるノードは方針無知なノードの観点からの信じられたノードとしてその管理ドメインで機能するでしょう。 あるいはまた、方針は唯一PCEsに方針無知なノードであるすべてのPCCsで適用されるかもしれません。
- 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の経路で複数のLSPsとネットワーク・ノードに対応することに関してスケールに合図するそのRSVP-TEを少なくとも同じ範囲にスケーリングしなければなりません。 方針ベースの経路計算コントロールのスケーラビリティに関していくつかの情報焦点地域があります。 まず最初に、インフラストラクチャにおけるあらゆる方針意識しているノードがリモートPDPに連絡すると予想されるべきであるというわけではありません。 これは要求について確かめる潜在的に長い遅れを引き起こすでしょう。 さらに、方針規制構造はRSVP-TEがRSVP-TEメッセージのサイズなどの要素に基づいて議定書を作るのと少なくとも同じくらいよく比例しなければなりません、と時間はネットワークのためにRSVP-TE要求、ノード単位で必要であるローカル処理時間、およびローカルの記憶がノード単位で消費したサービスに必要としました。 これらのスケーリング問題はLSPsの1セットのコースを変更する間、特別に重要です。
- 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 2番目に、方針コントロールにかかわる実体(PEPsやPDPsなどの)が互いのアイデンティティについて確かめて、交信する前に必要な信用を確立できるのを確実にしなければなりません。
- 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と相互領域要件Thereは[RFC4216]と[RFC5376]で議論した、いくつかの相互ASの方針関連の要件と、[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.
このドキュメントがコミュニケーション要素について概説するだけであることに注意されるべきであり、メカニズムは、さまざまな可能な方針が経路計算コントロールのために適用されるのを許容する必要がありました。 どんな特定保険証券の振舞いの少しの議論も含んでいなくて、それは、特定保険証券の使用を定義するか、または必要としません。
Bryskin, et al. Informational [Page 17] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [17ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
4. Path Computation Policy Information Model (PCPIM)
4. 経路計算方針情報モデル(PCPIM)
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]で広げられたPolicy Core情報Model(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.
例えばアクセス・プロトコルとしてライトウェイト・ディレクトリ・アクセス・プロトコルバージョン3(LDAPv3)を使用するディレクトリへの様々な具体的な実現にこれらのクラスを写像できます。
Figure 6 shows an abstract from the class inheritance hierarchy for PCIM.
図6はPCIMのためにクラス遺産階層構造から要約を示しています。
Bryskin, et al. Informational [Page 18] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [18ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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)
ManagedElement(抽象的な)| +--方針(要約)| | | +---PolicySet(抽象的な)| | | | | +---PolicyGroup| | | | | +---PolicyRule| | | +---PolicyCondition(抽象的な)| | | | | +---PolicyTimePeriodCondition| | | | | +---VendorPolicyCondition| | | | | +---SimplePolicyCondition| | | | | +---CompoundPolicyCondition| | | | | +---CompoundFilterCondition| | | +---PolicyAction(抽象的な)| | | | | +---VendorPolicyAction| | | | | +---SimplePolicyAction| | | | | +---CompoundPolicyAction| | | +---PolicyVariable(抽象的な)| | | | | +---PolicyExplicitVariable| | | | | +---PolicyImplicitVariable| | | | | +---(より特定のクラスの下位木) | | | +---PolicyValue(抽象的な)| | | +---(より特定のクラスの下位木)
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で定義された方針のクラスと協会は彼らが何にでも関連する方針を表すのを許容できるくらい一般的です。
Bryskin, et al. Informational [Page 19] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [19ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
Path Computation Serviceなどのアプリケーション特有の領域への政策モデルはいくつかの方法で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.
Service情報Model[RFC3644]のPolicy Qualityは、大規模な方針ドメインのためのQoS方針情報を表すためにさらにPCIMを広げています。 PCPIMの基礎として本書ではQoSについて説明しながら導入された新しいクラス、RSVP関連の変数、状態、および動きを使用できます。
Detailed description of the PCPIM will be provided in a separate document.
PCPIMの詳述を別々のドキュメントに提供するでしょう。
5. Policy-Enabled Path Computation Framework Components
5. 方針で可能にされた経路計算枠組みのコンポーネント
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 Policy Repository Aデータベースは属します。 PCE PoliciesはPCE Policy Management Toolsによって構成されて、管理されます。
- 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);
- 1Policy Repositoriesから関連経路計算方針を検索して、関連PCE-PEP(s)に情報を渡すことができるPCE Policy Decision Point(PCE-PDP)のA論理的な実体。
- 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;
- 方針を実施する目的を求める装置特有のPath Computation Engine構成要求を出すことができるPCE Policy Enforcement Point(PCE-PEP)のA論理的な実体。
- 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);
- 1Policy Repositoriesから関連経路計算方針を検索して、関連PCC-PEP(s)に情報を渡すことができるPCC Policy Decision Point(PCC-PDP)のA論理的な実体。
- 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.
- 装置特有のPath Computation Service User構成を発行できるPCC Policy Enforcement Point(PCC-PEP)のA論理的な実体は実施の目的のために方針を要求します。
Bryskin, et al. Informational [Page 20] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [20ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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-気力。 存在しているとき、PCC-PEPはリモート経路計算(例えば、LSRのGMPLS制御飛行機)を必要とするPath Computation Service User実体で共同見つけられています。 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は2つの部品に論理的に分解されます: PCE-気力とPCE-PDP。 存在しているとき、PCE-PEPは実際に、Path Computation Service(すなわち、経路計算アルゴリズムを走らせる)を提供するPath Computation Engine実体で共同見つけられています。 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 Policy Repositoryは共同見つけられたかもしれなくて、分離しました。 後者の場合では、PDPsは何らかのアクセス・プロトコル(例えば、LDAPv3かSNMP)を使用します。 PDPsに関するタスクは、倉庫(または、倉庫)から方針を検索して、求められていない道かPEPの要求でのそれぞれのPEPsまでそれらを運ぶことです。
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)から受け取るだけではなく、PCE-PEP(s)からもPCC-PCEコミュニケーション、そして/または、PCE発見プロトコルで方針情報を受け取るかもしれません。 同様に、PCE-PEPはPCE-PDP(s)から受け取るだけではなく、PCC-PEP(s)からも方針情報を受け取るかもしれません、PCC-PCE通信プロトコル[PCEP]で。
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によって供給されたドメイン特定保険証券を適用することによって経路計算を制御することです。
6. Policy Component Configurations
6. 方針コンポーネント構成
6.1. PCC-PCE Configurations
6.1. PCC-PCE構成
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,
PCE方針構造はPCCにおいてPCEにおいて適用される方針を支持します。 構造は両方で適用される方針を支持しますが、方針が両方において、または、どちらかでさえいつも適用されるという要件が全くありません。 PCCsの上のネットワークにおける方針の使用
Bryskin, et al. Informational [Page 21] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [21ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
そして、特定のネットワークはPCEsにおける、デザイン選択ですか? ネットワークの中にはPCCs(図7)、PCEsのいくつか(エイト環)だけで方針を適用して、PCCsとPCEsの両方(図9)で他のものを適用するのを選ぶものも、あるかもしれません。 にかかわらず、方針が適用されているところでは、意図した結果を獲得するために一貫したファッションでそれを適用しなければなりません。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy -----------------------
| PCC-PDP |<--------- | PCE Policy Repository |
--------- -----------------------
^
| e.g., SOAP
v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol ---------
......................... . . . PCE政策管理… . . --------- 方針----------------------- | PCC-PDP| <、-、-、-、-、-、-、-、--、| PCE方針倉庫| --------- ----------------------- ^ | 例えば、SOAP v--------- PCEP--------- | PCC-気力|<------------------------------------------->| PCE| --------- PCC-PCE通信プロトコル---------
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方針タイプを適用しなければなりません。
Bryskin, et al. Informational [Page 22] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [22ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
----------------------- Policy ---------
| PCE Policy Repository | -------->| PCE-PDP |
----------------------- ---------
^
e.g., SOAP |
v
--------- PCEP ---------
| PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
......................... . . . PCE政策管理… . . ----------------------- 方針--------- | PCE方針倉庫| -------->| PCE-PDP| ----------------------- --------- ^例えば、SOAP| v--------- PCEP--------- | PCC|<------------------------------------------->| PCE-気力| --------- PCC-PCE通信プロトコル---------
Figure 8: Policies Applied on Only
エイト環: 唯一で適用された方針
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がそれが経路計算要求(たぶんPCPIM政策変数の形の)に集めることができるサービスのすべての情報をPCEに通過すると予想されます。 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に適用されるかもしれなくて、要求とクライアント特定保険証券はPCEに適用されるかもしれません、ドメイン特定保険証券がPCCと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はすべてのタイプの必要な方針、例えば、ユーザ、サービス、サーバ、およびドメイン特定保険証券を適用しなければなりません。 PCCは、適切に適用された方針を表す経路計算要求を構成するのに方針を使用します。 要求は必ずPCC-PCE通信プロトコルによって明らかに定義された「基本的な」(すなわち、できる無政策)規制のセットに制限されるでしょう。
Bryskin, et al. Informational [Page 23] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [23ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
6.2. Policy Repositories
6.2. 方針倉庫
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.
この構成には、PCCsとPCEsの間で共有された独身のPCE Policy Repositoryがあります。
.........................
. .
. 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 ---------
......................... . . . PCE政策管理… . . --------- 方針----------------------- 方針b--------- | PCC-PDP| <、-、-、-、-、-、-、-、--、| PCE方針倉庫| -------->| PCE-PDP| --------- ----------------------- --------- ^ ^ | 例えば、SOAP、例えば、SOAP| vに対して--------- PCEP--------- | PCC-気力|<------------------------------------------->| PCE-気力| --------- PCC-PCE通信プロトコル---------
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 Policy Repository Aであるときに、状況がまさに、PC Policy Repository B(ただ一つのPCE Policy Repository構成場合における結果)に合っていることに注意してください。
Bryskin, et al. Informational [Page 24] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [24ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
-------------- --------------
| 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 ---------
-------------- -------------- | PCE方針| | PCE方針| ---| 倉庫A| | 倉庫B|--- | -------------- -------------- | | | | 方針はPolicy bです。| | | vに対して--------- --------- | PCC-PDP| | PCE-PDP| --------- --------- ^ ^ | 例えば、SOAP、例えば、SOAP| vに対して--------- PCEP--------- | PCC-気力|<------------------------------------------->| PCE-気力| --------- PCC-PCE通信プロトコル---------
Figure 10: Multiple PCE/PCC Policy Repositories
図10: 複数のPCE/PCC方針倉庫
6.3. Cooperating PCE Configurations
6.3. 協力関係を持っているPCE構成
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.
前項はPCCsとPCEsとの関係を示しています。 並行関係は協力PCEsの間に存在しています、そして、事実上、PCCsとPCEsとの関係と同じくらい同じようにこの関係は見ることができます。 1つの注目に値する違いはPCEsが異なった実体によって管理されるとき、ケースが例えば共有されたPCE Policy Repositoryを持っているのが望ましくないところにあるということです。 この場合それがまだ方針が使用可能な経路を特定するためにドメインの向こう側に一貫しているのに必要なままで残っていることに注意してください。 もう片方の注目に値する違いはPCEが、経路計算要求を処理する間他の協力PCE(s)にそれを送る前に要求を変更するためにリクエスタの特定(すなわち、クライアント詳細)の方針を適用する必要があるかもしれないということです。 すべてのPCCsが方針によって可能にされるというわけではないところでPCE構造が構成を考慮するので、この関係は特に重要です。
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.
この構成には、PCEsの間で共有された独身のPCE Policy Repositoryがあります。 この構成は、ただ一つの管理ドメインで中複数のPCEsが冗長に提供される役に立つか、または分配目的をロードしそうです。
Bryskin, et al. Informational [Page 25] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [25ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
.........................
. .
. 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 ---------
......................... . . . PCE政策管理… . . --------- 方針----------------------- 方針b--------- | PCE-PDP| <、-、-、-、-、-、-、-、--、| PCE方針倉庫| -------->| PCE-PDP| --------- ----------------------- --------- ^ ^ | 例えば、SOAP、例えば、SOAP| vに対して--------- --------- | PCE-気力|<------------------------------------------->| PCE-気力| --------- PCE-PCE通信プロトコル---------
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 ---------
-------------- -------------- | PCE方針| | PCE方針| ---| 倉庫A| | 倉庫B|--- | -------------- -------------- | | | | 方針はPolicy bです。| | | vに対して--------- --------- | PCE-PDP| | PCE-PDP| --------- --------- ^ ^ | 例えば、SOAP、例えば、SOAP| vに対して--------- PCEP--------- | PCE-気力|<------------------------------------------->| PCE-気力| --------- PCC-PCE通信プロトコル---------
Figure 12: Multiple PCC Policy Repositories
図12: 複数のPCC方針倉庫
Bryskin, et al. Informational [Page 26] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [26ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
6.4. Policy Configuration Management
6.4. 方針構成管理
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によって使用された経路計算方針情報の管理があります。 枠組みは、そのような情報が典型的な方針管理技術を使用することでインストールされて、取り外されて、別の方法で管理されると仮定します。 方針Repositoriesは政策管理/発見プロトコルとアプリケーションでダイナミックに居住されていて、静的な構成、標準の、そして、独占である政策管理ツールを通して管理されているか、または同等であるかもしれません。
7. Inter-Component Communication
7. 相互コンポーネントコミュニケーション
7.1. Policy Communication
7.1. 方針コミュニケーション
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に適用されるだけである場合では、PCEがサービスかユーザ特定保険証券を適用するように、PCC-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に提供しなければならない方針情報を含むかもしれません。
Bryskin, et al. Informational [Page 27] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [27ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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か1組のPCE-PEPsは要求応答タイプPCC-PCE Communicationプロトコルで交信します[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 ゼロか以下の形式の、より多くの方針記述子: <方針名前>、<方針variable1名前>、<param11>、<param12>…<param1N><方針variable2名前>、<param21>、<param12>…<param2N>… <方針variableMは>、<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 Communicationプロトコルは、経路計算要求と応答で指定された方針の意味論に関して少しの仮定も方針情報に輸送を提供して、理解して、するべきではありません。
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が1セットの方針を使用する、(より多く、PCPIM政策変数) 正確にサービス特有の情報について説明すること。 [PCEP]などのPCC-PCE通信プロトコルでこれらの方針を経路計算要求の中に置いて、PCEに渡すかもしれません。 この情報を理解して、規制を決定するのにそれを使用するために予想されるのと最適化機能はローカルの方針を適用しています。PCE、(より正確である、PCE-PEP)、(すなわち、関連PCE-PDP(s))によって局所的に構成されたか、または提供された方針。
Bryskin, et al. Informational [Page 28] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [28ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
7.2. PCE Discovery Policy Considerations
7.2. PCE発見方針問題
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が自動的にPCEsの1セットを発見するのを許容します(情報を含むのが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発見プロトコルかPCC-PCE通信プロトコルのどちらかを使用することでこの情報を分配すると考慮するので、後者も方針を受けることがあります。 1つの重要な政策決定がこのような関係においてはこの情報が厳密に言うと「発見」情報でないときに特に分配されるべき情報の本質である、むしろ、PCEは変化を述べます。 クライアントの特定、そして、ドメイン特定保険証券は、この情報が分配されるべきであるかどうか決めるとき、当てはまられていて、(すなわち、どのPCCs、そして/または、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.
方針が適用される別の場所は管理境界にあります。 マルチドメインネットワークでは、複数のPCEsが互いと、そして、管理境界の向こう側に交信するでしょう。 そのような場合、ドメイン特定保険証券が情報が発見の過程の間にじっと見るPCEsの間で交換した1)フィルタに適用されるだろう、(最低限、多くの場合安全保障政策によってせいぜい許容される、)、2は)経路計算要求と応答で通過される情報の内容を制限します。
8. Path Computation Sequence of Events
8. 出来事の経路計算系列
This section presents a non-exhaustive list of representative scenarios.
このセクションは代表しているシナリオに関する非完全なりストを提示します。
8.1. Policy-Enabled PCC, Policy-Enabled PCE
8.1. 方針で可能にされたPCC、方針で可能にされたPCE
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からSetup(RSVP Path)メッセージを受け取るとき、LSRは、リモートPath Computation Entityを使用すると決めるかもしれません。 出来事の以下の系列はこの場合起こります:
- 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
- LSRと共に共同見つけられたPCC-PEPは、サービス経路計算のためにPCEを選択して、経路計算要求を組み込むためにサービス特定保険証券を適用します。(それがそう、リストを選択します。
Bryskin, et al. Informational [Page 29] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [29ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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:
サービス経路計算に、適切な規制、相違、目的関数、および緩和戦略を言い表す方針、それらの変数、状態、および動作) 方針は以下の通りです。
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) いつ今までのところPCC-PEPにおいて知られている方針でまだいくつかの新しくサービスの詳細をカバーしていないかを予測する(ケースの大部分)か場合におけるPCC-PEPによる明白な要求に関するSOAPなどのプロトコルを通したリモートであるか地方のPCC-PDPによる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など)などと同様にシグナリングメッセージで見つけられた情報です。 経路計算要求が組立していた後に、直接PCC-PCE Communicationプロトコル例えば、[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は、クライアントとドメイン特定保険証券と同様に要求で見つけられた方針を適用しながら、要求を処理します。 後者は、再びSOAPなどのプロトコルでPCE-PEPで静的に構成されるか、または関連地方の、または、リモートな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-PEPは、地方の経路計算を実行するよう共同見つけられた経路演算処理エンジンに命令して、必要なら、PCC-PCE Communicationプロトコルを使用することで中で次に、鎖を作っているPCEに経路計算要求を送ります。 次に、それは、PCCを使用することで地方の経路演算処理エンジンとリモートPCEから応答を待っていて、結果として起こる経路を結合して、それらをPCC-PEPに送り返します。
Bryskin, et al. Informational [Page 30] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [30ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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は、送信するSetupメッセージに容認された経路をコード化するようGMPLS LSRのシグナリングサブシステムに命令します。
8.2. Policy-Ignorant PCC, Policy-Enabled PCE
8.2. 方針無知なPCC、方針で可能にされたPCE
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からSetup(RSVP Path)メッセージを受け取ったとき、一方、LSRが、aを使用すると決めるかもしれない、非、-、共同、-、見つけられたPath Computation Entity。 出来事の以下の系列はこの場合起こります:
- 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、E-NNIなど)などなどのいかなる他のサービス特殊情報と同様にシグナリング/食糧を供給するメッセージで見つけられた情報を使用することでPCE要求を構成します。 この情報は政策変数の形で要求でコード化されます。 要求が組立していた後に、PCC-PCE Communicationプロトコルを使用することで直接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は、要求で見つけられた政策変数を解釈して、実際の経路計算要求を組み込むためにユーザ、サービス、クライアント、およびドメイン特定保険証券を適用しながら、要求を処理します。 方針は、再びSOAPなどのプロトコルでPCE-PEPで静的に構成されるか、または関連地方の、または、リモートな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に送られるという経路計算要求。
Bryskin, et al. Informational [Page 31] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [31ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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 Communicationプロトコルを使用することで中で次に、鎖を作っているPCEに経路計算要求を送ります。 次に、それは、PCC- PCE Communicationプロトコルを使用することで地方の経路演算処理エンジンとリモート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は、送信するSetupメッセージに容認された経路をコード化するようGMPLS LSRのシグナリングサブシステムに命令します。
9. Introduction of New Constraints
9. 新しい規制の導入
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とPCEsは少しの変更も必要としてはいけません。
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).
ソフトウェアが以前にそのドメインで支持されなかったPolarization Modeディアスポラ(PMD)などの光の物理的な損傷規制を支持している状態でPCEがアップグレードしたケースを考えてください。 この場合、1つ以上の新しい政策が、規制(アプリケーション評価基準を決定する規則、政策変数のセット、状態、動作など)とその緩和戦略(または、戦略)を定義しながら、PCE Policy Repository(PCEに関連している)にインストールされるでしょう。 また、新しい政策はドメインの中で発見と同期プロトコルか地方の構成で他のPCE Policy Repositoriesに伝播されるでしょう。 そして、PCE-PDPsとPCC-PDPsは倉庫(または、倉庫)から対応する方針を検索するでしょう。 それ以来、PCC-PDPsは、あるパラメタ(例えば光学チャンネル(OCh)層の中で食糧を供給されたサービスのために)でサービスを求める経路計算要求に新しい政策情報を追加するよう関連PCC-PEPsに命令するでしょう。
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
方針で可能にされた経路計算モデルが自然にPCE能力発見問題を解決することに注意するのは重要です。 ただ一つのPCE Policy Repository構成で働いているPCEが新しい規制を支持し始めると仮定してください。 かつてのインストールされた対応する方針
Bryskin, et al. Informational [Page 32] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [32ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
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.
倉庫であり、それは自動的にすなわち、すべての倉庫ユーザ、PCCsに利用可能になります。 マルチ倉庫場合では、何らかの方針同期を提供しなければなりません。 しかしながら、この問題は既に解決されている管理飛行機の1つです。
10. Security Considerations
10. セキュリティ問題
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 Policy Repositoriesで保守された方針情報に関連する問題と方針関連の取引であると考えるのが現在、特に、必要です。 最も注目に値する問題(また、それの或るものは[RFC4655]に記載されている)は以下の通りです。
- Unauthorized access to the PCE Policy Repositories;
- PCE Policy Repositoriesへの不正アクセス。
- Interception of policy information when it is retrieved from the
repositories and/or transported from PDPs to PEPs;
- それがいつ倉庫から検索される、そして/または、PDPsから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局面を記述すると予想されて。
11. Acknowledgments
11. 承認
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ヴァンder Merweに感謝申し上げます。
Bryskin, et al. Informational [Page 33] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [33ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[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.ゲラン、「方針ベースの入場コントロールのための枠組み」、RFC2753、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仕様」、RFC3060、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[RFC3460] ムーア、B.、エド、「方針コア情報モデル(PCIM)拡大」、RFC3460、1月2003日
[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.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[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.、ランベルク、Y.、Strassner、J.、コーエン、R.、およびB.ムーア、「方針サービスの質(QoS)情報モデル」、RFC3644(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)要件を設計すること」でのRFC4216、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)ベースの構造」、RFC4655、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.、「相互領域MPLSとGMPLS交通のための経路計算要素通信プロトコル(PCECP)決められた一定の要求は設計すること」でのRFC4927(2007年6月)。
12.2. Informative References
12.2. 有益な参照
[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]一般的な情報Model(CIM)図式、バージョン2.x。 分配されたManagement Task Force Inc.、CIM v2.x図式の成分は以下のDMTFウェブページのリンクを通して利用可能です: http://www.dmtf.org/standards/standard_cim.php 。
Bryskin, et al. Informational [Page 34] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [34ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
[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]は2006年9月11日にder Merwe、J.、他、「知的なルートサービス制御ポイントとのダイナミックな接続性管理」、インターネットNetwork Management(INM)、ピサ、イタリアのACM SIGCOMM Workshopをバンに積みます。
[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)」、処理中の作業、11月2008
[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.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[RFC3080] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、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.、Huynh、A.、カールソン、M.、ペリー、J.、およびS.Waldbusser、「方針を拠点とする管理のための用語」、RFC3198(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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、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.、チャン、R.、およびK.Kumaki、「相互、経路計算要素通信プロトコル(PCECP)のための要件、」、RFC5376(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.、「バージョン1.2第1部を石けんでこすってください」 「メッセージング枠組み」、W3C REC REC-soap12-part1-20030624、2003年6月。
Bryskin, et al. Informational [Page 35] RFC 5394 Policy-Enabled Path Computation December 2008
Bryskin、他 [35ページ]情報のRFC5394の方針で可能にされた経路計算2008年12月
Authors' Addresses
作者のアドレス
Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
光学イーゴリの7926ジョーンズ支店ドライブBryskin ADVA Suite615マクリーン、ヴァージニア 22102はメールされます: ibryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
ディミトリPapadimitriouアルカテルフラン。 Wellesplein1、B-2018アントウェルペン(ベルギー)は以下に電話をします。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be
Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net
ルウバーガーLabNが相談して、LLCは以下に電話をします。 +1 9228年の301 468メール: lberger@labn.net
Jerry Ash AT&T EMail: gash5107@yahoo.com
ジェリー灰のAT&Tメール: gash5107@yahoo.com
Bryskin, et al. Informational [Page 36]
Bryskin、他 情報[36ページ]
一覧
スポンサーリンク
