Network Working Group H. Khosravi, Ed.
Request for Comments: 3654 T. Anderson, Ed.
Category: Informational Intel
November 2003
Requirements for Separation of IP Control and Forwarding
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書は、転送と制御素子分離（のForCES）アーキテクチャを紹介し、関連用語の集合を定義します。この文書はまた、論理デバイスをネットワークIP（IPv4の、IPv6の、等）の制御及びデータ転送プレーンを分離するアーキテクチャ、モデリング、およびプロトコル要件のセットを定義します。
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
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スイッチングのような）所定の機能を提供するように協働する多数の論理的に別個のエンティティで構成されています。ネットワーク要素部品の二つの主要なタイプが存在する：コントロールプレーンのコンポーネントおよび転送プレーンコンポーネント。一般的には、転送プレーンの構成要素は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つの主要部分で構成されています。これらのコンポーネントは、相互に関連しながら、互いにほぼ独立している機能を実行します。底部にデータ転送プレーンで動作し、パケットごとの処理及び転送を担当して転送パスです。フォワーディングプレーン上でコントロールプレーンでの操作を担当してネットワーク・オペレーティング・システムです。ルータまたはスイッチの場合には、ネットワーク・オペレーティング・システムは、ルーティングシグナリング及び制御プロトコル（例えば、RIP、OSPFおよびRSVP）と転送テーブル、フロー毎のQoSテーブルとアクセス制御リスト操作することにより転送動作を指示する実行します。典型的には、これらのデバイスのアーキテクチャは、外部エンティティに対して単一の機能全体にこの機能の全てを兼ね備えました。
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.
アドレス指定可能なエンティティ（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.
物理的転送要素（PFE） - パケット単位の処理及び取り扱いを提供するために使用されるハードウェアを含むAE。このハードウェアは、から成ることができる（これらに限定されないが）、ネットワークプロセッサ、ASICの、複数のチップを有するラインカードまたは汎用プロセッサで単独でボックススタンド。
Physical Control Element (PCE) - An AE that includes hardware used to provide control functionality. This hardware typically includes a general-purpose processor.
物理的制御要素（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.
転送要素（FE） - のForCESプロトコルを実装する論理エンティティ。 FEは、のForCESプロトコルを介してCEによって制御/指示されるように、パケット単位の処理および取り扱いを提供するために、基礎となるハードウェアを使用します。 FEは、単一のブレード（またはPFE）、PFE又は複数のPFEのパーティションであることが起こり得ます。
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.
制御要素（CE） - のForCESプロトコルを実装し、どのようにパケットを処理するために1つの以上のFEを指示するためにそれを使用する論理エンティティ。 CEは、このような制御およびシグナリングプロトコルの実行などの機能を扱います。 CEはPCEのパーティションまたは全体のPCEからなるものであってもよいです。
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.
事前会合相 - FEマネージャ（以下を参照）およびCEマネージャが（下記参照）FEとCEが同じネットワーク要素の一部であるべきかを決定される期間。 PFEとのPCEの任意のパーティショニングは、このフェーズの間に発生します。
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.
FEは、CEとFEが互いに通信を確立する時間を含め、その逆も同様に制御することであるCE知っている期間 - ポスト会合フェーズ。
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 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ポスト協会フェーズプロトコル - CEとFEとの間にポスト会合相の通信に使用されるプロトコル。このプロトコルは、CE-に-CE通信、FE-に-FE通信、またはFEとCEマネージャ間の通信には適用されません。 ForCESプロトコルは、複数のFEはスレーブであり、CEがマスターであるマスター・スレーブプロトコルです。このプロトコルは、通信チャネル（例えば、接続確立、ハートビート）の管理及び制御メッセージ自体の両方を含みます。このプロトコルは、単一のプロトコル可能性があり、または一緒に働いて、複数のプロトコルで構成されてできました。
FE Model - A model that describes the logical processing functions of a FE.
FEモデル - 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 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.
FEマネージャー - プレ会合相で動作し、FEが通信すべきCE（S）に決定する責任がある論理エンティティ。このプロセスは、CEの発見と呼ばれ、利用可能なCEの機能を学習FEマネージャを含むことができます。 FEマネージャが使用する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の発見と呼ばれ、利用できるのFEの機能を学習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.
事前会合フェーズプロトコル - のCEまたは複数のFEを使用するかを決定するために使用されるFEマネージャとCE管理者との間のプロトコル。事前会合相プロトコルは、CEおよび/またはFE能力発見メカニズムを含むことができます。この能力の発見プロセスは完全に（第6節、要件＃1を参照）のForCESプロトコル内で使用されているものとは別の（と置き換えることはありません）であることに注意してください。しかし、2つの機能ディスカバリメカニズム（セクション5を参照）と同じFEモデルを利用してもよいです。事前会合相プロトコルは本書では更に説明しません。
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ネットワーク要素（NE） - 一の以上のCEと1つの以上のFEで構成するエンティティ。 NE外のエンティティに、NEは、単一の管理ポイントを表します。同様に、NEは、通常、外部エンティティからその内部組織を隠します。
ForCES Protocol Element - A FE or CE.
ForCESプロトコル要素 - 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.
ハイタッチ能力 - この用語は、IPヘッダーで発見されたものよりも、他のコンテンツに基づいて、パケットの内容やヘッダーに行動を取るために、いくつかのフォワーダーで見つかった機能に適用するために使用されます。これらの機能の例としては、NAT-PT、ファイアウォール、およびL7コンテンツの認識が含まれます。
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は、その転送テーブルを操作することにより、FE、そのインタフェースの状態を制御し、または結合NATを追加または除去することによってかもしれません。
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は、フォワーディングプレーンで動作し、パケットあたりの処理および取り扱いを担当しています。より専門的ないくつかの一般的な目的及び他の - コントロールを可能にし、独立して進化して平面を転送することによって、複数のFEの異なるタイプを開発することができます。 FEが実行できるいくつかの機能は、これらの機能のほぼ全ての組み合わせが実用的フェスに存在することができるレイヤ3フォワーディング、計量、整形、ファイアウォール、NAT、カプセル化（例えば、トンネル）、デカプセル化、暗号化、課金、等が挙げられます。
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.
以下CE二つのFEからなる例NEを示す図です。両方のFEおよびCEは、事前設定プロセスの一部として、最小限の構成を必要とし、これは、それぞれFE ManagerおよびCEマネージャによって行うことができます。これとは別に、FE ManagerおよびCEマネージャのための定義された役割がありません。これらのコンポーネントは、CEとFEを含むのForCESプロトコルのためのアーキテクチャおよび要件の範囲外です。
--------------------------------
| NE |
| ------------- |
| | CE | |
| ------------- |
| / \ |
| / \ |
| / \ |
| / \ |
| ----------- ----------- |
| | FE | | FE | |
| ----------- ----------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
--------------------------------
| | | | | | | |
| | | | | | | |
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）CEとFEは、相互接続技術の様々な接続できなければなりません。現在のアーキテクチャで使用される相互接続技術の例は、イーサネット（登録商標）、バスバックプレーン、およびATM（セル）布地を含みます。 FEは、CE / FEの通信に使用されるものとは異なる技術を介して相互に接続されてもよいです。
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）のFEは、ネットワーク接続を確立するために必要な機能の最小セット（例えば、インタフェース発見、ポートアップ/ダウン機能）をサポートしなければなりません。この最小セット以外にも、のForCESアーキテクチャは、FEには含まれていてもよいの能力の種類や数字を制限してはいけません。
3) Packets MUST be able to arrive at the NE by one FE and leave the NE via a different FE.
3）パケットは、一FEによって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は、単一の機能装置の外観をサポートしなければなりません。それは関係なく、それが通過するどのように多くのFEの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）アーキテクチャは、NEを接合から不正のForCESプロトコル要素を防ぐための方法を提供しなければなりません。 （より多くのプロトコルの詳細については、セクション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）A FEは非同期でFEに利用可能な資源や能力に障害または増加/減少のCEを知らせることができなければなりません。このように、FEは、エラーの監視と報告をサポートしなければなりません。 （FESとのPFEとの間の厳密な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フェイルオーバーのためのメカニズムをサポートしなければなりません。これは、それらの間の関連付け、関連かつ効率的な状態（再）同期メカニズムを回復する能力の損失があるときを決定するためにCEとFEのための能力を含みます。これはまた、FEは、パケットを転送し続けるか、動作を停止するかどうかかどうか、例えば、そのCEに関連の損失に反応してかかるFEアクションを予め設定する能力を含みます。
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）のFEは、RIP、OSPFメッセージなどの制御パケットを（）リダイレクトできなければならないCEへのインターフェイス宛て。彼らはまた、CEに（例えば、ルータ警告オプションが設定されているものなど、例えば、）他の関連するパケットをリダイレクトしなければなりません。 CEはFEでのパケットリダイレクション情報/フィルタを設定できなければなりません。 CEは、パケットを作成し、そのFEには、それらを提供していことができなければなりません。
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.
[RFC1812]で定義されるように9）の任意の提案のForCESアーキテクチャは、そのアーキテクチャは、ルータ機能の全てをサポートする方法を説明しなければなりません。 IPv4の転送機能RFC 1812で定義されたようなIPヘッダの検証、実行、最長プレフィックス一致アルゴリズム、TTLの減少、チェックサム計算、ICMPエラーメッセージの発生等を説明すべきです。
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）のForCESのNEは、CE（複数可）NEでのFEが接続されるトポロジーを知ることができなければなりません。
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アーキテクチャ（すなわち、複数のFEと数十ポートの数千のの少なくとも何百時）に拡張しなければならない支持できなければなりません。
12) The ForCES architecture MUST allow FEs AND CEs to join and leave NEs dynamically.
12）のForCESアーキテクチャはのFEとCEが参加し、動的にNEを残すことを許容しなければなりません。
13) The ForCES NE architecture MUST support multiple CEs and FEs. However, coordination between CEs is out of scope of ForCES.
13）のForCESのNEアーキテクチャは、複数のCEとFEをサポートしなければなりません。しかし、CE間の連携は、力の範囲外です。
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）前会合相セットアップ、モニタリング、構成の問題のためには、CEとFEのための標準的な管理メカニズムを使用することが有用であり得ます。 ForCESアーキテクチャと要件は、これを排除するものではありません。一般的には、ポスト会合相のために、ほとんどの管理タスクは、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.管理ツール（例えば、SNMP）のための能力は、FEの状態が排除されるべきではない読み取り（ただし変更しない）ために使用されます。 2. CEが通知されることなく、全体的なNEの動作に影響を与えた方法でFEの状態を変更するための管理ツール（例えば、SNMPなど）のために可能にすることはできません。
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の機能の様々なCEのための潜在的な問題を提起します。効果的にFEを制御するCEためには、CEは、FEがパケットを処理する方法を理解する必要があります。したがって、我々は、FEモデルがFEの論理的なパケット処理能力を表現できるように作成する必要があります。このモデルは、FE能力を記述を強制プロトコルで使用される（セクション6を参照して、要件＃1）。 FEモデルは、能力モデルとデバイスの現在の構成を表現する状態モデル、の両方を定義しなければなりません。 FEモデルは、NEアーキテクチャの複数のFEをサポートしなければなりません。
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モデルがサポートしなければならない論理関数の最小セットを定義します。
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にこれらが別々の論理機能として実装することかもしれないが、例えば、特定のFEに転送論理機能は、ネクストホップIPアドレスとネクストホップのMACアドレスの両方についての情報を持っているかもしれません。別の例は、伝統的/アウトバウンドNAT、双方向NAT、二度NAT、およびマルチホームNAT [RFC2663]などのいくつかの味を有することができるNAT機能であろう。モデルは、関数におけるこのような変化を可能にするのに十分に柔軟でなければなりません。
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機能は、ドメインを出て行くパケットの転送決定（、彼らのプライベートアドレスの後に実行されます）公共のものに置き換えられます。
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モデルは、新たな論理機能および新しい分類、アクション、およびパラメータデータを容易に追加することができる柔軟なインフラストラクチャを提供しなければなりません。また、FEモデルは、各論理機能によって収集された統計のタイプを記述することができなければなりません。
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モデルがサポートしなければならない論理機能の最小セットを定義します。この最小限のセットは、すべてのFEは、この機能を提供しなければならないことを意味するものではありません。代わりに、これらの要件は唯一のモデルはFEには、提供することを選択するかもしれな機能を発現することが可能でなければならないことを指定します。
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モデルは、デバイス上のポートの数を表すことができなければなりません、各ポート（例えば、ポートタイプ、リンク速度）の静的属性、および各ポートの構成可能な属性（例えば、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モデルは、転送決定を行うために転送機能で使用することができるデータを表現できなければなりません。 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）QoSは、FEモデルは、FEは、例えば、計量、ポリシング、シェーピング、およびキューイング機能の点で、そのQoS機能を発現することを可能にしなければならない機能です。 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モデルは、フィルタリング機能の複雑な組を発現することが可能である必要がある関数。モデルは、FEのパケット処理機能の順序で任意の点で、これらの機能の存在を表現できなければなりません。 FEモデルは、単一のフィールド（例えば、宛先アドレス）から任意のnタプルの分類能力の広い範囲を表すことができなければなりません。同様に、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.
新しい、現在未知のFEの機能を発現することができるように5）ベンダー固有関数FEモデルは拡張可能であるべきです。 FEモデルは、独自の方法で標準/共通機能を発現するように拡張されるべきではありません。これは、対応の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 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).
6）ハイタッチ機能FEモデルは、FEのカプセル化とトンネリング機能を発現することができなければなりません。 FEモデルは、パケットが受信すべきサービス（すなわち、IPv4のヘッダのTOSオクテットまたはIPv6のトラフィッククラスオクテット）のクラスをマークする機能をサポートしなければなりません。 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モデルは、転送パス内のパケットに適用することができる暗号化の種類を表現できなければなりません。
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）オフロード機能単位のパケット処理（例えば、各パケットが与えるポリサーのトークンバケット占有率の状態を更新することができる、FE状態を残すことができ）。また、FEモデルは、FEにCEからロードオフの論理関数は、例えば、ある機能を実行するために、特定の有限状態機械によれば、パケット処理から非同期に実行することを可能にしなければなりません。 FEモデルは、これらの非同期の機能を発現することができなければなりません。このような関数の例としては、TCPの終了やOSPFのHello処理で必要とされる有限状態マシンの実行を含め、パケットのイベントによって、が、同様にタイマーイベントではないだけにトリガ。これは、FEモデルがFE上の既存のオフロード機能を表現することができるはずだけという、オフロードFEへのコードのどの部分を意味するものではありません。
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）IPFLOW / PSAMP機能な従量課金、トラフィックエンジニアリング、のようないくつかのアプリケーションは、ネットワーク・エレメントからのフローベースのIPトラフィックの測定を必要としています。 【IPFLOW】測定およびエクスポート、IPトラフィックフローを監視するためのアーキテクチャを定義します。 FEモデルは、計量機能を発現して、IPトラフィックのフロー情報をエクスポートするために必要な会計処理を流すことができるべきである（SHOULD）。同様に、測定ベースのアプリケーションをサポートするために、[PSAMP]統計及び他の方法でパケットのサブセットをサンプリングするために、ネットワーク要素の機能の標準セットを定義するためのフレームワークを記述する。 FEモデルは、パケット・サンプリング・アプリケーションをサポートするために必要な統計的なパケットフィルタリング機能とパケット情報を表現することができるべきです。
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 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.
1）モデル化要素の構成のForCESプロトコルはCEが各FEの能力を決定することを可能にしなければなりません。これらの機能は、その要件さらにセクション5で定義されているFEモデルを用いて表現されるべきであり、プロトコルは、CEがFEモデルによって発見されたすべての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.
セキュア通信aの2）のサポート）FEの設定は、ネットワーク（例えば、IPフォワーディングテーブル）の機能に重要な情報を含むことになります。このように、すべての力のプロトコルメッセージの完全性を確保し、man-in-the-middle攻撃から保護することは可能でなければなりません。 B）FE構成情報はまた、取引関係（例えば、サービスレベル契約）から得られた情報を含んでいてもよいです。そのため、情報の機密性のために、それは（プライベートに）すべての力プロトコルメッセージを確保することが可能でなければなりません。 C）認可CEとFEはNEに参加していることを確認すると、CEやFE偽装攻撃を防御するためには、のForCESアーキテクチャは、CEとFEのための認証手段を選択する必要があります。 D）いくつかの配備の力は、ボックスの物理的セキュリティに、中間マン、スヌーピング、および偽装攻撃が不可能であることを確実にバックプレーン、上ボックス内互いに接続CEとFEとの間に配備されることが期待されます。このようなシナリオではアーキテクチャはこれらの攻撃やプロトコルメカニズムを防御するために箱の物理的なセキュリティに頼ることができる力はオフにすることができます。 E）CEとFEがネットワークを介して接続されている場合には、セキュリティ・メカニズムは、そのような攻撃に対しての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プロトコル（すなわち、複数のFEと数十ポートの数千のの少なくとも何百時）に拡張しなければならない支持できなければなりません。例えば、FEまたはポート番号に対応するのForCESプロトコルフィールドのサイズは、必要最小限の数をサポートするのに十分な大きさでなければなりません。 NE内のFEまたはポートの数が大きくなるにつれて、この要件は、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）CEとFEが単一L3ルーティングホップを超えて分離されているマルチホップは、のForCESプロトコルが輸送目的のために十分な信頼性、セキュリティ、および輻輳制御（例えば、TCP、SCTP）を有する既存のRFC2914準拠L4プロトコルを利用するであろう。
5) Message Priority The ForCES protocol MUST provide a means to express the protocol message priorities.
5）メッセージの優先度のForCESプロトコルは、プロトコルメッセージの優先度を表現する手段を提供しなければなりません。
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プロトコルは、信頼性の様々なレベルを必要とする情報を搬送するために使用されます。私たちは意味、この要件では厳しいか堅牢な信頼性では、どの損失は、何の汚職、情報のいかなる再順序付けは、輸送ませんされていると、タイムリーに配信。 b）のようにリダイレクトされたパケットまたはパケットサンプリングなどの一部の情報またはペイロードは、強固な信頼性を必要としないかもしれない（損失をある程度許容することができます）。この種の情報については、力は極めて高い信頼性に制限されてはなりません。 C）このような（セクション6、（1で説明した）コンフィギュレーション情報、例えば、ACLは、FIBエントリ、またはFE能力情報）などのペイロードは、ミッションクリティカルであり、堅牢で信頼性のある様式で送達されなければなりません。したがって、この種の情報のために、力は内蔵プロトコルメカニズムを提供しなければなりませんのいずれか又は堅牢な/厳格な信頼性を達成するための信頼性の高いトランスポートプロトコルを使用します。 d）の情報の一部またはCEとのFEとの間の関連の損失を検出するために使用することができるようなハートビートパケットなどのペイロードは、（セクション6（8）を参照）、信頼性の高い配信の上に適時性を好むかもしれません。この種の情報については、力は極めて高い信頼性に制限されてはなりません。力がマルチホップIPネットワーク上で実施される場合、E）は、力が[RFC2914]準拠のトランスポートプロトコルを使用しなければならないという要件です。 F）のいずれかの基本的なリンクによって、上記（c）に指定されたタイプの重要な情報を搬送するときに力がかかるCEとFEとの間のイーサネットまたは細胞ファブリックとしてIPネットワーク上で実行されていない場合には、次に信頼性を依然として提供しなければなりません/ネットワーク/トランスポート層または内蔵プロトコルメカニズムによる。
7) Interconnect Independence The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 4, requirement #1)
7）のForCESプロトコルは相互接続技術の様々なサポートしなければならない独立インターコネクト。 （セクション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 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)
8）CE冗長またはCEフェイルオーバーのForCESプロトコルはCE冗長またはCEフェイルオーバーのためのメカニズムをサポートしなければなりません。これは、それらの間の関連付け、関連かつ効率的な状態（再）同期メカニズムを回復する能力の損失があるときを決定するためにCEとFEのための能力を含みます。これはまた、FE 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）パケットリダイレクション/ミラーリングA）のForCESプロトコルはCE及びその逆へのFEからのパケットをリダイレクトする方法を定義しなければなりません。パケットリダイレクションは、FEにリダイレクトされたパケットの任意の更なる処理を終了します。 B）のForCESプロトコルはCEにFEからのパケットをミラーリングする方法を定義しなければなりません。ミラーリングは、元のパケットが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.
リダイレクトまたはミラーリングすることができるパケットの例は、（例えば、RIP、OSPFメッセージなど）の制御パケットがインターフェイスまたは（例えば、ルータ警告オプションが設定されているもののような）他の関連パケット宛含みます。 ForCESプロトコルはまた、CEは、の動作を設定する）およびb）（上記）、各によって影響されたパケットを指定するための方法を定義しなければなりません。
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プロトコルで運ばれた情報は、インターFEトポロジー情報を有するそれらのFEは、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プロトコルはCEとFEが参加し、動的に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プロトコルをバンドルコマンドFEへのコマンドの順序集合群できなければなりません。コマンドのような各グループは、できるだけ少数のメッセージで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）非同期イベント通知のForCESプロトコルは、非同期的に、このような障害としてFE上のイベントのCEに通知したり、利用可能なリソースまたは機能に変更することができなければなりません。 （セクション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プロトコルはFEから（パフォーマンスを監視）CEは、統計情報を照会できるようにするための手段を提供しなければなりません。
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).
ForCESプロトコルを利用し15）CPU過負荷またはキューのオーバーフローに基づいてサービス拒否攻撃に対する保護（）システムは、CPUの過負荷やキューのオーバーフローに基づいてサービス拒否攻撃を使って攻撃することができます。プロトコルは、このような攻撃によって悪用される可能性が力はCEがFEを制御したり、適宜他のルータやシステムと通信できなくなることを引き起こします。 ForCESプロトコルは、したがって、そのような攻撃から保護するために使用することができるFE能力を制御するためのメカニズムを提供しなければなりません。力により操作しなければならないFE能力を検出し、攻撃パケットをドロップするだけでなく、有効であると思われるが、の一部とすることができるパケットのレートを制限するレートリミッタをインストールできるようにするために分類し、フィルタをインストールする能力、攻撃（例えば、偽のBGPパケット）。
[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のルータのための非公式の管理モデル"、RFC 3290、2002年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、 "制御負荷ネットワーク要素サービスの仕様"、RFC 2211、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.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、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、 "統合サービスネットワーク要素のための一般的な特性化パラメータ"、RFC 2215、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. Weisss、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 14, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 14、RFC 2914、2000年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3532] Anderson, T. and J. Buerkle, "Requirements for the Dynamic Partitioning of Switching Elements", RFC 3532, May 2003.
[RFC3532]アンダーソン、T.およびJ. Buerkle、 "スイッチング素子の動的パーティショニングの要件"、RFC 3532、2003年5月。
[IPFLOW] Quittek, et al., "Requirements for IP Flow Information Export", Work in Progress, February 2003.
[IPFLOW] Quittek、ら、 "IPフロー情報をエクスポートするための要件"、進歩、2003年2月での作業。
[PSAMP] Duffield, et al., "A Framework for Passive Packet Measurement ", Work in Progress, March 2003.
[PSAMP]ダフィールド、ら、「受動パケット測定のためのフレームワーク」が進歩、2003年3月に働いています。
See architecture requirement #5 and protocol requirement #2.
アーキテクチャ要件＃5とプロトコルの要件＃2を参照してください。
This document was written by the ForCES Requirements design team:
この文書は、のForCES要件のデザインチームによって書かれました：
Todd A. Anderson (Editor)
トッドA.アンダーソン（編集）
Ed Bowen IBM Zurich Research Laboratory Saumerstrasse 4 CH-8803 Rueschlikon Switzerland
エド・ボーエンIBMチューリッヒ研究所Saumerstrasse 4 CH-8803リュシュリコンスイス
Phone: +41 1 724 83 68 EMail: edbowen@us.ibm.com
電話：+41 1 724 83 68 Eメール：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
電話：940 565 2822 Eメール：rdantu@unt.edu
Avri Doria ETRI 161 Gajeong-dong, Yuseong-gu Deajeon 305-350 Korea
AvriドリアETRI 161 Gajeong洞、儒城区305から350韓国大田
EMail: avri@acm.org
メールアドレス：avri@acm.org
Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803
ラムゴパルノキア・リサーチセンター5、道端の道路、バーリントン、MA 01803
Phone: 1-781-993-3685 EMail: ram.gopal@nokia.com
電話：1-781-993-3685 Eメール：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アバイア社123、エッピング道路、ノースライド、NSW 2113、オーストラリア電話：+61 2 9352 8620 Eメール：muneyb@avaya.com
Margaret Wasserman Nokia Research Center 5 Wayside Road Burlington, MA 01803 Phone: +1 781 993 3858 EMail: margaret.wasserman@nokia.com
マーガレットワッサーマンノキア・リサーチセンター5道端の道路バーリントン、MA 01803電話：+1 781 993 3858 Eメール：margaret.wasserman@nokia.com
The authors would like to thank Vip Sharma and Lily Yang for their valuable contributions.
著者は、彼らの貴重な貢献のVIPシャルマとリリーヤンに感謝したいと思います。
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd Khosraviインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
電話：+1 503 264 0334 Eメール：hormuzd.m.khosravi@intel.com
Todd A. Anderson Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
トッドA.アンダーソンインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 712 1760 EMail: todd.a.anderson@intel.com
電話：+1 503 712 1760 Eメール：todd.a.anderson@intel.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。