draft-ietf-forces-interop-01.txt   draft-ietf-forces-interop-02.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Intended status: Informational K. Ogawa Intended status: Informational K. Ogawa
Expires: September 15, 2011 NTT Corporation Expires: January 12, 2012 NTT Corporation
E. Haleplidis E. 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
March 14, 2011 July 11, 2011
Interoperability Report for Forwarding and Control Element Separation Interoperability Report for Forwarding and Control Element Separation
(ForCES) (ForCES)
draft-ietf-forces-interop-01 draft-ietf-forces-interop-02
Abstract Abstract
This document captures test results from the second Forwarding and This document captures test results from the second Forwarding and
control Element Separation (ForCES) interop testing which took place control Element Separation (ForCES) interoperability test which took
on March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang place on February 24-25, 2011 in the Internet Technology Lab (ITL) of
Gongshang University in China. Zhejiang Gongshang University, China.
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 September 15, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 3
1.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 3
1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 3
1.4. CE HA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Date, Location, and Participants . . . . . . . . . . . . . 7
3.1. Date, Location, and Participants . . . . . . . . . . . . . 8 3.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 7
3.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 8 3.2.1. Participants Access . . . . . . . . . . . . . . . . . 7
3.2.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 8
3.2.2. Local Configuration . . . . . . . . . . . . . . . . . 9 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Distributed Configuration . . . . . . . . . . . . . . 10 4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 11
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 11
4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 12 4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 12
4.1.1. Connection Diagram . . . . . . . . . . . . . . . . . . 12 4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 14
4.1.2. Design Considerations . . . . . . . . . . . . . . . . 12 5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 12 5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 17
4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 12 5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 22
4.2.1. Connection Diagram . . . . . . . . . . . . . . . . . . 13 5.3. CE High Availability Test . . . . . . . . . . . . . . . . 23
4.2.2. Design Considerations . . . . . . . . . . . . . . . . 13 5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 24
4.2.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 14 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 14 6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 27
4.3.1. Connection Diagram . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2. Design Considerations . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
4.4.1. Connection Diagram . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2. Design Considerations . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34
4.4.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 34
5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 19
5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 24
5.3. CE High Availability Test . . . . . . . . . . . . . . . . 25
5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 26
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 29
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This document captures the results of the second interoperability This document captures the results of the second interoperability
test of the Forwarding and control Element Separation (ForCES) test of the Forwarding and control Element Separation (ForCES)
Framework which took place March 24-25, 2011 in the Internet Framework which took place February 24-25, 2011 in the Internet
Technology Lab (ITL) of Zhejiang Gongshang University in China. The Technology Lab (ITL) of Zhejiang Gongshang University, China. The
tests involved several documents namely: ForCES protocol [RFC5810], test involved several documents namely: ForCES protocol [RFC5810],
ForCES FE model [RFC5812], ForCES TML [RFC5811], ForCES LFB Library ForCES FE model [RFC5812], ForCES TML [RFC5811], ForCES LFB Library
[FORCES-LFBLIB] and ForCES CE HA specification[FORCES-CEHA]. Three [I-D.ietf-forces-lfb-lib] and ForCES CE HA specification
independent ForCES implementations participated in the test. [I-D.ietf-forces-ceha] 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 are constructed. Series of Availability, and Packet Forwarding are constructed. Series of
testing items for every scenario are carried out and interoperability testing items for every scenario are carried out and interoperability
results are achieved. Extended Wireshark and extended tcpdump are results are achieved. Extended Wireshark and extended tcpdump are
used to verify the results. used to verify the results.
The first interop test held in July 2008 at the University of Patras, The first interoperability test on ForCES was held in July 2008 at
Greece, focussed on validating the basic semantics of the protocol the University of Patras, Greece. The test focussed on validating
and model[RFC6053]. the basic semantics of the ForCES protocol and ForCES FE model. The
test results were captured by RFC 6053[RFC6053].
1.1. ForCES Protocol 1.1. ForCES Protocol
The ForCES protocol works in a master-slave mode in which FEs are The ForCES protocol works in a master-slave mode in which FEs are
slaves and CEs are masters. The protocol includes commands for slaves and CEs are masters. The protocol includes commands for
transport of Logical Function Block (LFB) configuration information, transport of Logical Function Block (LFB) configuration information,
association setup, status, and event notifications, etc. The reader association setup, status, and event notifications, etc. The reader
is encouraged to read FE-protocol [RFC5810] for further information. is encouraged to read the ForCES protocol specification RFC 5810
[RFC5810] for further information.
1.2. ForCES Model 1.2. ForCES FE Model
The FE-MODEL [RFC5811] presents a formal way to define FE Logical The ForCES FE modelRFC 5812 [RFC5812] presents a formal way to define
Function Blocks (LFBs) using XML. LFB configuration components, FE Logical Function Blocks (LFBs) using XML. LFB configuration
capabilities, and associated events are defined when the LFB is components, capabilities, and associated events are defined when the
formally created. The LFBs within the FE are accordingly controlled LFB is formally created. The LFBs within the FE are accordingly
in a standardized way by the ForCES protocol. controlled in a standardized way by the ForCES protocol.
1.3. Transport Mapping Layer 1.3. Transport Mapping Layer
The TML transports the PL messages. The TML is where the issues of The ForCES Transport Mapping Layer (TML) transports the ForCES
how to achieve transport level reliability, congestion control, Protocol Layer (PL) messages. The TML is where the issues of how to
multicast, ordering, etc. are handled. It is expected that more than achieve transport level reliability, congestion control, multicast,
one TML will be standardized. The various possible TMLs could vary ordering, etc are handled. It is expected that more than one TML
their implementations based on the capabilities of underlying media will be standardized. The various possible TMLs could vary their
and transport. However, since each TML is standardized, implementations based on the capabilities of underlying media and
interoperability is guaranteed as long as both endpoints support the transport. However, since each TML is standardized, interoperability
same TML. All ForCES Protocol Layer implementations MUST be portable is guaranteed as long as both endpoints support the same TML. All
across all TMLs. Although more than one TML may be standardized for ForCES Protocol Layer implementations MUST be portable across all
the ForCES Protocol, for the purposes of the interoperability test, TMLs. Although more than one TML may be standardized for the ForCES
the mandated MUST IMPLEMENT SCTP TML [RFC5811] will be used. Protocol, for the purposes of the interoperability test, the mandated
MUST IMPLEMENT SCTP TML [RFC5811] will be used.
1.4. CE HA
2. Terminology and Conventions 2. Terminology and Conventions
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Definitions 2.2. Definitions
This document follows the terminology defined by ForCES related This document follows the terminology defined by ForCES related
documents, including RFC3654, RFC3746, documents, including RFC3654, RFC3746, RFC5810, RFC5811, RFC5812,
RFC5810,RFC5811,RFC5812,RFC5812. Some definitions are repeated below RFC5813, etc. Some definitions are repeated below for clarity.
for clarity.
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of packets. CEs handle functionality such as the execution of
control and signaling protocols. control and signaling protocols.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by one or packet processing and handling as directed/controlled by one or
more CEs via the ForCES protocol. more CEs via the ForCES protocol.
skipping to change at page 7, line 9 skipping to change at page 6, line 9
LFB Metadata - Metadata is used to communicate per-packet state LFB Metadata - Metadata is used to communicate per-packet state
from one LFB to another, but is not sent across the network. The from one LFB to another, but is not sent across the network. The
FE model defines how such metadata is identified, produced, and FE model defines how such metadata is identified, produced, and
consumed by the LFBs. It defines the functionality but not how consumed by the LFBs. It defines the functionality but not how
metadata is encoded within an implementation. metadata is encoded within an implementation.
LFB Components - Operational parameters of the LFBs that must be LFB Components - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB visible to the CEs are conceptualized in the FE model as the LFB
components. The LFB components include, for example, flags, components. The LFB components include, for example, flags,
single-parameter arguments, complex arguments, and tables that the single-parameter arguments, complex arguments, and tables that the
CE can read and/or write via the ForCES protocol (see below). CE can read and/or write via the ForCES protocol.
ForCES Protocol - While there may be multiple protocols used ForCES Protocol - While there may be multiple protocols used
within the overall ForCES architecture, the term "ForCES protocol" within the overall ForCES architecture, the term "ForCES protocol"
and "protocol" refer to the "Fp" reference points in the ForCES and "protocol" refer to the "Fp" reference points in the ForCES
framework in [RFC3746]. This protocol does not apply to CE-to-CE framework in [RFC3746]. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between communication, FE-to-FE communication, or to communication between
FE and CE managers. Basically, the ForCES protocol works in a FE and CE managers. Basically, the ForCES protocol works in a
master-slave mode in which FEs are slaves and CEs are masters. master-slave mode in which FEs are slaves and CEs are masters.
ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
skipping to change at page 8, line 9 skipping to change at page 7, line 9
message transportation issues, such as how the protocol messages message transportation issues, such as how the protocol messages
are mapped to different transport media (like TCP, IP, ATM, are mapped to different transport media (like TCP, IP, ATM,
Ethernet, etc.), and how to achieve and implement reliability, Ethernet, etc.), and how to achieve and implement reliability,
multicast, ordering, etc. The ForCES TML specifications are multicast, ordering, etc. The ForCES TML specifications are
detailed in separate ForCES documents, one for each TML. detailed in separate ForCES documents, one for each TML.
3. Overview 3. Overview
3.1. Date, Location, and Participants 3.1. Date, Location, and Participants
The ForCES interoperability test meeting was held by IETF ForCES The second ForCES interoperability test meeting was held by IETF
working group on March 24-25, 2011, and was chaired by Jamal Hadi ForCES Working Group on February 24-25, 2011, and was chaired by
Salim, the current ForCES working group co-chair. Three independent Jamal Hadi Salim, the current ForCES Working Group co-chair. Three
ForCES implementations participated in the test: independent ForCES implementations participated in the test:
* Zhejiang Gongshang University/Hangzhou BAUD Networks, China. This * Zhejiang Gongshang University/Hangzhou BAUD Corparation of
implementation is referred to as "China" or in some cases "C" in the Inforamtion and Networks Technology (Hangzhou BAUD Networks), China.
document for the sake of brevity. This implementation is referred to as "China" or in some cases "C" in
the document for the sake of brevity.
* NTT Corporation, Japan. This implementation is referred to as * NTT Corporation, Japan. This implementation is referred to as
"Japan" or in some cases "J" in the document for the sake of brevity. "Japan" or in some cases "J" in the document for the sake of brevity.
* The University of Patras, Greece. This implementation is referred * The University of Patras, Greece. This implementation is referred
to as "Greece" or in some cases "G" in the document for the sake of to as "Greece" or in some cases "G" in the document for the sake of
brevity. brevity.
During the interoperability test, protocol analyzers Wireshark and Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks
tcpdump were used to verify the validity of ForCES protocol messages Corporation, which independently extended two different well known
and in some cases semantics. public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and
Tcpdump [Tcpdump], also participated in the interop test. During the
interoperability test, the two protocol analyzers were used to verify
the validity of ForCES protocol messages and in some cases semantics.
Some issues related to interoperability among implementations were Some issues related to interoperability among implementations were
discovered. Most of the issues were solved on site during the test. discovered. Most of the issues were solved on site during the test.
The most contentious issue found was on the format of encapsulation The most contentious issue found was on the format of encapsulation
for protocol TLV (Refer to Section 6). for protocol TLV (Refer to Section 6.1).
Some errata related to ForCES document were found by the Some errata related to ForCES document were found by the
interoperability test. The errata will be reported to related IETF interoperability test. The errata has been reported to related IETF
RFCs. RFCs.
At times, interoperability testing was exercised between 2 instead of At times, interoperability testing was exercised between 2 instead of
all three representative implementations due to the third one lacking all three representative implementations due to the third one lacking
a specific feature; however, in ensuing discussions, all implementors a specific feature; however, in ensuing discussions, all implementors
mentioned they will be implementing any missing features in the mentioned they will be implementing any missing features in the
future. future.
3.2. Testbed Configuration 3.2. Testbed Configuration
3.2.1. Access 3.2.1. Participants Access
Japan and China physically attended on site at the Internet Japan and China physically attended on site at the Internet
Technology Lab (ITL) of Zhejiang Gongshang University in China. The Technology Lab (ITL) of Zhejiang Gongshang University in China. The
University of Patras implementation joined remotely from Greece. The University of Patras implementation joined remotely from Greece. The
chair, Jamal Hadi Salim, joined remotely from Canada by using the chair, Jamal Hadi Salim, joined remotely from Canada by using the
teamviewer tool [ref XXX]. The approach is as shown in figure 1. In Teamviewer as the monitoring tool. The approach is as shown in
the figure, FE/CE refers to FE or CE that the implementor may act Figure 1. In the figure, FE/CE refers to FE or CE that the
alternatively. implementor may act alternatively.
+---------+ +----+ +----------+ +---------+ +----+ +----------+
| FE/CE | | | +---|TeamViewer| | FE/CE | | | +---|Monitoring|
| China |-----| | /\/\/\/\/\ | | Canada | | China |-----| | /\/\/\/\/\ | |(TeamViewer)
+---------+ | | \Internet/ | +----------+ +---------+ | | \Internet/ | | Canada |
|LAN |----/ \--| |LAN |----/ \--| +----------+
+---------+ | | \/\/\/\/\/ | +----------+ +---------+ | | \/\/\/\/\/ | +----------+
| FE/CE |-----| | | | FE/CE | | FE/CE |-----| | | | FE/CE |
| Japan | | | +---| Greece | | Japan | | | +---| Greece |
+---------+ +----+ +----------+ +---------+ +----+ +----------+
Figure 1: The Approach for all Participants Figure 1: Access for Participants
For interoperability test items, all CEs and FEs SHALL implement All CEs and FEs SHALL implement IPSec security in the TML. For
IPSEC security in the TML. For security, firewalls MUST be used that security, firewalls MUST be used that will allow only the specific
will allow only the specific IPs and the SCTP ports defined in the IPs and the SCTP ports defined in the ForCES SCTP-TML [RFC5811].
ForCES SCTP-TML [RFC5811].
3.2.2. Local Configuration 3.2.2. Testbed Configuration
Hardwares and softwares including CEs and FEs from China and Japan Hardwares and softwares including CEs and FEs from China and Japan
implementions that were located within the ITL Lab of Zhejiang implementions that were located within the ITL Lab of Zhejiang
Gongshang University, were connected together using ethernet Gongshang University, were connected together using Ethernet
switches. The configuration can be seen in figure 2. switches. The configuration can be seen in Figure 2. In the figure,
the SmartBits is a third-party supplied routing protocol testing
machine, which acts as a router running OSPF and RIP and exchanges
routing protocol messages with ForCES routers in the network. The
Internet is connected via an ADSL channel.
/\/\/\/\/\ /\/\/\/\/\
\Internet/ \Internet/
/ \ / \
\/\/\/\/\/ \/\/\/\/\/
| |
|124.90.146.218 (ADSL) |124.90.146.218 (ADSL)
| |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| LAN (10.20.0.0/24) | | LAN (10.20.0.0/24) |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | | | | | | | | | | |
| | | | | | | | | | | |
|.222 |.230 |.221 |.179 |.231 |.220 |.222 |.230 |.221 |.179 |.231 |.220
+-----+ +-----+ +-----+ +-----+ +-----+ +---------+ +-----+ +-----+ +-----+ +-----+ +-----+ +---------+
| CE | | CE | | | | | | | | Protocol| | CE | | CE | | | | | | | | Protocol|
|China| |Japan| | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer| |China| |Japan| | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer|
+-----+ +-----+ |China|---------|Japan|----------|China| +---------+ +-----+ +-----+ |China|---------|Japan|----------|China| +---------+
+---------| | | | | |-------+ +---------| |192.169. | | 192.168. | |-------+
| .2 +-----+ ^ +-----+ ^ +-----+ .2 | | .2 +-----+ 20.0.24 +-----+ 30.0/24 +-----+ .2 |
| .12|192.168.20.0/24 192.168.30.0/24 |.12 | | .12| |.12 |
| | | | | | | |
192.168.50.0/24 | | 192.168.50.0/24 192.168.50.0/24 | | 192.168.60.0/24
| 192.168.10.0/24 192.168.40.0/24 | | 192.168.10.0/24 192.168.40.0/24 |
.1 | |.11 |.11 |.1 .1 | |.11 |.11 |.1
+--------+ +---------------------------------------+ +--------+ +--------+ +---------------------------------------+ +--------+
|Terminal| | Smartbits | |Terminal| |Terminal| | Smartbits | |Terminal|
+--------+ +---------------------------------------+ +--------+ +--------+ +---------------------------------------+ +--------+
Figure 2: Testbed Configuration Located in ITL Lab,China Figure 2: Testbed Configuration Located in ITL Lab,China
3.2.3. Distributed Configuration Hardwares and Softwares (CE and FE) of Greece that were located
within the University of Patras, Greece, were connected together
Hardware/Software (CE and FE) of Greece that were located within the using LAN as shown in Figure 3. The Internet is connected via a VPN
University of Patras premises,were connected together using LAN as channel.
shown in figure 3.
/\/\/\/\/\ /\/\/\/\/\
\Internet/ \Internet/
/ \ / \
\/\/\/\/\/ \/\/\/\/\/
| |
|150.140.254.110(VPN) |150.140.254.110(VPN)
| |
+------------------------------------+ +------------------------------------+
| LAN | | LAN |
skipping to change at page 11, line 25 skipping to change at page 10, line 25
| | | | | |
| | | | | |
+------+ +--------+ +------+ +------+ +--------+ +------+
| FE | |Protocol| | CE | | FE | |Protocol| | CE |
|Greece| |Analyzer| |Greece| |Greece| |Analyzer| |Greece|
+------+ +--------+ +------+ +------+ +--------+ +------+
Figure 3: Testbed Configuration Located in the University of Figure 3: Testbed Configuration Located in the University of
Patras,Greece Patras,Greece
Above configuations can satisfy requirements of all scenarios that Above Testbed configuations can satisfy requirements of all the
are mentioned in this document. interoperability test scenarios that are mentioned in this document.
4. Scenarios 4. Scenarios
4.1. Scenario 1 - LFB Operation 4.1. Scenario 1 - LFB Operation
4.1.1. Connection Diagram This scenario is to test the interoperability on LFB operations among
the participants. The connection diagram for the participants is as
shown in Figure 4.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE |
| China| | Japan| | China| |Greece| | Japan| |Greece| | China| | Japan| | China| |Greece| | Japan| |Greece|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE | | FE |
|Japan | |China | |Greece| |China | |Greece| |Japan | |Japan | |China | |Greece| |China | |Greece| |Japan |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 4: Scenario for LFB Operation Figure 4: Scenario for LFB Operation
4.1.2. Design Considerations In order to make interoperability more credible,the three
implementors carried out the test in an alternative way acting as a
CE or an FE. As a result, every operation should be tested with 6
combinations all three participants, as shown in Figure 4.
Firstly, the scenario of LFB Operation shown in Figure 4 is designed The test scenario is designed with the following purposes:
to verify all kinds of messages which are defined in RFC 5810.
Different implementor may have different choices on implemeting RFC Firstly, the scenario is designed to verify all kinds of protocol
5810 using cases in the protocol messages. However as long as it messages with their complex data formats, which are defined in RFC
complies with the RFC 5810, the interoperating peer must have the 5810. Specially, we try to verify the data format of a PATH-DATA
ability to decode and handle it. Specially, what we want to verify with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array
the most is the format of encasulation for PATH-DATA with nested or an array with a nested array.
PATH-DATAs, and the operation(SET, GET,DEL) of array, as well as
array with nested array. (This case can be seen in ARP LFB's
component of PortV4AddrInfoTable).
Second,the scenario is designed to verify the definition of ForCES Second,the scenario is designed to verify the definition of ForCES
LFB Library[I-D.ietf-forces-lfb-lib]. Successful test under this LFB Library[FORCES-LFBLIB], which defines a base set of ForCES LFB
scenario means all the implementors have followed the instruction classes for typical router functions. Successful test under this
given by the ForCES LFB Library document. scenario also means the validity of the LFB definitions.
4.1.3. Testing Proccess 4.2. Scenario 2 - TML with IPSec
In order to make interoperability more credible,the three This scenario is designed to implement a TML with IPSec, which is the
implementors carried out the test in an alternative way acting as a requirement by RFC 5811. TML with IPSec was not implemented in the
CE or an FE, as shown in figure 4, combined with 6 cases for this first ForCES interoperability test as reported by RFC 6053. For this
Scenario. reason, in the second interoperability test, we specificially
designed the test scenario to verify the TML over IPSec channel.
4.2. Scenario 2 - TML with IPSec In this scenario, tests on LFB operations for Scenario 1 were just
4.2.1. Connection Diagram repeated only with the difference that the IPSec TML was adopted. In
this way, we try to verify whether all interactions between CE and FE
can be made correctly under an IPSec TML enviroment.
The connection diagram for this scenario is shown as Figure 5.
Because of system difficulty to deploy IPSec over TML in Greece, the
text only took place between China and Japan.
+------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE |
| China| | Japan| | China| | Japan|
+------+ +------+ +------+ +------+
| | | |
|TML over IPSec |TML over IPSec |TML over IPSec |TML over IPSec
+------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE |
|Japan | |China | |Japan | |China |
+------+ +------+ +------+ +------+
(a)
+------+ +------+
| CE | | CE |
| China| |Greece|
+------+ +------+
| |
|TML over IPSec |TML over IPSec
+------+ +------+
| FE | | FE |
|Greece| |China |
+------+ +------+
(b)
+------+ +------+
| CE | | CE |
| Japan| |Greece|
+------+ +------+
| |
|TML over IPSec |TML over IPSec
+------+ +------+
| FE | | FE |
|Greece| |Japan |
+------+ +------+
(c)
Figure 5: Scenario for LFB Operation with TML over IPSec Figure 5: Scenario for LFB Operation with TML over IPSec
4.2.2. Design Considerations In this scenario, ForCES TML was run over IPSec channel.
Implementors joined in this interoperability have used the same
This scenario is designed to implement the requirement that stated in third-party software 'racoon' to have established the IPSec channel.
the section "7. Security Considerations" in RFC 5811. For this
reason, we designed the scenario to make TML run over IPSec channel
that was pre-established. In this scenario, all operations for
Scenario 1 were just repeated. In this way, we try to verify whether
all interactions between CE and FE can be done correctly under an
IPSec enviroment.
4.2.3. Testing Proccess
In this scenario, ForCES TML was run over IPSec channel. All the China and Japan have made a successful test with the scenario, and
implementors joined in this interoperability used the same third- the following items have been realized:
party tool software 'racoon' to establish IPSec channel. By this
tool, China and Japan had a successful test, and the following items
have been 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
[RFC2404] for message integrity protection. [RFC2404] for message integrity protection.
4.3. Scenario 3 - CE High Availability 4.3. Scenario 3 - CE High Availability
4.3.1. Connection Diagram CE High Availability (CEHA) was also tested in this interoperability
test based on the ForCES CEHA document [ForCES-CEHA].
The design of the setup and the scenario for the CEHA are as simple
as possible to focus mostly on the mechanics of the CEHA, which are:
o Associating with more than one CEs.
o Switching to backup CE on master CE fail.
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 |
| China| |Greece| |Japan | |Greece| | China| |Greece| |Japan | |Greece|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | | | | | | |
+----------+ +-----------+ +----------+ +-----------+
| | | |
+------+ +------+ +------+ +------+
| FE | | FE | | FE | | FE |
|Greece| |Greece| |Greece| |Greece|
+------+ +------+ +------+ +------+
(a) (b) (a) (b)
Figure 6: Scenario for CE High Availability Figure 6: Scenario for CE High Availability
4.3.2. Design Considerations
CE High Availability (CEHA) was also tested in this interoperability
test based on the CEHA document [I-D.draft-ietf-forces-ceha].
The design of the setup and the scenario for the CEHA are as simple
as possible to focus mostly on the mechanics of the CEHA, which are:
o Associating with more than one CEs.
o Switching to backup CE on master CE fail.
4.3.3. Testing Proccess
In this scenario one FE would be connected and associated with a In this scenario one FE would be connected and associated with a
master CE and a backup CE. In the pre-association phase, the FE master CE and a backup CE. In the pre-association phase, the FE
would be configured to have China's or Japan's CE as master CE and would be configured to have China's or Japan's CE as master CE and
Greece's CE as standby CE. The CEFailoverPolicy component of the FE Greece's CE as standby CE. The CEFailoverPolicy component of the FE
Protocol Object LFB that specifies whether the FE is in High Protocol Object LFB that specifies whether the FE is in High
Availability mode (value 2 or 3) would either be set in the pre- Availability mode (value 2 or 3) would either be set in the pre-
association phase or in post-association phase by the master CE. association phase or in post-association phase by the master CE.
Once the FE is associated with the master CE it will move to the Once the FE is associated with the master CE it will move to the
post-association phase. Then when the CEFailoverPolicy value is set post-association phase. Then when the CEFailoverPolicy value is set
skipping to change at page 16, line 7 skipping to change at page 14, 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.
4.4. Scenario 4 - Packet forwarding 4.4. Scenario 4 - Packet forwarding
4.4.1. Connection Diagram This test scenario is to verify LFBs like RedirectIn, RedirectOut,
IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library
document[ForCES-LFBLIB], and more importantly, to verify the
combination of the LFBs to implement IP packet forwarding.
The connection diagram for this scenario is as Figure 7.
+------+ +------+
| CE | | CE |
| Japan| | Japan|
+------+ +------+
| ^ | ^
| | OSPF | | OSPF
| +-------> | +------->
+------+ +------+ +------+ +------+
+--------+ | FE | | OSPF | +--------+ +--------+ | FE | | OSPF | +--------+
skipping to change at page 16, line 33 skipping to change at page 14, line 48
(a) (a)
+------+ +------+
| CE | | CE |
| China| | China|
+------+ +------+
^ | ^ ^ | ^
OSPF | | | OSPF OSPF | | | OSPF
<-----+ | +-----> <-----+ | +----->
+-------+ +------+ +------+ +-------+ +------+ +------+
+--------+ | OSPF | | FE | | OSPF | +--------+ +--------+ | OSPF | | FE | | OSPF | +--------+
|Terminal|----|Router |----|Japan |-----|Router|----|Terminal| |Terminal|----|Router |----|Japan |-----|Router|----|Terminal|
+--------+ +-------+ +------+ +------+ +--------+ +--------+ +-------+ +------+ +------+ +--------+
<--------------------------------------------> <-------------------------------------------->
Packet Forwarding Packet Forwarding
(b) (b)
+------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE |
| Japan| | China| | Japan| | China|
+------+ +------+ +------+ +------+
| ^ ^ | | ^ ^ |
skipping to change at page 17, line 16 skipping to change at page 15, line 28
|Terminal|------|China |-------|Japan |------|Terminal| |Terminal|------|China |-------|Japan |------|Terminal|
+--------+ +------+ +------+ +--------+ +--------+ +------+ +------+ +--------+
<--------------------------------------------> <-------------------------------------------->
Packet Forwarding Packet Forwarding
(c) (c)
Figure 7: Scenario for IP Packet forwarding Figure 7: Scenario for IP Packet forwarding
4.4.2. Design Considerations In case (a), a CE by Japan is connected to an FE by China to form a
ForCES router. A Smartbits test machine with its routing protocol
This Scenario is used to verify some LFBs such as RedirectIn, software are used to simulate an OSPF router and are connected with
RedirectOut, IPv4NextHop, IPv4UcastLPM defined by ForCES LFB the ForCES router to try to exchange OSPF hello packets and LSA
library[I-D.ietf-forces-lfb-lib]. Cases of (a) and (b) in Figure 7 packets among them. Terminals are simulated by Smartbits to send and
both need a RedirectIn LFB to send CE generated OSPF packets to FE by receive packets. As a result, the CE in the ForCES router need to be
packet redirect messages. The OSPF packets are futher sent to an configured to run and support OSPF routing protocol.
outside OSPF Router by the FE via forwarding LFBs like IPv4NextHop,
IPv4UcastLPM. A RedirectOut LFB in the FE sends OSPF packets
received from the outside OSPF Router to CE by packet redirect
messages also. In this process, meta-data that are included in
packet redirect messages as defined by ForCES LFB library document
should be coded and decoded by either CE or FE.
If above test process can be done, then this whole NE including FE In case (b), a CE by China is connected to an FE by Japan to form a
and CE actually work like an OSPF router which exchanges OSPF ForCES router. Two routers running OSPF are simulated and coneected
protocol information with other OSPF routers. By running OSPF to the ForCES router to test if the ForCES router can support OSPF
protocol, the CE can generate new routes and be loaded to FE. In the protocol and support packet forwarding.
process, IPv4NextHop and Ipv4UcastLPM LFBs must be working to support
operations.
By sending packet to the destination through the FE, FE should In case (c), two ForCES rotuers are constructed. One is with CE by
forward packet according to the route generated by OSPF. so, the data Japan and FE by China and the other is opposite. OSPF and packet
path in FE can be tested and LFBs such as EtherPHYCop, EtherMacIn, forwarding are tested in the enviroment.
IPv4Classifier, IPv4Validator, EtherEncasulator, EtherMacOut also be
verified.
4.4.3. Testing Proccess Testing proccess for this scenario is as below:
First,Boot terminals and routers, and set IP addresses of their 1. Boot terminals and routers, and set IP addresses of their
interfaces. interfaces.
Second, Boot CE and FE. 2. Boot CE and FE.
Third, Establish association between CE and FE, and set IP addresses 3. Establish association between CE and FE, and set IP addresses of
of FE__s interfaces. FE__s interfaces.
Fifth, Start OSPF among CE and routers, and set FIB on FE. 4. Start OSPF among CE and routers, and set FIB on FE.
Sixth, Send packets between terminals. 5. Send packets between terminals.
5. Test Results 5. Test Results
5.1. LFB Operation Test 5.1. LFB Operation Test
For the convinience sake, as mentioned earlier, abbreviations of 'C' The test result is as reported by Figure 8. For the convinience
means implementation from China,'J'Japan implementaion, and 'G' sake, as mentioned earlier, abbreviations of 'C' in the table means
Greece implemenation. Testing results of this scenario are listed in implementation from China,'J'Japan implementaion, and 'G' Greece
the following figure. implemenation.
+----+----+-----+----+-----------+-----------+--------+-------------+ +-----+----+-----+-----+--------------+-------------------+---------+
|Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment | |Test#| CE |FE(s)|Oper | LFB | Component | Result |
|# | | | | |Capability | | | | | | | | | /Capability | |
+----+----+-----+----+-----------+-----------+--------+-------------+ +-----+----+-----+-----+--------------+-------------------+---------+
| 1 | C | J | | | |Success |As for the | | 1 | C | J | | | | Success |
| | J | C | | | |Success | format of | | | J | C | | | | Success |
| | C | G | | | |Success |encapsulation| | | G | C | GET | FEObject | LFBTopology | Success |
| | G | C | GET| FEObject |LFBTopology|Success |on array, | | | J | G | | | | Success |
| | J | G | | | |Success |only the case| | | G | J | | | | Success |
| | G | J | | | |Success |of FULLDATA- | | | | | | | | |
| | | | | | | |-in-FULLDATA | | 2 | C | J | | | | Success |
| 2 | C | J | | | |Success |is supported | | | J | C | | | | Success |
| | J | C | | | |Success |for everyone.| | | C | G | | | | Success |
| | C | G | | | |Success |Howerver more| | | G | C | GET | FEObject | LFBSelector | Success |
| | G | C | GET| FEObject |LFBSelector|Success |types such as| | | J | G | | | | Success |
| | J | G | | | s |Success |SPARSEDATA | | | G | J | | | | Success |
| | G | J | | | |Success |should be | | | | | | | | |
| | | | | | | |supported | | 3 | C | J | | | | Success |
| 3 | C | J | | | |Success |in the | | | J | C | | | | Success |
| | J | C | | | |Success |future. | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherPHYCop | PHYPortID | Success |
| | G | C | GET|EtherPHYCop|PHYPortID |Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 4 | C | J | | | | Success |
| 4 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherPHYCop | AdminStatus | Success |
| | G | C | GET|EtherPHYCop|AdminStatus|Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 5 | C | J | | | | Success |
| 5 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherPHYCop | OperStatus | Success |
| | G | C | GET|EtherPHYCop|OperStatus |Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success |As for the | | | | | | | | |
| | | | | | | |format of | | 6 | C | J | | | | Success |
| 6 | C | J | | | |Success |PATH-DATA, | | | J | C | | | | Success |
| | J | C | | | |Success |J use the | | | C | G | | | | Success |
| | C | G | | | |Success |case of | | | G | C | GET | EtherPHYCop | AdminLinkSpeed | Success |
| | G | C | GET|EtherPHYCop|AdminLink |Success |PATH-DATA in | | | J | G | | | | Success |
| | J | G | | | Speed |Success |PATH-DATA,C | | | G | J | | | | Success |
| | G | J | | | |Success |uses | | | | | | | | |
| | | | | | | |only one | | 7 | C | J | | | | Success |
| 7 | C | J | | | |Success |PATH-DATA with | | J | C | | | | Success |
| | J | C | | | |Success |mutiple IDs. | | | C | G | | | | Success |
| | C | G | | | |Success |G uses ... | | | G | C | GET | EtherPHYCop | OperLinkSpeed | Success |
| | G | C | GET|EtherPHYCop| OperLink |Success | | | | J | G | | | | Success |
| | J | G | | | Speed |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 8 | C | J | | | | Success |
| 8 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherPHYCop | AdminDuplexSpeed | Success |
| | G | C | GET|EtherPHYCop|AdminDuplex|Success | | | | J | G | | | | Success |
| | J | G | | | Speed |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | |The side of | | 9 | C | J | | | | Success |
| 9 | C | J | | | |Success |C thinks that| | | J | C | | | | Success |
| | J | C | | | |Success |CE SHOULD get| | | C | G | | | | Success |
| | C | G | | | |Success |LFB instance | | | G | C | GET | EtherPHYCop | OperDuplexSpeed | Success |
| | G | C | GET|EtherPHYCop|OperDuplex |Success |data | | | J | G | | | | Success |
| | J | G | | | Speed |Success |according to | | | G | J | | | | Success |
| | G | J | | | |Success |LFBSelectors.| | | | | | | | |
| | | | | | | | | | 10 | C | J | | | | Success |
| 10 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherPHYCop | CarrierStatus | Success |
| | G | C | GET|EtherPHYCop| Carrier |Success | | | | J | G | | | | Success |
| | J | G | | | Status |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 11 | C | J | | | | Success |
| 11 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | AdminStatus | Success |
| | G | C | GET| EtherMACIn|AdminStatus|Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 12 | C | J | | | | Success |
| 12 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | LocalMacAddresses | Success |
| | G | C | GET|EtherMACIn | LocalMac |Success | | | | J | G | | | | Success |
| | J | G | | | Addresses |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 13 | C | J | | | | Success |
| 13 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | L2Bridging | Success |
| | G | C | GET|EtherMACIn |L2Bridging |Success | | | | J | G | | | PathEnable | Success |
| | J | G | | |PathEnable |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 14 | C | J | | | | Success |
| 14 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | PromiscuousMode | Success |
| | G | C | GET|EtherMACIn |Promiscuous|Success | | | | J | G | | | | Success |
| | J | G | | | Mode |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 15 | C | J | | | | Success |
| 15 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | TxFlowControl | Success |
| | G | C | GET|EtherMACIn | TxFlow |Success | | | | J | G | | | | Success |
| | J | G | | | Control |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 16 | C | J | | | | Success |
| 16 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | RxFlowControl | Success |
| | G | C | GET|EtherMACIn | RxFlow |Success | | | | J | G | | | | Success |
| | J | G | | | Control |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 17 | C | J | | | | Success |
| 17 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACIn | MACInStats | Success |
| | G | C | GET|EtherMACIn |MACInStats |Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 18 | C | J | | | | Success |
| 18 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACOut | AdminStatus | Success |
| | G | C | GET|EtherMACOut|AdminStatus|Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 19 | C | J | | | | Success |
| 19 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACOut | MTU | Success |
| | G | C | GET|EtherMACOut| MTU |Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 20 | C | J | | | | Success |
| 20 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACOut | TxFlowControl | Success |
| | G | C | GET|EtherMACOut| TxFlow |Success | | | | J | G | | | | Success |
| | J | G | | | Control |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 21 | C | J | | | | Success |
| 21 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACOut | TxFlowControl | Success |
| | G | C | GET|EtherMACOut| TxFlow |Success | | | | J | G | | | | Success |
| | J | G | | | Control |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 22 | C | J | | | | Success |
| 22 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | EtherMACOut | MACOutStats | Success |
| | G | C | GET|EtherMACOut|MACOutStats|Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 23 | C | J | | | | Success |
| 23 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | GET | ARP |PortV4AddrInfoTable| Success |
| | G | C | GET| ARP |PortV4Addr |Success | | | | J | G | | | | Success |
| | J | G | | | InfoTable |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 24 | C | J | | | | Success |
| 24 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | SET | ARP |PortV4AddrInfoTable| Success |
| | G | C | SET| ARP |PortV4Addr |Success | | | | J | G | | | | Success |
| | J | G | | | InfoTable |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 25 | C | J | | | | Success |
| 25 | C | J | | | |Success |C's misunder-| | | J | C | | | | Success |
| | J | C | | | |Success |standing of | | | C | G | | | | Success |
| | C | G | | | |Success |the PATHDATA | | | G | C | DEL | ARP |PortV4AddrInfoTable| Success |
| | G | C | DEL| ARP |PortV4Addr |Success |in DEL | | | J | G | | | | Success |
| | J | G | | | InfoTable |Success |Operation. | | | G | J | | | | Success |
| | G | J | | | |Success |Later C fixed| | | | | | | | |
| | | | | | | |the problem | | 26 | C | J | | | | Success |
| 26 | C | J | | | |Success |and make it | | | J | C | | | | Success |
| | J | C | | | |Success |successful | | | C | G | | | | Success |
| | C | G | | | |Success |in testing | | | G | C | SET | EtherMACIn | LocalMACAddresses | Success |
| | G | C | SET|EtherMACIn | LocalMAC |Success |with J. | | | J | G | | | | Success |
| | J | G | | | Addresses |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 27 | C | J | | | | Success |
| 27 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | SET | EtherMACIn | MTU | Success |
| | G | C | SET|EtherMACIn | MTU |Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 28 | C | J | | | | Success |
| 28 | C | J | | | |Success |By setting | | | J | C | | | | Success |
| | J | C | | | |Success |new reachable| | | C | G | | | | Success |
| | C | G | | | |Success |network,route| | | G | C | SET | IPv4NextHop | IPv4NextHopTable | Success |
| | G | C | SET|IPv4NextHop|IPv4NextHop|Success |entry can be | | | J | G | | | | Success |
| | J | G | | | Table |Success |added into | | | G | J | | | | Success |
| | G | J | | | |Success |system. | | | | | | | | |
| | | | | | | | | | 29 | C | J | | | | Success |
| 29 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | SET | IPv4UcastLPM | IPv4PrefixTable | Success |
| | G | C | SET| IPv4Ucast |IPv4Prefix |Success | | | | J | G | | | | Success |
| | J | G | | LPM | Table |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 30 | C | J | | | | Success |
| 30 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success |Corresponding| | | C | G | | | | Success |
| | C | G | | | |Success |nexthop entry| | | G | C | DEL | IPv4NextHop | IPv4NextHopTable | Success |
| | G | C | DEL|IPv4NextHop|IPv4NextHop|Success |MUST delete | | | J | G | | | | Success |
| | J | G | | | Table |Success |before prefix| | | G | J | | | | Success |
| | G | J | | | |Success |entry. | | | | | | | | |
| | | | | | | | | | 31 | C | J | | | | Success |
| 31 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | DEL | IPv4UcastLPM | IPv4PrefixTable | Success |
| | G | C | DEL| IPv4Ucast |IPv4Prefix |Success | | | | J | G | | | | Success |
| | J | G | | LPM | Table |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 32 | C | J | | | | Success |
| 32 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | SET | EtherPHYCop | AdminStatus | Success |
| | G | C | SET|EtherPHYCop|AdminStatus|Success | | | | J | G | | | | Success |
| | J | G | | | |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 33 | C | J | | | | Success |
| 33 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | SET | Ether | VlanInputTable | Success |
| | G | C | SET| Ether | VlanInput |Success | | | | J | G | | Classifier | | Success |
| | J | G | | Classifier| Table |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 34 | C | J | | | | Success |
| 34 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | DEL | Ether | VlanInputTable | Success |
| | G | C | DEL| Ether | VlanInput |Success | | | | J | G | | Classifier | | Success |
| | J | G | | Classifier| Table |Success | | | | G | J | | | | Success |
| | G | J | | | |Success | | | | | | | | | |
| | | | | | | | | | 35 | C | J | | | | Success |
| 35 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | SET | Ether | VlanOutputTable | Success |
| | G | C | SET| Ether |VlanOutput |Success | | | | J | G | | Encapsulator | | Success |
| | J | G | |Encapsulato| Table |Success | | | | G | J | | | | Success |
| | G | J | | r | |Success | | | | | | | | | |
| | | | | | | | | | 36 | C | J | | | | Success |
| 36 | C | J | | | |Success | | | | J | C | | | | Success |
| | J | C | | | |Success | | | | C | G | | | | Success |
| | C | G | | | |Success | | | | G | C | DEL | Ether | VlanOutputTable | Success |
| | G | C | DEL| Ether |VlanOutput |Success | | | | J | G | | Encapsulator | | Success |
| | J | G | |Encapsulato| Table |Success | | | | G | J | | | | Success |
| | G | J | | r | |Success | | +-----+----+-----+-----+--------------+-------------------+---------+
+----+----+-----+----+-----------+-----------+--------+-------------+
Figure 8: LFB Operation Test Results
5.2. TML with IPSec Test 5.2. TML with IPSec Test
In this scenario, ForCES TML will run over IPSec channel.All the In this scenario, ForCES TML will run over IPSec channel.
implementors who joined this interoperability test use the same Implementors joined this interoperability test use the same third-
third-party tool software 'racoon' to establish IPSec channel.To be party tool software 'racoon' to establish IPSec channel. Some
mentioned is that we have not repeat all the operations listed in typical LFB operation tests as in Scenario 1 have been repeated with
Scenario 1,only some typical operations have been done. the new security TML.
Although some problems still remains in the connection with Greece, A note on this test is, because of the system difficulty to implement
the TML with IPSec test is considered as success. The goal was to IPSec over TML, Greece did not join in the test. Therefore, this
verify whether the interaction between CE and FE can be done normally scenario only successfully took place between C and J. However, it is
under such IPSec environment. Since Japan's and China's still valid to make the interoperability test among two participants.
implementation worked it is assumed that Greece's would as well, as
the problem was on the setup and configuration of the IPSec
connection and not on the ForCES protocol perse.
During the test following results as shown in figure occured. The TML with IPSec test results are reported by Figure 9.
+----+----+-----+----+-----------+-----------+--------+-------------+ +-----+----+-----+-----+--------------+-------------------+---------+
|Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment | |Test#| CE |FE(s)|Oper | LFB | Component/ | Result |
|# | | | | |Capability | | | | | | | | | Capability | |
+----+----+-----+----+-----------+-----------+--------+-------------+ +-----+----+-----+-----+--------------+-------------------+---------+
| 1 | C | J | | | |Success |For unkown | | 1 | C | J | GET | FEObject | LFBTopology | Success |
| | J | C | | | |Success |error in | | | J | C | | | | Success |
| | C | G | | | |Failure |configuration| | | | | | | | |
| | G | C | GET| FEObject |LFBTopology|Failure |with racoon, | | 2 | C | J | GET | FEObject | LFBSelectors | Success |
| | J | G | | | |Failure |Greece still | | | J | C | | | | Success |
| | G | J | | | |Failure |need some | | | | | | | | |
| | | | | | | |time to fix | | 3 | C | J | SET | Ether | VlanInputTable | Success |
| 2 | C | J | | | |Success |the issue. | | | J | C | | Classifier | | Success |
| | J | C | | | |Success |So,this | | | | | | | | |
| | C | G | | | |Failure |scenario only| | 4 | C | J | DEL | Ether | VlanInputTable | Success |
| | G | C | GET| FEObject |LFBSelector|Failure |took place | | | J | C | | Classifier | | Success |
| | J | G | | | s |Failure |between C and| +-----+----+-----+-----+--------------+-------------------+---------+
| | G | J | | | |Failure |J. |
| | | | | | | | | Figure 9: TML with IPSec Test Results
| 3 | C | J | | | |Success | |
| | J | C | | | |Success | |
| | C | G | | | |Failure | |
| | G | C | SET| Ether | VlanInput |Failure | |
| | J | G | | Classifier| Table |Failure | |
| | G | J | | | |Failure | |
| | | | | | | | |
| 4 | C | J | | | |Success | |
| | J | C | | | |Success | |
| | C | G | | | |Failure | |
| | G | C | DEL| Ether | VlanInput |Failure | |
| | J | G | | Classifier| Table |Failure | |
| | G | J | | | |Failure | |
+----+----+-----+----+-----------+-----------+--------+-------------+
5.3. CE High Availability Test 5.3. CE High Availability Test
In this scenario one FE will connect and associate with a master CE In this scenario one FE will connect and associate with a master CE
and a backup CE. When the master CE is considered disconnected the and a backup CE. When the master CE is considered disconnected the
FE would attempt to find another associated CE to become the master FE would attempt to find another associated CE to become the master
CE. CE.
The CEHA scenario as is described in Scenario 3 was completed The CEHA scenario as is described in Scenario 3 was completed
successfully for both setups. successfully for both setups.
skipping to change at page 26, line 32 skipping to change at page 24, line 18
receive and handle messages from the backup CEs. receive and handle messages from the backup CEs.
o Only when the FE is attempting to associate with the backup CEs, o Only when the FE is attempting to associate with the backup CEs,
then the FE SHOULD receive and handle messages per priority then the FE SHOULD receive and handle messages per priority
channel from all CEs. When all backup CEs are associated with or channel from all CEs. When all backup CEs are associated with or
deemed unreachable, then the FE SHOULD return to receiving and deemed unreachable, then the FE SHOULD return to receiving and
handling messages first from the master CE. handling messages first from the master CE.
5.4. Packet Forwarding Test 5.4. Packet Forwarding Test
The Scenario of packet forwading is the most complex one because it As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib],
need the Scenario 1 must be completed.In this scenario testing,the packet forwarding is implemented by a set of LFB classes that compose
pattern of J-CE C-FE was carried out. Smartbits's 2 testing ports a processing path for packets. In this test scenario, as shown in
connect to FE's 2 data-forwarding ports,meanwhile smartbits simulate Figure 7, a ForCES router running OSPF protocol should be construted.
ospf router and try to exchange the OSPF hello packet and LSA packet Moreover, a set of LFBs including RedirectIn, RedirectOut,
with CE,because CE also has an OSPF process in it so that the whole IPv4UcastLPM, and IPv4NextHop LFBs should be constructed and be
NE including FE and CE looks like an OSPF router. joined in a processing data path. RedirectIn and RedirectOut LFBs
redirect OSPF hello and LSA packets from and to CE. Smartbits test
machine is used to simulate an OSPF router and try to exchange the
OSPF hello packet and LSA packet with CE in ForCES router.
In this scenario,RedirectIn,RedirectOut,IPv4NextHop,IPv4UcastLPM LFB Cases (a) and (b) in Figure 7 both need a RedirectIn LFB to send OSPF
should join the data path.First, it must be sured that IPv4NextHop packets generated by CE to FE by use of ForCES packet redirect
and IPv4UcastLPM can work normally so that route entry can be added messages. The OSPF packets are futher sent to an outside OSPF Router
to FE.Second,RedirectIn and RedirectOut LFB MUST work,only that can by the FE via forwarding LFBs including IPv4NextHop and IPv4UcastLPM
FE redirect out OSPF hello and LSA packets to CE received from LFBs. A RedirectOut LFB in FE is used to send OSPF packets received
smartBits,FE redirect in OSPF hello and LSA packets to smartBits from outside OSPF Router to CE by ForCES packet redirect messages.
received from CE's OSPF process.
During the test, results as shown in the following figure are By running OSPF protocol, CE in the ForCES router then can generate
recorded. new routes and load them to routing table in FE. FE is then able to
forward packets according to the routing table.
+----+----+-----+----------------+-----------+--------+-------------+ The test is reported with the results in Figure 10
|Test| CE |FE(s)| Item | LFB | Result | Comment |
|# | | | | | | | +-----+----+-----+-------------------------+--------------+---------+
+----+----+-----+----------------+-----------+--------+-------------+ |Test#| CE |FE(s)| Item | LFBs Related | Result |
| 1 | J | C |IPv4NextHopTable|IPv4NextHop|Success | Muticast | +-----+----+-----+-------------------------+--------------+---------+
| | | | SET | | | route is | | 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | | added by | | | | | | | |
| 2 | J | C |IPv4PrefixTable | IPv4Ucast |Success |manual,this | | 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success |
| | | | SET | LPM | |problem still| | | | | | | |
| | | | | | |need to be | | 3 | J | C |Redirect ospf packet from| RedirectIn | Success |
| | | |Redirect ospf | | |fixed in the | | | | | CE to SmartBits | | |
| 3 | J | C |packet from CE |RedirectIn |Success | future. | | | | | | | |
| | | |to SmartBits | | | | | 4 | J | C |Redirect ospf packet from| RedirectOut | Success |
| | | | | | | As for | | | | | SmartBits to CE | | |
| | | |Redirect ospf | | | redirect | | | | | | | |
| 4 | J | C |packet from |RedirectOut|Success | message, | | 5 | J | C | Metadata in | RedirectOut | Success |
| | | |SmartBits to CE | | |ospf hello | | | | | redirect message | RedirectIn | |
| | | | | | |packet in 2- | | | | | | | |
| | | |Metadata in |RedirectOut| |direction can| | 6 | J | C |OSPF neiborhood discovery| RedirectOut | Success |
| 5 | J | C |redirect message|RedirectIn |Success |be wathed by | | | | | | RedirectIn | |
| | | | | | | wireshark. | | | | | | | |
| | | | | | |however ospf | | 7 | J | C | OSPF DD exchange | RedirectOut | Success |
| | | |OSPF neiborhood |RedirectOut| | packet | | | | | | RedirectIn | |
| 6 | J | C | discovery |RedirectIn |Success |received from| | | | | | IPv4NextHop | |
| | | | | | |CE have an | | | | | | | |
| | | | |RedirectOut| |error with | | 8 | J | C | OSPF LSA exchange | RedirectOut | Success |
| | | | OSPF DD |RedirectIn | |checksum,so | | | | | | RedirectIn | |
| 7 | J | C | exchange |IPv4NextHop|Success |smartBits | | | | | | IPv4NextHop | |
| | | | | IPv4Ucast | |will drop it | | | | | | IPv4UcastLPM| |
| | | | | LPM | |with no | | | | | | | |
| | | | | | |neighborhood | | 9 | J | C | Data Forwarding | RedirectOut | |
| | | | | | |discovered. | | | | | | RedirectIn | Success |
| 8 | J | C | OSPF LSA |RedirectOut| | | | | | | | IPv4NextHop | |
| | | | exchange |RedirectIn |Success | | | | | | | IPv4UcastLPM| |
| | | | |IPv4NextHop| | | | | | | | | |
| | | | | IPv4Ucast | | | | 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | LPM | | | | | | | | | |
| | | | | | | | | 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success |
| | | | |RedirectOut| | | | | | | | | |
| 9 | J | C |Data Forwarding |RedirectIn | | | | 12 | C | J |Redirect ospf packet from| RedirectIn | Success |
| | | | |IPv4NextHop|Success | | | | | | CE to other OSPF router | | |
| | | | | IPv4Ucast | | | | | | | | | |
| | | | | LPM | | | | 13 | C | J |Redirect ospf packet from| RedirectOut | Success |
| | | | | | | | | | | |other OSPF router to CE | | |
| 10 | C | J |IPv4NextHopTable|IPv4NextHop|Success | | | | | | | | |
| | | | SET | | | | | 14 | C | J | Metadata in | RedirectOut | Success |
| | | | | | | | | | | | redirect message | RedirectIn | |
| 11 | C | J |IPv4PrefixTable | IPv4Ucast |Success | | | | | | | | |
| | | | SET | LPM | | | | 15 | C | J |OSPF neiborhood discovery| RedirectOut | Success |
| | | | | | | | | | | | | RedirectIn | |
| | | |Redirect ospf | | | | | | | | | | |
| 12 | C | J |packet from CE |RedirectIn |Success | | | | | | | RedirectOut | |
| | | |to other OSPF | | | | | 16 | C | J | OSPF DD exchange | RedirectIn | Failure |
| | | | router | | | | | | | | | IPv4NextHop | |
| | | | | | | | | | | | | | |
| | | |Redirect ospf | | | | | 17 | C | J | OSPF LSA exchange | RedirectOut | |
| 12 | C | J |packet from |RedirectOut|Success | | | | | | | RedirectIn | Failure |
| | | |other OSPF | | | | | | | | | IPv4NextHop | |
| | | |router to CE | | | | | | | | | IPv4UcastLPM| |
| | | | | | | | +-----+----+-----+-------------------------+--------------+---------+
| | | |Metadata in |RedirectOut| | | Figure 10: Packet Forwarding Test Results
| 13 | C | J |redirect message|RedirectIn |Success | |
| | | | | | | | Comment on Test #16 and #17:
| | | | | | | |
| | | |OSPF neiborhood |RedirectOut| | | The two test items failed. Note that Test #7 and #8 are exactly the
| 14 | C | J | discovery |RedirectIn |Success | | same as these tests, only with CE and FE implementors are exchanged,
| | | | | | | | and Test #12 and #13 show the redirect channel works well. As a
| | | | |RedirectOut| | | result, it can be infered that the problem caused the test failure
| | | | OSPF DD |RedirectIn | | | was almost certainly from the implementation of the related LFBs
| 15 | C | J | exchange |IPv4NextHop|Failure |FE connected | rather than from the ForCES protocol design problem, therefore the
| | | | | IPv4Ucast | |by 2 OSPF | failure does not lead to the interoperability problem on ForCES.
| | | | | LPM | |router,only |
| | | | | | |1 OSPF can be|
| | | | | | |discovered by|
| | | | | | |CE,so DD |
| | | | | | |exchanging |
| 16 | C | J | OSPF LSA |RedirectOut| |stopped. |
| | | | exchange |RedirectIn |Failure | |
| | | | |IPv4NextHop| | |
| | | | | IPv4Ucast | | |
| | | | | LPM | | |
| | | | | | | |
| | | | |RedirectOut| | |
| 17 | J | C |Data Forwarding |RedirectIn | | |
| | | | |IPv4NextHop|TBD | |
| | | | | IPv4Ucast | | |
| | | | | LPM | | |
+----+----+-----+----------------+-----------+--------+-------------+
6. Discussions 6. Discussions
6.1. On Data Encapsulation Format 6.1. On Data Encapsulation Format
In the first day of the test, it was found that the LFB inter- In the first day of the test, it was found that the LFB inter-
operations about tables all failed. The reason is found to be the operations about tables all failed. The reason is found to be the
different ForCES protocol data encapsulation method among different different ForCES protocol data encapsulation method among different
implementations. The encapsulation issues are detailed as below: implementations. The encapsulation issues are detailed as below:
skipping to change at page 35, line 7 skipping to change at page 33, line 7
Jingjing Zhou, Zhejiang Gongshang Unviersity Jingjing Zhou, Zhejiang Gongshang Unviersity
Liaoyuan Ke, Hangzhou BAUD Networks Liaoyuan Ke, Hangzhou BAUD Networks
Kelei Jin,Hangzhou BAUD Networks Kelei Jin,Hangzhou BAUD Networks
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
TBD Developers of ForCES FEs and CEs must take the security
considerations of the ForCES Framework [RFC3746] and the ForCES
Protocol [RFC5810] into account. Also, as specified in the security
considerations section of the SCTP-Based TML for the ForCES Protocol
[RFC5811] the transport-level security, has to be ensured by IPsec.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-forces-ceha]
Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
Intra-NE High Availability", draft-ietf-forces-ceha-01
(work in progress), February 2011.
[I-D.ietf-forces-lfb-lib]
Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "ForCES Logical Function Block (LFB) Library",
draft-ietf-forces-lfb-lib-03 (work in progress),
December 2010.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[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
Layer (TML) for the Forwarding and Control Element Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", RFC 5811, March 2010. Separation (ForCES) Protocol", RFC 5811, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010. RFC 5812, March 2010.
[RFC5813] Haas, R., "Forwarding and Control Element Separation [RFC5813] Haas, R., "Forwarding and Control Element Separation
(ForCES) MIB", RFC 5813, March 2010. (ForCES) MIB", RFC 5813, March 2010.
[RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim,
"Implementation Report for Forwarding and Control Element
Separation (ForCES)", RFC 6053, November 2010.
11.2. Informative References 11.2. Informative References
[Ethereal]
"Ethereal is a protocol analyzer. The specific Ethereal
that was used is an updated Ethereal, by Fenggen Jia, that
can analyze and decode the ForCES protocol messages", http
://www.ietf.org/mail-archive/web/forces/current/
msg03687.html .
[I-D.ietf-forces-ceha]
Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
Intra-NE High Availability", draft-ietf-forces-ceha-01
(work in progress), February 2011.
[I-D.ietf-forces-lfb-lib]
Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "ForCES Logical Function Block (LFB) Library",
draft-ietf-forces-lfb-lib-05 (work in progress),
July 2011.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim,
"Implementation Report for Forwarding and Control Element
Separation (ForCES)", RFC 6053, November 2010.
[Tcpdump] "Tcpdump is a Linux protocol analyzer. The specific
tcpdump that was used is a modified tcpdump, by Jamal Hadi
Salim, that can analyze and decode the ForCES protocol
messages", http://www.ietf.org/mail-archive/web/forces/
current/msg03811.html .
Authors' Addresses Authors' Addresses
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town 18 Xuezheng Str., Xiasha University Town
Hangzhou, 310018 Hangzhou, 310018
P.R.China P.R.China
Phone: +86-571-28877721 Phone: +86-571-28877721
Email: wmwang@zjgsu.edu.cn Email: wmwang@zjgsu.edu.cn
 End of changes. 71 change blocks. 
668 lines changed or deleted 612 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/