[要約] RFC 6369は、Forwarding and Control Element Separation (ForCES)の実装経験に関するドキュメントです。このRFCの目的は、ForCESの実装に関する情報を共有し、実装者が相互に学び合い、ForCESの進化を促進することです。
Internet Engineering Task Force (IETF) E. Haleplidis
Request for Comments: 6369 O. Koufopavlou
Category: Informational S. Denazis
ISSN: 2070-1721 University of Patras
September 2011
Forwarding and Control Element Separation (ForCES) Implementation Experience
要素の分離（力）の転送および制御実装の経験
Abstract
概要
The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol.
転送および制御要素分離（Force）プロトコルは、制御要素（CE）が転送要素（FE）の動作を制御できる標準的な通信および制御メカニズムを定義します。このドキュメントは、Force ProtocolとModelを実装した経験をキャプチャします。その目的は、力プロトコルを実装するための例と可能な戦略を提供することにより、他者を支援することです。
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/rfc6369.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6369で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
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.
信頼の法的規定のセクション4.Eで説明されているように、簡略化されたBSDライセンステキストを含め、簡素化されたBSDライセンスに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Pre-Association Setup - Initial Configuration . . . . . . 5
3.2. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Components . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Message Deserialization . . . . . . . . . . . . . . . 13
3.4.3. Message Serialization . . . . . . . . . . . . . . . . 15
4. Development Platforms . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). [RFC3654] defines the ForCES requirements, and [RFC3746] defines the ForCES framework.
転送および制御要素分離（Forces）は、コントロールプレーンとフォワードプレーン間の情報交換をForce Network Element（Force NE）との間の情報交換を標準化するためのアーキテクチャのフレームワークと関連するプロトコルを定義します。[RFC3654]は力の要件を定義し、[RFC3746]は力フレームワークを定義します。
The ForCES protocol works in a master-slave mode in which Forwarding Elements (FEs) are slaves and Control Elements (CEs) are masters. The protocol includes commands for transport of Logical Functional Block (LFB) configuration information, association setup, status, and event notifications, etc. The reader is encouraged to read the Forwarding and Control Element Separation Protocol [RFC5810] for further information.
Force Protocolは、転送要素（FES）が奴隷であり、制御要素（CE）がマスターであるマスタースレーブモードで機能します。プロトコルには、論理機能ブロック（LFB）構成情報、関連付け、ステータス、およびイベント通知などの輸送のコマンドが含まれています。読者は、詳細については転送および制御要素分離プロトコル[RFC5810]を読むことをお勧めします。
[RFC5812] presents a formal way to define FE LFBs using XML. LFB configuration components, capabilities, and associated events are defined when LFBs are formally created. The LFBs within the Forwarding Element (FE) are accordingly controlled in a standardized way by the ForCES protocol.
[RFC5812]は、XMLを使用してFE LFBを定義する正式な方法を提示します。LFB構成コンポーネント、機能、および関連するイベントは、LFBが正式に作成されたときに定義されます。それに応じて、転送要素（FE）内のLFBは、力プロトコルによって標準化された方法で制御されます。
The Transport Mapping Layer (TML) transports the protocol messages. The TML is where the issues of how to achieve transport-level reliability, congestion control, multicast, ordering, etc., are handled. It is expected that more than one TML will be standardized. The various possible TMLs could vary their implementations based on the capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. All ForCES protocol layer implementations must be portable across all TMLs. Although more than one TML may be standardized for the ForCES protocol, all ForCES implementations must implement the Stream Control Transmission Protocol (SCTP) TML [RFC5811].
トランスポートマッピングレイヤー（TML）は、プロトコルメッセージを輸送します。TMLは、輸送レベルの信頼性、混雑制御、マルチキャスト、注文などを達成する方法の問題が処理される場所です。複数のTMLが標準化されることが予想されます。可能なさまざまなTMLは、基礎となるメディアと輸送の機能に基づいて実装を変化させる可能性があります。ただし、各TMLは標準化されているため、両方のエンドポイントが同じTMLをサポートする限り、相互運用性が保証されます。すべての力プロトコル層の実装は、すべてのTMLにわたって移植可能でなければなりません。Force Protocolには複数のTMLが標準化される場合がありますが、すべての力の実装は、ストリーム制御伝送プロトコル（SCTP）TML [RFC5811]を実装する必要があります。
The Forwarding and Control Element Separation Applicability Statement [RFC6041] captures the applicable areas in which ForCES can be used.
転送および制御要素分離適用ステートメント[RFC6041]は、力を使用できる該当する領域をキャプチャします。
This document captures the experience of implementing the ForCES protocol and model, and its main goal is to provide alternatives, ideas, and proposals as how it can be implemented, not to tell others how to implement it.
このドキュメントは、フォースプロトコルとモデルを実装する経験を捉えています。その主な目標は、他の人を実装する方法を伝えるのではなく、実装方法として代替、アイデア、提案を提供することです。
Also, this document mentions possible problems and potential choices that can be made, in an attempt to help implementors develop their own products.
また、このドキュメントは、実装者が独自の製品を開発するのを支援しようとするために、可能な問題と潜在的な選択を行うことができます。
Additionally, this document assumes that the reader has become familiar with the three main ForCES RFCs: the Forwarding and Control Element Separation Protocol [RFC5810], the Forwarding and Control Element Separation Forwarding Element Model [RFC5812], and the SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation Protocol [RFC5811].
さらに、このドキュメントは、読者が3つの主力RFCに精通していることを前提としています：転送および制御要素分離プロトコル[RFC5810]、転送および制御要素分離転送要素モデル[RFC5812]、およびSCTPベースの輸送マッピングレイヤー（TML）転送および制御要素分離プロトコル[RFC5811]。
The terminology used in this document is the same as in the Forwarding and Control Element Separation Protocol [RFC5810]; some of the definitions below are copied from that document.
このドキュメントで使用される用語は、転送および制御要素分離プロトコル[RFC5810]と同じです。以下の定義の一部は、そのドキュメントからコピーされています。
Control Element (CE): A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols.
制御要素（CE）：Force Protocolを実装し、それを使用してパケットの処理方法を1つ以上のFESに指示する論理的エンティティ。CESは、制御プロトコルやシグナル伝達プロトコルの実行などの機能を処理します。
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 one or more CEs via the ForCES protocol.
転送要素（FE）：Force Protocolを実装する論理エンティティ。FESは、基礎となるハードウェアを使用して、パケットごとの処理と取り扱いを、力プロトコルを介して1つ以上のCESが指示/制御します。
LFB (Logical Functional Block): The basic building block that is operated on by the ForCES protocol. The LFB is a well-defined, logically separable functional block that resides in an FE and is controlled by the CE via the ForCES protocol. The LFB may reside at the FE's data path and process packets or may be purely an FE control or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities but not a hardware-accurate representation of the FE implementation.
LFB（論理機能ブロック）：Force Protocolによって動作する基本的な構成要素。LFBは、FEに存在する明確に定義された論理的に分離可能な機能ブロックであり、Forceプロトコルを介してCEによって制御されます。LFBは、FEのデータパスとプロセスパケットに存在する場合があります。または、CEによって操作されるFEコントロールまたは構成エンティティの純粋なものである場合があります。LFBは、FEの処理能力を機能的に正確に抽象化しているが、FE実装のハードウェアがアクセスする表現ではないことに注意してください。
LFB Class and LFB Instance: LFBs are categorized by LFB classes. An LFB instance represents an LFB class (or type) existence. There may be multiple instances of the same LFB class (or type) in an FE. An LFB class is represented by an LFB class ID, and an LFB instance is represented by an LFB instance ID. As a result, an LFB class ID associated with an LFB instance ID uniquely specifies an LFB existence.
LFBクラスとLFBインスタンス：LFBはLFBクラスによって分類されます。LFBインスタンスは、LFBクラス（またはタイプ）の存在を表します。FEには、同じLFBクラス（またはタイプ）の複数のインスタンスがある場合があります。LFBクラスはLFBクラスIDで表され、LFBインスタンスはLFBインスタンスIDで表されます。その結果、LFBインスタンスIDに関連付けられたLFBクラスIDは、LFBの存在を一意に指定します。
LFB Component: Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components. The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol.
LFBコンポーネント：CESに見える必要があるLFBの運用パラメーターは、FEモデルでLFBコンポーネントとして概念化されています。LFBコンポーネントには、たとえば、フラグ、単一のパラメーター引数、複雑な引数、およびCEがフォースプロトコルを介して読み取りおよび/または書き込むことができる表が含まれます。
ForCES Protocol: While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES framework [RFC3746]. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or communication between FE and CE Managers. Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. This document defines the specifications for this ForCES protocol.
力プロトコル：全体の力アーキテクチャ内で使用される複数のプロトコルがある場合がありますが、「力プロトコル」と「プロトコル」という用語は、Force Framework [RFC3746]のFP参照ポイントを指します。このプロトコルは、CE-CE-CE通信、FE対FE通信、またはFEマネージャーとCEマネージャーの間の通信には適用されません。基本的に、Force Protocolは、FESが奴隷であり、CEがマスターであるマスタースレーブモードで機能します。このドキュメントは、この力プロトコルの仕様を定義しています。
ForCES has undergone two successful interoperability tests, where very few issues were caught and resolved.
部隊は、2つの成功した相互運用性テストを受けており、問題が発生して解決された問題はほとんどありません。
This section discusses the ForCES architecture, implementation challenges, and ways to overcome these challenges.
このセクションでは、フォースアーキテクチャ、実装の課題、およびこれらの課題を克服する方法について説明します。
The initial configuration of the FE and the CE is done by the FE Manager and the CE Manager, respectively. These entities have not as yet been standardized.
FEとCEの初期構成は、それぞれFEマネージャーとCEマネージャーによって行われます。これらのエンティティはまだ標準化されていません。
The simplest solution is static configuration files, which play the role of the Managers and are read by FEs and CEs.
最も単純なソリューションは、マネージャーの役割を果たし、FESとCESによって読まれる静的構成ファイルです。
For more dynamic solutions, however, it is expected that the Managers will be entities that will talk to each other and exchange details regarding the associations. Any developer can create any Manager, but they should at least be able to exchange the details below.
ただし、より動的なソリューションの場合、マネージャーは互いに話し合い、協会に関する詳細を交換するエンティティになることが期待されています。開発者は任意のマネージャーを作成できますが、少なくとも以下の詳細を交換できる必要があります。
From the FE Manager side:
FEマネージャー側から：
1. FE Identifiers (FEIDs).
1. FE識別子（FEIDS）。
2. FE IP addresses, if the FEs and CEs will be communicating via network.
2. FE IPアドレス、FESとCESがネットワークを介して通信する場合。
3. TML. The TML that will be used. If this is omitted, then SCTP must be chosen as default.
3. TML。使用されるTML。これが省略されている場合、SCTPはデフォルトとして選択する必要があります。
4. TML priority ports. If this is omitted as well, then the CE must use the default values from the respective TML RFC.
4. TML優先ポート。これも省略されている場合、CEはそれぞれのTML RFCのデフォルト値を使用する必要があります。
From the CE Manager side:
CEマネージャー側から：
1. CE Identifiers (CEIDs).
1. CE識別子（CEID）。
2. CE IP addresses, if the FEs and CEs will be communicating via network.
2. FESとCESがネットワークを介して通信する場合、CE IPアドレス。
3. TML. The TML that will be used. If this is omitted, then SCTP must be chosen as default.
3. TML。使用されるTML。これが省略されている場合、SCTPはデフォルトとして選択する必要があります。
4. TML priority ports. If this is omitted as well, then the FE must use the default values from the respective TML RFC.
4. TML優先ポート。これも省略されている場合、FEはそれぞれのTML RFCのデフォルト値を使用する必要があります。
All ForCES implementations must support the SCTP TML. Even if another TML will be chosen by the developer, SCTP is mandatory and must be supported.
すべての力の実装は、SCTP TMLをサポートする必要があります。開発者によって別のTMLが選択されたとしても、SCTPは必須であり、サポートする必要があります。
There are several issues that should concern a developer for the TML:
TMLの開発者に関係するはずのいくつかの問題があります。
1. Security. TML must be secure according to the respective RFC. For SCTP, you have to use IPsec.
1. 安全。TMLは、それぞれのRFCに従って安全でなければなりません。SCTPの場合、IPSECを使用する必要があります。
2. Remote connection. While ForCES is meant to be used locally, both interoperability tests have proven that ForCES can be deployed everywhere that SCTP/IP is available. In both interoperability tests, there were connections between Greece and China, and the performance was very satisfactory. However, in order for the FE and CE to work in a non-local environment, an implementor must ensure that the SCTP-TML ports are forwarded to the CE and/or FE if they are behind NATs; if there is a firewall, it will allow the SCTP ports through. These were identified during the first ForCES interoperability test and documented in the Implementation Report for Forwarding and Control Element Separation [RFC6053].
2. リモート接続。力はローカルで使用することを目的としていますが、両方の相互運用性テストは、SCTP/IPが利用可能な場所に力を展開できることを証明しています。両方の相互運用性テストでは、ギリシャと中国の間につながりがあり、パフォーマンスは非常に満足のいくものでした。ただし、FEとCEが非ローカル環境で動作するためには、実装者はSCTP-TMLポートがNATの背後にいる場合はCEおよび/またはFEに転送されることを確認する必要があります。ファイアウォールがある場合、SCTPポートを通過できます。これらは、最初の力の相互運用性テストで特定され、転送および制御要素分離のための実装レポートで文書化されました[RFC6053]。
The ForCES model is inherently very dynamic. Using the basic atomic data types that are specified in the model, new atomic (single valued) and/or compound (structures and arrays) datatypes can be built. Thus, developers are free to create their own LFBs. One other advantage that the ForCES model provides is inheritance. New versions of existing LFBs can be created to suit any extra developer requirements.
力モデルは本質的に非常に動的です。モデルで指定されている基本的な原子データ型を使用して、新しい原子（単一の価値）および/または化合物（構造と配列）データタイプを構築できます。したがって、開発者は独自のLFBを自由に作成できます。力モデルが提供するもう1つの利点は継承です。既存のLFBの新しいバージョンは、追加の開発者要件に合わせて作成できます。
The difficulty for a developer is to create an architecture that is completely scalable so there is no need to write the same code for new LFBs, new components, etc. Developers can just create code for the defined atomic values, and new components can then be built based on already written code, thus reusing it.
開発者の難しさは、完全にスケーラブルなアーキテクチャを作成することです。そのため、新しいLFB、新しいコンポーネントなどに同じコードを作成する必要はありません。開発者は、定義された原子値のコードを作成でき、新しいコンポーネントはすでに書かれたコードに基づいて構築されているため、再利用します。
The model itself provides the key, which is inheritance.
モデル自体は、継承であるキーを提供します。
First, a basic component needs to be created as the mother of all the components that has the basic parameters of all the components:
まず、すべてのコンポーネントの基本パラメーターを持つすべてのコンポーネントの母親として基本的なコンポーネントを作成する必要があります。
o The ID of the component.
o コンポーネントのID。
o The access rights of the component.
o コンポーネントのアクセス権。
o If it is an optional component.
o オプションのコンポーネントの場合。
o If it is of variable size.
o サイズが可変の場合。
o Minimum data size.
o 最小データサイズ。
o Maximum data size.
o 最大データサイズ。
If the data size of the component is not variable, then the size is either the minimum or the maximum size, as both should have the same value.
コンポーネントのデータサイズが変動しない場合、サイズは最小サイズまたは最大サイズのいずれかです。どちらも同じ値を持つ必要があります。
Next, some basic functions are in order:
次に、いくつかの基本的な関数が順番にあります。
o A common constructor.
o 共通のコンストラクター。
o A common destructor.
o 一般的な破壊者。
o Retrieve Component ID.
o コンポーネントIDを取得します。
o Retrieve access right property.
o アクセス権のあるプロパティを取得します。
o Query if it is an optional component.
o オプションのコンポーネントの場合、クエリ。
o Get Full Data.
o 完全なデータを取得します。
o Set Full Data.
o 完全なデータを設定します。
o Get Sparse Data.
o まばらなデータを取得します。
o Set Sparse Data.
o スパースデータを設定します。
o Del Full Data.
o delフルデータ。
o Del Sparse Data.
o デルスパースデータ。
o Get Property.
o プロパティを取得します。
o Set Property.
o プロパティを設定します。
o Get Value.
o 価値を取得します。
o Set Value.
o 値を設定します。
o Del Value.
o Del Value。
o Get Data.
o データを取得します。
o Clone component.
o クローンコンポーネント。
The Get/Set/Del Full Data, Get/Set/Del Sparse Data, and Get/Set Property functions handle the respective ForCES commands and return the respective TLV, for example, Set Full Data should return a RESULT-TLV. The Get Value, Set Value, and Del Value functions are called from Get Full/Sparse Data, Set Full/Sparse Data, and Del Full/ Sparse Data respectively and provide the interface to the actual values in the hardware, separating the forces handling logic from the interface to the actual values.
get/set/delフルデータ、get/set/delスパースデータ、およびget/setプロパティ関数は、それぞれの力コマンドを処理し、それぞれのTLVを返します。GET値、セット値、およびDel値関数は、Get Full/Sparseデータ、完全/スパースデータ、およびDelフル/スパースデータをそれぞれ設定し、ハードウェアの実際の値にインターフェイスを提供し、ロジックを処理する力を分離します。インターフェイスから実際の値まで。
The Get Data function should return the value of the data only, not in TLV format.
GETデータ関数は、TLV形式ではなく、データの値のみを返す必要があります。
The Clone function seems out of place. This function must return a new component that has the exact same values and attributes. This function is useful in array components as described further below.
クローン関数は場違いのようです。この関数は、まったく同じ値と属性を持つ新しいコンポーネントを返す必要があります。この関数は、以下にさらに説明するアレイコンポーネントに役立ちます。
The only requirement is to implement the base atomic data types. Any new atomic datatype can be built as a child of a base data type, which will inherit all the functions and, if necessary, override them.
唯一の要件は、ベース原子データ型を実装することです。新しい原子データ型は、すべての機能を継承し、必要に応じてそれらをオーバーライドする基本データ型の子供として構築できます。
The struct component can then be built. A struct component is a component by itself but consists of a number of atomic components. These atomic components create a static array within the struct. The ID of each atomic component is the array's index. For a struct component, the Clone function must create and return an exact copy of the struct component with the same static array.
その後、構造体コンポーネントを構築できます。構造コンポーネントはそれ自体でコンポーネントですが、多くの原子成分で構成されています。これらの原子コンポーネントは、構造体内に静的配列を作成します。各原子コンポーネントのIDは、配列のインデックスです。structコンポーネントの場合、クローン関数は、同じ静的配列を持つstructコンポーネントの正確なコピーを作成して返す必要があります。
The most difficult component to be built is the array. The difficulty lies in the actual benefit of the model: you have absolute freedom over what you build. An array is an array of components. In all rows, you have the exact same type of component, either a single component or a struct. The struct can have multiple single components or a combination of single components, structs, arrays, and so on. So, the difficulty lies in how to create a new row, a new component by itself. This is where the Clone function is very useful. For the array, a mother component that can spawn new components exactly like itself is needed. Once a Set command is received, the mother component can spawn a new component if the targeted row does not exist and add it into the array; with the Set Full Data function, the value is set in the recently spawned component, as the spawned component knows how the data is created. In order to distinguish these spawned components from each other and their functionality, some kind of index is required that will also reflect how the actual data of the specific component is stored on the hardware.
構築するのが最も難しいコンポーネントは、配列です。困難は、モデルの実際の利点にあります。あなたが構築するものに対して絶対的な自由を持っています。配列はコンポーネントの配列です。すべての行に、単一のコンポーネントまたは構造体のいずれかとまったく同じタイプのコンポーネントがあります。構造体には、複数の単一コンポーネント、または単一コンポーネント、構造体、配列などの組み合わせがあります。したがって、難易度は、新しい行、新しいコンポーネント自体を作成する方法にあります。これは、クローン機能が非常に便利なところです。配列の場合、それ自体とまったく同じように新しいコンポーネントを生成できる母親コンポーネントが必要です。設定コマンドが受信されると、ターゲット行が存在しない場合、マザーコンポーネントが新しいコンポーネントを生成し、配列に追加できます。設定された完全なデータ関数を使用すると、データの作成方法が生成されたコンポーネントが認識しているため、値は最近生成されたコンポーネントに設定されます。これらの生成されたコンポーネントを互いに区別するためには、特定のコンポーネントの実際のデータがハードウェアに保存される方法を反映する、ある種のインデックスが必要です。
Once the basic constructors of all possible components are created, then a developer only has to create LFB components or datatypes as a child of one of the already-created components, and the only thing the developer really needs to add is the three functions of Get Value, Set Value, and Del Value of each component, which is platform dependent. The rest stays the same.
すべての可能なコンポーネントの基本コンストラクターが作成されたら、開発者はすでに作成されたコンポーネントの1つの子としてLFBコンポーネントまたはデータ型を作成するだけで、開発者が本当に追加する必要があるのはGetの3つの関数だけです。プラットフォームに依存する各コンポーネントの値、設定値、およびdel値。残りは同じままです。
The same architecture in the components can be used for the LFBs, allowing a developer to write LFB handling code only once. The parent LFB has some basic attributes:
コンポーネント内の同じアーキテクチャをLFBに使用できるため、開発者はLFB処理コードを1回だけ書き込むことができます。親LFBにはいくつかの基本的な属性があります。
o The LFB Class ID.
o LFBクラスID。
o The LFB Instance ID.
o LFBインスタンスID。
o An Array of Components.
o コンポーネントの配列。
o An Array of Capabilities.
o 一連の機能。
o An Array of Events.
o 一連のイベント。
Following are some common functions:
以下はいくつかの一般的な機能です。
o Handle Configuration Command.
o 構成コマンドを処理します。
o Handle Query Command.
o クエリコマンドを処理します。
o Get Class ID.
o クラスIDを取得します。
o Get Instance ID.
o インスタンスIDを取得します。
Once these are created, each LFB can inherit all these from the parent, and the only thing it has to do is add the components that have already been created.
これらが作成されると、各LFBはこれらすべてを親から継承でき、それがしなければならない唯一のことは、すでに作成されているコンポーネントを追加することです。
An example can be seen in Figure 1. The following code creates a part of FEProtocolLFB:
例を図1に示します。次のコードでは、Feprotocollfbの一部を作成します。
//FEID
cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id);
Components[cui->get_ComponentId()]=cui; //Add component to array list
//Current FEHB Policy Value
cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0);
Components[cub->get_ComponentId()]=cub; //Add component to array list
//FEIDs for BackupCEs Array
cui = new Component_uInt(0, ACCESS_READ_WRITE, 0);
ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE);
ca->AddRow(cui, 1);
ca->AddMotherComponent(cui);
Components[ca->get_ComponentId()]=ca; //Add component to array list
Figure 1: Example Code for Creating Part of FEProtocolLFB
図1：feprotocollfbの一部を作成するためのコードの例
The same concept can be applied to handling LFBs as one FE. An FE is a collection of LFBs. Thus, all LFBs can be stored in an array based on the LFB's class id, version, and instance. Then, what is required is an LFBHandler that will handle the array of LFBs. A specific LFB, for example, can be addressed using the following scheme:
同じ概念を1つのFEとしてLFBの処理に適用できます。FEはLFBのコレクションです。したがって、すべてのLFBは、LFBのクラスID、バージョン、およびインスタンスに基づいて配列に保存できます。次に、必要なのは、LFBの配列を処理するLFBHandlerです。たとえば、特定のLFBは、次のスキームを使用して対処できます。
LFBs[ClassID][Version][InstanceID]
LFBS [ClassID] [バージョン] [InstanceID]
Note: While an array can be used in components, capabilities, and events, a hash table or a similar concept is better suited for storing LFBs using the component ID as the hash key with linked lists for collision handling, as the created array can have large gaps if the values of LFB Class ID vary greatly.
注：アレイはコンポーネント、機能、イベントで使用できますが、ハッシュテーブルまたは同様の概念は、作成された配列が持つ可能性のあるハッシュキーとしてコンポーネントIDを使用してLFBを保存するのに適しています。LFBクラスIDの値が大きく異なる場合、大きなギャップ。
The goal for protocol handling is to create a general and scalable architecture that handles all protocol messages instead of something implementation specific. There are certain difficulties that have to be overcome first.
プロトコル処理の目標は、実装固有のものではなく、すべてのプロトコルメッセージを処理する一般的でスケーラブルなアーキテクチャを作成することです。最初に克服する必要がある特定の困難があります。
Since the model allows a developer to define any LFB required, the protocol has been thus created to give the user the freedom to configure and query any component, whatever the underlying model. While this is a strong point for the protocol itself, one difficulty lies with the unknown underlying model and the unlimited number of types of messages that can be created, making creating generic code a daunting task.
モデルにより、開発者が必要なLFBを定義できるようになるため、基礎となるモデルが何であれ、ユーザーに任意のコンポーネントを構成してクエリする自由をユーザーに提供するためにプロトコルが作成されました。これはプロトコル自体にとって強いポイントですが、1つの難しさは、未知の基礎モデルと作成できる無制限の数のメッセージにあり、ジェネリックコードの作成を困難なタスクにします。
Additionally, the protocol also allows two different path approaches to LFB components, and the CE or FE must handle both or even a mix of them, making a generic decoding of the protocol message difficult.
さらに、プロトコルはLFBコンポーネントへの2つの異なるパスアプローチも許可し、CEまたはFEはそれらの両方または混合さえ処理する必要があり、プロトコルメッセージの一般的なデコードを困難にします。
Another difficulty also arises from the batching capabilities of the protocol. You can have multiple Operations within a message; you can select more than one LFB to command and more than one component to manipulate.
別の困難は、プロトコルのバッチング機能からも生じます。メッセージ内で複数の操作を実行できます。コマンドする複数のLFBを選択し、複数のコンポーネントを操作することができます。
A possible solution is again provided by inheritance. There are two basic components in a protocol message:
可能な解決策は、継承によって再び提供されます。プロトコルメッセージには2つの基本的なコンポーネントがあります。
1. The common header.
1. 共通ヘッダー。
2. The rest of the message.
2. 残りのメッセージ。
The rest of the message is divided in Type-Length-Value (TLV) units and, in one case, Index-Length-Value (ILV) units.
メッセージの残りの部分は、タイプ長値（TLV）単位で分割され、ある場合にはインデックスレングス値（ILV）ユニットです。
The TLV hierarchy can be seen in Figure 2:
TLV階層を図2に見ることができます。
Common Header
|
+---------------+---------------+---------------+
| | | |
REDIRECT-TLV LFBselect-TLV ASResult-TLV ASTreason-TLV
|
|
OPER-TLV
|
|
PATH-DATA-TLV ---> Optional KEYINFO-TLV
|
+-------------+-------------+-------------+
| | | |
SPARSEDATA-TLV RESULT-TLV FULLDATA-TLV PATH-DATA-TLV
Figure 2: ForCES TLV Hierarchy
図2：強制TLV階層
The above figure shows only the basic hierarchical level of TLVs and does not show batching. Also, this figure does not show the recursion that can occur at the last level of the hierarchy. The figure shows one kind of recursion with a PATH-DATA-TLV within a PATH-DATA-TLV. A FULLDATA-TLV can be within a FULLDATA-TLV and a SPARSEDATA-TLV. The possible combination of TLVs are described in detail in the Forwarding and Control Element Separation Protocol [RFC5810] as well as the data-packing rules.
上記の図は、TLVの基本的な階層レベルのみを示しており、バッチは表示されません。また、この図は、階層の最後のレベルで発生する可能性のある再帰を示していません。この図は、Path-Data-TLV内のPath-Data-TLVを使用した1つの種類の再帰を示しています。fulldata-tlvは、fulldata-tlvおよびsparsedata-tlv内にあります。TLVの可能な組み合わせは、転送および制御要素分離プロトコル[RFC5810]とデータパッキングルールで詳細に説明されています。
A TLV's main attributes are:
TLVの主な属性は次のとおりです。
o Type.
o タイプ。
o Length.
o 長さ。
o Data.
o データ。
o An array of TLVs.
o TLVの配列。
The array of TLVs is the next hierarchical level of TLVs nested in this TLV.
TLVの配列は、このTLVにネストされたTLVの次の階層レベルです。
A TLV's common function could be:
TLVの一般的な機能は次のとおりです。
o A basic constructor.
o 基本的なコンストラクター。
o A constructor using data from the wire.
o ワイヤーからのデータを使用したコンストラクター。
o Add a new TLV for next level.
o 次のレベルに新しいTLVを追加します。
o Get the next TLV of next level.
o 次のレベルの次のTLVを取得します。
o Get a specific TLV of next level.
o 次のレベルの特定のTLVを取得します。
o Replace a TLV of next level.
o 次のレベルのTLVを交換します。
o Get the Data.
o データを取得します。
o Get the Length.
o 長さを取得します。
o Set the Data.
o データを設定します。
o Set the Length.
o 長さを設定します。
o Set the Type.
o タイプを設定します。
o Serialize the header.
o ヘッダーをシリアル化します。
o Serialize the TLV to be written on the wire.
o ワイヤーに記述されるTLVをシリアル化します。
All TLVs inherit these functions and attributes and either override them or create new where it is required.
すべてのTLVは、これらの関数と属性を継承し、それらをオーバーライドするか、必要な場合に新しい作成を作成します。
Following is an algorithm for deserializing any protocol message:
以下は、プロトコルメッセージを辞任するためのアルゴリズムです。
1. Get the message header.
1. メッセージヘッダーを取得します。
2. Read the length.
2. 長さを読んでください。
3. Check the message type to understand what kind of message this is.
3. メッセージタイプを確認して、これがどんなメッセージであるかを理解してください。
4. If the length is larger than the message header, then there is data for this message.
4. 長さがメッセージヘッダーよりも大きい場合、このメッセージのデータがあります。
5. A check can be made here regarding the message type and the length of the message.
5. メッセージの種類とメッセージの長さに関して、ここでチェックを行うことができます。
If the message is a Query or Config type, then there are LFBselect-TLVs for this level:
メッセージがクエリまたは構成タイプの場合、このレベルにはLFBSElect-TLVがあります。
1. Read the next 2 shorts(type-length). If the type is an LFBselect-TLV, then the message is valid.
1. 次の2つのショートパンツ（タイプ長）を読んでください。タイプがLFBSelect-TLVの場合、メッセージは有効です。
2. Read the necessary length for this LFBselect-TLV, and create the LFBselect-TLV from the data of the wire.
2. このLFBSElect-TLVに必要な長さを読み、ワイヤーのデータからLFBSElect-TLVを作成します。
3. Add this LFBselect-TLV to the main header array of LFBselect-TLVs.
3. このLFBSELECT-TLVをLFBSELECT-TLVのメインヘッダーアレイに追加します。
4. Repeat all above steps until the rest of the message has finished.
4. メッセージの残りの部分が終了するまで、上記のすべての手順を繰り返します。
The next level of TLVs is OPER-TLVs.
TLVの次のレベルはOper-TLVです。
1. Read the next 2 shorts(type-length). If the type is an OPER-TLV, then the message is valid.
1. 次の2つのショートパンツ（タイプ長）を読んでください。タイプがOper-TLVの場合、メッセージは有効です。
2. Read the necessary length for this OPER-TLV, and create the OPER-TLV from the data of the wire.
2. このOper-TLVに必要な長さを読み、ワイヤのデータからOper-TLVを作成します。
3. Add this OPER-TLV to the LFBselect-TLV array of TLVs.
3. このOper-TLVをTLVのLFBSElect-TLV配列に追加します。
4. Do this until the rest of the LFBselect-TLV has finished.
4. LFBSelect-TLVの残りの部分が終了するまでこれを行います。
The next level of TLVs is PATH-DATA-TLVs.
TLVの次のレベルはPath-Data-TLVです。
1. Read the next 2 shorts(type-length). If the type is a PATH-DATA-TLV, then the message is valid.
1. 次の2つのショートパンツ（タイプ長）を読んでください。タイプがPath-Data-TLVの場合、メッセージは有効です。
2. Read the necessary length for this PATH-DATA-TLV, and create the PATH-DATA-TLV from the data of the wire.
2. このPath-Data-TLVに必要な長さを読み、ワイヤのデータからPath-Data-TLVを作成します。
3. Add this PATH-DATA-TLV to the OPER-TLV's array of TLVs.
3. このPath-Data-TLVをTLVのOpera-TLV配列に追加します。
4. Do this until the rest of the OPER-TLV is finished.
4. Opera-TLVの残りの部分が終了するまでこれを行います。
Here it gets interesting, as the next level of PATH-DATA-TLVs can be one of the following:
次のレベルのPath-Data-TLVが次のいずれかになる可能性があるため、ここでは興味深いものになります。
o PATH-DATA-TLVs.
o Path-data-tlvs。
o FULLDATA-TLV.
o fulldata-tlv。
o SPARSEDATA-TLV.
o Sparsedata-tlv。
o RESULT-TLV.
o result-tlv。
The solution to this difficulty is recursion. If the next TLV is a PATH-DATA-TLV, then the PATH-DATA-TLV that is created uses the same kind of deserialization until it reaches a FULLDATA-TLV or SPARSEDATA-TLV. There can be only one FULLDATA-TLV or SPARSEDATA-TLV within a PATH-DATA-TLV.
この困難の解決策は再帰です。次のTLVがPath-Data-TLVである場合、作成されるPath-Data-TLVは、Fulldata-TLVまたはSparsedata-TLVに達するまで、同じ種類の敏arializationを使用します。Path-Data-TLV内には、fulldata-tlvまたはSparsedata-tlvが1つしかありません。
1. Read the next 2 shorts(type-length).
1. 次の2つのショートパンツ（タイプ長）を読んでください。
2. If the Type is a PATH-DATA-TLV, then repeat the previous algorithm but add the PATH-DATA-TLV to this PATH-DATA-TLV's array of TLVs.
2. タイプがPath-Data-TLVの場合は、前のアルゴリズムを繰り返しますが、このPath-Data-TLVのTLVの配列にPath-Data-TLVを追加します。
3. Do this until the rest of the PATH-DATA-TLV is finished.
3. Path-Data-TLVの残りの部分が終了するまでこれを行います。
4. If the Type is a FULLDATA-TLV, then create the FULLDATA-TLV from the message and add this to the PATH-DATA-TLV's array of TLVs.
4. タイプがfulldata-tlvの場合は、メッセージからfulldata-tlvを作成し、これをPath-data-tlvのTLVの配列に追加します。
5. If the Type is a SPARSEDATA-TLV, then create the SPARSEDATA-TLV from the message and add this to the PATH-DATA-TLV's array of TLVs.
5. タイプがSparsedata-TLVの場合は、メッセージからSparsedata-TLVを作成し、これをPath-Data-TLVのTLVの配列に追加します。
6. If the Type is a RESULT-TLV, then create the RESULT-TLV from the message and add this to the PATH-DATA-TLV's array of TLVs.
6. タイプが結果tlvの場合、メッセージから結果tlvを作成し、これをPath-data-tlvのTLVの配列に追加します。
If the message is a Query, it must not have any kind of data inside the PATH-DATA-TLV.
メッセージがクエリの場合、Path-Data-TLV内にいかなる種類のデータも持っていてはなりません。
If the message is a Query Response, then it must have either a RESULT-TLV or a FULLDATA-TLV.
メッセージがクエリ応答である場合、結果tlvまたはfulldata-tlvのいずれかが必要です。
If the message is a Config, it must contain either a FULLDATA-TLV or a SPARSEDATA-TLV.
メッセージが構成の場合、fulldata-tlvまたはsparsedata-tlvのいずれかを含める必要があります。
If the message is a Config Response, it must contain a RESULT-TLV.
メッセージが構成応答の場合、結果tlvを含める必要があります。
More details regarding message validation can be read in Section 7 of the Forwarding and Control Element Separation Protocol [RFC5810].
メッセージの検証に関する詳細は、転送および制御要素分離プロトコル[RFC5810]のセクション7で読むことができます。
Note: When deserializing, implementors must take care to ignore padding of TLVs as all must be 32-bit aligned. The length value in TLVs includes the Type and Length (4 bytes) but does not include padding.
注：脱必要な場合、実装者はTLVのパディングを無視するように注意しなければなりません。TLVの長さの値には、タイプと長さ（4バイト）が含まれますが、パディングは含まれません。
The same concept can be applied in the message creation process. Having the TLVs ready, a developer can go bottom up. All that is required is the serialization function that will transform the TLV into bytes ready to be transferred on the network.
メッセージ作成プロセスにも同じ概念を適用できます。TLVの準備ができているため、開発者はボトムアップできます。必要なのは、TLVをネットワーク上で転送する準備ができたバイトに変換するシリアル化関数だけです。
For example, for the creation of a simple query from the CE to the FE, all the PATH-DATA-TLVs are created. Then they will be serialized and inserted into an OPER-TLV, which in turn will be serialized and inserted into an LFBselect-TLV. The LFBselect-TLV will then be serialized and entered into the Common Header, which will be passed to the TML to be transported to the FE.
たとえば、CEからFEまでの簡単なクエリを作成するために、すべてのPath-Data-TLVが作成されます。その後、それらはシリアル化され、Oper-TLVに挿入され、それがシリアル化され、LFBSElect-TLVに挿入されます。その後、LFBSELECT-TLVがシリアル化され、共通ヘッダーに入力され、TMLに渡されてFEに輸送されます。
Having an array of TLVs inside a TLV that is next in the TLV hierarchy allows the developer to insert any number of next-level TLVs, thus creating any kind of message.
TLV階層の次のTLV内にTLVの配列があるため、開発者は次のレベルのTLVを任意の数の挿入し、あらゆる種類のメッセージを作成できます。
Note: When the TLV is serialized to be written on the wire, implementors must take care to include padding to TLVs as all must be 32-bit aligned.
注：TLVがワイヤー上に書かれるようにシリアル化されている場合、実装者はTLVにパディングを含めるように注意しなければなりません。
Any development platform that can support the SCTP TML and the TML of the developer's choosing is available for use.
開発者の選択のSCTP TMLとTMLをサポートできる開発プラットフォームは、使用可能です。
Figure 3 provides an initial survey of SCTP support for C/C++ and Java at the present time.
図3は、現時点でのC/CおよびJavaのSCTPサポートの初期調査を示しています。
/-------------+-------------+-------------+-------------\
|\ Platform | | | |
| ----------\ | Windows | Linux | Solaris |
| Language \| | | |
+-------------+-------------+-------------+-------------+
| | | | |
| C/C++ | Supported | Supported | Supported |
| | | | |
+-------------+-------------+-------------+-------------+
| | Limited | | |
| Java | Third Party | Supported | Supported |
| | Not from SUN| | |
\-------------+-------------+-------------+-------------/
Figure 3: SCTP Support on Operating Systems
図3：オペレーティングシステムでのSCTPサポート
A developer should be aware of some limitations regarding Java implementations.
開発者は、Javaの実装に関するいくつかの制限を認識する必要があります。
Java inherently does not support unsigned types. A workaround can be found in the creation of classes that do the translation of unsigned types to Java types. The problem is that the unsigned long cannot be used as-is in the Java platform. The proposed set of classes can be found in [JavaUnsignedTypes].
Javaは本質的に署名されていないタイプをサポートしていません。回避策は、UnsignedタイプのJavaタイプへの翻訳を行うクラスの作成にあります。問題は、署名されていないロングをJavaプラットフォームで使用できないことです。提案されている一連のクラスは[JavaunSignedTypes]にあります。
The authors would like to thank Adrian Farrel for sponsoring this document and Jamal Hadi Salim for discussions that made this document better.
著者は、この文書を後援してくれたAdrian Farrelと、この文書を改善した議論についてJamal Hadi Salimに感謝したいと思います。
Developers of ForCES FEs and CEs must take the Security Considerations of the Forwarding and Control Element Separation Framework [RFC3746] and the Forwarding and Control Element Separation Protocol [RFC5810] into account.
FESとCESの開発者は、転送および制御要素分離フレームワーク[RFC3746]および転送および制御要素分離プロトコル[RFC5810]のセキュリティに関する考慮事項を考慮しなければなりません。
Also, as specified in the Security Considerations section of the SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation Protocol [RFC5811], transport-level security has to be ensured by IPsec.
また、SCTPベースの輸送マッピング層（TML）のセキュリティに関する考慮事項セクションで指定されているように、転送および制御要素分離プロトコル[RFC5811]のために、IPSECによって輸送レベルのセキュリティを確保する必要があります。
[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月。
[RFC6041] Crouch, A., Khosravi, H., Doria, A., Wang, X., and K. Ogawa, "Forwarding and Control Element Separation (ForCES) Applicability Statement", RFC 6041, October 2010.
[RFC6041] Crouch、A.、Khosravi、H.、Doria、A.、Wang、X。、およびK. Ogawa、「Forwarding and Control Control element Separation（Forces）Applicability Statement」、RFC 6041、2010年10月。
[RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, "Implementation Report for Forwarding and Control Element Separation (ForCES)", RFC 6053, November 2010.
[RFC6053] Haleplidis、E.、Ogawa、K.、Wang、W。、およびJ. Hadi Salim、「転送および制御要素分離（Forces）の実装レポート」、RFC 6053、2010年11月。
[JavaUnsignedTypes] "Java Unsigned Types", <http://nam.ece.upatras.gr/index.php?q=node/44>.
[javaunsignedtypes] "Java unsigned Types"、<http://nam.ece.upatras.gr/index.php?q=node/44>。
[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
著者のアドレス
Evangelos Haleplidis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
エヴァンゲロス・ハレプリディスパトラス大学電気およびコンピューター工学部パトラス26500ギリシャ
EMail: ehalep@ece.upatras.gr
Odysseas Koufopavlou University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
Odysseas Koufopavlou Patras大学電気およびコンピューターエンジニアリングパトラス26500ギリシャ
EMail: odysseas@ece.upatras.gr
Spyros Denazis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
スピロスデナジスパトラス大学電気およびコンピューターエンジニアリングパトラス26500ギリシャ
EMail: sdena@upatras.gr