draft-ietf-forces-interop-02.txt   draft-ietf-forces-interop-03.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: January 12, 2012 NTT Corporation Expires: July 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
July 11, 2011 January 9, 2012
Interoperability Report for Forwarding and Control Element Separation Interoperability Report for Forwarding and Control Element Separation
(ForCES) (ForCES)
draft-ietf-forces-interop-02 draft-ietf-forces-interop-03
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) interoperability test which took control Element Separation (ForCES) interoperability test which took
place on February 24-25, 2011 in the Internet Technology Lab (ITL) of place on February 24-25, 2011 in the Internet Technology Lab (ITL) of
Zhejiang Gongshang University, China. Zhejiang Gongshang University, China.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 12, 2012. This Internet-Draft will expire on July 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 7 3.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 7
3.2.1. Participants Access . . . . . . . . . . . . . . . . . 7 3.2.1. Participants Access . . . . . . . . . . . . . . . . . 7
3.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 8 3.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 8
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 11 4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 11
4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 11 4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 11
4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 12 4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 12
4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 14 4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 14
5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 17 5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 17
5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 22 5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 23
5.3. CE High Availability Test . . . . . . . . . . . . . . . . 23 5.3. CE High Availability Test . . . . . . . . . . . . . . . . 23
5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 24 5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 24
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 27 6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 27
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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 February 24-25, 2011 in the Internet Framework which took place February 24-25, 2011 in the Internet
Technology Lab (ITL) of Zhejiang Gongshang University, China. The Technology Lab (ITL) of Zhejiang Gongshang University, China. The
test 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
[I-D.ietf-forces-lfb-lib] and ForCES CE HA specification [I-D.ietf-forces-lfb-lib] and ForCES CE HA specification
[I-D.ietf-forces-ceha] Three independent ForCES implementations [I-D.ietf-forces-ceha]. Three independent ForCES implementations
participated in the test. 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. Popular packet analyzers Ethereal/
used to verify the results. Wireshark[Ethereal] and Tcpdump[Tcpdump] are used to verify the wire
results.
The first interoperability test on ForCES was held in July 2008 at The first interoperability test on ForCES was held in July 2008 at
the University of Patras, Greece. The test focussed on validating the University of Patras, Greece. The test focused on validating the
the basic semantics of the ForCES protocol and ForCES FE model. The basic semantics of the ForCES protocol and ForCES FE model. The test
test results were captured by RFC 6053[RFC6053]. results were captured by [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 the ForCES protocol specification RFC 5810 is encouraged to read the ForCES protocol specification [RFC5810] for
[RFC5810] for further information. further information.
1.2. ForCES FE Model 1.2. ForCES FE Model
The ForCES FE modelRFC 5812 [RFC5812] presents a formal way to define The ForCES FE model [RFC5812] presents a formal way to define FE
FE Logical Function Blocks (LFBs) using XML. LFB configuration Logical Function Blocks (LFBs) using XML. LFB configuration
components, capabilities, and associated events are defined when the components, capabilities, and associated events are defined when the
LFB is formally created. The LFBs within the FE are accordingly LFB is formally created. The LFBs within the FE are accordingly
controlled 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 ForCES Transport Mapping Layer (TML) transports the ForCES The ForCES Transport Mapping Layer (TML) transports the ForCES
Protocol Layer (PL) messages. The TML is where the issues of how to Protocol Layer (PL) messages. The TML is where the issues of how to
achieve transport level reliability, congestion control, multicast, achieve transport level reliability, congestion control, multicast,
ordering, etc are handled. It is expected that more than one TML ordering, etc are handled. It is expected that more than one TML
will be standardized. The various possible TMLs could vary their will be standardized. The various possible TMLs could vary their
implementations based on the capabilities of underlying media and implementations based on the capabilities of underlying media and
transport. However, since each TML is standardized, interoperability transport. However, since each TML is standardized, interoperability
is guaranteed as long as both endpoints support the same TML. All is guaranteed as long as both endpoints support the same TML. All
ForCES Protocol Layer implementations MUST be portable across all ForCES Protocol Layer implementations MUST be portable across all
TMLs. Although more than one TML may be standardized for the ForCES TMLs. Although more than one TML may be standardized for the ForCES
Protocol, for the purposes of the interoperability test, the mandated Protocol, for the purposes of the interoperability test, the mandated
MUST IMPLEMENT SCTP TML [RFC5811] will be used. MUST IMPLEMENT SCTP TML [RFC5811] was be used.
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
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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. 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
ForCES protocol architecture that uses the capabilities of ForCES protocol architecture that uses the capabilities of
existing transport protocols to specifically address protocol existing transport protocols to specifically address protocol
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 second ForCES interoperability test meeting was held by IETF The second ForCES interoperability test meeting was held by IETF
ForCES Working Group on February 24-25, 2011, and was chaired by ForCES Working Group on February 24-25, 2011, and was chaired by
Jamal Hadi Salim, the current ForCES Working Group co-chair. Three Jamal Hadi Salim. Three independent ForCES implementations
independent ForCES implementations participated in the test: participated in the test:
* Zhejiang Gongshang University/Hangzhou BAUD Corparation of * Zhejiang Gongshang University/Hangzhou BAUD Corporation of
Inforamtion and Networks Technology (Hangzhou BAUD Networks), China. Information and Networks Technology (Hangzhou BAUD Networks), China.
This implementation is referred to as "China" or in some cases "C" in This implementation is referred to as "China" or in some cases "C" in
the document for the sake of brevity. 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.
Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks
Corporation, which independently extended two different well known Corporation, which independently extended two different well known
public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and
Tcpdump [Tcpdump], also participated in the interop test. During the Tcpdump [Tcpdump], also participated in the interop test. During the
interoperability test, the two protocol analyzers were used to verify interoperability test, the two protocol analyzers were used to verify
the validity of ForCES protocol messages and in some cases semantics. 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.1). 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 has been 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 two instead
all three representative implementations due to the third one lacking of all three representative implementations due to a third one
a specific feature; however, in ensuing discussions, all implementors lacking a specific feature; however, in ensuing discussions, all
mentioned they will be implementing any missing features in the implementers mentioned they will be implementing any missing features
future. in the future.
3.2. Testbed Configuration 3.2. Testbed Configuration
3.2.1. Participants 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 as the monitoring tool. The approach is as shown in Teamviewer as the monitoring tool[Teamviewer]. The approach is as
Figure 1. In the figure, FE/CE refers to FE or CE that the shown in Figure 1. In the figure, FE/CE refers to FE or CE that the
implementor may act alternatively. implementer may act alternatively.
+---------+ +----+ +----------+ +---------+ +----+ +----------+
| FE/CE | | | +---|Monitoring| | FE/CE | | | +---|Monitoring|
| China |-----| | /\/\/\/\/\ | |(TeamViewer) | China |-----| | /\/\/\/\/\ | |(TeamViewer)
+---------+ | | \Internet/ | | Canada | +---------+ | | \Internet/ | | Canada |
|LAN |----/ \--| +----------+ |LAN |----/ \--| +----------+
+---------+ | | \/\/\/\/\/ | +----------+ +---------+ | | \/\/\/\/\/ | +----------+
| FE/CE |-----| | | | FE/CE | | FE/CE |-----| | | | FE/CE |
| Japan | | | +---| Greece | | Japan | | | +---| Greece |
+---------+ +----+ +----------+ +---------+ +----+ +----------+
Figure 1: Access for Participants Figure 1: Access for Participants
All CEs and FEs SHALL implement IPSec security in the TML. For As specified in RFC 5811, all CEs and FEs SHALL implement IPSec
security, firewalls MUST be used that will allow only the specific security in the TML.
IPs and the SCTP ports defined in the ForCES SCTP-TML [RFC5811].
On the internet boundary, gateways used MUST allow for IPSec, SCTP
protocol and SCTP ports as defined in the ForCES SCTP-TML [RFC5811] .
3.2.2. Testbed Configuration 3.2.2. Testbed Configuration
Hardwares and softwares including CEs and FEs from China and Japan CEs and FEs from China and Japan implementations were physically
implementions that were located within the ITL Lab of Zhejiang located within the ITL Lab of Zhejiang Gongshang University and
Gongshang University, were connected together using Ethernet connected together using Ethernet switches. The configuration can be
switches. The configuration can be seen in Figure 2. In the figure, seen in Figure 2. In the figure, the SmartBits is a third-party
the SmartBits is a third-party supplied routing protocol testing supplied routing protocol testing machine, which acts as a router
machine, which acts as a router running OSPF and RIP and exchanges running OSPF and RIP and exchanges routing protocol messages with
routing protocol messages with ForCES routers in the network. The ForCES routers in the network. The Internet is connected via an ADSL
Internet is connected via an ADSL channel. 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) |
skipping to change at page 10, 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 Testbed configuations can satisfy requirements of all the All above testbed configurations can then satisfy requirements of all
interoperability test scenarios that are mentioned in this document. the 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
This scenario is to test the interoperability on LFB operations among This scenario is to test the interoperability on LFB operations among
the participants. The connection diagram for the participants is as the participants. The connection diagram for the participants is as
shown in Figure 4. shown in Figure 4.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 11, line 27 skipping to change at page 11, line 27
| | | | | | | | | | | |
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| 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
In order to make interoperability more credible,the three In order to make interoperability more credible,the three
implementors carried out the test in an alternative way acting as a implementers are required to carry out the test in a way acting as CE
CE or an FE. As a result, every operation should be tested with 6 or FE alternatively. As a result, every LFB operation is combined
combinations all three participants, as shown in Figure 4. with 6 scenarios, as shown by Figure 4.
The test scenario is designed with the following purposes: The test scenario is designed with the following purposes:
Firstly, the scenario is designed to verify all kinds of protocol Firstly, the scenario is 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 are defined in RFC
5810. Specially, we try to verify the data format of a PATH-DATA 5810. Specially, we try 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.
Second,the scenario is designed to verify the definition of ForCES Secondly,the scenario is designed to verify the definition of ForCES
LFB Library[FORCES-LFBLIB], which defines a base set of ForCES LFB LFB Library[FORCES-LFBLIB], which defines a base set of ForCES LFB
classes for typical router functions. Successful test under this classes for typical router functions. Successful test under this
scenario also means the validity of the LFB definitions. scenario also means the validity of the LFB definitions.
4.2. Scenario 2 - TML with IPSec 4.2. Scenario 2 - TML with IPSec
This scenario is designed to implement a TML with IPSec, which is the This scenario is designed to implement a TML with IPSec, which is the
requirement by RFC 5811. TML with IPSec was not implemented in the requirement by RFC 5811. TML with IPSec was not implemented in the
first ForCES interoperability test as reported by RFC 6053. For this first ForCES interoperability test as reported by RFC 6053. For this
reason, in the second interoperability test, we specificially reason, in the second interoperability test, we specifically designed
designed the test scenario to verify the TML over IPSec channel. the test scenario to verify the TML over IPSec channel.
In this scenario, tests on LFB operations for Scenario 1 were just In this scenario, tests on LFB operations for Scenario 1 were
repeated only with the difference that the IPSec TML was adopted. In repeated with the difference that TML was secured via IPSec. This
this way, we try to verify whether all interactions between CE and FE setup scenario allows us to verify whether all interactions between
can be made correctly under an IPSec TML enviroment. CE and FE can 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 of system difficulty to deploy IPSec over TML in Greece, the Because of system deficiency to deploy IPSec over TML in Greece, the
text only took place between China and Japan. 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 |
+------+ +------+ +------+ +------+
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 was run over IPSec channel. In this scenario, ForCES TML was run over IPSec channel.
Implementors joined in this interoperability have used the same Implementers joined in this interoperability have used the same
third-party software 'racoon' to have established the IPSec channel. third-party software 'racoon' to have established the IPSec channel.
China and Japan have made a successful test with the scenario, and China and Japan have made a successful test with the scenario, and
the following items have been realized: 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
CE High Availability (CEHA) was also tested in this interoperability CE High Availability (CEHA) was tested based on the ForCES CEHA
test based on the ForCES CEHA document [ForCES-CEHA]. document [ForCES-CEHA].
The design of the setup and the scenario for the CEHA are as simple The design of the setup and the scenario for the CEHA were simplified
as possible to focus mostly on the mechanics of the CEHA, which are: so as to focus mostly on the mechanics of the CEHA, which are:
o Associating with more than one CEs. o Associating with more than one CE.
o Switching to backup CE on master CE fail. 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 |
| 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
In this scenario one FE would be connected and associated with a In this scenario one FE is connected and associated to a master CE
master CE and a backup CE. In the pre-association phase, the FE and a backup CE. In the pre-association phase, the FE would be
would be configured to have China's or Japan's CE as master CE and configured to have China's or Japan's CE as master CE and Greece's CE
Greece's CE as standby CE. The CEFailoverPolicy component of the FE as standby CE. The CEFailoverPolicy component of the FE Protocol
Protocol Object LFB that specifies whether the FE is in High Object LFB that specifies whether the FE is in High Availability mode
Availability mode (value 2 or 3) would either be set in the pre- (value 2 or 3) would either be set in the pre-association phase by
association phase or in post-association phase by the master CE. the FEM interface or in post-association phase by the master CE.
Once the FE is associated with the master CE it will move to the If the CEFailoverPolicy value is set to 2 or 3, the FE (in the post-
post-association phase. Then when the CEFailoverPolicy value is set association phase) will attempt to connect and associate with the
to 2 or 3, then it will then attempt to connect and associate with standby CE.
the standby CE.
When the master CE is considered disconnected, either by TearDown, When the master CE is deemed disconnected, either by a TearDown, Loss
Loss of Heartbeats or Disconnected, FE would assume that the standby of Heartbeats or physically disconnected, the FE would assume that
CE is now the master CE. FE will then send an Event Notification, the standby CE is now the master CE. The FE will then send an Event
Primary CE Down,to all associated CEs, only the standby CE in this Notification, Primary CE Down,to all associated CEs, only the standby
case with the value of the new master CEID. The standby CE will then CE in this case, with the value of the new master CEID. The standby
respond by setting with a configuration message the CEID of the FE CE will then respond by sending a configuration message to the CEID
Protocol Object with it's own ID, the same value, to confirm that the component of the FE Protocol Object with its own ID to confirm that
CE considers itself as the master as well. the CE considers itself as the master as well.
The steps of the CEHA scenario were the following: The steps of the CEHA test scenario are 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 14, line 48 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 |
skipping to change at page 15, line 37 skipping to change at page 15, line 37
In case (a), a CE by Japan is connected to an FE by China to form a 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 ForCES router. A Smartbits test machine with its routing protocol
software are used to simulate an OSPF router and are connected with software are used to simulate an OSPF router and are connected with
the ForCES router to try to exchange OSPF hello packets and LSA the ForCES router to try to exchange OSPF hello packets and LSA
packets among them. Terminals are simulated by Smartbits to send and packets among them. Terminals are simulated by Smartbits to send and
receive packets. As a result, the CE in the ForCES router need to be receive packets. As a result, the CE in the ForCES router need to be
configured to run and support OSPF routing protocol. configured to run and support OSPF routing protocol.
In case (b), a CE by China is connected to an FE by Japan to form a In case (b), a CE by China is connected to an FE by Japan to form a
ForCES router. Two routers running OSPF are simulated and coneected ForCES router. Two routers running OSPF are simulated and connected
to the ForCES router to test if the ForCES router can support OSPF to the ForCES router to test if the ForCES router can support OSPF
protocol and support packet forwarding. protocol and support packet forwarding.
In case (c), two ForCES rotuers are constructed. One is with CE by In case (c), two ForCES routers are constructed. One is with CE by
Japan and FE by China and the other is opposite. OSPF and packet Japan and FE by China and the other is opposite. OSPF and packet
forwarding are tested in the enviroment. forwarding are tested in the environment.
Testing proccess for this scenario is as below: Testing process for this scenario is as below:
1. Boot terminals and routers, and set IP addresses of their 1. Boot terminals and routers, and set IP addresses of their
interfaces. interfaces.
2. Boot CE and FE. 2. Boot CE and FE.
3. Establish association between CE and FE, and set IP addresses of 3. Establish association between CE and FE, and set IP addresses of
FE__s interfaces. FEs interfaces.
4. Start OSPF among CE and routers, and set FIB on FE. 4. Start OSPF among CE and routers, and set FIB on FE.
5. 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
The test result is as reported by Figure 8. For the convinience The test result is as reported by Figure 8. For the convenience
sake, as mentioned earlier, abbreviations of 'C' in the table means sake, as mentioned earlier, abbreviations of 'C' in the table means
implementation from China,'J'Japan implementaion, and 'G' Greece implementation from China,'J'Japan implementation, and 'G' Greece
implemenation. implementation.
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
|Test#| CE |FE(s)|Oper | LFB | Component | Result | |Test#| CE |FE(s)|Oper | LFB | Component | Result |
| | | | | | /Capability | | | | | | | | /Capability | |
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
| 1 | C | J | | | | Success | | 1 | C | J | GET | FEObject | LFBTopology | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | G | C | GET | FEObject | LFBTopology | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 2 | C | J | | | | Success | | 2 | C | J | GET | FEObject | LFBSelector | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | FEObject | LFBSelector | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 3 | C | J | | | | Success | | 3 | C | J | GET | EtherPHYCop | PHYPortID | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | PHYPortID | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 4 | C | J | | | | Success | | 4 | C | J | GET | EtherPHYCop | AdminStatus | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | AdminStatus | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 5 | C | J | | | | Success | | 5 | C | J | GET | EtherPHYCop | OperStatus | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | OperStatus | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 6 | C | J | | | | Success | | 6 | C | J | GET | EtherPHYCop | AdminLinkSpeed | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | AdminLinkSpeed | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 7 | C | J | | | | Success | | 7 | C | J | GET | EtherPHYCop | OperLinkSpeed | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | OperLinkSpeed | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 8 | C | J | | | | Success | | 8 | C | J | GET | EtherPHYCop | AdminDuplexSpeed | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | AdminDuplexSpeed | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 9 | C | J | | | | Success | | 9 | C | J | GET | EtherPHYCop | OperDuplexSpeed | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | OperDuplexSpeed | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 10 | C | J | | | | Success | | 10 | C | J | GET | EtherPHYCop | CarrierStatus | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherPHYCop | CarrierStatus | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 11 | C | J | | | | Success | | 11 | C | J | GET | EtherMACIn | AdminStatus | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | AdminStatus | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 12 | C | J | | | | Success | | 12 | C | J | GET | EtherMACIn | LocalMacAddresses | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | LocalMacAddresses | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 13 | C | J | | | | Success | | 13 | C | J | GET | EtherMACIn | L2Bridging | Success |
| | J | C | | | | Success | | | J | C | | | PathEnable | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | L2Bridging | Success | | | G | C | | | | Success |
| | J | G | | | PathEnable | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 14 | C | J | | | | Success | | 14 | C | J | GET | EtherMACIn | PromiscuousMode | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | PromiscuousMode | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 15 | C | J | | | | Success | | 15 | C | J | GET | EtherMACIn | TxFlowControl | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | TxFlowControl | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 16 | C | J | | | | Success | | 16 | C | J | GET | EtherMACIn | RxFlowControl | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | RxFlowControl | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 17 | C | J | | | | Success | | 17 | C | J | GET | EtherMACIn | MACInStats | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACIn | MACInStats | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 18 | C | J | | | | Success | | 18 | C | J | GET | EtherMACOut | AdminStatus | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACOut | AdminStatus | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 19 | C | J | | | | Success | | 19 | C | J | GET | EtherMACOut | MTU | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACOut | MTU | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 20 | C | J | | | | Success | | 20 | C | J | GET | EtherMACOut | TxFlowControl | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACOut | TxFlowControl | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 21 | C | J | | | | Success | | 21 | C | J | GET | EtherMACOut | TxFlowControl | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACOut | TxFlowControl | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 22 | C | J | | | | Success | | 22 | C | J | GET | EtherMACOut | MACOutStats | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | EtherMACOut | MACOutStats | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 23 | C | J | | | | Success | | 23 | C | J | GET | ARP |PortV4AddrInfoTable| Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | GET | ARP |PortV4AddrInfoTable| Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 24 | C | J | | | | Success | | 24 | C | J | SET | ARP |PortV4AddrInfoTable| Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | ARP |PortV4AddrInfoTable| Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 25 | C | J | | | | Success | | 25 | C | J | DEL | ARP |PortV4AddrInfoTable| Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | DEL | ARP |PortV4AddrInfoTable| Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 26 | C | J | | | | Success | | 26 | C | J | SET | EtherMACIn | LocalMACAddresses | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | EtherMACIn | LocalMACAddresses | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 27 | C | J | | | | Success | | 27 | C | J | SET | EtherMACIn | MTU | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | EtherMACIn | MTU | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 28 | C | J | | | | Success | | 28 | C | J | SET | IPv4NextHop | IPv4NextHopTable | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | IPv4NextHop | IPv4NextHopTable | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 29 | C | J | | | | Success | | 29 | C | J | SET | IPv4UcastLPM | IPv4PrefixTable | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | IPv4UcastLPM | IPv4PrefixTable | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 30 | C | J | | | | Success | | 30 | C | J | DEL | IPv4NextHop | IPv4NextHopTable | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | DEL | IPv4NextHop | IPv4NextHopTable | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 31 | C | J | | | | Success | | 31 | C | J | DEL | IPv4UcastLPM | IPv4PrefixTable | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | DEL | IPv4UcastLPM | IPv4PrefixTable | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 32 | C | J | | | | Success | | 32 | C | J | SET | EtherPHYCop | AdminStatus | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | EtherPHYCop | AdminStatus | Success | | | G | C | | | | Success |
| | J | G | | | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 33 | C | J | | | | Success | | 33 | C | J | SET | Ether | VlanInputTable | Success |
| | J | C | | | | Success | | | J | C | | Classifier | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | Ether | VlanInputTable | Success | | | G | C | | | | Success |
| | J | G | | Classifier | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 34 | C | J | | | | Success | | 34 | C | J | DEL | Ether | VlanInputTable | Success |
| | J | C | | | | Success | | | J | C | | Classifier | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | DEL | Ether | VlanInputTable | Success | | | G | C | | | | Success |
| | J | G | | Classifier | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 35 | C | J | | | | Success | | 35 | C | J | SET | Ether | VlanOutputTable | Success |
| | J | C | | | | Success | | | J | C | | Encapsulator | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | SET | Ether | VlanOutputTable | Success | | | G | C | | | | Success |
| | J | G | | Encapsulator | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
| | | | | | | | | | | | | | | |
| 36 | C | J | | | | Success | | 36 | C | J | DEL | Ether | VlanOutputTable | Success |
| | J | C | | | | Success | | | J | C | | Encapsulator | | Success |
| | C | G | | | | Success | | | C | G | | | | Success |
| | G | C | DEL | Ether | VlanOutputTable | Success | | | G | C | | | | Success |
| | J | G | | Encapsulator | | Success | | | J | G | | | | Success |
| | G | J | | | | Success | | | G | J | | | | Success |
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
Figure 8: LFB Operation Test Results Figure 8: LFB Operation Test Results
Note on test 1#:
On the wire format of encapsulation on array, only the case of
FULLDATA-in-FULLDATA was tested.
In China's implementation,after test 2# CE have to get all LFBs'
instance data actively according to the queried component of
LFBSelectors.
Note on test 28# and 29#:
Only had new reachable network destination been set,can route entry
be added into system.
Note on test 30# and 31#:
Corresponding nexthop entry must be deleted before prefix entry which
is decided by FE's routing management.
5.2. TML with IPSec Test 5.2. TML with IPSec Test
In this scenario, ForCES TML will run over IPSec channel. In this scenario, the ForCES TML is run over IPSec. Implementers
Implementors joined this interoperability test use the same third- joined this interoperability test use the same third-party tool
party tool software 'racoon' to establish IPSec channel. Some software 'racoon' to establish IPSec channel. Some typical LFB
typical LFB operation tests as in Scenario 1 have been repeated with operation tests as in Scenario 1 are repeated with the IPSec enabled
the new security TML. TML.
A note on this test is, because of the system difficulty to implement A note on this test is, because of the system difficulty to implement
IPSec over TML, Greece did not join in the test. Therefore, this IPSec over TML, Greece did not join in the test. Therefore, this
scenario only successfully took place between C and J. However, it is scenario only took place between C and J.
still valid to make the interoperability test among two participants.
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 | C | J | GET | FEObject | LFBTopology | Success | | 1 | C | J | GET | FEObject | LFBTopology | Success |
| | J | C | | | | Success | | | J | C | | | | Success |
| | | | | | | | | | | | | | | |
skipping to change at page 23, line 26 skipping to change at page 23, line 40
| | J | C | | Classifier | | Success | | | J | C | | Classifier | | Success |
| | | | | | | | | | | | | | | |
| 4 | C | J | DEL | Ether | VlanInputTable | Success | | 4 | C | J | DEL | Ether | VlanInputTable | Success |
| | J | C | | Classifier | | Success | | | J | C | | Classifier | | Success |
+-----+----+-----+-----+--------------+-------------------+---------+ +-----+----+-----+-----+--------------+-------------------+---------+
Figure 9: TML with IPSec Test Results Figure 9: TML with IPSec Test Results
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 connects and associates with a master CE and
and a backup CE. When the master CE is considered disconnected the a backup CE. When the master CE is deemed disconnected the FE would
FE would attempt to find another associated CE to become the master 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.
Due to a bug in the FE, a possible issue was caught. The bug in the Due to a bug in one of the FEs, a interesting issue was caught: it
FE introduced a delay in message handling of 1 second. The master CE was observed that the buggy FE took up to a second to failover. It
was sending Heartbeats at a rate of one in 500milliseconds (2 per was eventually found that the issue was due to the FE's
second). As heartbeats are of very low priority, the FE was working prioritization of the different CEs. All messages from the backup CE
fine with associated only with the master CE. However when the FE were being ignored unless the master CE is disconnected.
attempted to associate with the backup CE the following issue
occured.
The FE was checking first for messages from all priorities from the
master CE and if the master CE hasn't sent any messages then it would
check the backup CE. So, when the FE was ordered to begin
associating with the backup CE , it sent the Association setup
message, the backup CE received it, responded back with an
Association Setup result, but the FE never processed managed to
process it.
While the bug was fixed and the CEHA scenario was completed While the bug was fixed and the CEHA scenario was completed
successfully, the issue still remains. This is actually an successfully, the authors feel it was important to capture the
implementation issue of how the FE prioritizes incoming messages from implementation issue in this document. The recommended approach is
multiple CEs. The recommended approach is the following: the following:
o The FE SHOULD receive and handle messages first from the master CE o The FE SHOULD receive and handle messages first from the master CE
on all priority channels to maintain proper functionality and then on all priority channels to maintain proper functionality and then
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
As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib], As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib],
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 should be construted. Figure 7, a ForCES router running OSPF protocol was constructed. In
Moreover, a set of LFBs including RedirectIn, RedirectOut, addition, a set of LFBs including RedirectIn, RedirectOut,
IPv4UcastLPM, and IPv4NextHop LFBs should be constructed and be IPv4UcastLPM, and IPv4NextHop LFBs are used. RedirectIn and
joined in a processing data path. RedirectIn and RedirectOut LFBs RedirectOut LFBs redirect OSPF hello and LSA packets from and to CE.
redirect OSPF hello and LSA packets from and to CE. Smartbits test A Smartbits test machine is used to simulate an OSPF router and
machine is used to simulate an OSPF router and try to exchange the exchange the OSPF hello and LSA packets with CE in ForCES router.
OSPF hello packet and LSA packet with CE in ForCES router.
Cases (a) and (b) in Figure 7 both need a RedirectIn LFB to send OSPF Cases (a) and (b) in Figure 7 both need a RedirectIn LFB to send OSPF
packets generated by CE to FE by use of ForCES packet redirect packets generated by CE to FE by use of ForCES packet redirect
messages. The OSPF packets are futher sent to an outside OSPF Router messages. The OSPF packets are further sent to an outside OSPF
by the FE via forwarding LFBs including IPv4NextHop and IPv4UcastLPM Router by the FE via forwarding LFBs including IPv4NextHop and
LFBs. A RedirectOut LFB in FE is used to send OSPF packets received IPv4UcastLPM LFBs. A RedirectOut LFB in the FE is used to send OSPF
from outside OSPF Router to CE by ForCES packet redirect messages. packets received from outside OSPF Router to CE by ForCES packet
redirect messages.
By running OSPF protocol, CE in the ForCES router then can generate By running OSPF, the CE in the ForCES router can generate new routes
new routes and load them to routing table in FE. FE is then able to and load them to routing table in FE. The FE is then able to forward
forward packets according to the routing table. packets according to the routing table.
The test is reported with the results in Figure 10 The test is reported with the results in Figure 10
+-----+----+-----+-------------------------+--------------+---------+ +-----+----+-----+-------------------------+--------------+---------+
|Test#| CE |FE(s)| Item | LFBs Related | Result | |Test#| CE |FE(s)| Item | LFBs Related | Result |
+-----+----+-----+-------------------------+--------------+---------+ +-----+----+-----+-------------------------+--------------+---------+
| 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success | | 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | | | | | | | | |
| 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success | | 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success |
| | | | | | | | | | | | | |
| 3 | J | C |Redirect ospf packet from| RedirectIn | Success | | 3 | J | C |Redirect ospf packet from| RedirectIn | Success |
| | | | CE to SmartBits | | | | | | | CE to SmartBits | | |
| | | | | | | | | | | | | |
| 4 | J | C |Redirect ospf packet from| RedirectOut | Success | | 4 | J | C |Redirect ospf packet from| RedirectOut | Success |
| | | | SmartBits to CE | | | | | | | SmartBits to CE | | |
| | | | | | | | | | | | | |
| 5 | J | C | Metadata in | RedirectOut | Success | | 5 | J | C | Metadata in | RedirectOut | Success |
| | | | redirect message | RedirectIn | | | | | | redirect message | RedirectIn | |
| | | | | | | | | | | | | |
| 6 | J | C |OSPF neiborhood discovery| RedirectOut | Success | | 6 | J | C |OSPF neighbor discovery | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | | | | | | | | | |
| 7 | J | C | OSPF DD exchange | RedirectOut | Success | | 7 | J | C | OSPF DD exchange | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | | | | | | | | | |
| 8 | J | C | OSPF LSA exchange | RedirectOut | Success | | 8 | J | C | OSPF LSA exchange | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| | | | | | | IPv4UcastLPM| |
| | | | | | | | | | | | | |
| 9 | J | C | Data Forwarding | RedirectOut | | | 9 | J | C | Data Forwarding | RedirectOut | Success |
| | | | | RedirectIn | Success | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| | | | | | | IPv4UcastLPM| |
| | | | | | | | | | | | | |
| 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success | | 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success |
| | | | | | | | | | | | | |
| 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success | | 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success |
| | | | | | | | | | | | | |
| 12 | C | J |Redirect ospf packet from| RedirectIn | Success | | 12 | C | J |Redirect ospf packet from| RedirectIn | Success |
| | | | CE to other OSPF router | | | | | | | CE to other OSPF router | | |
| | | | | | | | | | | | | |
| 13 | C | J |Redirect ospf packet from| RedirectOut | Success | | 13 | C | J |Redirect ospf packet from| RedirectOut | Success |
| | | |other OSPF router to CE | | | | | | |other OSPF router to CE | | |
| | | | | | | | | | | | | |
| 14 | C | J | Metadata in | RedirectOut | Success | | 14 | C | J | Metadata in | RedirectOut | Success |
| | | | redirect message | RedirectIn | | | | | | redirect message | RedirectIn | |
| | | | | | | | | | | | | |
| 15 | C | J |OSPF neiborhood discovery| RedirectOut | Success | | 15 | C | J |OSPF neighbor discovery | RedirectOut | Success |
| | | | | RedirectIn | | | | | | | RedirectIn | |
| | | | | | | | | | | | | |
| | | | | RedirectOut | | | 16 | C | J | OSPF DD exchange | RedirectOut | Failure |
| 16 | C | J | OSPF DD exchange | RedirectIn | Failure | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | | | | | | | | | |
| 17 | C | J | OSPF LSA exchange | RedirectOut | | | 17 | C | J | OSPF LSA exchange | RedirectOut | Failure |
| | | | | RedirectIn | Failure | | | | | | RedirectIn | |
| | | | | IPv4NextHop | | | | | | | IPv4NextHop | |
| | | | | IPv4UcastLPM| | | | | | | IPv4UcastLPM| |
+-----+----+-----+-------------------------+--------------+---------+ +-----+----+-----+-------------------------+--------------+---------+
Figure 10: Packet Forwarding Test Results Figure 10: Packet Forwarding Test Results
Note on test 1# and 2#:
Before redirect channel working normally, multicast route pointed to
localhost must be added manually firstly.
Note on test 3# to 9#:
During the tests, ospf packets received from CE were found by
Ethereal/Wireshark with checksum errors. China's FE corrected the
checksum in FE so that the Smartbits would not drop the packets and
the neighbor discovery can continue. Such correcting action does not
affect the test scenarios and the results.
Comment on Test #16 and #17: Comment on Test #16 and #17:
The two test items failed. Note that Test #7 and #8 are exactly the The two test items failed. Note that Test #7 and #8 are exactly the
same as these tests, only with CE and FE implementors are exchanged, same as these tests, only with CE and FE implementers are exchanged,
and Test #12 and #13 show the redirect channel works well. As a and Test #12 and #13 show the redirect channel works well. As a
result, it can be infered that the problem caused the test failure result, it can be inferred that the problem caused the test failure
was almost certainly from the implementation of the related LFBs was almost certainly from the implementation of the related LFBs
rather than from the ForCES protocol design problem, therefore the rather than from the ForCES protocol design problem, therefore the
failure does not lead to the interoperability problem on ForCES. failure does not lead to the interoperability problem on ForCES.
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:
Assuming that an LFB has two components, one a struct with ID 1 and Assuming that an LFB has two components, one is a struct with ID 1
an array with ID 2 with two components of u32 both per row. and the other an array with ID 2, further with two components of u32
both inside, as below:
struct1: type struct, ID=1 struct1: type struct, ID=1
components are: components are:
a, type u32, ID=1 a, type u32, ID=1
b, type u32, ID=2 b, type u32, ID=2
table1: type array, ID=2 table1: type array, ID=2
components for each row are (a struct of): components for each row are (a struct of):
x, type u32, ID=1 x, type u32, ID=1
y, type u32, ID=2 y, type u32, ID=2
1. On response of PATH-DATA format 1. On response of PATH-DATA format
When a CE sends a config/query ForCES protocol message to an FE from When a CE sends a config/query ForCES protocol message to an FE from
a different implementor, the CE probably receives response from the a different implementer, the CE probably receives response from the
FE with different PATH-DATA encaplation format. For example, if a CE FE with different PATH-DATA encapsulation format. For example, if a
sends a query message with a path of 1 to a third party FE to CE sends a query message with a path of 1 to a third party FE to
manipulate struct 1 as defined above, the FE is probable to generate manipulate struct 1 as defined above, the FE is probable to generate
response with two different PATH-DATA encaplation format: one is the response with two different PATH-DATA encapsulation format: one is
value with FULL/SPARSE-DATA and the other is the value with many the value with FULL/SPARSE-DATA and the other is the value with many
parallel PATH-DATA TLV and nested PATH-DATA TLV, as below: parallel PATH-DATA TLV and nested PATH-DATA TLV, as below:
format 1: format 1:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=1 IDs=1
FULLDATA-TLV containing valueof(a),valueof(b) FULLDATA-TLV containing valueof(a),valueof(b)
format 2: format 2:
OPER = GET-RESPONSS-TLV OPER = GET-RESPONSE-TLV
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=1 IDs=1
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=1 IDs=1
FULLDATA-TLV containing valueof(a) FULLDATA-TLV containing valueof(a)
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=2 IDs=2
FULLDATA-TLV containing valueof(b) FULLDATA-TLV containing valueof(b)
The interoperability test shows that an ForCES element (CE or FE) The interoperability test witnessed that a ForCES element (CE or FE)
sender is free to choose whatever data structure that IETF ForCES sender is free to choose whatever data structure that IETF ForCES
documents define and best suits the element, while an ForCES element documents define and best suits the element, while a ForCES element
(CE or FE) is preferable to accept and process information (requests (CE or FE) MUST be able to accept and process information (requests
and responses) that use any legitimate structure defined by IETF and responses) that use any legitimate structure defined by IETF
ForCES documents. While in the case an ForCES element is free to ForCES documents. While in the case a ForCES element is free to
choose any legitimate data structure as a response, it is preferred choose any legitimate data structure as a response, it is preferred
the ForCES element responds in the same format that the request was the ForCES element responds in the same format that the request was
made, as it is most probably the data structure is the request sender made, as it is most probably the data structure is the request sender
looks forward to receive. looks forward to receive.
2. On operation to array 2. On operation to array
An array operation may also have several different data encaplation An array operation may also have several different data encapsulation
formats. For instance, if a CE sends a config message to table 1 formats. For instance, if a CE sends a config message to table 1
with a path of (2.1), which refers to component with ID=2, which is with a path of (2.1), which refers to component with ID=2, which is
an array, and the second ID is the row, so row 1, it may be an array, and the second ID is the row, so row 1, it may be
encapsulated with three formats as below: encapsulated with three formats as below:
format 1: format 1:
OPER = SET-TLV OPER = SET-TLV
PATH-DATA-TLV: PATH-DATA-TLV:
IDs=2.1 IDs=2.1
FULLDATA-TLV conaining valueof(x),valueof(y) FULLDATA-TLV conaining valueof(x),valueof(y)
skipping to change at page 34, line 28 skipping to change at page 34, line 28
[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.
11.2. Informative References 11.2. Informative References
[Ethereal] [Ethereal]
"Ethereal is a protocol analyzer. The specific Ethereal "Ethereal, also named Wireshark, is a protocol analyzer.
that was used is an updated Ethereal, by Fenggen Jia, that The specific Ethereal that was used is an updated
can analyze and decode the ForCES protocol messages", http Ethereal, by Fenggen Jia, that can analyze and decode the
://www.ietf.org/mail-archive/web/forces/current/ ForCES protocol messages", http://www.ietf.org/
msg03687.html . mail-archive/web/forces/current/msg03687.html .
[I-D.ietf-forces-ceha] [I-D.ietf-forces-ceha]
Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
Intra-NE High Availability", draft-ietf-forces-ceha-01 Intra-NE High Availability", draft-ietf-forces-ceha-01
(work in progress), February 2011. (work in progress), February 2011.
[I-D.ietf-forces-lfb-lib] [I-D.ietf-forces-lfb-lib]
Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "ForCES Logical Function Block (LFB) Library", Halpern, "ForCES Logical Function Block (LFB) Library",
draft-ietf-forces-lfb-lib-05 (work in progress), draft-ietf-forces-lfb-lib-05 (work in progress),
skipping to change at page 36, line 5 skipping to change at page 35, line 16
[RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim,
"Implementation Report for Forwarding and Control Element "Implementation Report for Forwarding and Control Element
Separation (ForCES)", RFC 6053, November 2010. Separation (ForCES)", RFC 6053, November 2010.
[Tcpdump] "Tcpdump is a Linux protocol analyzer. The specific [Tcpdump] "Tcpdump is a Linux protocol analyzer. The specific
tcpdump that was used is a modified tcpdump, by Jamal Hadi tcpdump that was used is a modified tcpdump, by Jamal Hadi
Salim, that can analyze and decode the ForCES protocol Salim, that can analyze and decode the ForCES protocol
messages", http://www.ietf.org/mail-archive/web/forces/ messages", http://www.ietf.org/mail-archive/web/forces/
current/msg03811.html . current/msg03811.html .
[Teamviewer]
"TeamViewer connects to any PC or server around the world
within a few seconds.", http://www.teamviewer.com/ .
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. 145 change blocks. 
249 lines changed or deleted 278 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/