draft-ietf-forces-implementation-report-00.txt   draft-ietf-forces-implementation-report-01.txt 
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force E. Haleplidis
Internet-Draft University of Patras Internet-Draft University of Patras
Intended status: Informational K. Ogawa Intended status: Informational K. Ogawa
Expires: March 11, 2010 NTT Corporation Expires: August 29, 2010 NTT Corporation
W. Wang W. Wang
Zhejiang Gongshang University Zhejiang Gongshang University
J. Hadi Salim J. Hadi Salim
Mojatatu Networks Mojatatu Networks
September 7, 2009 February 25, 2010
Implementation Report for ForCES Implementation Report for ForCES
draft-ietf-forces-implementation-report-00 draft-ietf-forces-implementation-report-01
Abstract
Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC3654 has defined
the ForCES requirements, and RFC3746 has defined the ForCES
framework.
This document is an implementation report of the ForCES Protocol,
Model and SCTP-TML, including the report on interoperability testing
and the current state of ForCES implementations.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 2, line 5
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 11, 2010. This Internet-Draft will expire on August 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Forwarding and Control Element Separation (ForCES) defines an described in the BSD License.
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC3654 has defined
the ForCES requirements, and RFC3746 has defined the ForCES
framework.
This document is an implementation report of the ForCES Protocol,
Model and SCTP-TML, including the report on interoperability testing
and the current state of ForCES implementations.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 6 2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 7
2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 6 2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 7
3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Implementation Experience . . . . . . . . . . . . . . . . 10 6.1. Implementation Experience . . . . . . . . . . . . . . . . 11
6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 10 6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 11
6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 11 6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 12
6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 12 6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 13
6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 13 6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 14
6.1.1.4. Operation Types Supported . . . . . . . . . . . . 14 6.1.1.4. Operation Types Supported . . . . . . . . . . . . 15
6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 15 6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 16
6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 15 6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 16
6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 16 6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 17
6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 17 6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 18
6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 17 6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 18
6.1.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . 20 6.1.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . 21
6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 20 6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 21
6.1.3.2. Message Handling at specific priorities . . . . . 21 6.1.3.2. Message Handling at specific priorities . . . . . 22
6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 22 6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 23
6.2. Interoperability Report . . . . . . . . . . . . . . . . . 22 6.2. Interoperability Report . . . . . . . . . . . . . . . . . 23
6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1.1. Scenario 1 - Pre-association Setup . . . . . . . . 23 6.2.1.1. Scenario 1 - Pre-association Setup . . . . . . . . 24
6.2.1.2. Scenario 2 - TML priority channels connection . . 24 6.2.1.2. Scenario 2 - TML priority channels connection . . 25
6.2.1.3. Scenario 3 - Association Setup - Association 6.2.1.3. Scenario 3 - Association Setup - Association
Complete . . . . . . . . . . . . . . . . . . . . . 24 Complete . . . . . . . . . . . . . . . . . . . . . 25
6.2.1.4. Scenario 4 - CE query . . . . . . . . . . . . . . 26
6.2.1.4. Scenario 4 - CE query . . . . . . . . . . . . . . 24 6.2.1.5. Scenario 5 - Heartbeat monitoring . . . . . . . . 26
6.2.1.5. Scenario 5 - Heartbeat monitoring . . . . . . . . 25 6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 26
6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 25 6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 27
6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 25 6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 27
6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 26 6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 27
6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 26 6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 29
6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 28 6.2.2.3. ForCES SCTP-TML Features . . . . . . . . . . . . . 32
6.2.2.3. ForCES SCTP-TML Features . . . . . . . . . . . . . 30 6.2.3. Interoperability Results . . . . . . . . . . . . . . . 33
6.2.3. Interoperability Results . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.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].
1.2. Definitions 1.2. Definitions
skipping to change at page 6, line 10 skipping to change at page 7, line 10
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.
2. Introduction 2. Introduction
This is an implementation report for the ForCES protocol, model and This is an implementation report for the ForCES protocol, model and
SCTP-TML documents and includes an interoperability report. SCTP-TML documents and includes an interoperability report.
It follows the outline suggested by [I-D.dusseault-impl-reports]. It follows the outline suggested by [RFC5657].
Forwarding and Control Element Separation (ForCES) defines an Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined
the ForCES requirements, and [RFC3746] has defined the ForCES the ForCES requirements, and [RFC3746] has defined the ForCES
framework. framework.
2.1. ForCES Protocol 2.1. ForCES Protocol
skipping to change at page 7, line 10 skipping to change at page 8, line 10
implementations MUST be portable across all TMLs. Although more than implementations MUST be portable across all TMLs. Although more than
one TML may be standardized for the ForCES Protocol, all one TML may be standardized for the ForCES Protocol, all
implementations MUST IMPLEMENT the SCTP TML implementations MUST IMPLEMENT the SCTP TML
[I-D.ietf-forces-sctptml]. [I-D.ietf-forces-sctptml].
3. Summary 3. Summary
The authors attest that the ForCES Protocol, Model and SCTP-TML meet The authors attest that the ForCES Protocol, Model and SCTP-TML meet
the requirements for Draft Standard. the requirements for Draft Standard.
Three independent implementations were surveyed and found to already Three independent implementations, NTT Japan, University of Patras
and Zhejiang Gongshang University, were surveyed and found to already
implement all the major features. All implementors mentioned they implement all the major features. All implementors mentioned they
will be implementing all missing features in the future. will be implementing all missing features in the future.
An interop test was conducted in July/2009 for all three An interop test was conducted in July/2009 for all three
implementations. Two other organizations, which independently implementations. Two other organizations, Mojatatu Networks and
extended two different well known public domain protocol analyzers, Hangzhou Baud Information and Networks Technology Corporation, which
also participated in the interop for a total of five independent independently extended two different well known public domain
organizations implementing. The two protocol analyzers were used to protocol analyzers, Ethereal/Wireshark and tcpdump, also participated
verify validity of ForCEs protocol messages (and in some cases in the interop for a total of five independent organizations
semantics). implementing. The two protocol analyzers were used to verify
validity of ForCEs protocol messages (and in some cases semantics).
There were no notable difficulty in the interoperability test and There were no notable difficulties in the interoperability test and
almost all issues were code bugs that were dealt with mostly on site almost all issues were code bugs that were dealt with mostly on site
and tests repeated successfully. and tests repeated successfully.
4. Methodology 4. Methodology
This report has both an implementation experience survey as well as This report has both an implementation experience survey as well as
the results of the interoperability test. the results of the interoperability test.
The survey information was gathered after implementors answered a The survey information was gathered after implementors answered a
brief questionnaire with all ForCES Protocol, Model and SCTP-TML brief questionnaire with all ForCES Protocol, Model and SCTP-TML
features. The results can be seen in Section 6.1 features. The results can be seen in ForCES Features (Section 6.1)
The interoperability results were part of the interoperability test. The interoperability results were part of the interoperability test.
Extended Ethereal and extended Tcpdump were used to verify the Extended Ethereal and extended Tcpdump were used to verify the
results. The results can be seen in Section 6.2 results. The results can be seen in Interoperability Report
(Section 6.2)
5. Exceptions 5. Exceptions
The core features of the ForCES Protocol, Model and SCTP-TML have The core features of the ForCES Protocol, Model and SCTP-TML have
been implemented and tested in an interop in July, 2009. The been implemented and tested in an interop in July, 2009. The
intention of the interop testing was to validate that all the main intention of the interop testing was to validate that all the main
features of the 3 core documents were inter-operable amongst features of the 3 core documents were inter-operable amongst
different implementations. The tested features can be seen in different implementations. The tested features can be seen in Tested
Section 6.2.2. Features (Section 6.2.2).
Different organizations surveyed have implemented certain features Different organizations surveyed have implemented certain features
but not others. This approach is driven by presence of different but not others. This approach is driven by presence of different
LFBs the different organizations have currently implemented. All LFBs the different organizations have currently implemented. All
organizations surveyed have indicated intention to implement all organizations surveyed have indicated intention to implement all
outstanding features in due time. The implemented features can be outstanding features in due time. The implemented features can be
seen in Section 6.1. seen in Section 6.1.
Regarding the security feature of TML, IPSec, the fact that is not The mandated TML security requirement, IPSec, was not validated
currently implemented does not affect the validity of this during the interop and is not discussed in this document. Since
implementation report, since IPSec is a well-known and widely IPSec is well known and is widely deployed not testing in presence of
implemented protocol and does not affect the actual ForCES protocol IPSec does not invalidate the tests done.
and model in any way.
Although the SCTP priority ports have been changed since the
interoperability test with the latest SCTP-TML draft, the change has
no impact in the validity of the interoperability test.
6. Detail Section 6. Detail Section
6.1. Implementation Experience 6.1. Implementation Experience
Three different organizations have implemented the ForCES Protocol, Three different organizations have implemented the ForCES Protocol,
Model and SCTP-TML and answered a questionnaire. These are: Model and SCTP-TML and answered a questionnaire. These are:
o NTT Japan. o NTT Japan.
skipping to change at page 10, line 29 skipping to change at page 11, line 29
analyzers capable of understanding ForCES protocol messages, also are analyzers capable of understanding ForCES protocol messages, also are
considered part of an implementation as they can offer validation of considered part of an implementation as they can offer validation of
exchanged protocol messages. Two such extensions have been created: exchanged protocol messages. Two such extensions have been created:
o Extension to Ethereal/Wireshark [ethereal]. o Extension to Ethereal/Wireshark [ethereal].
o Extension to Tcpdump [tcpdump]. o Extension to Tcpdump [tcpdump].
All implementors were asked regarding the ForCES features they have All implementors were asked regarding the ForCES features they have
implemented. For every item listed the respondents indicated whether implemented. For every item listed the respondents indicated whether
they had implemented it, will implement it, or won't implement it at they had implemented, will implement, or won't implement at all.
all.
6.1.1. ForCES Protocol Features 6.1.1. ForCES Protocol Features
6.1.1.1. Protocol Messages 6.1.1.1. Protocol Messages
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
| Protocol Message | NTT Japan | University of | Zhejiang | | Protocol Message | NTT Japan | University of | Zhejiang |
| | | Patras | Gongshang | | | | Patras | Gongshang |
| | | | University | | | | | University |
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
| Association | Implemented | Implemented | Implemented | | Association | Implemented | Implemented | Implemented |
skipping to change at page 22, line 31 skipping to change at page 23, line 31
| Feature | | Patras | University | | Feature | | Patras | University |
+--------------+------------+-----------------+---------------------+ +--------------+------------+-----------------+---------------------+
| IPSec | Will | Will Implement | Will Implement | | IPSec | Will | Will Implement | Will Implement |
| | Implement | | | | | Implement | | |
+--------------+------------+-----------------+---------------------+ +--------------+------------+-----------------+---------------------+
Security Feature Support Security Feature Support
6.2. Interoperability Report 6.2. Interoperability Report
The interoperability test was performed at the University of Patras, The interoperability test took place at the University of Patras, in
in the Department of Electrical and Computer Engineering. the Department of Electrical and Computer Engineering.
There were two options to participate in the interoperability test. There were two options to participate in the interoperability test.
1. Locally at the University of Patras premises. 1. Locally at the University of Patras premises.
2. Remotely via internet. 2. Remotely via internet.
Implementations from NTT and University of Patras, were present Implementations from NTT and University of Patras, were present
locally at the premises, while the implementation from Zhejiang locally at the University of Patras premises in Greece, while the
Gongshang University were connected remotely. implementation from Zhejiang Gongshang University, which was behind a
NAT, connected remotely from China.
The interoperability test, tested the basic functionality of the The interoperability test, tested the basic functionality of the
ForCES protocol, mainly message passing and handling. ForCES protocol, mainly message exchanging and handling.
The following scenarios were tested. The following scenarios were tested.
6.2.1. Scenarios 6.2.1. Scenarios
Since the main goal of this interoperability test is to test the The main goal of the interoperability test was to test the basic
basic protocol functionality, the test parameters are limited. protocol functionality, the test parameters were limited.
1. In the Association Setup Message, all report messages will be 1. In the Association Setup Message, all report messages were
ignored. ignored.
2. In the Association Setup Phase, the messages, FEO OperEnable 2. In the Association Setup Phase, the messages, FEO OperEnable
Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config- Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config-
Resp (FE to CE) will be ignored. The CE will assume that the FE Resp (FE to CE) were ignored. The CEs assumed that the FEs were
is enabled once the LFBSelectors has been queried. enabled once the LFBSelectors had been queried.
3. Only FullDataTLVs are going to be used and not SparseData TLV's. 3. Only FullDataTLVs were used and not SparseData TLVs.
4. There will be no transaction operations. 4. There were no transaction operations.
5. Each message shall have only one LFBSelector TLV, one Operation 5. Each message had only one LFBSelector TLV, one Operation TLV and
TLV and one PathDataTLV per message when these are used. one PathDataTLV per message when these were used.
6.2.1.1. Scenario 1 - Pre-association Setup 6.2.1.1. Scenario 1 - Pre-association Setup
While the Pre-association setup is not in the ForCES current scope it While the Pre-association setup is not in the ForCES current scope it
is an essential step before CEs and FEs communicate. As the first is an essential step before CEs and FEs communicate. As the first
part in a successful CE-FE connection the participating CEs and FEs part in a successful CE-FE connection the participating CEs and FEs
should be able to be configured. had to be able to be configured.
In the Pre-association Phase the following configuration items MUST In the Pre-association Phase the following configuration items were
be setup regarding the CEs: setup regarding the CEs:
o The CE ID. o The CE ID.
o The FE IDs that will be connected to this CE o The FE IDs that were connected to this CE
o The IP of the FEs that will connect o The IP of the FEs that connected
o The TML priority ports. o The TML priority ports.
In the Pre-association Phase the following configuration items MUST In the Pre-association Phase the following configuration items were
be setup regarding the FEs: setup regarding the FEs:
o The FE ID. o The FE ID.
o The CE ID that this FE will be connecting to. o The CE ID that this FE were connecting to.
o The IP of the CE that will connect to
o The IP of the CE that connected to
o The TML priority ports. o The TML priority ports.
6.2.1.2. Scenario 2 - TML priority channels connection 6.2.1.2. Scenario 2 - TML priority channels connection
For the current interoperability test, the SCTP will be used as TML. For the interoperability test, the SCTP was used as TML. The TML
The TML connection with the associating element is needed for the connection with the associating element was needed for the scenario 2
scenario 2 to be successful. to be successful.
The SCTP-TML document [I-D.ietf-forces-sctptml] defines 3 priority Although the latest SCTP-TML document [I-D.ietf-forces-sctptml]
channels, with specific ports: defines 3 priority channels, with specific ports:
o High priority - Port number: 6704
o Medium priority - Port number: 6705
o Lower priority - Port number: 6706
At the time of the interoperability test, the sctp ports of the three
priority channels were the following:
o High priority - Port number: 6700 o High priority - Port number: 6700
o Medium priority - Port number: 6701 o Medium priority - Port number: 6701
o Lower priority - Port number: 6702 o Lower priority - Port number: 6702
As specified in the exceptions section, this does not invalidate the
results of the interoperability test.
6.2.1.3. Scenario 3 - Association Setup - Association Complete 6.2.1.3. Scenario 3 - Association Setup - Association Complete
Once the Pre-association phase has been complete in the previous 2 Once the Pre-association phase had been complete in the previous 2
scenarios, CEs and FEs are ready to communicate using the ForCES scenarios, CEs and FEs would be ready to communicate using the ForCES
protocol, and enter the Association Setup stage. In this stage the protocol, and enter the Association Setup stage. In this stage the
FEs attempts to join the NE. The following ForCES protocol messages FEs would attempt to join the NE. The following ForCES protocol
will be exchanged for each CE-FE pair in the specified order: messages would be exchanged for each CE-FE pair in the specified
order:
o Association Setup Message (from FE to CE) o Association Setup Message (from FE to CE)
o Association Setup Response Message (from CE to FE) o Association Setup Response Message (from CE to FE)
o Query Message: FEO LFBSelectors(from CE to FE) o Query Message: FEO LFBSelectors(from CE to FE)
o Query Response: FEO LFBSelectors response (from FE to CE) o Query Response: FEO LFBSelectors response (from FE to CE)
6.2.1.4. Scenario 4 - CE query 6.2.1.4. Scenario 4 - CE query
Once the Association Phase stage has been complete, the FEs and CEs Once the Association Phase stage has been complete, the FEs and CEs
will enter the Established stage. In this stage the FE is would enter the Established stage. In this stage the FE will be
continuously updated or queried. The CE should query the FE a continuously updated or queried. The CE should query the FE a
specific value from the FE Object LFB and from the FE Protocol LFB. specific value from the FE Object LFB and from the FE Protocol LFB.
An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and
from the FE Object LFB is the State of the LFB (FEState) from the FE Object LFB is the State of the LFB (FEState)
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages were exchanged:
o Query Message o Query Message
o Query Response Message o Query Response Message
6.2.1.5. Scenario 5 - Heartbeat monitoring 6.2.1.5. Scenario 5 - Heartbeat monitoring
The Heartbeat (HB) Message is used for one ForCES element (FE or CE) The Heartbeat (HB) Message is used for one ForCES element (FE or CE)
to asynchronously notify one or more other ForCES elements in the to asynchronously notify one or more other ForCES elements in the
same ForCES NE on its liveness. The default configuration of the same ForCES NE on its liveness. The default configuration of the
Heartbeat Policy of the FE is set to 0 which means, that the FE Heartbeat Policy of the FE is set to 0 which means, that the FE
should not generate any Heartbeat messages. the CE is responsible for should not generate any Heartbeat messages. the CE is responsible for
checking FE liveness by setting the PL header ACK flag of the message checking FE liveness by setting the PL header ACK flag of the message
it sends to AlwaysACK. In this Scenario the CE should send a it sends to AlwaysACK. In this Scenario the CE will send a Heartbeat
Heartbeat message with the ACK flag set to AlwaysACK and the FE message with the ACK flag set to AlwaysACK and the FE should respond.
should respond.
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages were exchanged:
o Heartbeat Message o Heartbeat Message
6.2.1.6. Scenario 6 - Simple Config Command 6.2.1.6. Scenario 6 - Simple Config Command
A config message is sent by the CE to the FE to configure LFB A config message is sent by the CE to the FE to configure LFB
components in the FE. A simple config command easily visible and components in the FE. A simple config command easily visible and
metered would be to change the Heartbeat configuration. This will be metered would be to change the Heartbeat configuration. This was
done in two steps: done in two steps:
1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force 1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force
the FE to send heartbeats. the FE to send heartbeats.
2. After some heartbeats from the FE, the FE Heartbeat Interval 2. After some heartbeats from the FE, the FE Heartbeat Interval
(FEHI) will be changed. (FEHI) was changed.
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages were exchanged:
o Config Message o Config Message
o Config Response Message o Config Response Message
6.2.1.7. Scenario 7 - Association Teardown 6.2.1.7. Scenario 7 - Association Teardown
In the end, the association must be terminated. There are two In the end, the association must be terminated. There were three
scenarios by which the association maybe terminated: scenarios by which the association was terminated:
1. Normal tear down by exchanging Association Teardown Message 1. Normal tear down by exchanging Association Teardown Message
2. Irregular tear down by stopping heartbeats from a FE or a CE. 2. Irregular tear down by stopping heartbeats from a FE or a CE.
3. Irregular tear down by externally shutting down/rebooting a FE or 3. Irregular tear down by externally shutting down/rebooting a FE or
a CE. a CE.
All scenarios may be tested in the interoperability test. All scenarios were tested in the interoperability test.
The following ForCES protocol messages will be exchanged: The following ForCES protocol messages were exchanged:
o Association Teardown Message o Association Teardown Message
6.2.2. Tested Features 6.2.2. Tested Features
The features that were tested are: The features that were tested are:
6.2.2.1. ForCES Protocol Features 6.2.2.1. ForCES Protocol Features
6.2.2.1.1. Protocol Messages 6.2.2.1.1. Protocol Messages
skipping to change at page 26, line 36 skipping to change at page 28, line 4
| Configuration | | Configuration |
| | | |
| Configuration Response | | Configuration Response |
| | | |
| Query | | Query |
| | | |
| Query Response | | Query Response |
| | | |
| HeartBeat | | HeartBeat |
+----------------------------+ +----------------------------+
ForCES Protocol Message ForCES Protocol Message
o PASS: All implementations handled the protocol messages and all
protocol analyzers captured them.
6.2.2.1.2. MainHeader Handling 6.2.2.1.2. MainHeader Handling
+------------------+ +------------------+
| Header Field | | Header Field |
+------------------+ +------------------+
| Correlator | | Correlator |
| | | |
| Acknowledge Flag | | Acknowledge Flag |
| | | |
| Priority Flag | | Priority Flag |
+------------------+ +------------------+
MainHeader Handling MainHeader Handling
o PASS: All implementations handled these main header flags and all
protocol analyzers captured them.
6.2.2.1.3. TLV Handling 6.2.2.1.3. TLV Handling
+---------------------------------+ +---------------------------------+
| TLV | | TLV |
+---------------------------------+ +---------------------------------+
| Association Setup Result TLV | | Association Setup Result TLV |
| | | |
| Association TearDown Reason TLV | | Association TearDown Reason TLV |
| | | |
| LFBSelector TLV | | LFBSelector TLV |
skipping to change at page 27, line 27 skipping to change at page 28, line 48
| | | |
| PathData TLV | | PathData TLV |
| | | |
| FullData TLV | | FullData TLV |
| | | |
| Result TLV | | Result TLV |
+---------------------------------+ +---------------------------------+
TLVs Supported TLVs Supported
o PASS: All implementations handled these TLVs and all protocol
analyzers captured them.
6.2.2.1.4. Operation Types Supported 6.2.2.1.4. Operation Types Supported
+--------------+ +--------------+
| Operation | | Operation |
+--------------+ +--------------+
| Set | | Set |
| | | |
| Set Response | | Set Response |
| | | |
| Get | | Get |
| | | |
| Get Response | | Get Response |
| | | |
| Report | | Report |
+--------------+ +--------------+
Operation Type Supported Operation Type Supported
o PASS: All implementations handled these Operations and all
protocol analyzers captured them.
6.2.2.1.5. ForCES Protocol Advanced Features 6.2.2.1.5. ForCES Protocol Advanced Features
+------------+ +------------+
| Feature | | Feature |
+------------+ +------------+
| Batching | | Batching |
| | | |
| HeartBeats | | HeartBeats |
+------------+ +------------+
ForCES Protocol Advanced Features ForCES Protocol Advanced Features
Although Batching was not initially designed to be tested, it was Although Batching was not initially designed to be tested, it was
tested during the interoperability test. tested during the interoperability test.
6.2.2.2. ForCES Model Features o PASS: Two implementations handled batching and all handled
Heartbeats. The protocol analyzers captured both.
6.2.2.2. ForCES Model Features
6.2.2.2.1. Basic Atomic Types Supported 6.2.2.2.1. Basic Atomic Types Supported
+-------------+ +-------------+
| Atomic Type | | Atomic Type |
+-------------+ +-------------+
| uchar | | uchar |
| | | |
| uint32 | | uint32 |
+-------------+ +-------------+
Basic Atomic Types Supported Basic Atomic Types Supported
o PASS: All implementations handled these basic atomic types.
6.2.2.2.2. Compound Types Supported 6.2.2.2.2. Compound Types Supported
+---------------+ +---------------+
| Compound Type | | Compound Type |
+---------------+ +---------------+
| structs | | structs |
| | | |
| arrays | | arrays |
+---------------+ +---------------+
Compound Types Supported Compound Types Supported
o PASS: All implementations handled these compound types.
6.2.2.2.3. LFBs Supported 6.2.2.2.3. LFBs Supported
6.2.2.2.3.1. FE Protocol LFB 6.2.2.2.3.1. FE Protocol LFB
+--------------------+ +--------------------+
| Protocol DataTypes | | Protocol DataTypes |
+--------------------+ +--------------------+
| CEHBPolicy | | CEHBPolicy |
| | | |
| FEHIBPolicy | | FEHIBPolicy |
+--------------------+ +--------------------+
skipping to change at page 29, line 16 skipping to change at page 30, line 46
+--------------------+ +--------------------+
| Protocol DataTypes | | Protocol DataTypes |
+--------------------+ +--------------------+
| CEHBPolicy | | CEHBPolicy |
| | | |
| FEHIBPolicy | | FEHIBPolicy |
+--------------------+ +--------------------+
FE Protocol LFB Datatypes FE Protocol LFB Datatypes
o PASS: All implementations handled these FE Protocol LFB Datatypes.
+---------------------+ +---------------------+
| Protocol Components | | Protocol Components |
+---------------------+ +---------------------+
| FEID | | FEID |
| | | |
| CEHBPolicy | | CEHBPolicy |
| | | |
| CEHDI | | CEHDI |
| | | |
| FEHBPolicy | | FEHBPolicy |
| | | |
| FEHI | | FEHI |
| | | |
| CEID | | CEID |
+---------------------+ +---------------------+
FE Protocol LFB Components FE Protocol LFB Components
o PASS: All implementations handled these FE Protocol LFB
Components.
6.2.2.2.3.2. FE Object LFB 6.2.2.2.3.2. FE Object LFB
+------------------+ +------------------+
| Object DataTypes | | Object DataTypes |
+------------------+ +------------------+
| FEStateValues | | FEStateValues |
| | | |
| LFBSelectorType | | LFBSelectorType |
+------------------+ +------------------+
FE Object LFB Datatypes FE Object LFB Datatypes
o PASS: All implementations handled these FE Object LFB Datatypes.
+-------------------+ +-------------------+
| Object Components | | Object Components |
+-------------------+ +-------------------+
| LFBSelectors | | LFBSelectors |
| | | |
| FEState | | FEState |
+-------------------+ +-------------------+
FE Object LFB Components FE Object LFB Components
o PASS: All implementations handled these FE Object LFB Components.
6.2.2.3. ForCES SCTP-TML Features 6.2.2.3. ForCES SCTP-TML Features
6.2.2.3.1. TML Priority Ports 6.2.2.3.1. TML Priority Ports
+------------------------+ +------------------------+
| Port | | Port |
+------------------------+ +------------------------+
| High priority (6700) | | High priority (6700) |
| | | |
| Medium priority (6701) | | Medium priority (6701) |
| | | |
| Low priority (6702) | | Low priority (6702) |
+------------------------+ +------------------------+
Priority Ports Priority Ports
o PASS: All implementations opened and connected to all the SCTP
priority ports. The protocol analyzers captured all ports and
corresponding priority.
6.2.2.3.2. Message Handling at specific priorities 6.2.2.3.2. Message Handling at specific priorities
+----------------------------+ +----------------------------+
| ForCES Message | | ForCES Message |
+----------------------------+ +----------------------------+
| Association Setup | | Association Setup |
| | | |
| Association Setup Response | | Association Setup Response |
| | | |
| Association Teardown | | Association Teardown |
skipping to change at page 31, line 4 skipping to change at page 32, line 46
| Config | | Config |
| | | |
| Config Response | | Config Response |
| | | |
| Query | | Query |
| | | |
| Query Response | | Query Response |
+----------------------------+ +----------------------------+
Message Handling at High priority (6700) Port Message Handling at High priority (6700) Port
o PASS: All implementations handled these messages at this SCTP
priority port. The protocol analyzers captured these messages at
these priority ports.
+----------------+ +----------------+
| ForCES Message | | ForCES Message |
+----------------+ +----------------+
| Heartbeats | | Heartbeats |
+----------------+ +----------------+
Message Handling at Low priority (6702) Port Message Handling at Low priority (6702) Port
o PASS: All implementations handled these messages at this SCTP
priority port. The protocol analyzers captured these messages at
these priority ports.
6.2.3. Interoperability Results 6.2.3. Interoperability Results
All implementations were found to be interoperable with each other. All implementations were found to be interoperable with each other.
All scenarios were tested successfully. All scenarios were tested successfully.
The following issues were found and dealt with. The following issues were found and dealt with.
1. Some messages were sent to the wrong priority channels. There 1. Some messages were sent to the wrong priority channels. There
was some ambiguities on the SCTP-TML document that have been was some ambiguities on the SCTP-TML document on what must be
corrected. the correct response from the CE and FE. Should it respond in
the same channel, should it respond in the correct channel, or
should it drop the packet? This has been corrected by changing
the word recommended to MUST in the SCTP-TML document regarding
priority channel messaging .
2. At some point, a CE sent a TearDown message to the FE. The CE 2. At some point, a CE sent a TearDown message to the FE. The CE
expected the FE to shut down the connection, and the FE waited expected the FE to shut down the connection, and the FE waited
the CE to shut down the connection and were caught in a the CE to shut down the connection and were caught in a
deadlock. This was a code bug and was fixed. deadlock. This was a code bug and was fixed.
3. Sometimes the association setup message, only on the remote 3. Sometimes the association setup message, only on the remote
connection test, although sent, was not received by the other connection test, although sent, was not received by the other
end and made impossible the association. This was caused by end and made impossible the association. This was caused by
network problems. network problems.
skipping to change at page 31, line 44 skipping to change at page 34, line 5
4. An implementation did not take into account that the padding in 4. An implementation did not take into account that the padding in
TLVs MUST NOT be included in the length of the TLV. This was a TLVs MUST NOT be included in the length of the TLV. This was a
code bug and was fixed. code bug and was fixed.
5. EM Flag was set to reserved by a CE and was not ignored by the 5. EM Flag was set to reserved by a CE and was not ignored by the
FE. This was a code bug and was fixed. FE. This was a code bug and was fixed.
6. After the FEHBPolicy was set to 1 the FE didn't send any 6. After the FEHBPolicy was set to 1 the FE didn't send any
HeartBeats. This was a code bug and was fixed. HeartBeats. This was a code bug and was fixed.
7. Some FE's sent HeartBeats with the ACK flag with a value other 7. Some FEs sent HeartBeats with the ACK flag with a value other
than NoACK. The CE responded. This was a code bug and was than NoACK. The CE responded. This was a code bug and was
fixed. fixed.
8. When a cable was disconnected, the TML didn't realize that. The 8. When a cable was disconnected, all TML implementation didn't
association was dropped due to heartbeats, this was a success, detect it. The association was eventually dropped due to
but this is an implementation issue implementers should keep in heartbeats, this was a success, but this is an implementation
mind. This is a SCTP options issue. Nothing was needed to be issue implementers should keep in mind. This is a SCTP options
done. issue. Nothing was needed to be done.
9. A CE crashed due to unknown LFBSelector values. This was a code 9. A CE crashed due to unknown LFBSelector values. This was a code
bug and was fixed. bug and was fixed.
10. With the remote connection there were a lot of ForCES packet 10. With the remote connection from China, which was behind a NAT,
retransmittion. The problem is that packets like Heartbeats to Greece there were a lot of ForCES packet retransmission. The
were retransmitted. This is a SCTP issue. SCTP-PR is needed to problem is that packets like Heartbeats were retransmitted.
be used. This was a SCTP issue. SCTP-PR was needed to be used.
The implementers went beyond the call of duty. The test was extended The interoperability test went so well that an additional extended
with another test for batching messages. This test was also done test was added to test for batching messages. This test was also
successfully. done successfully.
7. Acknowledgements 7. Acknowledgements
The authors like to give thanks to Professors Odysseas Koufopavlou The authors like to give thanks to Professors Odysseas Koufopavlou
and Spyros Denazis, and the Department of Electrical and Computer and Spyros Denazis, and the Department of Electrical and Computer
Engineering in the University of Patras who hosted the ForCES Engineering in the University of Patras who hosted the ForCES
interoperability test. interoperability test.
Also the authors would like to give thanks to Chuanhuang Li, Ming Also the authors would like to give thanks to Chuanhuang Li, Ming
Gao, and other participants from Zhejiang Gongshang University which Gao, and other participants from Zhejiang Gongshang University which
connected remotely. This allowed the discovery of a series of issues connected remotely. This allowed the discovery of a series of issues
that would have been uncaught otherwise. that would have been uncaught otherwise.
The authors would like to thank also Hideaki Iwata and Yoshinobu The authors would like to thank also Hideaki Iwata and Yoshinobu
Morimoto for participating locally at the interoperability test and Morimoto for participating locally at the interoperability test and
also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for
contributing to the interoperability test. contributing to the interoperability test.
Additionally thanks are given to Xinping Wang for her help in writing Additionally thanks are given to Xinping Wang for her help in writing
the interoperability draft an Fenggen Jia for exteding the Ethereal the interoperability draft an Fenggen Jia for extending the Ethereal
protocol analyzer. protocol analyzer.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
For Security considerations please see [I-D.ietf-forces-protocol] and For Security considerations please see [I-D.ietf-forces-protocol] and
[I-D.ietf-forces-sctptml] [I-D.ietf-forces-sctptml]
skipping to change at page 36, line 22 skipping to change at page 38, line 22
October 2008. October 2008.
[I-D.ietf-forces-protocol] [I-D.ietf-forces-protocol]
Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,
Khosravi, H., and W. Wang, "ForCES Protocol Khosravi, H., and W. Wang, "ForCES Protocol
Specification", draft-ietf-forces-protocol-22 (work in Specification", draft-ietf-forces-protocol-22 (work in
progress), March 2009. progress), March 2009.
[I-D.ietf-forces-sctptml] [I-D.ietf-forces-sctptml]
Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping
Layer) for ForCES protocol", draft-ietf-forces-sctptml-04 Layer) for ForCES protocol", draft-ietf-forces-sctptml-08
(work in progress), June 2009. (work in progress), January 2010.
10.2. Informative References 10.2. Informative References
[I-D.dusseault-impl-reports]
Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft
Standard", draft-dusseault-impl-reports-04 (work in
progress), July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
skipping to change at page 37, line 5 skipping to change at page 38, line 48
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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, September 2009.
[ethereal] [ethereal]
"Ethereal is a protocol analyzer. The specific ethereal "Ethereal is a protocol analyzer. The specific ethereal
that will be used is an updated Ethereal, by Fenggen Jia, that was used is an updated Ethereal, by Fenggen Jia, that
that can analyze and decode the ForCES protocol can analyze and decode the ForCES protocol messages.", <ht
messages.", <http://peach.ease.lsoft.com/scripts/ tp://peach.ease.lsoft.com/scripts/
wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=1048>. wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=1048>.
[tcpdump] "Tcpdump is a linux protocol analyzer. The specific [tcpdump] "Tcpdump is a linux protocol analyzer. The specific
tcpdump that will be used is a modified tcpdump, by Jamal tcpdump that was used is a modified tcpdump, by Jamal Hadi
Hadi Salim, that can analyze and decode the ForCES Salim, that can analyze and decode the ForCES protocol
protocol messages.", <http://peach.ease.lsoft.com/scripts/ messages.", <http://peach.ease.lsoft.com/scripts/
wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=2262>. wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=2262>.
Authors' Addresses Authors' Addresses
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Patras, Patras,
Greece Greece
Email: ehalep@ece.upatras.gr Email: ehalep@ece.upatras.gr
 End of changes. 77 change blocks. 
169 lines changed or deleted 231 lines changed or added

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