draft-ietf-forces-interop-00.txt   draft-ietf-forces-interop-01.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 8, 2011 NTT Corporation Expires: September 15, 2011 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 7, 2011 March 14, 2011
Interoperability Report for Forwarding and Control Element Separation Interoperability Report for Forwarding and Control Element Separation
(ForCES) (ForCES)
draft-ietf-forces-interop-00 draft-ietf-forces-interop-01
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) interop testing which took place
March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang on March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang
Gongshang University in China. Gongshang University in 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 8, 2011. This Internet-Draft will expire on September 15, 2011.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4
1.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4
1.4. CE HA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. CE HA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Date, Location, and Participants . . . . . . . . . . . . . 8 3.1. Date, Location, and Participants . . . . . . . . . . . . . 8
3.2. Testbed configuration . . . . . . . . . . . . . . . . . . 8 3.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 8
3.2.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Local Configuration . . . . . . . . . . . . . . . . . 9 3.2.2. Local Configuration . . . . . . . . . . . . . . . . . 9
3.2.3. Distributed Configuration . . . . . . . . . . . . . . 10 3.2.3. Distributed Configuration . . . . . . . . . . . . . . 10
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 12 4.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . . 12
4.1.1. Connection Diagram . . . . . . . . . . . . . . . . . . 12 4.1.1. Connection Diagram . . . . . . . . . . . . . . . . . . 12
4.1.2. Design Considerations . . . . . . . . . . . . . . . . 12 4.1.2. Design Considerations . . . . . . . . . . . . . . . . 12
4.1.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 12 4.1.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 12
4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 12 4.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 12
4.2.1. Connection Diagram . . . . . . . . . . . . . . . . . . 13 4.2.1. Connection Diagram . . . . . . . . . . . . . . . . . . 13
4.2.2. Design Considerations . . . . . . . . . . . . . . . . 13 4.2.2. Design Considerations . . . . . . . . . . . . . . . . 13
4.2.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 14 4.2.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 14
4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 14 4.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 14
4.3.1. Connection Diagram . . . . . . . . . . . . . . . . . . 14 4.3.1. Connection Diagram . . . . . . . . . . . . . . . . . . 14
4.3.2. Design Considerations . . . . . . . . . . . . . . . . 14 4.3.2. Design Considerations . . . . . . . . . . . . . . . . 14
4.3.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 15 4.3.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 15
4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 15 4.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . . 16
4.4.1. Connection Diagram . . . . . . . . . . . . . . . . . . 16 4.4.1. Connection Diagram . . . . . . . . . . . . . . . . . . 16
4.4.2. Design Considerations . . . . . . . . . . . . . . . . 16 4.4.2. Design Considerations . . . . . . . . . . . . . . . . 17
4.4.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 17 4.4.3. Testing Proccess . . . . . . . . . . . . . . . . . . . 17
5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 18 5.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . . 19
5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 23 5.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 24
5.3. CE High Availability Test . . . . . . . . . . . . . . . . 24 5.3. CE High Availability Test . . . . . . . . . . . . . . . . 25
5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 25 5.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . . 26
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 27 6.1. On Data Encapsulation Format . . . . . . . . . . . . . . . 29
6.2. On ... . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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 March 24-25, 2011 in the Internet
Technology Lab (ITL) of Zhejiang Gongshang University in China. The Technology Lab (ITL) of Zhejiang Gongshang University in China. The
tests involved several documents namely: ForCES protocol [RFC5810], tests 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
] and ForCES CE HA specification[]. Three independent ForCES [FORCES-LFBLIB] and ForCES CE HA specification[FORCES-CEHA]. Three
implementations participated in the test. 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 interop test held in July 2008 at the University of Patras,
Greece, focussed on validating the basic semantics of the protocol Greece, focussed on validating the basic semantics of the protocol
and model[RFC6053]. and model[RFC6053].
skipping to change at page 6, line 15 skipping to change at page 6, line 15
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 of RFC3654, RFC3746, RFC5810,RFC5811,RFC5812,RFC5812. The documents, including RFC3654, RFC3746,
definitions are repeated below for clarity. RFC5810,RFC5811,RFC5812,RFC5812. Some definitions are repeated below
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 8, line 15 skipping to change at page 8, line 15
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 ForCES interoperability test meeting was held by IETF ForCES
working group on March 24-25, 2011, and was chaired by Jamal Hadi working group on March 24-25, 2011, and was chaired by Jamal Hadi
Salim, the current ForCES working group co-chair. Three independent Salim, the current ForCES working group co-chair. Three independent
ForCES implementations participated in the test: ForCES implementations participated in the test:
* Zhejiang Gongshang University/Hangzhou BAUD Networks, China. This * Zhejiang Gongshang University/Hangzhou BAUD Networks, China. This
implementation is reffered to as "China" in the document for the sake implementation is referred to as "China" or in some cases "C" in the
of brevity. 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" 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" in the document for the sake of brevity. to as "Greece" or in some cases "G" in the document for the sake of
brevity.
During the interoperability test, protocol analyzers Wireshark and During the interoperability test, protocol analyzers Wireshark and
tcpdump were used to verify the validity of ForCES protocol messages tcpdump were used to verify the validity of ForCES protocol messages
and in some cases semantics. Some issues related to interoperability and in some cases semantics.
among implementations were discovered. Most of the issues were
solved on site during the test. The most contentious issue found was Some issues related to interoperability among implementations were
on the format of encapsulation for protocol TLV (Refer to Section 6). discovered. Most of the issues were solved on site during the test.
The most contentious issue found was on the format of encapsulation
for protocol TLV (Refer to Section 6).
Some errata related to ForCES document were found by the
interoperability test. The errata will be reported to related IETF
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. 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 the following teamviewer tool [ref XXX]. The approach is as shown in figure 1. In
figure. the figure, FE/CE refers to FE or CE that the implementor may act
alternatively.
+---------+ +----+ +----------+ +---------+ +----+ +----------+
| FE/CE | | | +---|TeamViewer| | FE/CE | | | +---|TeamViewer|
| China |-----| | /\/\/\/\/\ | | Canada | | China |-----| | /\/\/\/\/\ | | Canada |
+---------+ | | \Internet/ | +----------+ +---------+ | | \Internet/ | +----------+
|LAN |----/ \--| |LAN |----/ \--|
+---------+ | | \/\/\/\/\/ | +----------+ +---------+ | | \/\/\/\/\/ | +----------+
| FE/CE |-----| | | | FE/CE | | FE/CE |-----| | | | FE/CE |
| Japan | | | +---| Greece | | Japan | | | +---| Greece |
+---------+ +----+ +----------+ +---------+ +----+ +----------+
Figure 1: The Approach for all Participants Figure 1: The Approach for all Participants
For interoperability test items, all CEs and FEs SHALL implement For interoperability test items, all CEs and FEs SHALL implement
IPSEC security in the TML. For security, firewalls MUST be used that IPSEC security in the TML. For security, firewalls MUST be used that
will allow only the specific IPs and the SCTP ports defined in the will allow only the specific IPs and the SCTP ports defined in the
ForCES SCTP-TML [RFC5811]. ForCES SCTP-TML [RFC5811].
3.2.2. Local Configuration 3.2.2. Local Configuration
Hardware/Software (CEs and FEs) of China and Japan that were located Hardwares and softwares including CEs and FEs from China and Japan
within the ITL Lab of Zhejiang Gongshang University, were connected implementions that were located within the ITL Lab of Zhejiang
together using ethernet switches.The detailed configuration can be Gongshang University, were connected together using ethernet
seen in the following figure. switches. The configuration can be seen in figure 2.
/\/\/\/\/\ /\/\/\/\/\
\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 39 skipping to change at page 10, line 39
+--------+ +---------------------------------------+ +--------+ +--------+ +---------------------------------------+ +--------+
|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 3.2.3. Distributed Configuration
Hardware/Software (CE and FE) of Greece that were located within the Hardware/Software (CE and FE) of Greece that were located within the
University of Patras premises,were connected together using LAN as University of Patras premises,were connected together using LAN as
shown in the following figure. shown in figure 3.
Such configuation can satisfy all scenarios that are mentioned in
this document. Specially for the scenario of CE High Availability,in
which CE of Greece will be the backup one.
/\/\/\/\/\ /\/\/\/\/\
\Internet/ \Internet/
/ \ / \
\/\/\/\/\/ \/\/\/\/\/
| |
|150.140.254.110(VPN) |150.140.254.110(VPN)
| |
+------------------------------------+ +------------------------------------+
| LAN | | LAN |
+------------------------------------+ +------------------------------------+
| | | | | |
| | | | | |
+------+ +--------+ +------+ +------+ +--------+ +------+
| CE | |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
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 4.1.1. Connection Diagram
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE |
| China| | Japan| | China| |Greece| | Japan| |Greece| | China| | Japan| | China| |Greece| | Japan| |Greece|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 12, line 26 skipping to change at page 12, line 26
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| 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 4.1.2. Design Considerations
First, the scenario of LFB Operation shown in Figure 4 is designed to Firstly, the scenario of LFB Operation shown in Figure 4 is designed
verify all kinds of messages which are defined in RFC 5810. to verify all kinds of messages which are defined in RFC 5810.
Different implementor may have different choices on implemeting RFC Different implementor may have different choices on implemeting RFC
5810 using cases in the protocol messages. However as long as it 5810 using cases in the protocol messages. However as long as it
complies with the RFC 5810, the interoperating peer must have the complies with the RFC 5810, the interoperating peer must have the
ability to decode and handle it. Specially, what we want to verify ability to decode and handle it. Specially, what we want to verify
th most is the format of encasulation for PATHDATA with nested the most is the format of encasulation for PATH-DATA with nested
PATHDATA and the operation(SET, GET,DEL) of array, as well as array PATH-DATAs, and the operation(SET, GET,DEL) of array, as well as
with nested array(This case can be seen in ARP LFB's component of array with nested array. (This case can be seen in ARP LFB's
PortV4AddrInfoTable). 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 Lib[ ]. A succeeded operation in this scenario means all the LFB Library[I-D.ietf-forces-lfb-lib]. Successful test under this
meeting joining implementor follow the instruction given by the scenario means all the implementors have followed the instruction
ForCES LFB Lib. given by the ForCES LFB Library document.
4.1.3. Testing Proccess 4.1.3. Testing Proccess
In order to make interoperability more credible,these three In order to make interoperability more credible,the three
implementors carry out the test alternately. As shown in figure 4, implementors carried out the test in an alternative way acting as a
every side's CE or FE must connect with the other two sides's FE or CE or an FE, as shown in figure 4, combined with 6 cases for this
CE. So that, we shall have 6 cases in this Scenario. Scenario.
4.2. Scenario 2 - TML with IPSec 4.2. Scenario 2 - TML with IPSec
4.2.1. Connection Diagram 4.2.1. Connection Diagram
+------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE |
| China| | Japan| | China| | Japan|
+------+ +------+ +------+ +------+
| | | |
|TML over IPSec |TML over IPSec |TML over IPSec |TML over IPSec
skipping to change at page 13, line 48 skipping to change at page 13, line 48
|Greece| |Japan | |Greece| |Japan |
+------+ +------+ +------+ +------+
(c) (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 4.2.2. Design Considerations
This scenario is designed to implement the requirement that stated in This scenario is designed to implement the requirement that stated in
the section "7. Security Considerations" in RFC 5811. For this the section "7. Security Considerations" in RFC 5811. For this
reason, we design the scenario to make TML to run over the IPSec reason, we designed the scenario to make TML run over IPSec channel
channel that is pre-established. In this scenario all operations for that was pre-established. In this scenario, all operations for
Scenario 1 will be repeated. In this way, we try to verify whether Scenario 1 were just repeated. In this way, we try to verify whether
the interaction between CE and FE can be done normally under such all interactions between CE and FE can be done correctly under an
IPSec enviroment. IPSec enviroment.
4.2.3. Testing Proccess 4.2.3. Testing Proccess
In this scenario, ForCES TML will run over IPSec channel. All the In this scenario, ForCES TML was run over IPSec channel. All the
implementors who joined in this interoperability testing use the same implementors joined in this interoperability used the same third-
third-party tool software 'racoon' to establish IPSec channel. By party tool software 'racoon' to establish IPSec channel. By this
this tool, China and Japan had a successful test, and the following tool, China and Japan had a successful test, and the following items
items have been realized: 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 4.3.1. Connection Diagram
master standby master standby master standby master standby
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE | | CE | | CE | | CE | | CE | | CE | | CE | | CE |
| China| |Greece| |Japan | |Greece| | China| |Greece| |Japan | |Greece|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 14, line 43 skipping to change at page 14, line 43
+------+ +------+ +------+ +------+
| 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 4.3.2. Design Considerations
CE High Availability was also tested in this interoperability test CE High Availability (CEHA) was also tested in this interoperability
based on the the CEHA draft [draft-ietf-forces-ceha-01]. 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 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. 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 4.3.3. Testing Proccess
In this scenario one FE would be connected with two CEs. In pre- In this scenario one FE would be connected and associated with a
association setup, the FE would be configured to have CE1 as master master CE and a backup CE. In the pre-association phase, the FE
CE and CE2 as standby CE and CEFailoverPolicy to High Availability (2 would be configured to have China's or Japan's CE as master CE and
or 3). The FE once associated with the master CE it would then Greece's CE as standby CE. The CEFailoverPolicy component of the FE
attempt to connect and associate with the standby CE. Protocol Object LFB that specifies whether the FE is in High
Availability mode (value 2 or 3) would either be set in the pre-
association phase or in post-association phase by the master CE.
When master CE is considered disconnected, either by TearDown, Loss Once the FE is associated with the master CE it will move to the
of Heartbeats or Disconnected, FE would assume that the standby CE is post-association phase. Then when the CEFailoverPolicy value is set
now the master CE. FE will then send an Event Notification, Primary to 2 or 3, then it will then attempt to connect and associate with
CE Down,to all associated CEs, only the standby CE in this case with the standby CE.
the value of the new master CEID. The standby CE will then respond
by setting with a configuration message the CEID of the FE Protocol When the master CE is considered disconnected, either by TearDown,
Object with it's own ID, the same value, to confirm that the CE Loss of Heartbeats or Disconnected, FE would assume that the standby
considers itself as the master as well. CE is now the master CE. FE will then send an Event Notification,
Primary CE Down,to all associated CEs, only the standby CE in this
case with the value of the new master CEID. The standby CE will then
respond by setting with a configuration message the CEID of the FE
Protocol Object with it's own ID, the same value, to confirm that the
CE considers itself as the master as well.
The steps of the CEHA scenario were the following:
1. In the pre-association phase, setup of FE with master CE and
backup CE
2. FE connecting and associating with master CE.
3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and
associate with backup CE.
4. Once the master CE is considered disconnected then the FE chooses
the first Associated backup CE.
5. It sends an Event Notification specifying that the master CE is
down and who is now the master CE.
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
the switch.
4.4. Scenario 4 - Packet forwarding 4.4. Scenario 4 - Packet forwarding
4.4.1. Connection Diagram 4.4.1. Connection Diagram
+------+ +------+
| CE | | CE |
| Japan| | Japan|
+------+ +------+
| ^ | ^
| | OSPF | | OSPF
| +-------> | +------->
+------+ +------+ +------+ +------+
+--------+ | FE | | OSPF | +--------+ +--------+ | FE | | OSPF | +--------+
|Terminal|------|China |-------|Router|------|Terminal| |Terminal|------|China |-------|Router|------|Terminal|
+--------+ +------+ +------+ +--------+ +--------+ +------+ +------+ +--------+
<-------------------------------------------->
<-------------------------------------------->
Packet Forwarding
(a)
+------+
| CE |
| China|
+------+
^ | ^
OSPF | | | OSPF
<-----+ | +----->
+-------+ +------+ +------+
+--------+ | OSPF | | FE | | OSPF | +--------+
|Terminal|----|Router |----|Japan |-----|Router|----|Terminal|
+--------+ +-------+ +------+ +------+ +--------+
<-------------------------------------------->
Packet Forwarding
(b)
+------+ +------+
| CE | | CE |
| Japan| | China|
+------+ +------+
| ^ ^ |
| | OSPF | |
| +----------+ |
+------+ +------+
+--------+ | FE | | FE | +--------+
|Terminal|------|China |-------|Japan |------|Terminal|
+--------+ +------+ +------+ +--------+
<-------------------------------------------->
Packet Forwarding Packet Forwarding
(a)
+------+ +------+ (c)
| CE | | CE |
| Japan| | China|
+------+ +------+
| ^ ^ |
| | OSPF | |
| +----------+ |
+------+ +------+
+--------+ | FE | | FE | +--------+
|Terminal|------|China |-------|Japan |------|Terminal|
+--------+ +------+ +------+ +--------+
<-------------------------------------------->
Packet Forwarding
(b)
Figure 7: Scenario for IP Packet forwarding Figure 7: Scenario for IP Packet forwarding
4.4.2. Design Considerations 4.4.2. Design Considerations
This Scenario can be used to verify some LFBs such as RedirectIn, This Scenario is used to verify some LFBs such as RedirectIn,
RedirectOut, IPv4NextHop, IPv4UcastLPM.Cases of (a) and (b) in Figure RedirectOut, IPv4NextHop, IPv4UcastLPM defined by ForCES LFB
7 both need RedirectIn LFB send CE's OSPF packet to FE futher to the library[I-D.ietf-forces-lfb-lib]. Cases of (a) and (b) in Figure 7
outside OSPF Router as Packet Redirect Message, RedirectOut LFB send both need a RedirectIn LFB to send CE generated OSPF packets to FE by
OSPF packet received from the outside OSPF Router to CE as well as packet redirect messages. The OSPF packets are futher sent to an
Packet Redirect Message.In such procedure, META DATA that included in outside OSPF Router by the FE via forwarding LFBs like IPv4NextHop,
Packet Redirect Message should be coded and decoded for both CE and IPv4UcastLPM. A RedirectOut LFB in the FE sends OSPF packets
FE. 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 the above can be done with no issue, then the whole NE including If above test process can be done, then this whole NE including FE
FE and CE will work like an OSPF router exchanging OSPF protocol and CE actually work like an OSPF router which exchanges OSPF
information with other OSPF router. As for CE, after finishing OSPF protocol information with other OSPF routers. By running OSPF
exchanging, some routes maybe generated by OSPF and need to be added protocol, the CE can generate new routes and be loaded to FE. In the
to FE. So, IPv4NextHop and Ipv4UcastLPM must be working to support process, IPv4NextHop and Ipv4UcastLPM LFBs must be working to support
such operation. operations.
By sending packet to the destination through the FE, FE should By sending packet to the destination through the FE, FE should
forward packet according to the route generate by OSPF. so, the data forward packet according to the route generated by OSPF. so, the data
path in FE can be tested and LFBs such as EtherPHYCop, EtherMacIn, path in FE can be tested and LFBs such as EtherPHYCop, EtherMacIn,
IPv4Classifier, IPv4Validator, EtherEncasulator, EtherMacOut also be IPv4Classifier, IPv4Validator, EtherEncasulator, EtherMacOut also be
verified. verified.
4.4.3. Testing Proccess 4.4.3. Testing Proccess
First,Boot terminals and routers, and set IP addresses of their First,Boot terminals and routers, and set IP addresses of their
interfaces. interfaces.
Second, Boot CE and FE. Second, Boot CE and FE.
skipping to change at page 18, line 9 skipping to change at page 19, line 9
of FE__s interfaces. of FE__s interfaces.
Fifth, Start OSPF among CE and routers, and set FIB on FE. Fifth, Start OSPF among CE and routers, and set FIB on FE.
Sixth, Send packets between terminals. Sixth, Send packets between terminals.
5. Test Results 5. Test Results
5.1. LFB Operation Test 5.1. LFB Operation Test
For the convinience of stating,abbreviation is used here.So 'C' means For the convinience sake, as mentioned earlier, abbreviations of 'C'
China ,'J' - Japan,'G'Greece and all testing results of this scenario means implementation from China,'J'Japan implementaion, and 'G'
are listed in the following figure as well.(Note: other Scenarios Greece implemenation. Testing results of this scenario are listed in
will follow the definition) the following figure.
+----+----+-----+----+-----------+-----------+--------+-------------+ +----+----+-----+----+-----------+-----------+--------+-------------+
|Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment | |Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment |
|# | | | | |Capability | | | |# | | | | |Capability | | |
+----+----+-----+----+-----------+-----------+--------+-------------+ +----+----+-----+----+-----------+-----------+--------+-------------+
| 1 | C | J | | | |Success |As for the | | 1 | C | J | | | |Success |As for the |
| | J | C | | | |Success | format of | | | J | C | | | |Success | format of |
| | C | G | | | |TBD |encapsulation| | | C | G | | | |Success |encapsulation|
| | G | C | GET| FEObject |LFBTopology|Success |about array | | | G | C | GET| FEObject |LFBTopology|Success |on array, |
| | J | G | | | |Success |Only the case| | | J | G | | | |Success |only the case|
| | G | J | | | |Success |of FULLDATA- | | | G | J | | | |Success |of FULLDATA- |
| | | | | | | |-in-FULLDATA | | | | | | | | |-in-FULLDATA |
| 2 | C | J | | | |Success |is spupported| | 2 | C | J | | | |Success |is supported |
| | J | C | | | |Success |for everyone.| | | J | C | | | |Success |for everyone.|
| | C | G | | | |TBD |Howerver more| | | C | G | | | |Success |Howerver more|
| | G | C | GET| FEObject |LFBSelector|Success |types such as| | | G | C | GET| FEObject |LFBSelector|Success |types such as|
| | J | G | | | s |Success |SPARSEDATA | | | J | G | | | s |Success |SPARSEDATA |
| | G | J | | | |Success |should be | | | G | J | | | |Success |should be |
| | | | | | | |supported for| | | | | | | | |supported |
| 3 | C | J | | | |Success |every party. | | 3 | C | J | | | |Success |in the |
| | J | C | | | |Success | | | | J | C | | | |Success |future. |
| | C | G | | | |TBD | | | | 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 | | | |TBD | | | | 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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherPHYCop|OperStatus |Success | | | | G | C | GET|EtherPHYCop|OperStatus |Success | |
| | J | G | | | |Success | | | | J | G | | | |Success | |
| | G | J | | | |Success |As for the | | | G | J | | | |Success |As for the |
| | | | | | | |format of | | | | | | | | |format of |
| 6 | C | J | | | |Success |PATHDATA, | | 6 | C | J | | | |Success |PATH-DATA, |
| | J | C | | | |Success |J use the | | | J | C | | | |Success |J use the |
| | C | G | | | |TBD |case of | | | C | G | | | |Success |case of |
| | G | C | GET|EtherPHYCop|AdminLink |Success |PATHDATA in | | | G | C | GET|EtherPHYCop|AdminLink |Success |PATH-DATA in |
| | J | G | | | Speed |Success |PATHDATA,C | | | J | G | | | Speed |Success |PATH-DATA,C |
| | G | J | | | |Success |uses | | | G | J | | | |Success |uses |
| | | | | | | |only one | | | | | | | | |only one |
| 7 | C | J | | | |Success |PATHDATA with| | 7 | C | J | | | |Success |PATH-DATA with
| | J | C | | | |Success |mutiple IDs. | | | J | C | | | |Success |mutiple IDs. |
| | C | G | | | |TBD |G uses ... | | | C | G | | | |Success |G uses ... |
| | G | C | GET|EtherPHYCop| OperLink |Success | | | | G | C | GET|EtherPHYCop| OperLink |Success | |
| | J | G | | | Speed |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherPHYCop|AdminDuplex|Success | | | | G | C | GET|EtherPHYCop|AdminDuplex|Success | |
| | J | G | | | Speed |Success | | | | J | G | | | Speed |Success | |
| | G | J | | | |Success | | | | G | J | | | |Success | |
| | | | | | | |The side of | | | | | | | | |The side of |
| 9 | C | J | | | |Success |C think that | | 9 | C | J | | | |Success |C thinks that|
| | J | C | | | |Success |CE SHOULD get| | | J | C | | | |Success |CE SHOULD get|
| | C | G | | | |TBD |LFB instance | | | C | G | | | |Success |LFB instance |
| | G | C | GET|EtherPHYCop|OperDuplex |Success |data | | | G | C | GET|EtherPHYCop|OperDuplex |Success |data |
| | J | G | | | Speed |Success |according to | | | J | G | | | Speed |Success |according to |
| | G | J | | | |Success |LFBSelectors.| | | G | J | | | |Success |LFBSelectors.|
| | | | | | | | | | | | | | | | | |
| 10 | C | J | | | |Success | | | 10 | C | J | | | |Success | |
| | J | C | | | |Success | | | | J | C | | | |Success | |
| | C | G | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherPHYCop| Carrier |Success | | | | G | C | GET|EtherPHYCop| Carrier |Success | |
| | J | G | | | Status |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 | | | |TBD | | | | 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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherMACIn | LocalMac |Success | | | | G | C | GET|EtherMACIn | LocalMac |Success | |
| | J | G | | | Addresses |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 | | | |TBD | | | | 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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherMACIn |Promiscuous|Success | | | | G | C | GET|EtherMACIn |Promiscuous|Success | |
| | J | G | | | Mode |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherMACIn | TxFlow |Success | | | | G | C | GET|EtherMACIn | TxFlow |Success | |
| | J | G | | | Control |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherMACIn | RxFlow |Success | | | | G | C | GET|EtherMACIn | RxFlow |Success | |
| | J | G | | | Control |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 | | | |TBD | | | | 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 | | | |TBD | | | | 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 | | | |TBD | | | | 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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherMACOut| TxFlow |Success | | | | G | C | GET|EtherMACOut| TxFlow |Success | |
| | J | G | | | Control |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET|EtherMACOut| TxFlow |Success | | | | G | C | GET|EtherMACOut| TxFlow |Success | |
| | J | G | | | Control |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 | | | |TBD | | | | 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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | GET| ARP |PortV4Addr |Success | | | | G | C | GET| ARP |PortV4Addr |Success | |
| | J | G | | | InfoTable |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | SET| ARP |PortV4Addr |TBD | | | | G | C | SET| ARP |PortV4Addr |Success | |
| | J | G | | | InfoTable |Success | | | | J | G | | | InfoTable |Success | |
| | G | J | | | |Success | | | | G | J | | | |Success | |
| | | | | | | | | | | | | | | | | |
| 25 | C | J | | | |Success |C's misunder-| | 25 | C | J | | | |Success |C's misunder-|
| | J | C | | | |Success |standing of | | | J | C | | | |Success |standing of |
| | C | G | | | |TBD |the PATHDATA | | | C | G | | | |Success |the PATHDATA |
| | G | C | DEL| ARP |PortV4Addr |Failure |in DEL | | | G | C | DEL| ARP |PortV4Addr |Success |in DEL |
| | J | G | | | InfoTable |Success |Operation. | | | J | G | | | InfoTable |Success |Operation. |
| | G | J | | | |Success |Later C fixed| | | G | J | | | |Success |Later C fixed|
| | | | | | | |the problem | | | | | | | | |the problem |
| 26 | C | J | | | |Success |and make it | | 26 | C | J | | | |Success |and make it |
| | J | C | | | |Success |successful | | | J | C | | | |Success |successful |
| | C | G | | | |TBD |in testing | | | C | G | | | |Success |in testing |
| | G | C | SET|EtherMACIn | LocalMAC |Success |with J. | | | G | C | SET|EtherMACIn | LocalMAC |Success |with J. |
| | J | G | | | Addresses |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 | | | |TBD | | | | 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 |By setting | | 28 | C | J | | | |Success |By setting |
| | J | C | | | |Success |new reachable| | | J | C | | | |Success |new reachable|
| | C | G | | | |TBD |network,Route| | | C | G | | | |Success |network,route|
| | G | C | SET|IPv4NextHop|IPv4NextHop|TBD |entry can be | | | G | C | SET|IPv4NextHop|IPv4NextHop|Success |entry can be |
| | J | G | | | Table |Success |add into | | | J | G | | | Table |Success |added into |
| | G | J | | | |Success |system. | | | G | J | | | |Success |system. |
| | | | | | | | | | | | | | | | | |
| 29 | C | J | | | |Success | | | 29 | C | J | | | |Success | |
| | J | C | | | |Success | | | | J | C | | | |Success | |
| | C | G | | | |TBD | | | | C | G | | | |Success | |
| | G | C | SET| IPv4Ucast |IPv4Prefix |TBD | | | | G | C | SET| IPv4Ucast |IPv4Prefix |Success | |
| | J | G | | LPM | Table |Success | | | | J | G | | LPM | Table |Success | |
| | G | J | | | |Success | | | | G | J | | | |Success | |
| | | | | | | | | | | | | | | | | |
| 30 | C | J | | | |Success | | | 30 | C | J | | | |Success | |
| | J | C | | | |Success |Corresponding| | | J | C | | | |Success |Corresponding|
| | C | G | | | |TBD |nexthop entry| | | C | G | | | |Success |nexthop entry|
| | G | C | DEL|IPv4NextHop|IPv4NextHop|TBD |MUST delete | | | G | C | DEL|IPv4NextHop|IPv4NextHop|Success |MUST delete |
| | J | G | | | Table |Success |before prefix| | | J | G | | | Table |Success |before prefix|
| | G | J | | | |Success |entry. | | | G | J | | | |Success |entry. |
| | | | | | | | | | | | | | | | | |
| 31 | C | J | | | |Success | | | 31 | C | J | | | |Success | |
| | J | C | | | |Success | | | | J | C | | | |Success | |
| | C | G | | | |TBD | | | | C | G | | | |Success | |
| | G | C | DEL| IPv4Ucast |IPv4Prefix |TBD | | | | G | C | DEL| IPv4Ucast |IPv4Prefix |Success | |
| | J | G | | LPM | Table |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 | | | |TBD | | | | 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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | SET| Ether | VlanInput |Success | | | | G | C | SET| Ether | VlanInput |Success | |
| | J | G | | Classifier| Table |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | DEL| Ether | VlanInput |Failure | | | | G | C | DEL| Ether | VlanInput |Success | |
| | J | G | | Classifier| Table |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 | | | |TBD | | | | C | G | | | |Success | |
| | G | C | SET| Ether |VlanOutput |Success | | | | G | C | SET| Ether |VlanOutput |Success | |
| | J | G | |Encapsulato| Table |Success | | | | J | G | |Encapsulato| Table |Success | |
| | G | J | | r | |Success | | | | G | J | | r | |Success | |
| | | | | | | | | | | | | | | | | |
| 36 | C | J | | | |Success | | | 36 | C | J | | | |Success | |
| | J | C | | | |Success | | | | J | C | | | |Success | |
| | C | G | | | |TBD | | | | C | G | | | |Success | |
| | G | C | DEL| Ether |VlanOutput |Failure | | | | G | C | DEL| Ether |VlanOutput |Success | |
| | J | G | |Encapsulato| Table |Success | | | | J | G | |Encapsulato| Table |Success | |
| | G | J | | r | |Success | | | | G | J | | r | |Success | |
+----+----+-----+----+-----------+-----------+--------+-------------+ +----+----+-----+----+-----------+-----------+--------+-------------+
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.All the
implementors who joined this interoperability test use the same implementors who joined this interoperability test use the same
third-party tool software 'racoon' to establish IPSec channel.To be third-party tool software 'racoon' to establish IPSec channel.To be
mentioned is that we have not repeat all the operations listed in mentioned is that we have not repeat all the operations listed in
Scenario 1,only some typical operations have been done. During the Scenario 1,only some typical operations have been done.
test following results as shown in figure occured.
Although some problems still remains in the connection with Greece,
the TML with IPSec test is considered as success. The goal was to
verify whether the interaction between CE and FE can be done normally
under such IPSec environment. Since Japan's and China's
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.
+----+----+-----+----+-----------+-----------+--------+-------------+ +----+----+-----+----+-----------+-----------+--------+-------------+
|Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment | |Test| CE |FE(s)|Oper| LFB |Component/ | Result | Comment |
|# | | | | |Capability | | | |# | | | | |Capability | | |
+----+----+-----+----+-----------+-----------+--------+-------------+ +----+----+-----+----+-----------+-----------+--------+-------------+
| 1 | C | J | | | |Success |For unkown | | 1 | C | J | | | |Success |For unkown |
| | J | C | | | |Success |error in | | | J | C | | | |Success |error in |
| | C | G | | | |TBD |configuration| | | C | G | | | |Failure |configuration|
| | G | C | GET| FEObject |LFBTopology|TBD |with racoon, | | | G | C | GET| FEObject |LFBTopology|Failure |with racoon, |
| | J | G | | | |TBD |Greece still | | | J | G | | | |Failure |Greece still |
| | G | J | | | |TBD |need some | | | G | J | | | |Failure |need some |
| | | | | | | |time to fix | | | | | | | | |time to fix |
| 2 | C | J | | | |Success |the issue. | | 2 | C | J | | | |Success |the issue. |
| | J | C | | | |Success |So,this | | | J | C | | | |Success |So,this |
| | C | G | | | |TBD |scenario only| | | C | G | | | |Failure |scenario only|
| | G | C | GET| FEObject |LFBSelector|TBD |took place | | | G | C | GET| FEObject |LFBSelector|Failure |took place |
| | J | G | | | s |TBD |between C and| | | J | G | | | s |Failure |between C and|
| | G | J | | | |TBD |J. | | | G | J | | | |Failure |J. |
| | | | | | | | | | | | | | | | | |
| 3 | C | J | | | |Success | | | 3 | C | J | | | |Success | |
| | J | C | | | |Success | | | | J | C | | | |Success | |
| | C | G | | | |TBD | | | | C | G | | | |Failure | |
| | G | C | SET| Ether | VlanInput |TBD | | | | G | C | SET| Ether | VlanInput |Failure | |
| | J | G | | Classifier| Table |TBD | | | | J | G | | Classifier| Table |Failure | |
| | G | J | | | |TBD | | | | G | J | | | |Failure | |
| | | | | | | | | | | | | | | | | |
| 4 | C | J | | | |Success | | | 4 | C | J | | | |Success | |
| | J | C | | | |Success | | | | J | C | | | |Success | |
| | C | G | | | |TBD | | | | C | G | | | |Failure | |
| | G | C | DEL| Ether | VlanInput |TBD | | | | G | C | DEL| Ether | VlanInput |Failure | |
| | J | G | | Classifier| Table |TBD | | | | J | G | | Classifier| Table |Failure | |
| | G | J | | | |TBD | | | | G | J | | | |Failure | |
+----+----+-----+----+-----------+-----------+--------+-------------+ +----+----+-----+----+-----------+-----------+--------+-------------+
5.3. CE High Availability Test 5.3. CE High Availability Test
In this scenario one FE would be connected with two CEs. In pre- In this scenario one FE will connect and associate with a master CE
association setup, the FE would be configured to have CE1 as master and a backup CE. When the master CE is considered disconnected the
CE and CE2 as standby CE and CEFailoverPolicy to High Availability (2 FE would attempt to find another associated CE to become the master
or 3). The FE once associated with the master CE it would then CE.
attempt to connect and associate with the standby CE.
When master CE is considered disconnected, either by TearDown, Loss The CEHA scenario as is described in Scenario 3 was completed
of Heartbeats or Disconnected, FE would assume that the standby CE is successfully for both setups.
now the master CE. FE will then send an Event Notification, Primary
CE Down,to all associated CEs, only the standby CE in this case with Due to a bug in the FE, a possible issue was caught. The bug in the
the value of the new master CEID. The standby CE will then respond FE introduced a delay in message handling of 1 second. The master CE
by setting with a configuration message the CEID of the FE Protocol was sending Heartbeats at a rate of one in 500milliseconds (2 per
Object with it's own ID, the same value, to confirm that the CE second). As heartbeats are of very low priority, the FE was working
considers itself as the master as well. fine with associated only with the master CE. However when the FE
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
successfully, the issue still remains. This is actually an
implementation issue of how the FE prioritizes incoming messages from
multiple CEs. The recommended approach is the following:
o The FE SHOULD receive and handle messages first from the master CE
on all priority channels to maintain proper functionality and then
receive and handle messages from the backup CEs.
o Only when the FE is attempting to associate with the backup CEs,
then the FE SHOULD receive and handle messages per priority
channel from all CEs. When all backup CEs are associated with or
deemed unreachable, then the FE SHOULD return to receiving and
handling messages first from the master CE.
5.4. Packet Forwarding Test 5.4. Packet Forwarding Test
The Scenario of packet forwading is the most complex one because it The Scenario of packet forwading is the most complex one because it
need the Scenario 1 must be completed.In this scenario testing,the need the Scenario 1 must be completed.In this scenario testing,the
pattern of J-CE C-FE was carried out. Smartbits's 2 testing ports pattern of J-CE C-FE was carried out. Smartbits's 2 testing ports
connect to FE's 2 data-forwarding ports,meanwhile smartbits simulate connect to FE's 2 data-forwarding ports,meanwhile smartbits simulate
ospf router and try to exchange the OSPF hello packet and LSA packet ospf router and try to exchange the OSPF hello packet and LSA packet
with CE,because CE also has an OSPF process in it so that the whole with CE,because CE also has an OSPF process in it so that the whole
NE including FE and CE looks like an OSPF router. NE including FE and CE looks like an OSPF router.
skipping to change at page 26, line 9 skipping to change at page 27, line 7
smartBits,FE redirect in OSPF hello and LSA packets to smartBits smartBits,FE redirect in OSPF hello and LSA packets to smartBits
received from CE's OSPF process. received from CE's OSPF process.
During the test, results as shown in the following figure are During the test, results as shown in the following figure are
recorded. recorded.
+----+----+-----+----------------+-----------+--------+-------------+ +----+----+-----+----------------+-----------+--------+-------------+
|Test| CE |FE(s)| Item | LFB | Result | Comment | |Test| CE |FE(s)| Item | LFB | Result | Comment |
|# | | | | | | | |# | | | | | | |
+----+----+-----+----------------+-----------+--------+-------------+ +----+----+-----+----------------+-----------+--------+-------------+
| 1 | J | C |IPv4NextHopTable|IPv4NextHop|success | Muticast | | 1 | J | C |IPv4NextHopTable|IPv4NextHop|Success | Muticast |
| | | | SET | | | route is | | | | | SET | | | route is |
| | | | | | | added by | | | | | | | | added by |
| 2 | J | C |IPv4PrefixTable | IPv4Ucast |success |manual,this | | 2 | J | C |IPv4PrefixTable | IPv4Ucast |Success |manual,this |
| | | | SET | LPM | |problem still| | | | | SET | LPM | |problem still|
| | | | | | |need to be | | | | | | | |need to be |
| | | |Redirect ospf | | |fixed in the | | | | |Redirect ospf | | |fixed in the |
| 3 | J | C |packet from CE |RedirectIn |failure | future. | | 3 | J | C |packet from CE |RedirectIn |Success | future. |
| | | |to SmartBits | | | | | | | |to SmartBits | | | |
| | | | | | | As for | | | | | | | | As for |
| | | |Redirect ospf | | | redirect | | | | |Redirect ospf | | | redirect |
| 4 | J | C |packet from |RedirectOut|success | message, | | 4 | J | C |packet from |RedirectOut|Success | message, |
| | | |SmartBits to CE | | |ospf hello | | | | |SmartBits to CE | | |ospf hello |
| | | | | | |packet in 2 | | | | | | | |packet in 2- |
| | | |Metadata in |RedirectOut| |direction can| | | | |Metadata in |RedirectOut| |direction can|
| 5 | J | C |redirect message|RedirectIn |success |be wathed by | | 5 | J | C |redirect message|RedirectIn |Success |be wathed by |
| | | | | | | wireshark. | | | | | | | | wireshark. |
| | | | | | |however ospf | | | | | | | |however ospf |
| | | |OSPF neiborhood |RedirectOut| | packet | | | | |OSPF neiborhood |RedirectOut| | packet |
| 6 | J | C | discovery |RedirectIn |failure |received from| | 6 | J | C | discovery |RedirectIn |Success |received from|
| | | | | | |CE have an | | | | | | | |CE have an |
| | | | |RedirectOut| |error with | | | | | |RedirectOut| |error with |
| | | | OSPF LSA |RedirectIn | |checksum,so | | | | | OSPF DD |RedirectIn | |checksum,so |
| 6 | J | C | exchange |IPv4NextHop|TBD |smartBits | | 7 | J | C | exchange |IPv4NextHop|Success |smartBits |
| | | | | IPv4Ucast | |will drop it | | | | | | IPv4Ucast | |will drop it |
| | | | | LPM | |with no | | | | | | LPM | |with no |
| | | | | | |neighborhood | | | | | | | |neighborhood |
| | | | | | |discovered. | | | | | | | |discovered. |
| 8 | J | C | OSPF LSA |RedirectOut| | |
| | | | exchange |RedirectIn |Success | |
| | | | |IPv4NextHop| | |
| | | | | IPv4Ucast | | |
| | | | | LPM | | |
| | | | | | | |
| | | | |RedirectOut| | |
| 9 | J | C |Data Forwarding |RedirectIn | | |
| | | | |IPv4NextHop|Success | |
| | | | | IPv4Ucast | | |
| | | | | LPM | | |
| | | | | | | |
| 10 | C | J |IPv4NextHopTable|IPv4NextHop|Success | |
| | | | SET | | | |
| | | | | | | |
| 11 | C | J |IPv4PrefixTable | IPv4Ucast |Success | |
| | | | SET | LPM | | |
| | | | | | | |
| | | |Redirect ospf | | | |
| 12 | C | J |packet from CE |RedirectIn |Success | |
| | | |to other OSPF | | | |
| | | | router | | | |
| | | | | | | |
| | | |Redirect ospf | | | |
| 12 | C | J |packet from |RedirectOut|Success | |
| | | |other OSPF | | | |
| | | |router to CE | | | |
| | | | | | | |
| | | |Metadata in |RedirectOut| | |
| 13 | C | J |redirect message|RedirectIn |Success | |
| | | | | | | |
| | | | | | | |
| | | |OSPF neiborhood |RedirectOut| | |
| 14 | C | J | discovery |RedirectIn |Success | |
| | | | | | | |
| | | | |RedirectOut| | |
| | | | OSPF DD |RedirectIn | | |
| 15 | C | J | exchange |IPv4NextHop|Failure |FE connected |
| | | | | IPv4Ucast | |by 2 OSPF |
| | | | | 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:
1. On response of PATH-DATA format When a CE sends a config/query Assuming that an LFB has two components, one a struct with ID 1 and
ForCES protocol message to an FE with a different implementor, the CE an array with ID 2 with two components of u32 both per row.
is probable to receive response from the FE with different PATH-DATA
encaplation format. For example, if a CE sends a query message with
a path (1.1.1) to a third party FE, the FE is probable to generate
response with two different PATH-DATA encaplation format: the value
with FULL/SPARSE-DATA, and the format of many parallel PATHDATA TLV
and nested PATHDATA TLV, as below:
format 1: struct1: type struct, ID=1
GET-RESPONSE: components are:
PATH DATA (id:1.2) a, type u32, ID=1
FULL DATA(a,b) b, type u32, ID=2
table1: type array, ID=2
components for each row are (a struct of):
x, type u32, ID=1
y, type u32, ID=2
1. On response of PATH-DATA format
When a CE sends a config/query ForCES protocol message to an FE from
a different implementor, the CE probably receives response from the
FE with different PATH-DATA encaplation format. For example, if a 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
response with two different PATH-DATA encaplation format: one is 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:
format 1:
OPER = GET-RESPONSE-TLV
PATH-DATA-TLV:
IDs=1
FULLDATA-TLV containing valueof(a),valueof(b)
format 2: format 2:
GET-RESPONSE: OPER = GET-RESPONSS-TLV
PATH DATA PATH-DATA-TLV:
PATH DATA IDs=1
FULL DATA PATH-DATA-TLV:
PATH DATA IDs=1
FULL DATA FULLDATA-TLV containing valueof(a)
...... PATH-DATA-TLV:
IDs=2
FULLDATA-TLV containing valueof(b)
The interoperability test shows that an ForCES element (CE or FE) The interoperability test shows that an 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 an ForCES element
(CE or FE) MUST be prepared to accept and process information (CE or FE) is preferable to accept and process information (requests
(requests and responses) that use any legitimate structure defined by and responses) that use any legitimate structure defined by IETF
IETF ForCES documents. ForCES documents. While in the case an ForCES element is free to
choose any legitimate data structure as a response, it is preferred
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
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 encaplation
formats. For example, a component of array with two elements (a and formats. For instance, if a CE sends a config message to table 1
b) in one entry, CE may encapsulate a SET message in two format: 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
encapsulated with three formats as below:
format 1: format 1:
SET: OPER = SET-TLV
PATH DATA (id:1.2) PATH-DATA-TLV:
FULL DATA(a,b) IDs=2.1
FULLDATA-TLV conaining valueof(x),valueof(y)
format 2: format 2:
SET: OPER = SET-TLV
PATH DATA PATH-DATA-TLV:
PATH DATA (id:1) IDs=2.1
FULL DATA (a) PATH-DATA-TLV:
PATH DATA (id:2) IDs=1
FULL DATA (b) FULLDATA-TLV containing valueof(x)
PATH-DATA-TLV
IDs=2
FULLDATA-TLV containing valueof(y)
Via the interoperability test experience, this document recommends Moreover, if CE is targeting the whole array, for example if the
that format 1 be used for all array data format encapsulations. It array is empty and CE wants to add the first row to the table, it
is purely because format 1 can achieve the best efficiency. could also adopt another format:
6.2. On ... format 3:
OPER = SET-TLV
PATH-DATA-TLV:
IDs=2
FULLDATA-TLV containing rowindex=1,valueof(x),valueof(y)
TBD The interoperability test experience shows that format 1 and format
3, which take full advantage of multiple data elements description in
one TLV of FULLDATA-TLV, get more efficiency, although format 2 can
also get the same operating goal.
7. Contributors 7. Contributors
Contributors who have made major contributions to the Contributors who have made major contributions to the
interoperability test are as below: interoperability test are as below:
Hirofumi Yamazaki Hirofumi Yamazaki
NTT Corporation NTT Corporation
Tokyo Tokyo
Japan Japan
skipping to change at page 31, line 7 skipping to change at page 34, line 7
The authors would also like thank the following test participants: The authors would also like thank the following test participants:
Chuanhuang Li, Hangzhou BAUD Networks Chuanhuang Li, Hangzhou BAUD Networks
Ligang Dong, Zhejiang Gongshang University Ligang Dong, Zhejiang Gongshang University
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
(TBD) This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
TBD TBD
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 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003. of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. 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
 End of changes. 109 change blocks. 
270 lines changed or deleted 468 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/