ForCES Model Extension

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 .

This document follows the terminology defined by the ForCES Model in . The required definitions are repeated below for clarity. FE Model - The FE model is designed to model the logical processing functions of an FE. The FE model proposed in this document includes three components; the LFB modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810]. LFB (Logical Functional Block) Class (or type) - A template that represents a fine-grained, logically separable aspect of FE processing. Most LFBs relate to packet processing in the data path. LFB classes are the basic building blocks of the FE model. LFB Instance - As a packet flows through an FE along a data path, it flows through one or multiple LFB instances, where each LFB is an instance of a specific LFB class. Multiple instances of the same LFB class can be present in an FE's data path. Note that we often refer to LFBs without distinguishing between an LFB class and LFB instance when we believe the implied reference is obvious for the given context. LFB Model - The LFB model describes the content and structures in an LFB, plus the associated data definition. XML is used to provide a formal definition of the necessary structures for the modeling. Four types of information are defined in the LFB model. The core part of the LFB model is the LFB class definitions; the other three types of information define constructs associated with and used by the class definition. These are reusable data types, supported frame (packet) formats, and metadata. Element - Element is generally used in this document in accordance with the XML usage of the term. It refers to an XML tagged part of an XML document. For a precise definition, please see the full set of XML specifications from the W3C. This term is included in this list for completeness because the ForCES formal model uses XML. Attribute - Attribute is used in the ForCES formal modeling in accordance with standard XML usage of the term, i.e., to provide attribute information included in an XML tag. 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, but not how the per-packet state is implemented within actual hardware. Metadata is sent between the FE and the CE on redirect packets. ForCES Component - A ForCES Component is a well-defined, uniquely identifiable and addressable ForCES model building block. A component has a 32-bit ID, name, type, and an optional synopsis description. These are often referred to simply as components. LFB Component - An LFB component is a ForCES component that defines the Operational parameters of the LFBs that must be visible to the CEs. LFB Class Library - The LFB class library is a set of LFB classes that has been identified as the most common functions found in most FEs and hence should be defined first by the ForCES Working Group.

The ForCES Model presents a formal way to define FEs Logical Function Blocks (LFBs) using XML. has been published a more than two years and current experience in its use has demonstrated need for adding new and changing existing modeling concepts. Specifically this document extends the ForCES Model to allow complex datatypes for metadata, optional default values for datatypes and optional access types for structures. Additionally the document introduces three new features, bitmap as a new datatype, a new event condition BecomesEqualTo and LFB properties. These extensions are an addendum to the ForCES model and do not require any changes on the ForCES protocol as they are simply changes of the schema definition. Additionally backward compatibility is ensured as xml libraries produced with the earlier schema are still valid with the new one. XXX: Discussion is needed to specify whether bitmap required protocol definition of how bitmap is sent through the wire.

Section 4.6. (Element for Metadata Definitions) in the ForCES Model limits the datatype use in metadata to only atomic types. shows the xml schema excerpt where ony typeRef and atomic are allowed for a metadata definition. However there are cases where complex metadata are used in the datapath, for example two simple use cases can be seen in the OpenFlow switch 1.1 and beyond: The Action Set metadata follows a packet inside the Flow Tables. The Action Set metadata is an array of actions to be performed at the end of the pipeline. When a packet is received from a controller it may be accompanied by a list of actions to be performed on it prior to be sent on the flow table pipeline which is also an array. With this extension, complex data types are also allowed, specifically structs and arrays as metadata. The key declarations are required to check for validity of content keys in arrays and componentIDs in structs.

]]>

In the original schema, default values can only be defined for datatypes defined inside LFB components and not inside structures or arrays. Therefore default values of datatypes that are constantly being reused, e.g. counters with default value of 0, have to be constantly respecified. Additionally, datatypes inside complex datatypes cannot be defined with a default value, e.g. a counter inside a struct that has a default value of 0. This extension allows optionally to add default values to atomic and typeref types, whether they are as simple or complex datatypes. A simple use case would be to have a struct component where one of the components is a counter which the default value would be zero. This extension alters the definition of the typeDeclarationGroup in the xml schema from to to allow default values to TypeRef.

]]>

]]> Additionally it appends to the declaration of the AtomicType this xml to allow default values to Atomic datatypes.

]]>

