Internet Engineering Task Force (IETF) A. Crouch
Request for Comments: 6041 H. Khosravi
Category: Informational Intel
ISSN: 2070-1721 A. Doria, Ed.
LTU
X. Wang
Huawei
K. Ogawa
NTT Corporation
October 2010
Forwarding and Control Element Separation (ForCES)
Applicability Statement
Abstract
抽象
The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES.
転送と制御素子分離（のForCES）プロトコルは、IPルータと類似の装置内の制御要素及び転送要素間の相互接続のための標準的なフレームワークおよびメカニズムを定義します。この文書では、我々はのForCESモデルとプロトコルの適用性を説明します。私たちは力を不適切である例の展開シナリオや機能性だけでなく、文書のアプリケーションを提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6041.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6041で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Purpose .........................................................4
3. Terminology .....................................................4
4. Applicability to IP Networks ....................................4
4.1. Applicable Services ........................................5
4.1.1. Association, Capability Discovery, and
Information Exchange ................................5
4.1.2. Topology Information Exchange .......................6
4.1.3. Configuration .......................................6
4.1.4. Routing Exchange ....................................6
4.1.5. QoS Capabilities Exchange and Configuration .........7
4.1.6. Security Exchange ...................................7
4.1.7. Filtering Exchange and Firewalls ....................7
4.1.8. Encapsulation/Tunneling Exchange ....................7
4.1.9. NAT and Application-Level Gateways ..................7
4.1.10. Measurement and Accounting .........................7
4.1.11. Diagnostics ........................................8
4.1.12. Redundancy and Failover ............................8
4.2. CE-FE Link Capability ......................................8
4.3. CE/FE Locality .............................................8
5. Security Considerations .........................................9
6. ForCES Manageability ............................................9
6.1. The NE as an Atomic Element ...............................10
6.2. The NE as Composed of Manageable Elements .................10
6.3. ForCES Protocol MIB .......................................10
6.3.1. MIB Management of an FE ............................11
6.4. The FEM and CEM ...........................................12
7. Contributors ...................................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the exchange of information between the logically separate functionality of the control and data forwarding planes of IP routers and similar devices. It focuses on the communication necessary for separation of control plane functionality such as routing protocols, signaling protocols, and admission control from data forwarding plane per-packet activities such as packet forwarding, queuing, and header editing.
転送と制御素子分離（のForCES）プロトコルは、IPルータと類似のデバイスの制御及びデータ転送プレーンの論理的に別個の機能との間の情報交換のための標準フレームワークおよびメカニズムを定義します。そのようなルーティングプロトコル、シグナリングプロトコル、およびそのようなパケット転送、キューイング、及びヘッダ編集などの平面パケットごとの活動を転送するデータからアドミッション制御などの制御プレーン機能を分離するために必要な通信に焦点を当てています。
This document defines the applicability of the ForCES mechanisms. It describes types of configurations and settings where ForCES is most appropriately applied. This document also describes scenarios and configurations where ForCES would not be appropriate for use.
この文書では、のForCESメカニズムの適用性を定義します。これは、力が最も適切に適用される構成と設定のタイプについて説明します。また、このドキュメントでは、軍が使用するために適切ではないシナリオと構成について説明します。
The purpose of the ForCES Applicability Statement is to capture the intent of the ForCES protocol [RFC5810] designers as to how the protocol could be used in conjunction with the ForCES model [RFC5812] and a Transport Mapping Layer [RFC5811].
ForCES適用ステートメントの目的は、プロトコルがのForCESモデル[RFC5812]とトランスポートマッピング・レイヤ[RFC5811]と組み合わせて使用することができる方法としてのForCESプロトコル[RFC5810]デザイナーの意図を捕捉することです。
A set of concepts associated with ForCES was introduced in "Requirements for Separation of IP Control and Forwarding" [RFC3654] and in "Forwarding and Control Element Separation (ForCES) Framework" [RFC3746]. The terminology associated with these concepts and with the protocol elements in ForCES is defined in the "Forwarding and Control Element Separation (ForCES) Protocol Specification" [RFC5810].
力で関連する概念のセットは[RFC3654]と「転送および制御素子分離（のForCES）フレームワーク」[RFC3746]に「IP制御および転送の分離のための要件」に導入しました。これらの概念を用いて、強制的にプロトコル要素に関連付けられている用語は、「転送と制御素子分離（のForCES）プロトコル仕様」[RFC5810]で定義されています。
The reader is directed to these documents for the conceptual introduction and for definitions, including the following acronyms:
読者は、概念の導入のために、以下の頭字語を含む定義するためにこれらの文書を対象とします。
o CE: control element
CE：制御要素
o CEM: CE Manager
O CEM：CEマネージャ
o FE: forwarding element
O FE：転送要素
o FEM: FE Manager
FEM O：FEマネージャー
o ForCES: Forwarding and Control Element Separation protocol
O強制：転送と制御素子分離プロトコル
o LFB: Logical Function Block
O LFB：論理機能ブロック
o NE: ForCES network element
Oはありません：強制的にネットワーク要素を
o TML: Transport Mapping Layer
O TML：トランスポートのマッピング・レイヤー
This section lists the areas of ForCES applicability in IP network devices. Some relatively low-end routing systems may be implemented on simple hardware that performs both control and packet forwarding functionality. ForCES may not be useful for such devices.
このセクションでは、IPネットワーク機器の力の適用性の領域を示しています。いくつかの比較的低いエンドルーティングシステムは、制御及びパケット転送機能の両方を実行する単純なハードウェア上に実装することができます。軍はこのようなデバイスのために有用ではないかもしれません。
Higher-end routing systems typically distribute work amongst several interface-processing elements, and these devices (FEs) therefore need to communicate with the control element(s) to perform their job. A higher-end router may also distribute control processing amongst several processing elements (CEs). ForCES provides a standard way to do this communication. ForCES also provides support for high-availability configurations that include a primary CE and one or more secondary CEs.
ハイエンドルーティングシステムは、典型的には、いくつかのインターフェース処理要素間で作業を分配し、これらのデバイス（FES）は、したがって、それらのジョブを実行するための制御要素（単数または複数）と通信する必要があります。ハイエンドルータは、いくつかの処理要素（CES）の間で制御処理を分散してもよいです。軍はこの通信を行うための標準的な方法を提供します。力は、一次CEと1つ以上の二次のCEを含む高可用性構成のサポートを提供します。
The remainder of this section lists the applicable services that ForCES may support, applicable FE functionality, applicable CE-FE link scenarios, and applicable topologies in which ForCES may be deployed.
このセクションの残りの部分は力がサポートすることができる適用可能なサービス、適用可能なFEの機能、適用可能なCE-FEリンクシナリオ、及び力が展開可能な適用トポロジを示しています。
In this section we describe the applicability of ForCES for the following control-forwarding-plane services:
このセクションでは、次のような制御転送プレーンサービスのための力の適用可能性を説明します。
o Association, Capability Discovery, and Information Exchange
O協会、能力の発見、および情報交換
o Topology Information Exchange
Oトポロジ情報交換
o Configuration
O構成
o Routing Exchange
Oルーティング交換
o Quality of Service (QoS) Exchange
Oサービス品質（QoS）の交換
o Security Exchange
証券取引O
o Filtering Exchange
Oフィルタリング交換
o Encapsulation/Tunneling Exchange
Oカプセル化/トンネリング交換
o NAT and Application-Level Gateways
O NATとアプリケーションレベルゲートウェイ
o Measurement and Accounting
O測定および会計
o Diagnostics
お ぢあｇのｓちｃｓ
o CE Redundancy or CE Failover
CE冗長またはCEフェイルオーバーO
Association is the first step of the ForCES protocol exchange in which capability discovery and exchange happens between one or more CEs and the FEs. ForCES assumes that CEs and FEs already have sufficient information to begin communication in a secure manner. The ForCES protocol is only applicable after CEs and FEs have discovered each other. ForCES makes no assumption about whether discovery was performed using a dynamic protocol or merely static configuration. Some discussion about how this can occur can be found in Section 6.4 of this document.
アソシエーションは、能力発見及び交換は、1つまたは複数のCEとFEとの間に発生したの力プロトコル交換の最初のステップです。力はCEとFEが既に安全な方法で通信を開始するのに十分な情報を持っていることを前提としています。 CEとFEが互いを発見した後のForCESプロトコルにのみ適用されます。力が発見ダイナミックプロトコルまたは単に静的構成を用いて実行されたかどうかについての仮定をしません。これが発生する可能性があります方法についていくつかの議論はこのドキュメントのセクション6.4に記載されています。
During the association phase, CEs and FEs exchange capability information with each other. For example, the FEs express the number of interface ports they provide, as well as the static and configurable attributes of each port.
互いに関連付け段階中、CEとFE交換能力情報。例えば、のFEは、それらが提供するインタフェースポートの数、並びに各ポートの静的及び設定可能な属性を表します。
In addition to initial configuration, the CEs and FEs also exchange dynamic configuration changes using ForCES. For example, FEs asynchronously inform the CEs of an increase/decrease in available resources or capabilities on the FE.
初期構成に加えて、CEとFEにも力を使用して動的な構成変更を交換します。例えば、FEが非同期FE上の利用可能な資源や能力の増加/減少のCEのを知らせます。
In this context, topology information relates to how the FEs are interconnected with each other with respect to packet forwarding. Topology discovery is outside the scope of the ForCES protocol. An implementation can choose its own method of topology discovery (for example, it can use a standard topology discovery protocol or apply a static topology configuration policy). Once the topology is established, the ForCES protocol may be used to transmit the resulting information to the CEs.
この文脈では、トポロジー情報は、複数のFEは、パケット転送に関して互いに相互接続される方法に関する。トポロジ発見はのForCESプロトコルの範囲外です。実装は、（例えば、それは標準的なトポロジ発見プロトコルを使用するか、静的トポロジ設定ポリシーを適用することができる）トポロジー発見の独自の方法を選択することができます。トポロジーが確立されると、のForCESプロトコルはCEに得られた情報を送信するために使用されてもよいです。
ForCES is used to perform FE configuration. For example, CEs set configurable FE attributes such as IP addresses, etc. for their interfaces.
力はFEの設定を実行するために使用されます。例えば、CEは設定FEは、そのインタフェースのためなど、このようなIPアドレスなどの属性セット。
ForCES may be used to deliver packet forwarding information resulting from CE routing calculations. For example, CEs may send forwarding table updates to the FEs, so that they can make forwarding decisions. FEs may inform the CEs in the event of a forwarding table miss. ForCES may also be used to configure Equal Cost Multi-Path (ECMP) capability.
力は、CEルーティング計算から得られた情報を転送するパケットを送達するために使用され得ます。彼らは転送決定を行うことができるように、例えば、CEは、のFEに転送テーブルの更新を送信することができます。 FEが転送テーブルミスのイベントでのCEに通知することができます。軍はまた、イコールコストマルチパス（ECMP）機能を設定するために使用することができます。
ForCES may be used to exchange QoS capabilities between CEs and FEs. For example, an FE may express QoS capabilities to the CE. Such capabilities might include metering, policing, shaping, and queuing functions. The CE may use ForCES to configure these capabilities.
力はCEとFE間のQoS機能を交換するために使用することができます。例えば、FEはCEにQoS機能を発現することができます。このような機能は、計量、ポリシング、シェーピング、およびキューイング機能が含まれる場合があります。 CEは、これらの機能を設定するために力を使用することができます。
ForCES may be used to exchange security information between a CE and the FEs it controls. For example, the FE may use ForCES to express the types of encryption that it is capable of using in an IP Security (IPsec) tunnel. The CE may use ForCES to configure such a tunnel. The CEs would be responsible for the NE dynamic key exchanges and updates.
力は、CEとそれが制御するのFE間でセキュリティ情報を交換するために使用されてもよいです。例えば、FEは、IPセキュリティ（IPSec）トンネルで使用することが可能な暗号化の種類を表現するために力を使用してもよいです。 CEは、このようなトンネルを設定するための力を使用してもよいです。 CEは、NE、動的鍵交換と更新について責任を負うことになります。
ForCES may be used to exchange filtering information. For example, FEs may use ForCES to express the filtering functions, such as classification and action, that they can perform, and the CE may configure these capabilities.
力は、フィルタリング情報を交換するために使用されてもよいです。例えば、のFEは、彼らが行うことができる、そのような分類およびアクションとして、フィルタリング機能を発現させるために力を使用することができ、及びCEは、これらの機能を構成することができます。
ForCES may be used to exchange encapsulation capabilities of an FE, such as tunneling, and the configuration of such capabilities.
力は、このようなトンネリング、およびそのような機能の構成とFEのカプセル化機能を交換するために使用されてもよいです。
ForCES may be used to exchange configuration information for Network Address Translators. Whilst ForCES is not specifically designed for the configuration of application-level gateway functionality, this may be in scope for some types of application-level gateways.
力はネットワークアドレス変換の設定情報を交換するために使用することができます。力は、具体的に、アプリケーション・レベルのゲートウェイの機能の構成のために設計されていない一方で、これはアプリケーションレベルゲートウェイのいくつかのタイプの範囲であってもよいです。
ForCES may be used to exchange configuration information regarding traffic measurement and accounting functionality. In this area, ForCES may overlap somewhat with functionality provided by network management mechanisms such as the Simple Network Management Protocol (SNMP). In some cases, ForCES may be used to convey information to the CE to be reported externally using SNMP. A further discussion of this capability is covered in Section 6 of this document.
力はトラフィック測定および会計機能に関する設定情報を交換するために使用することができます。この領域では、力は、そのような簡易ネットワーク管理プロトコル（SNMP）などのネットワーク管理メカニズムによって提供される機能と多少重なっていてもよいです。いくつかのケースでは、力がSNMPを使用して外部に報告されるようにCEに情報を伝えるために使用することができます。この能力のさらなる議論は、このドキュメントのセクション6で覆われています。
ForCES may be used for CEs and FEs to exchange diagnostic information. For example, an FE can send self-test results to a CE.
力は、診断情報を交換するためにCEとFEのために使用することができます。例えば、FEはCEにセルフテストの結果を送信することができます。
The ForCES architecture includes mechanisms that allow for multiple redundant CEs and FEs in a ForCES NE. The ForCES-model LFB definitions provide sufficient component details via component identifiers to be universally unique within an NE. The ForCES protocol includes mechanisms to facilitate transactions as well as atomicity across the NE.
ForCESアーキテクチャはのForCES NEの複数の冗長CEとFEを可能にする機構を含みます。 ForCESモデルLFB定義は、NE内に普遍的に一意であるコンポーネント識別子を介して十分な成分の詳細を提供します。 ForCESプロトコルは、トランザクションならびにNE横切って原子性を容易にする機構を含みます。
Given the above, it is possible to deploy redundant CEs and FEs that incorporate failover.
上述した、フェイルオーバーを組み込ん冗長CEとFEを展開することが可能です。
When using ForCES, the bandwidth of the CE-FE link is a consideration, and cannot be ignored. For example, sending a full routing table is reasonable over a high-bandwidth link, but could be non-trivial over a lower-bandwidth link. ForCES should be sufficiently future-proof to be applicable in scenarios where routing tables grow to several orders of magnitude greater than their current size. However, we also note that not all IP routers need full routing tables.
力を使用する場合は、CE-FEリンクの帯域幅が考慮され、無視することはできません。例えば、完全なルーティングテーブルを送信することは、高帯域幅リンク上妥当であるが、低帯域幅リンクを介して非自明であってもよいです。力はルーティングテーブルが現在のサイズより大きい数桁にまで成長シナリオで適用されるのに十分に将来を保証する必要があります。しかし、我々はまた、必ずしもすべてのIPルータが完全なルーティングテーブルを必要とすることに注意してください。
ForCES is intended for environments where one of the following applies:
力は、以下のいずれかが適用される環境のために意図されています。
o The control interconnect is some form of local bus, switch, or LAN, where reliability is high, closely controlled, and not susceptible to external disruption that does not also affect the CEs and/or FEs.
O制御相互接続は、信頼性が厳密に制御さ、高い、またCEと/またはのFEには影響しない外部の破壊を受けにくいローカルバス、スイッチ、又はLAN、何らかの形です。
o The control interconnect shares its fate with the FE's forwarding function. Typically this is because the control connection is also the FE's primary packet forwarding connection, and so if that link goes down, the FE cannot forward packets anyway.
O制御相互接続は、FEの転送機能との運命を共有しています。制御接続はまた、FEの主要なパケット転送接続であるため、通常、これはある、となるように、リンクがダウンした場合、FEはとにかくパケットを転送することはできません。
The key guideline is that the reliability of the device should not be significantly reduced by the separation of control and forwarding functionality.
重要なガイドラインは、デバイスの信頼性が大幅に制御および転送機能を分離することによって低減されるべきではないということです。
Taking this into account, ForCES is applicable in the following CE/FE localities:
この点を考慮し、力は、次のCE / FEの地域に適用されます。
Single Box NE: chassis with multiple CEs and FEs set up. ForCES is applicable in localities consisting of control and forwarding elements that are components in the same physical box.
シングルボックスNE：設定し、複数のCEとFEとシャーシ。力は、同じ物理ボックス内の構成要素である制御および転送要素からなる地域で適用可能です。
Example: a network element with a single control blade, and one or more forwarding blades, all present in the same chassis and sharing an interconnect such as Ethernet or Peripheral Component Interconnect (PCI). In this locality, the majority of the data traffic being forwarded typically does not traverse the same links as the ForCES control traffic.
例：単一の制御ブレードを有するネットワーク要素、および1つまたは複数の転送ブレード、全て同じシャーシ内に存在すると、イーサネット（登録商標）または周辺コンポーネント相互接続（PCI）として相互接続を共有します。この地域では、一般的に転送されるデータトラフィックの大半はのForCES制御トラフィックと同じリンクを通過しません。
Multiple Box NE: separated CE and FE, where physical locality could be the same rack, room, or building; or long distances that could span across continents and oceans. ForCES is applicable in localities consisting of control and forwarding elements that are separated by a single hop or multiple hops in the network.
複数のボックスNE：分離CEとFE、物理的な地域が同じラック、部屋、または建物である可能性があります。大陸と海洋にまたがることができたり、長い距離。力は、ネットワーク内の単一ホップまたは複数のホップによって分離された制御および転送要素からなる地域で適用可能です。
The ForCES protocol allows for a variety of security levels [RFC5810]. When operating under a secured physical environment, or for other operational concerns (in some cases, performance issues), the operator may turn off all the security functions between CEs and FEs. When the operator makes a decision to secure the path between the FEs and CEs, then the operator chooses from one of the options provided by the TML. Security choices provided by the TML take effect during the pre-association phase of the ForCES protocol. An operator may choose to use all, some, or none of the security services provided by the TML in a CE-FE connection. A ForCES NE is required to provide CE/FE node authentication services, and may provide message integrity and confidentiality services. The NE may provide these services by employing IPsec or Transport Layer Security (TLS), depending on the choice of TML used in the deployment of the NE.
ForCESプロトコルは、セキュリティレベル[RFC5810]の多様を可能にします。セキュアな物理的環境の下で動作している場合、または他の動作の懸念のために（場合によっては、パフォーマンスの問題で）、オペレータは、CEとFEとの間のすべてのセキュリティ機能をオフにすることができます。オペレータが複数のFEとCEの間の経路を確保するための決定を行う場合、オペレータはTMLによって提供されるオプションのいずれかから選択します。 TMLによって提供されるセキュリティの選択肢はのForCESプロトコルの事前会合相の間に有効になります。オペレータは、CE-FE接続でTMLが提供するセキュリティサービスのすべて、一部、またはnoneを使用することもできます。 ForCES NEはCE / FEノード認証サービスを提供するために必要とされ、メッセージの完全性と機密性サービスを提供することができます。 NEは、NEの展開で使用TMLの選択に応じて、IPsecのまたはTransport Layer Security（TLS）を使用することによって、これらのサービスを提供することができます。
From the architectural perspective, the ForCES NE is a single network element. As an example, if the ForCES NE is specifically a router that needs to be managed, then it should be managed in essentially the same way any router should be managed. From another perspective, element management could directly view the individual entities and interfaces that make up a ForCES NE. However, any element management updates made directly on these entities and interfaces may compromise the control relationship between the CEs and the FEs, unless the update mechanism has been accounted for in the model used by the NE.
アーキテクチャの観点からは、のForCES NEは、単一のネットワーク要素です。 ForCES NEは、具体的に管理する必要のあるルータである場合の例としては、それは任意のルータが管理すべき本質的に同じ方法で管理されなければなりません。別の観点から、要素の管理は直接のForCES NEを構成する個々のエンティティとのインターフェイスを表示することができます。更新機構は、NEによって使用されるモデルにおいて考慮されていない限りしかし、これらのエンティティおよびインターフェース上で直接行われた要素管理更新は、CEとFEとの間の制御関係を危うくすることができます。
From the ForCES Requirements [RFC3654], Section 4, point 4:
ForCES要件[RFC3654]、セクション4から、点4：
A NE MUST support the appearance of a single functional device.
NEは、単一の機能装置の外観をサポートしなければなりません。
As a single functional device, a ForCES NE runs protocols, and each of the protocols has its own existing manageability aspects that are documented elsewhere. As an example, a router would also have a configuration interface. When viewed in this manner, the NE is controlled as a single routing entity, and no new management beyond what is already available for routers and routing protocols would be required for a ForCES NE. Management commands on a management interface to the NE will arrive at the CE and may require ForCES interactions between the CE and FEs to complete. This may impact the atomicity of such commands and may require careful implementation by the CE.
単一の機能デバイスとして強制しNEは、プロトコルを実行し、プロトコルのそれぞれが別の場所で文書化され、自身の既存の管理性の側面を持っています。例として、ルータはコンフィギュレーション・インターフェースを持っているでしょう。このように見た場合、NEは、単一のルーティングエンティティとして制御され、すでにルータおよびルーティングプロトコルのための利用可能なものを超えた新たな管理はのForCES NEのために必要とされないであろう。 NEへの管理インターフェイス上の管理コマンドは、CEに到着すると、完了するために、CEとFEとの間の力の相互作用を必要とするかもしれません。これは、そのようなコマンドのアトミック性に影響を与える可能性があるし、CEにより慎重な実装が必要な場合があります。
When viewed as a decomposed set of elements from the management perspective, the ForCES NE is divided into a set of one of more control elements, forwarding elements, and the interfaces between them. The interface functionality between the CE and the FE is provided by the ForCES protocol. A MIB module is provided for the purpose of gaining management information on the operation of the protocol described in Section 6.3 of this document.
管理の観点からの要素の分解集合として見た場合、のForCESのNEは、複数の制御要素、転送要素、およびそれらの間のインターフェイスのいずれかの組に分割されます。 CEとFEとの間のインタフェース機能をのForCESプロトコルによって提供されます。 MIBモジュールは、本書のセクション6.3に記載のプロトコルの動作の管理情報を獲得するために設けられています。
Additionally, the architecture makes provisions for configuration control of the individual CEs and FEs. This is handled by elements called the FE Manager (FEM) and the CE Manager (CEM). Specifically, from the ForCES Requirements RFC [RFC3654], Section 4, point 4:
さらに、アーキテクチャは、個々のCEとFEの構成制御のための規定を作ります。これは、FEマネージャ（FEM）とCEマネージャ（CEM）と呼ばれる要素によって処理されます。具体的に強制し要件RFC [RFC3654]、セクション4、ポイント4から：
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 the post-association phase.
しかし、外部エンティティ（例えば、FEマネージャおよびCEマネージャ）はポスト会合相に予め関連からそれらを移行するための情報を提供するために個々のForCESプロトコル要素に直接アクセスすることができます。
The ForCES MIB [RFC5813] defines a primarily read-only MIB module that captures information related to the ForCES protocol. This includes state information about the associations between CE(s) and FE(s) in the NE.
ForCES MIB [RFC5813]はのForCESプロトコルに関連する情報をキャプチャ主読み取り専用MIBモジュールを定義します。これは、NEのCE（S）及びFE（S）との間の関連についての状態情報を含みます。
The ForCES MIB does not include information that is specified in other MIB modules, such as packet counters for interfaces, etc.
などインターフェイスのパケットカウンタのような他のMIBモジュールで指定されたMIB情報を含まない力
More specifically, the information in the ForCES MIB module relative to associations includes:
より具体的には、関連付けに力のMIBモジュール相対の情報が含まれています。
o identifiers of the elements in the association
関連の要素の入出力識別子
o state of the association
関連のO状態
o configuration parameters of the association
関連のO構成パラメータ
o statistics of the association
協会の統計O
While it is possible to manage an FE from an element manager, several requirements relating to this have been included in the ForCES Requirements.
それがエレメントマネージャからFEを管理することが可能であるが、これに関連するいくつかの要件はのForCES要件に含まれています。
From the ForCES Requirements [RFC3654], Section 4, point 14:
ForCES要件[RFC3654]から、第4、ポイント14：
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.管理ツール（例えば、SNMP）のための能力は、FEの状態が排除されるべきではない読み取り（ただし変更しない）ために使用されます。
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. CEが通知されることなく、全体的なNEの動作に影響を与えた方法でFEの状態を変更するための管理ツール（例えば、SNMPなど）のために可能にすることはできません。
The ForCES Framework [RFC3746], Section 5.7, goes further in discussing the manner in which FEs should handle management requests that are specifically directed to the FE:
ForCESフレームワーク[RFC3746]、セクション5.7は、FEには特にFEに向けられている管理要求を処理する必要がありますする方法を議論する中で、さらに行きます：
(For a ForCES NE that is an IP router,) RFC 1812 [RFC1812] also dictates that "Routers must be manageable by SNMP". In general, for the post-association phase, most external management tasks (including SNMP) should be done through interaction with the CE in order to support the appearance of a single functional device. Therefore, it is recommended that an SNMP agent be implemented by CEs and that the SNMP messages received by FEs be redirected to their CEs. AgentX framework defined in RFC 2741 [RFC2741]) may be applied here such that CEs act in the role of master agent to process SNMP messages while FEs act in the role of subagent to provide access to the MIB objects residing on FEs. AgentX protocol messages between the master agent (CE) and the subagent (FE) are encapsulated and transported via ForCES, just like data packets from any other application layer protocols.
RFC 1812 [RFC1812]（IPルータでのForCES NEについて）また、「ルータは、SNMPによって管理可能でなければならない」と規定。一般に、ポスト会合相のために、（SNMPを含む）最も外部の管理タスクは、単一の機能装置の外観をサポートするためにCEとの相互作用を介して行われるべきです。したがって、SNMPエージェントは、CEのことでとのFEが受信したSNMPメッセージがそのCEにリダイレクトされることを実装することをお勧めします。 RFC 2741で定義されたのAgentXフレームワーク[RFC2741]）は、ここでサブエージェントの役割におけるフェス行為はのFEに存在するMIBオブジェクトへのアクセスを提供することながら、CEがSNMPメッセージを処理するマスターエージェントの役割で作用するように適用されてもよいです。マスターエージェント（CE）とサブエージェント（FE）との間のAgentXプロトコルメッセージは、他のアプリケーション層プロトコルのデータ・パケットのような力によってカプセル化され、輸送されます。
Though out of scope for the initial ForCES specification effort, the ForCES architecture includes two entities: the CE Manager (CEM) and the FE Manager (FEM). From the ForCES Protocol Specification [RFC5810]:
CEマネージャ（CEM）とFEマネージャ（FEM）：範囲外の初期のForCES仕様努力のためものの、のForCESアーキテクチャは、2つのエンティティを含んでいます。 ForCESプロトコル仕様[RFC5810]から：
CE Manager (CEM): A logical entity responsible for generic CE management tasks. It is particularly used during the pre-association phase to determine with which FE(s) a CE should communicate.
CEマネージャ（CEM）：一般的なCEの管理タスクを担当する論理エンティティ。特にCEが通信すべきFE（S）とを決定するために予め関連付け段階中に使用されます。
FE Manager (FEM): A logical entity responsible for generic FE management tasks. It is used during the pre-association phase to determine with which CE(s) an FE should communicate.
FEマネージャー（FEM）：一般的なFE管理タスクを担当する論理エンティティ。 CE（S）FEが通信すべきであると決定するために、事前関連付け段階中に使用されます。
Mark Handley was an initial author involved in the earlier versions of this document.
マーク・ハンドリーはこのドキュメントの以前のバージョンに関与した初期の著者でした。
Many of the participants in the ForCES WG, as well as fellow employees of the authors, have provided valuable input into this work. Particular thanks go to Jamal Hadi Salim, our WG chair and document shepherd; and to Adrian Farrel, the AD for the area; for their review, comments, and encouragement, without which this document might never have been completed.
強制しWGの参加者だけでなく、著者の仲間の従業員の多くは、この作業に貴重な入力を提供してきました。特定のおかげでジャマルハディサリム、私たちのWGいすとドキュメント羊飼いに移動します。そして、エイドリアン・ファレル、地域のためのADへ。この文書は完成されていない可能性があります決してなくても、レビュー、コメント、励まし、ため。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810]ドリア、A.、ハディサリム、J.、ハース、R.、Khosravi、H.、王、W.、ドン、L.、ゴパル、R.、およびJ.アルペルン、「転送および制御素子分離（のForCES）プロトコル仕様」、RFC 5810、2010年3月。
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, March 2010.
[RFC5811]ハディサリム、J.及びK.小川、 "転送および制御素子分離用SCTPベースのトランスポート・マッピング・レイヤ（TML）（のForCES）プロトコル"、RFC 5811、2010年月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812]アルペルン、J.およびJ.ハディサリム、 "転送および制御素子分離（のForCES）転送要素モデル"、RFC 5812、2010年3月。
[RFC5813] Haas, R., "Forwarding and Control Element Separation (ForCES) MIB", RFC 5813, March 2010.
[RFC5813]ハース、R.、 "転送と制御素子分離（のForCES）MIB"、RFC 5813、2010年3月。
[RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[RFC2741]ダニエル、M.、Wijnenの、B.、エリソン、M.、およびD.フランシスコ、 "エージェントの拡張機能（のAgentX）プロトコルバージョン1"、RFC 2741、2000年1月。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H.、およびT.アンダーソン、 "IP制御とフォワーディングの分離のための要件"、RFC 3654、2003年11月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746]ヤン、L.、Dantu、R.、アンダーソン、T.、およびR.ゴパル、 "転送および制御素子分離（のForCES）フレームワーク"、RFC 3746、2004年4月。
Authors' Addresses
著者のアドレス
Alan Crouch Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
アラン・クラウチインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 264 2196 EMail: alan.crouch@intel.com
電話：+1 503 264 2196 Eメール：alan.crouch@intel.com
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd Khosraviインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: 1-503-264-0334 EMail: hormuzd.m.khosravi@intel.com
電話：1-503-264-0334 Eメール：hormuzd.m.khosravi@intel.com
Avri Doria (editor) LTU Lulea University of Technology Sweden
Avriドリア（エディタ）技術スウェーデンのルーレオ大学LTU
Phone: +46 73 277 1788 EMail: avri@acm.org
電話：+46 73 277 1788 Eメール：avri@acm.org
Xin-ping Wang Huawei Beijing China
北京、中国のPingの王HU A IN- X
Phone: +86 10 82836067 EMail: carly.wang@huawei.com
電話：+86 10 82836067 Eメール：carly.wang@huawei.com
Kentaro Ogawa NTT Corporation 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
けんたろ おがわ んっｔ こｒぽらちおん ３ー９ー１１ みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: ogawa.kentaro@lab.ntt.co.jp
メールアドレス：ogawa.kentaro@lab.ntt.co.jp