Implementation Report for ForCES
draft-ietf-forces-implementation-report-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 11, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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.

Table of Contents

1.  Terminology and Conventions
    1.1.  Requirements Language
    1.2.  Definitions
2.  Introduction
    2.1.  ForCES Protocol
    2.2.  ForCES Model
    2.3.  Transport mapping layer
3.  Summary
4.  Methodology
5.  Exceptions
6.  Detail Section
    6.1.  Implementation Experience
        6.1.1.  ForCES Protocol Features
            6.1.1.1.  Protocol Messages
            6.1.1.2.  MainHeader Handling
            6.1.1.3.  TLV Handling
            6.1.1.4.  Operation Types Supported
            6.1.1.5.  ForCES Protocol Advanced Features
        6.1.2.  ForCES Model Features
            6.1.2.1.  Basic Atomic Types Supported
            6.1.2.2.  Compound Types Supported
            6.1.2.3.  LFBs Supported
        6.1.3.  ForCES SCTP-TML Features
            6.1.3.1.  TML Priority Ports
            6.1.3.2.  Message Handling at specific priorities
            6.1.3.3.  TML Security Feature
    6.2.  Interoperability Report
        6.2.1.  Scenarios
            6.2.1.1.  Scenario 1 - Pre-association Setup
            6.2.1.2.  Scenario 2 - TML priority channels connection
            6.2.1.3.  Scenario 3 - Association Setup - Association Complete
            6.2.1.4.  Scenario 4 - CE query
            6.2.1.5.  Scenario 5 - Heartbeat monitoring
            6.2.1.6.  Scenario 6 - Simple Config Command
            6.2.1.7.  Scenario 7 - Association Teardown
        6.2.2.  Tested Features
            6.2.2.1.  ForCES Protocol Features
            6.2.2.2.  ForCES Model Features
            6.2.2.3.  ForCES SCTP-TML Features
        6.2.3.  Interoperability Results
7.  Acknowledgements
8.  IANA Considerations
9.  Security Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Terminology and Conventions

1.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

1.2.  Definitions

This document follows the terminology defined by the ForCES Requirements in [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.) and by the ForCES framework in [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.). The definitions below are repeated below for clarity.

Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols.

Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by one or more CEs via the ForCES protocol.

LFB (Logical Function Block) - The basic building block that is operated on by the ForCES protocol. The LFB is a well defined, logically separable functional block that resides in an FE and is controlled by the CE via ForCES protocol. The LFB may reside 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. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities, but not a hardware-accurate representation of the FE implementation.

LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An LFB Instance represents an LFB Class (or Type) existence. 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 Instance is represented by an LFB Instance ID. As a result, an LFB Class ID associated with an LFB Instance ID uniquely specifies an LFB existence.

LFB Metadata - Metadata is used to communicate per-packet state from one LFB to another, but is not sent across the network. The FE model defines how such metadata is identified, produced and consumed by the LFBs. It defines the functionality but not how metadata is encoded within an implementation.

LFB Components - Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components. The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or Components write via the ForCES protocol (see below).

ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES Framework in [RFC3746]. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. Basically, the ForCES protocol works in a 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 architecture that uses the capabilities of existing transport protocols to specifically address protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc), and how to achieve and implement reliability, multicast, ordering, etc. The ForCES TML specifications are 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 [I‑D.dusseault‑impl‑reports] (Dusseault, L. and R. Sparks, “Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard,” July 2009.).

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] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.) has defined the ForCES requirements, and [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.) 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 FE-protocol (Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Khosravi, H., and W. Wang, “ForCES Protocol Specification,” March 2009.) [I‑D.ietf‑forces‑protocol] for further information.

2.2.  ForCES Model

The FE-MODEL (Halpern, J. and J. Salim, “ForCES Forwarding Element Model,” October 2008.) [I‑D.ietf‑forces‑model] 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 (Salim, J. and K. Ogawa, “SCTP based TML (Transport Mapping Layer) for ForCES protocol,” June 2009.) [I‑D.ietf‑forces‑sctptml].

3.  Summary

The authors attest that the ForCES Protocol, Model and SCTP-TML meet the requirements for Draft Standard.

Three independent implementations 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 implementations. Two other organizations, which independently extended two different well known public domain protocol analyzers, also participated in the interop for a total of five independent organizations 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 almost all issues were code bugs that were dealt with mostly on site and tests repeated successfully.

4.  Methodology

This report has both an implementation experience survey as well as the results of the interoperability test.

The survey information was gathered after implementors answered a brief questionnaire with all ForCES Protocol, Model and SCTP-TML features. The results can be seen in Section 6.1 (Implementation Experience)

The interoperability results were part of the interoperability test. Extended Ethereal and extended Tcpdump were used to verify the results. The results can be seen in Section 6.2 (Interoperability Report)

5.  Exceptions

