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
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)
转发和控制单元分离（部队）互操作性报告
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）进行的第二次转发和控制元素分离（ForCES）互操作性测试的结果。RFC 6053中报告了第一次部队互操作性测试的结果，本文档通过提供进一步的互操作性结果更新了RFC 6053。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/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.
版权所有（c）2013 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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:
本文件捕获了2011年2月24日至25日在中国浙江工商大学互联网技术实验室（ITL）进行的转发和控制元素分离（ForCES）第二次互操作性测试的结果。测试涉及多个文件中描述的协议元素，即：
- ForCES Protocol [RFC5810]
- 强制协议[RFC5810]
- ForCES Forwarding Element (FE) Model [RFC5812]
- 强制转发元素（FE）模型[RFC5812]
- ForCES Transport Mapping Layer (TML) [RFC5811]
- 部队传输映射层（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:
该测试还涉及当时两份互联网草案的最新版本中描述的协议元素。尽管这些文件随后进行了修订和改进，但了解测试期间使用了哪些版本的作品是很重要的。当时的互联网草案是：
- "ForCES Logical Function Block (LFB) Library" (December 2010) [LFB-LIB]
- “强制逻辑功能块（LFB）库”（2010年12月）[LFB-LIB]
- "ForCES Intra-NE High Availability" (October 2010) [CEHA]
- “东北地区部队内部高可用性”（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.
三个独立的部队参与了测试。
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.
构建了强制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.
本文档是对[RFC6053]的更新，它捕获了第一批部队互操作性测试的结果。第一次对军队的测试是在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
ForCES协议以主从模式工作，其中FEs为从设备，控制元件（CE）为主设备。该协议包括用于传输逻辑功能块（LFB）配置的命令
information, association setup, status, event notifications, etc. The reader is encouraged to read the ForCES protocol specification [RFC5810] for further information.
信息、关联设置、状态、事件通知等。鼓励读者阅读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.
部队传输映射层（TML）传输部队协议层消息。TML是处理如何实现传输级可靠性、拥塞控制、多播、排序等问题的地方。预计不止一个TML将标准化。RFC 5811规定了基于流控制传输协议（SCTP）的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]等。
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:
第二次部队互操作性测试会议由IETF部队工作组于2011年2月24日至25日举行，由Jamal Hadi Salim主持。三个独立的部队参与了测试：
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公司。为了简洁起见，本文档中将此实现称为“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.
另外两个组织Mojatatu Networks和杭州波特网络公司也参与了互操作性测试，他们分别扩展了两个不同的著名公共域协议分析器Ethereal/Wireshark[Ethereal]和Tcpdump[Tcpdump]。在测试期间，使用两个协议分析器来验证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.
互操作性测试发现了一些与部队文件相关的勘误表。还报告了相关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.
有时，互操作性测试是在两个而不是所有三个有代表性的实现之间进行的，因为第三个实现缺少特定的功能；然而，在随后的讨论中，所有实现者都提到他们将在将来实现任何缺失的特性。
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 |
+---------+ +----+ +------------+
+---------+ +----+ +------------+
| 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和FEs都在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].
在Internet边界上，使用的网关必须允许IPsec、SCTP协议和SCTP端口，如基于SCTP的TML文档[RFC5811]中所定义。
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实施的CEs和FEs实际位于浙江工商大学ITL实验室内，并使用以太网交换机连接在一起。配置如图2所示。在图中，SmartBits[SmartBits]是一台第三方路由协议测试机，充当运行开放最短路径优先（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|
+--------+ +--------------------------------------+ +--------+
/\/\/\/\/\
\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.
来自UOP实现的CE和FE位于希腊佩特雷大学，并使用LAN连接在一起，如图3所示。通过VPN通道连接到Internet。
/\/\/\/\/\
\Internet/
/ \
\/\/\/\/\/
|
|(VPN)
|
+------------------------------------+
| LAN |
+------------------------------------+
| | |
| | |
+------+ +--------+ +------+
| FE | |Protocol| | CE |
| UoP | |Analyzer| | UoP |
+------+ +--------+ +------+
/\/\/\/\/\
\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 |
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
| 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.
为了使互操作性更加可信，要求这三个实现者作为CE或FE交替执行测试。因此，每个LFB操作都与六个场景相结合，如图4所示。
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]中定义的具有复杂数据格式的各种协议消息。具体来说，我们尝试验证带有嵌套路径数据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.
此场景设计用于使用IPsec实现TML，这是RFC 5811定义的需求。如RFC 6053中所述，在第一次部队互操作性测试中未实现和测试带有IPsec的TML。因此，在这个互操作性测试中，我们专门设计了测试场景来验证IPsec通道上的TML。
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中的测试系统出现了一个不幸的问题，阻止了通过TML部署IPsec，因此该测试仅在ZJSU和NTT中的测试系统之间进行。
+------+ +------+
| CE | | CE |
| ZJSU | | NTT |
+------+ +------+
| |
|TML over IPsec |TML over IPsec
+------+ +------+
| FE | | FE |
| NTT | | ZJSU |
+------+ +------+
+------+ +------+
| 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:IPsec上TML的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.
在此场景中，强制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是一个Internet密钥交换（IKE）守护进程，它与对等方执行密钥交换。Linux 2.6中的Racoon支持IKEv1和IKEv2，互操作测试中采用了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高可用性（CEHA）是根据部队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)
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.
在此场景中，一个FE连接并关联到主CE和备份CE。在预关联阶段，FE将配置为ZJSU或NTT的CE作为主CE，UoP的CE作为备用CE。FE协议对象LFB的CEFailoverPolicy组件指定FE是否处于高可用性模式（值2或3），该组件将由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.
当主CE被认为断开连接时，无论是由于拆卸、心跳丢失还是物理断开，FE都会假定备用CE现在是主CE。FE随后将向所有关联的CE（在本例中仅为备用CE）发送事件通知（Primary CE Down），通知值为新的主控制元素ID（CEID）。然后，备用CE将通过向FE协议对象的CEID组件发送一条配置消息来进行响应，该消息具有其自己的ID，以确认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. 在预关联阶段，FE与主CE和备份CE一起设置。
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向FE发送SET配置消息；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]定义的LFB，如RedirectIn、RedirectOut、IPv4NextHop和IPv4UcastLPM，更重要的是，验证LFB的组合以实现IP数据包转发。
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 |
| 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 |
| 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)
+------+ +------+
| 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模拟发送和接收数据包。因此，强制路由器中的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的两个路由器，并将其连接到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）中，构建了两个ForCES路由器；一个是NTT的CE和ZJSU的FE，另一个是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 |
| | | | | | | |
+-----+----+-----+-----+--------------+-------------------+---------+
|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 |
| 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 |
| | | | | | | |
| | | | | | | |
| 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 |
| 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 |
| | | | | | | |
| | | | | | | |
| 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 |
+-----+----+-----+-----+--------------+-------------------+---------+
| 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与SPARA-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中的拓扑的信息。因此，专门进行了两次试验。
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.
在此场景中，部队TML通过IPsec运行。实施者加入了这个互操作性测试，并使用相同的第三方工具软件“Racoon”[Racoon]来建立IPsec通道。使用启用IPsec的TML重复场景1中的典型LFB操作测试。
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.
带有IPsec的TML测试结果如图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 |
+-----+----+-----+-----+--------------+-------------------+---------+
+-----+----+-----+-----+--------------+-------------------+---------+
|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.
在此场景中，一个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.
由于其中一个FEs中存在一个bug，因此发现了一个有趣的问题：据观察，出现bug的FE需要长达一秒钟的时间进行故障切换。最终发现该问题是由于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:
虽然bug已经修复，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与主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 library[LFB-LIB]中所述，数据包转发由一组LFB类实现，这些LFB类构成数据包的处理路径。在这个测试场景中，如图7所示，构建了一个运行OSPF协议的ForCES路由器。此外，还使用了一组LFB，包括RedirectIn、RedirectOut、IPv4UcastLPM和IPv4NextHop。RedirectIn和RedirectOut LFBs将OSPF Hello和LSA数据包从CE重定向到CE。SmartBits[SmartBits]测试机用于模拟OSPF路由器，并与ForCES路由器中的CE交换OSPF Hello和LSA数据包。
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）都需要在LFB中使用重定向来使用ForCES分组重定向消息将CE生成的OSPF分组发送给FE。FE通过转发LFB（包括IPv4NextHop和IPv4ucastpm）将OSPF数据包进一步发送到外部OSPF路由器。FE中的重定向输出LFB用于通过强制数据包重定向消息将从OSPF路由器外部接收的OSPF数据包发送到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 | |
+-----+----+-----+-------------------------+--------------+---------+
|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| |
+-----+----+-----+-------------------------+--------------+---------+
| | | | | | |
| 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.
在测试期间，Ethereal/Wireshark发现从CE接收的OSPF数据包在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.
这两项测试都失败了。请注意，测试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有两个组件，一个是ID=1的结构，另一个是ID=2的数组；此外，两者内部都有两个u32组件，如下所示：
struct1: type struct, ID=1 components are: a, type u32, ID=1 b, type u32, ID=2
struct1:type struct，ID=1组件是：a，type u32，ID=1b，type 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
表1：类型数组，ID=2每行的组件是（一个结构）：x，类型u32，ID=1y，类型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发送配置/查询强制协议消息时，CE可能会从FE接收到具有不同PATH-DATA-TLV封装格式的响应。例如，如果CE向第三方FE发送路径为1的查询消息，以操作上文定义的struct1，FE可能会使用两种不同的PATH-DATA-TLV封装格式生成响应：一种是FULLDATA-TLV/SPARA-TLV的值，另一种是多个并行路径数据TLV和嵌套路径数据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 FULLDATA-TLV包含值（a），值（b）格式2:OPER=GET-RESPONSE-TLV PATH-DATA-TLV:IDs=1 PATH-DATA-TLV:IDs=1 FULLDATA-TLV包含值（a）PATH-DATA-TLV:IDs=2 FULLDATA-TLV包含值（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
互操作性测试人员见证了ForCES元素（CE或FE）发送者可以自由选择IETF ForCES文档定义并最适合该元素的任何数据结构，而ForCES元素（CE或FE）应该能够接受和处理信息（请求和响应）使用IETF文件定义的任何合法结构。而在力元素是自由的情况下
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元素以与请求相同的格式响应，因为它很可能是请求发送方希望接收的数据结构。
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向table1发送一条路径为（2.1）的配置消息，该路径指的是ID=2的组件（一个数组），第二个ID是行，那么行1可以用三种格式封装，如下所示：
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包含（x）的值，valueof（y）格式2:OPER=SET-TLV PATH-DATA-TLV:IDs=2.1 PATH-DATA-TLV:IDs=1 FULLDATA-TLV包含（x）的值PATH-DATA-TLV IDs=2 FULLDATA-TLV包含（y）的值
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)
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.
互操作性测试经验表明，格式1和3充分利用FULLDATA-TLV的一个TLV中的多个数据元素描述，效率更高，尽管格式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.
部队FEs和CEs的开发人员必须考虑部队框架[RFC3746]和部队协议规范[RFC5810]的安全考虑。此外，根据部队协议[RFC5811]基于SCTP的TML安全注意事项中的规定，必须通过IPsec确保传输级安全。本文件第4.2节显示了支持IPsec的TML的测试结果。
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隧道上的sctptml。关键协商是该过程的一部分，但我们认为，使用的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，“转发和控制元件分离（部队）协议规范”，RFC 58102010年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，“转发和控制元素分离（ForCES）协议的基于SCTP的传输映射层（TML）”，RFC 58112010年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，“转发和控制单元分离（部队）转发单元模型”，RFC 5812，2010年3月。
[RFC5813] Haas, R., "Forwarding and Control Element Separation (ForCES) MIB", RFC 5813, March 2010.
[RFC5813]Haas，R.，“转发和控制单元分离（部队）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.，和J.Salim，“东北方向内的部队高可用性”，正在进行的工作，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 ForCES邮件列表的信息，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，“部队逻辑功能块（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控制和转发分离的要求”，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，“转发和控制单元分离（部队）框架”，RFC 37462004年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，“转发和控制分队（部队）实施报告”，RFC 60532010年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，“转发和控制元件分离（部队）逻辑功能块（LFB）库”，RFC 69562013年6月。
[Racoon] The NetBSD Foundation, "How to build a remote user access VPN with Racoon", <http://www.netbsd.org/docs/network/ipsec/rasvpn.html>.
[Rracon ] NETBSD基金会，“如何用R浣熊构建远程用户访问VPN”，<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.，“高度可扩展路由器性能测试仪：TeraRouting测试仪”，2005年<http://www.spirent.com/~/media/Datasheets/Broadband/observate\u SMB-TM/terarrouting%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.，“主题：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
李传煌、杭州波特网络李刚东、浙江工商大学诸葛斌、浙江工商大学荆州、浙江工商大学客源、杭州波特网络科雷金、杭州波特网络
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
Hirofumi Yamazaki NTT Corporation东京日本电子邮件：Yamazaki。horofumi@lab.ntt.co.jp
Rong Jin Zhejiang Gongshang University Hangzhou P.R. China EMail: jinrong@zjsu.edu.cn
荣进浙江工商大学杭州中华人民共和国电子邮件：jinrong@zjsu.edu.cn
Yuta Watanabe NTT Corporation Tokyo Japan EMail: yuta.watanabe@ntt-at.co.jp
渡边Yuta NTT公司东京日本电子邮件：Yuta。watanabe@ntt-at.co.jp
Xiaochun Wu Zhejiang Gongshang University Hangzhou P.R. China EMail: spring-403@zjsu.edu.cn
吴晓春浙江工商大学杭州中华人民共和国电子邮件：spring-403@zjsu.edu.cn
Authors' Addresses
作者地址
Weiming Wang Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
王伟明浙江工商大学中国杭州下沙大学城学政街18号310018
Phone: +86-571-28877721
EMail: wmwang@zjsu.edu.cn
Phone: +86-571-28877721
EMail: wmwang@zjsu.edu.cn
Kentaro Ogawa NTT Corporation Tokyo Japan
日本东京小川健太郎NTT公司
EMail: ogawa.kentaro@lab.ntt.co.jp
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
EMail: ehalep@ece.upatras.gr
Ming Gao Hangzhou BAUD Networks 408 Wen-San Road Hangzhou 310012 P.R. China
中国杭州市文三路408号明高杭州波特网络有限公司310012
EMail: gaoming@mail.zjgsu.edu.cn
EMail: gaoming@mail.zjgsu.edu.cn
Jamal Hadi Salim Mojatatu Networks Ottawa Canada
加拿大渥太华Jamal Hadi Salim Mojatatu网络公司
EMail: hadi@mojatatu.com
EMail: hadi@mojatatu.com