この文書はRFC3654の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
この文書は転送と制御要素分離（ＦｏｒＣＥＳ）体系を紹介して、そして関
連した用語のセットを定義します。この文書はＩＰ（ＩＰｖ４、ＩＰｖ６な
ど）のネットワーキング装置の制御装置とデータ転送面を論理的に分離する
ための体系とモデルとプロトコルの必要条件も定義します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Definitions
2. 定義
3. Architecture
3. 体系
4. Architectural Requirements
4. 体系の必要条件
5. FE Model Requirements
5. ＦＥモデル必要条件
5.1. Types of Logical Functions
5.1. 論理的な機能の種類
5.2. Variations of Logical Functions
5.2. 論理的な機能の種類
5.3. Ordering of Logical Functions
5.3. 論理機能の順序
5.4. Flexibility
5.4. 柔軟性
5.5. Minimal Set of Logical Functions
5.5. 論理機能の最小セット
6. ForCES Protocol Requirements
6. ＦｏｒＣＥＳプロトコル必要条件
7. References
7. 参考文献
7.1. Normative References
7.1. 参照する参考文献
7.2. Informative References
7.2. 有益な参考文献
8. Security Considerations
8. セキュリティの考察
9. Authors' Addresses & Acknowledgments
9. 著者のアドレス＆謝辞
10. Editors' Contact Information
10. エディタの連絡情報
11. Full Copyright Statement
11. 著作権表示全文
1. Introduction
1. はじめに
An IP network element is composed of numerous logically separate
entities that cooperate to provide a given functionality (such as a
routing or IP switching) and yet appear as a normal integrated
network element to external entities. Two primary types of network
element components exist: control-plane components and forwarding-
plane components. In general, forwarding-plane components are ASIC,
network-processor, or general-purpose processor-based devices that
handle all data path operations. Conversely, control-plane
components are typically based on general-purpose processors that
provide control functionality such as the processing of routing or
signaling protocols. A standard set of mechanisms for connecting
these components provides increased scalability and allows the
control and forwarding planes to evolve independently, thus promoting
faster innovation.
ＩＰネットワーク要素は、（ルーティングやＩＰスイッチングの様な）機能
を供給して、外部の要素に標準的な統合ネットワーク要素として現われるた
めに協力する、多数の論理的に異なる要素で構成されています。ネットワー
ク要素に２つの主要なタイプが存在します：制御面要素と転送面要素。一般
に、転送面要素は、すべてのデータパスオペレーションを処理するＡＳＩＣ
かネットワークプロセッサか汎用プロセッサベースの装置です。逆に、制御
面要素は一般ににルーティングや信号プロトコル処理のような制御機能を供
給する汎用のプロセッサに基づいています。これらの要素を結ぶためのメカ
ニズムの水準セットがスケーラビリティを増やし、そして制御面と転送面で
独立な進展を可能にし、より速い革新を可能にします。
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. Definitions
2. 定義
Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on IP
networks, it is a device to which we can communicate using an IP
address; and on a switch fabric, it is a device to which we can
communicate using a switch fabric port number.
アドレス可能要素（ＡＥ） - ある接続技術下で直接接続可能な物理装置。例
えば、ＩＰネットワーク上で、これは我々がＩＰアドレスを使って通信でき
る装置です；そしてスイッチで、これは我々がスイッチのポート番号を使っ
て通信ができる装置です。
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.
物理転送要素（ＰＦＥ） - パケット毎の処理と扱いを供給するハードウェア
を含むＡＥ。このハードウェアはネットワークプロセッサやＡＳＩＣや多数
のチップラインカードや汎用プロセッサの単独ボックスを含むかもしれませ
ん（他のあるかもしれません）。
Physical Control Element (PCE) - An AE that includes hardware used to
provide control functionality. This hardware typically includes a
general-purpose processor.
物理制御要素（ＰＣＥ） - 制御機能を供給するハードウェアを含むＡＥ。
このハードウェアは一般に汎用プロセッサを含みます。
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.
転送要素（ＦＥ） - ＦｏｒＣＥＳプロトコルを実行する論理要素。ＦＥは、
ＦｏｒＣＥＳプロトコルによるＣＥによって指揮／制御としてパケット毎処
理と扱いを供給するため基礎ハードウェアを使います。ＦＥはシングルブレー
ド（あるいはＰＦＥ）か、ＰＦＥの分割か、多数のＰＦＥかもしれません。
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.
制御要素（ＣＥ） - ＦｏｒＣＥＳプロトコルを実装し、ＦＥにどのように
パケットを処理するべきかを指示するためにこれを使う、論理要素。ＣＥは
制御と信号プロトコルを実行するような機能を処理します。ＣＥはＰＣＥの
一部あるいはＰＣＥ全体から成り立つかもしれません。
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.
連携前段階 - ＦＥ管理者（下記参照）とＣＥ管理者（下記参照）が、どの
ＦＥとＣＥが同じネットワークの要素の一部であるべきか決定する期間。
どんなＰＦＥとＰＣＥの分割もこの段階で起こります。
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.
連携後段階 - ＦＥがどのＣＥを制御するか知り、その逆も成り立つ期間、
ＣＥとＦＥがお互いに通信を確立する期間を含みます。
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 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.
ＦｏｒＣＥＳ連携後段階プロトコル - 連携後段階にＣＥとＦＥ間の通信に使
うプロトコル。このプロトコルはＣＥとＣＥ間の通信やＦＥとＦＥ間の通信
やＦＥとＣＥ管理者間の通信には当てはまりません。ＦｏｒＣＥＳプロトコ
ルはＦＥがスレーブでＣＥがマスターとなるマスタースレーブプロトコルで
す。このプロトコルは通信チャンネルの管理（例えば、接続設立、定期確認）
と自己の制御メッセージを含みます。このプロトコルはひとつのプロトコル
かもしれないし、協調動作する多数のプロトコルかもしれません。
FE Model - A model that describes the logical processing functions of
a 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.
ＦＥ管理者 - 連携前段階で稼働し、どのＦＥがどのＣＥと通信士べきか決定
する責任がある論理要素。このプロセスはＣＥ探索と呼ばれ、そしてＦＥ管
理者が利用可能なＣＥの能力を学ぶのを伴うかもしれません。ＦＥ管理者は
どのＣＥを使うか決定するのに静的設定から連携前段階プロトコル（下記参
照）まで何でも使ってもよいです。しかしながら、この連携前段階プロトコ
ルは現在の範囲外です。論理要素として、ＦＥ管理者はこの章で示した他の
論理要素のどれとでも一緒になりえます。
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.
ＣＥ管理者 - 連携前段階で稼働して、ＣＥがどのＦＥと通信すべきか決定す
る責任がある論理要素。このプロセスはＦＥ探索と呼ばれ、そしてＣＥ管理
者が利用可能なＦＥの能力を学ぶのを伴うかもしれません。ＣＥ管理者はど
のＦＥを使うべきか決定するために静的設定から連携前段階プロトコル（下
記参照）まで何でも使ってもよいです。再び、この連携前段階プロトコルは
範囲から現在です。論理名エンティティーであって、ＣＥマネージャーが身
体的に他のこの章で言及された論理名エンティティーの（どれ・何・誰）と
でも一緒にされるかもしれません。
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.
連携前段階プロトコル - どのＣＥやＦＥを使うべきか決定するために使われ
るＦＥ管理者とＣＥ管理者間のプロトコル。連携前段階プロトコルがＣＥと
ＦＥの能力探索メカニズムを含むかもしれません。この能力探索プロセスが
ＦｏｒＣＥＳプロトコルの中で使われる何かと完全に独立してい（そして置
き換わらない）ことに注意してください（６章、必要条件＃１参照）。しか
しながら、２つの能力探索メカニズムは同じＦＥモデルを利用するかもしれ
ません（５章参照）。連携前段階プロトコルがこの文書でさらに論じられま
せん。
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 Protocol Element - A FE or 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.
高い接触能力 - この用語は、ＩＰヘッダ以外で見つかる以外のパケットの内
容やヘッダの内容に基づき行動する、転送者の能力に適用するでしょう。こ
れらの能力の例は、ＮＡＴ−ＰＴやファイアウォールやＬ７内容認識を含み
ます。
3. Architecture
3. 体系
The chief components of a NE architecture are the CE, the FE, and the
interconnect protocol. The CE is responsible for operations such as
signaling and control protocol processing and the implementation of
management protocols. Based on the information acquired through
control processing, the CE(s) dictates the packet-forwarding behavior
of the FE(s) via the interconnect protocol. For example, the CE
might control a FE by manipulating its forwarding tables, the state
of its interfaces, or by adding or removing a NAT binding.
ＮＥ体系の北主要要素はＣＥとＦＥと相互接続プロトコルです。ＣＥは信号
と制御プロトコル処理と管理プロトコル実装の責任があります。制御処理を
通して獲得された情報に基づいて、ＣＥは相互接続プロトコルによってＦＥ
のパケットを転送する行動を示します。例えば、ＣＥは転送テーブルやイン
ターフェースの状態やＮＡＴ結合の扱いや削除を通じてＦＥをコントロール
するかもしれません。
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.
ＦＥは転送面で動作し、パケット毎の処理と扱いの責任があります。制御面
と転送面に独立して進展することを許すことで、異なるタイプのＦＥが開発
できます−あるものは一般的な目的に、別のものはより専門的に。ＦＥが実
行できる機能はレイヤ３転送と測定とシェーピングとファイアウォールとＮ
ＡＴとカプセル化（例えば、トンネル）とカプセル解除と暗号化と課金など
を含みます。これらの機能のほとんどすべての組合せは実用的なＦＥで存在
しているかもしれません。
Below is a diagram illustrating an example NE composed of a CE and
two FEs. Both FEs and CE require minimal configuration as part of
the pre-configuration process and this may be done by FE Manager and
CE Manager respectively. Apart from this, there is no defined role
for FE Manager and CE Manager. These components are out of scope of
the architecture and requirements for the ForCES protocol, which only
involves CEs and FEs.
下にＣＥと２つのＦＥで構成されたＮＥの例を示します。ＦＥとＣＥの両方
で設定前処理の一部として最小限の設定を必要とします、そしてこれはそれ
ぞれＦＥ管理者とＣＥ管理者によってされるかもしれません。これ以外、Ｆ
Ｅ管理者とＣＥ管理者のために定義された役割がありません。これらの要素
はＦｏｒＣＥＳプロトコルの体系と必要条件の範囲外で、ＦｏｒＣＥＳプロ
トコルはＣＥとＦＥに関係するだけです。
--------------------------------
| NE |
| ------------- |
| | CE | |
| ------------- |
| / \ |
| / \ |
| / \ |
| / \ |
| ----------- ----------- |
| | FE | | FE | |
| ----------- ----------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
--------------------------------
| | | | | | | |
| | | | | | | |
4. Architectural Requirements
4. 体系の必要条件
The following are the architectural requirements:
次は体系の必要条件です：
1) CEs and FEs MUST be able to connect by a variety of interconnect
technologies. Examples of interconnect technologies used in current
architectures include Ethernet, bus backplanes, and ATM (cell)
fabrics. FEs MAY be connected to each other via a different
technology than that used for CE/FE communication.
1) ＣＥとＦＥは様々な相互接続技術で連結できなければなりません(MUST)。
現在の体系で使う相互接続技術の例はイーサネットやバスバックプレーンや
とＡＴＭ（セル）装置を含みます。ＦＥ同士はＣＥ／ＦＥ通信に使うのと異
なる技術で接続しているかもしれません(MAY)。
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) ＦＥがネットワーク接続性を確立することに必要な最小セットの能力をサ
ポートしなくてはなりません(MUST)（例えば、インタフェース探索、ポート
アップ／ダウン機能）。ＦｏｒＣＥＳ体系はＦＥが持つ能力のタイプや数を
最小セットを越えて指定してはなりません(MUST NOT)。
3) Packets MUST be able to arrive at the NE by one FE and leave the
NE via a different FE.
3) パケットは１つのＦＥからＮＥに到着し、他のＦＥからＮＥを離れなけれ
ばなりません(MUST)。
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) ＥＮは単一機能装置の存在をサポートしなくてはなりません(MUST)。例え
ば、ルータで、パケットのＴＴＬは通過するＦＥにかかわらずＮＥを通過す
る際に１回だけ減少するべきです。しかしながら、外部のエンティティー
（例えば、ＦＥ管理者とＣＥ管理者）が連携前から連携後段階に移行するた
めに情報を用意するため個別のＦｏｒＣＥＳプロトコル要素に直接のアクセ
スを持つかもしれません(MSY)。
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) 体系は無許可のＦｏｒＣＥＳプロトコル要素がＮＥに参加するのを妨げる
方法を供給しなくてはなりません(MUST)。（詳細は、６章必要条件＃２参照）。
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) ＦＥ上の非同時的な故障や利用可能な資源や能力の増加／減少を、ＦＥは
ＣＥに知らせることができなければなりません(MUST)。それで、ＦＥはエラー
監視と報告を支援しなくてはなりません(MUST)。（ＦＥとＰＦＥの間に厳密
な１対１対応がないので、ＦＥとその物理資源の間の関係が時間と共に変化
することは可能です）。例えば、物理ポートの数やＦＥに充てられたメモリ
の量が時間が経つと変化するかもしれません。ＣＥは、正確な方法でＦＥを
制御できるように、このような変更の知らせらを受取る必要があります。
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) 体系はＣＥ冗長性やＣＥ故障切替のメカニズムをサポートしなくてはなり
ません(MUST)。これはＣＥとＦＥが、いつ連携が失われたか決定できる能力
と、連携復活と状態再同期機構を含みます。これはまた、ＦＥがＣＥとの連
携が切れたときにとる動作をあらかじめ設定する能力を含みます、例えばＦ
Ｅがパケット転送を続けるか、運用を止めるかです。
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) ＦＥはインタフェース宛の（ＲＩＰやＯＳＰＦメッセージのような）制御
パケットをＦＥに転送できなければなりません(MUST)。ＦＥは他の適切なパ
ケット（例えば、ルータ警告オプションをもつパケット）もＣＥに転送しな
ければ(MUST)。ＣＥはＦＥにパケットを転送情報／フィルタを設定できなけ
ればなりません(MUST)。ＣＥはパケットを生成し、ＦＥがそれらを配達でき
なければなりません(MUST)。
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]で定義される全てのルータ機能
をどのよう体系がサポートするか説明しなくてはなりません(MUST)。ＩＰヘッ
ダ検証、最長プレフィックス一致アルゴリズム、ＴＴＬ減少、チェックサム
計算、ＩＣＭＰエラーメッセージ生成、など、ＲＦＣ１８１２で定義したＩ
Ｐｖ４転送機能が説明されるべきです。
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) ＦｏｒＣＥＳのＮＥで、ＣＥは、ＮＥでＦＥがどこに接続しているかの
トポロジを学習できなければなりません(MUST)。
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) ＦｏｒＣＥＳのＮＥ体系は、少なくとも数百のＦＥと数万のポートをサ
ポート（つまりスケールする）できなければなりません(MUST)。
12) The ForCES architecture MUST allow FEs AND CEs to join and leave
NEs dynamically.
12) ＦｏｒＣＥＳ体系はＦＥとＣＥの結合と動的なＮＥの分離を許さなくて
はなりません(MUST)。
13) The ForCES NE architecture MUST support multiple CEs and FEs.
However, coordination between CEs is out of scope of ForCES.
13) ＦｏｒＣＥＳのＮＥ体系は多数のＣＥとＦＥをサポートしなくてはなり
ません(MUST)。しかしながら、ＣＥ間の整合はＦｏｒＣＥＳの範囲外です。
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) 連携前段階組み立てで、監視と設定問題のために、ＣＥとＦＥの標準管
理メカニズムを使うことは有用かもしれません(MAY)。ＦｏｒＣＥＳ体系と必
要条件はこれを妨げません。一般に、連携後段階のために、たいていの管理
の仕事はＣＥとの相互作用を通してされるべきです(SHOULD)。ある特定の状
態（例えば、ＣＥ／ＦＥ切断）で、使われる管理ツール（例えば、ＳＮＭＰ）
で問題を診断し、そして修繕することを許すことは有用であるかもしれませ
ん。次のガイドラインは守られなくてはなりません(MUST)：
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.
1. ＦＥの状態を読む（変更しない）ために使われる管理ツール（例えばＳＮ
ＭＰ）の能力は妨げられるべきではありません(SHOULD NOT)。
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.
2. ＣＥへの通知なしで全体的なＮＥの行動を変化させるようなＦＥの状態変
更は管理ツール（例えば、ＳＮＭＰ）に可能であってはなりません(MUST
NOT)。
5. FE Model Requirements
5. ＦＥモデル必要条件
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.
ＦｏｒＣＥＳ体系が許すＦＥ機能の多種多様さはＣＥでの潜在的な問題を提
示します。ＣＥが効率的にＦＥを制御するために、ＣＥはどのようにＦＥが
パケットを処理するか理解しなくてはなりません。従って我々はＦＥモデル
がＦＥの論理的なパケット処理能力を表現できるように作られることを要求
します(REQUIRE)。このモデルはＦＥ能力を記述するためためにＦｏｒＣＥＳ
プロトコルで使われるでしょう（６章、必要条件#1参照）。ＦＥモデルは能
力モデルと装置の現在の設定を示す状態モデルの両方を定義しなくてはなり
ません(MUST)。ＦＥモデルはＮＥ体系で多数のＦＥをサポートしなくてはな
りません(MUST)。
5.1. Types of Logical Functions
5.1. 論理的な機能の種類
The FE model MUST express what logical functions can be applied to
packets as they pass through a FE. Logical functions are the packet
processing functions that are applied to the packets as they are
forwarded through a FE. Examples of logical functions are layer 3
forwarding, firewall, NAT, and shaping. Section 5.5 defines the
minimal set of logical functions that the FE Model MUST support.
ＦＥモデルは、パケットがＦＥを通過する時、パケットに何の論理的な機能
が適用できるか言い表さなくてはなりません(MUST)。論理機能は、それらが
ＦＥを通して転送される時、パケットに適用されるパケット処理機能です。
論理的な機能の例は３層での転送とファイアウォールとＮＡＴとシェーピン
グです。５.５章はＦＥモデルがサポートしなくてはならない(MUST)論理的
な機能の最小のセットを定義します。
5.2. Variations of Logical Functions
5.2. 論理的な機能の種類
The FE model MUST be capable of supporting/allowing variations in the
way logical functions are implemented on a FE. For example, on a
certain FE the forwarding logical function might have information
about both the next hop IP address and the next hop MAC address,
while on another FE these might be implemented as separate logical
functions. Another example would be NAT functionality that can have
several flavors such as Traditional/Outbound NAT, Bi-directional NAT,
Twice NAT, and Multihomed NAT [RFC2663]. The model must be flexible
enough to allow such variations in functions.
ＦＥモデルは、ＦＥ上で論理的な機能を実装する様々な方法をサポート／許
すことができなくてはなりません(MUST)。例えば、あるＦＥで、転送論理機
能は次の転送先ＩＰアドレスと次の転送先ＭＡＣアドレスの両方の情報を持
つかもしれず、他のＦＥでこれらは別の論理機能として実装されるかもしれ
ません。他の例はＮＡＴ機能で、これは伝統的／アウトバンドＮＡＴや双方
向ＮＡＴや２倍ＮＡＴやマルチホームＮＡＴ[RFC2663]のようないくつかの種
類がありえます。モデルは機能でこのような違いを許すのに十分な柔軟性が
あるに違いありません。
5.3. Ordering of Logical Functions
5.3. 論理機能の順序
The model MUST be capable of describing the order in which these
logical functions are applied in a FE. The ordering of logical
functions is important in many cases. For example, a NAT function
may change a packet's source or destination IP address. Any number
of other logical functions (e.g., layer 3 forwarding, ingress/egress
firewall, shaping, and accounting) may make use of the source or
destination IP address when making decisions. The CE needs to know
whether to configure these logical functions with the pre-NAT or
post-NAT IP address. Furthermore, the model MUST be capable of
expressing multiple instances of the same logical function in a FE's
processing path. Using NAT again as an example, one NAT function is
typically performed before the forwarding decision (packets arriving
externally have their public addresses replaced with private
addresses) and one NAT function is performed after the forwarding
decision (for packets exiting the domain, their private addresses are
replaced by public ones).
モデルはこれらの論理機能がＦＥで適用される順序を記述することができな
くてはなりません(MUST)。論理機能の順序は多くの場合重要です。例えば、
ＮＡＴ機能がパケットのソースあるいは宛先ＩＰアドレスを変えるかもしれ
ません。他の論理機能（例えば、レイヤ３転送、入／出ファイアウォール、
シェーピング、課金）は決定時にソースや宛先ＩＰアドレスを利用するかも
しれません。ＣＥはこれらの論理機能のＩＰアドレスを、ＮＡＴ前かＮＡＴ
後か知る必要があります。さらに、モデルはＦＥ処理パスで、同じ論理機能
の複数利用を表現できなくてはなりません(MUST)。ＮＡＴを例にすると、１
つのＮＡＴ機能が一般的に転送決定の前に実行されます（外から到着してい
るパケットは、プライベートアドレスで置き換る公共アドレスを持ちます）、
そして１つのＮＡＴ機能が転送決定後に実行されます（ドメインから出るパ
ケットで、プライベートのアドレスは公共アドレスに置き換えられます）。
5.4. Flexibility
5.4. 柔軟性
Finally, the FE model SHOULD provide a flexible infrastructure in
which new logical functions and new classification, action, and
parameterization data can be easily added. In addition, the FE model
MUST be capable of describing the types of statistics gathered by
each logical function.
最終的に、ＦＥモデルは新しい論理機能と新しい分類と行動とパラメータデー
タが容易に加えられる柔軟なインフラを供給するべきです(SHOULD)。加える
に、ＦＥモデルはタイプのそれぞれの論理機能で増えた統計を記述できなく
てはなりません(MUST)。
5.5. Minimal Set of Logical Functions
5.5. 論理機能の最小セット
The rest of this section defines a minimal set of logical functions
that any FE model MUST support. This minimal set DOES NOT imply that
all FEs must provide this functionality. Instead, these requirements
only specify that the model must be capable of expressing the
capabilities that FEs may choose to provide.
この章の残りがどんなＦＥモデルでもサポートしなくてはならない(MUST)論
理機能の最小セットを定義します。この最小セットはすべてのＦＥがこの機
能性を供給しなくてはならないことを意味しません(DOES NOT)。代わりに、
これらの必要条件は、ＦＥが供給するかもしれない能力をモデルが表現でき
なくてはならないことを明示するだけです。
1) Port Functions
1) ポート機能
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).
ＦＥモデルは装置の多数のポートと、各ポートの静的属性（例えば、ポート
種別、リンク速度）と、各ポートの設定可能な属性（例えば、ＩＰアドレス、
管理状態）を表現できなくてはなりません(MUST)。
2) Forwarding Functions
2) 転送機能
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.
ＦＥモデルは転送機能が転送決定に使えるデータを表現できなくてはなりま
せん(MUST)。ＩＰｖ４とＩＰｖ６ユニキャストに対する支持とマルチキャス
ト転送機能がモデルによって供給されなくてはなりません(MUST)。
3) QoS Functions
3) 品質機能
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].
ＦＥモデルは、ＦＥが、例えば、測定やポリシングやシェーピングやキュー
イング機能に関するＱｏＳ能力を表現することを許さなくてはなりません
(MUST)。ＦＥモデルは[RFC2211]と[RFC2212]と[RFC2215]と[RFC2475]と
[RFC3290]で記述される、ＩｎｔＳｅｒｖやＤｉｆｆＳｅｒｖ機能を供給する
ためにこれらの機能の使用を表現できなくてはなりません(MUST)。
4) Generic Filtering Functions
4) 一般フィルタリング機能
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.
ＦＥモデルはフィルタ機能の複雑なセットを表現できなくてはなりません
(MUST)。モデルはＦＥのパケット処理機能列の任意の点でこれらの機能の存
在を表現することができなければなりません(MUST)。ＦＥモデルはひとつの
フィールド（例えば、宛先アドレス）から任意のｎ項組みまで広範囲の分類
能力を表現できなくてはなりません(MUST)。同様に、ＦＥモデルはフィルタ
機能が分類に一致するパケットに何の動作を行うことができるか言い表すこ
とができなくてはなりません(MUST)。
5) Vendor-Specific Functions
5) ベンダ固有機能
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.
ＦＥモデルは、新しい、現在未知のＦＥ機能が表現できるように、拡張可能
であるべきです(SHOULD)。ＦＥモデルは標準／一般機能を独占的に表現する
ように拡張されるべきではありません(SHOULD NOT)。これはＦｏｒＣＥＳ準
拠ではないでしょう(NOT)。
6) High-Touch Functions
6) 上位機能
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).
ＦＥモデルはＦＥのカプセル化とトンネル能力を表現できなくてはなりませ
ん(MUST)。ＦＥモデルはパケットが受けるべきサービスクラス（すなわち、
ＩＰｖ４ヘッダのＴＯＳオクテットあるいはＩＰｖ６トラフィッククラスオ
クテット）を印す機能をサポートしなくてはなりません(MUST)。ＦＥモデル
は他の上位機能をサポートするかもしれません（例えば、ＮＡＴ、ＡＬＧ）
(MAY)。
7) Security Functions
7) セキュリティ機能
The FE model MUST be capable of expressing the types of encryption
that may be applied to packets in the forwarding path.
ＦＥモデルは転送パスでパケットに適用されるかもしれない暗号の種類を表
現することができなくてはなりません(MUST)。
8) Off-loaded Functions
8) 機能移転
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.
パケット毎の処理が状態をＦＥに残すことができます、それでパケット処理
の間に実行する論理機能が矛盾のない動作が可能です（例えば、各パケット
がポリシに従ってトークンバケットの状態を更新するかもしれません）。加
えて、ＦＥモデルは、ある有限状態遷移機械に従って、例えばＣＥからＦＥ
に渡される機能を実行するために、論理機能のパケット処理と非同期の実行
を許さなければなりません(MUST)。ＦＥモデルはこれらの非同期機能を表現
できなくてはなりません(MUST)。このような機能の例は、パケットイベント
やタイマーイベントによって引き起こされたＴＣＰ終了やＯＳＰＦ挨拶処理
で必要とされる有限の状態遷移実行を含みます。これはＦＥに任意のコード
を移せる事を意味しません(Does NOT)、ＦＥモデルがＦＥ上の既存の機能を
表現することが可能であるべきです。
9) IPFLOW/PSAMP Functions
9) ＩＰＦＬＯＷ／ＰＳＡＭＰ機能
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.
従量課金やトラヒックエンジニアリングのようないくつかのアプリケーショ
ンがネットワーク要素でのフローベースのＩＰトラフィック測定を必要とし
ます。[IPFLOW]はＩＰトラヒックフローのモニタと計測と出力の体系を定義
します。ＦＥモデルはＩＰトラヒック情報を出力するために必要な測定機能
とフロー課金を表現することが可能であるべきです(SHOULD)。同様に測定ベー
スのアプリケーションをサポートするために、[PSAMP]がネットワーク要素が
統計や他の方法でパケットの一部を抽出する能力の標準セットを定義する機
構を記述します。ＦＥモデルは統計パケットフィルタリング機能とパケット
サンプリングアプリケーションをサポートすることに必要なパケット情報を
表現可能であるべきです(SHOULD)。
6. ForCES Protocol Requirements
6. ＦｏｒＣＥＳプロトコル必要条件
This section specifies some of the requirements that the ForCES
protocol MUST meet.
この章はＦｏｒＣＥＳプロトコルが満たさなくてはならない(MUST)必要条件
のいくつかを指定します。
1) Configuration of Modeled Elements
1) モデル要素の設定
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.
ＦｏｒＣＥＳプロトコルはＣＥが各ＦＥの能力を決定することを許さなくて
はなりません(MUST)。これらの能力はその必要条件が５章で定義されるＦＥ
モデルを使って表現されるべきです(SHALL)。さらに、プロトコルはＣＥがＦ
Ｅモデルを通して発見されるすべてのＦＥ能力を制御する手段を供給しなく
てはなりません(MUST)。プロトコルは分類／行動項目とパラメータの設定／
削除と統計値問合せとイベントの登録と受信の追加／削除ができなければな
りません(MUST)。
2) Support for Secure Communication
2) 安全な通信のサポート
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.
a) ＦＥ設定はネットワーク動作の重要情報を含んでいるでしょう（例え
ば、ＩＰ転送テーブル）。それなので、すべてのＦｏｒＣＥＳプロト
コルメッセージの完全性を保証し、中間者攻撃から保護することが可
能であるに違いありません(MUST)。
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.
b) ＦＥ設定情報はビジネス関係から得られた情報を含んでいるかもしれ
ません（例えば、サービスレベル協定）。情報の機密性のために、す
べてのＦｏｒＣＥＳプロトコルメッセージを保護する（秘密にする）
ことは可能であるに違いありません(MUST)。
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.
c) 認証されたＣＥとＦＥがＮＥに参加していることを保証し、ＣＥある
いはＦＥをものまね攻撃から守るために、ＦｏｒＣＥＳ体系はＣＥと
ＦＥの認証の手段を選択しなくてはなりませんと(MUST)。
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.
d) ある製品でＦｏｒＣＥＳはボックス内のバックプレーン上でＣＥとＦ
Ｅ間を接続することが期待され、そして箱の物理安全管理が中間者攻
撃とものまね攻撃が不可能な事を保障します。このような場合に、Ｆ
ｏｒＣＥＳ体系はこれらの攻撃からの保護にボックスの物理的セキュ
リティに依存するかもしれません(MAY)、そしてプロトコルメカニズム
が停止されるかもしれません(May)。
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.
e) ＣＥとＦＥがネットワーク上で接続する場合、このような攻撃に対し
てＦｏｒＣＥＳプロトコルを守るセキュリティ機構が指定か選択され
なくてはなりません(MUST)。どんなＦｏｒＣＥＳのために使われたセ
キュリティ解決策でも、このような攻撃を扱う方法を指定しなくては
なりません(MUST)。
3) Scalability
3) スケーラビリティ
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.
ＦｏｒＣＥＳプロトコルは数百のＦＥと数千のポートをサポートする能力が
なくてはなりません(MUST)（つまり、スケールしなければならない）。例え
ば、ＦＥやポート番号に対応しているＦｏｒＣＥＳプロトコルフィールドの
大きさは最小の必要数をサポートするのに十分大きいべきです(SHALL)。この
必要条件は、ＦＥの数やＮＥのポート数の増加で、ＮＥの性能に関連してい
ません。
4) Multihop
4) マルチホップ
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.
ＣＥとＦＥが単一Ｌ３ルーティングホップを越えて分離される時、適切な信
頼性とセキュリティと混雑制御のため、ＦｏｒＣＥＳプロトコルは既存のＲ
ＦＣ２９１４準拠のＬ４プロトコル（例えば、ＴＣＰ、ＳＣＴＰ）を、輸送
目的のために利用するでしょう。
5) Message Priority
5) メッセージ優先度
The ForCES protocol MUST provide a means to express the protocol
message priorities.
ＦｏｒＣＥＳプロトコルはプロトコルメッセージ優先度を表現する手段を供
給しなくてはなりません。
6) Reliability
6) 信頼性
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.
a) ＦｏｒＣＥＳプロトコルはさまざまなレベルの信頼性を必要とする輸
送情報を使うでしょう。厳密か強靭な信頼性をかにより、この必要条
件は、損失なし、変造なし、転送情報の順序変更なし、タイムリーな
配達、の意味があります。
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.
b) リダイレクトされたパケットやパケットサンプリングのような、ある
情報はやペイロードは、強靭な信頼性を必要としないかもしれません
（損失の程度を大目に見ることができます）。この種類の情報のため
に、ＦｏｒＣＥＳは厳密な信頼性に制限されてはなりません(MUST NOT)。
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.
c) 設定情報、例えばＡＣＬやＦＩＢ項目や（６章（１）で記述された）
ＦＥ能力情報のようなペイロードは、不可欠な情報で、強靭で信頼で
きる方法で配達されなくてはなりません。それで、この種類の情報の
ために、ＦｏｒＣＥＳが組み込みのプロトコルメカニズムを供給する
か、あるいは信頼性が高い輸送プロトコルを強靭／厳密な信頼性を成
し遂げるために使わなくてはなりません(MUST)。
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.
d) ＣＥとＦＥの間に関係の損失を発見するために使われる確認パケット
のような（６章（８）参照）、ある情報やペイ路^度が信頼性が高い配
達よりタイムリーな方が好きであるかもしれません。この種類のイ情
報のために、ＦｏｒＣＥＳは厳密な信頼性に制限されてはなりません
(MUST NOT)。
e) When ForCES is carried over multi-hop IP networks, it is a
requirement that ForCES MUST use a [RFC2914]-compliant
transport protocol.
e) ＦｏｒＣＥＳが多ホップのＩＰネットワーク上で運ばれる時、Ｆｏｒ
ＣＥＳが[RFC2914]準拠輸送プロトコルを使わなくてはならない(MUST)
ことは必要条件です。
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.
f) ＣＥとＦＥ間のＦｏｒＣＥＳがイーサネットあるいはセル構造のよう
なＩＰネットワーク以外で走っている場合、基礎リンク／ネットワー
ク／輸送レイヤや組み込みプロトコルメカニズムによって、上記（ｃ）
で指定された種類の重大情報を運ぶ時、やはり信頼性が供給されなく
てはなりません(MUST)。
7) Interconnect Independence
7) 相互接続独立
The ForCES protocol MUST support a variety of interconnect
technologies. (refer to section 4, requirement #1)
ＦｏｒＣＥＳプロトコルはいろいろな相互接続技術をサポートしなくてはな
りません(MUST)。（４章、必要条件＃１参照）。
8) CE redundancy or CE failover
8) ＣＥ冗長性あるいはＣＥ故障切替
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)
ＦｏｒＣＥＳプロトコルはＣＥ冗長性あるいはＣＥ故障切替のメカニズムを
サポートしなくてはなりません(MUST)。これはＣＥとＦＥが相互間での連携
の損失を検出する能力と連携の再生能力とと効率的状態再同期メカニズムを
含みます。これは同じくＦＥが連携の損失時に行う行動の事前設定、例えば
ＦＥが転送を継続するか運用を停止するか、の能力を含みます。（４章、必
要条件＃７参照）。
9) Packet Redirection/Mirroring
9) パケットリダイレクト／ミラーリング
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.
a) ＦｏｒＣＥＳプロトコルはＦＥからＣＥにパケットをリダイレクトす
る方法を定義しなくてはなりません、逆も同様です(MUST)。パケット
リダイレクトがＦＥのりダイレクトされたパケットの任意の処理で終
結します。
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.
b) ＦｏｒＣＥＳプロトコルはＦＥからＣＥにパケットをミラーするパス
を定義しなくてはなりません(MUST)。ミラーリングは複写点でオリジ
ナルのパケットがＦＥによって処理され続ける間に、ＣＥへ送るため
のＦＥによるパケット複写を許します。
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.
リダイレクトされるかミラーされるかもしれないパケットの例は、インタフェー
ス宛の制御パケット（ＲＩＰやＯＳＰＦメッセージなど）や他の適切なパケッ
ト（ルータ警告オプションを持つもの）を含みます。ＦｏｒＣＥＳプロトコ
ルはＣＥが（上記）a)やb)の行動を設定する方法、どのパケットがそれぞれ
の効果があるか、を定義しなくてはならなりません(MUST)。
10) Topology Exchange
10) トポロジー交換
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).
ＦｏｒＣＥＳプロトコルあるいはＦｏｒＣＥＳプロトコルで運ばれた情報が
ＦＥ間のトポロジー情報を持つＦＥがＣＥにその情報を供給することを許さ
なくてはなりません(MUST)。
11) Dynamic Association
11) 動的連携
The ForCES protocol MUST allow CEs and FEs to join and leave a NE
dynamically. (refer to section 4, requirement #12)
ＦｏｒＣＥＳプロトコルはＣＥとＦＥが動的にＮＥに参加と離脱を許さなく
てはなりません(MUST)。（４章、必要条件＃１２参照）。
12) Command Bundling
12) コマンドをまとめること
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.
ＦｏｒＣＥＳプロトコルは、順序づけられたＦＥへのコマンドの集まりを、
まとめることができなければなりません(MUST)。このようなコマンドのグルー
プが可能な限少ないメッセージでＦＥに送られるべきです(SHOULD)。さらに、
プロトコルはコマンドグループが、全部実行されるか全く実行されないかの
意味を持つかどうか、明示する能力をサポートしなくてはなりません(MUST)。
13) Asynchronous Event Notification
13) 非同期イベント通知
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)
ＦｏｒＣＥＳプロトコルは故障や利用可能な資源や能力の変更のようなＦＥ
上の非同期イベントをＣＥに通知することができなければなりません(MUST)。
（４章、必要条件＃６参照）。
14) Query Statistics
14) 質問統計
The ForCES protocol MUST provide a means for the CE to be able to
query statistics (monitor performance) from the FE.
ＦｏｒＣＥＳプロトコルはＣＥがＦＥから統計（性能モニター）を尋ねるこ
とが手段を供給しなくてはなりません(MUST)。
15) Protection against Denial of Service Attacks (based on CPU
overload or queue overflow)
15) サービス妨害攻撃（ＣＰＵ過負荷やキューあふれ）に対する保護
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).
ＦｏｒＣＥＳプロトコルを利用しているシステムはＣＰＵ過負荷やキューあ
ふれに基づくサービス妨害攻撃を使って攻撃されえます。攻撃はＦｏｒＣＥ
Ｓプロトコルを利用し、ＦＥがＣＥを制御できないか、他のルータやシステ
ムと適切な通信が不可能にすることができます。従ってＦｏｒＣＥＳプロト
コルはこのような攻撃から保護するために使える、ＦＥ能力を制御するメカ
ニズムを供給しなくてはなりません(MUST)。ＦｏｒＣＥＳで操らなければな
らない(MUST)ＦＥ能力は、攻撃パケットの検出と廃棄のための分類とフィル
タリングの設定、正当に見えるが攻撃の一部であるパケット（例えば、偽Ｂ
ＧＰパケット）の転送率の制限を含みます。
7. References
7. 参考文献
7.1. Normative References
7.1. 参照する参考文献
[RFC3290] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
Informal Management Model for DiffServ Routers", RFC 3290,
May 2002.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, September
1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC
2215, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weisss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 14, RFC
2914, September 2000.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
7.2. Informative References
7.2. 有益な参考文献
[RFC3532] Anderson, T. and J. Buerkle, "Requirements for the Dynamic
Partitioning of Switching Elements", RFC 3532, May 2003.
[IPFLOW] Quittek, et al., "Requirements for IP Flow Information
Export", Work in Progress, February 2003.
[PSAMP] Duffield, et al., "A Framework for Passive Packet
Measurement ", Work in Progress, March 2003.
8. Security Considerations
8. セキュリティの考察
See architecture requirement #5 and protocol requirement #2.
体系必要条件＃５とプロトコル必要条件＃２を見てください。
9. Authors' Addresses & Acknowledgments
9. 著者のアドレス＆謝辞
This document was written by the ForCES Requirements design team:
この文書はＦｏｒＣＥＳ要求条件設計チームによって書かれました：
Todd A. Anderson (Editor)
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
Phone: 940 565 2822
EMail: rdantu@unt.edu
Avri Doria
ETRI
161 Gajeong-dong, Yuseong-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
Jamal Hadi Salim
Znyx Networks
Ottawa, Ontario
Canada
EMail: hadi@znyx.com
Hormuzd Khosravi (Editor)
Muneyb Minhazuddin
Avaya Inc.
123, Epping road,
North Ryde, NSW 2113, Australia
Phone: +61 2 9352 8620
EMail: muneyb@avaya.com
Margaret Wasserman
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Phone: +1 781 993 3858
EMail: margaret.wasserman@nokia.com
The authors would like to thank Vip Sharma and Lily Yang for their
valuable contributions.
著者は貴重な貢献に対してVip SharmaとLily Yangに感謝します。
10. Editors' Contact Information
10. エディタの連絡情報
Hormuzd Khosravi
Intel
2111 NE 25th Avenue
Hillsboro, OR 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
Phone: +1 503 712 1760
EMail: todd.a.anderson@intel.com
11. Full Copyright Statement
11. 著作権表示全文
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。