Forwarding and Control Element Separation (ForCES) Model Extension
updates
- rfc-5812 — Forwarding and Control Element Separation (ForCES) Forwarding Element Model
Extracted elements (24)
Complex data types for metadata were added because real-world use cases (such as OpenFlow Action Set metadata and controller-supplied action lists) require arrays and structs as metadata, not just atomic types. RFC 5812 limited metadata to atomic types only.
eventBecomesEqualTo was introduced to enable monitoring of specific LFB or FE states without polling; for example, a master CE in a CEHA scenario can be notified immediately when a backup CE becomes associated, rather than polling periodically.
LFB properties were introduced primarily for debug and monitoring purposes, to expose per-LFB-instance statistics about sent/received messages and errors between CE and FE without requiring protocol changes.
The version attribute in derivedFrom is optional to maintain backward compatibility with RFC 5812; when omitted, derivedFrom refers to version 1.0 of the parent LFB class.
The extensions are backward compatible: XML definitions valid under the old namespace (1.0) are also valid under the new namespace (1.1). Auxiliary tools processing XML from both namespaces must be able to understand both.
Default values MUST be ignored if the data type is not an atomic or a base data type. Default values of data types referenced in capabilities or metadata MUST be ignored.
For an eventBecomesEqualTo condition with hysteresis value V, after the last notification, a new eventBecomesEqualTo notification MUST be generated only one time once the value has changed by +/- V.
LFB componentID 0 MUST refer specifically to LFB properties; ID 0 MUST NOT be used for any component definition. Any command with a path starting from LFB componentID 0 refers to LFB properties.
The eventBecomesEqualTo event condition 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 condition value.
When a data type X with default value A is referenced from a data type Y with default value B, Y's default value B overrides A. Default values of LFB components override any default value from the dataTypeDef definition.
When optional access types for components within a struct are defined, those access types MUST override the access type of the enclosing struct. Access types provided for components in a capability MUST be ignored; access types for structs in metadata MUST be ignored.
XML libraries produced by the new schema that need to be compatible with existing ForCES implementations MUST NOT include any of the features described in this document.
LFB class inheritance (derivedFrom) is extended with an optional version attribute of type versionType, allowing a child LFB to explicitly reference a specific version of the parent class and resolve ambiguity when multiple versions exist.
LFB Properties are defined as a read-only struct (LFBProperties) with 8 uint32 components: PacketsSentToCE, SentErrorPacketsToCE, BytesSentToCE, SentErrorBytesToCE, PacketsReceivedFromCE, ReceivedErrorPacketsFromCE, BytesReceivedFromCE, ReceivedErrorBytesFromCE.
The dataTypeDefsType schema is extended with an optional defaultValue element (type xsd:token, minOccurs=0) to allow data type definitions to carry a default value reusable across components and complex types.
The eventBecomesEqualTo event condition is added to the schema as a new member of the eventCondition substitution group, complementing the existing eventGreaterThan and eventLessThan conditions for exact-value state monitoring.
The ForCES LFB XML schema namespace is updated from 'urn:ietf:params:xml:ns:forces:lfbmodel:1.0' to 'urn:ietf:params:xml:ns:forces:lfbmodel:1.1' to reflect the extensions introduced by this document.
The metadataDefsType schema is extended to allow array and struct types in addition to typeRef and atomic, enabling complex metadata definitions. Key declarations are added to enforce uniqueness of contentKeyIDs in arrays and componentIDs in structs.
The structType schema is extended with an optional access attribute (default 'read-write') on each component element, allowing per-component fine-grained access control within structs using accessModeType values: read-only, read-write, write-only, read-reset, trigger-only.
The XML validation schema adds uniqueness constraints enforced via xsd:key declarations: metadataID must be unique, LFBClassIDs must be unique, componentID/capabilityID/event baseID must be unique per LFB, eventIDs must be unique per LFB, and special values in atomic types must be unique per type.
IANA registered a new XML namespace URI 'urn:ietf:params:xml:ns:forces:lfbmodel:1.1' per RFC 3688 guidelines. The registrant contact is IESG; no XML body is associated with the namespace registration.
The extensions in this document add constructs (new event, new properties, optional access types, complex metadata) that do not change the security semantics of the ForCES protocol. The security considerations of RFC 5812 apply in full.
With respect to pervasive monitoring (RFC 7258), the new complex metadata types and the eventBecomesEqualTo event have very little or no effect in making pervasive monitoring simpler or more effective; no new mechanisms to abuse LFBs for monitoring are introduced.
The LFB componentID attribute is restricted from xsd:unsignedInt to require minExclusive value of 0, reserving componentID 0 exclusively for LFB properties and ensuring it cannot be used in component definitions.