rfc-7408

Forwarding and Control Element Separation (ForCES) Model Extension

E. Haleplidis
date2014-11 streamIETF areartg wgforces statusPROPOSED STANDARD pages31 canonicalhttps://www.rfc-editor.org/rfc/rfc7408 doi10.17487/RFC7408 errataview
This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.

updates

Extracted elements (24)

design-rationale §2.1

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.

design-rationale §2.4

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.

design-rationale §2.5

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.

design-rationale §2.6

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.

interoperability-note §3

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.

normative-requirement §2.2 MUST

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.

normative-requirement §2.4 MUST

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.

normative-requirement §2.5 MUST

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.

normative-requirement §2.4 MUST

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.

normative-requirement §2.2 MUST

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.

normative-requirement §2.3 MUST

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.

normative-requirement §1 MUST NOT

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.

registry

protocol-element §2.6

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.

protocol-element §2.5

LFB Properties are defined as a read-only struct (LFBProperties) with 8 uint32 components: PacketsSentToCE, SentErrorPacketsToCE, BytesSentToCE, SentErrorBytesToCE, PacketsReceivedFromCE, ReceivedErrorPacketsFromCE, BytesReceivedFromCE, ReceivedErrorBytesFromCE.

protocol-element §2.2

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.

protocol-element §2.4

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.

protocol-element §3

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.

registry

protocol-element §2.1

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.

protocol-element §2.3

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.

protocol-element §2.7

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.

registry §4

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.

registry

security-consideration §5

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.

security

security-consideration §5

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.

security, privacy

wire-format §2.5

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.