[要約] RFC 6984は、Forwarding and Control Element Separation（ForCES）の相互運用性レポートであり、ForCESプロトコルの実装と相互運用性の評価を提供します。このRFCの目的は、ForCESアーキテクチャの実装者や研究者に対して、プロトコルの実装と相互運用性の問題に関する洞察を提供することです。
Internet Engineering Task Force (IETF) W. Wang
Request for Comments: 6984 Zhejiang Gongshang University
Updates: 6053 K. Ogawa
Category: Informational NTT Corporation
ISSN: 2070-1721 E. Haleplidis
University of Patras
M. Gao
Hangzhou BAUD Networks
J. Hadi Salim
Mojatatu Networks
August 2013
Interoperability Report for Forwarding and Control Element Separation (ForCES)
転送および制御要素分離（ForCES）の相互運用性レポート
Abstract
概要
This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.
このドキュメントは、2011年2月24〜25日、中国の浙江公尚大学のインターネットテクノロジーラボ（ITL）で行われた2番目の転送および制御要素分離（ForCES）相互運用性テストの結果をキャプチャします。最初のForCES相互運用性テストの結果はRFC 6053で報告されており、このドキュメントは、相互運用性の結果をさらに提供することによってRFC 6053を更新します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6984.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6984で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 3
1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 4
1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4
1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Date, Location, and Participants . . . . . . . . . . . . . 4
2.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 5
2.2.1. Participants' Access . . . . . . . . . . . . . . . . . 5
2.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 6
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 7
3.2. Scenario 2 - TML with IPsec . . . . . . . . . . . . . . . 8
3.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 9
3.4. Scenario 4 - Packet Forwarding . . . . . . . . . . . . . . 11
4. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Test of LFB Operation . . . . . . . . . . . . . . . . . . 14
4.2. Test of TML with IPsec . . . . . . . . . . . . . . . . . . 20
4.3. Test of CE High Availability . . . . . . . . . . . . . . . 20
4.4. Test of Packet Forwarding . . . . . . . . . . . . . . . . 21
5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 28
This document captures the results of the second interoperability test of the Forwarding and Control Element Separation (ForCES) that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The test involved protocol elements described in several documents, namely:
このドキュメントは、中国の浙江公尚大学のインターネットテクノロジーラボ（ITL）で2011年2月24〜25日に行われた転送と制御要素分離（ForCES）の2番目の相互運用性テストの結果をキャプチャします。テストには、いくつかのドキュメントで説明されているプロトコル要素が含まれていました。
- ForCES Protocol [RFC5810]
- ForCESプロトコル[RFC5810]
- ForCES Forwarding Element (FE) Model [RFC5812]
- ForCES転送要素（FE）モデル[RFC5812]
- ForCES Transport Mapping Layer (TML) [RFC5811]
- ForCESトランスポートマッピングレイヤー（TML）[RFC5811]
The test also involved protocol elements described in the then-current versions of two Internet-Drafts. Although these documents have subsequently been revised and advanced, it is important to understand which versions of the work were used during this test. The then-current Internet-Drafts are:
テストには、2つのインターネットドラフトの当時最新バージョンで説明されていたプロトコル要素も含まれていました。これらのドキュメントはその後改訂および拡張されましたが、このテスト中に使用された作業のバージョンを理解することが重要です。当時最新のインターネットドラフトは次のとおりです。
- "ForCES Logical Function Block (LFB) Library" (December 2010) [LFB-LIB]
- 「ForCES論理機能ブロック（LFB）ライブラリ」（2010年12月）[LFB-LIB]
- "ForCES Intra-NE High Availability" (October 2010) [CEHA]
- 「ForCES Intra-NE High Availability」（2010年10月）[CEHA]
Note: The ForCES Logical Function Block (LFB) Library document was published as [RFC6956].
注：ForCES論理機能ブロック（LFB）ライブラリドキュメントは[RFC6956]として公開されました。
Three independent ForCES implementations participated in the test.
3つの独立したForCES実装がテストに参加しました。
Scenarios of ForCES LFB Operation, TML with IPsec, Control Element High Availability (CEHA), and Packet Forwarding were constructed. Series of testing items for every scenario were carried out and interoperability results were achieved. The popular packet analyzers Ethereal/Wireshark [Ethereal] and Tcpdump [Tcpdump] were used to verify the wire results.
ForCES LFB操作のシナリオ、IPsecを使用したTML、制御要素の高可用性（CEHA）、およびパケット転送が構築されました。すべてのシナリオの一連のテスト項目が実行され、相互運用性の結果が達成されました。ワイヤーの結果を検証するために、人気のあるパケットアナライザーEthereal / Wireshark [Ethereal]およびTcpdump [Tcpdump]が使用されました。
This document is an update to [RFC6053], which captured the results of the first ForCES interoperability test. The first test on ForCES was held in July 2008 at the University of Patras, Greece. That test focused on validating the basic semantics of the ForCES protocol and ForCES Forwarding Element (FE) model.
このドキュメントは、最初のForCES相互運用性テストの結果を取り込んだ[RFC6053]の更新版です。 ForCESの最初のテストは、2008年7月にギリシャのパトラス大学で行われました。このテストは、ForCESプロトコルとForCES転送要素（FE）モデルの基本的なセマンティクスの検証に重点を置いていました。
The ForCES protocol works in a master-slave mode in which FEs are slaves and Control Elements (CEs) are masters. The protocol includes commands for transport of Logical Function Block (LFB) configuration information, association setup, status, event notifications, etc. The reader is encouraged to read the ForCES protocol specification [RFC5810] for further information.
ForCESプロトコルは、FEがスレーブでControl Element（CE）がマスターであるマスタースレーブモードで動作します。プロトコルには、論理機能ブロック（LFB）構成情報の転送、関連付けの設定、ステータス、イベント通知などのコマンドが含まれます。詳細については、ForCESプロトコル仕様[RFC5810]を読むことをお勧めします。
The ForCES FE model [RFC5812] presents a formal way to define FE LFBs using XML. LFB configuration components, capabilities, and associated events are defined when the LFB is formally created. The LFBs within the FE are accordingly controlled in a standardized way by the ForCES protocol.
ForCES FEモデル[RFC5812]は、XMLを使用してFE LFBを定義する正式な方法を提供します。 LFB構成コンポーネント、機能、および関連イベントは、LFBが正式に作成されるときに定義されます。したがって、FE内のLFBは、ForCESプロトコルによって標準化された方法で制御されます。
The ForCES Transport Mapping Layer (TML) transports the ForCES protocol layer 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. RFC 5811 specifies a TML that is based on the Stream Control Transmission Protocol (SCTP) and is a mandated TML for ForCES. See RFC 5811 for more details.
ForCESトランスポートマッピングレイヤー（TML）は、ForCESプロトコルレイヤーメッセージをトランスポートします。 TMLは、トランスポートレベルの信頼性、輻輳制御、マルチキャスト、順序付けなどを実現する方法の問題が処理される場所です。複数のTMLが標準化されることが予想されます。 RFC 5811は、Stream Control Transmission Protocol（SCTP）に基づいており、ForCESに必須のTMLであるTMLを指定しています。詳細については、RFC 5811を参照してください。
This document follows the terminology defined by ForCES-related documents, including [RFC3654], [RFC3746], [RFC5810], [RFC5811], [RFC5812], [RFC5813], etc.
このドキュメントは、[RFC3654]、[RFC3746]、[RFC5810]、[RFC5811]、[RFC5812]、[RFC5813]など、ForCES関連のドキュメントで定義された用語に従います。
The second ForCES interoperability test meeting was held by the IETF ForCES Working Group on February 24-25, 2011, and was chaired by Jamal Hadi Salim. Three independent ForCES implementations participated in the test:
2回目のForCES相互運用性テスト会議は、2011年2月24〜25日にIETF ForCESワーキンググループによって開催され、Jamal Hadi Salimが議長を務めました。テストには3つの独立したForCES実装が参加しました。
o Zhejiang Gongshang University/Hangzhou BAUD Corporation of Information and Networks Technology (Hangzhou BAUD Networks), China. This implementation is referred to as "ZJSU" or "Z" in this document for the sake of brevity.
o 浙江公尚大学/中国杭州情報ネットワーク技術公司（杭州情報ネットワーク）、中国。この実装では、簡潔にするために、このドキュメントでは「ZJSU」または「Z」と呼びます。
o NTT Corporation, Japan. This implementation is referred to as "NTT" or "N" in this document for the sake of brevity.
o 日本電信電話株式会社。この実装では、簡潔にするために、このドキュメントでは「NTT」または「N」と呼びます。
o The University of Patras, Greece. This implementation is referred to as "UoP" or "P" in this document for the sake of brevity.
o パトラス大学、ギリシャ。この実装では、簡潔にするために、このドキュメントでは「UoP」または「P」と呼びます。
Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks Corporation, which independently extended two different well-known public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and Tcpdump [Tcpdump], also participated in the interoperability test. During the test, the two protocol analyzers were used to verify the validity (and in some cases, the semantics) of ForCES protocol messages.
他の2つの組織、Mojatatu NetworksとHangzhou BAUD Networks Corporationも、2つの異なる有名なパブリックドメインプロトコルアナライザー、Ethereal / Wireshark [Ethereal]とTcpdump [Tcpdump]を独立して拡張し、相互運用性テストに参加しました。テスト中、2つのプロトコルアナライザーを使用して、ForCESプロトコルメッセージの有効性（場合によってはセマンティクス）を検証しました。
Some issues related to interoperability among implementations were discovered. Most of the issues were solved on site during the test. The most contentious issue found was on the format of encapsulation for the protocol TLVs (refer to Section 5.1).
実装間の相互運用性に関連するいくつかの問題が発見されました。ほとんどの問題は、テスト中に現場で解決されました。発見された最も論争の多い問題は、プロトコルTLVのカプセル化の形式に関するものでした（セクション5.1を参照）。
Some errata related to the ForCES document were found by the interoperability test. The errata found in related RFCs have also been reported.
ForCESドキュメントに関連するエラッタは、相互運用性テストで見つかりました。関連RFCで見つかったエラッタも報告されています。
At times, interoperability testing was exercised between two instead of all three representative implementations because the third one lacked a specific feature; however, in ensuing discussions, all implementers mentioned they would be implementing any missing features in the future.
3つ目の実装には特定の機能がなかったため、3つの代表的な実装すべてではなく、2つの実装間で相互運用性テストが行われることもありました。ただし、その後の議論で、すべての実装者は、欠落している機能を将来実装する予定であると述べました。
NTT and ZJSU were physically present for the testing at the Internet Technology Lab (ITL) at Zhejiang Gongshang University in China. The implementation team from the University of Patras joined remotely from Greece. The chair, Jamal Hadi Salim, joined remotely from Canada by using TeamViewer as the monitoring tool [TeamViewer]. The approach was as shown in Figure 1. In the figure, FE/CE refers to the FE or CE that the implementer may act as alternatively.
NTTとZJSUは、中国の浙江公尚大学のインターネットテクノロジーラボ（ITL）でのテストに物理的に出席しました。パトラス大学の実装チームは、ギリシャからリモートで参加しました。椅子Jamal Hadi Salimは、モニタリングツールとしてTeamViewerを使用して、カナダからリモートで参加しました[TeamViewer]。アプローチは図1に示したとおりです。図では、FE / CEは実装者が代替として機能するFEまたはCEを指します。
+---------+ +----+ +------------+
| FE/CE | | | +---| Monitoring |
| ZJSU |-----| | /\/\/\/\/\ | |(TeamViewer)|
+---------+ | | \Internet/ | | Mojatatu |
|LAN |----/ \--| +------------+
+---------+ | | \/\/\/\/\/ | +------------+
| FE/CE |-----| | | | FE/CE |
| NTT | | | +---| UoP |
+---------+ +----+ +------------+
Figure 1: Access for Participants
図1：参加者のアクセス
As specified in [RFC5811], all CEs and FEs implemented IPsec in the TML.
[RFC5811]で指定されているように、すべてのCEおよびFEはTMLにIPsecを実装しました。
On the Internet boundary, gateways used must allow for IPsec, the SCTP protocol, and SCTP ports as defined in the ForCES SCTP-based TML document [RFC5811].
インターネット境界では、使用されるゲートウェイは、ForCES SCTPベースのTMLドキュメント[RFC5811]で定義されているように、IPsec、SCTPプロトコル、およびSCTPポートを許可する必要があります。
The CEs and FEs from ZJSU's and NTT's implementations were physically located within the ITL Lab at Zhejiang Gongshang University and connected together using Ethernet switches. The configuration can be seen in Figure 2. In the figure, SmartBits [SmartBits] is a third-party routing protocol testing machine that acts as a router running Open Shortest Path First (OSPF) and RIP, and exchanges routing protocol messages with ForCES routers in the network. Connection to the Internet was via an Asymmetric Digital Subscriber Line (ADSL) channel.
ZJSUおよびNTTの実装からのCEおよびFEは、物理的には浙江公尚大学のITLラボ内に配置され、イーサネットスイッチを使用して相互に接続されていました。構成を図2に示します。図では、SmartBits [SmartBits]は、Open Shortest Path First（OSPF）およびRIPを実行するルーターとして機能し、ルーティングプロトコルメッセージをForCESルーターと交換するサードパーティのルーティングプロトコルテストマシンですネットワークで。インターネットへの接続は、非対称デジタル加入者線（ADSL）チャネルを介して行われました。
/\/\/\/\/\
\Internet/
/ \
\/\/\/\/\/
|
|(ADSL)
|
+-------------------------------------------------------------------+
| LAN (10.20.0.0/24) |
+-------------------------------------------------------------------+
| | | | | |
| | | | | |
|.222 |.230 |.221 |.179 |.231 |.220
+-----+ +-----+ +-----+ +-----+ +-----+ +---------+
| CE | | CE | | | | | | | | Protocol|
|ZJSU | | NTT | | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer|
+-----+ +-----+ |ZJSU |---------| NTT |---------|ZJSU | +---------+
+---------| |192.169. | | 192.168.| |------+
| .2 +-----+ 20.0.24 +-----+ 30.0/24+-----+ .2 |
| .12| |.12 |
| | | |
192.168.50.0/24 | |192.168.60.0/24
| 192.168.10.0/24 192.168.40.0/24 |
.1 | |.11 |.11 |.1
+--------+ +--------------------------------------+ +--------+
|Terminal| | SmartBits | |Terminal|
+--------+ +--------------------------------------+ +--------+
Figure 2: Testbed Configuration Located in the ITL Lab, China
図2：中国のITLラボにあるテストベッド構成
The CE and FE from the UoP implementation were located within the University of Patras, Greece, and were connected together using LAN, as shown in Figure 3. Connection to the Internet was via a VPN channel.
図3に示すように、UoP実装のCEとFEはギリシャのパトラス大学内にあり、LANを使用して相互に接続されていました。インターネットへの接続はVPNチャネルを介して行われました。
/\/\/\/\/\
\Internet/
/ \
\/\/\/\/\/
|
|(VPN)
|
+------------------------------------+
| LAN |
+------------------------------------+
| | |
| | |
+------+ +--------+ +------+
| FE | |Protocol| | CE |
| UoP | |Analyzer| | UoP |
+------+ +--------+ +------+
Figure 3: Testbed Configuration Located in the University of Patras, Greece
図3：ギリシャのパトラス大学にあるテストベッド構成
The testbeds above were then able to satisfy the requirements of all interoperability test scenarios in this document.
上記のテストベッドは、このドキュメントのすべての相互運用性テストシナリオの要件を満たすことができました。
This scenario was designed to test the interoperability of LFB operations among the participants. The connection diagram for the participants is shown in Figure 4.
このシナリオは、参加者間のLFB操作の相互運用性をテストするために設計されました。参加者の接続図を図4に示します。
+------+ +------+ +------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE | | CE | | CE |
| ZJSU | | NTT | | ZJSU | | UoP | | NTT | | UoP |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
+------+ +------+ +------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE | | FE | | FE |
| NTT | | ZJSU | | UoP | | ZJSU | | UoP | | NTT |
+------+ +------+ +------+ +------+ +------+ +------+
Figure 4: Scenario for LFB Operation
図4：LFB操作のシナリオ
In order to make interoperability more credible, the three implementers were required to carry out the test acting as a CE or FE alternatively. As a result, every LFB operation was combined with six scenarios, as shown by Figure 4.
相互運用性をより信頼できるものにするために、3人の実装者は、CEまたはFEとして機能するテストを交互に実行する必要がありました。その結果、図4に示すように、すべてのLFB操作が6つのシナリオと組み合わされました。
The test scenario was designed with the following purposes.
テストシナリオは、次の目的で設計されました。
Firstly, the scenario was designed to verify all kinds of protocol messages with their complex data formats, which were defined in [RFC5810]. Specifically, we tried to verify the data format of a PATH-DATA-TLV with nested PATH-DATA-TLVs, and the operation (SET, GET, and DEL) of an array or an array with a nested array.
最初に、シナリオは、[RFC5810]で定義された複雑なデータ形式であらゆる種類のプロトコルメッセージを検証するように設計されました。具体的には、PATH-DATA-TLVがネストされたPATH-DATA-TLVのデータ形式と、配列またはネストされた配列を持つ配列の操作（SET、GET、およびDEL）を検証しようとしました。
Secondly, the scenario was designed to verify the definition of ForCES LFB Library [LFB-LIB], which defined a base set of ForCES LFB classes for typical router functions. Successful tests under this scenario would help the validity of the LFB definitions.
次に、シナリオはForCES LFBライブラリ[LFB-LIB]の定義を検証するために設計されました。これは、一般的なルーター機能用のForCES LFBクラスの基本セットを定義しました。このシナリオで成功したテストは、LFB定義の妥当性を支援します。
This scenario was designed to implement a TML with IPsec, which was the requirement defined by RFC 5811. TML with IPsec was not implemented and tested in the first ForCES interoperability test, as reported in RFC 6053. For this reason, in this interoperability test, we specifically designed the test scenario to verify the TML over IPsec channel.
このシナリオは、RFC 5811で定義された要件であるIPsecを使用したTMLを実装するように設計されました。IPsecを使用したTMLは、RFC 6053で報告されている最初のForCES相互運用性テストで実装およびテストされていません。このため、この相互運用性テストでは、 TML over IPsecチャネルを検証するためのテストシナリオを特別に設計しました。
In this scenario, tests on LFB operations for Scenario 1 were repeated with the difference that TML was secured via IPsec. This setup scenario allowed us to verify whether all interactions between the CE and FE could be made correctly under an IPsec TML environment.
このシナリオでは、シナリオ1のLFB操作のテストが繰り返されましたが、TMLはIPsecを介して保護されたという違いがあります。このセットアップシナリオにより、CEとFE間のすべての対話がIPsec TML環境で正しく行われるかどうかを確認できました。
The connection diagram for this scenario is shown in Figure 5. Because an unfortunate problem with the test system in the UoP prevented the deployment of IPsec over TML, this test only took place between the test systems in ZJSU and NTT.
このシナリオの接続図を図5に示します。UoPのテストシステムの不幸な問題により、IPsec over TMLの展開が妨げられたため、このテストはZJSUとNTTのテストシステム間でのみ行われました。
+------+ +------+
| CE | | CE |
| ZJSU | | NTT |
+------+ +------+
| |
|TML over IPsec |TML over IPsec
+------+ +------+
| FE | | FE |
| NTT | | ZJSU |
+------+ +------+
Figure 5: Scenario for LFB Operation with TML over IPsec
図5：TML over IPsecを使用したLFB操作のシナリオ
In this scenario, ForCES TML was run over the IPsec channel. Implementers joined in this interoperability test using the same third-party software 'Racoon' [Racoon] to establish the IPsec channel.
このシナリオでは、ForCES TMLはIPsecチャネルを介して実行されました。実装者は、同じサードパーティソフトウェア「Racoon」[Racoon]を使用してこの相互運用性テストに参加し、IPsecチャネルを確立しました。
The Racoon in NetBSD is an Internet Key Exchange (IKE) daemon that performs the key exchange with the peers. Both IKEv1 and IKEv2 are supported by Racoon in Linux 2.6, and IKEv2 was adopted in the interop test. The Security Association Database (SAD) and Security Policy Database (SPD) were necessary for the test, setups of which were in the Racoon configuration file. The Encapsulating Security Payload (ESP) was specified in the SAD and SPD in the Racoon configuration file.
NetBSDのRacoonは、ピアとの鍵交換を実行するインターネット鍵交換（IKE）デーモンです。 IKEv1とIKEv2の両方がLinux 2.6のRacoonによってサポートされており、IKEv2が相互運用テストで採用されました。セキュリティアソシエーションデータベース（SAD）とセキュリティポリシーデータベース（SPD）がテストに必要でしたが、そのセットアップはRacoon構成ファイルにありました。カプセル化セキュリティペイロード（ESP）は、Racoon構成ファイルのSADおよびSPDで指定されています。
ZJSU and NTT conducted a successful test with the scenario, and the IPsec requirement items in [RFC5812] were realized.
ZJSUとNTTはシナリオを使用してテストに成功し、[RFC5812]のIPsec要件項目が実現されました。
CE High Availability (CEHA) was tested based on the ForCES CEHA document [CEHA].
CE High Availability（CEHA）は、ForCES CEHAドキュメント[CEHA]に基づいてテストされました。
The design of the setup and the scenario for the CEHA were simplified so as to focus mostly on the mechanics of the CEHA, which were:
セットアップの設計とCEHAのシナリオは、主にCEHAのメカニズムに焦点を合わせるように簡略化されました。
o Associating with more than one CE.
o 複数のCEとの関連付け。
o Switching to a backup CE on a master CE failure.
o マスターCEの障害時にバックアップCEに切り替える。
The connection diagram for the scenario is shown in Figure 6.
シナリオの接続図を図6に示します。
master standby master standby
+------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE |
| ZJSU | | UoP | | NTT | | UoP |
+------+ +------+ +------+ +------+
| | | |
+----------+ +-----------+
| |
+------+ +------+
| FE | | FE |
| UoP | | UoP |
+------+ +------+
(a) (b)
Figure 6: Scenario for CE High Availability
図6：CE高可用性のシナリオ
In this scenario, one FE was connected and associated to a master CE and a backup CE. In the pre-association phase, the FE would be configured to have ZJSU's or NTT's CE as the master CE and the UoP's CE as the standby CE. The CEFailoverPolicy component of the FE Protocol Object LFB that specified whether the FE was in High Availability mode (value 2 or 3) would be set either in the pre-association phase by the FE interface or in the post-association phase by the master CE.
このシナリオでは、1つのFEが接続され、マスターCEとバックアップCEに関連付けられました。事前関連付けフェーズでは、FEは、ZJSUまたはNTTのCEをマスターCEとして、UoPのCEをスタンバイCEとして構成します。 FEが高可用性モード（値2または3）であるかどうかを指定したFEプロトコルオブジェクトLFBのCEFailoverPolicyコンポーネントは、FEインターフェイスによって関連付け前のフェーズで設定されるか、マスターCEによって関連付け後のフェーズで設定されます。 。
If the CEFailoverPolicy value was set to 2 or 3, the FE (in the post-association phase) would attempt to connect and associate with the standby CE.
CEFailoverPolicy値が2または3に設定されている場合、FEは（関連付け後の段階で）スタンバイCEに接続して関連付けようとします。
When the master CE was deemed disconnected, either by a TearDown, Loss of Heartbeats, or physically disconnected, the FE would assume that the standby CE was now the master CE. The FE would then send an Event Notification, Primary CE Down, to all associated CEs (only the standby CE in this case) with the value of the new master Control Element ID (CEID). The standby CE would then respond by sending a configuration message to the CEID component of the FE Protocol Object with its own ID to confirm that the CE considered itself the master as well.
TearDown、Loss of Heartbeats、または物理的に切断されたためにマスターCEが切断されたと見なされた場合、FEはスタンバイCEがマスターCEであると想定します。次に、FEはイベント通知、プライマリCEダウンを、関連するすべてのCE（この場合はスタンバイCEのみ）に、新しいマスターコントロールエレメントID（CEID）の値とともに送信します。次に、スタンバイCEは、自身のIDを使用して構成メッセージをFEプロトコルオブジェクトのCEIDコンポーネントに送信することによって応答し、CEが自身もマスターであると見なしたことを確認します。
The steps of the CEHA test scenario were as follows:
CEHAテストシナリオの手順は次のとおりです。
1. In the pre-association phase, the FE is set up with the master CE and the backup CE.
1. 事前関連付けフェーズでは、マスターCEとバックアップCEを使用してFEがセットアップされます。
2. The FE connects and associates with the master CE.
2. FEはマスターCEに接続して関連付けます。
3. When CEFailoverPolicy is set to 2 or 3, the FE connects and associates with the backup CE.
3. CEFailoverPolicyが2または3に設定されている場合、FEはバックアップCEに接続して関連付けます。
4. Once the master CE is considered disconnected, then the FE chooses the first associated backup CE.
4. マスターCEが切断されていると見なされると、FEは最初に関連付けられたバックアップCEを選択します。
5. It sends an Event Notification that specifies the master CE is down and identifies the new master CE.
5. マスターCEがダウンしていることを示し、新しいマスターCEを識別するイベント通知を送信します。
6. The new master CE sends a SET Configuration message to the FE; the FE then sets the CEID value to the new master CE completing the switch.
6. 新しいマスターCEは、SET構成メッセージをFEに送信します。次に、FEはCEID値を新しいマスターCEに設定して、切り替えを完了します。
This test scenario was conducted to verify LFBs like RedirectIn, RedirectOut, IPv4NextHop, and IPv4UcastLPM, which were defined by the ForCES LFB library document [LFB-LIB], and more importantly, to verify the combination of the LFBs to implement IP packet forwarding.
このテストシナリオは、ForCES LFBライブラリドキュメント[LFB-LIB]で定義されているRedirectIn、RedirectOut、IPv4NextHop、IPv4UcastLPMなどのLFBを検証し、さらに重要なことに、IPパケット転送を実装するLFBの組み合わせを検証するために行われました。
The connection diagram for this scenario is shown in Figure 7.
このシナリオの接続図を図7に示します。
+------+
| CE |
| NTT |
+------+
| ^
| | OSPF
| +------->
+------+ +------+
+--------+ | FE | | OSPF | +--------+
|Terminal|------| ZJSU |-------|Router|------|Terminal|
+--------+ +------+ +------+ +--------+
<-------------------------------------------->
Packet Forwarding
(a)
+------+
| CE |
| ZJSU |
+------+
^ | ^
OSPF | | | OSPF
<-----+ | +----->
+-------+ +------+ +------+
+--------+ | OSPF | | FE | | OSPF | +--------+
|Terminal|----|Router |----| NTT |-----|Router|--|Terminal|
+--------+ +-------+ +------+ +------+ +--------+
<-------------------------------------------->
Packet Forwarding
(b)
+------+ +------+
| CE | | CE |
| NTT | | ZJSU |
+------+ +------+
| ^ ^ |
| | OSPF | |
| +----------+ |
+------+ +------+
+--------+ | FE | | FE | +--------+
|Terminal|------| ZJSU |-------| NTT |------|Terminal|
+--------+ +------+ +------+ +--------+
<-------------------------------------------->
Packet Forwarding
(c)
Figure 7: Scenario for IP Packet Forwarding
図7：IPパケット転送のシナリオ
In case (a), NTT's CE was connected to ZJSU's FE to form a ForCES router. A SmartBits [SmartBits] test machine equipped with routing protocol software was used to simulate an OSPF router and was connected with the ForCES router to try to exchange OSPF Hello packets and Link State Advertisement (LSA) packets among them. Terminals were simulated by SmartBits to send and receive packets. As a result, the CE in the ForCES router needed to be configured to run and support the OSPF routing protocol.
ケース（a）では、NTTのCEはZJSUのFEに接続されてForCESルーターを形成しました。ルーティングプロトコルソフトウェアを備えたSmartBits [SmartBits]テストマシンを使用して、OSPFルーターをシミュレートし、ForCESルーターに接続して、OSPF Helloパケットとリンク状態アドバタイズ（LSA）パケットを交換しました。端末は、パケットを送受信するためにSmartBitsによってシミュレートされました。その結果、ForCESルーターのCEは、OSPFルーティングプロトコルを実行およびサポートするように構成する必要がありました。
In case (b), ZJSU'S CE was connected to NTT'S FE to form a ForCES router. Two routers running OSPF were simulated and connected to the ForCES router to test if the ForCES router could support the OSPF protocol and support packet forwarding.
ケース（b）では、ZJSUのCEがNTTのFEに接続されてForCESルーターが形成されました。 OSPFを実行している2台のルーターをシミュレートし、ForCESルーターに接続して、ForCESルーターがOSPFプロトコルをサポートし、パケット転送をサポートできるかどうかをテストしました。
In case (c), two ForCES routers were constructed; one was with NTT's CE and ZJSU's FE, and the other was with NTT's FE and ZJSU's CE. OSPF and packet forwarding were tested in the environment.
ケース（c）では、2つのForCESルーターが構築されました。 1つはNTTのCEとZJSUのFE、もう1つはNTTのFEとZJSUのCEでした。 OSPFおよびパケット転送が環境でテストされました。
The testing process for this scenario is shown below:
このシナリオのテストプロセスを以下に示します。
1. Boot terminals and routers, and set the IP addresses of their interfaces.
1. 端末とルーターを起動し、インターフェースのIPアドレスを設定します。
2. Boot the CE and FE.
2. CEとFEを起動します。
3. Establish an association between the CE and FE, and set the IP addresses of the FE interfaces.
3. CEとFE間の関連付けを確立し、FEインターフェイスのIPアドレスを設定します。
4. Start OSPF among the CE and routers, and set the Forwarding Information Base (FIB) on the FE.
4. CEとルーター間でOSPFを開始し、FEに転送情報ベース（FIB）を設定します。
5. Send packets between terminals.
5. 端末間でパケットを送信します。
The test results are reported in Figure 8. As mentioned earlier, for convenience, the following abbreviations are used in the table: "Z" for the implementation from ZJSU, "N" for the implementation from NTT, and "P" for the implementation from the UoP.
テスト結果は図8に報告されています。前述のように、便宜上、表では次の略語が使用されています。「Z」はZJSUからの実装、「N」はNTTからの実装、「P」は実装UoPから。
+-----+----+-----+-----+--------------+-------------------+---------+
|Test#| CE |FE(s)|Oper | LFB | Component | Result |
| | | | | | /Capability | |
+-----+----+-----+-----+--------------+-------------------+---------+
| 1 | Z | N | GET | FEObject | LFBTopology | Success |
| | N | Z | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 2 | Z | N | GET | FEObject | LFBSelector | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 3 | Z | N | GET | EtherPHYCop | PHYPortID | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 4 | Z | N | GET | EtherPHYCop | AdminStatus | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 5 | Z | N | GET | EtherPHYCop | OperStatus | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 6 | Z | N | GET | EtherPHYCop | AdminLinkSpeed | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 7 | Z | N | GET | EtherPHYCop | OperLinkSpeed | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 8 | Z | N | GET | EtherPHYCop | AdminDuplexSpeed | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 9 | Z | N | GET | EtherPHYCop | OperDuplexSpeed | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 10 | Z | N | GET | EtherPHYCop | CarrierStatus | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 11 | Z | N | GET | EtherMACIn | AdminStatus | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 12 | Z | N | GET | EtherMACIn | LocalMacAddresses | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 13 | Z | N | GET | EtherMACIn | L2Bridging | Success |
| | N | Z | | | PathEnable | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 14 | Z | N | GET | EtherMACIn | PromiscuousMode | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 15 | Z | N | GET | EtherMACIn | TxFlowControl | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 16 | Z | N | GET | EtherMACIn | RxFlowControl | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 17 | Z | N | GET | EtherMACIn | MACInStats | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 18 | Z | N | GET | EtherMACOut | AdminStatus | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 19 | Z | N | GET | EtherMACOut | MTU | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 20 | Z | N | GET | EtherMACOut | TxFlowControl | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 21 | Z | N | GET | EtherMACOut | TxFlowControl | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 22 | Z | N | GET | EtherMACOut | MACOutStats | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 23 | Z | N | GET | ARP |PortV4AddrInfoTable| Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 24 | Z | N | SET | ARP |PortV4AddrInfoTable| Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 25 | Z | N | DEL | ARP |PortV4AddrInfoTable| Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 26 | Z | N | SET | EtherMACIn | LocalMACAddresses | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 27 | Z | N | SET | EtherMACIn | MTU | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 28 | Z | N | SET | IPv4NextHop | IPv4NextHopTable | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 29 | Z | N | SET | IPv4UcastLPM | IPv4PrefixTable | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 30 | Z | N | DEL | IPv4NextHop | IPv4NextHopTable | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 31 | Z | N | DEL | IPv4UcastLPM | IPv4PrefixTable | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 32 | Z | N | SET | EtherPHYCop | AdminStatus | Success |
| | N | Z | | | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 33 | Z | N | SET | Ether | VlanInputTable | Success |
| | N | Z | | Classifier | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 34 | Z | N | DEL | Ether | VlanInputTable | Success |
| | N | Z | | Classifier | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 35 | Z | N | SET | Ether | VlanOutputTable | Success |
| | N | Z | | Encapsulator | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
| | | | | | | |
| 36 | Z | N | DEL | Ether | VlanOutputTable | Success |
| | N | Z | | Encapsulator | | Success |
| | Z | P | | | | Success |
| | P | Z | | | | Success |
| | N | P | | | | Success |
| | P | N | | | | Success |
+-----+----+-----+-----+--------------+-------------------+---------+
Figure 8: Test Results for LFB Operation
図8：LFB操作のテスト結果
Note on tests #1 and #2:
テスト＃1および＃2に関する注意：
On the wire format of encapsulation on array, only the case of FULLDATA-TLV vs. SPARSEDATA-TLV was tested.
アレイ上のカプセル化のワイヤ形式では、FULLDATA-TLVとSPARSEDATA-TLVのケースのみがテストされました。
When we use the ForCES protocol, it is very common for the CE to use the FEobject LFB to get information on LFBs and their topology in the FE. Hence, the two tests were specifically made.
ForCESプロトコルを使用する場合、CEがFEobject LFBを使用してLFBとFE内のトポロジーに関する情報を取得することは非常に一般的です。したがって、2つのテストが具体的に行われました。
In this scenario, the ForCES TML was run over IPsec. Implementers joined this interoperability test and used the same third-party tool software 'Racoon' [Racoon] to establish the IPsec channel. Typical LFB operation tests as in Scenario 1 were repeated with the IPsec-enabled TML.
このシナリオでは、ForCES TMLはIPsecを介して実行されました。実装者はこの相互運用性テストに参加し、同じサードパーティツールソフトウェア「Racoon」[Racoon]を使用してIPsecチャネルを確立しました。シナリオ1のような典型的なLFB動作テストは、IPsec対応のTMLで繰り返されました。
As mentioned, this scenario only took place between implementers from ZJSU and NTT.
前述のように、このシナリオはZJSUとNTTの実装者の間でのみ発生しました。
The TML with IPsec test results are reported in Figure 9.
TML with IPsecテストの結果を図9に示します。
+-----+----+-----+-----+--------------+-------------------+---------+
|Test#| CE |FE(s)|Oper | LFB | Component/ | Result |
| | | | | | Capability | |
+-----+----+-----+-----+--------------+-------------------+---------+
| 1 | Z | N | GET | FEObject | LFBTopology | Success |
| | N | Z | | | | Success |
| | | | | | | |
| 2 | Z | N | GET | FEObject | LFBSelectors | Success |
| | N | Z | | | | Success |
| | | | | | | |
| 3 | Z | N | SET | Ether | VlanInputTable | Success |
| | N | Z | | Classifier | | Success |
| | | | | | | |
| 4 | Z | N | DEL | Ether | VlanInputTable | Success |
| | N | Z | | Classifier | | Success |
+-----+----+-----+-----+--------------+-------------------+---------+
Figure 9: Test Results for TML with IPsec
図9：IPsecを使用したTMLのテスト結果
In this scenario, one FE connected and associated with a master CE and a backup CE. When the master CE was deemed disconnected, the FE attempted to find another associated CE to become the master CE.
このシナリオでは、1つのFEが接続され、マスターCEとバックアップCEに関連付けられています。マスターCEが切断されていると見なされた場合、FEは、マスターCEになる別の関連付けられたCEを見つけようとしました。
The CEHA scenario, as described in Scenario 3, was completed successfully for both setups.
シナリオ3で説明したCEHAシナリオは、両方のセットアップで正常に完了しました。
Due to a bug in one of the FEs, an interesting issue was caught: it was observed that the buggy FE took up to a second to failover. It was eventually found that the issue was due to the FE's prioritization of the different CEs. All messages from the backup CE were being ignored unless the master CE was disconnected.
FEの1つにバグがあったため、興味深い問題が見つかりました。バグのあるFEがフェイルオーバーに最大1秒かかることが確認されました。最終的に、問題はFEによるさまざまなCEの優先順位付けに起因することが判明しました。マスターCEが切断されない限り、バックアップCEからのすべてのメッセージは無視されていました。
While the bug was fixed and the CEHA scenario was completed successfully, the authors felt it was important to capture the implementation issue in this document. The recommended approach is the following:
バグは修正され、CEHAシナリオは正常に完了しましたが、作成者は、このドキュメントで実装の問題を把握することが重要であると感じました。推奨されるアプローチは次のとおりです。
o The FE should receive and handle messages first from the master CE on all priority channels to maintain proper functionality and then receive and handle messages from the backup CEs.
o FEは、適切な機能を維持するために、まずすべての優先チャネルでマスターCEからメッセージを受信して処理し、次にバックアップCEからメッセージを受信して処理する必要があります。
o Only when the FE is attempting to associate with the backup CEs should the FE receive and handle messages per priority channel from all CEs. When all backup CEs are associated with or deemed unreachable, then the FE should return to receiving and handling messages first from the master CE.
o FEがバックアップCEとの関連付けを試みている場合にのみ、FEはすべてのCEから優先チャネルごとにメッセージを受信して処理する必要があります。すべてのバックアップCEが関連付けられているか到達不能と見なされた場合、FEは最初にマスターCEからのメッセージの受信と処理に戻る必要があります。
As described in the ForCES LFB library [LFB-LIB], packet forwarding is implemented by a set of LFB classes that compose a processing path for packets. In this test scenario, as shown in Figure 7, a ForCES router running the OSPF protocol was constructed. In addition, a set of LFBs including RedirectIn, RedirectOut, IPv4UcastLPM, and IPv4NextHop were used. RedirectIn and RedirectOut LFBs redirected OSPF Hello and LSA packets from and to the CE. A SmartBits [SmartBits] test machine was used to simulate an OSPF router and exchange the OSPF Hello and LSA packets with the CE in the ForCES router.
ForCES LFBライブラリ[LFB-LIB]で説明されているように、パケット転送は、パケットの処理パスを構成する一連のLFBクラスによって実装されます。このテストシナリオでは、図7に示すように、OSPFプロトコルを実行するForCESルーターが構築されました。さらに、RedirectIn、RedirectOut、IPv4UcastLPM、およびIPv4NextHopを含むLFBのセットが使用されました。 RedirectInおよびRedirectOut LFBは、CEとの間でOSPF HelloおよびLSAパケットをリダイレクトしました。 SmartBits [SmartBits]テストマシンを使用して、OSPFルーターをシミュレートし、OSPF HelloおよびLSAパケットをForCESルーターのCEと交換しました。
In Figure 7, cases (a) and (b) both need a RedirectIn LFB to send OSPF packets generated by the CE to the FE by use of ForCES packet redirect messages. The OSPF packets were further sent to an outside OSPF router by the FE via forwarding LFBs, including IPv4NextHop and IPv4UcastLPM. A RedirectOut LFB in the FE was used to send OSPF packets received from outside the OSPF router to the CE by ForCES packet redirect messages.
図7では、ケース（a）と（b）の両方で、CEによって生成されたOSPFパケットをForCESパケットリダイレクトメッセージを使用してFEに送信するためにRedirectIn LFBが必要です。 OSPFパケットは、IPv4NextHopおよびIPv4UcastLPMを含む転送LFBを介してFEによって外部OSPFルーターにさらに送信されました。 FEのRedirectOut LFBは、OSPFルーターの外部から受信したOSPFパケットをForCESパケットリダイレクトメッセージによってCEに送信するために使用されました。
By running OSPF, the CE in the ForCES router could generate new routes and load them to the routing table in the FE. The FE was then able to forward packets according to the routing table.
OSPFを実行することにより、ForCESルーターのCEは新しいルートを生成し、それらをFEのルーティングテーブルにロードできます。その後、FEはルーティングテーブルに従ってパケットを転送できました。
The test results are shown in Figure 10.
テスト結果を図10に示します。
+-----+----+-----+-------------------------+--------------+---------+
|Test#| CE |FE(s)| Item | LFBs Related | Result |
+-----+----+-----+-------------------------+--------------+---------+
| 1 | N | Z | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | |
| 2 | N | Z | IPv4PrefixTable SET | IPv4UcastLPM | Success |
| | | | | | |
| 3 | N | Z |Redirect OSPF packet from| RedirectIn | Success |
| | | | CE to SmartBits | | |
| | | | | | |
| 4 | N | Z |Redirect OSPF packet from| RedirectOut | Success |
| | | | SmartBits to CE | | |
| | | | | | |
| 5 | N | Z | Metadata in | RedirectOut | Success |
| | | | redirect message | RedirectIn | |
| | | | | | |
| 6 | N | Z | OSPF neighbor discovery | RedirectOut | Success |
| | | | | RedirectIn | |
| | | | | | |
| 7 | N | Z | OSPF DD exchange | RedirectOut | Success |
| | | | | RedirectIn | |
| | | | | IPv4NextHop | |
| | | | | | |
| 8 | N | Z | OSPF LSA exchange | RedirectOut | Success |
| | | | | RedirectIn | |
| | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| |
| | | | | | |
| 9 | N | Z | Data Forwarding | RedirectOut | Success |
| | | | | RedirectIn | |
| | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| |
| | | | | | |
| 10 | Z | N | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | |
| 11 | Z | N | IPv4PrefixTable SET | IPv4UcastLPM| Success |
| | | | | | |
| 12 | Z | N |Redirect OSPF packet from| RedirectIn | Success |
| | | | CE to other OSPF router | | |
| | | | | | |
| 13 | Z | N |Redirect OSPF packet from| RedirectOut | Success |
| | | |other OSPF router to CE | | |
| | | | | | |
| 14 | Z | N | Metadata in | RedirectOut | Success |
| | | | redirect message | RedirectIn | |
| | | | | | |
| 15 | Z | N |OSPF neighbor discovery | RedirectOut | Success |
| | | | | RedirectIn | |
| | | | | | |
| 16 | Z | N | OSPF DD exchange | RedirectOut | Failure |
| | | | | RedirectIn | |
| | | | | IPv4NextHop | |
| | | | | | |
| 17 | Z | N | OSPF LSA exchange | RedirectOut | Failure |
| | | | | RedirectIn | |
| | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| |
+-----+----+-----+-------------------------+--------------+---------+
Figure 10: Test Results for Packet Forwarding
図10：パケット転送のテスト結果
Note on tests #3 to #9:
テスト＃3から＃9に関する注意：
During the test, OSPF packets received from the CE were found by Ethereal/Wireshark to have checksum errors in the FE. Because the test time was quite limited, the implementer of the CE did not make an effort to find and solve the checksum error; instead, the FE had tried to correct the checksum in order to not let the SmartBits drop the packets. Note that such a solution does not affect the test results.
テスト中に、CEから受信したOSPFパケットは、Ethereal / Wiresharkにより、FEにチェックサムエラーがあることがわかりました。テスト時間が非常に限られていたため、CEの実装者はチェックサムエラーを見つけて解決するための努力をしませんでした。代わりに、FEはSmartBitsがパケットをドロップしないようにチェックサムを修正しようとしました。このようなソリューションはテスト結果に影響を与えないことに注意してください。
Comment on tests #16 and #17:
テスト＃16と＃17に関するコメント：
The two test items failed. Note that tests #7 and #8 were identical to tests #16 and #17, only with CE and FE implementers being exchanged. Moreover, tests #12 and #13 showed that the redirect channel worked well. Therefore, it can be reasonably inferred that the problem caused by the failure was from the implementations, rather than from the ForCES protocol itself or the misunderstanding of implementations on the protocol specification. Although the failure made the OSPF interoperability test incomplete, it did not show an interoperability problem. More test work is needed to verify the OSPF interoperability.
2つのテスト項目が失敗しました。テスト＃7と＃8は、テスト＃16と＃17と同じですが、CEとFEの実装者が交換されているだけです。さらに、テスト＃12および＃13は、リダイレクトチャネルが適切に機能することを示しました。したがって、障害によって引き起こされた問題は、ForCESプロトコル自体やプロトコル仕様の実装の誤解からではなく、実装から生じたものであると合理的に推測できます。障害によりOSPF相互運用性テストが不完全になりましたが、相互運用性の問題は示されませんでした。 OSPFの相互運用性を確認するには、さらにテスト作業が必要です。
On the first day of the test, it was found that the LFB interoperations pertaining to tables all failed. It was eventually found that the failure occurred because different data encapsulation methods for ForCES protocol messages were used by different implementations. The issue is described in detail below.
テストの初日に、テーブルに関連するLFB相互運用がすべて失敗したことがわかりました。 ForCESプロトコルメッセージのさまざまなデータカプセル化メソッドがさまざまな実装で使用されていたため、最終的に障害が発生したことがわかりました。この問題について、以下で詳しく説明します。
Assuming that an LFB has two components, one is a struct with ID=1 and the other is an array with ID=2; in addition, both have two components of u32 inside, as shown below:
LFBに2つのコンポーネントがあるとすると、1つはID = 1の構造体で、もう1つはID = 2の配列です。さらに、以下に示すように、どちらにも内部にu32の2つのコンポーネントがあります。
struct1: type struct, ID=1 components are: a, type u32, ID=1 b, type u32, ID=2
struct1：タイプstruct、ID = 1コンポーネントは次のとおりです：a、タイプu32、ID = 1 b、タイプu32、ID = 2
table1: type array, ID=2 components for each row are (a struct of): x, type u32, ID=1 y, type u32, ID=2
table1：各配列のID = 2コンポーネントは（構造体）：x、タイプu32、ID = 1 y、タイプu32、ID = 2です。
1. On Response of PATH-DATA-TLV Format
1. PATH-DATA-TLV形式の応答について
When a CE sends a config/query ForCES protocol message to an FE from a different implementer, the CE probably receives a response from the FE with a different PATH-DATA-TLV encapsulation format. For example, if a CE sends a query message with a path of 1 to a third-party FE to manipulate struct1 as defined above, it is probable that the FE will generate a response with two different PATH-DATA-TLV encapsulation formats: one is the value with FULLDATA-TLV/SPARSEDATA-TLV and the other is the value with many parallel PATH-DATA-TLVs and nested PATH-DATA-TLVs, as shown below:
CEが別の実装者からFEにconfig / query ForCESプロトコルメッセージを送信すると、CEはおそらく、異なるPATH-DATA-TLVカプセル化形式でFEから応答を受信します。たとえば、CEがパス1のクエリメッセージをサードパーティのFEに送信して、上記で定義されたstruct1を操作する場合、FEは2つの異なるPATH-DATA-TLVカプセル化形式で応答を生成する可能性があります。以下に示すように、FULLDATA-TLV / SPARSEDATA-TLVの値であり、もう1つは、多数の並列PATH-DATA-TLVとネストされたPATH-DATA-TLVの値です。
format 1: OPER = GET-RESPONSE-TLV PATH-DATA-TLV: IDs=1 FULLDATA-TLV containing valueof(a),valueof(b) format 2: OPER = GET-RESPONSE-TLV PATH-DATA-TLV: IDs=1 PATH-DATA-TLV: IDs=1 FULLDATA-TLV containing valueof(a) PATH-DATA-TLV: IDs=2 FULLDATA-TLV containing valueof(b)
形式1：OPER = GET-RESPONSE-TLV PATH-DATA-TLV：IDs = 1 valueof（a）、valueof（b）を含むFULLDATA-TLV形式2：OPER = GET-RESPONSE-TLV PATH-DATA-TLV：IDs = 1 PATH-DATA-TLV：IDs = 1 valueof（a）を含むFULLDATA-TLV PATH-DATA-TLV：IDs = 2 valueof（b）を含む
The interoperability testers witnessed that a ForCES element (CE or FE) sender is free to choose whatever data structure that IETF ForCES documents define and best suits the element, while a ForCES element (CE or FE) should be able to accept and process information (requests and responses) that use any legitimate structure defined by IETF ForCES documents. While in the case where a ForCES element is free to choose any legitimate data structure as a response, it is preferred that the ForCES element responds in the same format that the request was made, as it is most likely the data structure that the request sender looks to receive.
相互運用性テスターは、ForCES要素（CEまたはFE）の送信者は、IETF ForCESドキュメントが定義し、要素に最適なデータ構造を自由に選択できる一方、ForCES要素（CEまたはFE）は情報を受け入れて処理できる必要があることを確認しました（ IETF ForCESドキュメントで定義された正当な構造を使用する要求と応答）。 ForCES要素が正当なデータ構造を応答として自由に選択できる場合、ForCES要素は、要求が送信されたデータ構造である可能性が最も高いため、要求が行われたのと同じ形式で応答することが好ましい受け取るように見えます。
2. On Operation to Array
2. アレイの操作について
An array operation may also have several different data encapsulation formats. For instance, if a CE sends a config message to table1 with a path of (2.1), which refers to the component with ID=2 (an array), and the second ID is the row, then row 1 may be encapsulated with three formats as shown below:
配列操作には、いくつかの異なるデータカプセル化形式がある場合もあります。たとえば、CEが（2.1）のパスでtable1に構成メッセージを送信し、ID = 2（配列）のコンポーネントを参照し、2番目のIDが行である場合、行1は3つでカプセル化されます。以下に示すフォーマット：
format 1: OPER = SET-TLV PATH-DATA-TLV: IDs=2.1 FULLDATA-TLV containing valueof(x),valueof(y) format 2: OPER = SET-TLV PATH-DATA-TLV: IDs=2.1 PATH-DATA-TLV: IDs=1 FULLDATA-TLV containing valueof(x) PATH-DATA-TLV IDs=2 FULLDATA-TLV containing valueof(y)
形式1：OPER = SET-TLV PATH-DATA-TLV：IDs = 2.1 FULLDATA-TLV（valueof（x）、valueof（y）を含む）形式2：OPER = SET-TLV PATH-DATA-TLV：IDs = 2.1 PATH-DATA -TLV：IDs = 1 valueof（x）を含むFULLDATA-TLV PATH-DATA-TLV IDs = 2 valueof（y）を含むFULLDATA-TLV
Moreover, if the CE is targeting the whole array, for example, if the array is empty and the CE wants to add the first row to the table, it could also adopt another format:
さらに、CEが配列全体をターゲットにしている場合、たとえば、配列が空で、CEが最初の行をテーブルに追加したい場合は、別の形式を採用することもできます。
format 3:
OPER = SET-TLV
PATH-DATA-TLV:
IDs=2
FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y)
The interoperability test experience has shown that formats 1 and 3, which take full advantage of the multiple data elements description in one TLV of FULLDATA-TLV, are more efficient, although format 2 can also achieve the same operating goal.
相互運用性テストの経験では、FULLDATA-TLVの1つのTLVで複数のデータ要素の説明を最大限に活用するフォーマット1および3の方が効率的ですが、フォーマット2でも同じ動作目標を達成できます。
Developers of ForCES FEs and CEs must take the security considerations of the ForCES Framework [RFC3746] and ForCES Protocol Specification [RFC5810] into account. Also, as specified in the security considerations of SCTP-Based TML for the ForCES Protocol [RFC5811], the transport-level security has to be ensured by IPsec. Test results of TML with IPsec supported have been shown in Section 4.2 in this document.
ForCES FEおよびCEの開発者は、ForCESフレームワーク[RFC3746]およびForCESプロトコル仕様[RFC5810]のセキュリティに関する考慮事項を考慮する必要があります。また、ForCESプロトコル用のSCTPベースのTMLのセキュリティに関する考慮事項[RFC5811]で指定されているように、トランスポートレベルのセキュリティはIPsecによって確保する必要があります。 IPsecをサポートするTMLのテスト結果は、このドキュメントのセクション4.2に示されています。
The tests described in this document used only simple password security mode. Testing using more sophisticated security is for future study.
このドキュメントで説明するテストでは、単純なパスワードセキュリティモードのみを使用しました。より高度なセキュリティを使用したテストは、今後の検討課題です。
Further testing using key agility is encouraged. The tests reported here used SCTP TML running over an IPsec tunnel, which was established by Racoon. Key negotiation formed part of this process, but we believe that the SCTP TML used does not include key agility or renegotiation.
主要な俊敏性を使用したさらなるテストが推奨されます。ここで報告されたテストは、Racoonによって確立されたIPsecトンネル上で実行されるSCTP TMLを使用しました。キーネゴシエーションはこのプロセスの一部を形成しましたが、使用されるSCTP TMLにはキーアジリティまたは再ネゴシエーションが含まれていないと考えています。
[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、「転送および制御要素の分離（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] Hadi Salim、J。およびK. Ogawa、「Forwarding and Control Element Separation（ForCES）ProtocolのSCTPベースのトランスポートマッピングレイヤー（TML）」、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、「Forwarding and Control Element Separation（ForCES）Forwarding Element Model」、RFC 5812、2010年3月。
[RFC5813] Haas, R., "Forwarding and Control Element Separation (ForCES) MIB", RFC 5813, March 2010.
[RFC5813] Haas、R。、「Forwarding and Control Element Separation（ForCES）MIB」、RFC 5813、2010年3月。
[CEHA] Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES Intra-NE High Availability", Work in Progress, October 2010.
[CEHA] Ogawa、K.、Wang、W.、Haleplidis、E.、and J. Salim、 "ForCES Intra-NE High Availability"、Work in Progress、2010年10月。
[Ethereal] Fenggen, J., "Subject: Release of a test version of ForCES dissector based on Ethereal 0.99.0", message to the IETF forces mailing list, 11 June 2009, <http://www.ietf.org/mail-archive/web/forces/current/ msg03687.html>.
[Ethereal] Fenggen、J。、「件名：Ethereal 0.99.0に基づくForCESディセクタのテストバージョンのリリース」、IETFフォースメーリングリストへのメッセージ、2009年6月11日、<http://www.ietf.org/ mail-archive / web / forces / current / msg03687.html>。
[LFB-LIB] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "ForCES Logical Function Block (LFB) Library", Work in Progress, December 2010.
[LFB-LIB] Wang、W.、Haleplidis、E.、Ogawa、K.、Li、C.、J。Halpern、「ForCES論理関数ブロック（LFB）ライブラリ」、作業中、2010年12月。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H。およびT. Anderson、「IP Control and Forwardingの分離の要件」、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、「Forwarding and Control Element Separation（ForCES）Framework」、RFC 3746、2004年4月。
[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、「Forwarding and Control Element Separation（ForCES）の実装レポート」、RFC 6053、2010年11月。
[RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", RFC 6956, June 2013.
[RFC6956] Wang、W.、Haleplidis、E.、Ogawa、K.、Li、C。、およびJ. Halpern、「Forwarding and Control Element Separation（ForCES）Logical Function Block（LFB）Library」、RFC 6956、6月2013。
[Racoon] The NetBSD Foundation, "How to build a remote user access VPN with Racoon", <http://www.netbsd.org/docs/network/ipsec/rasvpn.html>.
[Racoon] The NetBSD Foundation、 "How to build a remote user access VPN with Racoon"、<http://www.netbsd.org/docs/network/ipsec/rasvpn.html>。
[SmartBits] Spirent Inc., "The Highly-Scalable Router Performance Tester: TeraRouting Tester", 2005, <http://www.spirent.com/~/media/Datasheets/Broadband/ Obsolete_SMB-TM/TeraRouting%20Tester.pdf>.
[SmartBits] Spirent Inc。、「The Highly Scalable Router Performance Tester：TeraRouting Tester」、2005、<http://www.spirent.com/~/media/Datasheets/Broadband/ Obsolete_SMB-TM / TeraRouting％20Tester.pdf >。
[Tcpdump] Hadi Salim, J., "Subject: tcpdump 4.1.1", message to the IETF forces mailing list, 20 May 2010, <http://www.ietf.org/mail-archive/web/forces/current/ msg03811.html>.
[Tcpdump] Hadi Salim、J。、「Subject：tcpdump 4.1.1」、IETFフォースメーリングリストへのメッセージ、2010年5月20日、<http://www.ietf.org/mail-archive/web/forces/current / msg03811.html>。
[TeamViewer] TeamViewer Inc., "TeamViewer - the All-In-One Software for Remote Support and Online Meetings", <http://www.teamviewer.com/>.
[TeamViewer] TeamViewer Inc。、「TeamViewer-リモートサポートとオンライン会議のためのオールインワンソフトウェア」、<http://www.teamviewer.com/>。
The authors thank the following test participants:
著者は、次のテスト参加者に感謝します。
Chuanhuang Li, Hangzhou BAUD Networks Ligang Dong, Zhejiang Gongshang University Bin Zhuge, Zhejiang Gongshang University Jingjing Zhou, Zhejiang Gongshang University Liaoyuan Ke, Hangzhou BAUD Networks Kelei Jin, Hangzhou BAUD Networks
チュアンファンリー、杭州BAUDネットワークリーガンドン、浙江公尚大学ビンジューゲ、浙江公尚大学景京周、浙江公尚大学遼源Ke、杭州BAUDネットワークスケイレイジン、杭州BAUDネットワークス
The authors also thank very much Adrian Farrel, Joel Halpern, Ben Campbell, Nevil Brownlee, and Sean Turner for their important help in the document publication process.
著者はまた、ドキュメントの公開プロセスにおける重要な助力に対して、Adrian Farrel、Joel Halpern、Ben Campbell、Nevil Brownlee、およびSean Turnerに大変感謝しています。
Contributors who have made major contributions to the interoperability test are listed below.
相互運用性テストに大きく貢献した貢献者を以下に示します。
Hirofumi Yamazaki NTT Corporation Tokyo Japan EMail: yamazaki.horofumi@lab.ntt.co.jp
ひろふみ やまざき んっｔ こｒぽらちおん ときょ じゃぱん えまいｌ： やまざき。ほろふみ＠ぁｂ。んっｔ。こ。ｊｐ
Rong Jin Zhejiang Gongshang University Hangzhou P.R. China EMail: jinrong@zjsu.edu.cn
Ronとjin Z Hejiangが農工大学杭州P.R.中国のメールアドレス：金融@在江苏。クォータ。人材
Yuta Watanabe NTT Corporation Tokyo Japan EMail: yuta.watanabe@ntt-at.co.jp
ゆた わたなべ んっｔ こｒぽらちおん ときょ じゃぱん えまいｌ： ゆた。わたなべ＠んっｔーあｔ。こ。ｊｐ
Xiaochun Wu Zhejiang Gongshang University Hangzhou P.R. China EMail: spring-403@zjsu.edu.cn
ξAO纯W u Z Hejiang go Agriculture and Industry University Hangzhou P.R. China email：spring-403 @在江苏。Quota。Talent
Authors' Addresses
著者のアドレス
Weiming Wang Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
Weiの名前Wang Z Hejiang go Agriculture and Industry University 18 X UE正通り、ξASha大学の町杭州310018 P.R.中国
Phone: +86-571-28877721
EMail: wmwang@zjsu.edu.cn
Kentaro Ogawa NTT Corporation Tokyo Japan
けんたろ おがわ んっｔ こｒぽらちおん ときょ じゃぱん
EMail: ogawa.kentaro@lab.ntt.co.jp
Evangelos Haleplidis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
エヴァンジェロスハレプリディスパトラス大学電気電子工学科パトラス26500ギリシャ
EMail: ehalep@ece.upatras.gr
Ming Gao Hangzhou BAUD Networks 408 Wen-San Road Hangzhou 310012 P.R. China
Ming Gao Hangzhou BAUD Networks 408 Wen-San Road Hangzhou 310012 P.R. China
EMail: gaoming@mail.zjgsu.edu.cn
Jamal Hadi Salim Mojatatu Networks Ottawa Canada
Jamal Hadi Saleem Mujtet Networksがカナダに来ました
EMail: hadi@mojatatu.com