ForCES Model Extension

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 1.1 specification and beyond: The Action Set metadata is an array of actions descriptors, which traverses the processing pipeline along with the packet data. When a packet is received from a controller it may be accompanied by a list of actions, as metadata, to be performed on it prior to being sent on the processing pipeline. This list of actions 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 the option 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 this document appends to the initial declaration of the AtomicType, , an optional defaultValue, , to allow default values to Atomic datatypes. Note that both declarations include the new special value validation described in

]]>

]]> Examples of using default values is depicted in .

Counter Values Example default values in struct GoodPacketCoutner A counter for good packets uint32 0 BadPacketCoutner A counter for bad packets uint32 0 ]]>

In the original schema, the access type can only be defined on components of an LFB and not on components within structs or arrays. That means that when it is a struct datatype it is not possible to fine-tune access type per component within 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. This extension allows the definition of the access type for a struct component either in the datatype definitions or in the LFB component definitions. When optional access type for components within a struct are defined, these components's access type MUST override the access type of the struct. For example if a struct has an access type of read-write but has a component that is a read-only counter, the counter's access type MUST be read-only. The access type for a component in a capability is always read-only per . If an access type is provided for a component in a capability, the access type MUST be ignored. Similarly if an access type is provided for a struct in a metadata the access type MUST be ignored. This extension alters the definition of the struct in the xml schema from to .

]]>

]]> An example of using optional access types for structs can be depicted in

PacketFlows Packet Flows, match and counter FlowMatch Flow Match MatchType MatchCounter Packets matching the flow match uint32 0 ]]>

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 becomes exactly that of the BecomesEqualTo, the event is triggered. This event condition is particularly useful when there is a need to monitor one or more states of an LFB or the FE. For example in the CE High Availability (CEHA) RFC 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. Implementations MUST NOT generate subsequent 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 should consider using count or time filtering to avoid being overrun by messages, e.g. in the case of rapid state changes.

The previous model definition specifies properties for components of LFBs. Experience has shown that, at least for debug reasons, it would be useful to have statistics per LFB instance to monitor sent and received messages and errors in communication between CE and FE. These properties are read-only. In order to avoid ambiguity on protocol path semantics, this document specifies that the LFB component with ID 0 specifically MUST refer to LFB properties and ID 0 MUST NOT be used for any component definition. This disallowment is backwards compatible as no known LFB definition uses LFB component with ID 0. Any command with a path starting from LFB component 0 refers to LFB properties. The following change in the xml schema disallows usage of LFB component 0:

]]>

]]> 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 ]]>

The ForCES model allows inheritance for LFB classes. However the xml schema defines only the LFB class from which an LFB class inherits. Recent implementations have identified an issue where ambiguity rises when different versions of the parent LFB class exists. This document augments the derivedFrom part of the LFB class definition with an optional version attribute when the derivedFrom field is used. Having the version attribute as optional was a decision based on the need to maintain backwards compatibility with the XML schema defined in . However if the version is omitted then the derivedFrom will always specify the first version of the parent LFB class, which usually is version 1.0. This extension alters the definition of the derivedFrom in the xml schema from to .

]]>

]]> An example of the use of the version attribute is given in

EtherPHYCop ]]>

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 defined by the ForCES Model. Such validations work only on within the same xml file. This document introduces the following validation rules that did not exist 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.