The core features of the ForCES Protocol, Model and SCTP-TML have been implemented and tested in an interop in July, 2009. The intention of the interop testing was to validate that all the main features of the 3 core documents were inter-operable amongst different implementations. The tested features can be seen in Section 6.2.2 (Tested Features).

Different organizations surveyed have implemented certain features but not others. This approach is driven by presence of different LFBs the different organizations have currently implemented. All organizations surveyed have indicated intention to implement all outstanding features in due time. The implemented features can be seen in Section 6.1 (Implementation Experience).

Regarding the security feature of TML, IPSec, the fact that is not currently implemented does not affect the validity of this implementation report, since IPSec is a well-known and widely implemented protocol and does not affect the actual ForCES protocol and model in any way.

6.  Detail Section

6.1.  Implementation Experience

Three different organizations have implemented the ForCES Protocol, Model and SCTP-TML and answered a questionnaire. These are:

• NTT Japan.
• University of Patras.
• Zhejiang Gongshang University.

Also, not actual implementations, but extensions on protocol analyzers capable of understanding ForCES protocol messages, also are considered part of an implementation as they can offer validation of exchanged protocol messages. Two such extensions have been created:

• Extension to Ethereal/Wireshark [ethereal] (, “Ethereal is a protocol analyzer. The specific ethereal that will be used is an updated Ethereal, by Fenggen Jia, that can analyze and decode the ForCES protocol messages.,” .).
• Extension to Tcpdump [tcpdump] (, “Tcpdump is a linux protocol analyzer. The specific tcpdump that will be used is a modified tcpdump, by Jamal Hadi Salim, that can analyze and decode the ForCES protocol messages.,” .).

All implementors were asked regarding the ForCES features they have implemented. For every item listed the respondents indicated whether they had implemented it, will implement it, or won't implement it at all.

6.1.1.  ForCES Protocol Features

6.1.1.1.  Protocol Messages

6.1.1.2.  MainHeader Handling

6.1.1.3.  TLV Handling

6.1.1.4.  Operation Types Supported

6.1.1.5.  ForCES Protocol Advanced Features

6.1.2.  ForCES Model Features

6.1.2.1.  Basic Atomic Types Supported

6.1.2.2.  Compound Types Supported

6.1.2.3.  LFBs Supported

6.1.2.3.1.  FE Protocol LFB

6.1.2.3.2.  FE Object LFB

6.1.3.  ForCES SCTP-TML Features

6.1.3.1.  TML Priority Ports

6.1.3.2.  Message Handling at specific priorities

6.1.3.3.  TML Security Feature

6.2.  Interoperability Report

The interoperability test was performed at the University of Patras, in the Department of Electrical and Computer Engineering.

There were two options to participate in the interoperability test.

1. Locally at the University of Patras premises.

2. Remotely via internet.

Implementations from NTT and University of Patras, were present locally at the premises, while the implementation from Zhejiang Gongshang University were connected remotely.

The interoperability test, tested the basic functionality of the ForCES protocol, mainly message passing and handling.

The following scenarios were tested.

6.2.1.  Scenarios

Since the main goal of this interoperability test is to test the basic protocol functionality, the test parameters are limited.

1. In the Association Setup Message, all report messages will be ignored.
2. In the Association Setup Phase, the messages, FEO OperEnable 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 is enabled once the LFBSelectors has been queried.
3. Only FullDataTLVs are going to be used and not SparseData TLV's.
4. There will be no transaction operations.
5. Each message shall have only one LFBSelector TLV, one Operation TLV and one PathDataTLV per message when these are used.

6.2.1.1.  Scenario 1 - Pre-association Setup

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 part in a successful CE-FE connection the participating CEs and FEs should be able to be configured.

In the Pre-association Phase the following configuration items MUST be setup regarding the CEs:

• The CE ID.
• The FE IDs that will be connected to this CE
• The IP of the FEs that will connect
• The TML priority ports.

In the Pre-association Phase the following configuration items MUST be setup regarding the FEs:

• The FE ID.
• The CE ID that this FE will be connecting to.
• The IP of the CE that will connect to
• The TML priority ports.

6.2.1.2.  Scenario 2 - TML priority channels connection

For the current interoperability test, the SCTP will be used as TML. The TML connection with the associating element is needed for the scenario 2 to be successful.

The SCTP-TML document (Salim, J. and K. Ogawa, “SCTP based TML (Transport Mapping Layer) for ForCES protocol,” June 2009.) [I‑D.ietf‑forces‑sctptml] defines 3 priority channels, with specific ports:

• High priority - Port number: 6700
• Medium priority - Port number: 6701
• Lower priority - Port number: 6702

6.2.1.3.  Scenario 3 - Association Setup - Association Complete

Once the Pre-association phase has been complete in the previous 2 scenarios, CEs and FEs are ready to communicate using the ForCES protocol, and enter the Association Setup stage. In this stage the FEs attempts to join the NE. The following ForCES protocol messages will be exchanged for each CE-FE pair in the specified order:

