Internet Engineering Task Force (IETF) E. Haleplidis Request for Comments: 7408 University of Patras Updates: 5812 November 2014 Category: Standards Track ISSN: 2070-1721
Forwarding and Control Element Separation (ForCES) Model Extension
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7408.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Haleplidis Standards Track [Page 1]
RFC 7408 ForCES Model Extension November 2014
Table of Contents
1. Introduction ....................................................2 1.1. Requirements Language ......................................3 1.2. Terminology ................................................3 2. ForCES Model Extensions .........................................3 2.1. Complex Data Types for Metadata ............................3 2.2. Optional Default Values for Data Types .....................5 2.3. Optional Access Types for Structs ..........................8 2.4. New Event Condition: eventBecomesEqualTo ..................11 2.5. LFB Properties ............................................12 2.6. LFB Class Inheritance .....................................14 2.7. Enhancing XML Validation ..................................15 3. XML Extension Schema for LFB Class Library Documents ...........15 4. IANA Considerations ............................................29 5. Security Considerations ........................................29 6. References .....................................................30 6.1. Normative References ......................................30 6.2. Informative References ....................................30 Acknowledgements ..................................................31 Author's Address ..................................................31
The ForCES model [RFC5812] presents a formal way to define Forwarding Element (FE) Logical Functional Blocks (LFBs) using the eXtensible Markup Language (XML). [RFC5812] was published several years before this document, and experience with its use has demonstrated the need to add new modeling concepts and change existing ones.
Specifically, this document updates the ForCES model [RFC5812] to allow complex data types for metadata (Section 2.1), optional default values for data types (Section 2.2), and optional access types for structures (Section 2.3). It also fixes an issue with LFB class inheritance (Section 2.6). Additionally, the document introduces two new features: a new event condition named eventBecomesEqualTo (Section 2.4) and LFB properties (Section 2.5).
These extensions are an update to the ForCES model [RFC5812] and do not require any changes to the ForCES protocol [RFC5810] as they are simply changes to the schema definition. Additionally, backward compatibility is ensured as XML libraries produced with the earlier schema are still valid with the new one. In order for XML libraries produced by the new schema to be compatible with existing ForCES implementations, the XML libraries MUST NOT include any of the features described in this document.
Haleplidis Standards Track [Page 2]
RFC 7408 ForCES Model Extension November 2014
Extensions to the schema and excerpts of the schema include the tags <!-- Extension RFC 7408 --> and <!-- /Extension RFC 7408 -->, which designate the beginning and ending of extension text specified by this document in respect to the schema in the original ForCES model [RFC5812].
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 [RFC2119].
This document uses the terminology defined in the ForCES model [RFC5812]. In particular, the reader is expected to be familiar with the following terms:
Section 4.6 ("<metadataDefs> Element for Metadata Definitions") of the ForCES model [RFC5812] limits the data type use in metadata to only atomic types. Figure 1 shows the XML schema excerpt where only typeRef and atomic are allowed for a metadata definition.
Figure 1: Initial metadataDefsType Definition in the Schema
However, there are cases where complex metadata are used in the datapath: for example, two simple use cases are described in version 1.1.0 (and subsequent versions) of the OpenFlow Switch Specification [OpenFlowSpec1.1]:
1. The Action Set metadata is an array of actions descriptors, which traverses the processing pipeline along with the packet data.
2. 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 the extension shown in Figure 2, 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 data types defined inside LFB components and not inside structures or arrays. Therefore, default values for data types that are constantly being reused, e.g., counters with default value of 0, have to be constantly respecified. Additionally, data types inside complex data types 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 data types. These data types can then be referenced as simple components or within complex data types such as structs. A simple use case would
Haleplidis Standards Track [Page 5]
RFC 7408 ForCES Model Extension November 2014
be to have a struct component where one of the components is a counter with a default value of zero. To achieve that, the counter must first be defined as a data type with the required default value and then referenced in the struct. Default values MUST adhere the following formal restrictions:
1. Default values MUST be ignored if the data type is not an atomic or a base data type.
2. When a data type X with default value A is referenced from a data type Y with a default value B, the default value of the data type that references overrides the referenced default value, e.g., in this case, Y's default value will be B.
3. Default values of LFB components override any default value specified from the dataTypeDef definition.
4. Default values of data types referenced in capabilities or metadata MUST be ignored.
This extension simply adds to the definition of dataTypeDefsType in the XML schema shown in Figure 3 to allow default values for dataTypeDefsType. The new definition is shown in Figure 4.
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 data type, 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 with an access type that 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 data type definitions or in the LFB component definitions.
When optional access types for components within a struct are defined, the access types for these components 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.
Haleplidis Standards Track [Page 8]
RFC 7408 ForCES Model Extension November 2014
Per [RFC5812], the access type for a component in a capability is always read-only. 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 the initial definition shown in Figure 6 to the new shown in Figure 7.
This extension adds one more event condition in the model schema, eventBecomesEqualTo. eventBecomesEqualTo is different from eventGreaterThan and eventLessThan because the event is triggered when the value is exactly that of the eventBecomesEqualTo threshold. 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 Control Element High Availability (CEHA) document [RFC7121], 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.
Haleplidis Standards Track [Page 11]
RFC 7408 ForCES Model Extension November 2014
eventBecomesEqualTo is appended to the schema as shown in Figure 9.
Figure 9: New Excerpt of eventBecomesEqualTo Event Condition Definition in the Schema
It can become useful for the CE to be notified when the state has changed once the eventBecomesEqualTo 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 eventChanged) or by simply reusing eventBecomesEqualTo and using event properties (in particular, eventHysteresis). We append the following definition to the eventHysteresis defined in Section 4.8.5.2 of [RFC5812], with V being the hysteresis value:
o 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 a CE and FE. These properties are read-only.
In order to avoid ambiguity on protocol path semantics, this document specifies that the LFB componentID 0 specifically MUST refer to LFB properties and ID 0 MUST NOT be used for any component definition. This disallowance is backward compatible as no known LFB definition uses an LFB componentID 0. Any command with a path starting from LFB componentID 0 refers to LFB properties. Figures 10 and 11 illustrate the change in the XML schema that disallows usage of LFB componentID 0:
The ForCES model [RFC5812] 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 exist. 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 backward compatibility with the XML schema defined in [RFC5812]. However, if the version is omitted, then derivedFrom will always specify the first version of the parent LFB class, which usually is version 1.0.
This extension alters the definition of derivedFrom in the XML schema from the initial definition shown in Figure 13 to the new shown in Figure 14.
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 [RFC5812]. Such validations work only within the same XML file.
This document introduces the following validation rules that did not exist in the original schema in [RFC5812]:
1. Each metadataID must be unique.
2. LFBClassIDs must be unique.
3. componentID, capabilityID, and Event baseID must be unique per LFB.
4. eventIDs must be unique per LFB.
5. Special values in atomic data types must be unique per atomic data type.
3. XML Extension Schema for LFB Class Library Documents
This section includes the new XML schema. Note that the namespace number has been updated from 1.0 to 1.1.
Haleplidis Standards Track [Page 15]
RFC 7408 ForCES Model Extension November 2014
The extensions described in this document are backwards compatible in terms of the operation of the ForCES protocol. In terms of the XML, any definitions that were valid under the old namespace are valid under the new namespace. It is to be noted that any auxiliary tools that are processing XML definitions written under both namespaces will need to be able to understand both.
<!--ref must refer to a name of a defined metadata--> <xsd:element name="ref" type="metadataInputRefType"/> <xsd:element name="one-of" type="metadataInputChoiceType"/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="metadataInputChoiceType"> <xsd:choice minOccurs="2" maxOccurs="unbounded"> <!-- ref must refer to a name of a defined metadata --> <xsd:element name="ref" type="xsd:NMTOKEN"/> <xsd:element name="one-of" type="metadataInputChoiceType"/> <xsd:element name="metadataSet" type="metadataInputSetType"/> </xsd:choice> </xsd:complexType> <xsd:complexType name="metadataInputSetType"> <xsd:choice minOccurs="2" maxOccurs="unbounded"> <!-- ref must refer to a name of a defined metadata --> <xsd:element name="ref" type="metadataInputRefType"/> <xsd:element name="one-of" type="metadataInputChoiceType"/> </xsd:choice> </xsd:complexType> <xsd:complexType name="metadataInputRefType"> <xsd:simpleContent> <xsd:extension base="xsd:NMTOKEN"> <xsd:attribute name="dependency" use="optional" default="required"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="required"/> <xsd:enumeration value="optional"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="defaultValue" type="xsd:token" use="optional"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:complexType name="outputPortsType"> <xsd:sequence> <xsd:element name="outputPort" type="outputPortType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="outputPortType">
Haleplidis Standards Track [Page 24]
RFC 7408 ForCES Model Extension November 2014
<xsd:sequence> <xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element ref="synopsis"/> <xsd:element name="product" type="portProductType"/> <xsd:element ref="description" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="group" type="xsd:boolean" use="optional" default="0"/> </xsd:complexType> <xsd:complexType name="portProductType"> <xsd:sequence> <xsd:element name="frameProduced" minOccurs="0"> <xsd:complexType> <xsd:sequence> <!-- ref must refer to a name of a defined frame type --> <xsd:element name="ref" type="xsd:NMTOKEN" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="metadataProduced" minOccurs="0"> <xsd:complexType> <xsd:choice maxOccurs="unbounded"> <!-- ref must refer to a name of a defined metadata --> <xsd:element name="ref" type="metadataOutputRefType"/> <xsd:element name="one-of" type="metadataOutputChoiceType"/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="metadataOutputChoiceType"> <xsd:choice minOccurs="2" maxOccurs="unbounded"> <!-- ref must refer to a name of a defined metadata --> <xsd:element name="ref" type="xsd:NMTOKEN"/> <xsd:element name="one-of" type="metadataOutputChoiceType"/> <xsd:element name="metadataSet" type="metadataOutputSetType"/> </xsd:choice> </xsd:complexType> <xsd:complexType name="metadataOutputSetType"> <xsd:choice minOccurs="2" maxOccurs="unbounded"> <!-- ref must refer to a name of a defined metadata --> <xsd:element name="ref" type="metadataOutputRefType"/> <xsd:element name="one-of" type="metadataOutputChoiceType"/>
IANA has registered a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
URI: The URI for this namespace is:
urn:ietf:params:xml:ns:forces:lfbmodel:1.1
Registrant Contact: IESG
XML: none, this is an XML namespace
5. Security Considerations
This specification adds only a few constructs to the initial model defined in [RFC5812], namely, a new event, some new properties, and a way to define optional access types and complex metadata. In addition, this document addresses and clarifies an issue with the inheritance model by introducing the version of the derivedFrom LFB class. These constructs and the update to the inheritance model do not change the nature of the initial model.
Thus, the security considerations defined in [RFC5812] apply to this specification as well, as the changes proposed here are simply constructs to write XML library definitions, as [RFC5812] does. These changes, as well as the clarification of the inheritance issue of the initial model, have no effect on the security semantics of the protocol.
In regard to pervasive monitoring (PM), as discussed in [RFC7258], this specification defines ways to expose more complex information (namely, metadata) exchanged between LFBs and between CEs and FEs and a new event. These changes have very little or no effect in terms of making PM simpler or more effective to an attacker who controls the LFBs. The new metadata might make for slightly more elegant PM, but does not enable any new ways to (ab)use LFBs for PM. The same applies for the new event.
Finally, this document does not provide any protocol specification and, as such, does not specify how information will be transmitted between respective entities. Thus, PM mitigation for a passive attacker that simply wants to eavesdrop on the information exchanged is out of the scope of this document.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, "High Availability within a Forwarding and Control Element Separation (ForCES) Network Element", RFC 7121, February 2014, <http://www.rfc-editor.org/info/rfc7121>.
The author would like to acknowledge Joel Halpern, Jamal Hadi Salim, and Dave Hood for their comments and discussion that helped shape this document for the better. Special acknowledgements to Joel Halpern for resolving the issue with the default values, Adrian Farrel for his AD review, Ben Campbell for his Gen-ART review, and Tom Yu for his security review, all of which improved the quality of this document. Additionally, reviews and comments by the following members of the IESG shaped the final version of this document: Stephen Farrel, Barry Leiba, and Ted Lemon. Finally, the author would like to acknowledge Julian Reschke for input regarding the namespace change issue and Joel Halpern for helping to resolve it.
Author's Address
Evangelos Haleplidis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece