RFC4674 日本語訳
4674 Requirements for Path Computation Element (PCE) Discovery. J.L.Le Roux, Ed.. October 2006. (Format: TXT=40321 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J.L. Le Roux, Ed. Request for Comments: 4674 France Telecom Category: Informational October 2006
ワーキンググループのJ.L.ル・ルー、エドをネットワークでつないでください。コメントのために以下を要求してください。 4674年のフランス電子通信カテゴリ: 情報の2006年10月
Requirements for Path Computation Element (PCE) Discovery
経路計算要素(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
要約
This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.
このドキュメントはPath Computation Client(PCC)がダイナミックに自動的にPCE選択において、関連しているある情報に伴うPCEsの1セットを発見できるPath Computation Element(PCE)発見メカニズムのための1セットの要件を提示します。 そのようなPCE発見として手順とプロトコルか拡大を既存のプロトコルに指定する解決策がこれらの要件を満たすことを意図します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Problem Statement and Requirements Overview .....................4
2.1. Problem Statement ..........................................4
2.2. Requirements Overview ......................................5
3. Example of Application Scenario .................................6
4. Detailed Requirements ...........................................7
4.1. PCE Information to Be Disclosed ............................7
4.1.1. General PCE Information (Mandatory Support) .........8
4.1.1.1. Discovery of PCE Location ..................8
4.1.1.2. Discovery of PCE Domains and
Inter-domain Functions .....................8
4.1.2. Detailed PCE Information (Optional Support) .........9
4.1.2.1. Discovery of PCE Capabilities ..............9
4.1.2.2. Discovery of Alternate PCEs ...............10
4.2. Scope of PCE Discovery ....................................10
4.2.1. Inter-AS Specific Requirements .....................10
1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 1.2. 用語…3 2. 問題声明と要件概観…4 2.1. 問題声明…4 2.2. 要件概観…5 3. アプリケーションシナリオに関する例…6 4. 要件を詳しく述べます…7 4.1. 明らかにされるべきPCE情報…7 4.1.1. 一般PCE情報(義務的なサポート)…8 4.1.1.1. PCE位置の発見…8 4.1.1.2. PCEドメインと相互ドメイン機能の発見…8 4.1.2. 詳細なPCE情報(任意のサポート)…9 4.1.2.1. PCE能力の発見…9 4.1.2.2. 交互のPCEsの発見…10 4.2. PCE発見の範囲…10 4.2.1. 相互、決められた一定の要求…10
Le Roux Informational [Page 1] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[1ページ]のRFC4674Requirements
4.3. PCE Information Synchronization ...........................11
4.4. Discovery of PCE Deactivation .............................11
4.5. Policy Support ............................................12
4.6. Security Requirements .....................................12
4.7. Extensibility .............................................13
4.8. Scalability ...............................................13
4.9. Operational Orders of Magnitudes ..........................13
4.10. Manageability Considerations .............................14
4.10.1. Configuration of PCE Discovery Parameters .........14
4.10.2. PCE Discovery MIB Modules .........................14
4.10.2.1. PCC MIB Module ...........................14
4.10.2.2. PCE MIB module ...........................15
4.10.3. Monitoring Protocol Operations ....................15
4.10.4. Impact on Network Operations ......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Contributors ...................................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
4.3. PCE情報同期…11 4.4. PCE非活性化の発見…11 4.5. 方針サポート…12 4.6. セキュリティ要件…12 4.7. 伸展性…13 4.8. スケーラビリティ…13 4.9. 大きさの操作上の注文…13 4.10. 管理可能性問題…14 4.10.1. PCE発見パラメタの構成…14 4.10.2. PCE発見MIBモジュール…14 4.10.2.1. PCC MIBモジュール…14 4.10.2.2. PCE MIBモジュール…15 4.10.3. モニターしているプロトコル操作…15 4.10.4. ネットワークオペレーションで影響を与えてください…16 5. セキュリティ問題…16 6. 承認…16 7. 貢献者…17 8. 参照…17 8.1. 標準の参照…17 8.2. 有益な参照…17
1. Introduction
1. 序論
The PCE-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity capable of computing TE-LSP paths based on a network graph, and applying computational constraints. A PCE serves path computation requests sent by Path Computation Clients (PCC).
PCEベースのネットワークアーキテクチャ[RFC4655]はネットワークグラフに基づくTE-LSP経路を計算して、コンピュータの規制を適用できる実体とPath Computation Element(PCE)を定義します。 PCEはPath Computation Clients(PCC)によって送られた経路計算要求に役立ちます。
A PCC is a client application requesting a path computation to be performed by a PCE. This can be, for instance, an LSR requesting a path for a TE-LSP for which it is the head-end, or a PCE requesting a path computation of another PCE (inter-PCE communication). The communication between a PCC and a PCE requires a client-server protocol whose generic requirements are listed in [RFC4657].
PCCはPCEによって実行されるよう経路計算に要求するクライアントアプリケーションです。 例えば、これは、ギヤエンドであるTE-LSPのために経路を要求するLSR、または別のPCE(相互PCEコミュニケーション)の経路計算を要求するPCEであるかもしれません。 PCCとPCEとのコミュニケーションは一般的な要件が[RFC4657]にリストアップされているクライアント/サーバプロトコルを必要とします。
The PCE based architecture requires that a PCC be aware of the location of one or more PCEs in its domain, and also potentially of some PCEs in other domains, e.g., in case of inter-domain path computation.
PCEのベースの構造は、PCCが他のドメインのいくつかのPCEsでドメインに、潜在的にも1PCEsの位置を意識しているのを必要とします、例えば、相互ドメイン経路計算の場合に。
Le Roux Informational [Page 2] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[2ページ]のRFC4674Requirements
In that context, it would be highly desirable to define a mechanism for automatic and dynamic PCE discovery, which would allow PCCs to automatically discover a set of PCEs, to determine additional information required for PCE selection, and to dynamically detect new PCEs or any modification of the PCEs' information. This includes the discovery by a PCC of a set of one or more PCEs in its domain, and potentially in some other domains. The latter is a desirable function in the case of inter-domain path computation, for example.
その文脈では、自動でダイナミックなPCE発見のためにメカニズムを定義するのは非常に望ましいでしょう。(PCCsは自動的にPCEsの1セットを発見して、追加情報がPCE選択に必要であることを決定して、発見でダイナミックにPCEsの情報の新しいPCEsかどんな変更も検出するでしょう)。 これはある他のドメインにドメインに、潜在的に1PCEsの1セットのPCCによる発見を含んでいます。 後者は例えば、相互ドメイン経路計算の場合で望ましい機能です。
This document lists a set of functional requirements for such an automatic and dynamic PCE discovery mechanism. Section 2 points out the problem statement. Section 3 illustrates an application scenario. Finally, Section 4 addresses detailed requirements.
このドキュメントはそのような自動でダイナミックなPCE発見メカニズムのための1セットの機能条件書をリストアップします。 セクション2は問題声明を指摘します。 セクション3はアプリケーションシナリオを例証します。 最終的に、セクション4は詳細な要件を記述します。
It is intended that solutions that specify procedures and protocols or protocol extensions for PCE discovery satisfy these requirements. There is no intent either to specify solution-specific requirements or to make any assumption on the protocols that could be used for the discovery.
PCE発見のための手順とプロトコルかプロトコル拡大を指定する解決策がこれらの要件を満たすことを意図します。 解決策決められた一定の要求を指定するか、またはどんな仮定もする意図も全く発見に使用できたプロトコルにありません。
Note that requirements listed in this document apply equally to PCEs that are capable of computing paths in MPLS-TE-enabled networks and PCEs that are capable of computing paths in GMPLS-enabled networks (and PCEs capable of both).
本書ではリストアップされた要件が等しくMPLS-TEによって可能にされたネットワークで経路を計算できるPCEsとGMPLSによって可能にされたネットワーク(そして、両方ができるPCEs)で経路を計算できるPCEsに適用されることに注意してください。
It is also important to note that the notion of a PCC encompasses a PCE acting as PCC when requesting a path computation of another PCE (inter-PCE communication). Hence, this document does not make the distinction between PCE discovery by PCCs and PCE discovery by PCEs.
また、PCCの概念が別のPCE(相互PCEコミュニケーション)の経路計算を要求するときPCCとして機能するPCEを取り囲むことに注意するのも重要です。 したがって、このドキュメントはPCCsによるPCE発見とPCEsによるPCE発見の間で区別をしません。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
1.2. Terminology
1.2. 用語
Terminology used in this document:
このドキュメントで中古の用語:
LSR: Label Switch Router.
LSR: スイッチルータをラベルしてください。
TE-LSP: Traffic Engineered Label Switched Path.
Te-LSP: 交通の設計されたラベルは経路を切り換えました。
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.
PCE: 経路計算要素。 ネットワーク経路かルートを計算できる実体(コンポーネント、アプリケーション、またはネットワーク・ノード)は、ネットワークグラフと、コンピュータの規制を適用するのを基礎づけました。
Le Roux Informational [Page 3] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[3ページ]のRFC4674Requirements
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
PCC: 経路計算クライアント。 Path Computation Elementによって実行されるよう経路計算に要求するどんなクライアントアプリケーション。
Interior Gateway Protocol (IGP) Area: OSPF Area or ISIS level/area.
内部のゲートウェイプロトコル(IGP)部門: OSPF Areaかイシスレベル/領域。
ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router).
ABR: IGP Area Border Router(OSPF ABRかISIS L1L2ルータ)。
AS: Autonomous System.
: 自律システム。
ASBR: AS Border Router.
ASBR: 境界ルータとして。
Intra-area TE LSP: A TE LSP whose path does not cross IGP area boundaries.
イントラ領域Te LSP: 経路がIGPエリアの境界に交差しないTE LSP。
Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas.
相互領域Te LSP: 経路が2つ以上のIGP領域を通って通過するTE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASs or sub-ASs (BGP confederations).
相互、MPLS Te LSP: 経路が2ASsかサブASs(BGP同盟者)を通して通過するTE LSP。
Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP areas and Autonomous Systems.
ドメイン: アドレス管理か経路のコンピュータの責任の一般的な球の中のネットワーク要素のどんな収集。 ドメインに関する例はIGP領域とAutonomous Systemsを含んでいます。
2. Problem Statement and Requirements Overview
2. 問題声明と要件概観
2.1. Problem Statement
2.1. 問題声明
A routing domain may, in practice, contain multiple PCEs:
経路ドメインは実際には複数のPCEsを含むかもしれません:
- The path computation load may be balanced among a set of PCEs to
improve scalability.
- For the purpose of redundancy, primary and backup PCEs may be used.
- PCEs may have distinct path computation capabilities (multi-
constrained path computation, backup path computation, etc.).
- In an inter-domain context, there can be several PCEs with distinct
inter-domain functions (inter-area, inter-AS, inter-layer), each
PCE being responsible for path computation in one or more domains.
- 経路計算負荷は、スケーラビリティを改良するためにPCEsの1セットの中でバランスをとるかもしれません。 - 冗長の目的のために、予備選挙とバックアップPCEsは使用されるかもしれません。 - PCEsには、異なった経路計算能力(マルチ強制的な経路計算、バックアップ経路計算など)があるかもしれません。 - 相互ドメイン文脈には、異なった相互ドメイン機能(相互領域、相互ASは相互層にします)(1つ以上のドメインでの経路計算に責任があるそれぞれのPCE)がある数個のPCEsがあることができます。
In order to allow for effective PCE selection by PCCs, that is, to select the appropriate PCE based on its capabilities and perform efficient load balancing of requests, a PCC needs to know the location of PCEs in its domain, along with some information relevant to PCE selection, and also potentially needs to know the location of some PCEs in other domains, for inter-domain path computation purpose.
PCCsによる有効なPCE選択を考慮して、すなわち、PCCは、能力に基づく適切なPCEを選択して、要求の効率的なロードバランシングを実行するのに、PCE選択に関連している何らかの情報に伴うドメインでPCEsの位置を知るのが必要であり、また、潜在的に他のドメインでいくつかのPCEsの位置を知る必要があります、相互ドメイン経路計算目的のために。
Le Roux Informational [Page 4] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[4ページ]のRFC4674Requirements
Such PCE information could be learned through manual configuration, on each PCC, of the set of PCEs along with their capabilities. Such a manual configuration approach may be sufficient, and even desired in some particular situations (e.g., inter-AS PCE discovery, where manual configuration of neighbor PCEs may be preferred for security reasons), but it obviously faces several limitations:
手動の構成を通してそのようなPCE情報について学習できました、彼らの能力に伴うPCEsのセットの各PCCで。 そのような手動の構成アプローチは、十分であって、いくつかの特定の状況(例えば、隣人PCEsの手動の構成が安全保障上の理由で好まれるかもしれないところでの相互AS PCE発見)で必要でさえあるかもしれませんが、明らかにいくつかの制限に直面しています:
- This may imply a substantial configuration overhead.
- This would not allow a PCC to dynamically detect that a new PCE is
available, that an existing PCE is no longer available, or that
there is a change in the PCE's information.
- これはかなりの構成オーバーヘッドを含意するかもしれません。 - これで、ダイナミックにそのa新しいPCEを検出するPCCが利用可能であるか、既存のPCEがもう利用可能でないか、またはPCEの情報における変化がないでしょう。
Furthermore, as with any manual configuration approach, there is a risk of configuration errors.
その上、どんな手動の構成アプローチのようにも、構成誤りのリスクがあります。
As an example, in a multi-area network made up of one backbone area and N peripheral areas, and where inter-area MPLS-TE path computation relies on multiple-PCE path computation with ABRs acting as PCEs, the backbone area would comprise at least N PCEs, and the configuration of PCC would be too cumbersome (e.g., in existing multi-area networks, N can be beyond fifty).
例として、PCEsとして1つの背骨領域とN周辺地域で構成されていたマルチ領域ネットワーク、および相互領域MPLS-TE経路計算がABRsとの複数のPCE経路計算に依存するところで機能して、背骨領域は少なくともN PCEsを包括するでしょう、そして、PCCの構成は厄介過ぎるでしょう(例えば、既存のマルチ領域ネットワークでは、50を超えてNはいることができます)。
Hence, an automated PCE discovery mechanism allowing a PCC to dynamically discover a set of PCEs is highly desirable.
したがって、PCCがダイナミックにPCEsの1セットを発見できる自動化されたPCE発見メカニズムは非常に望ましいです。
2.2. Requirements Overview
2.2. 要件概観
A PCE discovery mechanism that satisfies the requirements set forth in this document MUST allow a PCC to automatically discover the location of one or more of the PCEs in its domain.
詳しく説明された要件を満たすPCE発見メカニズムで、PCCはドメインで本書では自動的にPCEsの1つ以上の位置を発見できなければなりません。
Where inter-domain path computation is required and policy permits, the PCE discovery method MUST allow a PCC to automatically discover the location of PCEs in other domains that can assist with inter- domain path computation.
相互ドメイン経路計算が必要であり、方針が可能にするところでは、PCE発見方法で、PCCは相互ドメイン経路計算を助けることができる他のドメインで自動的にPCEsの位置を発見できなければなりません。
A PCE discovery mechanism MUST allow a PCC to discover the set of one or more domains where a PCE has TE topology visibility and can compute paths. It MUST also allow the discovery of the potential inter-domain path computation functions of a PCE (inter-area, inter- AS, inter-layer, etc.).
PCE発見メカニズムで、PCCはPCEがTEトポロジー目に見えることを持って、経路を計算できる1つ以上のドメインのセットを発見できなければなりません。 また、それはPCE(相互領域、相互AS、相互層など)の潜在的相互ドメイン経路計算機能の発見を許さなければなりません。
A PCE discovery mechanism MUST allow the control of the discovery scope, that is the set of one or more domains (areas, ASs) where information related to a given PCE has to be disclosed.
PCE発見メカニズムは発見範囲のコントロールを許さなければなりません、すなわち、情報が与えられたPCEに関連した1つ以上のドメイン(領域、ASs)のセットが明らかにされなければなりません。
Le Roux Informational [Page 5] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[5ページ]のRFC4674Requirements
A PCE discovery mechanism MUST allow PCCs in a given discovery scope to dynamically discover that a new PCE has appeared or that there is a change in a PCE's information.
PCE発見メカニズムで、与えられた発見範囲のPCCsは、新しいPCEが現れたか、またはPCEの情報における変化があるとダイナミックに発見できなければなりません。
A PCE discovery mechanism MUST allow PCCs to dynamically discover that a PCE is no longer available.
PCE発見メカニズムで、PCCsは、PCEがもう利用可能でないとダイナミックに発見できなければなりません。
A PCE discovery mechanism MUST support security procedures. In particular, key consideration MUST be given in terms of how to establish a trust model for PCE discovery.
PCE発見メカニズムはセキュリティ手順を支持しなければなりません。 特に、PCE発見のためにどう信用モデルを確立するかに関して重要な考慮すべき事柄を与えなければなりません。
OPTIONALLY, a PCE discovery mechanism MAY be used so as to disclose a set of detailed PCE capabilities so that the PCC may make advanced and informed choices about which PCE to use.
OPTIONALLY、PCE発見メカニズムは、PCCがどのPCEを使用したらよいかに関する高度で知識がある選択をすることができるように1セットの詳細なPCE能力を明らかにするのに使用されるかもしれません。
3. Example of Application Scenario
3. アプリケーションシナリオに関する例
<----------------AS1--------------------> <----AS2---
Area 1 Area 0 Area 2
R1---------R3-----R5-------R6-----------R9----------R11----R13
| | | |
| | | |
R2---------R4-----R7-------R8-----------R10---------R12----R14
|
|
--
|S1|
--
<。----------------AS1--------------------><。----AS2--- 1つの領域の地域0領域2R1---------R3-----R5-------R6-----------R9----------R11----R13| | | | | | | | R2---------R4-----R7-------R8-----------R10---------R12----R14| | -- |S1| --
Figure 1
図1
Figure 1 illustrates a multi-area/AS network with several PCEs:
図1はマルチ領域/ASネットワークに数個のPCEsを入れます:
- The ABR R3 is a PCE that can take part in inter-area path
computation. It can compute paths in area 1 and area 0.
- The ABR R6 is a PCE that can take part in inter-area path
computation. It can compute paths in area 0 and area 2.
- The ASBR R9 is a PCE that can take part in inter-AS path
computation. It is responsible for path computation in AS1 towards
AS2.
- The ASBR R12 is a PCE that can take part in inter-AS path
computation. It is responsible for path computation in AS2 towards
AS1.
- The server S1 is a PCE that can be used to compute diverse paths
and backup paths in area 1.
- ABR R3は相互領域経路計算に参加できるPCEです。 それは領域1と領域0で経路を計算できます。 - ABR R6は相互領域経路計算に参加できるPCEです。 それは領域0と領域2で経路を計算できます。 - ASBR R9は相互AS経路計算に参加できるPCEです。 それはAS2に向かったAS1での経路計算に責任があります。 - ASBR R12は相互AS経路計算に参加できるPCEです。 それはAS1に向かったAS2での経路計算に責任があります。 - サーバS1はさまざまの経路を計算して、領域1で経路のバックアップをとるのに使用できるPCEです。
Le Roux Informational [Page 6] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[6ページ]のRFC4674Requirements
By meeting the requirements set out in this document, the PCE discovery mechanism will allow:
本書では出された必要条件を満たすことによって、PCE発見メカニズムは以下を許容するでしょう。
- each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for
inter-area path computation, and that R3 can compute paths in area
0 and area 1.
- each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for
inter-area path computation, and that R6 can compute paths in area
2 and area 0.
- each PCC in AS1 and one or more PCCs in AS2 to dynamically discover
R9 as a PCE for inter-AS path computation in AS1 towards AS2.
- each PCC in AS2 and one or more PCCs in AS1 to dynamically discover
R12 as a PCE for inter-AS path computation in AS2 towards AS1.
- each PCC in area 1 to dynamically discover S1, as a PCE for intra-
area path computation in area1, and optionally to discover its path
computation capabilities (diverse path computation and backup path
computation).
- 相互領域経路計算のためのPCE、およびそのR3としてダイナミックにR3を発見する1と0の領域の各PCCは領域0と領域1で経路を計算できます。 - 相互領域経路計算のためのPCE、およびそのR6としてダイナミックにR6を発見する0と2の領域の各PCCは領域2と領域0で経路を計算できます。 - AS1での相互AS経路計算のためのPCEとしてダイナミックにAS2に向かってR9を発見するAS2のAS1の各PCCと1PCCs。 - AS2での相互AS経路計算のためのPCEとしてダイナミックにAS1に向かってR12を発見するAS1のAS2の各PCCと1PCCs。 - 領域の各PCC、1 経路計算能力(さまざまの経路計算とバックアップ経路計算)を発見するためにイントラ領域経路計算のためのPCEとしてダイナミックにarea1に、任意にS1を発見するために。
4. Detailed Requirements
4. 詳細な要件
4.1. PCE Information to Be Disclosed
4.1. 明らかにされるべきPCE情報
We distinguish two levels of PCE information to be disclosed by a PCE discovery mechanism:
私たちはPCE発見メカニズムによって明らかにされるために2つのレベルのPCE情報を区別します:
- General information. Disclosure MUST be supported by the PCE
discovery mechanism.
- Detailed information. Disclosure MAY be supported by the PCE
discovery mechanism.
- 一般情報。 公開はPCE発見メカニズムで後押しされていなければなりません。 - 詳細な情報。 公開はPCE発見メカニズムで後押しされているかもしれません。
The PCE discovery mechanism MUST allow disclosure of general PCE information that will allow PCCs to select appropriate PCEs. This comprises discovery of PCE location, PCE domains supported by the PCEs, and PCE inter-domain functions.
PCE発見メカニズムはPCCsが適切なPCEsを選択できる一般的なPCE情報の公開を許さなければなりません。 これはPCE位置、PCEsによって支持されたPCEドメイン、およびPCE相互ドメイン機能の発見を包括します。
The PCE discovery mechanism MAY also allow disclosure of detailed PCE information. This comprises any or all information about PCE path computation capabilities and alternate PCEs. This information is not part of PCE discovery; this is additional information that can facilitate the selection of a PCE by a PCC. Support of the exchange of this information is optional in the context of the PCE discovery mechanism itself. This does not mean that the availability of this information is optional in the PCE-based architecture, but such information could also be obtained by other mechanisms, such as the PCC-PCE communication protocol.
また、PCE発見メカニズムは詳細なPCE情報の公開を許すかもしれません。 これはPCE経路計算能力と交互のPCEsのいずれかすべての情報を包括します。 この情報はPCE発見の一部ではありません。 これはPCCによるPCEの選択を容易にすることができる追加情報です。 この情報の交換のサポートはPCE発見メカニズム自体の文脈で任意です。 これは、この情報の有用性がPCEベースの構造で任意ですが、また、他のメカニズムでそのような情報を得ることができたことを意味しません、PCC-PCE通信プロトコルなどのように。
Le Roux Informational [Page 7] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[7ページ]のRFC4674Requirements
4.1.1. General PCE Information (Mandatory Support)
4.1.1. 一般PCE情報(義務的なサポート)
4.1.1.1. Discovery of PCE Location
4.1.1.1. PCE位置の発見
The PCE discovery mechanism MUST allow the discovery, for a given PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE. This address will typically be an address that is always reachable, if there is any connectivity to the PCE.
PCE発見メカニズムは、PCEに達するのに使用されるためにIPv4、そして/または、IPv6アドレスの与えられたPCEのための発見を許さなければなりません。 このアドレスは通常何かPCEへの接続性があればいつも届いているアドレスになるでしょう。
This address will be used by PCCs to communicate with a PCE, through a PCC-PCE communication protocol.
このアドレスは、PCC-PCE通信プロトコルを通してPCEとコミュニケートするのにPCCsによって使用されるでしょう。
4.1.1.2. Discovery of PCE Domains and Inter-domain Functions
4.1.1.2. PCEドメインと相互ドメイン機能の発見
Inter-domain path computation is a key application of the PCE-based architecture. This can rely on a multiple-PCE path computation, where PCEs in each domain compute a part of the end-to-end path and collaborate with each other to find the end-to-end-path. Inter- domain path computation can also rely on a single-PCE path computation where a PCE has visibility inside multiple domains and can compute an entire end-to-end inter-domain path (that is, a path from the inter-domain TE-LSP head-end to the inter-domain TE-LSP tail end).
相互ドメイン経路計算はPCEベースの構造の主要な応用です。 これは複数のPCE経路計算に依存できます、各ドメインのPCEsが終わりから端への経路の一部を計算して、終わりから端の経路を見つけるために互いと協力するところで。 相互ドメイン経路計算は、また、PCEが複数のドメインの中に目に見えることを持っているところで独身のPCE経路計算に依存できて、終わりから端への相互ドメイン全体の経路(すなわち、相互ドメインTE-LSPギヤエンドからの相互ドメインTE-LSP末端への経路)を計算できます。
Hence, the PCE discovery mechanism MUST allow the discovery of the set of one or more domains where a PCE has visibility and can compute paths. These domains could be identified using a domain identifier: For instance, an IGP area can be identified by the Area ID (OSPF or ISIS), and an AS can be identified by the AS number.
したがって、PCE発見メカニズムはPCEが目に見えることを持って、経路を計算できる1つ以上のドメインのセットの発見を許さなければなりません。 ドメイン識別子を使用することでこれらのドメインを特定できるでしょう: 例えば、Area ID(OSPFかイシス)はIGP領域を特定できます、そして、AS番号でASを特定できます。
Also the PCE discovery mechanism MUST allow discovery of the inter- domain functions of a PCE, i.e., whether a PCE can be used to compute or to take part in the computation of end-to-end paths across domain borders. The inter-domain functions include nonexhaustively: inter- area, inter-AS and inter-layer path computation. Note that these functions are not mutually exclusive.
また、PCE発見メカニズムはPCEの相互ドメイン機能の発見を許さなければなりません、すなわち、計算するか、またはドメイン境界の向こう側に終わりから端への経路の計算に参加するのにPCEを使用できるか否かに関係なく。 相互ドメイン機能は「非-徹底的」を含んでいます: 相互領域、相互AS、および相互層の経路計算。 これらの機能が互いに唯一でないことに注意してください。
Note that the inter-domain functions are not necessarily inferred from the set of domains where a PCE has visibility. For instance, a PCE may have visibility limited to a single domain, but may be able to take part in the computation of inter-domain paths by collaborating with PCEs in other domains. Conversely, a PCE may have visibility in multiple domains, but the operator may not want the PCE to be used for inter-domain path computations.
相互ドメイン機能が必ずPCEが目に見えることを持っているドメインのセットから推論されるというわけではないことに注意してください。 例えば、PCEは、目に見えることを単一領域に制限させますが、他のドメインでPCEsと協力することによって、相互ドメイン経路の計算に参加できるかもしれません。 逆に、PCEは複数のドメインに目に見えることを持っているかもしれませんが、オペレータは相互ドメイン経路計算にPCEを使用して欲しくないかもしれません。
The PCE discovery mechanisms MUST also allow discovery of the set of one or more domains toward which a PCE can compute paths. For instance, in an inter-AS path computation context, there may be
また、PCE発見メカニズムはPCEが経路を計算できる1つ以上のドメインのセットの発見を許さなければなりません。 例えば、相互AS経路計算文脈に、あるかもしれません。
Le Roux Informational [Page 8] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[8ページ]のRFC4674Requirements
several PCEs in an AS, each one responsible for taking part in the computation of inter-AS paths toward a set of one or more destination ASs, and a PCC may have to discover the destination ASs each PCE is responsible for.
ASの数個のPCEs、取るのに責任がある各々は1つ以上の目的地のセットに向かった相互AS経路の計算でASsを分けます、そして、PCCはそれぞれのPCEが責任がある目的地ASsを発見しなければならないかもしれません。
4.1.2. Detailed PCE Information (Optional Support)
4.1.2. 詳細なPCE情報(任意のサポート)
4.1.2.1. Discovery of PCE Capabilities
4.1.2.1. PCE能力の発見
In the case where there are several PCEs with distinct capabilities available, a PCC has to select one or more appropriate PCEs.
異なった能力が利用可能の数個のPCEsがある場合では、PCCは1適切なPCEsを選択しなければなりません。
For that purpose, the PCE discovery mechanism MAY support the disclosure of some detailed PCE capabilities.
そのために、PCE発見メカニズムはいくつかの詳細なPCE能力の公開を支持するかもしれません。
For the sake of illustration, this could include the following path- computation-related PCE capabilities:
イラストのために、これは以下の経路の計算関連のPCE能力を含むかもしれません:
- The link constraints supported: e.g., bandwidth, affinities.
- The path constraints supported: maximum IGP/TE cost, maximum hop
count.
- The objective functions supported: e.g., shortest path, widest
path.
- The capability to compute multiple correlated paths: e.g., diverse
paths, load balanced paths.
- The capability to compute bidirectional paths.
- The GMPLS-technology-specific constraints supported: e.g., the
supported interface switching capabilities, encoding types.
- 規制が支えたリンク: 例えば、帯域幅、親近感。 - 規制が支持した経路: 最大のIGP/TE費用、最大のホップカウント。 - 目的関数は支持しました: 例えば、最短パス、最も広い経路。 - 複数の関連経路を計算する能力: 例えば、さまざまの経路であり、負荷は経路のバランスをとりました。 - 双方向の経路を計算する能力。 - GMPLS技術詳細規制は支持しました: 例えば、タイプをコード化して、能力を切り換える支持されたインタフェース。
And this could also include some specific PCE capabilities:
そして、また、これはいくつかの特定のPCE能力を含むかもしれません:
- The capability to handle request prioritization.
- The maximum size of a request message.
- The maximum number of path requests in a request message.
- The PCE computation power (static parameters to be used for
weighted load balancing of requests).
- 要求優先順位づけを扱う能力。 - 要求メッセージの最大サイズ。 - 要求メッセージの経路要求の最大数。 - PCE計算パワー(要求の荷重しているロードバランシングに使用されるべき静的なパラメタ)。
Such information regarding PCE capabilities could then be used by a PCC to select an appropriate PCE from a list of candidate PCEs.
そして、PCCは、候補PCEsのリストから適切なPCEを選択するのにPCE能力のそのような情報を使用できました。
Note that the exact definition and description of PCE capabilities are out of the scope of this document. It is expected that this will be described in one or more separate documents which may be application specific.
このドキュメントの範囲の外にPCE能力の正確な定義と記述があることに注意してください。 これが1通以上のアプリケーション特有であるかもしれない別々のドキュメントで説明されると予想されます。
Le Roux Informational [Page 9] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[9ページ]のRFC4674Requirements
4.1.2.2. Discovery of Alternate PCEs
4.1.2.2. 交互のPCEsの発見
In the case of a PCE failure, a PCC has to select another PCE, if one is available. It could be useful in various situations for a PCE to indicate a set of one or more alternate PCEs that can be selected in case the given PCE fails.
PCEの故障の場合では、1つが利用可能であるなら、PCCは別のPCEを選択しなければなりません。 PCEが与えられたPCEが失敗するといけないので選択できる1交互のPCEsの1セットを示すのは、様々な状況において役に立つかもしれません。
Hence, the PCE discovery mechanism MAY allow the discovery, for a given PCE, of the location of one or more assigned alternate PCEs.
したがって、PCE発見メカニズムは発見を許すかもしれません、1の位置についてPCEを与えているか、またはさらに割り当てた交互のPCEsのために。
The PCE discovery mechanism MAY also allow the discovery, for a given PCE, of the set of one or more PCEs for which it acts as alternate PCE.
また、PCE発見メカニズムは発見を許すかもしれません、それが交互のPCEとして機能する1PCEsのセットの与えられたPCEのために。
4.2. Scope of PCE Discovery
4.2. PCE発見の範囲
The PCE discovery mechanism MUST allow control of the scope of the PCE information disclosure on a per-PCE basis. In other words, it MUST allow control of to which PCC or group of PCCs the information related to a PCE may be disclosed.
PCE発見メカニズムは1PCEあたり1個のベースにおけるPCE情報公開の範囲のコントロールを許さなければなりません。 言い換えれば、それはPCEに関連する情報がPCCsのどのPCCかグループに明らかにされるかもしれないかに関するコントロールを許さなければなりません。
The choice for the discovery scope of a given PCE MUST include at least the followings settings:
与えられたPCE MUSTの発見範囲のための選択は少なくとも従設定を含んでいます:
- All PCCs in a single IGP area.
- ただ一つのIGP領域のすべてのPCCs。
- All PCCs in a set of adjacent IGP areas.
- 隣接しているIGP領域のセットにおけるすべてのPCCs。
- All PCCs in a single AS.
- 独身のASのすべてのPCCs。
- All PCCs in a set of ASs.
- ASsの1セットにおけるすべてのPCCs。
- A set of one or more PCCs in a set of one or more ASs.
- 1ASsの1セットにおける1PCCsの1セット。
In particular, this also implies that the PCE discovery mechanism MUST allow for the discovery of PCE information across IGP areas and across AS boundaries.
また、特に、これは、PCE発見メカニズムがPCEの発見のためにIGP領域の向こう側にAS境界の向こう側に情報を許容しなければならないのを含意します。
The discovery scope MUST be configurable on a per PCE basis.
発見範囲はPCE基礎あたりのaで構成可能であるに違いありません。
It MUST be possible to deactivate PCE discovery on a per PCE basis.
PCE基礎あたりのaにPCE発見を非活性化するのは可能であるに違いありません。
4.2.1. Inter-AS Specific Requirements
4.2.1. 相互、決められた一定の要求
When using a PCE-based approach for inter-AS path computation, a PCC in one AS may need to learn information related to inter-AS capable PCEs located in other ASs. For that purpose, and as pointed out in the previous section, the PCE discovery mechanism MUST allow
相互AS経路計算のためのPCEベースのアプローチを使用するとき、1ASのPCCは、情報が他のASsに位置する相互ASのできるPCEsに関連したことを学ぶ必要があるかもしれません。 そのために、前項で指摘されるように、PCE発見メカニズムは許容されなければなりません。
Le Roux Informational [Page 10] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[10ページ]のRFC4674Requirements
disclosure of information related to inter-AS-capable PCEs across AS boundaries.
情報の公開はAS境界の向こう側にできる相互AS PCEsに関連しました。
Such inter-AS PCE discovery must be carefully controlled. For security and confidentiality reasons, particularly in an inter- provider context, the discovery mechanism MUST allow the discovery scope to be limited to a set of ASs and MUST also provide control of the PCE information to be disclosed across ASs. This is achieved by applying policies (see also Section 4.4). This implies the capability to contain a PCE advertisement to a restricted set of one or more ASs, and to filter and translate any PCE parameter (PCE domains, PCE inter-domain functions, PCE capabilities, etc.) in disclosures that cross AS borders. For the sake of illustration, it may be useful to disclose detailed PCE information (such as detailed capabilities) locally in the PCE's AS but only general information (such as location and supported domains) in other ASs.
慎重にそのような相互AS PCE発見を制御しなければなりません。 セキュリティと秘密性理由と、特に相互プロバイダー文脈に、発見メカニズムは、発見範囲がASsの1セットに制限されるのを許容しなければならなくて、また、ASsの向こう側に明らかにされるためにPCE情報のコントロールを前提としなければなりません。 これは、方針を適用することによって、達成されます(また、セクション4.4を見てください)。 これがいずれも1ASsの制限されたセットにPCE広告を含んで、フィルターにかけて、翻訳する能力を含意する、PCEパラメタ、(PCEドメイン、PCE相互ドメイン機能、PCE能力など) (公開におけるその交差しているAS境界)。 イラストのために、他のASsのPCEのASにもかかわらず、一般情報(位置や支持されたドメインなどの)だけで局所的に、詳細なPCE情報(詳細な能力などの)を明らかにするのは役に立つかもしれません。
4.3. PCE Information Synchronization
4.3. PCE情報同期
The PCE discovery mechanism MUST allow a PCC to discover any change in the information related to a PCE that it has previously discovered. This includes changes to both general information (e.g., a change in the PCE domains supported) and detailed information if supported (e.g., a modification of the PCE's capabilities).
PCE発見メカニズムで、PCCはそれが以前に発見したPCEに関連する情報におけるどんな変化も発見できなければなりません。 支持されるなら(例えば、PCEの能力の変更)、これは一般情報(例えば、ドメインが支持したPCEにおける変化)と詳細な情報の両方への変化を含んでいます。
In addition, the PCE discovery mechanism MUST allow dynamic discovery of new PCEs in a given discovery scope.
さらに、PCE発見メカニズムは与えられた発見範囲での新しいPCEsのダイナミックな発見を許さなければなりません。
Note that there is no requirement for real-time detection of these changes; the PCE discovery mechanism SHOULD rather allow discovery of these changes in a range of 60 seconds, and the operator should have the ability to configure the discovery delay.
これらの変化のリアルタイムの検出のための要件が全くないことに注意してください。 PCE発見メカニズムSHOULDは60秒の範囲でむしろこれらの変化の発見を許します、そして、オペレータには、発見遅れを構成する能力があるべきです。
Note that PCE information is relatively static and is expected to be fairly stable and not to change frequently.
PCE情報が比較的静的であり、かなり安定していて、頻繁に変化しないと予想されることに注意してください。
4.4. Discovery of PCE Deactivation
4.4. PCE非活性化の発見
The PCE discovery mechanism MUST allow a PCC to discover when a PCE that it has previously discovered is no longer alive or is deactivated. This may help in reducing or avoiding path computation service disruption.
PCE発見メカニズムで、PCCは、それが以前に発見したPCEがいつもう生きていないか、または非活性化されるかを発見できなければなりません。 これは、経路計算サービスの崩壊を抑えるか、または避けるのを手伝うかもしれません。
Note that there is no requirement for real-time detection of PCE failure/deactivation; the PCE discovery mechanism SHOULD rather allow such discovery in a range of 60 seconds, and the operator should have the ability to configure the discovery delay.
PCE失敗/非活性化のリアルタイムの検出のための要件が全くないことに注意してください。 PCE発見メカニズムSHOULDは60秒の範囲でむしろそのような発見を許します、そして、オペレータには、発見遅れを構成する能力があるべきです。
Le Roux Informational [Page 11] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[11ページ]のRFC4674Requirements
4.5. Policy Support
4.5. 方針サポート
The PCE discovery mechanism MUST allow for policies to restrict the discovery scope to a set of authorized domains, to control and restrict the type and nature of the information to be disclosed, and also to filter and translate some information at domains borders. It MUST be possible to apply these policies on a per-PCE basis.
PCE発見メカニズムは、方針が発見範囲を1セットの認可されたドメイン、コントロールに制限して、また、ドメイン境界の何らかの情報を明らかにされて、フィルターにかけて、翻訳するために情報のタイプと本質を制限するのを許容しなければなりません。 1PCEあたり1個のベースにこれらの方針を適用するのは可能であるに違いありません。
Note that the discovery mechanisms MUST allow disclosing policy information so as to control the disclosure policies at domain boundaries.
ドメイン境界で公開方針を制御するために発見メカニズムで方針情報を明らかにしなければならないことに注意してください。
Also, it MUST be possible to apply different policies when disclosing PCE information to different domains.
また、異なったドメインにPCE情報を明らかにするとき、異なった方針を適用するのも可能であるに違いありません。
4.6. Security Requirements
4.6. セキュリティ要件
The five major threats related to PCE discovery mechanisms are
メカニズムがあるというPCE発見に関連する5つの大きな脅威
- impersonation of PCE; - interception of PCE discovery information (sniffing); - falsification of PCE discovery information; - information disclosure to non-authorized PCCs (PCC spoofing); - Denial of Service (DoS) Attacks.
- PCEのものまね。 - PCE発見情報(かぐ)の妨害。 - PCE発見情報の改竄。 - 非認可されたPCCs(PCCスプーフィング)への情報公開。 - サービス妨害(DoS)は攻撃されます。
Note that security of the PCE discovery procedures is of particular importance in an inter-AS context, where PCE discovery may increase the vulnerability to attacks and the consequences of these attacks.
PCE発見手順のセキュリティが相互AS文脈で特別に重要であることに注意してください。(そこでは、PCE発見が攻撃とこれらの攻撃の結果に脆弱性を増加させるかもしれません)。
Hence, mechanisms MUST be defined to ensure authenticity, integrity, confidentiality, and containment of PCE discovery information:
したがって、PCE発見情報の信憑性、保全、秘密性、および封じ込めを確実にするためにメカニズムを定義しなければなりません:
- There MUST be a mechanism to authenticate discovery information.
- There MUST be a mechanism to verify discovery information
integrity.
- There MUST be a mechanism to encrypt discovery information.
- There MUST be a mechanism to restrict the scope of discovery to a
set of authorized PCCs and to filter PCE information disclosed at
domain boundaries (as per defined in Section 4.5).
- 発見情報を認証するメカニズムがあるに違いありません。 - 発見情報保全について確かめるメカニズムがあるに違いありません。 - 発見情報をコード化するメカニズムがあるに違いありません。 - 発見の範囲を認可されたPCCsの1セットに制限して、ドメイン境界(セクション4.5で定義にされるに従って)で明らかにされたPCE情報をフィルターにかけるメカニズムがあるに違いありません。
A PCE and PCC MUST be identified by a globally unique ID, which may be, for instance, a combination of AS number and IP address.
PCEとPCC MUST、グローバルにユニークなIDによって特定されてください。(例えば、それは、AS番号とIPアドレスの組み合わせであるかもしれません)。
Mechanisms MUST be defined in order to limit the impact of a DoS attack on the PCE discovery procedure (e.g., filter out excessive PCE information change and flapping PCEs). Note also that DoS attacks may be either accidental (caused by a misbehaving PCE system) or intentional. As discussed in [RFC4657], such mechanisms may include
PCE発見手順に対するDoS攻撃の影響を制限するためにメカニズムを定義しなければなりません(例えば、過度のPCE情報変化とばたついているPCEsを無視してください)。 また、DoS攻撃が偶然的であるか(ふらちな事をしているPCEシステムで、引き起こされます)、または意図的であるかもしれないことに注意してください。 [RFC4657]で議論するように、そのようなメカニズムは包含するかもしれません。
Le Roux Informational [Page 12] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[12ページ]のRFC4674Requirements
packet filtering, rate limiting, no promiscuous listening, and where applicable use of private addresses spaces.
パケットがフィルターにかけられて、制限、無差別な聴取がなく、およびどこがプライベート・アドレス空間の適切な使用であるかと評定してください。
Also, key consideration MUST be given in terms of how to establish a trust model for PCE discovery. The PCE discovery mechanism MUST explicitly support a specific set of one or more trust models.
また、PCE発見のためにどう信用モデルを確立するかに関して重要な考慮すべき事柄を与えなければなりません。 PCE発見メカニズムは明らかに1つ以上の信用モデルの特定のセットを支えなければなりません。
4.7. Extensibility
4.7. 伸展性
The PCE discovery mechanism MUST be flexible and extensible so as to easily allow for the inclusion of additional PCE information that could be defined in the future.
PCE発見メカニズムは、容易に将来定義できた追加PCE情報の包含を考慮するためにフレキシブルであって、広げることができなければなりません。
4.8. Scalability
4.8. スケーラビリティ
The PCE discovery mechanism MUST be designed to scale well with an increase of any of the following parameters:
以下のパラメタのどれかの増加でよく比例するようにPCE発見メカニズムを設計しなければなりません:
- Number of PCCs discovering a given PCE. - Number of PCEs to be discovered by a given PCC. - Number of domains in the discovery scope.
- 与えられたPCEを発見するPCCsの数。 - 与えられたPCCによって発見されるべきPCEsの数。 - 発見範囲のドメインの数。
The PCE discovery mechanism MUST NOT have an adverse effect in the performance of other protocols (especially routing and signaling) already operating in the network.
PCE発見メカニズムは、ネットワークで既に作動しながら、他のプロトコル(特にルーティングとシグナリング)の性能に悪影響を及ぼしてはいけません。
Note that there is no scalability requirement with regards to the amount of information to be exchanged.
交換するために情報量への尊敬があるスケーラビリティ要件が全くないことに注意してください。
Information disclosed in the PCE discovery mechanism is relatively static. Changes in PCE information may occur as a result of PCE configuration updates, PCE deployment/activation, or PCE deactivation/suppression, and should not occur as a result of the PCE activity itself. Hence, this information is quite stable and will not change frequently.
PCE発見メカニズムで明らかにされた情報は比較的静的です。 PCE情報における変化は、PCE構成アップデート、PCE展開/起動、またはPCE非活性化/抑圧の結果、起こるかもしれなくて、PCE活動自体の結果、起こるはずがありません。 したがって、この情報は、かなり安定していて、頻繁に変化しないでしょう。
4.9. Operational Orders of Magnitudes
4.9. 大きさの操作上の注文
This section gives minimum order of magnitude estimates of what the PCE discovery mechanism should support.
このセクションはPCE発見メカニズムが支持するはずであることに関する大きさ見積りに関する最低発注量を与えます。
- Number of PCCs discovering a given PCE: 1000 - Number of PCEs to be discovered by a given PCC: 100
- 与えられたPCEを発見するPCCsの数: 1000--与えられたPCCによって発見されるべきPCEsの数: 100
Le Roux Informational [Page 13] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[13ページ]のRFC4674Requirements
4.10. Manageability Considerations
4.10. 管理可能性問題
Mechanisms are REQUIRED to manage PCE discovery operations. This includes the configuration of PCE discovery functions and policies, as well as the monitoring of the discovery protocol activity.
メカニズムはPCE発見操作を管理するREQUIREDです。 これはPCE発見機能と方針の構成、および発見プロトコル活動のモニターを含んでいます。
4.10.1. Configuration of PCE Discovery Parameters
4.10.1. PCE発見パラメタの構成
It MUST be possible to enable and disable the PCE discovery function at a PCC and at a PCE.
PCCにおいてPCEでPCE発見機能を可能にして、無効にするのは可能であるに違いありません。
On the PCC, it MUST be possible for an operator to activate/deactivate automatic PCE discovery. The activation of automatic discovery MUST not prevent static configuration of PCE information that may supplement discovered information.
PCCでは、オペレータが自動PCE発見を起動するか、または非活性化するのが、可能であるに違いありません。 自動発見の起動は発見された情報を補うかもしれないPCE情報の静的な構成を防いではいけません。
On the PCE, it MUST be possible for an operator to control the application of discovery policies by which the specific PCE is discovered. As described in Section 4.5, this control MUST include the ability to
PCEでは、オペレータが特定のPCEが発見される発見方針の適用を制御するのは、可能であるに違いありません。 中では、4.5に、このコントロールが能力を含まなければならないセクションについて説明します。
- restrict the discovery scope to a set of authorized domains;
- define the type and nature of the information disclosed;
- specify the filtering and translation to be applied to the PCE
information disclosed at domain borders.
- 発見範囲を1セットの認可されたドメインに制限してください。 - 明らかにされた情報のタイプと本質を定義してください。 - フィルタリングと翻訳を指定して、ドメイン境界で明らかにされたPCE情報に適用されてください。
These configuration options MAY be supported through an implementation-specific local configuration interface, or MAY be supported via a standardised interface (such as a MIB module, as below).
これらの設定オプションは、実現特有の地方の構成インタフェースを通してサポートされるか、または標準化されたインタフェース(下としてのMIBモジュールなどの)を通してサポートされるかもしれません。
4.10.2. PCE Discovery MIB Modules
4.10.2. PCE発見MIBモジュール
PCE discovery MIB modules MUST be specified for the control of the function on PCCs and PCEs.
PCCsとPCEsにおける機能のコントロールにPCE発見MIBモジュールを指定しなければなりません。
4.10.2.1. PCC MIB Module
4.10.2.1. PCC MIBモジュール
The MIB module that will run on PCCs MUST include at least the following:
PCCsの上で作業するMIBモジュールは少なくとも以下を含まなければなりません:
- A control to disable automatic discovery by the PCC, - The set of known PCEs, - The number of known PCEs, and the number of discovered PCEs.
- PCC--知られているPCEsのセット--知られているPCEsの数、および発見されたPCEsの数に従って自動発見を無効にするコントロール。
For each PCE reported in the MIB module, the following information MUST be available:
MIBモジュールで報告された各PCEに、以下の情報は利用可能であるに違いありません:
Le Roux Informational [Page 14] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[14ページ]のRFC4674Requirements
- Information advertised by the PCE (i.e., discovered information),
- Information locally configured about the PCE,
- The time since the PCE was discovered,
- The time since any change to the discovered information for the
PCE.
- PCE以来PCE(すなわち、情報を発見する)--PCEの周りで局所的に構成された情報--時間までに広告に掲載された情報は発見されました--PCEのための発見された情報へのどんな変化以来の時間。
Note that when a PCE is no longer alive (see Section 4.4), it SHOULD no longer be reported in the PCC MIB module.
PCEがもう生きていなくて(セクション4.4を見てください)、それがSHOULDであるそれがもうPCC MIBモジュールで報告されないことに注意してください。
The MIB module SHOULD also provide the average and maximum rates of arrival, departure, and modification of PCE discovery to enable effective analysis of the operation of the protocols. Furthermore, the MIB module SHOULD report on the operation of the discovery protocol by counting the number of unacceptable and incomprehensible information exchanges.
また、MIBモジュールSHOULDは、プロトコルの操作の有効な分析を可能にするためにPCE発見の到着、出発、および変更の平均して最大の速度を提供します。 その上、MIBモジュールSHOULDは、発見プロトコルの操作に関して容認できなくて不可解な情報交換の数を数えることによって、報告します。
The PCC MIB module SHOULD also be used to provide notifications when thresholds (e.g., on the maximum rate of change, on the number of unacceptable messages) are crossed, or when important events occur (e.g., the number of discovered PCEs decreases to zero).
PCC MIBモジュールSHOULD、また、敷居(例えば、最大の増減率、容認できないメッセージの数の上の)が交差しているか、または重大事件が起こる(例えば発見されたPCEsの数はゼロまで減少します)ときには使用されて、通知を提供してください。
4.10.2.2. PCE MIB module
4.10.2.2. PCE MIBモジュール
The MIB module that will run on PCEs MUST include at least
少なくとも意志の走られたPCEsが含まなければならないMIBモジュール
- a control to disable automatic discovery announcements by the PCE;
- information to be advertised by the PCE, although this information
MAY be present as read-only;
- the discovery policies active on the PCE, although this information
MAY be present as read-only.
- PCEによる自動発見発表を無効にするコントロール。 - この情報は書き込み禁止として存在しているかもしれませんが、PCEによって広告を出されるべき情報 - この情報は書き込み禁止として存在しているかもしれませんが、PCEでアクティブな発見方針。
The MIB module SHOULD also include
またSHOULDが含むMIBモジュール
- the time since the last change to the advertised PCE information;
- the time since the last change to the advertisement policies;
- control of on which interfaces the PCE issues advertisements where
this is applicable to the protocol solution selected.
- 広告を出しているPCE情報への最後の変化以来の時間。 - 広告方針への最後の変化以来の時間。 - これが解決策が選択したプロトコルに適切であるところでPCEがどのインタフェースで広告を発行するかに関するコントロール。
Note that a PCE MAY also be configured to discover other PCEs. In this case, it SHOULD operate the MIB module described in Section 4.10.2.1 as well as the module described here.
また、PCE MAYが他のPCEsを発見するために構成されることに注意してください。 この場合それ、SHOULDはモジュールと同様に.1がここで説明したセクション4.10.2で説明されたMIBモジュールを操作します。
4.10.3. Monitoring Protocol Operations
4.10.3. モニターしているプロトコル操作
It MUST be possible to monitor the operation of any PCE discovery protocol. Where an existing protocol is used to support the PCE discovery function, this monitoring SHOULD be achieved using the techniques already defined for that protocol, enhanced by the MIB
どんなPCE発見プロトコルの操作もモニターするのは可能であるに違いありません。 既存のプロトコルが使用されているところでは、PCE発見機能、このモニターしているSHOULDを支持するために、MIBによって高められたそのプロトコルのために既に定義されたテクニックを使用することで達成されてください。
Le Roux Informational [Page 15] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[15ページ]のRFC4674Requirements
modules described above. Where those techniques are inadequate, new techniques MUST be developed.
上で説明されたモジュール。 それらのテクニックが不十分であるところでは、新しいやり方を見いださなければなりません。
Monitoring of the protocol operation demands support for at least the following functions:
プロトコル操作のモニターは少なくとも以下の機能のサポートを要求します:
- Correlation of information advertised against information received.
- Counts of dropped, corrupt, and rejected information elements.
- Detection of 'segmented' networks, that is, the ability to detect
and diagnose the failure of a PCE advertisement to reach a PCC.
- 情報に対して広告に掲載された情報の相関関係は受信されました。 - 低下して、不正で、拒絶された情報要素のカウント。 - '区分された'ネットワーク(すなわち、PCE広告がPCCに達しないことを検出して、診断する能力)の検出。
4.10.4. Impact on Network Operations
4.10.4. ネットワークオペレーションで影響を与えてください。
Frequent changes in PCE information may have a significant impact on PCCs that receive the advertisements, might destabilize the operation of the network by causing the PCCs to swap between PCEs, and might harm the network through excessive advertisement traffic. Hence, it MUST be possible to apply at least the following controls:
PCE情報における頻繁な変化は、広告を受け取るPCCsで重要な影響を与えて、PCCsがPCEsの間でスワップすることを引き起こすことによってネットワークの操作を動揺させて、過度の広告交通でネットワークに害を及ぼすかもしれません。 したがって、少なくとも以下のコントロールを適用するのは可能であるに違いありません:
- Configurable limit on the rate of announcement of changed
parameters at a PCE.
- Control of the impact on PCCs such as through discovery messages
rate-limiting.
- Configurable control of triggers that cause a PCC to swap to
another PCE.
- PCEの変えられたパラメタの発表の速度における構成可能な限界。 - 発見メッセージレート制限などのPCCsにおける衝撃のコントロール。 - PCCが別のPCEにスワップする引き金の構成可能なコントロール。
5. Security Considerations
5. セキュリティ問題
This document is a requirement document and hence does not raise by itself any particular security issue.
このドキュメント自体は、要件ドキュメントであり、したがって、少しの特定の安全保障問題も提起しません。
A set of security requirements that MUST be addressed when considering the design and deployment of a PCE discovery mechanism has been identified in Section 4.6.
デザインを考えるとき記述しなければならない1セットのセキュリティ要件とPCE発見メカニズムの展開はセクション4.6で特定されました。
6. Acknowledgements
6. 承認
We would like to thank, in chronological order, Benoit Fondeviole, Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil Bitar, and Kenji Kumaki.
感謝申し上げます、年代順、ブノワFondeviole、トーマス・モーリン、エイミール・シュテファン、ジャンフィリップVasseur、ディーン・チェン、エードリアン・ファレル、Renhaiチャン、モハメドBoucadair、エリック・グレー、イーゴリBryskin、ディミトリPapadimitriou、Arthi Ayyangar、アンドリューDolganow、ルウ・バーガー、Nabil Bitar、およびKenji Kumakiで。
Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley and Sam Hartman for their review and constructive discussions during the final stages of publication.
また、彼らのレビューと建設的な討議を公表の最終段階の間、ロスCallon、テッド・ハーディー、ダンRomascanu、ラスHousley、およびサム・ハートマンをありがとうございます。
Le Roux Informational [Page 16] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[16ページ]のRFC4674Requirements
7. Contributors
7. 貢献者
The following are the authors who contributed to the present document:
↓これは現在のドキュメントに貢献した作者です:
Jean-Louis Le Roux (France Telecom) Paul Mabey (Qwest Communications) Eiji Oki (NTT) Richard Rabbat (Fujitsu) Ting Wo Chung (Bell Canada) Raymond Zhang (BT Infonet)
ジャン・ルイル・ルー(フランステレコム)ポールMabey(クエストコミュニケーションズ)Eiji Oki(NTT)リチャードRabbat(富士通)チリンチリンWoチャン(ベル・カナダ)・レイモンド・チャン(BT Infonet)
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4655] ファレル、A.、Vasseur、J.-P.、およびJ.灰、「経路の計算の要素の(PCE)ベースの構造」、RFC4655、2006年8月。
8.2. Informative References
8.2. 有益な参照
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC4657]灰、J.、エドJ.L.ル・ルー(エド)、「経路計算要素(PCE)通信プロトコルジェネリック要件」、RFC4657(2006年9月)
Contributors' Addresses
貢献者のアドレス
Paul Mabey Qwest Communications 950 17th Street Denver, CO 80202 USA
第17ポールMabeyクエストコミュニケーションズ950通りCO80202デンバー(米国)
EMail: pmabey@qwest.com
メール: pmabey@qwest.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585 JAPAN
美土里町の3 9-11テロのEiji Oki NTT武蔵野市、日本東京180-8585
EMail: oki.eiji@lab.ntt.co.jp
メール: oki.eiji@lab.ntt.co.jp
Le Roux Informational [Page 17] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[17ページ]のRFC4674Requirements
Richard Rabbat Fujitsu Laboratories of America 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 USA
1240の東Arques Ave、アメリカサニーベル、MS345カリフォルニア94085米国のリチャードRabbat富士通研究所
EMail: richard@us.fujitsu.com
メール: richard@us.fujitsu.com
Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, M5J 2T3 CANADA
Wo青ベル・カナダ181カナダ金融界、トロント、オンタリオ、スイート350M5J 2T3カナダをチリンチリンと鳴らしてください。
EMail: ting_wo.chung@bell.ca
メール: ting_wo.chung@bell.ca
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンドチャンBT Infonet2160のE.の壮大なAve。 エルセガンド、カリフォルニア90025米国
EMail: raymond_zhang@infonet.com
メール: raymond_zhang@infonet.com
Editor's Address
エディタのアドレス
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE
大通りピアー-Marzin22307Lannion Cedexフランスのジャン・ルイル・ルー(エディタ)フランステレコム2
EMail: jeanlouis.leroux@orange-ft.com
メール: jeanlouis.leroux@orange-ft.com
Le Roux Informational [Page 18] RFC 4674 Requirements for PCE Discovery October 2006
PCE発見2006年10月のためのル・ルー情報[18ページ]のRFC4674Requirements
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)によって提供されます。
Le Roux Informational [Page 19]
ル・ルーInformationalです。[19ページ]
一覧
スポンサーリンク
