draft-ietf-forces-implementation-report-02.txt   rfc6053.txt 
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force (IETF) E. Haleplidis
Internet-Draft University of Patras Request for Comments: 6053 University of Patras
Intended status: Informational K. Ogawa Category: Informational K. Ogawa
Expires: December 29, 2010 NTT Corporation ISSN: 2070-1721 NTT Corporation
W. Wang W. Wang
Zhejiang Gongshang University Zhejiang Gongshang University
J. Hadi Salim J. Hadi Salim
Mojatatu Networks Mojatatu Networks
June 27, 2010 November 2010
Implementation Report for ForCES Implementation Report for
draft-ietf-forces-implementation-report-02 Forwarding and Control Element Separation (ForCES)
Abstract Abstract
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). RFC 3654 has defined
the ForCES requirements, and RFC3746 has defined the ForCES the ForCES requirements, and RFC 3746 has defined the ForCES
framework. framework.
This document is an implementation report of the ForCES Protocol, This document is an implementation report for the ForCES Protocol,
Model and SCTP-TML, including the report on interoperability testing Model, and the Stream Control Transmission Protocol-based Transport
and the current state of ForCES implementations. Mapping Layer (SCTP TML) documents, and includes a report on
interoperability testing and the current state of ForCES
Status of this Memo implementations.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on December 29, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6053.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4
2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 6 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Implementation Experience . . . . . . . . . . . . . . . . 10 6.1. Implementation Experience . . . . . . . . . . . . . . . . 7
6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 10 6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 9
6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 11 6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 9
6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 12 6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 10
6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 13 6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 11
6.1.1.4. Operation Types Supported . . . . . . . . . . . . 14 6.1.1.4. Operation Types Supported . . . . . . . . . . . . 12
6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 15 6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 13
6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 15 6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 14
6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 16 6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 14
6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 17 6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 15
6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 17 6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 15
6.1.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . 20 6.1.3. ForCES SCTP TML Features . . . . . . . . . . . . . . . 19
6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 20 6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 19
6.1.3.2. Message Handling at specific priorities . . . . . 21 6.1.3.2. Message Handling at Specific Priorities . . . . . 19
6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 22 6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 20
6.2. Interoperability Report . . . . . . . . . . . . . . . . . 22 6.2. Interoperability Report . . . . . . . . . . . . . . . . . 20
6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 23 6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1.1. Scenario 1 - Pre-association Setup . . . . . . . . 23 6.2.1.1. Scenario 1 - Pre-Association Setup . . . . . . . . 21
6.2.1.2. Scenario 2 - TML priority channels connection . . 24 6.2.1.2. Scenario 2 - TML Priority Channels Connection . . 22
6.2.1.3. Scenario 3 - Association Setup - Association 6.2.1.3. Scenario 3 - Association Setup - Association
Complete . . . . . . . . . . . . . . . . . . . . . 24 Complete . . . . . . . . . . . . . . . . . . . . . 22
6.2.1.4. Scenario 4 - CE query . . . . . . . . . . . . . . 25 6.2.1.4. Scenario 4 - CE Query . . . . . . . . . . . . . . 23
6.2.1.5. Scenario 5 - Heartbeat monitoring . . . . . . . . 25 6.2.1.5. Scenario 5 - Heartbeat Monitoring . . . . . . . . 23
6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 25 6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 23
6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 26 6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 24
6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 26 6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 25
6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 26 6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 25
6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 28 6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 28
6.2.2.3. ForCES SCTP-TML Features . . . . . . . . . . . . . 31 6.2.2.3. ForCES SCTP TML Features . . . . . . . . . . . . . 30
6.2.3. Interoperability Results . . . . . . . . . . . . . . . 32 6.2.3. Interoperability Results . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Terminology and Conventions 1. Introduction
1.1. Requirements Language This document is an implementation report for the ForCES protocol,
model, and the SCTP TML documents, and includes an interoperability
report.
It follows the outline suggested by [RFC5657].
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.
1.1. ForCES Protocol
The ForCES protocol works in a master-slave mode in which forwarding
elements (FEs) are slaves and control elements (CEs) are masters.
The protocol includes commands for transport of Logical Functional
Block (LFB) configuration information, association setup, status,
event notifications, etc. The reader is encouraged to read the
ForCES Protocol Specification [RFC5810] for further information.
1.2. ForCES Model
The ForCES Model [RFC5812] presents a formal way to define FE Logical
Functional Blocks (LFBs) using XML. LFB configuration components,
capabilities, and associated events are defined when the LFB is
formally created. The LFBs within the FE are accordingly controlled
in a standardized way by the ForCES protocol.
1.3. Transport Mapping Layer
The TML transports the protocol layer (PL) messages [RFC5810]. The
TML is where the issues of how to achieve transport-level
reliability, congestion control, multicast, ordering, etc. are
handled. All ForCES protocol layer implementations MUST be portable
across all TMLs. Although more than one TML may be standardized for
the ForCES protocol, all implementations MUST implement SCTP TML
[RFC5811].
2. Terminology and Conventions
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].
1.2. Definitions 2.2. Definitions
This document follows the terminology defined by the ForCES This document follows the terminology defined by the ForCES
Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. requirements in [RFC3654] and by the ForCES framework in [RFC3746].
The definitions below are repeated below for clarity. The 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
packet processing and handling as directed/controlled by one or per-packet processing and handling as directed/controlled by one
more CEs via the ForCES protocol. or more CEs via the ForCES protocol.
LFB (Logical Function Block) - The basic building block that is LFB (Logical Functional Block) - The basic building block that is
operated on by the ForCES protocol. The LFB is a well defined, operated on by the ForCES protocol. The LFB is a well defined,
logically separable functional block that resides in an FE and is logically separable functional block that resides in an FE and is
controlled by the CE via ForCES protocol. The LFB may reside at controlled by the CE via the ForCES protocol. The LFB may reside
the FE's datapath and process packets or may be purely an FE at the FE's datapath and process packets or may be purely an FE
control or configuration entity that is operated on by the CE. control or configuration entity that is operated on by the CE.
Note that the LFB is a functionally accurate abstraction of the Note that the LFB is a functionally accurate abstraction of the
FE's processing capabilities, but not a hardware-accurate FE's processing capabilities, but not a hardware-accurate
representation of the FE implementation. representation of the FE implementation.
LFB Class and LFB Instance - LFBs are categorized by LFB Classes. LFB Class and LFB Instance - LFBs are categorized by LFB Classes.
An LFB Instance represents an LFB Class (or Type) existence. An LFB Instance represents an LFB Class (or Type) existence.
There may be multiple instances of the same LFB Class (or Type) in There may be multiple instances of the same LFB Class (or Type) in
an FE. An LFB Class is represented by an LFB Class ID, and an LFB an FE. An LFB Class is represented by an LFB Class ID, and an LFB
Instance is represented by an LFB Instance ID. As a result, an Instance is represented by an LFB Instance ID. As a result, an
LFB Class ID associated with an LFB Instance ID uniquely specifies LFB Class ID associated with an LFB Instance ID uniquely specifies
an LFB existence. an LFB existence.
LFB Metadata - Metadata is used to communicate per-packet state LFB Metadata - Metadata is used to communicate per-packet state
from one LFB to another, but is not sent across the network. The from one LFB to another, but is not sent across the network. The
FE model defines how such metadata is identified, produced and FE model defines how such metadata is identified, produced, and
consumed by the LFBs. It defines the functionality but not how consumed by the LFBs. It defines the functionality but not how
metadata is encoded within an implementation. metadata is encoded within an implementation.
LFB Components - Operational parameters of the LFBs that must be LFB Components - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB visible to the CEs are conceptualized in the FE model as the LFB
components. The LFB components include, for example, flags, components. The LFB components include, for example, flags,
single parameter arguments, complex arguments, and tables that the single-parameter arguments, complex arguments, and tables that the
CE can read and/or Components write via the ForCES protocol (see CE can read and/or write via the ForCES protocol (see below).
below).
ForCES Protocol - While there may be multiple protocols used ForCES Protocol - While there may be multiple protocols used
within the overall ForCES architecture, the term "ForCES protocol" within the overall ForCES architecture, the term "ForCES protocol"
and "protocol" refer to the Fp reference points in the ForCES and "protocol" refer to the "Fp" reference points in the ForCES
Framework in [RFC3746]. This protocol does not apply to CE-to-CE framework in [RFC3746]. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between communication, FE-to-FE communication, or to communication between
FE and CE managers. Basically, the ForCES protocol works in a FE and CE managers. Basically, the ForCES protocol works in a
master- slave mode in which FEs are slaves and CEs are masters. master-slave mode in which FEs are slaves and CEs are masters.
This document defines the specifications for this ForCES protocol.
ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
ForCES protocol architecture that uses the capabilities of ForCES protocol architecture that uses the capabilities of
existing transport protocols to specifically address protocol existing transport protocols to specifically address protocol
message transportation issues, such as how the protocol messages message transportation issues, such as how the protocol messages
are mapped to different transport media (like TCP, IP, ATM, are mapped to different transport media (like TCP, IP, ATM,
Ethernet, etc), and how to achieve and implement reliability, Ethernet, etc.), and how to achieve and implement reliability,
multicast, ordering, etc. The ForCES TML specifications are multicast, ordering, etc. The ForCES TML specifications are
detailed in separate ForCES documents, one for each TML. detailed in separate ForCES documents, one for each TML.
2. Introduction
This is an implementation report for the ForCES protocol, model and
SCTP-TML documents and includes an interoperability report.
It follows the outline suggested by [RFC5657].
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.
2.1. ForCES Protocol
The ForCES protocol works in a master-slave mode in which FEs are
slaves and CEs are masters. The protocol includes commands for
transport of Logical Function Block (LFB) configuration information,
association setup, status, and event notifications, etc. The reader
is encouraged to read the ForCES Protocol [RFC5810] for further
information.
2.2. ForCES Model
The ForCES Model [RFC5812] presents a formal way to define FE Logical
Function Blocks (LFBs) using XML. LFB configuration components,
capabilities, and associated events are defined when the LFB is
formally created. The LFBs within the FE are accordingly controlled
in a standardized way by the ForCES protocol.
2.3. Transport mapping layer
The TML transports the PL messages. The TML is where the issues of
how to achieve transport level reliability, congestion control,
multicast, ordering, etc. are handled. All ForCES Protocol Layer
implementations MUST be portable across all TMLs. Although more than
one TML may be standardized for the ForCES Protocol, all
implementations MUST implement the SCTP-TML [RFC5811].
3. Summary 3. Summary
The authors attest that the ForCES Protocol, Model and SCTP-TML meet Three independent implementations, NTT Japan, the University of
the requirements for Draft Standard. Patras, and Zhejiang Gongshang University, were surveyed and found to
already implement all the major features. All implementors mentioned
Three independent implementations, NTT Japan, University of Patras they will be implementing all missing features in the future.
and Zhejiang Gongshang University, were surveyed and found to already
implement all the major features. All implementors mentioned they
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, Mojatatu Networks and implementations. Two other organizations, Mojatatu Networks and
Hangzhou Baud Information and Networks Technology Corporation, which Hangzhou Baud Information and Networks Technology Corporation, which
independently extended two different well known public domain independently extended two different well known public domain
protocol analyzers, Ethereal/Wireshark and tcpdump, also participated protocol analyzers, Ethereal/Wireshark and tcpdump, also participated
in the interop for a total of five independent organizations in the interop for a total of five independent organizations
implementing. The two protocol analyzers were used to verify implementing. The two protocol analyzers were used to verify the
validity of ForCEs protocol messages (and in some cases semantics). validity of ForCES protocol messages (and in some cases semantics).
There were no notable difficulties 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 as stated in Section 6.2.3. tests repeated successfully, as stated in Section 6.2.3.
4. Methodology 4. Methodology
This report has both an implementation experience survey as well as This report describes 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 regarding all ForCES Protocol, Model, and SCTP
features. The results can be seen in Section 6.1 TML features. The results can be seen in 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 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 were
been implemented and tested in an interop in July, 2009. The implemented and assessed in an interop test 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 three core documents were interoperable amongst
different implementations. The tested features can be seen in different implementations. The tested features can be seen in
Section 6.2.2. 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 the presence of different
LFBs the different organizations have currently implemented. All LFBs that the different organizations currently implement. All
organizations surveyed have indicated intention to implement all organizations surveyed have indicated their intention to implement
outstanding features in due time. The implemented features can be all outstanding features in due time. The implemented features can
seen in Section 6.1. be seen in Section 6.1.
The mandated TML security requirement, IPSec, was not validated The mandated TML security requirement, IP security (IPsec), was not
during the interop and is not discussed in this document. Since validated during the interop and is not discussed in this document.
IPSec is well known and widely deployed not testing in presence of Since IPsec is well known and widely deployed, not testing in the
IPSec does not invalidate the tests done. Note that Section 6.1.3.3 presence of IPsec does not invalidate the tests done. Note that
indicates that none of the implementations reporting included support Section 6.1.3.3 indicates that none of the implementations reporting
for IPSec, but all indicated their intention to implement. included support for IPsec, but all indicated their intention to
implement it.
Although the SCTP priority ports have been changed since the Although the SCTP priority ports have changed since the
interoperability test with the latest SCTP-TML draft, the change has interoperability test with the version of the SCTP TML draft
no impact in the validity of the interoperability test. available prior to the publication of RFC 5811, the change has no
impact on 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 University of Patras. o NTT Japan
o Zhejiang Gongshang University. o University of Patras
Also, not actual implementations, but extensions on protocol o Zhejiang Gongshang University
analyzers capable of understanding ForCES protocol messages, also are Extensions to protocol analyzers capable of understanding ForCES
considered part of an implementation as they can offer validation of protocol messages are considered part of an implementation, since
exchanged protocol messages. Two such extensions have been created: these analyzers can now understand and validate ForCES protocol
message that have been exchanged. 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 about the ForCES features they have
implemented. For every item listed the respondents indicated whether implemented. For every item listed, the respondents indicated
they had implemented, will implement, or won't implement at all. whether they had implemented, will implement, or won't implement at
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 |
| Setup | | | | | Setup | | | |
| | | | | | | | | |
skipping to change at page 11, line 18 skipping to change at page 9, line 21
| | | Patras | Gongshang | | | | Patras | Gongshang |
| | | | University | | | | | University |
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
| Association | Implemented | Implemented | Implemented | | Association | Implemented | Implemented | Implemented |
| Setup | | | | | Setup | | | |
| | | | | | | | | |
| Association | Implemented | Implemented | Implemented | | Association | Implemented | Implemented | Implemented |
| Setup Response | | | | | Setup Response | | | |
| | | | | | | | | |
| Association | Implemented | Implemented | Implemented | | Association | Implemented | Implemented | Implemented |
| TearDown | | | | | Teardown | | | |
| | | | | | | | | |
| Configuration | Implemented | Implemented | Implemented | | Config | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Configuration | Implemented | Implemented | Implemented | | Config Response | Implemented | Implemented | Implemented |
| Response | | | |
| | | | | | | | | |
| Query | Implemented | Implemented | Implemented | | Query | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Query Response | Implemented | Implemented | Implemented | | Query Response | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Event | Implemented | Will | Implemented | | Event | Implemented | Will | Implemented |
| Notification | | Implement | | | Notification | | Implement | |
| | | | | | | | | |
| Packet Redirect | Implemented | Will | Implemented | | Packet Redirect | Implemented | Will | Implemented |
| | | Implement | | | | | Implement | |
| | | | | | | | | |
| HeartBeat | Implemented | Implemented | Implemented | | Heartbeat | Implemented | Implemented | Implemented |
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
ForCES Protocol Message ForCES Protocol Messages
6.1.1.2. MainHeader Handling 6.1.1.2. MainHeader Handling
+---------------+-------------+----------------+--------------------+ +-----------------+-------------+----------------+------------------+
| Header Field | NTT Japan | University of | Zhejiang Gongshang | | Header Field | NTT Japan | University of | Zhejiang |
| | | Patras | University | | | | Patras | Gongshang |
+---------------+-------------+----------------+--------------------+ | | | | University |
| Correlator | Implemented | Implemented | Implemented | +-----------------+-------------+----------------+------------------+
| | | | | | Correlator | Implemented | Implemented | Implemented |
| Acknowledge | Implemented | Implemented | Implemented | | | | | |
| Flag | | | | | ACK Indicator | Implemented | Implemented | Implemented |
| | | | | | Flag | | | |
| Priority Flag | Will | Implemented | Implemented | | | | | |
| | Implement | | | | Priority Flag | Will | Implemented | Implemented |
| | | | | | | Implement | | |
| Execution | Will | Will Implement | Implemented | | | | | |
| Mode Flag | Implement | | | | Execution Mode | Will | Will Implement | Implemented |
| | | | | | Flag | Implement | | |
| Atomic Flag | Will | Will Implement | Implemented | | | | | |
| | Implement | | | | Atomic | Will | Will Implement | Implemented |
| | | | | | Transaction | Implement | | |
| Transaction | Will | Will Implement | Implemented | | Flag | | | |
| Flag | Implement | | | | | | | |
+---------------+-------------+----------------+--------------------+ | Transaction | Will | Will Implement | Implemented |
| Phase Flag | Implement | | |
+-----------------+-------------+----------------+------------------+
MainHeader Handling MainHeader Handling
6.1.1.3. TLV Handling 6.1.1.3. TLV Handling
+------------------+-------------+--------------+-------------------+ +------------------+-------------+---------------+------------------+
| TLV | NTT Japan | University | Zhejiang | | TLV | NTT Japan | University of | Zhejiang |
| | | of Patras | Gongshang | | | | Patras | Gongshang |
| | | | University | | | | | University |
+------------------+-------------+--------------+-------------------+ +------------------+-------------+---------------+------------------+
| Redirect TLV | Implemented | Will | Implemented | | REDIRECT-TLV | Implemented | Will | Implemented |
| | | Implement | | | | | Implement | |
| | | | | | | | | |
| Association | Implemented | Implemented | Implemented | | ASResult-TLV | Implemented | Implemented | Implemented |
| Setup Result TLV | | | | | | | | |
| | | | | | ASTReason-TLV | Implemented | Implemented | Implemented |
| Association | Implemented | Implemented | Implemented | | | | | |
| TearDown Reason | | | | | LFBSelect-TLV | Implemented | Implemented | Implemented |
| TLV | | | | | | | | |
| | | | | | OPER-TLV | Implemented | Implemented | Implemented |
| LFBSelector TLV | Implemented | Implemented | Implemented | | | | | |
| | | | | | PATH-DATA-TLV | Implemented | Implemented | Implemented |
| Operation TLV | Implemented | Implemented | Implemented | | | | | |
| | | | | | KEYINFO-TLV | Will | Will | Implemented |
| PathData TLV | Implemented | Implemented | Implemented | | | Implement | Implement | |
| | | | | | | | | |
| KeyInfo TLV | Will | Will | Implemented | | FULLDATA-TLV | Implemented | Implemented | Implemented |
| | Implement | Implement | | | | | | |
| | | | | | SPARSEDATA-TLV | Will | Will | Implemented |
| FullData TLV | Implemented | Implemented | Implemented | | | Implement | Implement | |
| | | | | | | | | |
| SparseData TLV | Will | Will | Implemented | | ILV | Will | Will | Implemented |
| | Implement | Implement | | | | Implement | Implement | |
| | | | | | | | | |
| ILV | Will | Will | Implemented | | METADATA-TLV | Will | Will | Implemented |
| | Implement | Implement | | | | Implement | Implement | |
| | | | | | | | | |
| Metadata TLV | Will | Will | Implemented | | RESULT-TLV | Implemented | Implemented | Implemented |
| | Implement | Implement | | | | | | |
| | | | | | REDIRECTDATA-TLV | Implemented | Will | Implemented |
| Result TLV | Implemented | Implemented | Implemented | | | | Implement | |
| | | | | +------------------+-------------+---------------+------------------+
| Redirect Data | Implemented | Will | Implemented |
| TLV | | Implement | |
+------------------+-------------+--------------+-------------------+
TLVs Supported TLVs Supported
6.1.1.4. Operation Types Supported 6.1.1.4. Operation Types Supported
+--------------+-------------+-----------------+--------------------+ +-------------------+-------------+---------------+-----------------+
| Operation | NTT Japan | University of | Zhejiang Gongshang | | Operation | NTT Japan | University of | Zhejiang |
| | | Patras | University | | | | Patras | Gongshang |
+--------------+-------------+-----------------+--------------------+ | | | | University |
| Set | Implemented | Implemented | Implemented | +-------------------+-------------+---------------+-----------------+
| | | | | | SET | Implemented | Implemented | Implemented |
| Set Prop | Will | Will Implement | Implemented | | | | | |
| | Implement | | | | SET-PROP | Will | Will | Implemented |
| | | | | | | Implement | Implement | |
| Set Response | Implemented | Implemented | Implemented | | | | | |
| | | | | | SET-RESPONSE | Implemented | Implemented | Implemented |
| Set Prop | Will | Will Implement | Implemented | | | | | |
| Response | Implement | | | | SET-PROP-RESPONSE | Will | Will | Implemented |
| | | | | | | Implement | Implement | |
| Del | Implemented | Will Implement | Implemented | | | | | |
| | | | | | DEL | Implemented | Will | Implemented |
| Del Response | Implemented | Will Implement | Implemented | | | | Implement | |
| | | | | | | | | |
| Get | Implemented | Implemented | Implemented | | DEL-RESPONSE | Implemented | Will | Implemented |
| | | | | | | | Implement | |
| Get Prop | Will | Will Implement | Implemented | | | | | |
| | Implement | | | | GET | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Get Response | Implemented | Implemented | Implemented | | GET-PROP | Will | Will | Implemented |
| | | | | | | Implement | Implement | |
| Get Prop | Will | Will Implement | Implemented | | | | | |
| Response | Implement | | | | GET-RESPONSE | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Report | Implemented | Implemented | Implemented | | GET-PROP-RESPONSE | Will | Will | Implemented |
| | | | | | | Implement | Implement | |
| Commit | Will | Will Implement | Implemented | | | | | |
| | Implement | | | | REPORT | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Commit | Will | Will Implement | Implemented | | COMMIT | Will | Will | Implemented |
| Response | Implement | | | | | Implement | Implement | |
| | | | | | | | | |
| TRComp | Will | Will Implement | Implemented | | COMMIT-RESPONSE | Will | Will | Implemented |
| | Implement | | | | | Implement | Implement | |
+--------------+-------------+-----------------+--------------------+ | | | | |
| TRCOMP | Will | Will | Implemented |
| | Implement | Implement | |
+-------------------+-------------+---------------+-----------------+
Operation Type Supported Operation Types Supported
6.1.1.5. ForCES Protocol Advanced Features 6.1.1.5. ForCES Protocol Advanced Features
+---------------+-------------+----------------+--------------------+ +---------------+-------------+----------------+--------------------+
| Feature | NTT Japan | University of | Zhejiang Gongshang | | Feature | NTT Japan | University of | Zhejiang Gongshang |
| | | Patras | University | | | | Patras | University |
+---------------+-------------+----------------+--------------------+ +---------------+-------------+----------------+--------------------+
| Execute Mode | Will | Will Implement | Implemented | | Execute Mode | Will | Will Implement | Implemented |
| | Implement | | | | | Implement | | |
| | | | | | | | | |
| Transaction | Will | Will Implement | Implemented | | Transaction | Will | Will Implement | Implemented |
| | Implement | | | | | Implement | | |
| | | | | | | | | |
| Batching | Will | Implemented | Implemented | | Batching | Will | Implemented | Implemented |
| | Implement | | | | | Implement | | |
| | | | | | | | | |
| Command | Will | Will Implement | Will Implement | | Command | Will | Will Implement | Will Implement |
| Pipelining | Implement | | | | Pipelining | Implement | | |
| | | | | | | | | |
| HeartBeats | Implemented | Implemented | Implemented | | Heartbeats | Implemented | Implemented | Implemented |
+---------------+-------------+----------------+--------------------+ +---------------+-------------+----------------+--------------------+
ForCES Protocol Advanced Features ForCES Protocol Advanced Features
6.1.2. ForCES Model Features 6.1.2. ForCES Model Features
6.1.2.1. Basic Atomic Types Supported 6.1.2.1. Basic Atomic Types Supported
+----------------+-------------+---------------+--------------------+ +----------------+-------------+---------------+--------------------+
| Atomic Type | NTT Japan | University of | Zhejiang Gongshang | | Atomic Type | NTT Japan | University of | Zhejiang Gongshang |
| | | Patras | University | | | | Patras | University |
+----------------+-------------+---------------+--------------------+ +----------------+-------------+---------------+--------------------+
| char | Implemented | Implemented | Will Implement | | char | Implemented | Implemented | Will Implement |
| | | | | | | | | |
| uchar | Implemented | Implemented | Implemented | | uchar | Implemented | Implemented | Implemented |
| | | | | | | | | |
skipping to change at page 16, line 22 skipping to change at page 14, line 25
| uchar | Implemented | Implemented | Implemented | | uchar | Implemented | Implemented | Implemented |
| | | | | | | | | |
| int16 | Implemented | Implemented | Will Implement | | int16 | Implemented | Implemented | Will Implement |
| | | | | | | | | |
| uint16 | Implemented | Implemented | Will Implement | | uint16 | Implemented | Implemented | Will Implement |
| | | | | | | | | |
| int32 | Implemented | Implemented | Implemented | | int32 | Implemented | Implemented | Implemented |
| | | | | | | | | |
| uint32 | Implemented | Implemented | Implemented | | uint32 | Implemented | Implemented | Implemented |
| | | | | | | | | |
| int16 | Implemented | Implemented | Will Implement | | int64 | Implemented | Implemented | Will Implement |
| | | | | | | | | |
| uint64 | Implemented | Implemented | Will Implement | | uint64 | Implemented | Implemented | Will Implement |
| | | | | | | | | |
| boolean | Implemented | Implemented | Implemented | | boolean | Implemented | Implemented | Implemented |
| | | | | | | | | |
| string[N] | Implemented | Implemented | Implemented | | string[N] | Implemented | Implemented | Implemented |
| | | | | | | | | |
| string | Implemented | Implemented | Implemented | | string | Implemented | Implemented | Implemented |
| | | | | | | | | |
| byte[N] | Implemented | Implemented | Implemented | | byte[N] | Implemented | Implemented | Implemented |
skipping to change at page 17, line 24 skipping to change at page 15, line 24
+------------+-------------+-----------------+----------------------+ +------------+-------------+-----------------+----------------------+
Compound Types Supported Compound Types Supported
6.1.2.3. LFBs Supported 6.1.2.3. LFBs Supported
6.1.2.3.1. FE Protocol LFB 6.1.2.3.1. FE Protocol LFB
+------------------+-------------+----------------+-----------------+ +------------------+-------------+----------------+-----------------+
| Protocol | NTT Japan | University of | Zhejiang | | Protocol | NTT Japan | University of | Zhejiang |
| DataTypes | | Patras | Gongshang | | Datatypes | | Patras | Gongshang |
| | | | University | | | | | University |
+------------------+-------------+----------------+-----------------+ +------------------+-------------+----------------+-----------------+
| CEHBPolicy | Implemented | Implemented | Implemented | | CEHBPolicy | Implemented | Implemented | Implemented |
| | | | | | | | | |
| FEHIBPolicy | Implemented | Implemented | Implemented | | FEHBPolicy | Implemented | Implemented | Implemented |
| | | | | | | | | |
| FERestarPolicy | Implemented | Implemented | Implemented | | FERestartPolicy | Implemented | Implemented | Implemented |
| | | | | | | | | |
| CEFailoverPolicy | Implemented | Implemented | Implemented | | CEFailoverPolicy | Implemented | Implemented | Implemented |
| | | | | | | | | |
| FEHACapab | Implemented | Implemented | Will Implement | | FEHACapab | Implemented | Implemented | Will Implement |
+------------------+-------------+----------------+-----------------+ +------------------+-------------+----------------+-----------------+
FE Protocol LFB Datatypes FE Protocol LFB Datatypes
+-----------------------+-------------+-------------+---------------+ +-----------------------+-------------+-------------+---------------+
| Protocol Components | NTT Japan | University | Zhejiang | | Protocol Components | NTT Japan | University | Zhejiang |
skipping to change at page 19, line 17 skipping to change at page 17, line 17
| | | Patras | University | | | | Patras | University |
+---------------+------------+----------------+---------------------+ +---------------+------------+----------------+---------------------+
| PrimaryCEDown | Will | Will Implement | Will Implement | | PrimaryCEDown | Will | Will Implement | Will Implement |
| | Implement | | | | | Implement | | |
+---------------+------------+----------------+---------------------+ +---------------+------------+----------------+---------------------+
Events Supported Events Supported
6.1.2.3.2. FE Object LFB 6.1.2.3.2. FE Object LFB
+-------------------------+-------------+-------------+-------------+ +--------------------------+-------------+-------------+-------------+
| Object DataTypes | NTT Japan | University | Zhejiang | | Object Datatypes | NTT Japan | University | Zhejiang |
| | | of Patras | Gongshang | | | | of Patras | Gongshang |
| | | | University | | | | | University |
+-------------------------+-------------+-------------+-------------+ +--------------------------+-------------+-------------+-------------+
| LFBAdjacencyLimit | Implemented | Implemented | Implemented | | LFBAdjacencyLimitType | Implemented | Implemented | Implemented |
| | | | | | | | | |
| PortGroupLimitType | Implemented | Implemented | Implemented | | PortGroupLimitType | Implemented | Implemented | Implemented |
| | | | | | | | | |
| SupportedLFBType | Implemented | Implemented | Implemented | | SupportedLFBType | Implemented | Implemented | Implemented |
| | | | | | | | | |
| FEStateValues | Implemented | Implemented | Implemented | | FEStateValues | Implemented | Implemented | Implemented |
| | | | | | | | | |
| FEConfiguredeighborType | Implemented | Implemented | Implemented | | FEConfiguredNeighborType | Implemented | Implemented | Implemented |
| | | | | | | | | |
| FEConfiguredeighborType | Implemented | Implemented | Implemented | | LFBSelectorType | Implemented | Implemented | Implemented |
| | | | | | | | | |
| LFBSelectorType | Implemented | Implemented | Implemented | | LFBLinkType | Implemented | Implemented | Implemented |
| | | | | +--------------------------+-------------+-------------+-------------+
| LFBLinkType | Implemented | Implemented | Implemented |
+-------------------------+-------------+-------------+-------------+
FE Object LFB Datatypes FE Object LFB Datatypes
+--------------+-------------+----------------+---------------------+ +--------------+-------------+----------------+---------------------+
| Object | NTT Japan | University of | Zhejiang Gongshang | | Object | NTT Japan | University of | Zhejiang Gongshang |
| Components | | Patras | University | | Components | | Patras | University |
+--------------+-------------+----------------+---------------------+ +--------------+-------------+----------------+---------------------+
| LFBTopology | Implemented | Implemented | Implemented | | LFBTopology | Implemented | Implemented | Implemented |
| | | | | | | | | |
| LFBSelectors | Implemented | Implemented | Implemented | | LFBSelectors | Implemented | Implemented | Implemented |
skipping to change at page 20, line 40 skipping to change at page 19, line 5
| | | of Patras | Gongshang | | | | of Patras | Gongshang |
| | | | University | | | | | University |
+-----------------------+-------------+-------------+---------------+ +-----------------------+-------------+-------------+---------------+
| ModifiableLFBTopology | Implemented | Implemented | Implemented | | ModifiableLFBTopology | Implemented | Implemented | Implemented |
| | | | | | | | | |
| SupportedLFBs | Implemented | Implemented | Implemented | | SupportedLFBs | Implemented | Implemented | Implemented |
+-----------------------+-------------+-------------+---------------+ +-----------------------+-------------+-------------+---------------+
Capabilities Supported Capabilities Supported
6.1.3. ForCES SCTP-TML Features 6.1.3. ForCES SCTP TML Features
6.1.3.1. TML Priority Ports 6.1.3.1. TML Priority Ports
+----------------+-------------+---------------+--------------------+ +----------------+-------------+---------------+--------------------+
| Port | NTT Japan | University of | Zhejiang Gongshang | | Port | NTT Japan | University of | Zhejiang Gongshang |
| | | Patras | University | | | | Patras | University |
+----------------+-------------+---------------+--------------------+ +----------------+-------------+---------------+--------------------+
| High priority | Implemented | Implemented | Implemented | | High priority | Implemented | Implemented | Implemented |
| (6700) | | | | | (6700) | | | |
| | | | | | | | | |
| Medium | Implemented | Implemented | Implemented | | Medium | Implemented | Implemented | Implemented |
| priority | | | | | priority | | | |
| (6701) | | | | | (6701) | | | |
| | | | | | | | | |
| Low priority | Implemented | Implemented | Implemented | | Low priority | Implemented | Implemented | Implemented |
| (6702) | | | | | (6702) | | | |
+----------------+-------------+---------------+--------------------+ +----------------+-------------+---------------+--------------------+
Priority Ports Priority Ports
6.1.3.2. Message Handling at specific priorities 6.1.3.2. Message Handling at Specific Priorities
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
| ForCES Message | NTT Japan | University of | Zhejiang | | ForCES Message | NTT Japan | University of | Zhejiang |
| | | Patras | Gongshang | | | | Patras | Gongshang |
| | | | University | | | | | University |
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
| Association | Implemented | Implemented | Implemented | | Association | Implemented | Implemented | Implemented |
| Setup | | | | | Setup | | | |
| | | | | | | | | |
| Association | Implemented | Implemented | Implemented | | Association | Implemented | Implemented | Implemented |
skipping to change at page 21, line 39 skipping to change at page 19, line 51
| | | | | | | | | |
| Config | Implemented | Implemented | Implemented | | Config | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Config Response | Implemented | Implemented | Implemented | | Config Response | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Query | Implemented | Implemented | Implemented | | Query | Implemented | Implemented | Implemented |
| | | | | | | | | |
| Query Response | Implemented | Implemented | Implemented | | Query Response | Implemented | Implemented | Implemented |
+------------------+-------------+---------------+------------------+ +------------------+-------------+---------------+------------------+
Message Handling at High priority (6700) Port Message Handling at High-Priority (6700) Port
+---------------+-------------+----------------+--------------------+ +---------------+-------------+----------------+--------------------+
| ForCES | NTT Japan | University of | Zhejiang Gongshang | | ForCES | NTT Japan | University of | Zhejiang Gongshang |
| Message | | Patras | University | | Message | | Patras | University |
+---------------+-------------+----------------+--------------------+ +---------------+-------------+----------------+--------------------+
| Event | Implemented | Implemented | Implemented | | Event | Implemented | Implemented | Implemented |
| Notification | | | | | Notification | | | |
+---------------+-------------+----------------+--------------------+ +---------------+-------------+----------------+--------------------+
Message Handling at Medium priority (6701) Port Message Handling at Medium-Priority (6701) Port
+-------------+-------------+-----------------+---------------------+ +-------------+-------------+-----------------+---------------------+
| ForCES | NTT Japan | University of | Zhejiang Gongshang | | ForCES | NTT Japan | University of | Zhejiang Gongshang |
| Message | | Patras | University | | Message | | Patras | University |
+-------------+-------------+-----------------+---------------------+ +-------------+-------------+-----------------+---------------------+
| Packet | Implemented | Implemented | Implemented | | Packet | Implemented | Implemented | Implemented |
| Redirect | | | | | Redirect | | | |
| | | | | | | | | |
| Heartbeats | Implemented | Implemented | Implemented | | Heartbeat | Implemented | Implemented | Implemented |
+-------------+-------------+-----------------+---------------------+ +-------------+-------------+-----------------+---------------------+
Message Handling at Low priority (6702) Port Message Handling at Low-Priority (6702) Port
6.1.3.3. TML Security Feature 6.1.3.3. TML Security Feature
+--------------+------------+-----------------+---------------------+ +--------------+------------+-----------------+---------------------+
| Security | NTT Japan | University of | Zhejiang Gongshang | | Security | NTT Japan | University of | Zhejiang Gongshang |
| 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 took place at the University of Patras, in The interoperability test took place at the University of Patras, 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 for participation in the interoperability
test.
1. Locally at the University of Patras premises. 1. Locally, on 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 the University of Patras were present
locally at the University of Patras premises in Greece, while the locally on the University of Patras premises in Greece, while the
implementation from Zhejiang Gongshang University, which was behind a implementation from Zhejiang Gongshang University, which was behind a
NAT, connected remotely from China. NAT, connected remotely from China.
The interoperability test, tested the basic functionality of the The interoperability test validated the basic functionality of the
ForCES protocol, mainly message exchanging 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
The main goal of the interoperability test was to test the basic The main goal of the interoperability test was to validate the basic
protocol functionality, the test parameters were limited. protocol functionality; the test parameters were limited.
1. In the Association Setup Message, all report messages were 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 stage, the FEO OperEnable Event (FE to
Event (FE to CE), Config FEO Adminup (CE to FE) and FEO Config- CE), Config FEO Adminup (CE to FE), and FEO Config-Resp (FE to
Resp (FE to CE) were ignored. The CEs assumed that the FEs were CE) messages were ignored. The CEs assumed that the FEs were
enabled once the LFBSelectors had been queried. enabled once the LFB selectors had been queried.
3. Only FullDataTLVs were used and not SparseData TLVs. 3. Only FULLDATA-TLVs were used and not SPARSEDATA-TLVs.
4. There were no transaction operations. 4. There were no transaction operations.
5. Each message had only one LFBSelector TLV, one Operation TLV and 5. Each message had only one LFBSelect-TLV, one OPER-TLV, and one
one PathDataTLV per message when these were used. PATH-DATA-TLV 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,
is an essential step before CEs and FEs communicate. As the first it 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
had to be able to be configured. had to be configurable.
In the Pre-association Phase the following configuration items were In the pre-association phase, the following configuration items were
setup regarding the CEs: set up regarding the CEs:
o The CE ID. o The CE ID.
o The FE IDs that were connected to this CE o The FE IDs that were connected to this CE.
o The IP of the FEs that connected o The IP addresses of the FEs that connected to the CE.
o The TML priority ports. o The TML priority ports.
In the Pre-association Phase the following configuration items were In the pre-association phase, the following configuration items were
setup regarding the FEs: set up regarding the FEs:
o The FE ID. o The FE ID.
o The CE ID that this FE were connecting to. o The CE ID to which this FE was connecting.
o The IP address of the CE to which this FE was connecting.
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 interoperability test, the SCTP was used as TML. The TML For the interoperability test, the SCTP was used as TML. The TML
connection with the associating element was needed for the scenario 2 connection with the associating element was needed for Scenario 2 to
to be successful. be successful.
Although SCTP-TML [RFC5811] defines 3 priority channels, with SCTP TML [RFC5811] defines three priority channels, with specific
specific ports: ports:
o High priority - Port number: 6704 o High priority - Port number: 6704
o Medium priority - Port number: 6705 o Medium priority - Port number: 6705
o Lower priority - Port number: 6706 o Lower priority - Port number: 6706
At the time of the interoperability test, the sctp ports of the three However, at the time of the interoperability test, the SCTP ports of
priority channels were the following: 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 As specified in Section 5, "Exceptions", this does not invalidate the
results of the interoperability test. 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 had been complete in the previous 2 Once the pre-association phase in the previous two scenarios had
scenarios, CEs and FEs would be ready to communicate using the ForCES completed, 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 would attempt to join the NE. The following ForCES protocol FEs would attempt to join the NE. The following ForCES protocol
messages would be exchanged for each CE-FE pair in the specified messages would be exchanged for each CE-FE pair in the specified
order: 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 LFB selectors (from CE to FE)
o Query Response: FEO LFBSelectors response (from FE to CE) o Query Response: FEO LFB selectors 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 Setup stage had completed, the FEs and CEs would
would enter the Established stage. In this stage the FE will be 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 for 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 FE Heartbeat Interval
from the FE Object LFB is the State of the LFB (FEState) (FEHI), and an example from the FE Object LFB is the state of the LFB
(FEState).
The following ForCES protocol messages were 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 of 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
checking FE liveness by setting the PL header ACK flag of the message for checking FE liveness by setting the PL header ACK flag of the
it sends to AlwaysACK. In this Scenario the CE will send a Heartbeat message it sends to AlwaysACK. In this scenario, the CE will send a
message with the ACK flag set to AlwaysACK and the FE should respond. Heartbeat message with the ACK flag set to AlwaysACK, and the FE
should respond.
The following ForCES protocol messages were exchanged: The following type of ForCES protocol message was 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 was 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) was changed. (FEHI) was changed.
The following ForCES protocol messages were 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 were three In the end, the association must be terminated. There were three
scenarios by which the association was terminated: scenarios by which the association was terminated:
1. Normal tear down by exchanging Association Teardown Message 1. Normal teardown, by exchanging an Association Teardown message.
2. Irregular tear down by stopping heartbeats from a FE or a CE. 2. Irregular teardown, by stopping heartbeats from an FE or a CE.
3. Irregular tear down by externally shutting down/rebooting a FE or 3. Irregular teardown, by externally shutting down/rebooting an FE
a CE. or a CE.
All scenarios were tested in the interoperability test. All scenarios were investigated in the interoperability test.
The following ForCES protocol messages were exchanged: The following type of ForCES protocol message was 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
+----------------------------+ +----------------------------+
| Protocol Message | | Protocol Message |
+----------------------------+ +----------------------------+
| Association Setup | | Association Setup |
| | | |
| Association Setup Response | | Association Setup Response |
| | | |
| Association TearDown | | Association Teardown |
| | | |
| Configuration | | Config |
| | | |
| Configuration Response | | Config Response |
| | | |
| Query | | Query |
| | | |
| Query Response | | Query Response |
| | | |
| HeartBeat | | Heartbeat |
+----------------------------+ +----------------------------+
ForCES Protocol Message
o PASS: All implementations handled the protocol messages and all ForCES Protocol Messages
o PASS: All implementations handled the protocol messages, and all
protocol analyzers captured them. 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 | | ACK Indicator Flag |
| | | |
| Priority Flag | | Priority Flag |
+------------------+ +--------------------+
MainHeader Handling MainHeader Handling
o PASS: All implementations handled these main header flags and all o PASS: All implementations handled these main header flags, and all
protocol analyzers captured them. protocol analyzers captured them.
6.2.2.1.3. TLV Handling 6.2.2.1.3. TLV Handling
+---------------------------------+ +---------------+
| TLV | | TLV |
+---------------------------------+ +---------------+
| Association Setup Result TLV | | ASResult-TLV |
| | | |
| Association TearDown Reason TLV | | ASTReason-TLV |
| | | |
| LFBSelector TLV | | LFBSelect-TLV |
| | | |
| Operation TLV | | OPER-TLV |
| | | |
| PathData TLV | | PATH-DATA-TLV |
| | | |
| FullData TLV | | FULLDATA-TLV |
| | | |
| Result TLV | | RESULT-TLV |
+---------------------------------+ +---------------+
TLVs Supported TLVs Supported
o PASS: All implementations handled these TLVs and all protocol o PASS: All implementations handled these TLVs, and all protocol
analyzers captured them. 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 Types Supported
o PASS: All implementations handled these Operations and all o PASS: All implementations handled these operations, and all
protocol analyzers captured them. 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 intended to be tested, it was
tested during the interoperability test. assessed during the interoperability test.
o PASS: Two implementations handled batching and all handled o PASS: Two implementations handled batching, and all handled
Heartbeats. The protocol analyzers captured both. heartbeats. The protocol analyzers captured both.
6.2.2.2. ForCES Model Features 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 |
+-------------+ +-------------+
skipping to change at page 29, line 37 skipping to change at page 28, line 40
Compound Types Supported Compound Types Supported
o PASS: All implementations handled these compound types. 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 | | FEHBPolicy |
+--------------------+ +--------------------+
FE Protocol LFB Datatypes FE Protocol LFB Datatypes
o PASS: All implementations handled these 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 o PASS: All implementations handled these FE Protocol LFB
Components. 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. 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. 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 o PASS: All implementations opened and connected to all the SCTP
priority ports. The protocol analyzers captured all ports and priority ports. The protocol analyzers captured all ports and
corresponding priority. their 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 |
| | | |
| 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 o PASS: All implementations handled these messages at this SCTP
priority port. The protocol analyzers captured these messages at priority port. The protocol analyzers captured these messages at
these priority ports. this priority port.
+----------------+ +----------------+
| 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 o PASS: All implementations handled these messages at this SCTP
priority port. The protocol analyzers captured these messages at priority port. The protocol analyzers captured these messages at
these priority ports. this priority port.
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 on the wrong priority channels. There 1. Some messages were sent on the wrong priority channels. There
were some ambiguities on the SCTP-TML document on how to deal were some ambiguities in the SCTP TML document regarding how to
with such a situation. The possibilities were: an FE response deal with such a situation. The possibilities were an FE
on the same (wrong) channel as a CE query; on the correctly response on the same (wrong) channel as a CE query; an FE
documented channel for the message; or to simply drop the response on the correctly documented channel for the message; or
packet. This has been corrected by mandating the message to simply dropping the packet. This has been corrected by
channel mapping to be a MUST in the SCTP-TML document [RFC5811] mandating the message-to-channel mapping to be a MUST in the
before it was published as an RFC. SCTP TML document [RFC5811] before it was published as an RFC.
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 for the CE to shut down the connection; both were then caught in
deadlock. This was a code bug and was fixed. a deadlock. This was a code bug and was fixed.
3. Sometimes, only when the CE and FE were remote to each other 3. Sometimes, only when the CE and FE were remote to each other
(one being in China and another in Greece), the association (one being in China and another in Greece), the Association
setup message was not received by the CE side and therefore an Setup message was not received by the CE side, and therefore an
association never completed. This was not an implementation association never completed. This was not an implementation
issue, rather it was a network issue. This issue is solved with issue but rather a network issue. This issue was solved with
the retransmission of the non delivered messages. the retransmission of the non-delivered messages.
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. The Execution Mode flag was set to Reserved by a CE and was not
FE. This was a code bug and was fixed. ignored by the 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 FEs sent HeartBeats with the ACK flag with a value other 7. Some FEs sent heartbeats with the ACK flag set to 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, all TML implementation didn't 8. When a cable was disconnected, none of the TML implementations
detect it. The association was eventually dropped due to detected it. The association was eventually dropped due to
heartbeats, this was a success, but this is an implementation heartbeat detection; this test was a success, but this is an
issue implementers should keep in mind. This is a SCTP options implementation issue that implementors should keep in mind.
issue. Nothing was needed to be done. This is an SCTP options issue. Nothing needed to be done.
9. A CE crashed due to unknown LFBSelector values. This was a code 9. A CE crashed due to unknown LFB selector values. This was a
bug and was fixed. code bug and was fixed.
10. With the remote connection from China, which was behind a NAT, 10. With the remote connection from China (which was behind a NAT)
to Greece there were a lot of ForCES packet retransmission. The to Greece, there were a lot of ForCES packet retransmissions.
problem is that packets like Heartbeats were retransmitted. The problem was that packets like heartbeats were retransmitted.
This was an implementation issue regarding SCTP usage This was an implementation issue regarding SCTP usage that
implementers should keep in mind. SCTP-PR option was needed to implementors should keep in mind. The SCTP-PR option needed to
be used. Nothing was needed to be done. be used. Nothing needed to be done.
The interoperability test went so well that an additional extended The interoperability test went so well that an additional extended
test was added to test for batching messages. This test was also test was added to check for batching messages. This test was also
done successfully. done successfully.
7. Acknowledgements 7. Acknowledgements
The authors like to give thanks to Professors Odysseas Koufopavlou The authors would like to give thanks to Professors Odysseas
and Spyros Denazis, and the Department of Electrical and Computer Koufopavlou and Spyros Denazis, and the Department of Electrical and
Engineering in the University of Patras who hosted the ForCES Computer Engineering at the University of Patras, who hosted the
interoperability test. ForCES interoperability test.
Also the authors would like to give thanks to Chuanhuang Li, Ming The authors would also 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 also like to thank Hideaki Iwata and Yoshinobu
Morimoto for participating locally at the interoperability test and Morimoto of NTT Japan for participating locally at the
also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for interoperability test; as well as Hiroki Date and Hidefumi Otsuka,
contributing to the interoperability test. also of NTT Japan, for contributing to the interoperability test.
Additionally thanks are given to Xinping Wang for her help in writing
the interoperability draft and Fenggen Jia for extending the Ethereal
protocol analyzer.
8. IANA Considerations
This memo includes no request to IANA. Additionally, thanks are given to Xinping Wang for her help in
writing the interoperability document and to Fenggen Jia for
extending the Ethereal protocol analyzer.
9. Security Considerations 8. Security Considerations
No security elements of the protocol or the SCTP TML [RFC5811] No security elements of the protocol or the SCTP TML [RFC5811]
specification were tested. specification were tested.
The survey indicated that no security elements were implemented but The survey indicated that no security elements were implemented, but
all participants indicated their intention to implement all participants indicated their intention to implement them.
For security considerations regarding the ForCES Protocol and the For security considerations regarding the ForCES protocol and SCTP
SCTP-TML please see [RFC5810] and [RFC5811] TML, please see [RFC5810] and [RFC5811].
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Requirement Levels", BCP 14, RFC 2119, March 1997.
Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
Layer (TML) for the Forwarding and Control Element W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Separation (ForCES) Protocol", RFC 5811, March 2010. Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport
Element Separation (ForCES) Forwarding Element Model", Mapping Layer (TML) for the Forwarding and Control
RFC 5812, March 2010. Element Separation (ForCES) Protocol", RFC 5811,
March 2010.
10.2. Informative References [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9.2. Informative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for
of IP Control and Forwarding", RFC 3654, November 2003. Separation 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.
[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation [RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, September 2009. 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 was 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://www.ietf.org/mail-archive/web/forces/
tp://peach.ease.lsoft.com/scripts/ current/msg03687.html>.
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 was used is a modified tcpdump, by Jamal Hadi tcpdump that was used is a modified tcpdump, by Jamal
Salim, that can analyze and decode the ForCES protocol Hadi Salim, that can analyze and decode the ForCES
messages.", <http://peach.ease.lsoft.com/scripts/ protocol messages", <http://www.ietf.org/mail-archive/
wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=2262>. web/forces/current/msg03811.html>.
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
Kentaro Ogawa Kentaro Ogawa
NTT Corporation NTT Corporation
Tokyo, Tokyo
Japan Japan
Email: ogawa.kentaro@lab.ntt.co.jp EMail: ogawa.kentaro@lab.ntt.co.jp
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
18, Xuezheng Str., Xiasha University Town 18, Xuezheng Str., Xiasha University Town
Hangzhou, 310018 Hangzhou, 310018
P.R.China P.R. China
Phone: +86-571-28877721 Phone: +86-571-28877721
Email: wmwang@mail.zjgsu.edu.cn EMail: wmwang@mail.zjgsu.edu.cn
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Ottawa, Ontario, Ottawa, Ontario
Canada Canada
Phone: Phone:
Email: hadi@mojatatu.com EMail: hadi@mojatatu.com
 End of changes. 187 change blocks. 
549 lines changed or deleted 552 lines changed or added

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