RFC4655 日本語訳
4655 A Path Computation Element (PCE)-Based Architecture. A. Farrel,J.-P. Vasseur, J. Ash. August 2006. (Format: TXT=97561 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Farrel
Request for Comments: 4655 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
J. Ash
AT&T
August 2006
コメントを求めるワーキンググループA.ファレル要求をネットワークでつないでください: 4655年の古い犬のコンサルティングカテゴリ: 情報のJ.-P。 VasseurシスコシステムズInc.J.灰のAT&T2006年8月
A Path Computation Element (PCE)-Based Architecture
経路の計算の要素の(PCE)ベースのアーキテクチャ
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) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
規制ベースの経路計算はMultiprotocol Label Switching(MPLS)とGeneralized Multiprotocol Label Switching(GMPLS)ネットワークなどのトラフィックエンジニアリング・システムのための基本的なブロックです。 大きいか、マルチドメインの、または、マルチ領域の、または、マルチ層のネットワークにおける経路計算は、複雑であり、異なったネットワークドメインの間の特別なコンピュータのコンポーネントと協力を必要とするかもしれません。
This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.
Path Computation Elementの(PCE)ベースのモデルが、この問題がスペースであると扱うように、このドキュメントはアーキテクチャを指定します。 このドキュメントは、すべての建築構成の詳述を提供するのを試みませんが、むしろそれはソリューションが構成されるかもしれないPCEアーキテクチャのために1セットのブロックについて説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility .........................................7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............7
4.4. Node Outside the Routing Domain ............................8
1. 序論…3 2. 用語…3 3. 定義…4 4. PCEベースのアーキテクチャに関する動機…6 4.1. CPU徹底的な経路計算…6 4.2. 部分的な目に見えること…7 4.3. TEDの不在か可能にされた非Te IGPの使用…7 4.4. 経路ドメインの外のノード…8
Farrel, et al. Informational [Page 1] RFC 4655 PCE Architecture August 2006
ファレル、他 [1ページ]情報のRFC4655PCEアーキテクチャ2006年8月
4.5. Network Element Lacks Control Plane or Routing Capability ..8
4.6. Backup Path Computation for Bandwidth Protection ...........8
4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ......................................9
4.9. Non-Motivations ...........................................10
4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................11
5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE
Communication .............................................14
5.5. Management-Based PCE Usage ................................15
5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model .............................16
6.2. Distributed Computation Model .............................17
6.3. Synchronization ...........................................17
6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ...................................22
6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................25
6.10. Confidentiality ..........................................25
6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................28
6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ......................31
8. Evaluation Metrics .............................................32
9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring .........................34
9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional
Components ................................................35
9.6. Impact on Network Operation ...............................36
9.7. Other Considerations ......................................36
10. Security Considerations .......................................37
11. Acknowledgements ..............................................37
12. Informative References ........................................38
4.5. ネットワーク要素欠乏は飛行機かルート設定能力を制御します。8 4.6. 帯域幅保護のための経路計算のバックアップをとってください…8 4.7. マルチ層のネットワーク…9 4.8. 経路選択方針…9 4.9. 非動機…10 4.9.1. 全体のインターネット…10 4.9.2. Te LSP設立を保証します…10 5. PCEベースのアーキテクチャの概要…11 5.1. PCEノードを合成してください…11 5.2. 外部のPCE…12 5.3. 複数のPCE経路計算…13 5.4. 相互PCEコミュニケーションとの複数のPCE経路計算…14 5.5. 管理ベースのPCE用法…15 5.6. 標準化のための領域…16 6. PCEの建築問題…16 6.1. 計算モデルを集結します…16 6.2. 分散型計算方式モデル…17 6.3. 同期…17 6.4. PCE発見とロードバランシング…18 6.5. PCE活性を検出します…20 6.6. PCC-PCEとPCE-PCEコミュニケーション…20 6.7. PCE TED同期…22 6.8. Stateful対状態がないPCEs…23 6.9. モニターします。25 6.10. 秘密性…25 6.11. 方針…26 6.11.1. PCE方針アーキテクチャ…26 6.11.2. 方針実現…28 6.11.3. 方針のタイプ…28 6.11.4. シグナリングとの関係…29 6.12. 求められていない相互作用…30 6.13. Crankbackとの関係…30 7. 経路計算クライアントからの視点…31 8. 評価測定基準…32 9. 管理可能性問題…33 9.1. 機能と方針のコントロール…33 9.2. 情報とデータはモデル化されます…34 9.3. 活性検出であってモニターすること…34 9.4. 正しい操作について確かめます…35 9.5. 他のプロトコルと機能部品に関する要件…35 9.6. ネットワーク操作のときに、影響を与えてください…36 9.7. 他の問題…36 10. セキュリティ問題…37 11. 承認…37 12. 有益な参照…38
Farrel, et al. Informational [Page 2] RFC 4655 PCE Architecture August 2006
ファレル、他 [2ページ]情報のRFC4655PCEアーキテクチャ2006年8月
1. Introduction
1. 序論
Constraint-based path computation is a fundamental building block for traffic engineering in MPLS [RFC3209] and GMPLS [RFC3473] networks. [RFC2702] describes requirements for traffic engineering in MPLS networks, while [RFC4105] and [RFC4216] describe traffic engineering requirements in inter-area and inter-AS environments, respectively.
規制ベースの経路計算はMPLS[RFC3209]とGMPLS[RFC3473]ネットワークにおける交通工学のための基本的なブロックです。 [RFC2702]は[RFC4105]と[RFC4216]が相互領域の交通工学要件と相互AS環境について説明しますが、MPLSの工学がそれぞれネットワークでつなぐトラフィックのための要件について説明します。
Path computation in large, multi-domain networks is complex and may require special computational components and cooperation between the elements in different domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.
大きくて、マルチドメインのネットワークにおける経路計算は、複雑であり、異なったドメインの要素の間の特別なコンピュータのコンポーネントと協力を必要とするかもしれません。 Path Computation Elementの(PCE)ベースのモデルが、この問題がスペースであると扱うように、このドキュメントはアーキテクチャを指定します。
This document describes a set of building blocks for the PCE architecture from which solutions may be constructed. For example, it discusses PCE-based implementations including composite, external, and multiple PCE path computation. Furthermore, it discusses architectural considerations including centralized computation, distributed computation, synchronization, PCE discovery and load balancing, detection of PCE liveness, communication between Path Computation Clients (PCCs) and the PCE (PCC-PCE communication) and PCE-PCE communication, Traffic Engineering Database (TED) synchronization, stateful and stateless PCEs, monitoring, policy and confidentiality, and evaluation metrics.
このドキュメントはソリューションが構成されるかもしれないPCEアーキテクチャのために1セットのブロックについて説明します。 例えば、それは合成し、外部、および複数のPCE経路計算を含むPCEベースの実装について議論します。 その上、それは集結された計算、分散型計算方式、同期、PCE発見、ロードバランシング、PCE活性の検出、Path Computation Clients(PCCs)とPCEとのコミュニケーション(PCC-PCEコミュニケーション)とPCE-PCEコミュニケーション、Traffic Engineering Database(TED)同期、statefulであって状態がないPCEs、モニター、方針、秘密性、および評価測定基準を含む建築問題について議論します。
The model of the Internet is to distribute network functionality (e.g., routing) within the network. PCE functionality is not intended to contradict this model and can be used to match the model exactly, for example, when the PCE functionality coexists with each Label Switching Router (LSR) in the network. PCE is also able to augment functionality in the network where the Internet model cannot supply adequate solutions, for example, where traffic engineering information is not exchanged between network domains.
インターネットのモデルはネットワークの中でネットワークの機能性(例えば、ルーティング)を分配することになっています。 PCEの機能性は、このモデルに逆らうことを意図しないで、ちょうど、例えばモデルを合わせるのに使用できます、PCEの機能性がネットワークにおける各Label Switching Router(LSR)と共存すると。 また、PCEは例えばインターネットモデルが交通工学情報がネットワークドメインの間で交換されないところに適切な解決法を供給できないネットワークで機能性を増大させることができます。
2. Terminology
2. 用語
CSPF: Constraint-based Shortest Path First.
CSPF: 最短パス規制ベースの1番目。
LER: Label Edge Router.
LER: 縁のルータをラベルしてください。
LSDB: Link State Database.
LSDB: 州のデータベースをリンクしてください。
LSP: Label Switched Path.
LSP: ラベルは経路を切り換えました。
LSR: Label Switching Router.
LSR: 切り換えルータをラベルしてください。
Farrel, et al. Informational [Page 3] RFC 4655 PCE Architecture August 2006
ファレル、他 [3ページ]情報のRFC4655PCEアーキテクチャ2006年8月
PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element.
PCC: 経路計算クライアント。 Path Computation Elementによって実行されるよう経路計算に要求するどんなクライアントアプリケーション。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints (see further description in Section 3).
PCE: 経路計算要素。 ネットワーク経路かルートを計算できる実体(コンポーネント、アプリケーション、またはネットワーク・ノード)はグラフと適用のコンピュータの規制をネットワークに基礎づけました(セクション3でさらなる記述を見てください)。
TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means.
テッド: トラフィックEngineering Database。(そのEngineering Databaseはドメインのトポロジーとリソース情報を含みます)。 他の手段はInteriorゲートウェイプロトコル(IGP)拡大で潜在的にTEDを与えるかもしれません。
TE LSP: Traffic Engineering MPLS Label Switched Path.
Te LSP: MPLSがラベルする交通工学は経路を切り換えました。
3. Definitions
3. 定義
A Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc. For example, a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request.
Path Computation Element(PCE)はネットワークグラフに基づくネットワーク経路かルートを計算して、計算の間にコンピュータの規制を適用できる実体です。 PCE実体はネットワーク・ノードかコンポーネントの中に位置できるアプリケーションです、ネットワークで出ているサーバなどで 例えば、帯域幅と他の規制がTE LSPサービスのリクエストに適切であるとTEDを作動させて、考えることによって、PCEはTE LSPの経路を計算できるでしょう。
A domain is any collection of network elements within a common sphere of address management or path computation responsibility. Examples of domains include IGP areas, Autonomous Systems (ASes), and multiple ASes within a Service Provider network. Domains of path computation responsibility may also exist as sub-domains of areas or ASes.
ドメインはアドレス管理か経路計算責任の一般的な球の中のネットワーク要素のあらゆる収集です。 ドメインに関する例はIGP領域、Autonomous Systems(ASes)、およびService Providerネットワークの中の複数のASesを含んでいます。 また、経路計算責任のドメインは領域かASesに関するサブドメインとして存在するかもしれません。
In order to fully characterize a PCE and clarify these definitions, the following important considerations must also be examined:
また、PCEを完全に特徴付けて、これらの定義をはっきりさせるために、以下の重要な問題を調べなければなりません:
1) Path computation is applicable in intra-domain, inter-domain, and
inter-layer contexts.
1) 経路計算はイントラドメイン、相互ドメイン、および相互層の文脈で適切です。
a. Inter-domain path computation may involve the association of
topology, routing, and policy information from multiple domains
from which relationships may be deduced in order to help in
performing path computation.
a。 相互ドメイン経路計算は関係が経路計算を実行するのを手伝うために推論されるかもしれない複数のドメインからのトポロジー、ルーティング、および方針情報の協会にかかわるかもしれません。
b. Inter-layer path computation refers to the use of PCE where
multiple layers are involved and when the objective is to
perform path computation at one or multiple layers while taking
into account topology and resource information at these layers.
b。 相互層の経路計算は目的が複数の層がかかわって、これらの層でトポロジーとリソース情報を考慮に入れている間、1か複数の層で経路計算を実行することであることのPCEの使用について言及します。
Farrel, et al. Informational [Page 4] RFC 4655 PCE Architecture August 2006
ファレル、他 [4ページ]情報のRFC4655PCEアーキテクチャ2006年8月
Overlapping domains are not within the scope of this document. In
the inter-domain case, the domains may belong to a single or to
multiple Service Providers.
このドキュメントの範囲の中に重なっているドメインがありません。 相互ドメイン場合では、ドメインはシングル、または、複数のService Providersに属するかもしれません。
2) a. In "single PCE path computation", a single PCE is used to
compute a given path in a domain. There may be multiple PCEs
in a domain, but only one PCE per domain is involved in any
single path computation.
2) a。 「ただ一つのPCE経路計算」では、独身のPCEは、ドメインで与えられた経路を計算するのに使用されます。 複数のPCEsがドメインにあるかもしれませんが、1ドメインあたり1PCEだけがどんなただ一つの経路計算にもかかわります。
b. In "multiple PCE path computation", multiple PCEs are used to
compute a given path in a domain.
b。 「複数のPCE経路計算」では、複数のPCEsが、ドメインで与えられた経路を計算するのに使用されます。
3) a. "Centralized computation model" refers to a model whereby all
paths in a domain are computed by a single, centralized PCE.
3) a。 「集結された計算モデル」はドメインのすべての経路が単一の、そして、集結されたPCEによって計算されるモデルを示します。
b. Conversely, "distributed computation model" refers to the
computation of paths in a domain being shared among multiple
PCEs.
b。 逆に、「分散型計算方式モデル」は複数のPCEsの中で共有されるドメインでの経路の計算を示します。
Paths that span multiple domains may be computed using the
distributed model with one or more PCEs responsible for each
domain, or the centralized model by defining a domain that
encompasses all the other domains.
複数のドメインにかかる経路は、他のすべてのドメインを取り囲むドメインを定義することによって各ドメインに責任がある1PCEsの分配されたモデル、または集結されたモデルを使用することで計算されるかもしれません。
From these definitions, a centralized computation model inherently
uses single PCE path computation. However, a distributed
computation model could use either single PCE path computation or
multiple PCE path computations. There would be no such thing as a
centralized model that uses multiple PCEs.
これらの定義から、集結された計算モデルは本来ただ一つのPCE経路計算を使用します。 しかしながら、分散型計算方式モデルはただ一つのPCE経路計算か複数のPCE経路計算のどちらかを使用できました。 複数のPCEsを使用する集結されたモデルなんてことがないでしょう。
4) The PCE may or may not be located at the head-end of the path.
For example, a conventional intra-domain solution is to have path
computation performed by the head-end LSR of an MPLS TE LSP; in
this case, the head-end LSR contains a PCE. But solutions also
exist where other nodes on the path must contribute to the path
computation (for example, loose hops), making them PCEs in their
own right. At the same time, the path computation may be made by
some other PCE physically distinct from the computed path.
4) PCEは経路のギヤエンドに位置するかもしれません。 例えば、従来のイントラドメインソリューションはMPLS TE LSPのギヤエンドLSRまでに経路計算を実行させることです。 この場合、ギヤエンドLSRはPCEを含みます。 しかし、また、ソリューションは経路の他のノードが経路計算に貢献しなければならない(例えば、ホップを発射してください)ところに存在していて、作っているそれらはそれら自身の権利でPCEsです。 同時に、経路計算は計算された経路と物理的に異なったある他のPCEによってされるかもしれません。
5) The path computed by the PCE may be an "explicit path" (that is,
the full explicit path from start to destination, made of a list
of strict hops) or a "strict/loose path" (that is, a mix of strict
and loose hops comprising at least one loose hop representing the
destination), where a hop may be an abstract node such as an AS.
5) PCEによって計算された経路は、「明白な経路」(すなわち、完全な明白な始めから厳しいホップのリストで作られた目的地までの経路)かホップがASなどの抽象的なノードであるかもしれない「厳しいかゆるい経路」であるかもしれません(すなわち、目的地を表す少なくとも1つのゆるいホップを包括する厳しくてゆるいホップのミックス)。
6) A PCE-based path computation model does not mean to be exclusive
and can be used in conjunction with other path computation models.
For instance, the path of an inter-AS TE LSP may be computed using
6) PCEベースの経路計算モデルは、排他的であることを意味しないで、他の経路計算モデルに関連して使用できます。 例えば、相互AS TE LSPの経路は計算された使用であるかもしれません。
Farrel, et al. Informational [Page 5] RFC 4655 PCE Architecture August 2006
ファレル、他 [5ページ]情報のRFC4655PCEアーキテクチャ2006年8月
a PCE-based path computation model in some ASes, whereas the set
of traversed ASes may be specified by other means (not determined
by a PCE). Furthermore, different path computation models may be
used for different TE LSPs.
他の手段(PCEによって決定されない)で横断されたASesのセットは指定されるかもしれませんが、いくつかのASesのPCEベースの経路計算モデル。 その上、異なった経路計算モデルは異なったTE LSPsに使用されるかもしれません。
7) This document does not make any assumptions about the nature or
implementation of a PCE. A PCE could be implemented on a router,
an LSR, a dedicated network server, etc. Moreover, the PCE
function is orthogonal to the forwarding capability of the node on
which it is implemented.
7) このドキュメントはPCEの自然か実装に関する少しの仮定もしません。 ルータ、LSR、ひたむきなネットワークサーバなどでPCEを実装することができました。 そのうえ、PCE機能はそれが実装されるノードの推進能力と直交しています。
4. Motivation for a PCE-Based Architecture
4. PCEベースのアーキテクチャに関する動機
Several motivations for a PCE-based architecture (described in Section 5) are listed below. This list is not meant to be exhaustive and is provided for the sake of illustration.
PCEベースのアーキテクチャ(セクション5では、説明される)に関するいくつかの動機が以下に記載されています。 このリストを徹底的であることを意味しないで、イラストのために前提とします。
It should be highlighted that the aim of this section is to provide some application examples for which a PCE-based path may be suitable: this also clearly states that such a model does not aim to replace existing path computation models but would apply to specific existing or future situations.
それは目立つべきです。どのa PCEベースの経路にいくつかのアプリケーションの例をこのセクションの目的がことである提供するかは適当であるかもしれません: また、これは、そのようなモデルが既存の経路計算モデルを置き換えることを目指しませんが、特定の存在か将来の状況に当てはまると明確に述べます。
As can be seen from these examples, PCE does not replace the existing Internet model where intelligence is distributed within the network. Instead, it builds on this model and makes use of distributed centers of information or computational ability. PCE should not, therefore, necessarily be seen as a centralized, "all-seeing oracle in the sky", but as the cooperative operation of distributed functionality used to address specific challenges such as the computation of a shortest inter-domain constrained path.
これらの例から見ることができるように、PCEは知性がネットワークの中で分配される既存のインターネットモデルを置き換えません。 代わりに、それは、このモデルの上に建てて、情報かコンピュータの能力の分配されたセンターを利用します。 したがって、最も短い相互ドメインの計算などの集結されて、「オール空の神託を見ます」が分散機能性の操作が以前はよくそうしていた協同組合としてアドレス特有の挑戦が経路を抑制したので、必ずPCEを見るべきであるというわけではありません。
4.1. CPU-Intensive Path Computation
4.1. CPU徹底的な経路計算
There are many situations where the computation of a path may be highly CPU-intensive; examples of CPU-intensive path computations include the resolution of problems such as:
多くの状況が経路の計算がCPU非常に徹底的であるかもしれないところにあります。 CPU徹底的な経路計算に関する例は以下などの問題の解決を含んでいます。
- Placing a set of TE LSPs within a domain so as to optimize an
objective function (for example, minimization of the maximum link
utilization)
- 目的関数を最適化するためにドメインの中にTE LSPsの1セットを置きます。(例えば、最大のリンク利用の最小化)
- Multi-criteria path computation (for example, delay and link
utilization, inclusion of switching capabilities, adaptation
features, encoding types and optical constraints within a GMPLS
optical network)
- マルチ評価基準経路計算(例えば、GMPLSの光学ネットワークの中のスイッチング能力、適合機能、タイプをコード化して、および光の規制の遅れとリンク利用、包含)
Farrel, et al. Informational [Page 6] RFC 4655 PCE Architecture August 2006
ファレル、他 [6ページ]情報のRFC4655PCEアーキテクチャ2006年8月
- Computation of minimal cost Point to Multipoint trees (Steiner
trees)
- Multipoint木への最小量の費用Pointの計算(スタイナー木)
In these situations, it may not be possible or desirable for some routers to perform path computation because of the constraints on their CPUs, in which case the path computations may be off-loaded to some other PCE(s) that may, themselves, be routers or may be dedicated PCE servers.
それは、これらの状況で、いくつかのルータが規制のためにそれらのCPUに経路計算を実行するのにおいて、可能であるか、または望ましいです、その場合、経路計算はそうするかもしれないある他のPCE(s)へ積み下ろされるかもしれません、自分たちということでないかもしれないルータであるかひたむきなPCEサーバであるかもしれません。
4.2. Partial Visibility
4.2. 部分的な目に見えること
There are several scenarios where the node responsible for path computation has limited visibility of the network topology to the destination. This limitation may occur, for instance, when an ingress router attempts to establish a TE LSP to a destination that lies in a separate domain, since TE information is not exchanged across the domain boundaries. In such cases, it is possible to use loose routes to establish the TE LSP, relying on routers at the domain borders to establish the next piece of the path. However, it is not possible to guarantee that the optimal (shortest) path will be used, or even that a viable path will be discovered except, possibly, through repeated trial and error using crankback or other signaling extensions.
いくつかのシナリオが経路計算に原因となるノードがネットワーク形態の目に見えることを目的地に制限したところにあります。 イングレスルータが、別々のドメインに位置する目的地にTE LSPを設立するのを試みるとき、例えば、この制限は起こるかもしれません、TE情報がドメイン境界の向こう側に交換されないので。 そのような場合、TE LSPを証明するのにゆるいルートを使用するのは可能です、経路の次の断片を証明するためにドメイン境界でルータを当てにして。 しかしながら、最適(最も短い)の経路が使用されるか、または実行可能な経路が発見さえされるのを保証するのにおいて可能です、ことによると、crankbackを使用する試行錯誤か他のシグナリング拡大が通じて繰り返したということではありません。
This problem of inter-domain path computation may most probably be addressed through distributed computation with cooperation among PCEs within each of the domains, and potentially using crankback between the domains to dynamically resolve provisioning issues. Alternatively, a central "all-seeing" PCE that has access to the complete set of topology information may be used, but in this case there are challenges of scalability (both the size of the TED and the responsiveness of a single PCE handling requests for many domains) and of preservation of confidentiality when the domains belong to different Service Providers.
相互ドメイン経路計算のこの問題は最もたぶん分散型計算方式でそれぞれのドメインの中のPCEsの中の協力と問題に食糧を供給しながらダイナミックに決議するドメインの間で潜在的にcrankbackを使用する状態で扱われるかもしれません。 あるいはまた、完全なトポロジー情報に近づく手段を持っている中央の「オールの見る」PCEは使用されるかもしれませんが、ドメインがこの場合異なったService Providersに属すとき、スケーラビリティ(多くのドメインを求める要求を扱うTEDのサイズと独身のPCEの反応性の両方)と機密保持の挑戦があります。
Note that the issues described here can be further highlighted in the context of TE LSP reoptimization, or the establishment of multiple diverse TE LSPs for protection or load sharing.
保護か負荷分割法のためにTE LSP reoptimizationの文脈、または複数のさまざまのTE LSPsの設立でここで説明された問題はさらに強調できることに注意してください。
4.3. Absence of the TED or Use of Non-TE-Enabled IGP
4.3. TEDの不在か可能にされた非Te IGPの使用
The traffic engineering database (TED) may be a large drain on the resources of a network node (such as an edge router or LER). Maintaining the TED may require a lot of memory and may require non- negligible CPU activity. The use of a distinct PCE may be appropriate in such circumstances, and a separate node can be used to establish and maintain the TED, and to make it available for path computation.
交通工学データベース(TED)はネットワーク・ノード(縁のルータかLERなどの)のリソースに関する大きいドレインであるかもしれません。 TEDを維持するのは、多くのメモリを必要として、非取るにたらないCPU活動を必要とするかもしれません。 異なったPCEの使用はそのような事情で適切であるかもしれません、そして、TEDを設立して、維持して、それを経路計算に利用可能にするのに別々のノードは使用できます。
Farrel, et al. Informational [Page 7] RFC 4655 PCE Architecture August 2006
ファレル、他 [7ページ]情報のRFC4655PCEアーキテクチャ2006年8月
The IGPs run within some networks are not sufficient to build a full TED. For example, a network may run OSPF/IS-IS without the OSPF-TE/ISIS-TE extensions, or some routers in the network may not support the TE extensions. In these cases, in order to successfully compute paths through the network, the TED must be constructed or supplemented through configuration action and updated as network resources are reserved or released. Such a TED could be distributed to the routers that need to perform path computation or held centrally (on a distinct node that supports PCE) for centralized computation.
いくつかのネットワークの中で実行されたIGPsは、完全なTEDを造るために十分ではありません。 例えば、ネットワークがOSPF/を実行するかもしれない、-、拡大、またはネットワークにおけるいくつかのルータがそうしないイシスOSPF-TE/TEがなければ、TE拡張子をサポートしてください。 これらの場合では、ネットワーク資源を予約するか、またはリリースするとき、ネットワークを通して首尾よく経路を計算するためにTEDを組み立てなければならないか、構成動作で補って、またはアップデートしなければなりません。 そのようなTEDを経路計算を実行する必要があるルータに分配したか、または集結された計算のために中心(PCEを支える異なったノードの上で)で持つことができました。
4.4. Node Outside the Routing Domain
4.4. 経路ドメインの外のノード
An LER might not be part of the routing domain for administrative reasons (for example, a customer-edge (CE) router connected to the provider-edge (PE) router in the context of MPLS VPN [RFC4364] and for which it is desired to provide a CE to CE TE LSP path).
LERは管理理由(例えば、顧客縁(CE)のルータがMPLS VPN[RFC4364]の文脈のプロバイダー縁(PE)のルータに関させて、それがCE TE LSP経路にCEを提供することが望まれている)による経路ドメインの一部でないかもしれません。
This scenario suggests a solution that does not involve doing computation on the ingress (TE LSP head-end, CE) router, and that does not rely on the configuration of static loose hops. In this case, optimal shortest paths cannot be guaranteed. A solution that a distinct PCE can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops.
このシナリオはイングレス(TE LSPギヤエンド、CE)ルータで計算することを伴わないで、また静的なゆるいホップの構成を当てにしないソリューションを示します。 この場合、最適の最短パスを保証できません。 異なったPCEがここで助けることができるソリューション。 PCEがこの場合そうするかもしれないというメモ(それ自体)はゆるいホップを含んでいる経路を提供します。
4.5. Network Element Lacks Control Plane or Routing Capability
4.5. ネットワーク要素欠乏は飛行機かルート設定能力を制御します。
It is common in legacy optical networks for the network elements not to have a control plane or routing capability. Such network elements only have a data plane and a management plane, and all cross- connections are made from the management plane. It is desirable in this case to run the path computation on the PCE, and to send the cross-connection commands to each node on the computed path. That is, the PCC would be an element of the management plane, perhaps residing in the Network Management System (NMS) or Operations Support System (OSS).
レガシーの光学ネットワークでは、ネットワーク要素に、制御飛行機かルーティング能力を持っていないのは一般的です。 そのようなネットワーク要素にはデータ飛行機と管理飛行機があるだけです、そして、すべての十字接続が管理飛行機から作られます。 この場合、経路計算をPCEに実行して、計算された経路で交差接続命令を各ノードに送るのは望ましいです。 すなわち、PCCは管理飛行機の要素でしょう、恐らくNetwork Management System(NMS)かOperations Support System(OSS)に住んでいて。
This scenario is important for Automatically Switched Optical Network (ASON)-capable networks and may also be used for interworking between GMPLS-capable and GMPLS-incapable networks.
このシナリオは、Automatically Switched Optical Network(ASON)のできるネットワークに重要であり、また、GMPLSできてGMPLS不可能なネットワークの間の織り込むのに使用されるかもしれません。
4.6. Backup Path Computation for Bandwidth Protection
4.6. 帯域幅保護のためのバックアップ経路計算
A PCE can be used to compute backup paths in the context of fast reroute protection of TE LSPs. In this model, all backup TE LSPs protecting a given facility are computed in a coordinated manner by a PCE. This allows complete bandwidth sharing between backup tunnels protecting independent elements, while avoiding any extensions to TE
速いことの文脈の経路がTE LSPsの保護を別ルートで送るバックアップを計算するのにPCEを使用できます。 このモデルでは、与えられた施設を保護するすべてのバックアップTE LSPsが連携方法でPCEによって計算されます。 これはどんな拡大もTEとして避けている間に独立している要素を保護するバックアップトンネルを平等に割り当てる完全な帯域幅を許容します。
Farrel, et al. Informational [Page 8] RFC 4655 PCE Architecture August 2006
ファレル、他 [8ページ]情報のRFC4655PCEアーキテクチャ2006年8月
LSP signaling. Both centralized and distributed computation models are applicable. In the distributed case each LSR can be a PCE to compute the paths of backup tunnels to protect against the failure of adjacent network links or nodes.
LSPシグナリング。 両方が集中しました、そして、分散型計算方式モデルは適切です。 分配された場合では、各LSRは、隣接しているネットワークリンクかノードの失敗から守るためにバックアップトンネルの経路を計算するためにはPCEであるかもしれません。
4.7. Multi-layer Networks
4.7. マルチ層のネットワーク
A server-layer network of one switching capability may support multiple networks of another (more granular) switching capability. For example, a Time-Division Multiplexing (TDM) network may provide connectivity for client-layer networks such as IP, MPLS, or Layer 2 [MLN].
1つのスイッチング能力のサーバ層のネットワークは別の(より粒状)のスイッチング能力の複数のネットワークをサポートするかもしれません。 例えば、Time-事業部Multiplexing(TDM)ネットワークはIP、MPLS、またはLayer2など[MLN]のクライアント層ネットワークに接続性を提供するかもしれません。
The server-layer network is unlikely to provide the same connectivity paradigm as the client networks, so bandwidth granularity in the server-layer network may be much coarser than in the client-layer network. Similarly, there is likely to be a management separation between the two networks providing independent address spaces. Furthermore, where multiple client-layer networks make use of the same server-layer network, those client-layer networks may have independent policies, control parameters, address spaces, and routing preferences.
サーバ層のネットワークがクライアントネットワークと同じ接続性パラダイムを提供しそうにないので、サーバ層のネットワークにおける帯域幅粒状はクライアント層ネットワークよりはるかに粗いかもしれません。 2つのネットワークの間には、同様に、管理分離があって、独立しているアドレス空間を提供しそうです。 その上、複数のクライアント層ネットワークが同じサーバ層のネットワークを利用するところでは、それらのクライアント層ネットワークは独立している方針、管理パラメータ、アドレス空間、およびルーティング好みを持っているかもしれません。
The different client- and server-layer networks may be considered distinct path computation regions within a PCE domain, so the PCE architecture is useful to allow path computation from one client- layer network region, across the server-layer network, to another client-layer network region.
異なったクライアントとサーバ層のネットワークがPCEドメインの中の異なった経路計算地域であると考えられるかもしれないので、PCEアーキテクチャは1つのクライアント層のネットワーク領域から経路計算を許すために役に立ちます、サーバ層のネットワークの向こう側に、別のクライアント層ネットワーク領域に。
In this case, the PCEs are responsible for resolving address space issues, handling differences in policy and control parameters, and coordinating resources between the networks. Note that, because of the differences in bandwidth granularity, connectivity across the server-layer network may be provided through virtual TE links or Forwarding Adjacencies: the PCE may offer a point of control responsible for the decision to provision new TE links or Forwarding Adjacencies across the server-layer network.
この場合、PCEsはアドレス空間問題を解決するのに責任があります、方針の違いと管理パラメータを扱って、ネットワークの間のリソースを調整して。 サーバ層のネットワークの向こう側の接続性が帯域幅粒状の違いのために仮想のTEリンクかForwarding Adjacenciesを通して提供されるかもしれないことに注意してください: PCEはサーバ層のネットワークの向こう側に支給の新しいTEリンクかForwarding Adjacenciesに決定に原因となるコントロールのポイントを提供するかもしれません。
4.8. Path Selection Policy
4.8. 経路選択方針
A PCE may have a local policy that impacts path computation and selection in response to a path computation request. Such policy may act on information provided by the requesting PCC. The result of applying such policy includes, for example, rejection of the path computation request, or provision of a path that does not meet all of the requested constraints. Further, the policy may support
PCEには、経路計算要求に対応して経路計算と選択に影響を与えるローカルの方針があるかもしれません。 そのような方針は要求しているPCCによって提供された情報に影響するかもしれません。 そのような方針を適用するという結果は例えば、経路計算要求の拒絶、または要求された規制のすべてに会わない経路の支給を含んでいます。 さらに、方針はサポートするかもしれません。
Farrel, et al. Informational [Page 9] RFC 4655 PCE Architecture August 2006
ファレル、他 [9ページ]情報のRFC4655PCEアーキテクチャ2006年8月
administratively configured paths, or selection among transit providers. Inclusion of policy within PCE may simplify the application of policy within the path computation/selection process.
行政上構成された経路、またはトランジットプロバイダーの中の選択。 PCEの中の方針の包含は経路計算/選択プロセスの中で方針の適用を簡素化するかもしれません。
Similarly, a PCC may apply local policy to the selection of a PCE to compute a specific path, and to the constraints that are requested.
同様に、PCCは特定の経路を計算するPCEの選択と、そして、要求されている規制にローカルの方針を適用するかもしれません。
In a PCE context, the policy may be sensitive to the type of path that is being computed. For example, a different set of policies may be applied for an intra-area or single-layer path than would be provided for an inter-area or multi-layer path.
PCE文脈では、計算されている経路のタイプに、方針は敏感であるかもしれません。 例えば、異なったセットの方針は相互領域かマルチ層の経路に提供するだろうよりイントラ領域か単一層経路に適用されるかもしれません。
Note that synchronization of policy between PCEs or between PCCs and PCEs may be necessary. Such issues are outside the scope of the PCE architecture, but within scope for the PCE policy framework and application which is described in a separate document.
PCEsかPCCsとPCEsの間の方針の同期が必要であるかもしれないことに注意してください。 そのような問題は、PCEアーキテクチャの範囲の外にありますが、PCE方針フレームワークとアプリケーションのための別々のドキュメントで説明される範囲の中にあります。
4.9. Non-Motivations
4.9. 非動機
4.9.1. The Whole Internet
4.9.1. 全体のインターネット
PCE is not considered to be a solution that is applicable to the entire Internet. That is, the applicability of PCE is limited to a set of domains with known relationships. The scale of this limitation is similar to the peering relationships between Service Providers.
PCEは全体のインターネットに適切な解決策であると考えられません。 すなわち、PCEの適用性は知られている関係で1セットのドメインに制限されます。 この制限のスケールはService Providersの間のじっと見る関係と同様です。
4.9.2. Guaranteed TE LSP Establishment
4.9.2. Te LSP設立に保証されます。
When two or more paths for TE LSPs are computed on the same set of TE link state information, it is possible that the resultant paths will compete for limited resources within the network. This may result in success for only the first TE LSP to be signaled, or it might even mean that no TE LSP can be established.
TE LSPsのための2つ以上の経路が同じセットのTEリンク州の情報で計算されるとき、結果の経路がネットワークの中で限りある資源を競争するのは、可能です。 これが合図されるべき最初のTE LSPだけのための成功をもたらすかもしれませんか、またはそれは、TE LSPを全く設立できないことを意味さえするかもしれません。
Batch processing of computation requests, back-off times, computation of alternate paths, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup. However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state.
計算要求のバッチ処理、下に後部回、代替パスの計算、およびcrankbackは、この種類の問題を緩和するのを助けることができます、そして、また、PCEはうまくいっているTE LSPセットアップの機会を改良するかもしれません。 しかしながら、ネットワーク失敗の可能性かリソースのための主張が集結されたTEDが完全に現在(すなわち、リアルタイムの)のネットワーク状態を反映できるというわけではないところにまだ存在しているので、単一の、そして、集結されたPCEはTE LSPに設立を保証できる解決策として見なされません。
Farrel, et al. Informational [Page 10] RFC 4655 PCE Architecture August 2006
ファレル、他 [10ページ]情報のRFC4655PCE構造2006年8月
5. Overview of the PCE-Based Architecture
5. PCEベースの構造の概観
This section gives an overview of the architecture of the PCE model. It needs to be read in conjunction with the details provided in the next section to provide a full view of the flexibility of the model.
このセクションはPCEモデルの構造の概観を与えます。 それは、モデルの柔軟性の全景を提供するために次のセクションに明らかにされる詳細に関連して読まれる必要があります。
5.1. Composite PCE Node
5.1. 合成PCEノード
Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests to provision TE LSPs are received by the node and converted into signaling requests, but this conversion may require path computation that is requested from a PCE. The PCE operates on the TED subject to local policy in order to respond with the requested path.
以下の図1は経路計算を利用する典型的な合成PCEノード(すなわち、また、PCEの機能性を実行するルータ)の成分を示しています。 ルーティング・プロトコルは、TEDが組み立てられるTE情報を交換するのに使用されます。 支給TE LSPsへのサービスのリクエストは、ノードによって受け取られて、シグナリング要求に変換されますが、この変換はPCEから要求される経路計算を必要とするかもしれません。 PCEは、要求された経路で応じるためにローカルの方針を条件としてTEDを作動させます。
---------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- | | |
| | | | | Adjacent |
| | PCE | | | Node |
| | | | | |
| --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------
--------------- | --------- | ルート設定---------- | | | | プロトコル| | | | テッド| <、-+----------+->。| | | | | | | | --------- | | | | | | | | | | 入力| | | | v| | | | --------- | | | | | | | | 隣接| | | PCE| | | ノード| | | | | | | | --------- | | | | ^ | | | | |要求| | | | |応答| | | | v| | | | --------- | | | サービス| | | | シグナリング| | 要求| |シグナリング| | プロトコル| | ------+->| エンジン| <、-+----------+->。| | | | | | | | --------- | ---------- ---------------
Figure 1. Composite PCE Node
図1。 合成PCEノード
Note that the routing adjacency between the composite PCE node and any other router may be performed by means of direct connectivity or any tunneling mechanism.
合成PCEノードといかなる他のルータの間のルーティング隣接番組がダイレクト接続性かどんなトンネリングメカニズムによって実行されるかもしれないことに注意してください。
Farrel, et al. Informational [Page 11] RFC 4655 PCE Architecture August 2006
ファレル、他 [11ページ]情報のRFC4655PCE構造2006年8月
5.2. External PCE
5.2. 外部のPCE
Figure 2 shows a PCE that is external to the requesting network element. A service request is received by the head-end node, and before it can initiate signaling to establish the service, it makes a path computation request to the external PCE. The PCE uses the TED subject to local policy as input to the computation and returns a response.
図2は要求しているネットワーク要素に外部であることのPCEを示しています。 ギヤエンドのノードでサービスのリクエストを受け取ります、そして、それはサービスを証明するためにシグナリングを開始できる前に経路計算要求を外部のPCEにします。 PCEは計算に入力されるようにローカルの方針を条件としてTEDを使用して、応答を返します。
----------
| ----- |
| | TED |<-+----------->
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
---------- | ----- | | | テッド| <、-+----------->| ----- | TED同期| | | メカニズム(例えば、ルーティング・プロトコル)| | | | v| | ----- | | | PCE| | | ----- | ---------- ^ | 要求/| 応答対Service---------- シグナリング---------- 要求| ギヤエンド| プロトコル| 隣接| ---->| ノード| <、-、-、-、-、-、-、-、-、--、>| ノード| ---------- ----------
Figure 2. External PCE Node
図2。 外部のPCEノード
Note that in this case, the node that supports the PCE function may also be an LSR or router performing forwarding in its own right (i.e., it may be a composite PCE node), but those functions are purely orthogonal to the operation of the function in the instance being considered here.
また、この場合、PCE機能をサポートするノードがそれ自体で推進を実行するLSRかルータであるかもしれないこと(すなわち、それは合成PCEノードであるかもしれない)にもかかわらずの、ここで考えられる場合それらの機能が純粋に例における、機能の操作と直交しているというメモ。
Farrel, et al. Informational [Page 12] RFC 4655 PCE Architecture August 2006
ファレル、他 [12ページ]情報のRFC4655PCE構造2006年8月
5.3. Multiple PCE Path Computation
5.3. 複数のPCE経路計算
Figure 3 illustrates how multiple PCE path computations may be performed along the path of a signaled service. As in the previous example, the head-end PCC makes a request to an external PCE, but the path that is returned is such that the next network element finds it necessary to perform further computation. This may be the case when the path returned is a partial path that does not reach the intended destination or when the computed path is loose. The downstream network element consults another PCE to establish the next hop(s) in the path. In this case, all policy decisions are made independently at each PCE based on information passed from the PCC.
図3は複数のPCE経路計算が合図されたサービスの経路に沿ってどう実行されるかもしれないかを例証します。 前の例のように、ギヤエンドPCCはさらなる計算を実行するのに必要な状態で外部のPCEへの要求、しかし、返しているのが、次のネットワーク要素がそれに当たるそのようなものであるということである経路を作ります。 返された経路が意図している目的地に達しない部分的な経路であるか計算された経路がゆるいときに、これはそうであるかもしれません。 川下のネットワーク要素は、次のホップを経路に証明するために別のPCEに相談します。 この場合、PCCから通過された情報に基づく各PCEで独自にすべての政策決定をします。
Note that either or both PCEs in this case could be composite PCE nodes, as in Section 5.1.
セクション5.1のようにこの場合、どちらかかPCEsの両方が合成PCEノードであるかもしれないことに注意してください。
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request |Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
---------- ---------- | | | | | PCE| | PCE| | | | | | ----- | | ----- | | | テッド| | | | テッド| | | ----- | | ----- | ---------- ---------- ^ ^ | 要求/| 要求/| 応答| 応答v対Service-------- シグナリング------------ シグナリング------------ 要求|ギヤエンド| プロトコル|中間的| プロトコル|中間的| ---->| ノード| <、-、-、-、-、-、-、-、--、>| ノード| <、-、-、-、-、-、-、-、--、>| ノード| -------- ------------ ------------
Figure 3. Multiple PCE Path Computation
図3。 複数のPCE経路計算
Farrel, et al. Informational [Page 13] RFC 4655 PCE Architecture August 2006
ファレル、他 [13ページ]情報のRFC4655PCE構造2006年8月
5.4. Multiple PCE Path Computation with Inter-PCE Communication
5.4. 相互PCEコミュニケーションとの複数のPCE経路計算
The PCE in Section 5.3 was not able to supply a full path for the requested service, and as a result the adjacent node needs to make its own computation request. As illustrated in Figure 4, the same problem may be solved by introducing inter-PCE communication, and cooperation between PCEs so that the PCE consulted by the head-end network node makes a request of another PCE to help with the computation.
セクション5.3におけるPCEは要求されたサービスにフルパスを供給できませんでした、そして、その結果、隣接しているノードはそれ自身の計算要求をする必要があります。 同じ問題が図4で例証されるように相互PCEコミュニケーション、およびPCEsの間の協力を紹介することによって解決されるかもしれないので、ギヤエンドのネットワーク・ノードによって相談されたPCEは別のPCEが計算で助けるという要求をします。
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
---------- ---------- | | 相互PCE要求/応答| | | PCE|<--------------------------------->| PCE| | | | | | ----- | | ----- | | | テッド| | | | テッド| | | ----- | | ----- | ---------- ---------- ^ | 要求/| 応答対Service---------- シグナリング---------- シグナリング---------- 要求| ギヤエンド| プロトコル| 隣接| プロトコル| 隣接| ---->| ノード| <、-、-、-、-、-、-、-、-、--、>| ノード| <、-、-、-、-、-、-、-、-、--、>| ノード| ---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
図4。 相互PCEコミュニケーションとの複数のPCE経路計算
Multiple PCE path computation with inter-PCE communication involves coordination between distinct PCEs such that the result of the computation performed by one PCE depends on path fragment information supplied by other PCEs. This model does not provide a distributed computation algorithm, but it allows distinct PCEs to be responsible for computation of parts (segments) of the path.
相互PCEコミュニケーションがある複数のPCE経路計算が異なったPCEsの間のコーディネートにかかわるので、1PCEによって実行された計算の結果は他のPCEsによって提供された経路断片情報によります。 このモデルは分散型計算方式アルゴリズムを提供しませんが、それは、異なったPCEsが経路の地域(セグメント)の計算に責任があるのを許容します。
PCE-PCE communication is discussed further in Section 6.6.
セクション6.6で、より詳しくPCE-PCEコミュニケーションについて議論します。
Note that a PCC might not see the difference between centralized computation and multiple PCE path computation with inter-PCE communication. That is, the PCC network node or component that requests the computation makes a single request and receives a full or partial path in response, but the response is actually achieved through the coordinated, cooperative efforts of more than one PCE.
PCCが集結された計算と複数のPCE経路計算の相互PCEコミュニケーションがある違いを見ないかもしれないことに注意してください。 すなわち、計算を要求するPCCネットワーク・ノードかコンポーネントが、ただ一つの要求をして、応答における完全であるか部分的な経路を受けますが、応答は実際に1PCEの連携していて、協力的な努力で達成されます。
Farrel, et al. Informational [Page 14] RFC 4655 PCE Architecture August 2006
ファレル、他 [14ページ]情報のRFC4655PCE構造2006年8月
In this model, all policy decisions may be made independently at each PCE based on computation information passed from the previous PCE. Alternatively, there may be explicit communication of policy information between PCEs.
このモデルでは、前のPCEから通過された計算情報に基づく各PCEで独自にすべての政策決定をするかもしれません。 あるいはまた、PCEsの間には、方針情報の明白なコミュニケーションがあるかもしれません。
5.5. Management-Based PCE Usage
5.5. 管理ベースのPCE用法
It must be observed that the PCC is not necessarily an LSR. For example, in Figure 5 the NMS supplies the head-end LSR with a fully computed explicit path for the TE LSP that it is to establish through signaling. The NMS uses a management plane mechanism to send this request and encodes the data using a representation such as the TE MIB module [RFC3812].
PCCが必ずLSRであるというわけではないことを観測しなければなりません。 例えば、図5では、NMSはそれがシグナリングを通して設立することになっているTE LSPのために完全に計算された明白な経路をギヤエンドLSRに供給します。 NMSは、この要求を送るのに管理飛行機メカニズムを使用して、TE MIBモジュール[RFC3812]などの表現を使用することでデータをコード化します。
The NMS constructs the explicit path that it supplies to the head-end LSR using information provided by the operator. It consults the PCE, which returns a path for the NMS to use.
NMSは、オペレータによって提供された情報を使用することでそれがギヤエンドLSRまで供給する明白な経路を構成します。 それはPCEに相談します。(PCEはNMSが使用する経路を返します)。
Although Figure 5 shows the PCE as remote from the NMS, it could, of course, be collocated with the NMS.
図5はNMSからリモートであるとしてPCEを示していますが、もちろんそれの連語をなされることができました。NMS。
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
----------- | ----- | サービス| | テッド| <、-+----------->要求| ----- | TED同期| | | | メカニズム(例えば、v| | | ルーティング・プロトコル)------------- 要求/| v| | | 応答| ----- | | NMS| <、-、-、-、-、-、-、--+ >。| PCE| | | | | ----- | ------------- ----------- サービス| 要求| v---------- シグナリング---------- | ギヤエンド| プロトコル| 隣接| | ノード| <、-、-、-、-、-、-、-、-、--、>| ノード| ---------- ----------
Figure 5. Management-Based PCE Usage
図5。 管理ベースのPCE用法
Farrel, et al. Informational [Page 15] RFC 4655 PCE Architecture August 2006
ファレル、他 [15ページ]情報のRFC4655PCE構造2006年8月
5.6. Areas for Standardization
5.6. 標準化のための領域
The following areas require standardization within the PCE architecture.
以下の領域はPCE構造の中で標準化を必要とします。
- communication between PCCs and PCEs, and between cooperating PCEs,
including the communication of policy-related information
- PCCsとPCEsの間と、そして、方針関連の情報に関するコミュニケーションを含む協力PCEsとのコミュニケーション
- requirements for extending existing routing and signaling protocols
in support of PCE discovery and signaling of inter-domain paths
- 相互ドメイン経路のPCE発見とシグナリングを支持した既存のルーティングとシグナリングプロトコルを広げるための要件
- definition of metrics to evaluate path quality, scalability,
responsiveness, robustness, and policy support of path computation
models.
- 経路計算の経路品質を評価する測定基準の定義、スケーラビリティ、反応性、丈夫さ、および方針サポートはモデル化されます。
- MIB modules related to communication protocols, routing and
signaling extensions, metrics, and PCE monitoring information
- 通信プロトコルとルーティングと拡大、測定基準、およびPCE監視情報に合図すると関連するMIBモジュール
6. PCE Architectural Considerations
6. PCEの建築問題
This section provides a list of the PCE architectural components. Specific realizations and implementation details (state machines or algorithms, etc.) of PCE-based solutions are out of the scope of this document.
このセクションはPCE建築構成のリストを提供します。 このドキュメントの範囲の外にPCEベースの解決策の特定の実現と実現の詳細(州のマシンやアルゴリズムなど)があります。
Note also that PCE-based path computation does not affect in any way the use of the computed paths. For example, the use of PCE does not change the way in which Traffic Engineering LSPs are signaled, maintained, and torn down, but it strictly relates to the path computation aspects of such TE LSPs.
また、そのPCEベースの経路計算が何らかの方法で計算された経路の使用に影響しないことに注意してください。 例えば、PCEの使用はTraffic Engineering LSPsが合図されて、維持されて、取りこわされる方法を変えませんが、それは厳密にそのようなTE LSPsの経路計算局面に関連します。
This section presents an architectural view of PCE. That is, it describes the components that exist and how they interact. Note that the architectural model, and in particular the functional model, may be perceived differently by different components of the PCE system. For example, the PCC will not be aware of whether a PCE consults other PCEs. The PCC view of the PCE architecture is discussed in Section 7.
このセクションはPCEの建築視点を提示します。 すなわち、それは存在するコンポーネントとどう相互作用するかを説明します。 建築モデル、および特に機能論的モデルがPCEシステムの異なった部品によって異なって知覚されるかもしれないことに注意してください。 例えば、PCCはPCEが他のPCEsに相談するかどうかを意識しないでしょう。 セクション7でPCE構造のPCC視点について議論します。
6.1. Centralized Computation Model
6.1. 集結された計算モデル
A "centralized computation model" considers that all path computations for a given domain will be performed by a single, centralized PCE. This may be a dedicated server (for example, an external PCE node), or a designated router (for example, a composite PCE node) in the network. In this model, all PCCs in the domain would send their path computation requests to the central PCE. While
「集結された計算モデル」は、与えられたドメインのためのすべての経路計算が単一の、そして、集結されたPCEによって実行されると考えます。 これは、専用サーバ(例えば、外部のPCEノード)、またはネットワークで代表ルータであるかもしれません(例えば、合成PCEノード)。 このモデルでは、そのドメインのすべてのPCCsが彼らの経路計算要求を中央のPCEに送るでしょう。 while
Farrel, et al. Informational [Page 16] RFC 4655 PCE Architecture August 2006
ファレル、他 [16ページ]情報のRFC4655PCE構造2006年8月
a domain in this context might be an IGP area or AS, it might also be a sub-group of network nodes that is defined by its dependence on the PCE.
ドメインがこのような関係においてはIGP領域かASであるかもしれない、また、それはPCEへの依存によって定義されるネットワーク・ノードのサブグループであるかもしれません。
This model has a single point of failure: the PCE. In order to avoid this issue, the centralized computation model may designate a backup PCE that can take over the computation responsibility in a controlled manner in the event of a failure of the primary PCE. Any policies present on the primary PCE should also be present on the backup, although the primary policies may themselves be subject to policy governing how they are implemented on the backup. Note that at any moment in time there is only one active PCE in any domain.
このモデルには、1ポイントの失敗があります: PCE。 この問題を避けるために、集結された計算モデルは第一のPCEの失敗の場合、制御方法で引き継ぐことができるバックアップPCEを計算責任に指定するかもしれません。 第一の方針はバックアップ存在していますが、また、第一のPCEの現在のどんな方針も方針の治めることへの対象がそれらがバックアップの上でどう実行されるかということであるなら自分たちで存在しているでしょうに。 1アクティブなPCEしか時間内にいつ何時どんなドメインにもないことに注意してください。
6.2. Distributed Computation Model
6.2. 分散型計算方式モデル
A "distributed computation model" refers to a domain or network that
may include multiple PCEs, and where computation of paths is shared
among the PCEs. A given path may in turn be computed by a single PCE
("single PCE path computation") or multiple PCEs ("multiple PCE path
computation"). A PCC may be linked to a particular PCE or may be
able to choose freely among several PCEs; the method of choice
between PCEs is out of scope of this document, but see Section 6.4
for a discussion of PCE discovery that affects this choice.
Implementation of policy should be consistent across the set of
available PCEs.
「分散型計算方式モデル」は複数のPCEsを含むかもしれなくて、経路の計算がPCEsの中で共有されるドメインかネットワークを示します。 与えられた経路は独身のPCE(「ただ一つのPCE経路計算」)か複数のPCEs(「複数のPCE経路計算」)によって順番に計算されるかもしれません。 PCCは特定のPCEにリンクされるか、または数個のPCEsの中で自由に選ぶことができるかもしれません。 このドキュメントの範囲の外にPCEsの選択の方法がありますが、この選択に影響するPCE発見の議論に関してセクション6.4を見てください。 方針の実現は利用可能なPCEsのセットの向こう側に一貫しているべきです。
Often, the computation of an individual path is performed entirely by a single PCE. For example, this is usually the case in MPLS TE within a single IGP area where the ingress LSR/composite PCE node is responsible for computing the path or for contacting an external PCE. Conversely, multiple PCE path computation implies that more than one PCE is involved in the computation of a single path. An example of this is where loose hop expansion is performed by transit LSRs/composite PCE nodes on an MPLS TE LSP. Another example is the use of multiple cooperating PCEs to compute the path of a single TE LSP across multiple domains.
しばしば、個々の経路の計算は完全に独身のPCEによって実行されます。 例えば、通常、これはイングレスのLSR/合成しているPCEノードが経路を計算するか、または外部のPCEに連絡するのに原因となるただ一つのIGP領域の中のMPLS TEのそうです。 逆に、複数のPCE経路計算が、1PCEがただ一つの経路の計算にかかわるのを含意します。 この例はゆるいホップ拡大がトランジットのLSRs/合成しているPCEノードによってMPLS TE LSPに実行されるところです。 別の例は複数のドメインの向こう側に独身のTE LSPの経路を計算する複数の協力PCEsの使用です。
6.3. Synchronization
6.3. 同期
Often, multiple paths need to be computed to support a single service (for example, for protection or load sharing). A PCC that determines that it requires more than one path to be computed may send a series of individual requests to the PCE. In this case of non-synchronized path computation requests, the PCE may make multiple individual path computations to generate the paths, and the PCC may send its individual requests to different PCEs.
しばしば、複数の経路が、ただ一つのサービス(例えば保護か負荷分割法のために)を支持するために計算される必要があります。 計算されるのが1つ以上の経路を必要とすることを決定するPCCは一連の個々の要求をPCEに送るかもしれません。 この場合、PCEは経路を発生させるように非連動している経路計算要求では、複数の個々の経路計算をするかもしれません、そして、PCCは個々の要求を異なったPCEsに送るかもしれません。
Farrel, et al. Informational [Page 17] RFC 4655 PCE Architecture August 2006
ファレル、他 [17ページ]情報のRFC4655PCE構造2006年8月
Alternatively, the PCC may send a single request to a PCE asking for a set of paths to be computed, but specifying that non-synchronized path computation is acceptable. The PCE may compute each path in turn exactly as it would have done had the PCC made multiple requests, and the PCE may devolve some computations to other PCEs if it chooses. On the other hand, the PCE is not prohibited from performing all computations together in a synchronized manner as described below.
あるいはまた、PCCは1セットの経路が、非連動している経路計算が許容できると計算されますが、指定しているように頼むPCEにただ一つの要求を送るかもしれません。 PCEはちょうどPCCが複数の要求をしたならしたように順番に各経路を計算するかもしれません、そして、選ぶなら、PCEはいくつかの計算を他のPCEsへ譲り渡すかもしれません。 他方では、PCEは以下で説明されるように連動している方法ですべての計算を一緒に実行するのが禁止されていません。
The PCC may also issue a single request to the PCE asking for all the paths to be computed in a synchronized manner. The PCE will then perform simultaneous computation of the set of requested paths. Such synchronized computation can often provide better results.
また、PCCはすべての経路が連動している方法で計算されるように頼むPCEにただ一つの要求を出すかもしれません。 そして、PCEは要求された経路のセットの同時の計算を実行するでしょう。 そのような連動している計算はしばしばより良い結果を提供できます。
The involvement of more than one PCE in the computation of a series of paths is by its nature non-synchronized. However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC may send a request to a PCE that invokes domain-specific computations by other PCEs before supplying a result to the PCC.
一連の経路の計算における、1PCEのかかわり合いは本質的に非連動されています。 しかしながら、協力PCEsの1セットは独身のPCEのコントロールの下で同期するかもしれません。 例えば、PCCは結果をPCCに供給する前に他のPCEsによるドメイン特有の計算を呼び出すPCEに要求を送るかもしれません。
It is desirable to add a parameter to the PCC-PCE protocol to request that the PCE supply a set of alternate paths for use by the PCC, should the establishment of the TE LSP using the principal path fail to complete. While alternate paths may not always be successful if the first path fails, including alternate paths in a PCE response could have less overhead than having the PCC make separate requests for subsequent path computations as the need arises. This technique is used in some existing CSPF implementations.
PCEが1セットの代替パスをPCCによる使用に供給するよう要求するためにPCC-PCEプロトコルにパラメタを追加するのは望ましいです、主要な経路を使用するTE LSPの設立が完全な状態でそうしないなら。 最初の経路が失敗するなら代替パスがいつもうまくいくかもしれないというわけではない間、PCE応答に代替パスを含むのにおいて、PCCにその後の経路計算を求める別々の要求を必要に応じてさせるより少ないオーバーヘッドがあるかもしれません。 このテクニックはいくつかの既存のCSPF実現に使用されます。
6.4. PCE Discovery and Load Balancing
6.4. PCE発見とロードバランシング
In order that a PCC can communicate efficiently with a PCE, it must know the location of the PCE. That is, it is an architectural decision made here that PCC requests be targeted to a specific PCE, and not broadcast to the network for any PCE to respond. This decision means that only the selected PCE will operate on any single request, and it saves network resources during request propagation and processing resources at the PCEs that are not required to respond.
PCCが効率的にPCEとコミュニケートできるように、それはPCEの位置を知らなければなりません。 すなわち、それはPCC要求が特定のPCEに狙って、どんなPCEも応じるようにネットワークに放送されないというここでされた建築決定です。 この決定は、選択されたPCEだけがどんなただ一つの要求も作動させることを意味します、そして、それは要求伝播と処理リソースの間、応じる必要はないPCEsにネットワーク資源を取っておきます。
The knowledge of the location of a PCE may be achieved through local configuration at the PCC or may rely on a protocol-based discovery mechanism that may be governed by policy.
PCEの位置に関する知識は、PCCでの地方の構成を通して実現されるか、または方針で支配されるかもしれないプロトコルベースの発見メカニズムを当てにするかもしれません。
Where more than one PCE is known to a PCC, the PCC must have sufficient information to select an appropriate PCE for its purposes, under the control of policy. Such a selection procedure allows for
1PCEがPCCにおいて知られているところでは、PCCは目的のために適切なPCEを選択できるくらいの情報を持たなければなりません、方針のコントロールの下で。 選択手順が考慮するそのようなもの
Farrel, et al. Informational [Page 18] RFC 4655 PCE Architecture August 2006
ファレル、他 [18ページ]情報のRFC4655PCE構造2006年8月
load sharing between PCEs and supports PCEs with different computation capabilities including different visibility scopes. Thus, the information available to the PCC must include details of the PCE capabilities, which may be fixed or may vary dynamically in time.
PCEsと異なった計算能力が異なった目に見えることを含んでいるサポートPCEsの間の負荷分割法は見られます。 したがって、PCCに利用可能な情報はPCE能力の詳細を含まなければなりません。(修理されるかもしれないか、または能力は時間内に、ダイナミックに異なるかもしれません)。
The PCC may learn PCE capabilities through static configuration, or it may discover the information dynamically. Note that even when the location of the PCE is configured at the PCC, the PCC may still discover the PCE capabilities dynamically. Dynamic PCE capabilities cannot be configured and can only be discovered.
PCCが静的な構成を通してPCE能力を学ぶかもしれませんか、またはそれはダイナミックに情報を発見するかもしれません。 PCEの位置がPCCで構成さえされるとき、PCCがまだダイナミックにPCE能力を発見しているかもしれないことに注意してください。 ダイナミックなPCE能力を構成できないで、発見できるだけです。
Proxy PCE advertisement whereby the existence of a PCE is advertised via a proxy PCE is a viable alternative, should the PCE be incapable of such advertisement itself. In this case, it is a requirement that the proxy adequately advertise the PCE status and capability in a timely and synchronized fashion.
PCEの存在がプロキシPCEを通しての広告に掲載されているプロキシPCE広告は実行可能な代案です、PCEがそのような広告自体で不可能であるなら。 この場合、それはプロキシがタイムリーで連動しているファッションでPCE状態と能力の適切に広告を出すという要件です。
In the event that multiple PCEs are available to serve a particular path computation request, the PCC must select a PCE to satisfy the request. The details of such a selection (for instance, to efficiently share the computation load across multiple PCEs or to request secondary computations after partial or failed computations) are local to the PCC, may be based on policy, and are out of the scope of this document.
複数のPCEsが特定の経路計算要求に役立つように利用可能である場合、PCCは、PCEが要望に応じるのを選択しなければなりません。 そのような選択(例えば、複数のPCEsの向こう側に効率的に計算負荷を共有するか、または次々と二次部分的であるか失敗した計算を要求する)の詳細は、PCCに地方であり、方針に基づくかもしれなくて、このドキュメントの範囲の外にあります。
PCE capabilities that may be advertised or configured could include (and are not be limited to):
広告を出すか、または構成するかもしれないPCE能力が包含できた、(制限されないでください、)、:
- a set of constraints that it can account for (diversity, shared
risk link groups (SRLGs), optical impairments, wavelength
continuity, etc.)
- それが説明できる1セットの規制(多様性、共有されたリスクリンク群(SRLGs)、光の損傷、波長の連続など)
- computational capacity (for example, the number of computations it
can perform per second)
- コンピュータの容量(例えば、それが1秒単位で実行できる計算の数)
- the number of switching capability layers (and which ones)
- スイッチング能力層の数(そして、どれ)
- the number of path selection criteria (and which ones)
- 経路選択評価基準の数(そして、どれ)
- whether it is a stateless PCE or it can send updates about better
paths that might be available in the future
- それが国がないPCEですかそれとも発信できるかが将来利用可能であるかもしれないほとんどより良い経路をアップデートします。
- whether it can compute P2MP trees (and which types)
- それがP2MP木を計算できて(どれがタイプされるか)
- whether it can ensure resource sharing between backup tunnels
- それがバックアップトンネルの間のリソース・シェアリングを確実にすることができて
This information would help a PCC to decide which PCE to use.
この情報は、PCCが、どのPCEを使用したらよいかを決めるのを助けるでしょう。
Farrel, et al. Informational [Page 19] RFC 4655 PCE Architecture August 2006
ファレル、他 [19ページ]情報のRFC4655PCE構造2006年8月
Requirements for PCE advertisement will be documented separately. Note that there is no restriction within the architecture about how location and capabilities are advertised, and the two elements should be considered functionally distinct.
PCE広告のための要件は別々に記録されるでしょう。 位置と能力の広告を出して、機能上異なるとどう2つの要素を考えるべきであるかに関する構造の中に制限が全くないことに注意してください。
A PCC might also ask a PCE to perform a particular type of service without knowledge of the PCE's capabilities and receive a response that says that the PCE is unable to perform the service. The response could specify the capabilities of the PCE and might also suggest another PCE that has the requested capabilities.
PCCはまた、知識なしで特定のタイプのサービスを実行するようにPCEの能力にPCEに頼んで、PCEがサービスを実行できないと言う応答を受けるかもしれません。 応答は、PCEの能力を指定できて、また、要求される機能がある別のPCEを示すかもしれません。
6.5. Detecting PCE Liveness
6.5. PCE活性を検出します。
The ability to detect a PCE's liveness is a mandatory piece of the overall architecture and could be achieved by several means. If some form of regular advertisement (such as through IGP extensions) is used for PCE discovery, it is expected that the PCE liveness will be determined by means of status advertisement (for example, IGP LSA/LSPs).
PCEの活性を検出する能力は、総合的な構造の義務的な断片であり、いくつかの手段で達成できるでしょう。 何らかの形式の定期的な広告(IGP拡張子などの)がPCE発見に使用されるなら、PCE活性が状態広告(例えば、IGP LSA/LSPs)による決定すると予想されます。
The inability of a PCE to service a request (perhaps due to excessive load) may be reported to the PCC through a failure message, but the failure of a PCE or the communications mechanism while processing a request cannot be reported in this way. Furthermore, in the case of excessive load, the PCE may not have sufficient resources to send a failure message. Thus, the PCC should employ other mechanisms, such as protocol timers, to determine the liveness of the PCE. This is particularly important in the case of inter-domain path computation where the PCE liveness may not be detected by means of the IGP that runs in the PCC's domain.
PCEが要求(恐らく負担過重による)を修理できないことは失敗メッセージを通してPCCに報告されるかもしれませんが、要求を処理している間このようにPCEかコミュニケーションメカニズムの失敗は報告できません。 その上、負担過重の場合では、PCEは失敗メッセージを送ることができるくらいのリソースを持っていないかもしれません。 したがって、PCCは、PCEの活性を決定するのにプロトコルタイマなどの他のメカニズムを使うはずです。 これはPCE活性がPCCのドメインへ駆け込むIGPによって検出されないかもしれないところで相互ドメイン経路計算の場合で特に重要です。
6.6. PCC-PCE and PCE-PCE Communication
6.6. PCC-PCEとPCE-PCEコミュニケーション
Once the PCC has selected a PCE, and provided that the PCE is not local to the PCC, a request/response protocol is required for the PCC to communicate the path computation requests to the PCE and for the PCE to return the path computation response. Discussion of the security requirements and implications for this protocol is provided in Section 10 of this document.
一度、PCCはPCEを選択したことがあります、そして、PCEがPCCに地方でなければ、PCCが経路計算要求をPCEに伝えて、PCEが経路計算応答を返すのに要求/応答プロトコルが必要です。 このプロトコルのためのセキュリティ要件と含意の議論をこのドキュメントのセクション10に提供します。
The path computation request may include a significant set of requirements, including the following:
経路計算要求は以下を含む重要なセットの要件を含むかもしれません:
- the source and destination of the path
- 経路のソースと目的地
- the bandwidth and other Quality of Service (QoS) parameters desired
- 望まれていたService(QoS)パラメタの帯域幅と他のQuality
Farrel, et al. Informational [Page 20] RFC 4655 PCE Architecture August 2006
ファレル、他 [20ページ]情報のRFC4655PCE構造2006年8月
- resources, resource affinities, and shared risk link groups (SRLGs)
to use/avoid
- 使用するか、または避けるリソース、リソースの親近感、および共有されたリスクリンク群(SRLGs)
- the number of disjoint paths required and whether near-disjoint
paths are acceptable
- そして、数、必要である経路をばらばらにならせてください、近さ、-ばらばらになってください、経路は許容できます。
- the levels of resiliency, reliability, and robustness of the path
resources
- 経路リソースの弾性、信頼性、および丈夫さのレベル
- policy-related information
- 方針関連の情報
The level of robustness of the path resources covers a qualitative assessment of the vulnerability of the resources that may be used. For example, one might grade resources based on empirical evidence (mean time between failures), on known risks (there is major building work going on near this conduit), or on prejudice (vendor X's software is always crashing). A PCC could request that only robust resources be used, or it could allow any resource.
The level of robustness of the path resources covers a qualitative assessment of the vulnerability of the resources that may be used. For example, one might grade resources based on empirical evidence (mean time between failures), on known risks (there is major building work going on near this conduit), or on prejudice (vendor X's software is always crashing). A PCC could request that only robust resources be used, or it could allow any resource.
In case of a positive response from the PCE, one or more paths would be returned to the requesting node. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure(s), and potentially with advice about which constraints might be relaxed so that a positive result is more likely in a future request.
In case of a positive response from the PCE, one or more paths would be returned to the requesting node. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure(s), and potentially with advice about which constraints might be relaxed so that a positive result is more likely in a future request.
Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for the PCE to return the path computation response. The path computation request may include a significant set of requirements including those defined above. In case of a positive response from the PCE, one or more paths would be returned to the requesting PCE. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed so that a positive result is more likely. Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for the PCE to return the path computation response. The path computation request may include a significant set of requirements including those defined above. In case of a positive response from the PCE, one or more paths would be returned to the requesting PCE. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed so that a positive result is more likely. Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
An important feature of PCEs that are cooperating to compute a path is that they apply compatible or identical computation algorithms and coordinated policies. This may require coordination through the communication between the PCEs.
An important feature of PCEs that are cooperating to compute a path is that they apply compatible or identical computation algorithms and coordinated policies. This may require coordination through the communication between the PCEs.
Farrel, et al. Informational [Page 21] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 21] RFC 4655 PCE Architecture August 2006
Note that when multiple PCEs cooperate to compute a path, it is important that they have a coordinated view of the meaning of constraints such as costs, resource affinities, and class of service. This is particularly significant where the PCEs are responsible for different domains. It is assumed that this is a matter of policy between domains and between PCEs.
Note that when multiple PCEs cooperate to compute a path, it is important that they have a coordinated view of the meaning of constraints such as costs, resource affinities, and class of service. This is particularly significant where the PCEs are responsible for different domains. It is assumed that this is a matter of policy between domains and between PCEs.
No assumption is made in this architecture about whether the PCC-PCE and PCE-PCE communication protocols are identical.
No assumption is made in this architecture about whether the PCC-PCE and PCE-PCE communication protocols are identical.
6.7. PCE TED Synchronization
6.7. PCE TED Synchronization
As previously described, the PCE operates on a TED. Information on network status to build the TED may be provided in the domain by various means:
As previously described, the PCE operates on a TED. Information on network status to build the TED may be provided in the domain by various means:
1) Participation in IGP distribution of TE information. The standard
method of distribution of TE information within an IGP area is
through the use of extensions to the IGP [RFC3630, RFC3748]. This
mechanism allows participating nodes to build a TED, and this is
the standard technique, for example, within a single area MPLS or
GMPLS network. A node that hosts the PCE function may collect TE
information in this way by maintaining at least one routing
adjacency with a router in the domain. The PCE node may be
adjacent or non-adjacent (via some tunneling techniques) to the
router. Such a technique provides a mechanism for ensuring that
the TED is efficiently synchronized with the network state and is
the normal case, for example, when the PCE is co-resident with the
LSRs in an MPLS or GMPLS network.
1) Participation in IGP distribution of TE information. The standard method of distribution of TE information within an IGP area is through the use of extensions to the IGP [RFC3630, RFC3748]. This mechanism allows participating nodes to build a TED, and this is the standard technique, for example, within a single area MPLS or GMPLS network. A node that hosts the PCE function may collect TE information in this way by maintaining at least one routing adjacency with a router in the domain. The PCE node may be adjacent or non-adjacent (via some tunneling techniques) to the router. Such a technique provides a mechanism for ensuring that the TED is efficiently synchronized with the network state and is the normal case, for example, when the PCE is co-resident with the LSRs in an MPLS or GMPLS network.
2) Out-of-band TED synchronization. It may not be convenient or
possible for a PCE to participate in the IGPs of one or more
domains (for example, when there are very many domains, when IGP
participation is not desired, or when some domains are not running
TE-aware IGPs). In this case, some mechanism may need to be
defined to allow the PCE node to retrieve the TED from each
domain. Such a mechanism could be incremental (like the IGP in
the previous case), or it could involve a bulk transfer of the
complete TED. The latter might significantly limit the capability
to ensure TED synchronization, which might result in an increase
in the failure rate of computed paths, or the computation of sub-
optimal paths. Consideration should also be given to the impact
of the TED distribution on the network and on the network node
within the domain that is asked to distribute the database. This
is particularly relevant in the case of frequent network state
changes.
2) Out-of-band TED synchronization. It may not be convenient or possible for a PCE to participate in the IGPs of one or more domains (for example, when there are very many domains, when IGP participation is not desired, or when some domains are not running TE-aware IGPs). In this case, some mechanism may need to be defined to allow the PCE node to retrieve the TED from each domain. Such a mechanism could be incremental (like the IGP in the previous case), or it could involve a bulk transfer of the complete TED. The latter might significantly limit the capability to ensure TED synchronization, which might result in an increase in the failure rate of computed paths, or the computation of sub- optimal paths. Consideration should also be given to the impact of the TED distribution on the network and on the network node within the domain that is asked to distribute the database. This is particularly relevant in the case of frequent network state changes.
Farrel, et al. Informational [Page 22] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 22] RFC 4655 PCE Architecture August 2006
3) Information in the TED can include information obtained from
sources other than the IGP. For example, information about link
usage policies can be configured by the operator. Path
computation can also act on a far wider set of information that
includes data about the TE LSPs provisioned within the network.
This information can include TE LSP routes, reserved bandwidth,
and measured traffic volume passing through the TE LSP.
3) Information in the TED can include information obtained from sources other than the IGP. For example, information about link usage policies can be configured by the operator. Path computation can also act on a far wider set of information that includes data about the TE LSPs provisioned within the network. This information can include TE LSP routes, reserved bandwidth, and measured traffic volume passing through the TE LSP.
Such TE LSP information can enhance TE LSP (re)optimization to
provide "full network" (re)optimization and can allow traffic
fluctuations to be taken into account. Detailed TE LSP
information may also facilitate reconfiguration of the Virtual
Network Topology (VNT) [MLN], in which lower-layer TE LSPs, such
as optical paths, provide TE links for use by the higher layer,
since this reconfiguration is also a "full network" problem.
Such TE LSP information can enhance TE LSP (re)optimization to provide "full network" (re)optimization and can allow traffic fluctuations to be taken into account. Detailed TE LSP information may also facilitate reconfiguration of the Virtual Network Topology (VNT) [MLN], in which lower-layer TE LSPs, such as optical paths, provide TE links for use by the higher layer, since this reconfiguration is also a "full network" problem.
Note that synchronization techniques may apply to both intra- and inter-domain TEDs. Furthermore, the techniques can be mixed for use in different domains. The degree of synchronization between the PCE and the network is subject to implementation and/or policy. However, better synchronization generally leads to paths that are more likely to succeed.
Note that synchronization techniques may apply to both intra- and inter-domain TEDs. Furthermore, the techniques can be mixed for use in different domains. The degree of synchronization between the PCE and the network is subject to implementation and/or policy. However, better synchronization generally leads to paths that are more likely to succeed.
Note also that the PCE may have access to only a partial TED: for instance, in the case of inter-domain path computation where each such domain may be managed by different entities. In such cases, each PCE may have access to a partial TED, and cooperative techniques between PCEs may be used to achieve end-to-end path computation without any requirement that any PCE handle the complete TED related to the set of traversed domains by the TE LSP in question.
Note also that the PCE may have access to only a partial TED: for instance, in the case of inter-domain path computation where each such domain may be managed by different entities. In such cases, each PCE may have access to a partial TED, and cooperative techniques between PCEs may be used to achieve end-to-end path computation without any requirement that any PCE handle the complete TED related to the set of traversed domains by the TE LSP in question.
6.8. Stateful versus Stateless PCEs
6.8. Stateful versus Stateless PCEs
A PCE can be either stateful or stateless. In the former case, there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network. In other words, the PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests. Note that although this allows for optimal path computation and increased path computation success, stateful PCEs require reliable state synchronization mechanisms, with potentially significant control plane overhead and the maintenance of a large amount of data/states (for example, full mesh of TE LSPs).
A PCE can be either stateful or stateless. In the former case, there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network. In other words, the PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests. Note that although this allows for optimal path computation and increased path computation success, stateful PCEs require reliable state synchronization mechanisms, with potentially significant control plane overhead and the maintenance of a large amount of data/states (for example, full mesh of TE LSPs).
For example, if there is only one PCE in the domain, all TE LSP computation is done by this PCE, which can then track all the existing TE LSPs and stay synchronized (each TE LSP state change must
For example, if there is only one PCE in the domain, all TE LSP computation is done by this PCE, which can then track all the existing TE LSPs and stay synchronized (each TE LSP state change must
Farrel, et al. Informational [Page 23] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 23] RFC 4655 PCE Architecture August 2006
be tracked by the PCE). However, this model could require substantial control plane resources. If there are multiple PCEs in the network, TE LSP computation and information are distributed among PCEs and so the resources required to perform the computations are also distributed. However, synchronization issues discussed in Section 6.7 also come into play.
be tracked by the PCE). However, this model could require substantial control plane resources. If there are multiple PCEs in the network, TE LSP computation and information are distributed among PCEs and so the resources required to perform the computations are also distributed. However, synchronization issues discussed in Section 6.7 also come into play.
The maintenance of a stateful database can be non-trivial. However, in a single centralized PCE environment, a stateful PCE is almost a simple matter of remembering all the TE LSPs the PCE has computed, that the TE LSPs were actually set up (if this can be known), and when they were torn down. Out-of-band TED synchronization can also be complex, with multiple PCE setup in a distributed PCE computation model, and could be prone to race conditions, scalability concerns, etc. Even if the PCE has detailed information on all paths, priorities, and layers, taking such information into account for path computation could be highly complex. PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation performed among several PCEs, the problems of synchronization and race condition avoidance become larger and more complex.
The maintenance of a stateful database can be non-trivial. However, in a single centralized PCE environment, a stateful PCE is almost a simple matter of remembering all the TE LSPs the PCE has computed, that the TE LSPs were actually set up (if this can be known), and when they were torn down. Out-of-band TED synchronization can also be complex, with multiple PCE setup in a distributed PCE computation model, and could be prone to race conditions, scalability concerns, etc. Even if the PCE has detailed information on all paths, priorities, and layers, taking such information into account for path computation could be highly complex. PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation performed among several PCEs, the problems of synchronization and race condition avoidance become larger and more complex.
There is benefit in knowing which TE LSPs exist, and their routing, to support such applications as placing a high-priority TE LSP in a crowded network such that it preempts as few other TE LSPs as possible (also known as the "minimal perturbation" problem). Note that preempting based on the minimum number of links might not result in the smallest number of TE LSPs being disrupted. Another application concerns the construction and maintenance of a Virtual Network Topology [MLN]. It is also helpful to understand which other TE LSPs exist in the network in order to decide how to manage the forward adjacencies that exist or need to be set up. The cost- benefit of stateful PCE computation would be helpful to determine if the benefit in path computation is sufficient to offset the additional drain on the network and computational resources.
There is benefit in knowing which TE LSPs exist, and their routing, to support such applications as placing a high-priority TE LSP in a crowded network such that it preempts as few other TE LSPs as possible (also known as the "minimal perturbation" problem). Note that preempting based on the minimum number of links might not result in the smallest number of TE LSPs being disrupted. Another application concerns the construction and maintenance of a Virtual Network Topology [MLN]. It is also helpful to understand which other TE LSPs exist in the network in order to decide how to manage the forward adjacencies that exist or need to be set up. The cost- benefit of stateful PCE computation would be helpful to determine if the benefit in path computation is sufficient to offset the additional drain on the network and computational resources.
Conversely, stateless PCEs do not have to remember any computed path and each set of request(s) is processed independently of each other. For example, stateless PCEs may compute paths based on current TED information, which could be out of sync with actual network state given other recent PCE-computed paths changes. Note that a PCC may include a set of previously computed paths in its request, in order to take them into account, for instance, to avoid double bandwidth accounting or to try to minimize changes (minimum perturbation problem).
Conversely, stateless PCEs do not have to remember any computed path and each set of request(s) is processed independently of each other. For example, stateless PCEs may compute paths based on current TED information, which could be out of sync with actual network state given other recent PCE-computed paths changes. Note that a PCC may include a set of previously computed paths in its request, in order to take them into account, for instance, to avoid double bandwidth accounting or to try to minimize changes (minimum perturbation problem).
Farrel, et al. Informational [Page 24] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 24] RFC 4655 PCE Architecture August 2006
Note that the stateless PCE does operate on information about network state. The TED contains link state and bandwidth availability information as distributed by the IGPs or collected through some other means. This information could be further enhanced to provide increased granularity and more detail to cover, for example, the current bandwidth usage on certain links according to resource affinities or forwarding equivalence classes. Such information is, however, not PCE state information and so a model that uses it is still described as stateless in the PCE context.
Note that the stateless PCE does operate on information about network state. The TED contains link state and bandwidth availability information as distributed by the IGPs or collected through some other means. This information could be further enhanced to provide increased granularity and more detail to cover, for example, the current bandwidth usage on certain links according to resource affinities or forwarding equivalence classes. Such information is, however, not PCE state information and so a model that uses it is still described as stateless in the PCE context.
A limited form of statefulness might be applied within an otherwise stateless PCE. The PCE may retain some context from paths it has recently computed so that it avoids suggesting the use of the same resources for other TE LSPs.
A limited form of statefulness might be applied within an otherwise stateless PCE. The PCE may retain some context from paths it has recently computed so that it avoids suggesting the use of the same resources for other TE LSPs.
6.9. Monitoring
6.9. Monitoring
PCE monitoring is undoubtedly of the utmost importance in any PCE architecture. This must include the collection of variables related to the PCE status and operation. For example, it will be necessary to understand the way in which the TED is being kept synchronized, the rate of arrival of new requests and the computation times, the range of PCCs that are using the PCE, and the operation of any PCC- PCE protocol.
PCE monitoring is undoubtedly of the utmost importance in any PCE architecture. This must include the collection of variables related to the PCE status and operation. For example, it will be necessary to understand the way in which the TED is being kept synchronized, the rate of arrival of new requests and the computation times, the range of PCCs that are using the PCE, and the operation of any PCC- PCE protocol.
6.10. Confidentiality
6.10. Confidentiality
As stated in [RFC4216], the case of inter-provider TE LSP computation requires the ability to compute a path while preserving confidentiality across multiple Service Providers cores. That is, one Service Provider must not be required to divulge any information about its resources or topology in order to support inter-provider TE LSP path computation. Thus, any PCE architecture solution must support the ability to return partial paths by means of loose hops (for example, where each loose hop would, for instance, identify a boundary LSR).
As stated in [RFC4216], the case of inter-provider TE LSP computation requires the ability to compute a path while preserving confidentiality across multiple Service Providers cores. That is, one Service Provider must not be required to divulge any information about its resources or topology in order to support inter-provider TE LSP path computation. Thus, any PCE architecture solution must support the ability to return partial paths by means of loose hops (for example, where each loose hop would, for instance, identify a boundary LSR).
This requirement is not a security issue, but relates to Service Provider policy. Confidentiality, integrity, and authentication of PCC-PCE and PCE-PCE messages must also be ensured and are described in Section 10.
This requirement is not a security issue, but relates to Service Provider policy. Confidentiality, integrity, and authentication of PCC-PCE and PCE-PCE messages must also be ensured and are described in Section 10.
The ability to compute a path at the request of the head-end PCC, but to supply the path in segments to the domain boundary PCCs, may also be desirable.
The ability to compute a path at the request of the head-end PCC, but to supply the path in segments to the domain boundary PCCs, may also be desirable.
Farrel, et al. Informational [Page 25] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 25] RFC 4655 PCE Architecture August 2006
6.11. Policy
6.11. Policy
Policy impacts multiple aspects of the PCE architecture. There are two applications of policy for consideration:
Policy impacts multiple aspects of the PCE architecture. There are two applications of policy for consideration:
- application of policy within an architectural entity (PCC or PCE)
- application of policy within an architectural entity (PCC or PCE)
- application of policy to PCE-related communications
- application of policy to PCE-related communications
As directly applicable to TE LSPs, policy forms part of the signaling mechanism for the establishment of the TE LSPs and is not described here.
As directly applicable to TE LSPs, policy forms part of the signaling mechanism for the establishment of the TE LSPs and is not described here.
It is envisioned that policy will be largely applied as a local matter within each PCC and PCE. However, this document needs to define policy models that can be supported within the PCE architecture and by PCE-related communication.
It is envisioned that policy will be largely applied as a local matter within each PCC and PCE. However, this document needs to define policy models that can be supported within the PCE architecture and by PCE-related communication.
Some example policies include:
Some example policies include:
- selection of a PCE by a PCC
- selection of a PCE by a PCC
- rejection of a request by the PCE based on the identity of the
requesting PCC
- rejection of a request by the PCE based on the identity of the requesting PCC
- selection by the PCE of a path or application of additional
constraints to a computation based on the PCC, the computation
target, the time of day, etc.
- selection by the PCE of a path or application of additional constraints to a computation based on the PCC, the computation target, the time of day, etc.
6.11.1. PCE Policy Architecture
6.11.1. PCE Policy Architecture
Two examples of the use of policy components within the PCE architecture are illustrated in Figures 6 and 7. Policy components could equally be applied to the other PCE configurations shown in Section 5. In each configuration, policy may be consulted before a response is provided by a PCE and may also be consulted by the PCC/PCE that receives the response.
Two examples of the use of policy components within the PCE architecture are illustrated in Figures 6 and 7. Policy components could equally be applied to the other PCE configurations shown in Section 5. In each configuration, policy may be consulted before a response is provided by a PCE and may also be consulted by the PCC/PCE that receives the response.
A PCE may have a local policy that impacts the paths selected to satisfy a particular PCE request. A policy may be applied based on any information provided from a PCC.
A PCE may have a local policy that impacts the paths selected to satisfy a particular PCE request. A policy may be applied based on any information provided from a PCC.
In Figure 6, the policy component is shown providing input to the PCE component. This policy component may consult an external policy database, but this is outside the scope of this document.
In Figure 6, the policy component is shown providing input to the PCE component. This policy component may consult an external policy database, but this is outside the scope of this document.
Farrel, et al. Informational [Page 26] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 26] RFC 4655 PCE Architecture August 2006
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| |Component|--->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
------------------------------ | --------- | Routing ---------- | | | | Protocol | | | | TED |<-+----------+-> | | | | | | | | --------- | | | | | | | | | | Input | | | | v | | | | --------- --------- | | | | | Policy | | | | | Adjacent | | |Component|--->| PCE | | | Node | | | | | | | | | | --------- --------- | | | | ^ | | | | |Request | | | | |Response| | | | v | | | | --------- | | | Service | | | | Signaling| | Request | |Signaling| | Protocol | | ------+---------------->| Engine |<-+----------+-> | | | | | | | | --------- | ---------- ------------------------------
Figure 6. Policy Component in the Composite PCE Node
Figure 6. Policy Component in the Composite PCE Node
Note that policy information may be conveyed on the internal interfaces, and on the external protocol interfaces.
Note that policy information may be conveyed on the internal interfaces, and on the external protocol interfaces.
Figure 7 displays the case of a distinct PCE function through the example of the multiple PCE with inter-PCE communication example (compare with Figure 4). Each PCE takes input from local policy as part of the router computation/determination process. The local policy components may consult external policy components or databases, but that is out of the scope of this document.
Figure 7 displays the case of a distinct PCE function through the example of the multiple PCE with inter-PCE communication example (compare with Figure 4). Each PCE takes input from local policy as part of the router computation/determination process. The local policy components may consult external policy components or databases, but that is out of the scope of this document.
Note that policy information may be conveyed on the external protocol interfaces, including the inter-PCE interface.
Note that policy information may be conveyed on the external protocol interfaces, including the inter-PCE interface.
Farrel, et al. Informational [Page 27] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 27] RFC 4655 PCE Architecture August 2006
------------------ ------------------
| | 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 |
---------- ---------- ----------
------------------ ------------------ | | Inter-PCE Request/Response| | | PCE |<------------------------->| PCE | | | | | | ------ ----- | | ------ ----- | | |Policy| | TED | | | |Policy| | TED | | | ------ ----- | | ------ ----- | ------------------ ------------------ ^ | Request/ | Response v Service ---------- Signaling ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | ---->| Node |<---------->| Node |<---------->| Node | ---------- ---------- ----------
Figure 7. Policy Components in Multiple PCEs
Figure 7. Policy Components in Multiple PCEs
6.11.2. Policy Realization
6.11.2. Policy Realization
There are multiple options for how policy information is coordinated.
There are multiple options for how policy information is coordinated.
- Policy decisions may be made by PCCs before consulting PCEs. This
type of decision includes selection of PCE, application of
constraints, and interpretation of service requests.
- Policy decisions may be made by PCCs before consulting PCEs. This type of decision includes selection of PCE, application of constraints, and interpretation of service requests.
- Policy decisions may be made independently at a PCE, or at each
cooperating PCE. That is, the PCE(s) may make policy decisions
independent of other policy decisions made at PCCs or other PCEs.
- Policy decisions may be made independently at a PCE, or at each cooperating PCE. That is, the PCE(s) may make policy decisions independent of other policy decisions made at PCCs or other PCEs.
- There may also be explicit communication of policy information
between PCC and PCE, or between PCEs to achieve some level of
coordination of policy between entities. The type of information
conveyed to support policy has important implications on what
policies may be applied at each PCE, and the requirements for the
exchange of policy information inform the choice or implementation
of communication protocols including PCC-PCE, PCE-PCE, and
discovery protocols.
- There may also be explicit communication of policy information between PCC and PCE, or between PCEs to achieve some level of coordination of policy between entities. The type of information conveyed to support policy has important implications on what policies may be applied at each PCE, and the requirements for the exchange of policy information inform the choice or implementation of communication protocols including PCC-PCE, PCE-PCE, and discovery protocols.
6.11.3. Type of Policies
6.11.3. Type of Policies
Within the context of PCE, we identify several types of policies:
Within the context of PCE, we identify several types of policies:
o User-specific policies operate on information that is specific to
the user of a service or the service itself, that is, the service
for which the path is being computed, not the computation service.
Examples of such information includes the contents of objects of a
o User-specific policies operate on information that is specific to the user of a service or the service itself, that is, the service for which the path is being computed, not the computation service. Examples of such information includes the contents of objects of a
Farrel, et al. Informational [Page 28] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 28] RFC 4655 PCE Architecture August 2006
signaling or provisioning message, the port ID over which the
message was received, a VPN ID, a reference point type, or the
identity of the user initiating the request. User-specific
policies could be applied by a PCC while building a path
computation request, or by a PCE while processing the request
provided that sufficient information is supplied by the PCC to the
PCE.
signaling or provisioning message, the port ID over which the message was received, a VPN ID, a reference point type, or the identity of the user initiating the request. User-specific policies could be applied by a PCC while building a path computation request, or by a PCE while processing the request provided that sufficient information is supplied by the PCC to the PCE.
o Request-specific policies operate on information that is specific
to a path computation request and is carried in the request.
Examples of such information include constraints, diversities,
constraint and diversity relaxation strategies, and optimization
functions. Request-specific policies directly affect the path
selection process because they specify which links, nodes, path
segments, and/or paths are not acceptable or, on the contrary, may
be desirable in the resulting paths.
o Request-specific policies operate on information that is specific to a path computation request and is carried in the request. Examples of such information include constraints, diversities, constraint and diversity relaxation strategies, and optimization functions. Request-specific policies directly affect the path selection process because they specify which links, nodes, path segments, and/or paths are not acceptable or, on the contrary, may be desirable in the resulting paths.
o Domain-specific policies operate on the identify of the domain in
which the requesting PCC exists, and upon the identities of the
domains through which the resulting paths are routed. These
policies have the same effect as user-specific policies, with the
difference that they can be applied to a group of users rather than
an individual user. One example of domain-specific policy is a
restriction on what information a PCE publishes within a given
domain. In such a case, PCEs in some domains may advertise just
their presence, while others may advertise details regarding their
capabilities, client authentication process, and computation
resource availability.
o Domain-specific policies operate on the identify of the domain in which the requesting PCC exists, and upon the identities of the domains through which the resulting paths are routed. These policies have the same effect as user-specific policies, with the difference that they can be applied to a group of users rather than an individual user. One example of domain-specific policy is a restriction on what information a PCE publishes within a given domain. In such a case, PCEs in some domains may advertise just their presence, while others may advertise details regarding their capabilities, client authentication process, and computation resource availability.
6.11.4. Relationship to Signaling
6.11.4. Relationship to Signaling
When a path for an inter-domain TE LSP is being computed, it is not required to consider signaling plane policy. However, failure to do so may result in the TE LSP failing to be established, or being assigned fewer resources than intended resulting in a substandard service. Thus, where a PCE invoked by a head-end LSR has visibility into other domains, it should be capable of applying policy considerations to the computation and should be aware of the inter- domain policy agreements. Where path computation is the result of cooperation between PCEs, each of which is responsible for a particular domain, the policy issues should, where possible, be resolved at the time of computation so that the TE LSP is more likely to be signaled successfully. In this context, policy violation during inter-domain TE LSP computation may lead to path computation interruption, about which the requester should be notified along with the cause.
When a path for an inter-domain TE LSP is being computed, it is not required to consider signaling plane policy. However, failure to do so may result in the TE LSP failing to be established, or being assigned fewer resources than intended resulting in a substandard service. Thus, where a PCE invoked by a head-end LSR has visibility into other domains, it should be capable of applying policy considerations to the computation and should be aware of the inter- domain policy agreements. Where path computation is the result of cooperation between PCEs, each of which is responsible for a particular domain, the policy issues should, where possible, be resolved at the time of computation so that the TE LSP is more likely to be signaled successfully. In this context, policy violation during inter-domain TE LSP computation may lead to path computation interruption, about which the requester should be notified along with the cause.
Farrel, et al. Informational [Page 29] RFC 4655 PCE Architecture August 2006
Farrel, et al. Informational [Page 29] RFC 4655 PCE Architecture August 2006
6.12. Unsolicited Interactions
6.12. Unsolicited Interactions
It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction. For example, the PCE and PCC could exchange capabilities using this protocol. Additionally, the protocol could be used to collect and report information in support of a stateful PCE.
It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction. For example, the PCE and PCC could exchange capabilities using this protocol. Additionally, the protocol could be used to collect and report information in support of a stateful PCE.
Furthermore, it may be the case that a PCE is able to update a path that it computed earlier (perhaps in reaction to a change in the network or a change in policy), and in this case the PCE-PCC communication could support an "unsolicited" path computation message to supply this new path to the PCC. Note, however, that this function would require that the PCE retained a record of previous computations and had a clear trigger for performing recomputations. The PCC would also need to be able to identify the new path with the old path and determine whether it should act on the new path. Further, the PCC should be able to report the outcome of such path changes to the requesting PCE. Note that the PCE-PCC interaction is not a management interaction and the PCC is not obliged to utilize any additional path supplied by the PCE.
Furthermore, it may be the case that a PCE is able to update a path that it computed earlier (perhaps in reaction to a change in the network or a change in policy), and in this case the PCE-PCC communication could support an "unsolicited" path computation message to supply this new path to the PCC. Note, however, that this function would require that the PCE retained a record of previous computations and had a clear trigger for performing recomputations. The PCC would also need to be able to identify the new path with the old path and determine whether it should act on the new path. Further, the PCC should be able to report the outcome of such path changes to the requesting PCE. Note that the PCE-PCC interaction is not a management interaction and the PCC is not obliged to utilize any additional path supplied by the PCE.
These functions fit easily within the architecture described here but are left for further discussion within separate requirements documents.
These functions fit easily within the architecture described here but are left for further discussion within separate requirements documents.
6.13. Relationship with Crankback
6.13. Relationship with Crankback
Crankback routing is a mechanism whereby a failure to establish a path or a failure of an existing path may be corrected by a new path computation and fresh signaling. Crankback routing relies on the distribution of crankback information along with the failure notification so that the new computation can be performed avoiding the failure or blockage point.
Crankbackルーティングは経路を確立しないことか既存の経路の失敗が新しい経路計算と新鮮なシグナリングによって修正されるかもしれないメカニズムです。 Crankbackルーティングは、失敗か封鎖ポイントを避けながら新しい計算を実行できるように失敗通知に伴うcrankback情報の分配に依存します。
In the context of PCE, crankback information may be passed back to the head-end where the process of computation and signaling can be repeated using the failed resource as an exclusion in the computation process. But crankback may be used to attempt to correct the problem at intermediate points along the path. Such crankback recomputation nodes are most likely to be domain boundaries where the PCC had already invoked a PCE. Thus, a failure within a domain is reported to the ingress domain boundary, which will attempt to compute an alternate path across the domain. Failing this, the problem may be reported to the previous domain and communicated to the ingress boundary for that domain, which may attempt to select a more
PCEの文脈では、どこで除外として計算の過程で失敗したリソースを使用することで計算とシグナリングの過程を繰り返すことができるかというcrankback情報はギヤエンドまで戻されるかもしれません。 しかし、crankbackは、経路に沿った中間的ポイントで問題を修正するのを試みるのに使用されるかもしれません。 そのようなcrankback recomputationノードはPCCが既にPCEを呼び出したドメイン境界である最も傾向があります。 したがって、ドメインの中の失敗はイングレスドメイン境界に報告されます。(それは、ドメインの向こう側に代替パスを計算するのを試みるでしょう)。 これに失敗して、問題は、そのドメインのために前のドメインに報告されて、イングレス境界に伝えられるかもしれません。(それは、aをさらに選択するのを試みるかもしれません)。
Farrel, et al. Informational [Page 30] RFC 4655 PCE Architecture August 2006
ファレル、他 [30ページ]情報のRFC4655PCE構造2006年8月
successful path either by choosing a different entry point into the next domain, or by selecting a route through a different set of domains.
次のドメインに異なったエントリー・ポイントを選ぶか、または異なったセットのドメインを通してルートを選択するのによるうまくいっている経路。
7. The View from the Path Computation Client
7. 経路計算クライアントからの視点
The view of the PCE architecture, and particularly the functional model, is subtly different from the PCC's perspective. This is partly because the PCC has limited knowledge of the way in which the PCEs cooperate to answer its requests, but depends more on the fact that the PCC is concerned with different questions.
PCE構造の視点、および特に機能論的モデルはPCCの見解とかすかに異なっています。 これは一部、PCCがPCEsが協力する、要求に答える方法の知識不足を持っていますが、PCCは異なった質問に関係があるというさらに事実によるからです。
The PCC is interested in the following:
PCCは以下に興味を持っています:
- Selecting a PCE that is able to promptly provide a computed path
that meets the supplied constraints.
- 即座に計算された経路にそれを提供できるPCEを選択すると、供給された規制は満たされます。
- How many computation requests will the PCC have to send? Will the
desired path be computed by the first PCE contacted (possibly in
cooperation with other PCEs), or will the PCC have to consult other
PCEs to fill in gaps in the path?
- PCCはいくつの計算要求を送らなければならないでしょうか? 必要な経路がPCEが連絡した(ことによると他のPCEsと提携して)1日が計算されるでしょうか、またはPCCは、経路に不足に記入するために他のPCEsに相談しなければならないでしょうか?
- How many other path computations will need to be issued from within
the network in order to establish the TE LSP?
- 他のいくつの経路計算が、TE LSPを設立するためにネットワークの中で起こされる必要があるでしょうか?
This last question might be considered out of scope for the head-end LSR, but an important constraint that the PCC may wish to apply is that the path should be computed in its entirety and supplied without loose hops or non-simple abstract nodes.
この最後の質問は範囲からギヤエンドLSRと考えられるかもしれませんが、PCCが適用したがっているかもしれないという重要な規制はゆるいホップも非単純の抽象的なノードなしで経路を全体として計算して、供給するべきであるということです。
Thus, with its limited perspective, the PCC will see Multiple PCE Path Computation (Section 5.3) as important and will distinguish two subcases. The first is as shown in Figure 3 with subsequent computation requests made by other PCCs along the path of the TE LSP. In the second, multiple computation requests are issued by the head- end LSR. On the other hand, the PCC will not be aware of Multiple PCE Path Computation with Inter-PCE Communication (Section 5.4), which it will perceive as no different from the simple External PCE Node case (Section 5.2).
したがって、限られた見解で、PCCはMultiple PCE Path Computation(セクション5.3)が重要であるとみなして、2「副-ケース」を区別するでしょう。 その後の計算要求がTE LSPの経路に沿った他のPCCsによってされている状態で、1番目が図3に示されるようにあります。 2番目では、複数の計算要求がヘッド終わりのLSRまでに出されます。 他方では、PCCはInter-PCE Communication(セクション5.4)とMultiple PCE Path Computationを意識しないでしょう。(それは簡単なExternal PCE Nodeケース(セクション5.2)と異ならないとしてInter-PCE Communicationを知覚するでしょう)。
The PCC, therefore, will be acutely aware that a Centralized PCE Model (Section 6.1) might still require Multiple PCE Path Computations with the head-end or subsequent PCCs required to issue further requests to the central PCE. Conversely, the PCC may be protected from the Distributed PCE Model (Section 6.2) because the first PCE it consults uses inter-PCE communication to achieve a complete computation result so that no further computation requests are required.
したがって、PCCはCentralized PCE Model(セクション6.1)がまだギヤエンドかその後のPCCsが中央のPCEにさらなる要求を出していなければならないMultiple PCE Path Computationsを必要としているかもしれないのを鋭く意識するでしょう。 それが相談する最初のPCEが完全な計算結果を獲得するのに相互PCEコミュニケーションを使用するので逆に、PCCがDistributed PCE Model(セクション6.2)から保護されるかもしれないので、さらなる計算要求は全く必要ではありません。
Farrel, et al. Informational [Page 31] RFC 4655 PCE Architecture August 2006
ファレル、他 [31ページ]情報のRFC4655PCE構造2006年8月
These distinctions can be completely classified by determining whether the computation response includes all necessary paths, and whether those paths are fully explicit (that is, containing only strict hops between simple abstract nodes).
計算応答がすべての必要な経路を含むかどうかと、それらの経路が完全に明白であるかどうか(すなわち、簡単な抽象的なノードの間に厳しいホップだけを含んでいます)決定することによって、これらの区別を完全に分類できます。
8. Evaluation Metrics
8. 評価測定基準
Evaluation metrics that may be used to evaluate the efficiency and applicability of any PCE-based solution are listed below. Note that these metrics are not being used to determine paths, but are used to evaluate potential solutions to the PCE architecture.
どんなPCEベースの解決策の効率と適用性も評価するのに使用されるかもしれない評価測定基準は以下に記載されています。 これらの測定基準が経路を決定するのに使用されていませんが、PCE構造の潜在的解答を評価するのに使用されることに注意してください。
- Optimality: The ability to maximize network utilization and
minimize cost, considering QoS objectives, multiple regions, and
network layers. Note that models that require the sequential
involvement of multiple PCEs (for example, the multiple PCE model
described in Section 5.3) might create path loops unless careful
policy is applied.
- 最適: ネットワーク利用を最大にして、費用を最小にする能力、QoSが目的であると考える、複数の領域、およびネットワーク層。 慎重な方針が適用されていない場合複数のPCEs(例えばセクション5.3で説明された複数のPCEモデル)の連続したかかわり合いを必要とするモデルが経路輪を作成するかもしれないことに注意してください。
- Scalability: The implications of routing, TE LSP signaling, and PCE
communication overhead, such as the number of messages and the size
of messages (including LSAs, crankback information, queries,
distribution mechanisms, etc.).
- スケーラビリティ: メッセージの数やメッセージのサイズなどのルーティングの含意、TE LSPシグナリング、およびPCEコミュニケーションオーバーヘッド(LSAs、crankback情報、質問、分配メカニズムなどを含んでいます)。
- Load sharing: The ability to allow multiple PCEs to spread the path
computation load by allowing multiple PCEs each to take
responsibility for a subset of the total path computation requests.
- 負荷分割法: 複数のPCEsがそれぞれ総経路計算要求の部分集合への責任を取るのを許容することによって複数のPCEsが経路計算負荷を広げるのを許容する能力。
- Multi-path computation: The ability to compute multiple and
potentially diverse paths to satisfy load-sharing of traffic and
protection/restoration needs including end-to-end diversity and
protection within individual domains.
- マルチ経路計算: 交通と保護/回復の負荷分割法を満たすために複数の、そして、潜在的に多様な経路を計算する能力は、個々のドメインの中に終わりから終わりへの多様性と保護を含む必要があります。
- Reoptimization: The ability to perform TE LSP path reoptimization.
This also includes the ability to perform inter-layer correlation
when considering the reoptimization at any specific layer.
- Reoptimization: 履行能力TE LSP経路「再-最適化」。 また、これはどんな特定の層でも「再-最適化」を考えるとき相互層の相関関係を実行する能力を含んでいます。
- Path computation time: The time to compute individual paths and
multiple diverse paths and to satisfy bulk path computation
requests. (Note that such a metric can only be applied to problems
that are not NP-complete.)
- 経路計算時間: 個々の経路と複数のさまざまの経路を計算して、大量の経路計算要求を満たす時間。 (そのようなメートル法の缶がNP完全でない問題に適用されるだけであることに注意してください。)
- Network stability: The ability to minimize any perturbation on
existing TE state resulting from the computation and establishment
of new TE paths.
- 安定性をネットワークでつないでください: TEが述べる存在のときに新しいTE経路の計算と設立から生じながらどんな摂動も最小にする能力。
- Ability to maintain accurate synchronization between TED and
network topology and resource states.
- TEDと、ネットワーク形態とリソース州の間の正確な同期を維持する能力。
Farrel, et al. Informational [Page 32] RFC 4655 PCE Architecture August 2006
ファレル、他 [32ページ]情報のRFC4655PCE構造2006年8月
- Speed with which TED synchronization is achieved.
- どのTED同期が達成されるかで、疾走してください。
- Impact of the synchronization process on the data flows in the
network.
- 同期の過程のデータへの影響はネットワークで流れます。
- Ability to deal with situations where paths satisfying a required
set of constraints cannot be found by the PCE.
- PCEが必要な規制を満たす経路を見つけることができない状況に対処する能力。
- Policy: Application of policy to the PCC-PCE and PCE-PCE
communications as well as to the computation of paths that respect
inter-domain TE LSP establishment policies.
- 方針: PCC-PCEへの方針とコミュニケーションと経路の計算への相互ドメインTE LSP設立方針を尊敬するPCE-PCEのアプリケーション。
Note that other metrics may also be considered. Such metrics should be used when evaluating a particular PCE-based architecture. The potential tradeoffs of the optimization of such metrics should be evaluated (for instance, increasing the path optimality is likely to have consequences on the computation time).
また、他の測定基準が考えられるかもしれないことに注意してください。 特定のPCEベースの構造を評価するとき、そのような測定基準は使用されるべきです。 そのような測定基準の最適化の潜在的見返りは評価されるべきです(例えば、経路の最適を増加させるのは計算時間に結果を持っていそうです)。
9. Manageability Considerations
9. 管理可能性問題
The PCE architecture introduces several elements that are subject to manageability. The PCE itself must be managed, as must its communications with PCCs and other PCEs. The mechanism by which PCEs and PCCs discover each other are also subject to manageability.
PCE構造は数個の受けることがある要素を管理可能性に送り込みます。 PCCsと他のPCEsとのコミュニケーションでなければならないことのようにPCE自身を管理しなければなりません。 また、PCEsとPCCsが互いを発見するメカニズムも管理可能性を受けることがあります。
Many of the issues of manageability are already covered in other sections of this document.
管理可能性の問題の多くがこのドキュメントの他のセクションで既にカバーされています。
9.1. Control of Function and Policy
9.1. 機能と方針のコントロール
It must be possible to enable and disable the PCE function at a PCE, and this will lead to the PCE accepting, rejecting, or simply not receiving requests from PCCs. Graceful shutdown of the PCE function should also be considered so that in controlled circumstances (such as software upgrade) a PCE does not just 'disappear' but warns its PCCs and gracefully handles any queued computation requests (perhaps by completing them, forwarding them to another PCE, or rejecting them).
PCEでPCE機能を可能にして、無効にするのが可能であるに違いなく、これはPCCsからPCE受諾、拒絶、または絶対に受信していない要求に通じるでしょう。 また、PCE機能の優雅な閉鎖が考えられるべきであるので、PCEは制御事情(ソフトウェアの更新などの)で単に'見えなくなりません'が、PCCsに警告して、優雅にどんな列に並ばせられた計算要求も扱います(恐らく、それらを完成するか、別のPCEにそれらを送るか、またはそれらを拒絶することによって)。
Similarly it must be possible to control the application of policy at the PCE through configuration. This control may include the restriction of certain functions or algorithms, the configuration of access rights and priorities for PCCs, and the relationships with other PCEs both inside and outside the domain.
同様に、構成を通してPCEで方針の適用を制御するのは可能でなければなりません。 このコントロールはある機能かアルゴリズムの制限、PCCsのためのアクセス権とプライオリティの構成、およびドメインとドメインの外の他のPCEsとの関係を含むかもしれません。
The policy configuration interface is yet to be determined. The interface may be purely a local matter, or it may be supported via a standardized interface (such as a MIB module).
方針構成インタフェースはまだ断固としていません。 インタフェースは純粋に地域にかかわる事柄であるかもしれませんかそれが標準化されたインタフェース(MIBモジュールなどの)を通して支持されるかもしれません。
Farrel, et al. Informational [Page 33] RFC 4655 PCE Architecture August 2006
ファレル、他 [33ページ]情報のRFC4655PCE構造2006年8月
9.2. Information and Data Models
9.2. 情報とデータモデル
It is expected that the operations of PCEs and PCCs will be modeled and controlled through appropriate MIB modules. The tables in the new MIB modules will need to reflect the relationships between entities and to control and report on configurable options.
PCEsとPCCsの操作が適切なMIBモジュールでモデル化されて、制御されると予想されます。 新しいMIBモジュールによるテーブルは、構成可能なオプションに関して実体の間の関係を反映して、制御して、報告する必要があるでしょう。
Statistics gathering will form an important part of the operation of PCEs. The operator must be able to determine the historical interactions of a PCC with its PCEs, the performance that it has seen, and the success rate of its requests. Similarly, it is important for an operator to be able to inspect a PCE and determine its load and whether an individual PCC is responsible for a disproportionate amount of the load. It will also be important to be able to record and inspect statistics about the communications between the PCC and PCE, including issues such as malformed messages, unauthorized messages, and messages discarded because of congestion. In this respect, there is clearly an overlap between manageability and security.
統計集会はPCEsの操作の重要な部分を形成するでしょう。 オペレータはPCEsとのPCCの歴史的な相互作用、それが見た性能、および要求の成功率を測定できなければなりません。 同様に、オペレータが、PCEを点検して、負荷であって個々のPCCは負荷の不釣り合いな額に責任があるかどうか決定できるのが、重要です。 また、PCCとPCEとのコミュニケーションに関する統計を記録して、点検できるのも重要でしょう、奇形のメッセージや、権限のないメッセージや、混雑のために捨てられたメッセージなどの問題を含んでいて。 この点で、管理可能性とセキュリティの間には、オーバラップが明確にあります。
Statistics for the PCE architecture can be made available through appropriate tables in the new MIB modules.
PCE構造のための統計を新しいMIBモジュールによる適切なテーブルを通して利用可能にすることができます。
The new MIB modules should also be used to provide notifications when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with Simple Network Management Protocol (SNMP) notifications. Thus, it might be inappropriate to issue a notification every time a PCE receives a request to compute a path. In any case, full control must be provided to allow notifications to be disabled using, for example, the mechanisms defined in the SNMP-NOTIFICATION-MIB module in [RFC3413].
また、主要な敷居が交差しているか、または重大事件が起こるとき、新しいMIBモジュールは、通知を提供するのに使用されるべきです。 ネットワークがSimple Network Managementプロトコル(SNMP)通知であふれないのを保証するのに高度の注意を運動させなければなりません。 したがって、PCEが経路を計算するという要求を受け取るときはいつも、通知書を発行するのは不適当であるかもしれません。 どのような場合でも、通知が無効にされるのを例えば[RFC3413]のSNMP-NOTIFICATION-MIBモジュールで定義されたメカニズムを使用することで許容するために完全なコントロールを提供しなければなりません。
9.3. Liveness Detection and Monitoring
9.3. 活性検出とモニター
Section 6.5 discusses the importance of a PCC being able to detect the liveness of a PCE. PCE-PCC communications techniques must enable a PCC to determine the liveness of a PCE both before it sends a request and in the period between sending a request and receiving a response.
セクション6.5はPCEの活性を検出できるPCCの重要性について論じます。 PCE-PCCコミュニケーションのテクニックは、要求を送って、応答を受けるときPCCが要求を送る前と時代にPCEの活性を決定するのを可能にしなければなりません。
It is less important for a PCE to know about the liveness of PCCs, and within the simple request/response model, this is only helpful
PCEがPCCsの活性に関して知るのが、それほど重要でなく、簡単な要求/応答モデルの中では、これは役立っているだけです。
- to gain a predictive view of the likely loading of a PCE in the
future, or
- または将来PCEのありそうな荷重の予言の意見を獲得するために。
- to allow a PCE to abandon processing of a received request.
- PCEが受信された要求の処理を捨てるのを許容するために。
Farrel, et al. Informational [Page 34] RFC 4655 PCE Architecture August 2006
ファレル、他 [34ページ]情報のRFC4655PCE構造2006年8月
9.4. Verifying Correct Operation
9.4. 正しい操作について確かめます。
Correct operation for the PCE architecture can be classified as determining the correct point-to-point connectivity between PCCs and PCEs, and as assessing the validity of the computed paths. The former is a security issue that may be enhanced by authentication and monitored through event logging and records as described in Section 9.1. It may also be a routing issue to ensure that PCC-PCE connectivity is possible.
PCCsとPCEsの間の正しい二地点間接続性を決定することとして計算された経路の正当性を評価することとしてPCE構造のための正しい操作を分類できます。 前者はセクション9.1で説明されるように認証で高められて、イベント伐採と記録を通してモニターされるかもしれない安全保障問題です。 また、PCC-PCEの接続性が可能であることは、確実にするルーティング問題であるかもしれません。
Verifying computed paths is more complex. The information to perform this function can, however, be made available to the operator through MIB tables, provided that full records are kept of the constraints passed on the request, the path computed and provided on the response, and any additional information supplied by the PCE such as the constraint relaxation policies applied.
計算された経路について確かめるのは、より複雑です。 しかしながら、この機能を実行する情報をMIBテーブルを通してオペレータにとって利用可能にすることができます、完全な記録は要求のときに通過された規制についてつけられます、と経路が応答、および方針が当てはまった規制緩和などのPCEによって提供されたどんな追加情報でも、計算して、前提としました。
9.5. Requirements on Other Protocols and Functional Components
9.5. 他のプロトコルと機能部品に関する要件
At the architectural stage, it is impossible to make definitive statements about the impact on other protocols and functional components since the solution's work has not been completed. However, it is possible to make some observations.
建築段階では、解決策の仕事が終了していないので、他のプロトコルと機能部品の上で衝撃に関する決定的な声明を出すのは不可能です。 しかしながら、いくつかの観測をするのは可能です。
- Dependence on underlying transport protocols
- 基本的なトランスポート・プロトコルへの依存
PCE-PCC communications may choose to utilize underlying protocols
to provide transport mechanisms. In this case, some of the
manageability considerations described in the previous sections may
be devolved to those protocols.
PCE-PCCコミュニケーションは、移送機構を提供するのに基本的なプロトコルを利用するのを選ぶかもしれません。この場合、前項で説明された管理可能性問題のいくつかをそれらのプロトコルへ譲り渡すかもしれません。
- Re-use of existing protocols for discovery
- 既存のプロトコルの発見の再使用
Without prejudicing the requirements and solutions work for PCE
discovery (see Section 6.4), it is possible that use will be made
of existing protocols to facilitate this function. In this case
some of the manageability considerations described in the previous
sections may be devolved to those protocols.
PCE発見(セクション6.4を見る)のための要件と解決策仕事に偏見をいだかせないで、この機能を容易にするために既存のプロトコルで使用をするのは可能です。 この場合、前項で説明された管理可能性問題のいくつかをそれらのプロトコルへ譲り渡すかもしれません。
- Impact on LSRs and TE LSP signaling
- LSRsとTE LSPシグナリングで影響を与えてください。
The primary example of a PCC identified in this architecture is an
MPLS or a GMPLS LSR. Consideration must therefore be given to the
manageability of the LSRs and the additional manageability
constraints applicable to the TE LSP signaling protocols.
この構造で特定されたPCCの第一の例は、MPLSかGMPLS LSRです。 したがって、TE LSPシグナリングプロトコルに適切なLSRsと追加管理可能性規制の管理可能性に対して考慮を払わなければなりません。
Farrel, et al. Informational [Page 35] RFC 4655 PCE Architecture August 2006
ファレル、他 [35ページ]情報のRFC4655PCE構造2006年8月
In addition to allowing the PCC management described in the
previous sections, an LSR must be configurable to determine whether
it will use a remote PCE at all, the options being to use hop-by-
hop routing or to supply the PCE function itself. It is likely to
be important to be able to distinguish within an LSR whether the
route used for a TE LSP was supplied in a signaling message from
another LSR, by an operator, or by a PCE, and, in the case where it
was supplied in a signaling message, whether it was enhanced or
expanded by a PCE.
前項で説明されたPCC管理を許すことに加えて、LSRはそれが全くリモートPCEを使用するか否かに関係なく、使用にはあるオプションがルーティングを近く跳ぶほど飛び越すことを決定するか、またはPCE機能自体を供給するのにおいて構成可能であるに違いありません。 それはそして、シグナリングメッセージで別のLSRからTE LSPに使用されるルートを供給したか否かに関係なく、オペレータ、またはPCEがLSRの中でそれがシグナリングメッセージで供給された場合で区別できるように重要である傾向があります、それがPCEによって高められたか、または広げられたことにかかわらず。
- Reuse of existing policy models and mechanisms
- 既存の政策モデルとメカニズムの再利用
As policy support mechanisms can be quite extensive, it is
worthwhile to explore to what extent this prior work can be
leveraged and applied to PCE. This desire to leverage prior work
should not be interpreted as a requirement to use any particular
solution or protocol.
方針サポートメカニズムがかなり大規模であることができるように、この先の仕事にPCEに投機していて、適用できるというどんな範囲まで探検するか価値があります。 どんな特殊解やプロトコルも使用するという要件として先の仕事に投機するこの願望を解釈するべきではありません。
9.6. Impact on Network Operation
9.6. ネットワーク操作のときに、影響を与えてください。
This architecture may have two impacts on the operation of a network. It increases TE LSP setup times while requests are sent to and processed by a remote PCE, and it may cause congestion within the network if a significant number of computation requests are issued in a small period of time. These issues are most severe in busy networks and after network failures, although the effect may be mitigated if the protection paths are precomputed or if the path computation load is distributed among a set of PCEs.
この構造はネットワークの操作に2回の影響力を持っているかもしれません。 それは、リモートPCEで要求を送る間のTE LSPセットアップ回数を増加させて、処理しました、そして、多くの計算要求が小さい期間で出されるなら、ネットワークの中で混雑を引き起こすかもしれません。 これらの問題は忙しいネットワークとネットワーク失敗の後に最も厳しいです、保護経路が前計算されるなら効果が緩和されるかもしれないか、または経路計算負荷がPCEsの1セットの中で分配されるなら。
Issues of potential congestion during recovery from failures may be mitigated through the use of pre-established protection schemes such as fast reroute.
失敗からの回復の間の潜在的混雑の問題は速くコースを変更するようなプレ確立した保護計画の使用で緩和されるかもしれません。
It is important that network congestion be managed proactively because it may be impossible to manage it reactively once the network is congested. It should be possible for an operator to rate limit the requests that a PCC sends to a PCE, and a PCE should be able to report impending congestion (according to a configured threshold) both to the operator and to its PCCs.
ネットワークがいったん混雑するようになるとそれを反動的に管理するのが不可能であるかもしれないのでネットワークの混雑が予測して管理されるのは、重要です。 混雑(構成された敷居に従って)をオペレータと、そして、そのPCCsに迫らせると報告するのはオペレータが評価するように、PCCが発信するという要求をPCEに制限してください。そうすれば、PCEができるべきであるのが可能であるべきです。
9.7. Other Considerations
9.7. 他の問題
No other management considerations have been identified.
他の管理問題は全く特定されていません。
Farrel, et al. Informational [Page 36] RFC 4655 PCE Architecture August 2006
ファレル、他 [36ページ]情報のRFC4655PCE構造2006年8月
10. Security Considerations
10. セキュリティ問題
The impact of the use of a PCE-based architecture must be considered in the light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. The impact may be less likely to be an issue in the case of intra-domain use of PCE, but an increase in inter-domain information flows and the facilitation of inter-domain path establishment may increase the vulnerability to security attacks.
それがネットワークの中に既存のルーティングと使用中のプロトコルとテクニックに合図するセキュリティに持っている影響力の見地からPCEベースの構造の使用の影響を考えなければなりません。 相互ドメイン情報の増加は流れます、そして、衝撃はそれほどPCEのイントラドメイン使用の場合における問題である傾向がないかもしれませんが、相互ドメイン経路設立の簡易化はセキュリティー攻撃に脆弱性を増加させるかもしれません。
Of particular relevance are the implications for confidentiality inherent in a PCE-based architecture for multi-domain networks. It is not necessarily the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their effects in this area.
特定の関連性において、マルチドメインネットワークに、PCEベースの構造に固有の秘密性のための含意はそうですか? マルチドメインPCE解決策がセキュリティで妥協しますが、解決策がこの領域のそれらの効果を調べなければならないのは、必ず事実であるというわけではありません。
Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections.
シグナリング、ルーティング、および経路計算のテクニックの特定の組み合わせのための適用性証明が詳細なセキュリティ部を含むと予想されます。
Note that the use of a non-local PCE (that is, one not co-resident with the PCC) does introduce additional security issues. Most notable among these are:
非地方のPCE(すなわち、PCCをもっているコレジデントではなく、1)の使用が追加担保問題を紹介することに注意してください。 このうち最も注目に値するのは、以下の通りです。
- interception of PCE requests or responses;
- PCE要求か応答の妨害。
- impersonation of PCE or PCC;
- PCEかPCCのものまね。
- falsification of TE information, policy information, or PCE
capabilities; and
- TE情報、方針情報、またはPCE能力の改竄。 そして
- denial-of-service attacks on PCE or PCE communication mechanisms.
- PCEにおけるサービス不能攻撃かPCEコミュニケーションメカニズム。
It is expected that PCE solutions will address these issues in detail using authentication and security techniques.
PCE解決策が詳細に認証とセキュリティのテクニックを使用することでこれらの問題を記述すると予想されます。
11. Acknowledgements
11. 承認
The authors would like to extend their warmest thanks to (in alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for their review and suggestions. Lou Berger provided valuable and detailed contributions to the discussion of policy in this document.
作者は(アルファベット順に)Arthi Ayyangar、Zafarアリ、ルウ・バーガー、モハメドBoucadair、イーゴリBryskin、ディーン・チェン、Vivek Dubey、Kireeti Kompella、ジャン・ルイル・ルー、スティーブンモリス、Eiji Oki、ディミトリPapadimitriou、リチャードRabbat、Payam Torab、清水高尾、およびレイモンド・チャンのおかげで彼らのレビューと提案における彼らの最も暖かさを広げたがっています。 ルウ・バーガーは本書では方針の議論への貴重で詳細な貢献を提供しました。
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review and constructive discussions during the final stages of publication.
また、レビューと建設的な討議を公表の最終段階の間、ペッカSavola、ラスHousley、およびデーヴKessensをありがとうございます。
Farrel, et al. Informational [Page 37] RFC 4655 PCE Architecture August 2006
ファレル、他 [37ページ]情報のRFC4655PCE構造2006年8月
12. Informative References
12. 有益な参照
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC2702]AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年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月。
[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月。」
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3413] レビ、D.、マイヤー、P.、およびB.スチュワート、「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」、STD62、RFC3413、2002年12月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
[RFC3748] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3748] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC3812] Srinivasan、C.、Viswanathan、A.、およびT.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、2004年6月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、「相互領域MPLS交通工学のための要件」、RFC4105、2005年6月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
[RFC4216] チャン、R.、およびJ.-P。 Vasseur、「MPLS相互自律システム(AS)交通工学(Te)要件」、RFC4216、2005年11月。
[MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)", Work in
Progress, June 2006.
[MLN] Progress(2006年6月)のShiomoto、K.、Papdimitriou、D.、ル・ルー、J.-L.、ビグルー、M.、およびD.Brungard、「GMPLSを拠点とするマルチ領域の、そして、マルチ層のネットワーク(MRN/MLN)のための要件」、Work。
Farrel, et al. Informational [Page 38] RFC 4655 PCE Architecture August 2006
ファレル、他 [38ページ]情報のRFC4655PCE構造2006年8月
Authors' Addresses
作者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
EMail: adrian@olddog.co.uk
メール: adrian@olddog.co.uk
Jean-Philippe Vasseur 1414 Massachussetts Avenue Boxborough, MA 01719 USA
ジャンフィリップVasseur1414MassachussettsアベニューBoxborough、MA01719米国
EMail: jpv@cisco.com
メール: jpv@cisco.com
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェリー灰のAT&T余地のMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー 07748、米国
Phone: (732)-420-4578 Fax: (732)-368-8659 EMail: gash@att.com
以下に電話をしてください。 (732)-420-4578 Fax: (732)-368-8659 メールしてください: gash@att.com
Farrel, et al. Informational [Page 39] RFC 4655 PCE Architecture August 2006
ファレル、他 [39ページ]情報のRFC4655PCE構造2006年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Farrel, et al. Informational [Page 40]
ファレル、他 情報[40ページ]
一覧
スポンサーリンク
