[要約] RFC 3654は、IP制御と転送の分離に関する要件を定義しています。その目的は、ネットワークの柔軟性とスケーラビリティを向上させ、新しいサービスや技術の導入を容易にすることです。
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
IP制御と転送の分離の要件
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、転送および制御要素分離（Force）アーキテクチャを紹介し、関連する用語のセットを定義します。このドキュメントでは、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スイッチングなど）を提供するために協力する多数の論理的に個別のエンティティで構成されていますが、外部エンティティに通常の統合ネットワーク要素として表示されます。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つの主要な部分で構成されています。これらのコンポーネントは、相互に関連していますが、大部分が互いに独立した関数を実行します。一番下には、データフォワードプレーンで動作する転送パスがあり、パケットごとの処理と転送を担当します。転送面の上には、コントロールプレーンでの操作を担当するネットワークオペレーティングシステムがあります。ルーターまたはスイッチの場合、ネットワークオペレーティングシステムはルーティング、シグナリング、および制御プロトコル（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） - 力プロトコルを実装する論理的エンティティ。FESは、基礎となるハードウェアを使用して、パケットごとの処理と取り扱いを、Force Protocolを介してCEが指示/制御します。FESは、たまたま単一のブレード（または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） - 力プロトコルを実装し、それを使用してパケットの処理方法を1つ以上に指示する論理的エンティティ。CESは、制御プロトコルやシグナル伝達プロトコルの実行などの機能を処理します。CESは、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マネージャー（以下を参照）が同じネットワーク要素の一部であるかを決定している期間。このフェーズでは、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.
関連後の段階 - CEがそれを制御するためにCEがどの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).
力プロトコル - 全体の力アーキテクチャ内で使用される複数のプロトコルが存在する場合がありますが、「Force Protocol」という用語は、アソシエーションフェーズプロトコルの力のみを指します（以下を参照）。
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.
Association Post Association Phase Protocol-CESとFES間の関連性相通信に使用されるプロトコル。このプロトコルは、CE-CE-CE-CE-CE-To-Fe通信、またはFEマネージャーとCEマネージャー間の通信には適用されません。フォースプロトコルは、FESが奴隷であり、CESがマスターであるマスタースレーブプロトコルです。このプロトコルには、通信チャネルの管理（接続確立、ハートビートなど）とコントロールメッセージ自体の両方が含まれます。このプロトコルは、単一のプロトコルである可能性があるか、複数のプロトコルが一緒に動作する可能性があります。
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マネージャー - 連想前段階で動作し、CE（S）がどのFE Aが通信するかを決定する責任がある論理的エンティティ。このプロセスはCE Discoveryと呼ばれ、FEマネージャーが利用可能なCEの機能を学習することが含まれる場合があります。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マネージャー - 協会前の段階で動作し、CEがどのFe（s）が通信すべきかを決定する責任がある論理的エンティティ。このプロセスはFe Discoveryと呼ばれ、CEマネージャーが利用可能なFESの機能を学習することが含まれる場合があります。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.
事前関連フェーズプロトコル - 使用するCESまたはFESを決定するために使用されるFEマネージャーとCEマネージャーの間のプロトコル。前協会のフェーズプロトコルには、CEおよび/またはFE機能発見メカニズムが含まれる場合があります。この機能発見プロセスは、力プロトコル内で使用されるものとは完全に分離されている（および置き換えない）ことに注意してください（セクション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.
Force Network Element（NE） - 1つ以上のCESと1つ以上のFESで構成されるエンティティ。NE以外のエンティティにとって、NEは単一の管理ポイントを表します。同様に、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.
ハイタッチ機能 - この用語は、一部のフォワーダーで見つかった機能に適用して、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のパケットフォワードする動作を決定します。たとえば、CEは、転送テーブル、その界面の状態を操作するか、NAT結合を追加または削除することにより、FEを制御できます。
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を開発できます - 一部の汎用と他の目的はより専門化されています。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.
以下は、CEと2つのFESで構成されるNEの例を示す図です。FESとCEの両方は、構成前プロセスの一部として最小限の構成を必要とし、これはそれぞれFEマネージャーとCEマネージャーが実行できます。これとは別に、FEマネージャーとCEマネージャーには定義された役割はありません。これらのコンポーネントは、CESとFESのみを含む、Force Protocolのアーキテクチャと要件の範囲外です。
--------------------------------
| 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) CESとFESは、さまざまな相互接続テクノロジーによって接続できる必要があります。現在のアーキテクチャで使用されている相互接続技術の例には、イーサネット、バスバックプレーン、およびATM（セル）ファブリックが含まれます。FESは、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) FESは、ネットワーク接続を確立するために必要な最小限の機能セットをサポートする必要があります（たとえば、インターフェイスの発見、ポートアップ/ダウン機能）。この最小限のセットを超えて、Force ArchitectureはFESが含む可能性のある機能の種類または数を制限してはなりません。
3) Packets MUST be able to arrive at the NE by one FE and leave the NE via a different FE.
3) パケットは1つの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は、単一の機能デバイスの外観をサポートする必要があります。たとえば、ルーターでは、パケットのTTLは、通過するFESの数に関係なくNEを横断する場合に1回だけ減少する必要があります。ただし、外部のエンティティ（FEマネージャーやCEマネージャーなど）は、個々の力のプロトコル要素に直接アクセスして、提携前からアサシエーション後の段階に移行するための情報を提供する場合があります。
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に参加するのを防ぐ方法を提供する必要があります。（詳細については、セクション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は、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フェールオーバーのメカニズムをサポートする必要があります。これには、CESとFESがそれらの間に関連性が失われるか、関連性を回復する能力、効率的な状態（再）同期メカニズムを決定する能力が含まれます。これには、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は、CEへのインターフェイスにアドレス指定されたコントロールパケット（RIP、OSPFメッセージなど）をリダイレクトできる必要があります。また、他の関連するパケット（例：ルーターアラートオプションセットなど）をCEにリダイレクトする必要があります。CESは、FES上のパケットリダイレクト情報/フィルターを構成できる必要があります。また、CESはパケットを作成し、FESにそれらを配信させることもできなければなりません。
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) 提案された力のアーキテクチャは、[RFC1812]で定義されているように、そのアーキテクチャがすべてのルーター機能をどのようにサポートするかを説明する必要があります。IPv4転送機能などのIPヘッダー検証、最長のプレフィックスマッチアルゴリズム、TTLの減少、チェックサムの計算、ICMPエラーメッセージの生成などを実行するRFC 1812で定義されていることを説明する必要があります。
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（S）は、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）NEアーキテクチャは、少なくとも数百のFEおよび数万ポートをサポートできる（つまり、スケーリングする必要がある）必要があります。
12) The ForCES architecture MUST allow FEs AND CEs to join and leave NEs dynamically.
12）Force Architectureは、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）力NEアーキテクチャは、複数のCEとFESをサポートする必要があります。ただし、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に標準管理メカニズムを使用すると便利かもしれません。部隊の建築と要件はこれを排除しません。一般に、関連後の段階では、ほとんどの管理タスクは、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など）を使用して読み取る（変更しない）能力を排除すべきではありません。2.管理ツール（SNMPなど）が、CEに通知されずに全体的なNEの動作に影響を与える方法で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.
Force Architectureが許可するFe機能の多様性は、CESの潜在的な問題をもたらします。CEがFEを効果的に制御するためには、CEはFEがパケットをどのように処理するかを理解する必要があります。したがって、FEの論理パケット処理機能を表現できるFEモデルを作成する必要があります。このモデルは、FE機能を記述するためにフォースプロトコルで使用されます（セクション6、要件＃1を参照）。FEモデルは、デバイスの現在の構成を表現する機能モデルと状態モデルの両方を定義する必要があります。FEモデルは、NEアーキテクチャの複数のFESもサポートする必要があります。
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では、転送論理関数には次のホップIPアドレスと次のホップMACアドレスの両方に関する情報があり、別のFEでは、個別の論理関数として実装される場合があります。別の例は、従来の/アウトバウンドNAT、双方向NAT、2回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は、これらの論理関数をpre-natまたはpost-nat IPアドレスで構成するかどうかを知る必要があります。さらに、モデルは、FEの処理パスで同じ論理関数の複数のインスタンスを表現できる必要があります。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モデルがサポートする必要がある最小限の論理関数セットを定義します。この最小セットは、すべての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モデルは、デバイス上のポート数、各ポートの静的属性（ポートタイプ、リンク速度など）、および各ポートの構成可能な属性（例：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]に記載されているように、これらの機能の使用を表現することができなければなりません。
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.
5) ベンダー固有の機能FEモデルは、現在未知の新しいFE機能を表現できるように、拡張可能である必要があります。FEモデルは、独自の方法で標準/共通の関数を表現するために拡張すべきではありません。これは強制に準拠するものではありません。
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 OctetまたはIPv6トラフィッククラスOctet）をマークする機能をサポートする必要があります。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に状態を残す可能性があるため、パケット処理中に実行された論理関数は一貫した方法で実行できます（たとえば、各パケットは、Give Policerのトークンバケット占有率の状態を更新する場合があります）。さらに、FEモデルは、特定の有限状態マシンに従って、たとえばCEからFEまでオフロードされる関数を実行するために、特定の有限状態マシンに従って、パケット処理から非同期的に実行できるようにする必要があります。FEモデルは、これらの非同期機能を表現できる必要があります。このような機能の例には、パケットイベントだけでなく、タイマーイベントによってもトリガーされるTCP終了またはOSPF Hello Processingで必要な有限状態マシンの実行が含まれます。これは、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トラフィックフロー情報のエクスポートに必要な計量機能とフローアカウンティングを表現できる必要があります。測定ベースのアプリケーションをサポートするのと同様に、[PSAMP]は、統計的およびその他の方法でパケットのサブセットをサンプリングするネットワーク要素の標準の機能セットを定義するフレームワークを説明します。FEモデルは、パケットサンプリングアプリケーションをサポートするために必要な統計パケットフィルタリング機能とパケット情報を表現できるはずです。
This section specifies some of the requirements that the ForCES protocol MUST meet.
このセクションでは、Force Protocolが満たさなければならない要件の一部を指定します。
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) モデル化された要素の構成力プロトコルは、CESが各Feの機能を決定できるようにする必要があります。これらの機能は、セクション5で要件が定義されているFEモデルを使用して表現する必要があります。さらに、プロトコルは、CESが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.
2) 安全な通信のサポートA）FE構成には、ネットワークの機能に重要な情報（IP転送テーブルなど）が含まれます。そのため、すべての力のプロトコルメッセージの完全性を確保し、中間の攻撃から保護することが可能でなければなりません。b）FE構成情報には、ビジネス関係（サービスレベルの契約など）から得られた情報も含まれている場合があります。情報の秘密の性質のため、すべての力のプロトコルメッセージを保護（プライベート）することが可能である必要があります。c）認定されたCESとFESがNEに参加し、CEまたはFEのなりすまし攻撃に対して防御するために、Force ArchitectureはCESおよびFESの認証手段を選択する必要があります。d）いくつかの展開では、バックプレーンの上のボックス内で互いに接続されたCEとFESの間に力が展開されることが予想されます。ここでは、ボックスの物理的なセキュリティにより、中間の男、スヌーピング、およびなりすまし攻撃が不可能になることが保証されます。。このようなシナリオでは、フォースアーキテクチャは、これらの攻撃に対して防御するためにボックスの物理的セキュリティに依存する可能性があり、プロトコルメカニズムがオフになる可能性があります。e）CESとFESがネットワークに接続されている場合、そのような攻撃から力プロトコルを保護するセキュリティメカニズムを指定または選択する必要があります。力に使用されるセキュリティソリューションは、そのような攻撃をどのように扱うかを指定する必要があります。
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) スケーラビリティフォースプロトコルは、少なくとも数百のFESおよび数万ポートをサポートできる（つまり、スケーリングする必要があります）必要があります。たとえば、FEまたはポート番号に対応する力のプロトコルフィールドサイズは、必要な最小数をサポートするのに十分な大きさでなければなりません。この要件は、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) マルチホップCESとFESが単一のL3ルーティングホップを超えて分離されると、Force Protocolは、輸送目的で適切な信頼性、セキュリティ、輻輳制御（TCP、SCTPなど）を備えた既存のRFC2914準拠のL4プロトコルを使用します。
5) Message Priority The ForCES protocol MUST provide a means to express the protocol message priorities.
5) メッセージの優先順位勢力プロトコルは、プロトコルメッセージの優先順位を表現する手段を提供する必要があります。
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）力プロトコルは、さまざまなレベルの信頼性を必要とする情報を輸送するために使用されます。この要件における厳格または堅牢な信頼性により、私たちは、輸送されている情報の再注文なし、タイムリーに配達することを意味します。b）リダイレクトされたパケットやパケットサンプリングなど、一部の情報またはペイロードには、堅牢な信頼性が必要ない場合があります（ある程度の損失に耐えることができます）。この種の情報については、力を厳格な信頼性に限定してはなりません。c）構成情報などのペイロード、ACLS、FIBエントリ、またはFE機能情報（セクション6、（1）で説明）はミッションクリティカルであり、堅牢な信頼できる方法で配信する必要があります。したがって、この種の情報のために、力は組み込みプロトコルメカニズムを提供するか、堅牢/厳格な信頼性を達成するために信頼できる輸送プロトコルを使用する必要があります。d）CEとFESとFES間の関連性の喪失を検出するために使用できるハートビートパケットなどの情報またはペイロード（セクション6、（8）を参照）は、信頼できる配信よりも適時性を好む場合があります。この種の情報については、力を厳格な信頼性に限定してはなりません。e）マルチホップIPネットワークに力が運ばれる場合、力が[RFC2914]を使用する必要があることが要件です。f）CEとFEの間のイーサネットやセルファブリックなどのIPネットワーク上で力が走っていない場合、基礎となるリンクによって上記（c）で指定されたタイプの重要な情報を運ぶ場合、信頼性を提供する必要があります。/ネットワーク/輸送層または組み込みプロトコルメカニズムによる。
7) Interconnect Independence The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 4, requirement #1)
7) 相互接続の独立性勢力プロトコルは、さまざまな相互接続テクノロジーをサポートする必要があります。（セクション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フェールオーバーForce Protocolは、CE冗長性またはCEフェールオーバーのメカニズムをサポートする必要があります。これには、CESとFESがそれらの間に関連性が失われるか、関連性を回復する能力、効率的な状態（再）同期メカニズムを決定する能力が含まれます。これには、FEがCEへの関連性の喪失に反応して対応するアクションを事前セットする能力も含まれます。たとえば、Feがパケットを転送し続けるか、操作を停止するかどうか。（セクション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）フォースプロトコルは、パケットをFからCEにリダイレクトする方法を定義する必要があります。パケットリダイレクトは、FEでのリダイレクトパケットのさらなる処理を終了します。b）Force Protocolは、PackからCEまでのパケットをミラーリングする方法を定義する必要があります。ミラーリングにより、ミラーリングポイントでFEによって複製されたパケットをCEに送信できますが、元のパケットはFEによって処理され続けます。
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メッセージなど）が含まれます。Force Protocolは、CEがA）および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）トポロジ交換部隊のプロトコルまたは力プロトコルに携帯される情報は、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）動的関連Force Protocolは、CEと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）コマンドフォースバンドルフォースプロトコルは、順序付けられたコマンドのセットを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）非同期イベント通知フォースプロトコルは、使用可能なリソースや機能の障害や変更など、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）クエリ統計力プロトコルは、CEがFEから統計（監視パフォーマンス）を照会できるようにするための手段を提供する必要があります。
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）サービス拒否攻撃に対する保護（CPUの過負荷またはキューオーバーフローに基づく）Force Protocolを使用したシステムは、CPU過負荷またはキューオーバーフローに基づくサービス拒否攻撃を使用して攻撃できます。Force Protocolは、CEがFEを制御できなくなったり、他のルーターやシステムと適切に通信することができなくなるように、そのような攻撃によって活用される可能性があります。したがって、力プロトコルは、そのような攻撃から保護するために使用できる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.、Blake、S.、Grossman、D。、A。Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、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. Holdrege、「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] Anderson、T。およびJ. Buerkle、「スイッチング要素の動的分割の要件」、RFC 3532、2003年5月。
[IPFLOW] Quittek, et al., "Requirements for IP Flow Information Export", Work in Progress, February 2003.
[IPFlow] Quittek、et al。、「IPフロー情報エクスポートの要件」、2003年2月、進行中の作業。
[PSAMP] Duffield, et al., "A Framework for Passive Packet Measurement ", Work in Progress, March 2003.
[Psamp] Duffield、et al。、「パッシブパケット測定のフレームワーク」、2003年3月、進行中の作業。
See architecture requirement #5 and protocol requirement #2.
アーキテクチャ要件＃5およびプロトコル要件＃2を参照してください。
This document was written by the ForCES Requirements design team:
このドキュメントは、Force Reportion Design Teamによって書かれました。
Todd A. Anderson (Editor)
トッドA.アンダーソン（編集者）
Ed Bowen IBM Zurich Research Laboratory Saumerstrasse 4 CH-8803 Rueschlikon Switzerland
Ed Bowen Ibm Zurich Research Laboratory Saumerstrasse 4 CH-8803 Rueschlikon Switzerland
Phone: +41 1 724 83 68
EMail: edbowen@us.ibm.com
Ram Dantu Department of Computer Science University of North Texas, Denton, Texas, 76203
テキサス州デントンのノーステキサス州コンピュータサイエンス大学のラムダントゥ省、76203
Phone: 940 565 2822 EMail: rdantu@unt.edu
電話：940 565 2822メール：rdantu@unt.edu
Avri Doria ETRI 161 Gajeong-dong, Yuseong-gu Deajeon 305-350 Korea
Avri Doria Etri 161 Gajeong-Dong、Yousong-gu Deajeon 305-350 Korea
EMail: avri@acm.org
Ram Gopal
Nokia Research Center
5, Wayside Road,
Burlington, 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
Jamal Hadi Salim Znyx Networks Ottawa、オンタリオカナダ
EMail: 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、Epping Road、North Ryde、NSW 2113、Australia電話：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
マーガレットワッサーマンノキアリサーチセンター5ウェイサイドロードバーリントン、マサチューセッツ州01803電話：1 781 993 3858メール：margaret.wasserman@nokia.com
The authors would like to thank Vip Sharma and Lily Yang for their valuable contributions.
著者は、VIP SharmaとLily Yangの貴重な貢献に感謝したいと思います。
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro、または97124 USA
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Todd A. Anderson Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
トッドA.アンダーソンインテル2111 NE 25th Avenue Hillsboro、または97124 USA
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。