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.
転送と制御素子分離（のForCES）プロトコルは、制御要素（CE）は、転送要素（FE）の動作を制御できるような標準的な通信及び制御機構を定義します。この文書はのForCESプロトコルやモデルの実装の経験をキャプチャします。その目的はの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/rfc6369.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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ネットワーク要素（NEのForCES）における制御プレーンと転送プレーン間の情報交換を標準化します。 [RFC3654]はのForCES要件を定義し、[RFC3746]は、のForCESフレームワークを定義します。
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.
マスタースレーブモードの力プロトコルの動作とは、転送要素（FE）はスレーブであり、制御要素（CES）がマスターです。プロトコルは、更に、情報の転送と制御素子分離プロトコル[RFC5810]を読み取ることが奨励されている等、リーダ論理的な機能ブロック（LFB）の構成情報、関連設定、ステータス、およびイベント通知の輸送のためのコマンドを含みます。
[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 LFBsを定義するための正式な方法を提示しています。 LFBsが正式に作成されたときにLFB構成コンポーネント、機能、および関連するイベントが定義されています。転送要素（FE）内LFBsそれに応じのForCESプロトコルによって標準化された方法で制御されます。
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は標準化されることが期待されます。様々な可能性のあるTMLsは、基礎となるメディアや輸送の能力に基づいて、その実装を変化させることができます。各TMLが標準化されているので、相互運用性は、両方のエンドポイントが同じTMLをサポートしている限り保証されています。すべての力プロトコル層の実装は、すべてのTMLs間で移植する必要があります。複数TMLはのForCESプロトコルの標準化されてもよいが、全ての力の実装では、ストリーム制御伝送プロトコル（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.
この文書はのForCESプロトコルやモデルの実装経験を取り込み、その主な目標は、代替案、アイディア、そしてそれを実装する方法を他の人に伝えるために、ない実装する方法として提案を提供することです。
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ベースのトランスポートマッピング・レイヤー転送と制御素子分離プロトコル[RFC5811]のための（TML）。
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）のForCESプロトコルを実装し、パケットを処理する方法の一の以上のFEを指示するためにそれを使用する論理エンティティ。 CEは、このような制御およびシグナリングプロトコルの実行などの機能を扱います。
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）：のForCESプロトコルを実装する論理エンティティ。 FEは、のForCESプロトコルを介して1つのまたは複数のCEによって制御/指示されるように、パケット単位の処理および取り扱いを提供するために、基礎となるハードウェアを使用します。
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（論理機能ブロック）：のForCESプロトコルによって操作された基本的なビルディングブロック。 LFBはFEに存在する、強制的プロトコルを介して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インスタンスは：LFBsは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コンポーネントは：CEに見えなければならないLFBsの動作パラメータは、LFB成分としてFEモデルで概念化されます。 LFBの成分としては、例えば、フラグ、CEは、読み取り及び/又はのForCESプロトコルを介して書き込むことができる単一のパラメータ、引数、複雑な引数、およびテーブル。
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.
ForCESプロトコル：全体のForCESアーキテクチャ内で使用される複数のプロトコルが存在してもよいが、用語「のForCESプロトコル」および「プロトコル」とのForCESフレームワーク[RFC3746]でのFPの基準点を指します。このプロトコルは、CE-に-CE通信、FE-に-FE通信、またはFEとCEマネージャーとの間の通信には適用されません。基本的に、複数のFEは、スレーブおよびCEされたマスタ・スレーブモードの力プロトコル作品はマスターです。この文書では、こののForCESプロトコルの仕様を定義します。
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.
このセクションでは、のForCESアーキテクチャ、実装上の課題、およびこれらの課題を克服する方法について説明します。
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 ManagerおよびCEマネージャによって行われます。これらのエンティティは、まだ標準化されていません。
The simplest solution is static configuration files, which play the role of the Managers and are read by FEs and CEs.
最も簡単な解決策は、管理者の役割を果たしているとのFEとCEにより読み取られる静的なコンフィギュレーションファイル、です。
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マネージャ側から：
2. FE IP addresses, if the FEs and CEs will be communicating via network.
2. FE IPアドレスは、のFEおよびCEは、ネットワークを介して通信される場合。
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マネージャ側から：
2. CE IP addresses, if the FEs and CEs will be communicating via network.
2. CEのIPアドレスは、のFEおよびCEは、ネットワークを介して通信される場合。
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が非ローカル環境で動作するためには、実装者は、彼らがNATの背後にある場合、SCTP-TMLポートがCEおよび/またはFEに転送されていることを確認する必要があります。ファイアウォールがある場合、それはSCTPポートを経由できるようになります。これらは、最初のForCESの相互運用性のテスト中に識別し、転送と制御素子分離[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.
ForCESモデルは、本質的に非常に動的です。モデルで指定されている基本的なアトミックなデータ型を使用して、新しい原子（単一の値を持つ）および/または化合物（構造および配列）データ型を構築することができます。このため、開発者は自分のLFBsを作成するのは自由です。 ForCESモデルが提供するもう一つの利点は、継承です。既存LFBsの新バージョンでは、余分な開発者の要件に合わせて作成することができます。
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.
などの開発者のため困難新しいLFBsで同じコードを記述する必要がないので、完全にスケーラブルであるアーキテクチャを作成することで、新しいコンポーネント、開発者は単に定義原子値のコードを作成することができ、そして新たなコンポーネントはその後することができしたがって、それを再利用し、すでに書かれたコードに基づいて構築。
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.
コンポーネントのID O。
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・デル・フルデータ。
o Del Sparse Data.
またはデルスパースデータ。
o Get Property.
プロパティに取得します。
o Set Property.
プロパティに設定します。
o Get Value.
O値を取得します。
o Set Value.
O値を設定します。
o Del Value.
O・デル・バリュー。
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.
取得/設定/デルフルデータ、設定/取得/デルスパースデータ、および/ setプロパティ関数は、それぞれのForCESコマンドを処理し、それぞれのTLVを返しなさい、例えば、完全なデータセットはRESULT-TLVを返す必要があります。取得値、設定値、およびデル価値機能は、ロジックを処理する力を分離し、それぞれフル/スパースデータ、セットのフル/スパースデータ、およびデル・フル/スパースデータを取得し、ハードウェアの実際の値にインターフェイスを提供するからと呼ばれていますインターフェイスから実際の値です。
The Get Data function should return the value of the data only, not in TLV format.
データの取り込み機能だけでなく、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は、配列のインデックスです。構造体構成要素については、クローン機能は、同じ静的な配列を持つ構造体成分の正確なコピーを作成して返さなければなりません。
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.
構築されるべき最も困難な部品は配列です。難易度は、モデルの実際の利益である：あなたが構築するものの上に絶対的な自由を持っています。アレイは、コンポーネントの配列です。すべての行では、部品の正確な同じタイプの、いずれかの単一の成分または構造体を持っています。構造体は、これに複数の単一のコンポーネントまたは単一の構成要素、構造体、配列の組み合わせ、とを有することができます。だから、難易度自体は、新しい行、新しいコンポーネントを作成する方法です。クローン機能は非常に便利であるところです。配列の場合、正確に自分自身のような新しいコンポーネントを起動することができ、母コンポーネントが必要とされています。 Setコマンドを受信すると、母親のコンポーネントは、対象行が存在しない場合は、新しいコンポーネントを起動し、配列に追加することができます。生成されたコンポーネントは、データの作成方法を知っているようにすべてのデータセット機能で、値が、最近生まれたコンポーネントに設定されています。これらの生成された互いからのコンポーネントとそれらの機能を区別するために、指標の何らかのはまた、特定の成分の実際のデータをハードウェアに保存されている方法を反映することが必要です。
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の三つの機能であります値、設定値、およびプラットフォームに依存する各成分のデル値。残りは同じままです。
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処理コードを記述することができ、LFBsのために使用することができます。親LFBは、いくつかの基本的な属性があります。
o The LFB Class ID.
LFBクラスID、O。
o The LFB Instance ID.
LFBインスタンスID、O。
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:
例は、次のコードは、FEProtocolLFBの一部を作成し、図1に見ることができます。
//FEID cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id); Components[cui->get_ComponentId()]=cui; //Add component to array list
// FEIDのCUI =新しいComponent_uInt（FEPO_FEID、ACCESS_READ_ONLY、FE_id）。成分[cui-> get_ComponentId（）] = CUI。 //配列リストにコンポーネントを追加します。
//Current FEHB Policy Value cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0); Components[cub->get_ComponentId()]=cub; //Add component to array list
//現在のFEHBポリシー値カブ=新しいComponent_uByte（FEPO_FEHBPolicy、ACCESS_READ_WRITE、0）;成分[cub-> get_ComponentId（）] =カブ。 //配列リストにコンポーネントを追加します。
//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としてLFBsの取り扱いに適用することができます。 FEはLFBsのコレクションです。従って、全てLFBsは、LFBのクラスID、バージョン、およびインスタンスに基づいて、配列に格納することができます。その後、何が必要であることはLFBsの配列を処理するLFBHandlerです。特定のLFBは、例えば、次のスキームを使用して対処することができます。
LFBs[ClassID][Version][InstanceID]
LFBs [のClassID] [バージョン] [インスタンスID]
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を使用してLFBsを格納に適しています大きなギャップ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.
また、プロトコルはまた、2つの異なる経路がLFBコンポーネントに近づき、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つの基本的なコンポーネントがあります。
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：のForCES 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と再帰の種類を示しています。 FULLDATA-TLVはFULLDATA-TLVとSPARSEDATA-TLV内とすることができます。 TLVの可能な組み合わせは、転送および制御素子分離プロトコル[RFC5810]と同様に、データパッキングルールに詳細に記載されています。
A TLV's main attributes are:
TLVの主な属性は次のとおりです。
o Type.
Oタイプ。
o Length.
Oの長さ。
o Data.
一回。
o An array of TLVs.
TLVの配列O。
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:
任意のプロトコルメッセージをデシリアライズするためのアルゴリズムは、次のとおりです。
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を作成します。
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.このパス-DATA-TLVに必要な長さを読み、ワイヤのデータからPATH-DATA-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.
PATH-DATA-のTLV O。
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であるならば、それはFULLDATA-TLVまたはSPARSEDATA-TLVに到達するまで、その後、作成されたPATH-DATA-TLVは、デシリアライゼーションの同じ種類を使用しています。 PATH-DATA-TLV内の一つだけFULLDATA-TLVまたはSPARSEDATA-TLVが存在する場合があります。
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.
タイプは、PATH-DATA-TLVである場合2.その後、以前のアルゴリズムを繰り返しますが、TLVのこのPATH-DATA-TLVの配列に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を作成したTLVのPATH-DATA-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を作成したTLVのPATH-DATA-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.
タイプはRESULT-TLVである場合には、メッセージからの結果-TLVを作成したTLVのPATH-DATA-TLVの配列にこれを追加6。
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.
メッセージは、クエリ応答であれば、それはRESULT-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.
メッセージは、コンフィグ応答である場合、それはRESULT-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.
注意：デシリアライズすると、実装者は、すべて32ビット整列しなければならないとの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.
例えば、FEへのCEから単純なクエリの作成のために、すべてのPATH-DATA-のTLVが作成されます。その後、彼らはシリアライズと順番にLFBselect-TLVにシリアライズして挿入されますOPER-TLV、挿入されます。 LFBselect-TLVは、シリアライズとFEに輸送されるようにTMLに渡される共通ヘッダ、に入力されます。
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は、ワイヤに書き込まれるようにシリアル化された場合、実装者は、すべて32ビットに整列されなければならないとしての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型にunsigned型の変換を行うクラスの作成で見つけることができます。問題は、Javaプラットフォームでそのままunsigned long型を使用することができないということです。クラスの提案されたセットは[JavaUnsignedTypes]に見出すことができます。
The authors would like to thank Adrian Farrel for sponsoring this document and Jamal Hadi Salim for discussions that made this document better.
著者は、より良い、この文書を作った議論については、この文書とジャマルハディサリムを後援するためにエードリアンファレルに感謝したいと思います。
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.
ForCESのFEとCEの開発者のアカウントに転送し、制御素子分離フレームワーク[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.
転送と制御素子分離プロトコル[RFC5811]のためのSCTPベースのトランスポートマッピングレイヤ（TML）のセキュリティの考慮事項のセクションで指定され、また、トランスポートレベルのセキュリティは、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]ドリア、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月。
[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]クラウチ、A.、Khosravi、H.、ドリア、A.、ワング、X.、及びK.小川、 "転送および制御素子分離（のForCES）適用ステートメント"、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.、小川、K.、王、W.、およびJ.ハディサリム、 "転送および制御素子分離（のForCES）の導入レポート"、RFC 6053、2010年11月。
[JavaUnsignedTypes] "Java Unsigned Types", <http://nam.ece.upatras.gr/index.php?q=node/44>.
[JavaUnsignedTypes] "Javaの符号なし型"、<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.アンダーソン、 "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
著者のアドレス
Evangelos Haleplidis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
電気・コンピュータ工学パトラス26500ギリシャのパトラス部門のEvangelos Haleplidis大学
EMail: ehalep@ece.upatras.gr
メールアドレス：ehalep@ece.upatras.gr
Odysseas Koufopavlou University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
ユリシーズKoufopaflou Yniversityトレードオフパトラス部門のトレードオフElektrikal Kompyterエンジニアリング＆パトラス26500ギリシャ
EMail: odysseas@ece.upatras.gr
メールアドレス：odysseas@ece.upatras.gr
Spyros Denazis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
電気・コンピュータ工学パトラス26500ギリシャのパトラス部門のSpyros Denazis大学
EMail: sdena@upatras.gr
メールアドレス：sdena@upatras.gr