In the original schema, the access type can be only be defined on components of LFB and not on components in structs or arrays. However when it's a struct datatype it is not possible to fine-tune access type per component in the struct. A simple use case would be to have a read-write struct component where one of the components is a counter where the access-type could be read-reset or read-only, e.g. a read-reset or a read-only counter inside a struct. With this extension is it allowed to define the access type for a struct component either in the datatype definitions or in the LFB component definitions. When the optional access type for a struct component is defined it MUST override the access type of the struct. If by accident an access type for a component in a capability is defined, the access type MUST NOT be taken into account and MUST always be considered as read-only. This extension alters the definition of the struct in the xml schema from to .

]]>

With the current schema it is valid to create a struct of booleans in order to simulate a bitmap value. However each boolean is sent as 4bytes. This extension adds the bitmap, a set of sequential named bits. Bitmaps may be useful in describing capabilities, e.g. Link speed capabilities as multiple boolean values. EDITOR: Discussion may be required as to whether there is a need for protocol description of how the bitmap is sent through the wire. In the new schema, bits are named followed an optional bit value. An example:

BitmapExample A bitmap field example ]]> The ordering of the bits MUST be implemented in the order that are defined in the xml library. Positions MUST range from 0 and reach bitmap size-1. If the size of the bitmap is not defined, then the size of the bitmap MUST be the maximum position value of all the bit values, e.g. 4 The bitmap is defined in the model extension schema as follows:

]]> Along with the needed addition to the typeDeclarationGroup Definition:

]]>

This extensions adds one more event condition in the model schema, that of BecomesEqualTo. The difference between Greater Than and Less Than, is that when the value is exactly that of the BecomesEqualTo, the event is triggered. This event condition is particular useful when there is a need to monitor one or more states of an LFB or the FE. For example in the CEHA document it may be useful for the master CE to know which backup CEs have just become associated in order to connect to them and begin synchronizing the state of the FE. The master CE could always poll for such information but getting such an event will speed up the process and the event may be useful in other cases as well for monitoring state. The event MUST be triggered only when the value of the targeted component becomes equal to the event condition value and MUST NOT generate events while the targeted component's value remains equal to the event condition's value. The BecomesEqualTo is appended to the schema as follows:

]]> It can become useful for the CE to be notified when the state has changed once the BecomesEqualTo event has been triggered, e.g. the CE may need to know when a backup CE has lost association. Such an event can be generated either by defining a second event on the same component, namely an Event Changed, or by simply reusing BecomesEqualTo and use event properties, in particular event hysteresis. We append the following definition for the event hysteresis defined in section 4.8.5.2 in , with V being the hysteresis value: For an <eventBecomesEqualTo/> condition, after the last notification a new <eventBecomesEqualTo/> notification MUST be generated only one time once the value has changed by +/- V. For example using the value of 1 for V, will in effect create a singular event that will notify the CE that the value has changed by at least 1. A developer of a CE must also take into account to use count or time filtering to avoid being overun by messages, e.g. in the case of rapid state changes.

The current model definition specifies properties for components of LFBs. Experience however has proven valuable at least for debug reasons, to have statistics per LFB instance to monitor sent/received messages and errors for communication between CE and FE. These properties are read-only. Editorial: Need additional discussion whether we need these LFB packets. Additional definition may be required to handle protocol messages for LFB properties The following datatype definitions are to be used as properties for LFB instances.

LFBProperties LFB Properties definition PacketsSentToCE Packets sent to CE uint32 SentErrorPacketsToCE Error Packets sent to CE uint32 BytesSentToCE Bytes sent to CE uint32 SentErrorBytesToCE Error Bytes sent to CE uint32 PacketsReceivedFromCE Packets received from CE uint32 ReceivedErrorPacketsFromCE Error Packets received from CE uint32 BytesReceivedFromCE Bytesreceived from CE uint32 ReceivedErrorBytesFromCE Error Bytes received from CE uint32 ]]>

As specified earlier this is not an extension but an enhancement of the schema to provide additional validation rules. This includes adding new key declarations to provide uniqueness as deinfed by the ForCES Model. Such validations work only on within the same xml file. The following validation rules have been appended in the original schema in : Each metadata ID must be unique. LFB Class IDs must be unique. Component ID, Capability ID and Event Base ID must be unique per LFB. Event IDs must be unique per LFB. Special Values in Atomic datatypes must be unique per atomic datatype.

Schema for Defining LFB Classes and associated types ( frames, data types for LFB attributes, and metadata). ]]>

The author would like to acknowledge Joel Halpern, Jamal Hadi and Dave Hood for their comments and discussion that helped shape this document in a better way.

This memo includes no request to IANA.

The security considerations that have been described in the ForCES Model RFC apply to this document as well.