RFC3654 日本語訳
3654 Requirements for Separation of IP Control and Forwarding. H.Khosravi, Ed., T. Anderson, Ed.. November 2003. (Format: TXT=40418 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Khosravi, Ed.
Request for Comments: 3654 T. Anderson, Ed.
Category: Informational Intel
November 2003
ワーキンググループH.Khosravi、エドをネットワークでつないでください。コメントのために以下を要求してください。 3654 エドT.アンダーソン、カテゴリ: 情報のインテル2003年11月
Requirements for Separation of IP Control and Forwarding
IPコントロールと推進の分離のための要件
Status of this Memo
この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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.
このドキュメントは、ForwardingとControl Element Separation(ForCES)アーキテクチャを紹介して、1セットの関連用語を定義します。 また、このドキュメントはIP(IPv4、IPv6など)ネットワークデバイスの飛行機を進めながらコントロールとデータを論理的に切り離すという1セットの建築モデル、およびプロトコル要件を定義します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural Requirements. . . . . . . . . . . . . . . . . . 5
5. FE Model Requirements . . . . . . . . . . . . . . . . . . . . 7
5.1. Types of Logical Functions. . . . . . . . . . . . . . . 8
5.2. Variations of Logical Functions . . . . . . . . . . . . 8
5.3. Ordering of Logical Functions . . . . . . . . . . . . . 8
5.4. Flexibility . . . . . . . . . . . . . . . . . . . . . . 8
5.5 Minimal Set of Logical Functions. . . . . . . . . . . . 9
6. ForCES Protocol Requirements. . . . . . . . . . . . . . . . . 10
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References. . . . . . . . . . . . . . . . . . 14
7.2. Informative References. . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Authors' Addresses & Acknowledgments. . . . . . . . . . . . . 15
10. Editors' Contact Information. . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 定義. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 アーキテクチャ。 . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 建築要件。 . . . . . . . . . . . . . . . . . 5 5. FEは要件. . . . . . . . . . . . . . . . . . . . 7 5.1をモデル化します。 論理関数のタイプ。 . . . . . . . . . . . . . . 8 5.2. 論理関数. . . . . . . . . . . . 8 5.3の変化。 論理関数. . . . . . . . . . . . . 8 5.4を注文します。 柔軟性. . . . . . . . . . . . . . . . . . . . . . 8 5.5極小集合の論理関数。 . . . . . . . . . . . 9 6. 力は要件について議定書の中で述べます。 . . . . . . . . . . . . . . . . 10 7. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. 引用規格。 . . . . . . . . . . . . . . . . . 14 7.2. 有益な参照。 . . . . . . . . . . . . . . . . 15 8. セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 9。 作者のアドレスと承認。 . . . . . . . . . . . . 15 10. エディタの問い合わせ先。 . . . . . . . . . . . . . . . . 17 11. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 18
Khosravi & Anderson Informational [Page 1] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[1ページ]のRFC3654力要件2003年11月
1. Introduction
1. 序論
An IP network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as a routing or IP switching) and yet appear as a normal integrated network element to external entities. Two primary types of network element components exist: control-plane components and forwarding- plane components. In general, forwarding-plane components are ASIC, network-processor, or general-purpose processor-based devices that handle all data path operations. Conversely, control-plane components are typically based on general-purpose processors that provide control functionality such as the processing of routing or signaling protocols. A standard set of mechanisms for connecting these components provides increased scalability and allows the control and forwarding planes to evolve independently, thus promoting faster innovation.
IPネットワーク要素は協力する、与えられた機能性(ルーティングかIPの切り換えなどの)を提供しますが、標準の統合ネットワーク要素として外部実体に見える多数の論理的に別々の実体で構成されます。 2つのプライマリタイプのネットワーク要素成分は存在しています: 制御飛行機の部品と推進飛行機の部品。 一般に、推進飛行機の部品は、ASIC、ネットワークプロセッサ、またはすべてのデータ経路操作を扱う汎用プロセッサベースのデバイスです。 逆に、制御飛行機の部品は、ルーティングの処理などのコントロールの機能性を提供するメインプロセッサに通常基づいているか、またはプロトコルを示しています。 これらのコンポーネントを接続するのが提供されるので、メカニズムの標準セットは、コントロールと推進飛行機が独自に発展するのをスケーラビリティを増強して、許容します、その結果、より速い革新を促進します。
For the purpose of illustration, let us consider the architecture of a router to illustrate the concept of separate control and forwarding planes. The architecture of a router is composed of two main parts. These components, while inter-related, perform functions that are largely independent of each other. At the bottom is the forwarding path that operates in the data-forwarding plane and is responsible for per-packet processing and forwarding. Above the forwarding plane is the network operating system that is responsible for operations in the control plane. In the case of a router or switch, the network operating system runs routing, signaling and control protocols (e.g., RIP, OSPF and RSVP) and dictates the forwarding behavior by manipulating forwarding tables, per-flow QoS tables and access control lists. Typically, the architecture of these devices combines all of this functionality into a single functional whole with respect to external entities.
イラストの目的のために、ルータのアーキテクチャが別々のコントロールと推進飛行機の概念を例証すると考えましょう。 ルータのアーキテクチャは2つの主部で構成されます。 これらのコンポーネントは相互関連している間、互いから主に独立している機能を実行します。 下部に、データを転送する飛行機で運転している、1パケットあたりの処理と推進に原因となる推進経路があります。 上では、推進飛行機が制御飛行機での操作に原因となるネットワークOSです。 ルータかスイッチの場合では、ネットワークOSは、ルーティング、シグナリング、および制御プロトコル(例えば、リップ、OSPF、およびRSVP)を実行して、推進テーブル、1流れあたりのQoSテーブル、およびアクセスコントロールリストを操作することによって、推進の振舞いを書き取ります。 通常、これらのデバイスのアーキテクチャは外部実体に関してこの機能性のすべてをただ一つの機能的な全体に結合します。
2. Definitions
2. 定義
Addressable Entity (AE) - A physical device that is directly addressable given some interconnect technology. For example, on IP networks, it is a device to which we can communicate using an IP address; and on a switch fabric, it is a device to which we can communicate using a switch fabric port number.
アドレス可能なEntity(AE)--何らかの内部連絡技術を考えて、直接アドレス可能なフィジカル・デバイス。 例えば、IPネットワークでは、それは私たちがIPアドレスを使用することで伝えることができるデバイスです。 そして、それはスイッチ骨組みの上では、私たちがスイッチ骨組みのポートナンバーを使用することで伝えることができるデバイスです。
Physical Forwarding Element (PFE) - An AE that includes hardware used to provide per-packet processing and handling. This hardware may consist of (but is not limited to) network processors, ASIC's, line cards with multiple chips or stand alone box with general-purpose processors.
物理的なForwarding Element(PFE)--ハードウェアを含んでいるAEは以前はよく1パケットあたりの処理と取り扱いを提供していました。 しかし、このハードウェアが成るかもしれない、(制限されない、)、ネットワークプロセッサ(ASICのもの)はメインプロセッサで複数のチップかスタンドアロン箱でカードを裏打ちします。
Khosravi & Anderson Informational [Page 2] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[2ページ]のRFC3654力要件2003年11月
Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality. This hardware typically includes a general-purpose processor.
物理的なControl Element(PCE)--ハードウェアを含んでいるAEは以前はよくコントロールの機能性を提供していました。 このハードウェアはメインプロセッサを通常含んでいます。
Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by a CE via the ForCES protocol. FEs may happen to be a single blade(or PFE), a partition of a PFE or multiple PFEs.
推進Element(FE)--ForCESプロトコルを実装する論理的な実体。 FEsは、ForCESプロトコルでCEによる指示されるか制御されるとしての1パケットあたりの処理と取り扱いを提供するのに基盤となるハードウェアを使用します。 FEsはただ一つのブレード(または、PFE)、たまたまPFEか複数のPFEsのパーティションであるかもしれません。
Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs how to process packets. CEs handle functionality such as the execution of control and signaling protocols. CEs may consist of PCE partitions or whole PCEs.
Element(CE)を制御してください--ForCESプロトコルを実装して、パケットを処理する方法を1FEsに命令するのにそれを使用する論理的な実体。 CEsはコントロールとシグナリングプロトコルの実行などの機能性を扱います。 CEsはPCEパーティションか全体のPCEsから成るかもしれません。
Pre-association Phase - The period of time during which a FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. Any partitioning of PFEs and PCEs occurs during this phase.
プレ協会Phase--FEマネージャ(以下を見る)とCEマネージャ(以下を見る)がどのFEとCEを決定している期間は同じネットワーク要素の一部であるべきです。 PFEsとPCEsのどんな仕切りもこの段階の間、起こります。
Post-association Phase - The period of time during which a FE does know which CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another.
ポスト協会Phase--FEがどのCEを知っている期間は逆もまた同様にそれを制御することになっています、CEとFEがお互いとのコミュニケーションを確立している時間を含んでいて。
ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" refers only to the ForCES post-association phase protocol (see below).
ForCESプロトコル--総合的なForCESアーキテクチャの中で使用された複数のプロトコルがあるかもしれませんが、「ForCESプロトコル」という用語はForCESポスト協会フェーズプロトコルだけを示します(以下を見てください)。
ForCES Post-Association Phase Protocol - The protocol used for post- association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. This protocol could be a single protocol or could consist of multiple protocols working together.
ForCESポスト-協会Phaseプロトコル--CEsとFEsとのポスト協会フェーズコミュニケーションに使用されるプロトコル。 このプロトコルはCEからCEへのコミュニケーション、FEからFEへのコミュニケーション、または、FEとCEマネージャとのコミュニケーションに適用されません。 ForCESプロトコルはFEsが奴隷であり、CEsがマスターであるマスター奴隷プロトコルです。 このプロトコルは通信チャネル(例えば、コネクション確立、鼓動)の管理とコントロールメッセージの両方自体を含んでいます。 このプロトコルは、ただ一つのプロトコルであるかもしれないか一緒に働いている複数のプロトコルから成ることができました。
FE Model - A model that describes the logical processing functions of a FE.
FE Model--FEの論理的な処理機能について説明するモデル。
FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) a FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre-association
FEマネージャ--プレ協会フェーズで運転している、どのCE(s)にFEを決定するかに原因となる論理的な実体は交信するべきです。 このプロセスは、CE発見と呼ばれて、利用可能なCEsの能力を学ぶFEマネージャを伴うかもしれません。 FEマネージャは静的な構成からプレ協会までの何でも使用するかもしれません。
Khosravi & Anderson Informational [Page 3] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[3ページ]のRFC3654力要件2003年11月
phase protocol (see below) to determine which CE to use. However, this pre-association phase protocol is currently out of scope. Being a logical entity, a FE manager might be physically combined with any of the other logical entities mentioned in this section.
プロトコル(以下を見る)の位相を合わせて、どのCEを使用したらよいか決定してください。 しかしながら、範囲の外にこのプレ協会フェーズプロトコルは現在、あります。 論理的な実体であり、FEマネージャは物理的にこのセクションで言及される他の論理的な実体のいずれにも結合されるかもしれません。
CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which FE to use. Again, this pre-association phase protocol is currently out of scope. Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section.
CEマネージャ--プレ協会フェーズで運転している、どのFE(s)にCEを決定するかに原因となる論理的な実体は交信するべきです。 このプロセスは、FE発見と呼ばれて、利用可能なFEsの能力を学ぶCEマネージャを伴うかもしれません。 CEマネージャは、どのFEを使用したらよいかを決定するのに静的な構成からプレ協会フェーズプロトコル(以下を見る)までの何でも使用するかもしれません。 一方、範囲の外にこのプレ協会フェーズプロトコルは現在、あります。 論理的な実体であり、CEマネージャは物理的にこのセクションで言及される他の論理的な実体のいずれにも結合されるかもしれません。
Pre-association Phase Protocol - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) what is used within the ForCES protocol (see Section 6, requirement #1). However, the two capability discovery mechanisms may utilize the same FE model (see Section 5). Pre-association phase protocols are not discussed further in this document.
プレ協会Phaseプロトコル--FEマネージャとCEマネージャの間のどのCEsかFEsを使用したらよいかを決定するのに使用されるプロトコル。 プレ協会フェーズプロトコルはCE、そして/または、FE能力発見メカニズムを含むかもしれません。 そして、この能力発見プロセスが完全に別々である注意、(取り替えない、)、ForCESの中で使用されることは議定書を作ります(セクション6、要件#1を見てください)。 しかしながら、2つの能力発見メカニズムが同じFEモデルを利用するかもしれません(セクション5を見てください)。 さらに本書ではプレ協会フェーズプロトコルについて議論しません。
ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside a NE, the NE represents a single point of management. Similarly, a NE usually hides its internal organization from external entities.
ForCES Network Element(NE)--実体は1CEsと1FEsで構成されました。 NEの外の実体に、NEは1ポイントの管理を代表します。 同様に、通常、NEは内部の組織を外部実体から隠します。
ForCES Protocol Element - A FE or CE.
力は要素について議定書の中で述べます--FEかCe。
High Touch Capability - This term will be used to apply to the capabilities found in some forwarders to take action on the contents or headers of a packet based on content other than what is found in the IP header. Examples of these capabilities include NAT-PT, firewall, and L7 content recognition.
高いTouch Capability--今期は、IPヘッダーで見つけられるものを除いた内容に基づくパケットのコンテンツかヘッダーを実行するのに何人かの混載業者で見つけられた能力に申し込むのに使用されるでしょう。 これらの能力に関する例は太平洋標準時のNAT、ファイアウォール、およびL7の満足している認識を含んでいます。
3. Architecture
3. アーキテクチャ
The chief components of a NE architecture are the CE, the FE, and the interconnect protocol. The CE is responsible for operations such as signaling and control protocol processing and the implementation of management protocols. Based on the information acquired through control processing, the CE(s) dictates the packet-forwarding behavior of the FE(s) via the interconnect protocol. For example, the CE might control a FE by manipulating its forwarding tables, the state of its interfaces, or by adding or removing a NAT binding.
NEアーキテクチャの主要な成分は、CEと、FEと、内部連絡プロトコルです。 CEはシグナリングや制御プロトコル処理などの操作と管理プロトコルの実装に責任があります。 コントロール処理で取得された情報に基づいて、CE(s)は内部連絡プロトコルでFE(s)のパケットを進める動きを書き取ります。 例えば、CEは、NAT結合を推進テーブル、インタフェースの状態を操るか、加えるか、または取り除くことによって、FEを制御するかもしれません。
Khosravi & Anderson Informational [Page 4] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[4ページ]のRFC3654力要件2003年11月
The FE operates in the forwarding plane and is responsible for per- packet processing and handling. By allowing the control and forwarding planes to evolve independently, different types of FEs can be developed - some general purpose and others more specialized. Some functions that FEs could perform include layer 3 forwarding, metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), decapsulation, encryption, accounting, etc. Nearly all combinations of these functions may be present in practical FEs.
FEは推進飛行機で操作して、責任がある、-、パケット処理と取り扱い。 コントロールと推進飛行機が独自に発展するのを許容することによって、FEsの異なったタイプは発生できます--さらに専門にされた何人かの汎用と他のもの。 FEsが実行できたいくつかの機能が層3の推進、計量、形成、ファイアウォール、NAT、カプセル化(例えば、トンネリング)、被膜剥離術、暗号化、会計などを含んでいます。 これらの機能のほとんどすべての組み合わせが実用的なFEsに存在しているかもしれません。
Below is a diagram illustrating an example NE composed of a CE and two FEs. Both FEs and CE require minimal configuration as part of the pre-configuration process and this may be done by FE Manager and CE Manager respectively. Apart from this, there is no defined role for FE Manager and CE Manager. These components are out of scope of the architecture and requirements for the ForCES protocol, which only involves CEs and FEs.
以下に、ダイヤグラムが、NEがCEと2FEsで構成した例を例証しながら、あります。 FEマネージャとCEマネージャがそれぞれプレコンフィギュレーションプロセスとこの一部を完了しているかもしれないようにFEsとCEの両方が最小量の構成を必要とします。 これは別として、FEマネージャとCEマネージャのための定義された役割が全くありません。 これらのコンポーネントはアーキテクチャの範囲とForCESプロトコルのための要件を使い果たしました。(プロトコルはCEsとFEsにかかわるだけです)。
--------------------------------
| NE |
| ------------- |
| | CE | |
| ------------- |
| / \ |
| / \ |
| / \ |
| / \ |
| ----------- ----------- |
| | FE | | FE | |
| ----------- ----------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
--------------------------------
| | | | | | | |
| | | | | | | |
-------------------------------- | Ne| | ------------- | | | Ce| | | ------------- | | / \ | | / \ | | / \ | | / \ | | ----------- ----------- | | | FE| | FE| | | ----------- ----------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -------------------------------- | | | | | | | | | | | | | | | |
4. Architectural Requirements
4. 建築要件
The following are the architectural requirements:
↓これは建築要件です:
1) CEs and FEs MUST be able to connect by a variety of interconnect technologies. Examples of interconnect technologies used in current architectures include Ethernet, bus backplanes, and ATM (cell) fabrics. FEs MAY be connected to each other via a different technology than that used for CE/FE communication.
1) CEsとFEsはさまざまな内部連絡技術で接続できなければなりません。 現在のアーキテクチャに使用される内部連絡技術に関する例はイーサネット、バスバックプレーン、およびATM(セル)骨組みを含んでいます。 FEsはCE/FEコミュニケーションに使用されるそれと異なった技術で互いに接続されるかもしれません。
Khosravi & Anderson Informational [Page 5] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[5ページ]のRFC3654力要件2003年11月
2) FEs MUST support a minimal set of capabilities necessary for establishing network connectivity (e.g., interface discovery, port up/down functions). Beyond this minimal set, the ForCES architecture MUST NOT restrict the types or numbers of capabilities that FEs may contain.
2) FEsは1人の極小集合のネットワークの接続性を確立するのに必要な能力(例えば、インタフェース発見、/下に機能へのポート)をサポートしなければなりません。 この極小集合を超えて、ForCESアーキテクチャはFEsが含むかもしれない能力のタイプか数を制限してはいけません。
3) Packets MUST be able to arrive at the NE by one FE and leave the NE via a different FE.
3) パケットは、1FEでNEに到着して、異なったFEを通してNEを残すことができなければなりません。
4) A NE MUST support the appearance of a single functional device. For example, in a router, the TTL of the packet should be decremented only once as it traverses the NE regardless of how many FEs through which it passes. However, external entities (e.g., FE managers and CE managers) MAY have direct access to individual ForCES protocol elements for providing information to transition them from the pre- association to post-association phase.
4) NE MUSTは単一の機能素子の外観をサポートします。 例えば、ルータでは、それが通るいくつのFEsにかかわらずNEを横断するかに従って、パケットのTTLは一度だけ減少するべきです。 しかしながら、外部実体(例えば、FEマネージャとCEマネージャ) 情報を変遷に提供するために個々のForCESプロトコル要素にダイレクトに近づく手段を持っているかもしれません。プレ協会からポスト協会フェーズまでのそれら。
5) The architecture MUST provide a way to prevent unauthorized ForCES protocol elements from joining a NE. (For more protocol details, refer to section 6 requirement #2)
5) アーキテクチャは権限のないForCESプロトコル要素がNEを接合するのを防ぐ方法を提供しなければなりません。 (よりその他のプロトコルの詳細について、セクション6要件#2を参照してください)
6) A FE MUST be able to asynchronously inform the CE of a failure or increase/decrease in available resources or capabilities on the FE. Thus, the FE MUST support error monitoring and reporting. (Since there is not a strict 1-to-1 mapping between FEs and PFEs, it is possible for the relationship between a FE and its physical resources to change over time). For example, the number of physical ports or the amount of memory allocated to a FE may vary over time. The CE needs to be informed of such changes so that it can control the FE in an accurate way.
6) FE MUSTはFEで利用可能資源か能力に失敗についてCEに非同期に知らせることができるか、増強するか、または縮小します。 したがって、FE MUSTは誤りモニターと報告をサポートします。 (FEsとPFEsの間には、厳しい1〜1つのマッピングがないので、FEとその物理資源との関係が時間がたつにつれて変化するのは、可能です。) 例えば、物理的なポートの数かFEに割り当てられたメモリー容量が時間がたつにつれて、異なるかもしれません。 CEは、正確な方法でFEを制御できるようにそのような変化において知識がある必要があります。
7) The architecture MUST support mechanisms for CE redundancy or CE failover. This includes the ability for CEs and FEs to determine when there is a loss of association between them, ability to restore association and efficient state (re)synchronization mechanisms. This also includes the ability to preset the actions an FE will take in reaction to loss of association to its CE e.g., whether the FE will continue to forward packets or whether it will halt operations.
7) アーキテクチャがCE冗長のためにメカニズムをサポートしなければならない、さもなければ、CEフェイルオーバーこれはCEsとFEsがいつ、彼らの間の協会の損失があるかを決定する能力を含んでいます、協会と効率的な州(re)の同期メカニズムを返す能力。また、これは例えば、FEが、パケットを進め続けるか、または操作を止めることにかかわらずFEがCEへの協会の損失に反応で取る行動をあらかじめセットする能力を含んでいます。
8) FEs MUST be able to redirect control packets (such as RIP, OSPF messages) addressed to their interfaces to the CE. They MUST also redirect other relevant packets (e.g., such as those with Router Alert Option set) to their CE. The CEs MUST be able to configure the packet redirection information/filters on the FEs. The CEs MUST also be able to create packets and have its FEs deliver them.
8) FEsはそれらのインタフェースに扱われたコントロールパケット(リップ、OSPFメッセージなどの)をCEに向け直すことができなければなりません。 また、彼らは他の関連パケット(例えば、Router Alert Optionがセットしたことでのそれらなどの)を自分達のCEに向け直さなければなりません。 CEsはFEsの上のパケットリダイレクション情報/フィルタを構成できなければなりません。 CEsはFEsにパケットを作成して、また、彼らを提供させることができなければなりません。
Khosravi & Anderson Informational [Page 6] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[6ページ]のRFC3654力要件2003年11月
9) Any proposed ForCES architectures MUST explain how that architecture supports all of the router functions as defined in [RFC1812]. IPv4 Forwarding functions such IP header validation, performing longest prefix match algorithm, TTL decrement, Checksum calculation, generation of ICMP error messages, etc defined in RFC 1812 should be explained.
9) どんな提案されたForCESアーキテクチャでも、そのアーキテクチャが[RFC1812]で定義されるようにどうルータ機能のすべてをサポートするかがわからなければなりません。 そのようなIPヘッダー合法化、最も長い接頭語マッチアルゴリズムを実行するTTL減少、Checksum計算、ICMPエラーメッセージの世代などがRFC1812で定義したIPv4 Forwarding機能は説明されるべきです。
10) In a ForCES NE, the CE(s) MUST be able to learn the topology by which the FEs in the NE are connected.
10) Ne、力におけるCe NEのFEsが接続されているトポロジーを学ぶことができなければならなくなってください。
11) The ForCES NE architecture MUST be capable of supporting (i.e., must scale to) at least hundreds of FEs and tens of thousands of ports.
11) ForCES NEアーキテクチャがサポートすることができなければならない、(すなわち、必須が比例する、)、少なくとも何百FEsと何万ものポート。
12) The ForCES architecture MUST allow FEs AND CEs to join and leave NEs dynamically.
12) ForCESアーキテクチャで、FEsとCEsはダイナミックにNEsを接合して、残さなければなりません。
13) The ForCES NE architecture MUST support multiple CEs and FEs. However, coordination between CEs is out of scope of ForCES.
13) ForCES NEアーキテクチャは複数のCEsとFEsをサポートしなければなりません。 しかしながら、ForCESの範囲の外にCEsの間のコーディネートがあります。
14) For pre-association phase setup, monitoring, configuration issues, it MAY be useful to use standard management mechanisms for CEs and FEs. The ForCES architecture and requirements do not preclude this. In general, for post-association phase, most management tasks SHOULD be done through interaction with the CE. In certain conditions (e.g., CE/FE disconnection), it may be useful to allow management tools (e.g., SNMP) to be used to diagnose and repair problems. The following guidelines MUST be observed:
14) プレ協会フェーズセットアップ、モニターしている構成問題に、CEsとFEsに標準の管理メカニズムを使用するのは役に立つかもしれません。 ForCESアーキテクチャと要件はこれを排除しません。 一般に、ポスト協会フェーズのためのほとんどの経営者側がSHOULDに仕事を課します。CEとの相互作用で、します。 ある条件(例えば、CE/FE断線)では、管理ツール(例えば、SNMP)が問題を診断して、修理するのに使用されるのを許容するのは役に立つかもしれません。以下のガイドラインを守らなければなりません:
1. The ability for a management tool (e.g., SNMP) to be used to read
(but not change) the state of FE SHOULD NOT be precluded.
2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to
change the state of a FE in a manner that affects overall NE
behavior without the CE being notified.
1. 管理のための能力は、FE SHOULD NOTの州を読むこと(しかし、変化しない)に使用されるために(例えば、SNMP)をツーリングします。排除されます。 2. 管理ツール(例えば、SNMPなど)が通知されるCEなしで総合的なNEの振舞いに影響する方法でFEの州を変えるのは、可能であるはずがありません。
5. FE Model Requirements
5. FEモデル要件
The variety of FE functionality that the ForCES architecture allows poses a potential problem for CEs. In order for a CE to effectively control a FE, the CE must understand how the FE processes packets. We therefore REQUIRE that a FE model be created that can express the logical packet processing capabilities of a FE. This model will be used in the ForCES protocol to describe FE capabilities (see Section 6, requirement #1). The FE model MUST define both a capability model and a state model, which expresses the current configuration of the device. The FE model MUST also support multiple FEs in the NE architecture.
ForCESアーキテクチャが許容するFEの機能性のバラエティーはCEsのために潜在的な問題を引き起こします。 事実上、CEがFEを制御するように、CEは、FEがどのようにパケットを処理するかを理解しなければなりません。 私たち、したがって、REQUIRE、FEモデルは作成されて、それがa FEの論理的なパケット処理能力を言い表すことができるということです。 このモデルは、FE能力について説明するのにForCESプロトコルに使用されるでしょう(セクション6、要件#1を見てください)。 FEモデルは能力モデルと州のモデルの両方を定義しなければなりません。(モデルはデバイスの現在の構成を言い表します)。 また、FEモデルはNEアーキテクチャで複数のFEsをサポートしなければなりません。
Khosravi & Anderson Informational [Page 7] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[7ページ]のRFC3654力要件2003年11月
5.1. Types of Logical Functions
5.1. 論理関数のタイプ
The FE model MUST express what logical functions can be applied to packets as they pass through a FE. Logical functions are the packet processing functions that are applied to the packets as they are forwarded through a FE. Examples of logical functions are layer 3 forwarding, firewall, NAT, and shaping. Section 5.5 defines the minimal set of logical functions that the FE Model MUST support.
FEモデルは、FEを通り抜けるときどんな論理関数をパケットに適用できるかを言い表さなければなりません。 論理関数はFEを通してそれらを進めるときパケットに適用するパケット処理機能です。 論理関数に関する例は、層3の推進と、ファイアウォールと、NATと、形成です。 セクション5.5はFE Modelがサポートしなければならない論理関数の極小集合を定義します。
5.2. Variations of Logical Functions
5.2. 論理関数の変化
The FE model MUST be capable of supporting/allowing variations in the way logical functions are implemented on a FE. For example, on a certain FE the forwarding logical function might have information about both the next hop IP address and the next hop MAC address, while on another FE these might be implemented as separate logical functions. Another example would be NAT functionality that can have several flavors such as Traditional/Outbound NAT, Bi-directional NAT, Twice NAT, and Multihomed NAT [RFC2663]. The model must be flexible enough to allow such variations in functions.
論理関数がFEで実装される方法で変化をサポートしなければならないか、またはFEモデルは許容できなければなりません。 例えば、あるFEでは、推進論理関数で、別々の論理関数として次のホップIPアドレスとこれらが別のFEでそうするかもしれませんが、MACが扱う次のホップの両方の情報を実装するかもしれません。 別の例はTraditional/外国行きのNATや、Bi方向のNATや、Twice NATや、Multihomed NAT[RFC2663]などのいくつかの風味を持つことができるNATの機能性でしょう。 モデルは機能のそのような変化を許容するほどフレキシブルでなければなりません。
5.3. Ordering of Logical Functions
5.3. 論理関数の注文
The model MUST be capable of describing the order in which these logical functions are applied in a FE. The ordering of logical functions is important in many cases. For example, a NAT function may change a packet's source or destination IP address. Any number of other logical functions (e.g., layer 3 forwarding, ingress/egress firewall, shaping, and accounting) may make use of the source or destination IP address when making decisions. The CE needs to know whether to configure these logical functions with the pre-NAT or post-NAT IP address. Furthermore, the model MUST be capable of expressing multiple instances of the same logical function in a FE's processing path. Using NAT again as an example, one NAT function is typically performed before the forwarding decision (packets arriving externally have their public addresses replaced with private addresses) and one NAT function is performed after the forwarding decision (for packets exiting the domain, their private addresses are replaced by public ones).
モデルはこれらの論理関数がFEで適用されるオーダーについて説明できなければなりません。 多くの場合、論理関数の注文は重要です。 例えば、NAT機能はパケットのソースか送付先IPアドレスを変えるかもしれません。 決定をするとき、他のいろいろな論理関数(例えば、層3の推進、イングレス/出口ファイアウォール、形成、および会計)がソースか送付先IPアドレスを利用するかもしれません。 CEは、プレNATかポストNAT IPアドレスでこれらの論理関数を構成するかどうかを知る必要があります。 その上、モデルはFEのプロセシング・パスで同じ論理関数の複数のインスタンスを言い表すことができなければなりません。 再び例としてNATを使用して、1つのNAT機能が推進決定の前に通常実行されます、そして、(外部的に到着するパケットで、それらの場内放送をプライベート・アドレスに取り替えます)1つのNAT機能が推進決定の後に実行されます(ドメインを出るパケットに関して、それらのプライベート・アドレスを公共のものに取り替えます)。
5.4. Flexibility
5.4. 柔軟性
Finally, the FE model SHOULD provide a flexible infrastructure in which new logical functions and new classification, action, and parameterization data can be easily added. In addition, the FE model MUST be capable of describing the types of statistics gathered by each logical function.
最終的に、FEモデルSHOULDは容易に新しい論理関数、新しい分類、動作、およびパラメタリゼーションデータを加えることができるフレキシブルなインフラストラクチャを提供します。 さらに、FEモデルは各論理関数によって集められた統計のタイプについて説明できなければなりません。
Khosravi & Anderson Informational [Page 8] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[8ページ]のRFC3654力要件2003年11月
5.5. Minimal Set of Logical Functions
5.5. 極小集合の論理関数
The rest of this section defines a minimal set of logical functions that any FE model MUST support. This minimal set DOES NOT imply that all FEs must provide this functionality. Instead, these requirements only specify that the model must be capable of expressing the capabilities that FEs may choose to provide.
このセクションの残りはどんなFEモデルもサポートしなければならない1人の極小集合の論理関数を定義します。 この極小集合DOES NOTは、すべてのFEsがこの機能性を提供しなければならないのを含意します。 代わりに、これらの要件は、モデルがFEsが提供するのを選ぶかもしれない能力を言い表すことができなければならないと指定するだけです。
1) Port Functions The FE model MUST be capable of expressing the number of ports on the device, the static attributes of each port (e.g., port type, link speed), and the configurable attributes of each port (e.g., IP address, administrative status).
1) FEがモデル化するポートFunctionsはデバイスのポートの数、それぞれのポートの静的な属性(例えば、タイプを移植してください、リンク速度)、およびそれぞれのポートの構成可能な属性(例えば、IPアドレス、管理状態)を表すことができなければなりません。
2) Forwarding Functions The FE model MUST be capable of expressing the data that can be used by the forwarding function to make a forwarding decision. Support for IPv4 and IPv6 unicast and multicast forwarding functions MUST be provided by the model.
2) FEモデルをFunctionsに送ると、推進機能によって使用される、推進決定をすることができるデータは言い表すことができなければなりません。 モデルはIPv4のサポートとIPv6ユニキャストとマルチキャスト推進機能を提供しなければなりません。
3) QoS Functions The FE model MUST allow a FE to express its QoS capabilities in terms of, e.g., metering, policing, shaping, and queuing functions. The FE model MUST be capable of expressing the use of these functions to provide IntServ or DiffServ functionality as described in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290].
3) FEモデルがFEにQoS能力を言い表させなければならないQoS Functions、例えば、計量、取り締まり、形成、および列を作り機能。 FEモデルは、[RFC2211]、[RFC2212]、[RFC2215]、[RFC2475]、および[RFC3290]で説明されるようにIntServかDiffServに機能性を供給するためにこれらの機能の使用を言い表すことができなければなりません。
4) Generic Filtering Functions The FE model MUST be capable of expressing complex sets of filtering functions. The model MUST be able to express the existence of these functions at arbitrary points in the sequence of a FE's packet processing functions. The FE model MUST be capable of expressing a wide range of classification abilities from single fields (e.g., destination address) to arbitrary n-tuples. Similarly, the FE model MUST be capable of expressing what actions these filtering functions can perform on packets that the classifier matches.
4) FEがモデル化するジェネリックFiltering Functionsは複雑なフィルタ機能を言い表すことができなければなりません。 モデルは任意点でFEのパケット処理機能の系列でこれらの機能の存在を言い表すことができなければなりません。 FEモデルはただ一つの分野(例えば、送付先アドレス)から任意のn-tuplesまでさまざまな分類能力を言い表すことができなければなりません。 同様に、FEモデルは、これらのフィルタ機能がクラシファイアが合っているパケットにどんな動作を実行できるかを言い表すことができなければなりません。
5) Vendor-Specific Functions The FE model SHOULD be extensible so that new, currently unknown FE functionality can be expressed. The FE Model SHOULD NOT be extended to express standard/common functions in a proprietary manner. This would NOT be ForCES compliant.
5) 広げることができるそうがそんなに新しかったなら、ベンダー特有のFunctions FEはSHOULDをモデル化して、現在未知のFEの機能性は言い表すことができます。 FE Model SHOULD、独占方法で標準的、または、一般的な機能を言い表すには、広げられないでください。 これはForCES対応しないでしょう。
6) High-Touch Functions The FE model MUST be capable of expressing the encapsulation and tunneling capabilities of a FE. The FE model MUST support functions
6) FEがモデル化する高接触FunctionsはFEのカプセル化とトンネリング能力を言い表すことができなければなりません。 FEモデルは機能をサポートしなければなりません。
Khosravi & Anderson Informational [Page 9] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[9ページ]のRFC3654力要件2003年11月
that mark the class of service that a packet should receive (i.e., IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE model MAY support other high touch functions (e.g., NAT, ALG).
それはパケットが受けるはずであるサービス(すなわち、IPv4ヘッダーTOS八重奏かIPv6 Traffic Class八重奏)のクラスをマークします。 FEモデルは、他のハイタッチが機能(例えば、NAT、ALG)であるとサポートするかもしれません。
7) Security Functions The FE model MUST be capable of expressing the types of encryption that may be applied to packets in the forwarding path.
7) FEがモデル化するセキュリティFunctionsは推進経路のパケットに適用されるかもしれない暗号化のタイプを言い表すことができなければなりません。
8) Off-loaded Functions Per-packet processing can leave state in the FE, so that logical functions executed during packet processing can perform in a consistent manner (for instance, each packet may update the state of the token bucket occupancy of a give policer). In addition, the FE Model MUST allow logical functions to execute asynchronously from packet processing, according to a certain finite-state machine, in order to perform functions that are, for instance, off-loaded from the CE to the FE. The FE model MUST be capable of expressing these asynchronous functions. Examples of such functions include the finite-state machine execution required by TCP termination or OSPF Hello processing, triggered not only by packet events, but by timer events as well. This Does NOT mean off-loading of any piece of code to an FE, just that the FE Model should be able to express existing Off-loaded functions on an FE.
8) 積み下ろされたFunctions Per-パケット処理はFEで状態を出ることができます、パケット処理の間に実行された論理関数が一貫した方法で働くことができる(例えば、各パケットはaの占有がより多くのpolicerに与えるトークンバケツの状態をアップデートするかもしれない)ように。 さらに、FE Modelはパケット処理から非同期に実行する論理関数を許容しなければなりません、ある有限状態機械に従って、例えばCEからFEまで積み下ろされる機能を実行するために。 FEモデルはこれらの非同期な機能を言い表すことができなければなりません。 そのような機能に関する例はTCP終了で必要である有限状態機械実行かパケットイベントだけで引き起こされるのではなく、また、タイマイベントでも引き起こされたOSPF Hello処理を含んでいます。 このDoesは、どんなコードがFEへ積み下ろされることを意味しないで、まさしくそれはFE Modelです。FEで既存のOff満載の機能を言い表すことができるべきです。
9) IPFLOW/PSAMP Functions Several applications such as, Usage-based Accounting, Traffic engineering, require flow-based IP traffic measurements from Network Elements. [IPFLOW] defines architecture for IP traffic flow monitoring, measuring and exporting. The FE model SHOULD be able to express metering functions and flow accounting needed for exporting IP traffic flow information. Similarly to support measurement-based applications, [PSAMP] describes a framework to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The FE model SHOULD be able to express statistical packet filtering functions and packet information needed for supporting packet sampling applications.
9) UsageベースのAccounting、Trafficが設計して、Network Elementsから流れベースのIPトラフィック測定を必要とするようなIPFLOW/PSAMP Functions Severalアプリケーション。 [IPFLOW]はIP交通の流れモニター、測定、および輸出のために構造を定義します。 FEはIPが取引する輸出に必要である計量機能を言い表すことができて、流れ会計が流れ情報であったならSHOULDをモデル化します。 同様に、測定ベースのアプリケーションを支持するなら、[PSAMP]は、ネットワーク要素が統計的で他の方法でパケットの部分集合を抽出する能力の標準セットを定義するために枠組みについて説明します。 FEはパケット標本抽出を支持するのに必要である統計的なパケットフィルタ機能を言い表すことができて、パケット情報がアプリケーションであったならSHOULDをモデル化します。
6. ForCES Protocol Requirements
6. 力は要件について議定書の中で述べます。
This section specifies some of the requirements that the ForCES protocol MUST meet.
このセクションはForCESプロトコルが満たされなければならないという要件のいくつかを指定します。
1) Configuration of Modeled Elements The ForCES protocol MUST allow the CEs to determine the capabilities of each FE. These capabilities SHALL be expressed using the FE model whose requirements are defined in Section 5. Furthermore, the protocol MUST provide a means for the CEs to control all the FE
1) Elements ForCESが議定書の中で述べるModeledの構成で、CEsはそれぞれのFEの能力を決定できなければなりません。 これらの能力SHALL、要件がセクション5で定義されるFEモデルを使用することで、言い表されてください。 その上、プロトコルはCEsがすべてのFEを制御する手段を提供しなければなりません。
Khosravi & Anderson Informational [Page 10] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[10ページ]のRFC3654力要件2003年11月
capabilities that are discovered through the FE model. The protocol MUST be able to add/remove classification/action entries, set/delete parameters, query statistics, and register for and receive events.
発見される能力はFEを通してモデル化されます。 プロトコルは、出来事に分類/動作エントリーを加えるか、または取り除いて、パラメタを設定するか、または削除して、統計について質問して、登録して、受けることができなければなりません。
2) Support for Secure Communication
a) FE configuration will contain information critical to the
functioning of a network (e.g., IP Forwarding Tables). As
such, it MUST be possible to ensure the integrity of all ForCES
protocol messages and protect against man-in-the-middle
attacks.
b) FE configuration information may also contain information
derived from business relationships (e.g., service level
agreements). Because of the confidential nature of the
information, it MUST be possible to secure (make private) all
ForCES protocol messages.
c) In order to ensure that authorized CEs and FEs are
participating in a NE and defend against CE or FE impersonation
attacks, the ForCES architecture MUST select a means of
authentication for CEs and FEs.
d) In some deployments ForCES is expected to be deployed between
CEs and FEs connected to each other inside a box over a
backplane, where physical security of the box ensures that
man-in-the-middle, snooping, and impersonation attacks are not
possible. In such scenarios the ForCES architecture MAY rely
on the physical security of the box to defend against these
attacks and protocol mechanisms May be turned off.
e) In the case when CEs and FEs are connected over a network,
security mechanisms MUST be specified or selected that protect
the ForCES protocol against such attacks. Any security
solution used for ForCES MUST specify how it deals with such
attacks.
2) Secure Communication a)のサポート FE構成はネットワーク(例えば、IP Forwarding Tables)の機能に重要な情報を含むでしょう。 そういうものとして、すべてのForCESプロトコルメッセージの保全を確実にして、介入者攻撃b)から守るのは可能でなければなりません。 また、FE設定情報は取引関係(例えば、サービスレベル協定)から得られた情報を含むかもしれません。 情報の秘密保持のために、それは安全にするのにおいて(兵卒) すべてのForCESをプロトコルメッセージcにします)可能であるに違いありません。 それがCEsを認可して、FEsがNEに参加しているのを確実にして、CEかFEものまね攻撃に対して防御して、ForCES構造がCEsとFEs. dのために認証の手段を選択しなければならない、) いくつかの展開では、箱の物理的なセキュリティが中央のその男性を確実にするところで詮索しながらバックプレーンの上で箱の中に互いに接続されたCEsとFEsの間でForCESが配備されると予想されて、ものまね攻撃は可能ではありません。 そのようなシナリオでは、ForCES構造は、メカニズム5月にこれらの攻撃とプロトコルに対して防御するために箱の物理的なセキュリティを当てにするかもしれません。オフにされてください、e) CEsとFEsがネットワークの上に接続されるときの場合では、そのような攻撃に対してForCESを保護する指定していなければならないか、または選択されたセキュリティー対策が議定書を作ります。 ForCESに使用されるどんなセキュリティ解決策もそれがどうそのような攻撃に対処するかを指定しなければなりません。
3) Scalability The ForCES protocol MUST be capable of supporting (i.e., must scale to) at least hundreds of FEs and tens of thousands of ports. For example, the ForCES protocol field sizes corresponding to FE or port numbers SHALL be large enough to support the minimum required numbers. This requirement does not relate to the performance of a NE as the number of FEs or ports in the NE grows.
3) ForCESプロトコルが支持できなければならないスケーラビリティ、(すなわち、必須が比例する、)、少なくとも何百FEsと何万ものポート。 例えば、多大が最小の必要数を支持するために十分であったなら、ForCESはFEかポートナンバーSHALLに対応する分野サイズについて議定書の中で述べます。 NEのFEsかポートの数が成長するとき、この要件はNEの性能に関連しません。
4) Multihop When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES protocol will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g., TCP, SCTP) for transport purposes.
4) マルチホップWhenのCEsとFEsは単一のL3ルーティングホップを超えて切り離されて、ForCESプロトコルは輸送目的のための適切な信頼性、セキュリティ、および輻輳制御(例えば、TCP、SCTP)がある既存のRFC2914対応することのL4プロトコルを利用するでしょう。
Khosravi & Anderson Informational [Page 11] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[11ページ]のRFC3654力要件2003年11月
5) Message Priority The ForCES protocol MUST provide a means to express the protocol message priorities.
5) ForCESが議定書の中で述べるメッセージPriorityはプロトコルメッセージプライオリティを言い表す手段を提供しなければなりません。
6) Reliability
a) The ForCES protocol will be used to transport information that
requires varying levels of reliability. By strict or robust
reliability in this requirement we mean, no losses, no
corruption, no re-ordering of information being transported and
delivery in a timely fashion.
b) Some information or payloads, such as redirected packets or
packet sampling, may not require robust reliability (can
tolerate some degree of losses). For information of this sort,
ForCES MUST NOT be restricted to strict reliability.
c) Payloads such as configuration information, e.g., ACLs, FIB
entries, or FE capability information (described in section 6,
(1)) are mission critical and must be delivered in a robust
reliable fashion. Thus, for information of this sort, ForCES
MUST either provide built-in protocol mechanisms or use a
reliable transport protocol for achieving robust/strict
reliability.
d) Some information or payloads, such as heartbeat packets that
may be used to detect loss of association between CE and FEs
(see section 6, (8)), may prefer timeliness over reliable
delivery. For information of this sort, ForCES MUST NOT be
restricted to strict reliability.
e) When ForCES is carried over multi-hop IP networks, it is a
requirement that ForCES MUST use a [RFC2914]-compliant
transport protocol.
f) In cases where ForCES is not running over an IP network such as
an Ethernet or cell fabric between CE and FE, then reliability
still MUST be provided when carrying critical information of
the types specified in (c) above, either by the underlying
link/network/transport layers or by built-in protocol
mechanisms.
6) 信頼性a) ForCESプロトコルは、レベルを変えるのを信頼性を要求する情報を輸送するのに使用されるでしょう。 損失がない、不正が全く再注文されないで、私たちが言っている輸送される情報のこの要件の厳しいか強健な信頼性とaタイムリーなファッションb)での配送で 向け直されたパケットかパケット標本抽出などのいくつかの情報かペイロードが強健な信頼性(いくらかの損失を黙認できる)を必要としないかもしれません。 この種類の情報に関しては、ForCESを厳しい信頼性c)に制限してはいけません。 例えば、設定情報、ACLs、FIBエントリー、またはFE能力情報などの有効搭載量、(セクションで説明されて、6、(1))をミッションクリティカルであり、強健な信頼できるファッションで渡さなければなりません。 したがって、この種類の情報に関して、ForCESは、強健であるか厳しい信頼性d)を達成するのに内蔵のプロトコルメカニズムを提供しなければならないか、または信頼できるトランスポート・プロトコルを使用しなければなりません。 それが使用されているかもしれないハートビートパケットなどのいくつかの情報かペイロードがCEとFEsとの協会の損失を検出します。(セクション6((8)))が信頼できる配信よりタイムリーさであるのを好むかもしれないのを確実にしてください。 この種類の情報に関しては、ForCESを厳しい信頼性e)に制限してはいけません。 ForCESがマルチホップIPネットワークの上まで運ばれるとき、ForCESが言いなりになった状態で[RFC2914]を使用しなければならないという要件がプロトコルf)を輸送するということです。 運ぶときForCESがイーサネットなどのIPネットワークをひいてはいけないか、またはまだCEとFE、当時の信頼性の間のセル織物を提供しなければならない場合では、タイプに関する重要情報はメカニズム、基本的なリンク/ネットワーク/トランスポート層または内蔵のプロトコルメカニズムによる(c)で指定しました。
7) Interconnect Independence The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 4, requirement #1)
7) ForCESが議定書の中で述べる内部連絡Independenceはさまざまな内部連絡技術を支持しなければなりません。 (セクション4、要件#1を示します)
8) CE redundancy or CE failover The ForCES protocol MUST support mechanisms for CE redundancy or CE failover. This includes the ability for CEs and FEs to determine when there is a loss of association between them, ability to restore association and efficient state (re)synchronization mechanisms. This also includes the ability to preset the actions an FE will take in
8) ForCESが議定書の中で述べるCE冗長かCEフェイルオーバーがCE冗長のためにメカニズムをサポートしなければならない、さもなければ、CEフェイルオーバーこれはCEsとFEsがいつ、彼らの間の協会の損失があるかを決定する能力を含んでいます、協会と効率的な州(re)の同期メカニズムを返す能力。また、これはFEが中に入れる動作をあらかじめセットする能力を含んでいます。
Khosravi & Anderson Informational [Page 12] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[12ページ]のRFC3654力要件2003年11月
reaction to loss of association to its CE, e.g., whether the FE will continue to forward packets or whether it will halt operations. (refer to section 4, requirement #7)
例えば、FEが、パケットを進め続けるか、または操作を止めることにかかわらずCEへの協会の損失への反応。 (セクション4、要件#7を示します)
9) Packet Redirection/Mirroring
a) The ForCES protocol MUST define a way to redirect packets from
the FE to the CE and vice-versa. Packet redirection terminates
any further processing of the redirected packet at the FE.
b) The ForCES protocol MUST define a way to mirror packets from
the FE to the CE. Mirroring allows the packet duplicated by
the FE at the mirroring point to be sent to the CE while the
original packet continues to be processed by the FE.
9) パケットRedirection/ミラーリングa) ForCESプロトコルはFEからCEまでパケットを向け直す方法を定義しなければなりません、そして、逆もまた同様です。 リダイレクションが少しもより遠くに処理しながら終えるFE. bの向け直されたパケットのパケット) ForCESプロトコルはFEからCEまでパケットを映す方法を定義しなければなりません。 オリジナルのパケットは、FEによって処理され続けていますが、ミラーリングは、ミラーリングポイントのFEによってコピーされたパケットがCEに送られるのを許容します。
Examples of packets that may be redirected or mirrored include control packets (such as RIP, OSPF messages) addressed to the interfaces or any other relevant packets (such as those with Router Alert Option set). The ForCES protocol MUST also define a way for the CE to configure the behavior of a) and b) (above), to specify which packets are affected by each.
向け直されるか、または映されるかもしれないパケットに関する例はインタフェースまで記述されたコントロールパケット(リップ、OSPFメッセージなどの)かいかなる他の関連パケット(Router Alert Optionがセットしたことでのそれらなどの)も含んでいます。 また、ForCESプロトコルはCEがa)とb)の振舞いを構成する方法を定義しなければなりません。 (above), どのパケットがそれぞれで影響を受けるかを指定するために。
10) Topology Exchange The ForCES protocol or information carried in the ForCES protocol MUST allow those FEs which have inter-FE topology information to provide that information to the CE(s).
10) ForCESプロトコルか情報がForCESプロトコルで運んだトポロジーExchangeは相互FEトポロジー情報を持っているそれらのFEsにその情報をCE(s)に供給させなければなりません。
11) Dynamic Association The ForCES protocol MUST allow CEs and FEs to join and leave a NE dynamically. (refer to section 4, requirement #12)
11) ForCESが議定書の中で述べるダイナミックなAssociationはCEsとFEsにNEをダイナミックに接合して、残させなければなりません。 (セクション4、要件#12を示します)
12) Command Bundling The ForCES protocol MUST be able to group an ordered set of commands to a FE. Each such group of commands SHOULD be sent to the FE in as few messages as possible. Furthermore, the protocol MUST support the ability to specify if a command group MUST have all-or-nothing semantics.
12) ForCESが議定書の中で述べるコマンドBundlingは1つの順序集合のコマンドをFEに分類できなければなりません。 そのようなものが分類するそれぞれが、SHOULDができるだけわずかなメッセージのFEに送られると命令します。 その上、プロトコルが指揮機関がそうしたに違いないかどうか指定する能力を支持しなければならない、オール、無、意味論。
13) Asynchronous Event Notification The ForCES protocol MUST be able to asynchronously notify the CE of events on the FE such as failures or change in available resources or capabilities. (refer to section 4, requirement #6)
13) FEにおける失敗などの出来事についてCEに非同期に通知しなければならない、さもなければ、ForCESが議定書の中で述べる非同期なEvent Notificationは利用可能資源か能力で変化できなければなりません。 (セクション4、要件#6を示します)
14) Query Statistics The ForCES protocol MUST provide a means for the CE to be able to query statistics (monitor performance) from the FE.
14) ForCESが議定書の中で述べる質問StatisticsはCEがFEから統計(仕事ぶりを監視する)について質問できる手段を提供しなければなりません。
Khosravi & Anderson Informational [Page 13] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[13ページ]のRFC3654力要件2003年11月
15) Protection against Denial of Service Attacks (based on CPU overload or queue overflow) Systems utilizing the ForCES protocol can be attacked using denial of service attacks based on CPU overload or queue overflow. The ForCES protocol could be exploited by such attacks to cause the CE to become unable to control the FE or appropriately communicate with other routers and systems. The ForCES protocol MUST therefore provide mechanisms for controlling FE capabilities that can be used to protect against such attacks. FE capabilities that MUST be manipulated via ForCES include the ability to install classifiers and filters to detect and drop attack packets, as well as to be able to install rate limiters that limit the rate of packets which appear to be valid but may be part of an attack (e.g., bogus BGP packets).
15) サービス妨害Attacks(CPUオーバーロードか待ち行列オーバーフローに基づいている)に対する保護 CPUオーバーロードか待ち行列オーバーフローに基づくサービス不能攻撃を使用することでForCESプロトコルを利用するシステムは攻撃できます。 CEがFEを制御するか、または適切に他のルータとシステムとコミュニケートできないようになることを引き起こすのにそのような攻撃でForCESプロトコルを利用できるでしょう。したがって、ForCESプロトコルは、そのような攻撃から守るのに使用できるFE能力を制御するのにメカニズムを提供しなければなりません。 ForCESを通して操らなければならないFE能力は、攻撃パケットを検出して、落として、有効であるように見えるパケットのレートを制限するレートリミタはインストールできるようにクラシファイアとフィルタをインストールする能力を含んでいますが、攻撃(例えば、にせのBGPパケット)の一部であるかもしれません。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC3290] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
Informal Management Model for DiffServ Routers", RFC 3290,
May 2002.
[RFC3290] Bernet、Y.、ブレーク、S.、グロースマン、D.、およびA.スミス、「非公式の管理はDiffServルータのためにモデル化します」、RFC3290、2002年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, September
1997.
[RFC2212] ShenkerとS.とヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC
2215, September 1997.
[RFC2215] ShenkerとS.とJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weisss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ワイス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 14, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP14、RFC2914、2000年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2663] SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
Khosravi & Anderson Informational [Page 14] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[14ページ]のRFC3654力要件2003年11月
7.2. Informative References
7.2. 有益な参照
[RFC3532] Anderson, T. and J. Buerkle, "Requirements for the Dynamic
Partitioning of Switching Elements", RFC 3532, May 2003.
[RFC3532] アンダーソン、T.、およびJ.Buerkle(「スイッチング素子のダイナミックな仕切りのための要件」、RFC3532)は2003がそうするかもしれません。
[IPFLOW] Quittek, et al., "Requirements for IP Flow Information
Export", Work in Progress, February 2003.
[IPFLOW] Quittek、他、「IP流れ情報輸出のための要件」、Progress、2003年2月のWork。
[PSAMP] Duffield, et al., "A Framework for Passive Packet
Measurement ", Work in Progress, March 2003.
[PSAMP] 2003年3月のダッフィールド、他、「受け身のパケット測定のための枠組み」処理中の作業。
8. Security Considerations
8. セキュリティ問題
See architecture requirement #5 and protocol requirement #2.
構造要件#5とプロトコル要件#2を見てください。
9. Authors' Addresses & Acknowledgments
9. 作者のアドレスと承認
This document was written by the ForCES Requirements design team:
このドキュメントはForCES Requirementsデザインチームによって書かれました:
Todd A. Anderson (Editor)
トッド・A.アンダーソン(エディタ)
Ed Bowen IBM Zurich Research Laboratory Saumerstrasse 4 CH-8803 Rueschlikon Switzerland
エドボーエンIBMチューリッヒ研究所Saumerstrasse4CH-8803 Rueschlikonスイス
Phone: +41 1 724 83 68 EMail: edbowen@us.ibm.com
以下に電話をしてください。 +41 1 724 83 68はメールされます: edbowen@us.ibm.com
Ram Dantu Department of Computer Science University of North Texas, Denton, Texas, 76203
ノーステキサス、デントン、テキサス 76203人の牡羊座Dantuコンピュータサイエンス学部大学
Phone: 940 565 2822 EMail: rdantu@unt.edu
以下に電話をしてください。 2822年の940 565メール: rdantu@unt.edu
Avri Doria ETRI 161 Gajeong-dong, Yuseong-gu Deajeon 305-350 Korea
AvriドーリアETRI161Gajeong-ドング、Yuseong-gu Deajeon305-350韓国
EMail: avri@acm.org
メール: avri@acm.org
Khosravi & Anderson Informational [Page 15] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[15ページ]のRFC3654力要件2003年11月
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803
ゴパルノキアResearch Center5、道端の道路、バーリントン、MA 01803に激突してください。
Phone: 1-781-993-3685 EMail: ram.gopal@nokia.com
以下に電話をしてください。 1-781-993-3685 メールしてください: ram.gopal@nokia.com
Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada
ジャマルハディサリムZnyxネットワークオンタリオオタワ(カナダ)
EMail: hadi@znyx.com
メール: hadi@znyx.com
Hormuzd Khosravi (Editor)
Hormuzd Khosravi(エディタ)
Muneyb Minhazuddin Avaya Inc. 123, Epping road, North Ryde, NSW 2113, Australia Phone: +61 2 9352 8620 EMail: muneyb@avaya.com
Muneyb Minhazuddin Avaya Inc.123、エッピング道路、北部ライド、NSW2113、オーストラリア電話: +61 2 9352 8620はメールされます: muneyb@avaya.com
Margaret Wasserman Nokia Research Center 5 Wayside Road Burlington, MA 01803 Phone: +1 781 993 3858 EMail: margaret.wasserman@nokia.com
マーガレットワッサーマンノキアResearch Center5の道端の道路バーリントン、MA 01803は以下に電話をします。 +1 3858年の781 993メール: margaret.wasserman@nokia.com
The authors would like to thank Vip Sharma and Lily Yang for their valuable contributions.
作者は彼らの有価約因についてVipシャルマとリリーYangに感謝したがっています。
Khosravi & Anderson Informational [Page 16] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[16ページ]のRFC3654力要件2003年11月
10. Editors' Contact Information
10. エディタの問い合わせ先
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd Khosraviインテル2111NE第25Avenueヒースボロー、または97124米国
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
以下に電話をしてください。 +1 0334年の503 264メール: hormuzd.m.khosravi@intel.com
Todd A. Anderson Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
トッドA.アンダーソンインテル2111NE第25Avenueヒースボロー、または97124米国
Phone: +1 503 712 1760 EMail: todd.a.anderson@intel.com
以下に電話をしてください。 +1 1760年の503 712メール: todd.a.anderson@intel.com
Khosravi & Anderson Informational [Page 17] RFC 3654 ForCES Requirements November 2003
Khosraviとアンダーソン情報[17ページ]のRFC3654力要件2003年11月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Khosravi & Anderson Informational [Page 18]
KhosraviとアンダーソンInformationalです。[18ページ]
一覧
スポンサーリンク
