draft-ietf-forces-interop-08.txt   draft-ietf-forces-interop-09.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Updates: 6053 (if approved) K. Ogawa Updates: 6053 (if approved) K. Ogawa
Intended status: Informational NTT Corporation Intended status: Informational NTT Corporation
Expires: November 24, 2013 E.H. Haleplidis Expires: December 04, 2013 E.H. Haleplidis
University of Patras University of Patras
M. Gao M. Gao
Hangzhou BAUD Networks Hangzhou BAUD Networks
J. Hadi Salim J. Hadi Salim
Mojatatu Networks Mojatatu Networks
May 23, 2013 June 02, 2013
Interoperability Report for Forwarding and Control Element Separation Interoperability Report for Forwarding and Control Element Separation
(ForCES) (ForCES)
draft-ietf-forces-interop-08 draft-ietf-forces-interop-09
Abstract Abstract
This document captured results of the second Forwarding and Control This document captures results of the second Forwarding and Control
Element Separation (ForCES) interoperability test which took place on Element Separation (ForCES) interoperability test which took place on
February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang
Gongshang University, China. RFC 6053 has reported the results of Gongshang University, China. RFC 6053 reported the results of the
the first ForCES interoperability test, and this document updates RFC first ForCES interoperability test, and this document updates RFC
6053 by providing further interoperability results. 6053 by providing further interoperability results.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2013. This Internet-Draft will expire on December 04, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 4 1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 4
1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4
1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Date, Location, and Participants . . . . . . . . . . . . 4 2.1. Date, Location, and Participants . . . . . . . . . . . . 4
2.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 5 2.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 5
2.2.1. Participants Access . . . . . . . . . . . . . . . . . 5 2.2.1. Participants Access . . . . . . . . . . . . . . . . . 5
2.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 6 2.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 6
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . 7 3.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . 7
3.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 8 3.2. Scenario 2 - TML with IPsec . . . . . . . . . . . . . . . 8
3.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 9 3.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 9
3.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . 10 3.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . 11
4. Test Results . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Test Results . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . 12 4.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . 13
4.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 18 4.2. TML with IPsec Test . . . . . . . . . . . . . . . . . . . 19
4.3. CE High Availability Test . . . . . . . . . . . . . . . . 19 4.3. CE High Availability Test . . . . . . . . . . . . . . . . 19
4.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . 19 4.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . 20
5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. On Data Encapsulation Format . . . . . . . . . . . . . . 22 5.1. On Data Encapsulation Format . . . . . . . . . . . . . . 22
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document captured results of the second interoperability test of This document captures results of the second interoperability test of
the Forwarding and Control Element Separation (ForCES) which took the Forwarding and Control Element Separation (ForCES) which took
place February 24-25, 2011 in the Internet Technology Lab (ITL) of place February 24-25, 2011 in the Internet Technology Lab (ITL) of
Zhejiang Gongshang University, China. The test involved protocol Zhejiang Gongshang University, China. The test involved protocol
elements described in several documents namely: elements described in several documents namely:
- ForCES Protocol [RFC5810] - ForCES Protocol [RFC5810]
- ForCES Forwarding Element (FE) Model [RFC5812] - ForCES Forwarding Element (FE) Model [RFC5812]
- ForCES Transport Mapping Layer (TML) [RFC5811] - ForCES Transport Mapping Layer (TML) [RFC5811]
The test also involved protocol elements described in the then- The test also involved protocol elements described in the then-
current versions of two Internet-Drafts. Although these documents current versions of two Internet-Drafts. Although these documents
have subsequently been revised and advanced, it is important to have subsequently been revised and advanced, it is important to
understand which versions of the work were used during this test. understand which versions of the work were used during this test.
The then-current Internet-Drafts are: The then-current Internet-Drafts are:
- ForCES Logical Function Block (LFB) Library - ForCES Logical Function Block (LFB) Library
[I-D.ietf-forces-lfb-lib-03]. [I-D.ietf-forces-lfb-lib-03].
- ForCES Intra-NE High Availability [I-D.ietf-forces-ceha-00]. - ForCES Intra-NE High Availability [I-D.ietf-forces-ceha-00].
Up to date, the 'ForCES Logical Function Block (LFB) Library' The 'ForCES Logical Function Block (LFB) Library' document has
document has been publilshed by IETF as RFC 6956. advanced and been published by IETF as RFC 6956.
Three independent ForCES implementations participated in the test. Three independent ForCES implementations participated in the test.
Scenarios of ForCES LFB Operation, TML with IPSec, CE High Scenarios of ForCES LFB Operation, TML with IPsec, CE High
Availability, and Packet Forwarding were constructed. Series of Availability, and Packet Forwarding were constructed. Series of
testing items for every scenario were carried out and testing items for every scenario were carried out and
interoperability results were achieved. Popular packet analyzers interoperability results were achieved. Popular packet analyzers
Ethereal/Wireshark[Ethereal] and Tcpdump[Tcpdump] were used to verify Ethereal/Wireshark[Ethereal] and Tcpdump[Tcpdump] were used to verify
the wire results. the wire results.
This document is an update to RFC 6053, which captured the results of This document is an update to RFC 6053, which captured the results of
the first ForCES interoperability test. The first test on ForCES was the first ForCES interoperability test. The first test on ForCES was
held in July 2008 at the University of Patras, Greece. That test held in July 2008 at the University of Patras, Greece. That test
focused on validating the basic semantics of the ForCES protocol and focused on validating the basic semantics of the ForCES protocol and
skipping to change at page 5, line 48 skipping to change at page 5, line 48
| ZJSU |-----| | /\/\/\/\/\ | |(TeamViewer) | ZJSU |-----| | /\/\/\/\/\ | |(TeamViewer)
+---------+ | | \Internet/ | | Mojatatu | +---------+ | | \Internet/ | | Mojatatu |
|LAN |----/ \--| +----------+ |LAN |----/ \--| +----------+
+---------+ | | \/\/\/\/\/ | +----------+ +---------+ | | \/\/\/\/\/ | +----------+
| FE/CE |-----| | | | FE/CE | | FE/CE |-----| | | | FE/CE |
| NTT | | | +---| UoP | | NTT | | | +---| UoP |
+---------+ +----+ +----------+ +---------+ +----+ +----------+
Figure 1: Access for Participants Figure 1: Access for Participants
As specified in RFC 5811, all CEs and FEs shall implement IPSec As specified in RFC 5811, all CEs and FEs shall implement IPsec
security in the TML. security in the TML.
On the internet boundary, gateways used must allow for IPSec, SCTP On the internet boundary, gateways used must allow for IPsec, SCTP
protocol and SCTP ports as defined in the ForCES SCTP-TML [RFC5811] . protocol and SCTP ports as defined in the ForCES SCTP-TML [RFC5811] .
2.2.2. Testbed Configuration 2.2.2. Testbed Configuration
CEs and FEs from ZJSU and NTT implementations were physically located CEs and FEs from ZJSU and NTT implementations were physically located
within the ITL Lab of Zhejiang Gongshang University and connected within the ITL Lab of Zhejiang Gongshang University and connected
together using Ethernet switches. The configuration can be seen in together using Ethernet switches. The configuration can be seen in
Figure 2. In the figure, the SmartBits was a third-party routing Figure 2. In the figure, the SmartBits is a third-party routing
protocol testing machine, which acted as a router running OSPF and protocol testing machine, which acts as a router running OSPF and RIP
RIP and exchanged routing protocol messages with ForCES routers in and exchanged routing protocol messages with ForCES routers in the
the network. Connection to the Internet was via an ADSL channel. network. Connection to the Internet was via an ADSL channel.
/\/\/\/\/\ /\/\/\/\/\
\Internet/ \Internet/
/ \ / \
\/\/\/\/\/ \/\/\/\/\/
| |
|(ADSL) |(ADSL)
| |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| LAN (10.20.0.0/24) | | LAN (10.20.0.0/24) |
skipping to change at page 7, line 9 skipping to change at page 7, line 9
CE and FE from the UoP implementation were located within the CE and FE from the UoP implementation were located within the
University of Patras, Greece, and were connected together using LAN University of Patras, Greece, and were connected together using LAN
as shown in Figure 3. Connection to the Internet was via a VPN as shown in Figure 3. Connection to the Internet was via a VPN
channel. channel.
/\/\/\/\/\ /\/\/\/\/\
\Internet/ \Internet/
/ \ / \
\/\/\/\/\/ \/\/\/\/\/
| |
|(VPN) |(VPN)
| |
+------------------------------------+ +------------------------------------+
| LAN | | LAN |
+------------------------------------+ +------------------------------------+
| | | | | |
| | | | | |
+------+ +--------+ +------+ +------+ +--------+ +------+
| FE | |Protocol| | CE | | FE | |Protocol| | CE |
| UoP | |Analyzer| | UoP | | UoP | |Analyzer| | UoP |
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Figure 3: Testbed Configuration Located in the University of Figure 3: Testbed Configuration Located in the University of
Patras,Greece Patras,Greece
The testbeds above were then able to satisfy requirements of all The testbeds above were then able to satisfy requirements of all
interoperability test scenarios in this document. interoperability test scenarios in this document.
3. Scenarios 3. Scenarios
3.1. Scenario 1 - LFB Operation 3.1. Scenario 1 - LFB Operation
This scenario is to test the interoperability on LFB operations among This scenario was to test the interoperability on LFB operations
the participants. The connection diagram for the participants is as among the participants. The connection diagram for the participants
shown in Figure 4. is as shown in Figure 4.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE |
| ZJSU | | NTT | | ZJSU | | UoP | | NTT | | UoP | | ZJSU | | NTT | | ZJSU | | UoP | | NTT | | UoP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE |
| NTT | | ZJSU | | UoP | | ZJSU | | UoP | | NTT | | NTT | | ZJSU | | UoP | | ZJSU | | UoP | | NTT |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 4: Scenario for LFB Operation Figure 4: Scenario for LFB Operation
In order to make interoperability more credible, the three In order to make interoperability more credible, the three
implementers were required to carry out the test in a way acting as implementers were required to carry out the test in a way acting as
CE or FE alternatively. As a result, every LFB operation was CE or FE alternatively. As a result, every LFB operation was
combined with 6 scenarios, as shown by Figure 4. combined with 6 scenarios, as shown by Figure 4.
The test scenario is designed with the following purposes: The test scenario was designed with the following purposes:
Firstly, the scenario is designed to verify all kinds of protocol Firstly, the scenario was designed to verify all kinds of protocol
messages with their complex data formats, which are defined in RFC messages with their complex data formats, which were defined in RFC
5810. Specially, we try to verify the data format of a PATH-DATA 5810. Specially, we tried to verify the data format of a PATH-DATA
with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array
or an array with a nested array. or an array with a nested array.
Secondly, the scenario is designed to verify the definition of ForCES Secondly, the scenario was designed to verify the definition of
LFB Library [I-D.ietf-forces-lfb-lib-03], which define a base set of ForCES LFB Library [I-D.ietf-forces-lfb-lib-03], which defined a base
ForCES LFB classes for typical router functions. Successful test set of ForCES LFB classes for typical router functions. Successful
under this scenario will help the validity of the LFB definitions. test under this scenario would help the validity of the LFB
definitions.
3.2. Scenario 2 - TML with IPSec 3.2. Scenario 2 - TML with IPsec
This scenario is designed to implement a TML with IPSec, which is the This scenario was designed to implement a TML with IPsec, which was
requirement by RFC 5811. TML with IPSec was not implemented and the requirement by RFC 5811. TML with IPsec was not implemented and
tested in the first ForCES interoperability test as reported by RFC tested in the first ForCES interoperability test as reported by RFC
6053. For this reason, in this interoperability test, we 6053. For this reason, in this interoperability test, we
specifically designed the test scenario to verify the TML over IPSec specifically designed the test scenario to verify the TML over IPsec
channel. channel.
In this scenario, tests on LFB operations for Scenario 1 are repeated In this scenario, tests on LFB operations for Scenario 1 were
with the difference that TML is secured via IPSec. This setup repeated with the difference that TML was secured via IPsec. This
scenario allows us to verify whether all interactions between CE and setup scenario allowed us to verify whether all interactions between
FE can be made correctly under an IPSec TML environment. CE and FE could be made correctly under an IPsec TML environment.
The connection diagram for this scenario is shown as Figure 5. The connection diagram for this scenario is shown as Figure 5.
Because an unfortunate problem with the test system in UoP prevented Because an unfortunate problem with the test system in UoP prevented
the deployment of IPSec over TML, this test only took place between the deployment of IPsec over TML, this test only took place between
the test systems in ZJSU and NTT. the test systems in ZJSU and NTT.
+------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE |
| ZJSU | | NTT | | ZJSU | | NTT |
+------+ +------+ +------+ +------+
| | | |
|TML over IPSec |TML over IPSec |TML over IPsec |TML over IPsec
+------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE |
| NTT | | ZJSU | | NTT | | ZJSU |
+------+ +------+ +------+ +------+
Figure 5: Scenario for LFB Operation with TML over IPSec Figure 5: Scenario for LFB Operation with TML over IPsec
In this scenario, ForCES TML is run over the IPSec channel. In this scenario, ForCES TML was run over the IPsec channel.
Implementers joined in this interoperability used the same third- Implementers joined in this interoperability used the same third-
party software 'Racoon' [Racoon] to establish the IPSec channel. The party software 'Racoon' [Racoon] to establish the IPsec channel.
'Racoon' in NetBSD is an IKE daemon performing the IPsec Key Exchange
(IKE) with the peers. The Racoon in NetBSD is an IKE daemon performing the IPsec Key
Exchange (IKE) with the peers. Both IKE v1 and v2 are supported by
Racoon in linux 2.6, and the v2 was adopted in the interop test. SAD
and SPD were necessary for the test, setups of which were in the
Racoon configuration file. ESP was specified in SAD and SPD in the
Racoon configuration file.
ZJSU and NTT made a successful test with the scenario, and the ZJSU and NTT made a successful test with the scenario, and the
following items were realized: following items were realized:
o Internet Key Exchange (IKE) with certificates for endpoint o Internet Key Exchange (IKE) with certificates for endpoint
authentication. authentication.
o Transport Mode Encapsulating Security Payload (ESP). HMAC-SHA1-96 o Transport Mode Encapsulating Security Payload (ESP), HMAC-SHA1-96
for message integrity protection. for message integrity protection.
3.3. Scenario 3 - CE High Availability 3.3. Scenario 3 - CE High Availability
CE High Availability (CEHA) is tested based on the ForCES CEHA CE High Availability (CEHA) was tested based on the ForCES CEHA
document [I-D.ietf-forces-ceha-00] document [I-D.ietf-forces-ceha-00]
The design of the setup and the scenario for the CEHA are simplified 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 are: so as to focus mostly on the mechanics of the CEHA, which were:
o Associating with more than one CE. o Associating with more than one CE.
o Switching to backup CE on master CE failure. o Switching to backup CE on master CE failure.
The connection diagram for the scenario is as shown in Figure 6. The connection diagram for the scenario is as shown in Figure 6.
master standby master standby master standby master standby
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE |
skipping to change at page 10, line 5 skipping to change at page 10, line 21
+----------+ +-----------+ +----------+ +-----------+
| | | |
+------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE |
| UoP | | UoP | | UoP | | UoP |
+------+ +------+ +------+ +------+
(a) (b) (a) (b)
Figure 6: Scenario for CE High Availability Figure 6: Scenario for CE High Availability
In this scenario one FE is connected and associated to a master 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 will be and a backup CE. In the pre-association phase, the FE would be
configured to have ZJSU's or NTT's CE as master CE and UoP's CE as configured to have ZJSU's or NTT's CE as master CE and UoP's CE as
standby CE. The CEFailoverPolicy component of the FE Protocol Object standby CE. The CEFailoverPolicy component of the FE Protocol Object
LFB that specifies whether the FE is in High Availability mode (value LFB that specified whether the FE was in High Availability mode
2 or 3) will either be set in the pre-association phase by the FEM (value 2 or 3) would either be set in the pre-association phase by
interface or in post-association phase by the master CE. the FEM interface or in post-association phase by the master CE.
If the CEFailoverPolicy value is set to 2 or 3, the FE (in the post- If the CEFailoverPolicy value was set to 2 or 3, the FE (in the post-
association phase) will attempt to connect and associate with the association phase) would attempt to connect and associate with the
standby CE. standby CE.
When the master CE is deemed disconnected, either by a TearDown, Loss When the master CE was deemed disconnected, either by a TearDown,
of Heartbeats or physically disconnected, the FE will assume that the Loss of Heartbeats or physically disconnected, the FE would assume
standby CE is now the master CE. The FE will then send an Event that the standby CE was now the master CE. The FE would then send an
Notification, Primary CE Down, to all associated CEs, only the Event Notification, Primary CE Down, to all associated CEs, only the
standby CE in this case, with the value of the new master CEID. The standby CE in this case, with the value of the new master CEID. The
standby CE will then respond by sending a configuration message to standby CE would then respond by sending a configuration message to
the CEID component of the FE Protocol Object with its own ID to the CEID component of the FE Protocol Object with its own ID to
confirm that the CE considers itself as the master as well. confirm that the CE considered itself as the master as well.
The steps of the CEHA test scenario are as follows: The steps of the CEHA test scenario were as follows:
1. In the pre-association phase, setup of FE with master CE and 1. In the pre-association phase, setup of FE with master CE and
backup CE backup CE
2. FE connecting and associating with master CE. 2. FE connecting and associating with master CE.
3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and 3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and
associate with backup CE. associate with backup CE.
4. Once the master CE is considered disconnected then the FE chooses 4. Once the master CE is considered disconnected then the FE chooses
skipping to change at page 10, line 48 skipping to change at page 11, line 17
5. It sends an Event Notification specifying that the master CE is 5. It sends an Event Notification specifying that the master CE is
down and who is now the master CE. down and who is now the master CE.
6. The new master CE sends a SET Configuration message to the FE 6. The new master CE sends a SET Configuration message to the FE
setting the CEID value to who is now the new master CE completing setting the CEID value to who is now the new master CE completing
the switch. the switch.
3.4. Scenario 4 - Packet forwarding 3.4. Scenario 4 - Packet forwarding
This test scenario is to verify LFBs like RedirectIn, RedirectOut, This test scenario was to verify LFBs like RedirectIn, RedirectOut,
IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library document IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library document
[I-D.ietf-forces-lfb-lib-03], and more importantly, to verify the [I-D.ietf-forces-lfb-lib-03], and more importantly, to verify the
combination of the LFBs to implement IP packet forwarding. combination of the LFBs to implement IP packet forwarding.
The connection diagram for this scenario is as Figure 7. The connection diagram for this scenario is as Figure 7.
+------+ +------+
| CE | | CE |
| NTT | | NTT |
+------+ +------+
skipping to change at page 18, line 31 skipping to change at page 19, line 5
Note on test #1 and #2: Note on test #1 and #2:
On the wire format of encapsulation on array, only the case of On the wire format of encapsulation on array, only the case of
FULLDATA vs SPARSEDATA was tested. FULLDATA vs SPARSEDATA was tested.
It is very common for CE to get information of FEobject LFB in FE so It is very common for CE to get information of FEobject LFB in FE so
as to know status on all active LFBs in the FE. Hence, the two tests as to know status on all active LFBs in the FE. Hence, the two tests
were specifically designed. were specifically designed.
4.2. TML with IPSec Test 4.2. TML with IPsec Test
In this scenario, the ForCES TML was run over IPSec. Implementers In this scenario, the ForCES TML was run over IPsec. Implementers
joined this interoperability test used the same third-party tool joined this interoperability test used the same third-party tool
software 'Racoon' [Racoon] to establish IPSec channel. Typical LFB software 'Racoon' [Racoon] to establish IPsec channel. Typical LFB
operation tests as in Scenario 1 were repeated with the IPSec enabled operation tests as in Scenario 1 were repeated with the IPsec enabled
TML. TML.
As mentioned, this scenario only took place between implementers of As mentioned, this scenario only took place between implementers of
ZJSU and NTT. ZJSU and NTT.
The TML with IPSec test results are reported by Figure 9. The TML with IPsec test results are reported by Figure 9.
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
|Test#| CE |FE(s)|Oper | LFB | Component/ | Result | |Test#| CE |FE(s)|Oper | LFB | Component/ | Result |
| | | | | | Capability | | | | | | | | Capability | |
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
| 1 | Z | N | GET | FEObject | LFBTopology | Success | | 1 | Z | N | GET | FEObject | LFBTopology | Success |
| | N | Z | | | | Success | | | N | Z | | | | Success |
| | | | | | | | | | | | | | | |
| 2 | Z | N | GET | FEObject | LFBSelectors | Success | | 2 | Z | N | GET | FEObject | LFBSelectors | Success |
| | N | Z | | | | Success | | | N | Z | | | | Success |
| | | | | | | | | | | | | | | |
| 3 | Z | N | SET | Ether | VlanInputTable | Success | | 3 | Z | N | SET | Ether | VlanInputTable | Success |
| | N | Z | | Classifier | | Success | | | N | Z | | Classifier | | Success |
| | | | | | | | | | | | | | | |
| 4 | Z | N | DEL | Ether | VlanInputTable | Success | | 4 | Z | N | DEL | Ether | VlanInputTable | Success |
| | N | Z | | Classifier | | Success | | | N | Z | | Classifier | | Success |
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
Figure 9: TML with IPSec Test Results Figure 9: TML with IPsec Test Results
4.3. CE High Availability Test 4.3. CE High Availability Test
In this scenario, one FE connected and associated with a master CE 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 and a backup CE. When the master CE was deemed disconnected, the FE
would attempt to find another associated CE to become the master CE. would attempt to find another associated CE to become the master CE.
The CEHA scenario as was described by Scenario 3 was completed The CEHA scenario as was described by Scenario 3 was completed
successfully for both setups. successfully for both setups.
skipping to change at page 20, line 9 skipping to change at page 20, line 32
As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib-03], As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib-03],
packet forwarding is implemented by a set of LFB classes that compose packet forwarding is implemented by a set of LFB classes that compose
a processing path for packets. In this test scenario, as shown in a processing path for packets. In this test scenario, as shown in
Figure 7, a ForCES router running OSPF protocol was constructed. In Figure 7, a ForCES router running OSPF protocol was constructed. In
addition, a set of LFBs including RedirectIn, RedirectOut, addition, a set of LFBs including RedirectIn, RedirectOut,
IPv4UcastLPM, and IPv4NextHop LFBs were used. RedirectIn and IPv4UcastLPM, and IPv4NextHop LFBs were used. RedirectIn and
RedirectOut LFBs redirected OSPF hello and LSA packets from and to RedirectOut LFBs redirected OSPF hello and LSA packets from and to
CE. A Smartbits test machine was used to simulate an OSPF router and CE. A Smartbits test machine was used to simulate an OSPF router and
exchange the OSPF hello and LSA packets with CE in ForCES router. exchange the OSPF hello and LSA packets with CE in ForCES router.
In Figure 7, case (a) and case (b) both needed a RedirectIn LFB to In Figure 7, case (a) and case (b) both need a RedirectIn LFB to send
send OSPF packets generated by CE to FE by use of ForCES packet OSPF packets generated by CE to FE by use of ForCES packet redirect
redirect messages. The OSPF packets were further sent to an outside messages. The OSPF packets were further sent to an outside OSPF
OSPF Router by the FE via forwarding LFBs including IPv4NextHop and Router by the FE via forwarding LFBs including IPv4NextHop and
IPv4UcastLPM LFBs. A RedirectOut LFB in the FE was used to send OSPF IPv4UcastLPM LFBs. A RedirectOut LFB in the FE was used to send OSPF
packets received from outside OSPF Router to CE by ForCES packet packets received from outside OSPF Router to CE by ForCES packet
redirect messages. redirect messages.
By running OSPF, the CE in the ForCES router could generate new By running OSPF, the CE in the ForCES router could generate new
routes and load them to routing table in FE. The FE was then able to routes and load them to routing table in FE. The FE was then able to
forward packets according to the routing table. forward packets according to the routing table.
The test results are as shown in Figure 10 The test results are as shown in Figure 10
skipping to change at page 21, line 47 skipping to change at page 22, line 21
The implementer found a multicast route pointing to localhost had to The implementer found a multicast route pointing to localhost had to
be manually set before a redirect channel could work normally. be manually set before a redirect channel could work normally.
Note on test #3 to #9: Note on test #3 to #9:
During the test, OSPF packets received from CE were found by Ethereal During the test, OSPF packets received from CE were found by Ethereal
/Wireshark with checksum errors in FE. Because the test time was /Wireshark with checksum errors in FE. Because the test time was
quite limited, implementer of the CE did not try to make efforts to quite limited, implementer of the CE did not try to make efforts to
find and solve the checksum error, instead, the FE had tried to find and solve the checksum error, instead, the FE had tried to
correct the checksum not to let the Smartbits drop the packets. Note correct the checksum in order not to let the Smartbits drop the
that such solution does not affect the test results for this packets. Note that such solution does not affect the test results.
scenario.
Comment on Test #16 and #17: Comment on Test #16 and #17:
The two test items failed. Note that Test #7 and #8 were identical The two test items failed. Note that Test #7 and #8 were identical
to the tests, only with CE and FE implementers were exchanged. to the two tests, only with CE and FE implementers were exchanged.
Moreover, test #12 and #13 showed that the redirect channel worked Moreover, test #12 and #13 showed that the redirect channel worked
well. Therefore, it can be reasonably inferred that the problem well. Therefore, it can be reasonably inferred that the problem
caused the failure was from the implementations, rather than from the caused the failure was from the implementations, rather than from the
ForCES protocol itself or from misunderstanding of implementations on ForCES protocol itself or from misunderstanding of implementations on
the protocol specification. Although the failure made the OSPF the protocol specification. Although the failure made the OSPF
interoperability test incomplete, it did not show interoperability interoperability test incomplete, it did not show interoperability
problem. More test work is needed to verify the OSPF problem. More test work is needed to verify the OSPF
interoperability. interoperability.
5. Discussions 5. Discussions
skipping to change at page 24, line 19 skipping to change at page 25, line 5
Moreover, if CE is targeting the whole array, for example if the Moreover, if CE is targeting the whole array, for example if the
array is empty and CE wants to add the first row to the table, it array is empty and CE wants to add the first row to the table, it
could also adopt another format: could also adopt another format:
format 3: format 3:
OPER = SET-TLV OPER = SET-TLV
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=2 IDs=2
FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y) FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y)
The interoperability test experience showed that format 1 and format The interoperability test experience has shown that format 1 and
3, which take full advantage of multiple data elements description in format 3, which take full advantage of multiple data elements
one TLV of FULLDATA-TLV, get more efficiency, although format 2 can description in one TLV of FULLDATA-TLV, get more efficiency, although
also get the same operating goal. format 2 can also get the same operating goal.
6. Contributors 6. Contributors
Contributors who have made major contributions to the Contributors who have made major contributions to the
interoperability test are as below: interoperability test are as below:
Hirofumi Yamazaki Hirofumi Yamazaki
NTT Corporation NTT Corporation
Tokyo Tokyo
Japan Japan
skipping to change at page 25, line 19 skipping to change at page 25, line 51
The authors thank the following test participants: The authors thank the following test participants:
Chuanhuang Li, Hangzhou BAUD Networks Chuanhuang Li, Hangzhou BAUD Networks
Ligang Dong, Zhejiang Gongshang University Ligang Dong, Zhejiang Gongshang University
Bin Zhuge, Zhejiang Gongshang University Bin Zhuge, Zhejiang Gongshang University
Jingjing Zhou, Zhejiang Gongshang University Jingjing Zhou, Zhejiang Gongshang University
Liaoyuan Ke, Hangzhou BAUD Networks Liaoyuan Ke, Hangzhou BAUD Networks
Kelei Jin, Hangzhou BAUD Networks Kelei Jin, Hangzhou BAUD Networks
The authors also thank very much to Adrian Farrel, Joel Halpern, Ben The authors also thank very much to Adrian Farrel, Joel Halpern, Ben
Campbell, and Nevil Brownlee for their important help in the document Campbell, Nevil Brownlee, and Sean Turner for their important help in
publication process. the document publication process.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
Developers of ForCES FEs and CEs must take the security Developers of ForCES FEs and CEs must take the security
considerations of the ForCES Framework [RFC3746] and the ForCES considerations of the ForCES Framework [RFC3746] and the ForCES
Protocol [RFC5810] into account. Also, as specified in the security Protocol [RFC5810] into account. Also, as specified in the security
considerations section of the SCTP-Based TML for the ForCES Protocol considerations section of the SCTP-Based TML for the ForCES Protocol
[RFC5811], the transport-level security has to be ensured by IPsec. [RFC5811], the transport-level security has to be ensured by IPsec.
Test results of TML with IPsec supported have been shown in Test results of TML with IPsec supported have been shown in
Section 4.2 in this document. Section 4.2 in this document.
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.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
 End of changes. 54 change blocks. 
95 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/