[要約] RFC 6041は、Forwarding and Control Element Separation (ForCES)の適用性に関する声明であり、ForCESの目的と要約を提供しています。
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
転送および制御要素分離（Force）適用性声明
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.
転送および制御要素分離（Force）プロトコルは、IPルーターと同様のデバイスの制御要素と転送要素の間の相互接続の標準フレームワークとメカニズムを定義します。このドキュメントでは、力モデルとプロトコルの適用可能性について説明します。展開シナリオと機能の例と、力に不適切なドキュメントアプリケーションを提供します。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
転送および制御要素分離（Force）プロトコルは、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.
このドキュメントは、力メカニズムの適用可能性を定義しています。力が最も適切に適用される構成と設定の種類について説明します。このドキュメントでは、力が使用に適していないシナリオと構成についても説明しています。
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].
力の適用性声明の目的は、フォースモデル[RFC5812]およびトランスポートマッピング層[RFC5811]と併せてプロトコルをどのように使用できるかについて、フォースプロトコル[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].
力に関連する一連の概念は、「IP制御と転送の分離の要件」[RFC3654]および「転送および制御要素分離（力）フレームワーク」[RFC3746]に導入されました。これらの概念と力のプロトコル要素に関連する用語は、「転送および制御要素分離（力）プロトコル仕様」[RFC5810]で定義されています。
The reader is directed to these documents for the conceptual introduction and for definitions, including the following acronyms:
読者は、概念的な紹介と次の頭字語を含む定義のために、これらのドキュメントに向けられています。
o CE: control element
o CE：制御要素
o CEM: CE Manager
o CEM：CEマネージャー
o FE: forwarding element
o FE：転送要素
o FEM: FE Manager
o FEM：FEマネージャー
o ForCES: Forwarding and Control Element Separation protocol
o 力：転送および制御要素分離プロトコル
o LFB: Logical Function Block
o LFB：論理関数ブロック
o NE: ForCES network element
o NE：強制ネットワーク要素
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）は、コントロール要素と通信してジョブを実行する必要があります。ハイエンドルーターは、いくつかの処理要素（CE）に制御処理を分散することもあります。力は、このコミュニケーションを行うための標準的な方法を提供します。また、力は、プライマリ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 診断
o CE Redundancy or CE Failover
o CE冗長性またはCEフェールオーバー
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つ以上のCESとFESの間で発生するため、部隊プロトコル交換の最初のステップです。部隊は、CESとFESには、安全な方法でコミュニケーションを開始するのに十分な情報がすでにあると想定しています。Force Protocolは、CESとFESが互いに発見した後にのみ適用されます。力は、動的プロトコルを使用して発見が実行されたのか、単に静的構成を使用して実行されたのかについて仮定しません。これがどのように発生するかについてのいくつかの議論は、このドキュメントのセクション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.
関連段階では、CESとFESは互いに能力情報を交換します。たとえば、FESは、提供するインターフェイスポートの数と、各ポートの静的および構成可能な属性を表現します。
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.
初期構成に加えて、CESとFESは、力を使用して動的な構成の変更を交換します。たとえば、FESは、FEで利用可能なリソースまたは機能の増加/減少をCESに非同期に通知します。
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.
これに関連して、トポロジー情報は、パケット転送に関してFESが互いにどのように相互接続されているかに関連しています。トポロジの発見は、部隊プロトコルの範囲外です。実装は、独自のトポロジ発見方法を選択できます（たとえば、標準トポロジディスカバリープロトコルを使用したり、静的トポロジ構成ポリシーを適用したりできます）。トポロジが確立されると、力プロトコルを使用して、結果の情報をCESに送信できます。
ForCES is used to perform FE configuration. For example, CEs set configurable FE attributes such as IP addresses, etc. for their interfaces.
FE構成を実行するために力が使用されます。たとえば、CESは、インターフェイスにIPアドレスなどの構成可能なFE属性を設定します。
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ルーティングの計算から生じるパケット転送情報を提供できます。たとえば、CESはFESに転送テーブルの更新を送信して、転送の決定を下すことができます。FESは、転送テーブルミスが発生した場合にCESに通知する場合があります。力を使用して、等しいコストマルチパス（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とFES間の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とそれが制御するFESとの間のセキュリティ情報を交換することができます。たとえば、FEは力を使用して、IPセキュリティ（IPSEC）トンネルで使用できる暗号化の種類を表現する場合があります。CEは、そのようなトンネルを構成するために力を使用する場合があります。CESは、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.
力を使用してフィルタリング情報を使用できます。たとえば、FESは力を使用して、分類やアクションなどのフィルタリング関数を実行することができ、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は、アプリケーションレベルのゲートウェイ機能の構成用に特別に設計されていませんが、これはある種のアプリケーションレベルのゲートウェイの範囲にある可能性があります。
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.
診断情報を交換するために、CESおよびFESに力を使用できます。たとえば、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 Architectureには、力NEの複数の冗長CEとFESを可能にするメカニズムが含まれています。Force-Model LFB定義は、NE内で普遍的にユニークであるように、コンポーネント識別子を介して十分なコンポーネントの詳細を提供します。力プロトコルには、NE全体のトランザクションと原子性を促進するメカニズムが含まれています。
Given the above, it is possible to deploy redundant CEs and FEs that incorporate failover.
上記を考えると、フェールオーバーを組み込んだ冗長CESおよびFESを展開することが可能です。
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 コントロールの相互接続は、何らかの形のローカルバス、スイッチ、またはLANであり、信頼性が高く、密接に制御され、CESおよび/またはFESにも影響を与えない外部破壊の影響を受けにくいです。
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とFESが設定されたシャーシ。力は、同じ物理ボックス内のコンポーネントである制御要素と転送要素で構成される地域に適用されます。
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.
例：単一のコントロールブレードを備えたネットワーク要素と、すべて同じシャーシに存在し、イーサネットまたは周辺コンポーネントの相互接続（PCI）などの相互接続を共有します。この地域では、転送されるデータトラフィックの大部分は通常、力を制御するのと同じリンクを横断しません。
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.
Force Protocolは、さまざまなセキュリティレベルを可能にします[RFC5810]。安全な物理的環境の下で、または他の運用上の懸念（場合によってはパフォーマンスの問題）で動作する場合、オペレーターはCESとFES間のすべてのセキュリティ関数をオフにする場合があります。オペレーターがFESとCESの間のパスを確保することを決定すると、オペレーターはTMLが提供するオプションの1つから選択します。TMLによって提供されるセキュリティの選択は、力プロトコルの前協会前段階で有効になります。オペレーターは、CE-FE接続でTMLが提供するセキュリティサービスをすべて、一部、または使用することを選択することはできません。CE/FEノード認証サービスを提供するために力が必要であり、メッセージの整合性と機密性サービスを提供する場合があります。NEは、NEの展開で使用されるTMLの選択に応じて、IPSECまたは輸送層セキュリティ（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.
アーキテクチャの観点から見ると、力NEは単一のネットワーク要素です。例として、力が特に管理する必要があるルーターである場合、ルーターを管理する必要があるのと同じように、本質的に管理する必要があります。別の観点から、要素管理は、力を構成する個々のエンティティとインターフェイスを直接表示できます。ただし、これらのエンティティとインターフェイスで直接作成された要素管理の更新は、NEが使用するモデルで更新メカニズムが説明されていない限り、CESとFESの制御関係を損なう可能性があります。
From the ForCES Requirements [RFC3654], Section 4, point 4:
部隊要件[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に必要な新しい管理は必要ありません。NEへの管理インターフェイス上の管理コマンドはCEに到着し、CEとFESの間の力の相互作用を完了する必要がある場合があります。これは、そのようなコマンドの原子性に影響を与える可能性があり、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.
管理の観点から分解された要素のセットと見なされると、力NEは、より制御要素、転送要素、およびそれらの間のインターフェイスの1つのセットに分割されます。CEとFEの間のインターフェイス機能は、Force Protocolによって提供されます。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とFESの構成制御のための規定を作成します。これは、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マネージャーなど）は、先行協会からアサシエーション後の段階に移行するための情報を提供するための個々の力プロトコル要素に直接アクセスできる場合があります。
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.
Force Mib [RFC5813]は、力プロトコルに関連する情報をキャプチャする主に読み取り専用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:
より具体的には、Associationsと比較してForce Mibモジュールの情報には次のものが含まれます。
o identifiers of the elements in the association
o 協会の要素の識別子
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.
Element ManagerからFEを管理することは可能ですが、これに関連するいくつかの要件がForceの要件に含まれています。
From the ForCES Requirements [RFC3654], Section 4, point 14:
部隊要件[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. 管理ツール（SNMPなど）が、CEに通知されずに全体的なNEの動作に影響を与える方法でFEの状態を変更することは不可能であってはなりません。
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:
Force Framework [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.
（IPルーターである力の場合）RFC 1812 [RFC1812]は、「ルーターがSNMPによって管理可能でなければならない」ことも規定しています。一般に、アサシエーション後の段階では、単一の機能デバイスの外観をサポートするために、CEとの対話を通じてほとんどの外部管理タスク（SNMPを含む）を実行する必要があります。したがって、SNMPエージェントをCESによって実装し、FESによって受信されたSNMPメッセージをCESにリダイレクトすることをお勧めします。RFC 2741 [RFC2741]）で定義されているAgentXフレームワークは、CESがSNMPメッセージを処理するマスターエージェントの役割で行動する一方で、FESに存在するMIBオブジェクトにアクセスするためにSUBAGENTの役割に基づいて行動するようにここで適用できます。マスターエージェント（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]:
最初の力仕様の取り組みの範囲外ではありますが、Force Architectureには2つのエンティティが含まれます。CEマネージャー（CEM）とFEマネージャー（FEM）。フォースプロトコル仕様[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管理タスクを担当する論理エンティティ。これは、Pre-Asociation段階で特に、どの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管理タスクを担当する論理エンティティ。事前分類段階で使用され、FEがどのCE（S）が通信するかを決定します。
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の椅子とドキュメントシェパードであるJamal Hadi Salimに感謝します。エリアの広告であるエイドリアン・ファレルに。彼らのレビュー、コメント、励ましのために、この文書は決して完了しなかったかもしれません。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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] Doria、A.、Hadi Salim、J.、Haas、R.、Khosravi、H.、Wang、W.、Dong、L.、Gopal、R。、およびJ. Halpern、 "転送および制御要素の分離（Force）プロトコル仕様」、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] Hadi Salim、J。およびK. ogawa、「SCTPベースの輸送マッピング層（TML）の転送および制御要素分離（Force）プロトコルのための」、RFC 5811、2010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「転送および制御要素分離（Force）転送要素モデル」、RFC 5812、2010年3月。
[RFC5813] Haas, R., "Forwarding and Control Element Separation (ForCES) MIB", RFC 5813, March 2010.
[RFC5813] Haas、R。、「転送および制御要素分離（Force）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] Daniele、M.、Wijnen、B.、Ellison、M。、およびD. Francisco、「Agent Extensibility（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. Anderson、「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] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「転送および制御要素分離（Forces）フレームワーク」、RFC 3746、2004年4月。
Authors' Addresses
著者のアドレス
Alan Crouch Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Alan Crouch Intel 2111 NE 25th Avenue Hillsboro、または97124 USA
Phone: +1 503 264 2196
EMail: alan.crouch@intel.com
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
電話：1-503-264-0334メール：hormuzd.m.khosravi@intel.com
Avri Doria (editor) LTU Lulea University of Technology Sweden
Avri Doria（編集者）Ltu Lulea工科大学スウェーデン
Phone: +46 73 277 1788
EMail: avri@acm.org
Xin-ping Wang Huawei Beijing China
Xin-Ping Wang Huawei北京中国
Phone: +86 10 82836067
EMail: carly.wang@huawei.com
Kentaro Ogawa NTT Corporation 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
Kentaro Ogawa NTT Corporation 3-9-11 Midori-Cho Musashino-Shi、東京180-8585日本
EMail: ogawa.kentaro@lab.ntt.co.jp