• Association Setup Message (from FE to CE)
• Association Setup Response Message (from CE to FE)
• Query Message: FEO LFBSelectors(from CE to FE)
• Query Response: FEO LFBSelectors response (from FE to CE)

6.2.1.4.  Scenario 4 - CE query

Once the Association Phase stage has been complete, the FEs and CEs will enter the Established stage. In this stage the FE is continuously updated or queried. The CE should query the FE a 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 from the FE Object LFB is the State of the LFB (FEState)

The following ForCES protocol messages will be exchanged:

• Query Message
• Query Response Message

6.2.1.5.  Scenario 5 - Heartbeat monitoring

The Heartbeat (HB) Message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in 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 should not generate any Heartbeat messages. the CE is responsible for 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 Heartbeat message with the ACK flag set to AlwaysACK and the FE should respond.

The following ForCES protocol messages will be exchanged:

• Heartbeat Message

6.2.1.6.  Scenario 6 - Simple Config Command

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 metered would be to change the Heartbeat configuration. This will be done in two steps:

1. Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force the FE to send heartbeats.
2. After some heartbeats from the FE, the FE Heartbeat Interval (FEHI) will be changed.

The following ForCES protocol messages will be exchanged:

• Config Message
• Config Response Message

6.2.1.7.  Scenario 7 - Association Teardown

In the end, the association must be terminated. There are two scenarios by which the association maybe terminated:

1. Normal tear down by exchanging Association Teardown Message
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 a CE.

All scenarios may be tested in the interoperability test.

The following ForCES protocol messages will be exchanged:

• Association Teardown Message

6.2.2.  Tested Features

The features that were tested are:

6.2.2.1.  ForCES Protocol Features

6.2.2.1.1.  Protocol Messages

6.2.2.1.2.  MainHeader Handling

6.2.2.1.3.  TLV Handling

6.2.2.1.4.  Operation Types Supported

6.2.2.1.5.  ForCES Protocol Advanced Features

Although Batching was not initially designed to be tested, it was tested during the interoperability test.

6.2.2.2.  ForCES Model Features

6.2.2.2.1.  Basic Atomic Types Supported

6.2.2.2.2.  Compound Types Supported

6.2.2.2.3.  LFBs Supported

6.2.2.2.3.1.  FE Protocol LFB

6.2.2.2.3.2.  FE Object LFB

6.2.2.3.  ForCES SCTP-TML Features

6.2.2.3.1.  TML Priority Ports

6.2.2.3.2.  Message Handling at specific priorities

6.2.3.  Interoperability Results

All implementations were found to be interoperable with each other.

All scenarios were tested successfully.

The following issues were found and dealt with.

1. Some messages were sent to the wrong priority channels. There was some ambiguities on the SCTP-TML document that have been corrected.
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 the CE to shut down the connection and were caught in a deadlock. This was a code bug and was fixed.
3. Sometimes the association setup message, only on the remote connection test, although sent, was not received by the other end and made impossible the association. This was caused by network problems.
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 code bug and was fixed.
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.
6. After the FEHBPolicy was set to 1 the FE didn't send any HeartBeats. This was a code bug and was fixed.
7. Some FE's sent HeartBeats with the ACK flag with a value other than NoACK. The CE responded. This was a code bug and was fixed.
8. When a cable was disconnected, the TML didn't realize that. The association was dropped due to heartbeats, this was a success, but this is an implementation issue implementers should keep in mind. This is a SCTP options issue. Nothing was needed to be done.
9. A CE crashed due to unknown LFBSelector values. This was a code bug and was fixed.
10. With the remote connection there were a lot of ForCES packet retransmittion. The problem is that packets like Heartbeats were retransmitted. This is a SCTP issue. SCTP-PR is needed to be used.

The implementers went beyond the call of duty. The test was extended with another test for batching messages. This test was also done successfully.

7.  Acknowledgements

The authors like to give thanks to Professors Odysseas Koufopavlou and Spyros Denazis, and the Department of Electrical and Computer Engineering in the University of Patras who hosted the ForCES interoperability test.

Also the authors would like to give thanks to Chuanhuang Li, Ming Gao, and other participants from Zhejiang Gongshang University which connected remotely. This allowed the discovery of a series of issues that would have been uncaught otherwise.

The authors would like to thank also Hideaki Iwata and Yoshinobu Morimoto for participating locally at the interoperability test and also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for contributing to the interoperability test.

Additionally thanks are given to Xinping Wang for her help in writing the interoperability draft an Fenggen Jia for exteding the Ethereal protocol analyzer.

8.  IANA Considerations

This memo includes no request to IANA.

9.  Security Considerations

For Security considerations please see [I‑D.ietf‑forces‑protocol] (Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Khosravi, H., and W. Wang, “ForCES Protocol Specification,” March 2009.) and [I‑D.ietf‑forces‑sctptml] (Salim, J. and K. Ogawa, “SCTP based TML (Transport Mapping Layer) for ForCES protocol,” June 2009.)

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses