ForCES Interoperability Draft

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 .

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). has defined the ForCES requirements, and has defined the ForCES framework.

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 for further information.

The FE-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.

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. It is expected that more than one TML will be standardized. The various possible TMLs could vary their implementations based on the capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. All ForCES Protocol Layer implementations MUST be portable across all TMLs. Although more than one TML may be standardized for the ForCES Protocol, for the purposes of the interoperability test, the mandated MUST IMPLEMENT SCTP TML which will be used.

This document follows the terminology defined by the ForCES Requirements in and by the ForCES framework in . 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. CE Manager (CEM) - A logical entity responsible for generic CE management tasks. It is particularly used during the pre-association phase to determine with which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. 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. FE Manager (FEM) - A logical entity responsible for generic FE management tasks. It is used during pre-association phase to determine with which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. An FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, an FE manager might be physically combined with any of the other logical entities such as FEs. ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside an NE, the NE represents a single point of management. Similarly, an NE usually hides its internal organization from external entities. 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. FE Topology - A representation of how the multiple FEs within a single NE are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology). 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 Attribute - Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB attributes. The LFB attributes include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol (see below). LFB Topology - Representation of how the LFB instances are logically interconnected and placed along the datapath within one FE. Sometimes it is also called intra-FE topology, to be distinguished from inter-FE topology. Pre-association Phase - The period of time during which an FE Manager and a CE Manager are determining which FE(s) and CE(s) should be part of the same network element. Post-association Phase - The period of time during which an FE knows which CE is to control it and vice versa. This includes the time during which the CE and FE are establishing communication with one another. 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.

Most FEs and CEs should be located locally at the University of Patras premises. But if some parties would like to participate but cannot attend the interoperability test locally a connection over the internet MAY be created. The actual test will take place between FEs and CEs of different implementors with different permutations.

Hardware/Software (CEs and FEs) that will be located within the University of Patras premises, will be connected together using switches and hubs. For each permutation there would be a different subnet ranging starting from 192.168.1.xxx to 192.168.255.xxx to distinguish them. For each subnet there will be a machine with IP 192.168.xxx.2 which will act as a network monitor using a network analyzer that should be able to show the packets that are traversing the network.The IPs of CEs and FEs will range from 192.168.xxx.3 to 192.168.xxx.254 This will help minimize packet interference with other machines and make the testing and the validation easier

For parties that cannot participate locally there are two current propositions: A SCTP over IPsec (VPN) case, where CE and FE are part of a VPN. SCTP over IP with a firewall that will allow only the CEs and FEs IPs. A number of public IPs will be provided by the University of Patras will be provided for such a case.

All protocol messages of each scenario will be monitored using a protocol network analyzer to test validity.

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 succesfull 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: Which FE IDs should they be connected The IP of the corresponsing FEs In the Pre-association Phase the following configuration items MUST be setup regarding the FEs: Which CE IDs should they be connected The IP of the corresponsing CEs Once each element is configured, Scenario 1 is successfull.

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 successfull.

The SCTP-TML draft defines 3 priority channels, with specific ports: High priority - Port number: 6700 Medium priority - Port number: 6701 Lower priority - Port number: 6702 Once these channels have been established with each associated element, will the Scenario 3 be successfull.

Once the Pre-association phase has been complete in the previous 3 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: Association Setup Message (from FE to CE) Association Setup Response Message (from CE to FE) Once the associations has been initialized scenario 4 will have been successfull.

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

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

A config message is sent by the CE to the FE to configure LFB components in the FE. A simple config command easily visilble and metered would be to change the Heartbeat configuration. This will be done in two steps: Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force the FE to send heartbeats. 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

In the end, the association must be terminated. There are two scenarios by which the association maybe terminated: By stopping heartbeats from a FE or a CE. By externally shutting down/rebooting a FE or a CE. Both scenarios may be tested in the interoperability test. The following ForCES protocol messages will be exchanged: Association Teardown Message

TBA

This memo includes no request to IANA.

We should consider security issues if we have connections when there are associations between CEs and FEs over the internet. Perhaps SCTP over IPsec may be used. TBA.