draft-ietf-forces-model-extension-05.txt   rfc7408.txt 
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force (IETF) E. Haleplidis
Internet-Draft University of Patras Request for Comments: 7408 University of Patras
Updates: 5812 (if approved) September 11, 2014 Updates: 5812 November 2014
Intended status: Standards Track Category: Standards Track
Expires: March 15, 2015 ISSN: 2070-1721
ForCES Model Extension Forwarding and Control Element Separation (ForCES) Model Extension
draft-ietf-forces-model-extension-05
Abstract Abstract
This memo extends the Forwarding and Control Element Separation This memo extends the Forwarding and Control Element Separation
(ForCES) model defined in RFC 5812 and updates RFC5812 to allow (ForCES) model defined in RFC 5812 and updates that RFC to allow
complex datatypes for metadata, optional default values for complex data types for metadata, optional default values for data
datatypes, optional access types for structures. It fixes an issue types, and optional access types for structures. It also fixes an
with Logical Functional Block (LFB) inheritance. It also introduces issue with Logical Functional Block (LFB) inheritance and introduces
two new features a new event condition BecomesEqualTo and LFB two new features: a new event condition called eventBecomesEqualTo
properties. The changes introduced in this memo do not alter the and LFB properties. The changes introduced in this memo do not alter
protocol and retain backward compatibility with older LFB models. the protocol and retain backward compatibility with older LFB models.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 15, 2015. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language ......................................3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology ................................................3
2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 3 2. ForCES Model Extensions .........................................3
2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 3 2.1. Complex Data Types for Metadata ............................3
2.2. Optional Default Value for Datatypes . . . . . . . . . . 5 2.2. Optional Default Values for Data Types .....................5
2.3. Optional Access Type for Structs . . . . . . . . . . . . 8 2.3. Optional Access Types for Structs ..........................8
2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 11 2.4. New Event Condition: eventBecomesEqualTo ..................11
2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 12 2.5. LFB Properties ............................................12
2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 14 2.6. LFB Class Inheritance .....................................14
2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 15 2.7. Enhancing XML Validation ..................................15
3. XML Extension Schema for LFB Class Library Documents . . . . 15 3. XML Extension Schema for LFB Class Library Documents ...........15
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 4. IANA Considerations ............................................29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5. Security Considerations ........................................29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. References .....................................................30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Normative References ......................................30
7.1. Normative References . . . . . . . . . . . . . . . . . . 30 6.2. Informative References ....................................30
7.2. Informative References . . . . . . . . . . . . . . . . . 30 Acknowledgements ..................................................31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address ..................................................31
1. Introduction 1. Introduction
The ForCES Model [RFC5812] presents a formal way to define Forwarding The ForCES model [RFC5812] presents a formal way to define Forwarding
Elements (FE) Logical Function Blocks (LFBs) using the eXtensible Element (FE) Logical Functional Blocks (LFBs) using the eXtensible
Markup Language (XML). [RFC5812] has been published a more than two Markup Language (XML). [RFC5812] was published several years before
years and current experience in its use has demonstrated need for this document, and experience with its use has demonstrated the need
adding new and changing existing modeling concepts. to add new modeling concepts and change existing ones.
Specifically this document updates the ForCES Model [RFC5812] to Specifically, this document updates the ForCES model [RFC5812] to
allow complex datatypes for metadata (Section 2.1), optional default allow complex data types for metadata (Section 2.1), optional default
values for datatypes (Section 2.2), optional access types for values for data types (Section 2.2), and optional access types for
structures (Section 2.3) and fixes an issue with LFB class structures (Section 2.3). It also fixes an issue with LFB class
inheritance (Section 2.6). Additionally the document introduces two inheritance (Section 2.6). Additionally, the document introduces two
new features, a new event condition BecomesEqualTo (Section 2.4) and new features: a new event condition named eventBecomesEqualTo
LFB properties (Section 2.5). (Section 2.4) and LFB properties (Section 2.5).
These extensions are an update to the ForCES model [RFC5812] and do These extensions are an update to the ForCES model [RFC5812] and do
not require any changes on the ForCES protocol [RFC5810] as they are not require any changes to the ForCES protocol [RFC5810] as they are
simply changes of the schema definition. Additionally backward simply changes to the schema definition. Additionally, backward
compatibility is ensured as XML libraries produced with the earlier compatibility is ensured as XML libraries produced with the earlier
schema are still valid with the new one. In order for XML libraries schema are still valid with the new one. In order for XML libraries
produced by the new schema to be compatible with existing ForCES produced by the new schema to be compatible with existing ForCES
implementations, the XML libraries MUST NOT include any of the implementations, the XML libraries MUST NOT include any of the
features described in this document. features described in this document.
Extensions to the schema and excerpts of the schema include the tags Extensions to the schema and excerpts of the schema include the tags
<!-- Extension RFC XXXX --> and <!-- /Extension RFC XXXX --> which <!-- Extension RFC 7408 --> and <!-- /Extension RFC 7408 -->, which
designates the beginning and ending of extension text specified by designate the beginning and ending of extension text specified by
this document in respect to the original ForCES Model [RFC5812] this document in respect to the schema in the original ForCES model
schema. [RFC5812].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Definitions 1.2. Terminology
This document uses the terminology defined in the ForCES Model in This document uses the terminology defined in the ForCES model
[RFC5812]. In particular, the reader is expected to be familiar with [RFC5812]. In particular, the reader is expected to be familiar with
the following terms: the following terms:
FE Model FE Model
LFB (Logical Functional Block) Class (or type) LFB (Logical Functional Block) Class (or type)
LFB Instance LFB Instance
LFB Model LFB Model
skipping to change at page 3, line 46 skipping to change at page 3, line 43
Attribute Attribute
LFB Metadata LFB Metadata
ForCES Component ForCES Component
LFB Class Library LFB Class Library
2. ForCES Model Extensions 2. ForCES Model Extensions
2.1. Complex datatypes for Metadata 2.1. Complex Data Types for Metadata
Section 4.6. (Element for Metadata Definitions) in the ForCES Model Section 4.6 ("<metadataDefs> Element for Metadata Definitions") of
[RFC5812] limits the datatype use in metadata to only atomic types. the ForCES model [RFC5812] limits the data type use in metadata to
Figure 1 shows the xml schema excerpt where only typeRef and atomic only atomic types. Figure 1 shows the XML schema excerpt where only
are allowed for a metadata definition. typeRef and atomic are allowed for a metadata definition.
<xsd:complexType name="metadataDefsType"> <xsd:complexType name="metadataDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded"> <xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/> <xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:choice> <xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/> <xsd:element name="atomic" type="atomicType"/>
</xsd:choice> </xsd:choice>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
Figure 1: Initial MetadataDefType Definition in the schema Figure 1: Initial metadataDefsType Definition in the Schema
However there are cases where complex metadata are used in the However, there are cases where complex metadata are used in the
datapath, for example two simple use cases can be seen in the datapath: for example, two simple use cases are described in version
OpenFlow 1.1 specification [OpenFlowSpec1.1] and beyond: 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 1. The Action Set metadata is an array of actions descriptors, which
traverses the processing pipeline along with the packet data. traverses the processing pipeline along with the packet data.
2. When a packet is received from a controller it may be accompanied 2. When a packet is received from a controller, it may be
by a list of actions, as metadata, to be performed on it prior to accompanied by a list of actions, as metadata, to be performed on
being sent on the processing pipeline. This list of actions is it prior to being sent on the processing pipeline. This list of
also an array. actions is also an array.
With this extension (Figure 2), complex data types are also allowed, With the extension shown in Figure 2, complex data types are also
specifically structs and arrays as metadata. The key declarations allowed, specifically structs and arrays as metadata. The key
are required to check for validity of content keys in arrays and declarations are required to check for validity of content keys in
componentIDs in structs. arrays and componentIDs in structs.
<xsd:complexType name="metadataDefsType"> <xsd:complexType name="metadataDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded"> <xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/> <xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:choice> <xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/> <xsd:element name="atomic" type="atomicType"/>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:element name="array" type="arrayType"> <xsd:element name="array" type="arrayType">
<xsd:key name="contentKeyID1"> <xsd:key name="contentKeyID1">
<xsd:selector xpath="lfb:contentKey"/> <xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/> <xsd:field xpath="@contentKeyID"/>
</xsd:key> </xsd:key>
</xsd:element> </xsd:element>
<xsd:element name="struct" type="structType"> <xsd:element name="struct" type="structType">
<xsd:key name="structComponentID1"> <xsd:key name="structComponentID1">
<xsd:selector xpath="lfb:component"/> <xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
</xsd:element> </xsd:element>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:choice> </xsd:choice>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
Figure 2: New MetadataDefType Definition for the schema Figure 2: New metadataDefsType Definition in the Schema
2.2. Optional Default Value for Datatypes 2.2. Optional Default Values for Data Types
In the original schema, default values can only be defined for In the original schema, default values can only be defined for data
datatypes defined inside LFB components and not inside structures or types defined inside LFB components and not inside structures or
arrays. Therefore default values of datatypes that are constantly arrays. Therefore, default values for data types that are constantly
being reused, e.g. counters with default value of 0, have to be being reused, e.g., counters with default value of 0, have to be
constantly respecified. Additionally, datatypes inside complex constantly respecified. Additionally, data types inside complex data
datatypes cannot be defined with a default value, e.g. a counter types cannot be defined with a default value, e.g., a counter inside
inside a struct that has a default value of 0. a struct that has a default value of 0.
This extension allows the option to add default values to datatypes. This extension allows the option to add default values to data types.
These datatypes can then be referenced as simple components or within These data types can then be referenced as simple components or
complex datatypes such as structs. A simple use case would be to within complex data types such as structs. A simple use case would
have a struct component where one of the components is a counter be to have a struct component where one of the components is a
which the default value would be zero. To achieve that the counter counter with a default value of zero. To achieve that, the counter
must first be defined as a datatype with the required default value must first be defined as a data type with the required default value
and then referenced in the struct. Default values MUST adhere the and then referenced in the struct. Default values MUST adhere the
following formal restrictions: following formal restrictions:
1. Default Values MUST be ignored if the data type is not an atomic 1. Default values MUST be ignored if the data type is not an atomic
or a base data type. or a base data type.
2. When a datatype X with default value A is referenced from a 2. When a data type X with default value A is referenced from a data
datatype Y with a default value B, the default value of the type Y with a default value B, the default value of the data type
datatype that references overrides the referenced default value, that references overrides the referenced default value, e.g., in
e.g. in this case Y's default value will be B. this case, Y's default value will be B.
3. Default Values of LFB components overrides any default value 3. Default values of LFB components override any default value
specified from the dataTypeDef definition. specified from the dataTypeDef definition.
4. Default Values of datatypes reference in capabilities or metadata 4. Default values of data types referenced in capabilities or
MUST be ignored. metadata MUST be ignored.
This extension simply appends to the definition of the This extension simply adds to the definition of dataTypeDefsType in
dataTypeDefsType in the XML schema from Figure 3 to Figure 4 to allow the XML schema shown in Figure 3 to allow default values for
default values to dataTypeDefsType. dataTypeDefsType. The new definition is shown in Figure 4.
<xsd:complexType name="dataTypeDefsType"> <xsd:complexType name="dataTypeDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded"> <xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN" <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
Figure 3: Initial Excerpt of dataTypeDefsType Definition in the Figure 3: Initial Excerpt of dataTypeDefsType Definition in the
schema Schema
<xsd:complexType name="dataTypeDefsType"> <xsd:complexType name="dataTypeDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded"> <xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN" <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:element name="defaultValue" type="xsd:token" <xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/> minOccurs="0"/>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
Figure 4: New Excerpt of dataTypeDefsType Definition in the schema Figure 4: New Excerpt of dataTypeDefsType Definition in the Schema
Examples of using default values is depicted in Figure 5. Examples of using default values is depicted in Figure 5.
<dataTypeDef> <dataTypeDef>
<name>ZeroCounter</name> <name>ZeroCounter</name>
<synopsis>A counter with default 0</synopsis> <synopsis>A counter with default 0</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
<defaultValue>0</defaultValue> <defaultValue>0</defaultValue>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>CounterValues</name> <name>CounterValues</name>
<synopsis>Example default values in struct</synopsis> <synopsis>Example default values in struct</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>GoodPacketCoutner</name> <name>GoodPacketCounter</name>
<synopsis>A counter for good packets</synopsis> <synopsis>A counter for good packets</synopsis>
<typeRef>ZeroCounter</typeRef> <typeRef>ZeroCounter</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>BadPacketCoutner</name> <name>BadPacketCounter</name>
<synopsis>A counter for bad packets</synopsis> <synopsis>A counter for bad packets</synopsis>
<typeRef>ZeroCounter</typeRef> <typeRef>ZeroCounter</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
Figure 5: Example of optional default values Figure 5: Example of Optional Default Values
2.3. Optional Access Type for Structs 2.3. Optional Access Types for Structs
In the original schema, the access type can only be defined on In the original schema, the access type can only be defined on
components of an LFB and not on components within structs or arrays. 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 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 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 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 components is a counter with an access type that could be read-reset
read-only, e.g. a read-reset or a read-only counter inside a struct. 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 This extension allows the definition of the access type for a struct
component either in the datatype definitions or in the LFB component component either in the data type definitions or in the LFB component
definitions. definitions.
When optional access type for components within a struct are defined, When optional access types for components within a struct are
these components's access type MUST override the access type of the defined, the access types for these components MUST override the
struct. For example if a struct has an access type of read-write but access type of the struct. For example, if a struct has an access
has a component that is a read-only counter, the counter's access type of read-write but has a component that is a read-only counter,
type MUST be read-only. the counter's access type MUST be read-only.
The access type for a component in a capability is always read-only Per [RFC5812], the access type for a component in a capability is
per [RFC5812]. If an access type is provided for a component in a 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 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 type is provided for a struct in a metadata, the access type MUST be
ignored. ignored.
This extension alters the definition of the struct in the xml schema This extension alters the definition of the struct in the XML schema
from Figure 6 to Figure 7. from the initial definition shown in Figure 6 to the new shown in
Figure 7.
<xsd:complexType name="structType"> <xsd:complexType name="structType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN" <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded"> <xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/> <xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="componentID" type="xsd:unsignedInt" <xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Figure 6: Initial XML for the Struct Definition in the Schema
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<!-- Extension RFC 7408 -->
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<!-- /Extension RFC 7408 -->
<xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/> use="required"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
Figure 6: Initial xml for the struct definition in the schema Figure 7: New XML for the Struct Definition in the Schema
<xsd:complexType name="structType">
<xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence>
<!-- Extension RFC XXXX -->
<xsd:attribute name="access" use="optional"
default="read-write">
<xsd:simpleType>
<xsd:list itemType="accessModeType"/>
</xsd:simpleType>
</xsd:attribute>
<!-- /Extension RFC XXXX -->
<xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Figure 7: New xml for the struct definition in the schema An example of using optional access types for structs is depicted in
Figure 8.
An example of using optional access types for structs can be depicted <component componentID="1" access="read-write">
in Figure 8 <name>PacketFlows</name>
<component componentID="1" access="read-write"> <synopsis>Packet Flows, match and counter</synopsis>
<name>PacketFlows</name> <struct>
<synopsis>Packet Flows, match and counter</synopsis> <component componentID="1">
<struct> <name>FlowMatch</name>
<component componentID="1"> <synopsis>Flow Match</synopsis>
<name>FlowMatch</name> <typeRef>MatchType</typeRef>
<synopsis>Flow Match</synopsis> </component>
<typeRef>MatchType</typeRef> <component componentID="2" access="read-only">
</component> <name>MatchCounter</name>
<component componentID="2" access="read-only"> <synopsis>Packets matching the flow match</synopsis>
<name>MatchCounter</name> <typeRef>ZeroCounter</typeRef>
<synopsis>Packets matching the flow match</synopsis> </component>
<typeRef>ZeroCounter</typeRef> </struct>
</component> </component>
</struct>
</component>
Figure 8: Example of optional access types for struct Figure 8: Example of Optional Access Types for Struct
2.4. New Event Condition: BecomesEqualTo 2.4. New Event Condition: eventBecomesEqualTo
This extensions adds one more event condition in the model schema, This extension adds one more event condition in the model schema,
that of BecomesEqualTo. The difference between Greater Than and Less eventBecomesEqualTo. eventBecomesEqualTo is different from
Than, is that when the value becomes exactly that of the eventGreaterThan and eventLessThan because the event is triggered
BecomesEqualTo, the event is triggered. This event condition is when the value is exactly that of the eventBecomesEqualTo threshold.
particularly useful when there is a need to monitor one or more This event condition is particularly useful when there is a need to
states of an LFB or the FE. For example in the CE High Availability monitor one or more states of an LFB or the FE. For example, in the
(CEHA) [RFC7121] RFC it may be useful for the master CE to know which Control Element High Availability (CEHA) document [RFC7121], it may
backup CEs have just become associated in order to connect to them be useful for the master CE to know which backup CEs have just become
and begin synchronizing the state of the FE. The master CE could associated in order to connect to them and begin synchronizing the
always poll for such information but getting such an event will speed state of the FE. The master CE could always poll for such
up the process and the event may be useful in other cases as well for information, but getting such an event will speed up the process, and
monitoring state. 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 The event MUST be triggered only when the value of the targeted
component becomes equal to the event condition value. component becomes equal to the event condition value.
Implementations MUST NOT generate subsequent events while the Implementations MUST NOT generate subsequent events while the
targeted component's value remains equal to the event condition's targeted component's value remains equal to the event condition's
value. value.
The BecomesEqualTo is appended to the schema as follows: eventBecomesEqualTo is appended to the schema as shown in Figure 9.
<xsd:element name="eventBecomesEqualTo" <xsd:element name="eventBecomesEqualTo"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
Figure 9: New Excerpt of BecomesEqualTo event condition definition in Figure 9: New Excerpt of eventBecomesEqualTo Event Condition
the schema Definition in the Schema
It can become useful for the CE to be notified when the state has 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 changed once the eventBecomesEqualTo event has been triggered, e.g.,
may need to know when a backup CE has lost association. Such an the CE may need to know when a backup CE has lost association. Such
event can be generated either by defining a second event on the same an event can be generated either by defining a second event on the
component, namely an Event Changed, or by simply reusing same component (namely, an eventChanged) or by simply reusing
BecomesEqualTo and use event properties, in particular event eventBecomesEqualTo and using event properties (in particular,
hysteresis. We append the following definition for the event eventHysteresis). We append the following definition to the
hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the eventHysteresis defined in Section 4.8.5.2 of [RFC5812], with V being
hysteresis value: the hysteresis value:
o For an <eventBecomesEqualTo/> condition, after the last o For an eventBecomesEqualTo condition, after the last notification,
notification a new <eventBecomesEqualTo/> notification MUST be a new eventBecomesEqualTo notification MUST be generated only one
generated only one time once the value has changed by +/- V. time once the value has changed by +/- V.
For example using the value of 1 for V, will in effect create a 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 singular event that will notify the CE that the value has changed by
at least 1. at least 1.
A developer of a CE should consider using count or time filtering to 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 avoid being overrun by messages, e.g., in the case of rapid state
changes. changes.
2.5. LFB Properties 2.5. LFB Properties
The previous model definition specifies properties for components of The previous model definition specifies properties for components of
LFBs. Experience has shown that, at least for debug reasons, it LFBs. Experience has shown that, at least for debug reasons, it
would be useful to have statistics per LFB instance to monitor sent would be useful to have statistics per LFB instance to monitor sent
and received messages and errors in communication between CE and FE. and received messages and errors in communication between a CE and
These properties are read-only. FE. These properties are read-only.
In order to avoid ambiguity on protocol path semantics, this document In order to avoid ambiguity on protocol path semantics, this document
specifies that the LFB component with ID 0 specifically MUST refer to specifies that the LFB componentID 0 specifically MUST refer to LFB
LFB properties and ID 0 MUST NOT be used for any component properties and ID 0 MUST NOT be used for any component definition.
definition. This disallowment is backwards compatible as no known This disallowance is backward compatible as no known LFB definition
LFB definition uses LFB component with ID 0. Any command with a path uses an LFB componentID 0. Any command with a path starting from LFB
starting from LFB component 0 refers to LFB properties. The componentID 0 refers to LFB properties. Figures 10 and 11 illustrate
following change in the xml schema disallows usage of LFB component the change in the XML schema that disallows usage of LFB componentID
0: 0:
<xsd:attribute name="componentID" type="xsd:unsignedInt" <xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"> use="required">
Figure 10: Initial xml for LFB Component IDs Figure 10: Initial XML for LFB componentIDs
<!-- Extension Added restriction to component ID -->
<xsd:attribute name="componentID" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:unsignedInt">
<xsd:minExclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<!-- End of extension -->
Figure 11: New xml to disallow usage of 0 as LFB Component <!-- Extension added restriction to componentID -->
<xsd:attribute name="componentID" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:unsignedInt">
<xsd:minExclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<!-- End of extension -->
The following datatype definitions are to be used as properties for Figure 11: New XML to Disallow Usage of LFB componentID 0
The following data type definitions are to be used as properties for
LFB instances. LFB instances.
<dataTypeDef> <dataTypeDef>
<name>LFBProperties</name> <name>LFBProperties</name>
<synopsis>LFB Properties definition</synopsis> <synopsis>LFB Properties definition</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>PacketsSentToCE</name> <name>PacketsSentToCE</name>
<synopsis>Packets sent to CE</synopsis> <synopsis>Packets sent to CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>SentErrorPacketsToCE</name> <name>SentErrorPacketsToCE</name>
<synopsis>Error Packets sent to CE</synopsis> <synopsis>Error Packets sent to CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>BytesSentToCE</name> <name>BytesSentToCE</name>
<synopsis>Bytes sent to CE</synopsis> <synopsis>Bytes sent to CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>SentErrorBytesToCE</name> <name>SentErrorBytesToCE</name>
<synopsis>Error Bytes sent to CE</synopsis> <synopsis>Error Bytes sent to CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>PacketsReceivedFromCE</name> <name>PacketsReceivedFromCE</name>
<synopsis>Packets received from CE</synopsis> <synopsis>Packets received from CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component>
<component componentID="6">
<name>ReceivedErrorPacketsFromCE</name>
<synopsis>Error Packets received from CE</synopsis>
<typeRef>uint32</typeRef>
</component> </component>
<component componentID="7"> <component componentID="6">
<name>BytesReceivedFromCE</name> <name>ReceivedErrorPacketsFromCE</name>
<synopsis>Bytesreceived from CE</synopsis> <synopsis>Error Packets received from CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="8"> <component componentID="7">
<name>ReceivedErrorBytesFromCE</name> <name>BytesReceivedFromCE</name>
<synopsis>Error Bytes received from CE</synopsis> <synopsis>Bytes received from CE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> <component componentID="8">
</dataTypeDef> <name>ReceivedErrorBytesFromCE</name>
<synopsis>Error Bytes received from CE</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
Properties for LFB instances Figure 12: Properties for LFB Instances
2.6. LFB class inheritance 2.6. LFB Class Inheritance
The ForCES model [RFC5812] allows inheritance for LFB classes. The ForCES model [RFC5812] allows inheritance for LFB classes.
However the xml schema defines only the LFB class from which an LFB However, the XML schema defines only the LFB class from which an LFB
class inherits. Recent implementations have identified an issue class inherits. Recent implementations have identified an issue
where ambiguity rises when different versions of the parent LFB class where ambiguity rises when different versions of the parent LFB class
exists. This document augments the derivedFrom part of the LFB class exist. This document augments the derivedFrom part of the LFB class
definition with an optional version attribute when the derivedFrom definition with an optional version attribute when the derivedFrom
field is used. field is used.
Having the version attribute as optional was a decision based on the Having the version attribute as optional was a decision based on the
need to maintain backwards compatibility with the XML schema defined need to maintain backward compatibility with the XML schema defined
in [RFC5812]. However if the version is omitted then the derivedFrom in [RFC5812]. However, if the version is omitted, then derivedFrom
will always specify the first version of the parent LFB class, which will always specify the first version of the parent LFB class, which
usually is version 1.0. usually is version 1.0.
This extension alters the definition of the derivedFrom in the xml This extension alters the definition of derivedFrom in the XML schema
schema from Figure 12 to Figure 13. from the initial definition shown in Figure 13 to the new shown in
Figure 14.
<xsd:element name="derivedFrom" minOccurs="0"/> <xsd:element name="derivedFrom" minOccurs="0"/>
Figure 12: Initial xml for the LFB class inheritance Figure 13: Initial XML for LFB Class Inheritance
<xsd:element name="derivedFrom" minOccurs="0">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="version"
type="versionType" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
Figure 13: New xml for the LFB class inheritance <xsd:element name="derivedFrom" minOccurs="0">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="version"
type="versionType" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
An example of the use of the version attribute is given in Figure 14 Figure 14: New XML for LFB Class Inheritance
<derivedFrom version="1.0">EtherPHYCop</derivedFrom> An example of the use of the version attribute is given in Figure 15.
Figure 14: Example of use of new xml for LFB class Inheritance <derivedFrom version="1.0">EtherPHYCop</derivedFrom>
Figure 15: Example of Use of New XML for LFB Class Inheritance
2.7. Enhancing XML Validation 2.7. Enhancing XML Validation
As specified earlier this is not an extension but an enhancement of As specified earlier, this is not an extension but an enhancement of
the schema to provide additional validation rules. This includes the schema to provide additional validation rules. This includes
adding new key declarations to provide uniqueness as defined by the adding new key declarations to provide uniqueness as defined by the
ForCES Model [RFC5812]. Such validations work only on within the ForCES model [RFC5812]. Such validations work only within the same
same xml file. XML file.
This document introduces the following validation rules that did not This document introduces the following validation rules that did not
exist in the original schema in [RFC5812]: exist in the original schema in [RFC5812]:
1. Each metadata ID must be unique. 1. Each metadataID must be unique.
2. LFB Class IDs must be unique. 2. LFBClassIDs must be unique.
3. Component ID, Capability ID and Event Base ID must be unique per 3. componentID, capabilityID, and Event baseID must be unique per
LFB. LFB.
4. Event IDs must be unique per LFB. 4. eventIDs must be unique per LFB.
5. Special Values in Atomic datatypes must be unique per atomic 5. Special values in atomic data types must be unique per atomic
datatype. data type.
3. XML Extension Schema for LFB Class Library Documents 3. XML Extension Schema for LFB Class Library Documents
This section includes the new XML Schema. Note that the namespace This section includes the new XML schema. Note that the namespace
number has been updated from 1.0 to 1.1 number has been updated from 1.0 to 1.1.
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.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1" xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.1" xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.1" targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:annotation> <xsd:annotation>
<xsd:documentation xml:lang="en"> <xsd:documentation xml:lang="en">
Schema for Defining LFB Classes and associated types Schema for Defining LFB Classes and associated types
skipping to change at page 17, line 45 skipping to change at page 18, line 4
<xsd:sequence> <xsd:sequence>
<xsd:element name="dataTypeDef" maxOccurs="unbounded"> <xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN" <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" <xsd:element ref="description"
minOccurs="0"/> minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:element name="defaultValue" type="xsd:token" <xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/> minOccurs="0"/>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<!-- Predefined (built-in) atomic data-types are: char, uchar, <!-- Predefined (built-in) atomic data-types are: char, uchar,
int16, uint16, int32, uint32, int64, uint64, string[N], string, int16, uint16, int32, uint32, int64, uint64, string[N], string,
byte[N], boolean, octetstring[N], float32, float64 --> byte[N], boolean, octetstring[N], float32, float64 -->
<xsd:group name="typeDeclarationGroup"> <xsd:group name="typeDeclarationGroup">
<xsd:choice> <xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/> <xsd:element name="atomic" type="atomicType"/>
<xsd:element name="array" type="arrayType"> <xsd:element name="array" type="arrayType">
skipping to change at page 18, line 15 skipping to change at page 18, line 23
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<!-- Predefined (built-in) atomic data-types are: char, uchar, <!-- Predefined (built-in) atomic data-types are: char, uchar,
int16, uint16, int32, uint32, int64, uint64, string[N], string, int16, uint16, int32, uint32, int64, uint64, string[N], string,
byte[N], boolean, octetstring[N], float32, float64 --> byte[N], boolean, octetstring[N], float32, float64 -->
<xsd:group name="typeDeclarationGroup"> <xsd:group name="typeDeclarationGroup">
<xsd:choice> <xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/> <xsd:element name="atomic" type="atomicType"/>
<xsd:element name="array" type="arrayType"> <xsd:element name="array" type="arrayType">
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<!--declare keys to have unique IDs --> <!-- declare keys to have unique IDs -->
<xsd:key name="contentKeyID"> <xsd:key name="contentKeyID">
<xsd:selector xpath="lfb:contentKey"/> <xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/> <xsd:field xpath="@contentKeyID"/>
</xsd:key> </xsd:key>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:element> </xsd:element>
<xsd:element name="struct" type="structType"> <xsd:element name="struct" type="structType">
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<!-- key declaration to make componentIDs <!-- key declaration to make componentIDs
unique in a struct --> unique in a struct -->
<xsd:key name="structComponentID"> <xsd:key name="structComponentID">
<xsd:selector xpath="lfb:component"/> <xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:element> </xsd:element>
<xsd:element name="union" type="structType"/> <xsd:element name="union" type="structType"/>
<xsd:element name="alias" type="typeRefNMTOKEN"/> <xsd:element name="alias" type="typeRefNMTOKEN"/>
</xsd:choice> </xsd:choice>
</xsd:group> </xsd:group>
<xsd:simpleType name="typeRefNMTOKEN"> <xsd:simpleType name="typeRefNMTOKEN">
<xsd:restriction base="xsd:token"> <xsd:restriction base="xsd:token">
<xsd:pattern value="\c+"/> <xsd:pattern value="\c+"/>
<xsd:pattern value="string\[\d+\]"/> <xsd:pattern value="string\[\d+\]"/>
<xsd:pattern value="byte\[\d+\]"/> <xsd:pattern value="byte\[\d+\]"/>
<xsd:pattern value="octetstring\[\d+\]"/> <xsd:pattern value="octetstring\[\d+\]"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:complexType name="atomicType"> <xsd:complexType name="atomicType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/> <xsd:element name="baseType" type="typeRefNMTOKEN"/>
<xsd:element name="rangeRestriction" <xsd:element name="rangeRestriction"
type="rangeRestrictionType" minOccurs="0"/> type="rangeRestrictionType" minOccurs="0"/>
<xsd:element name="specialValues" type="specialValuesType" <xsd:element name="specialValues" type="specialValuesType"
minOccurs="0"> minOccurs="0">
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:key name="SpecialValue"> <xsd:key name="SpecialValue">
<xsd:selector xpath="specialValue"/> <xsd:selector xpath="specialValue"/>
<xsd:field xpath="@value"/> <xsd:field xpath="@value"/>
</xsd:key> </xsd:key>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="rangeRestrictionType"> <xsd:complexType name="rangeRestrictionType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="allowedRange" maxOccurs="unbounded"> <xsd:element name="allowedRange" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:attribute name="min" type="xsd:integer" <xsd:attribute name="min" type="xsd:integer"
use="required"/> use="required"/>
<xsd:attribute name="max" type="xsd:integer" <xsd:attribute name="max" type="xsd:integer"
skipping to change at page 20, line 31 skipping to change at page 20, line 39
<xsd:element name="component" maxOccurs="unbounded"> <xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" <xsd:element ref="description"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/> <xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:attribute name="access" use="optional" <xsd:attribute name="access" use="optional"
default="read-write"> default="read-write">
<xsd:simpleType> <xsd:simpleType>
<xsd:list itemType="accessModeType"/> <xsd:list itemType="accessModeType"/>
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:attribute name="componentID" type="xsd:unsignedInt" <xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"/> use="required"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="metadataDefsType"> <xsd:complexType name="metadataDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded"> <xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/> <xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" <xsd:element ref="description"
skipping to change at page 21, line 10 skipping to change at page 21, line 19
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="metadataID" type="xsd:integer"/> <xsd:element name="metadataID" type="xsd:integer"/>
<xsd:element ref="description" <xsd:element ref="description"
minOccurs="0"/> minOccurs="0"/>
<xsd:choice> <xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/> <xsd:element name="atomic" type="atomicType"/>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:element name="array" type="arrayType"> <xsd:element name="array" type="arrayType">
<!--declare keys to have unique IDs --> <!--declare keys to have unique IDs -->
<xsd:key name="contentKeyID1"> <xsd:key name="contentKeyID1">
<xsd:selector xpath="lfb:contentKey"/> <xsd:selector xpath="lfb:contentKey"/>
<xsd:field xpath="@contentKeyID"/> <xsd:field xpath="@contentKeyID"/>
</xsd:key> </xsd:key>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:element> </xsd:element>
<xsd:element name="struct" type="structType"> <xsd:element name="struct" type="structType">
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<!-- key declaration to make componentIDs <!-- key declaration to make componentIDs
unique in a struct --> unique in a struct -->
<xsd:key name="structComponentID1"> <xsd:key name="structComponentID1">
<xsd:selector xpath="lfb:component"/> <xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
</xsd:element> </xsd:element>
</xsd:choice> </xsd:choice>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="LFBClassDefsType"> <xsd:complexType name="LFBClassDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="LFBClassDef" maxOccurs="unbounded"> <xsd:element name="LFBClassDef" maxOccurs="unbounded">
skipping to change at page 26, line 33 skipping to change at page 26, line 42
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="defaultValue" type="xsd:token" <xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/> minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="access" use="optional" <xsd:attribute name="access" use="optional"
default="read-write"> default="read-write">
<xsd:simpleType> <xsd:simpleType>
<xsd:list itemType="accessModeType"/> <xsd:list itemType="accessModeType"/>
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
<!-- Extension Added restriction to component ID --> <!-- Extension added restriction to componentID -->
<xsd:attribute name="componentID" use="required"> <xsd:attribute name="componentID" use="required">
<xsd:simpleType> <xsd:simpleType>
<xsd:restriction base="xsd:unsignedInt"> <xsd:restriction base="xsd:unsignedInt">
<xsd:minExclusive value="0"/> <xsd:minExclusive value="0"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
<!-- End of extension --> <!-- End of extension -->
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
skipping to change at page 27, line 44 skipping to change at page 28, line 4
<xsd:element ref="eventCondition"/> <xsd:element ref="eventCondition"/>
<xsd:element name="eventReports" <xsd:element name="eventReports"
type="eventReportsType" minOccurs="0"/> type="eventReportsType" minOccurs="0"/>
<xsd:element ref="description" <xsd:element ref="description"
minOccurs="0"/> minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="eventID" type="xsd:integer" <xsd:attribute name="eventID" type="xsd:integer"
use="required"/> use="required"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="baseID" type="xsd:integer" <xsd:attribute name="baseID" type="xsd:integer"
use="optional"/> use="optional"/>
</xsd:complexType> </xsd:complexType>
<!-- the substitution group for the event conditions --> <!-- the substitution group for the event conditions -->
<xsd:element name="eventCondition" abstract="true"/> <xsd:element name="eventCondition" abstract="true"/>
<xsd:element name="eventCreated" <xsd:element name="eventCreated"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<xsd:element name="eventDeleted" <xsd:element name="eventDeleted"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<xsd:element name="eventChanged" <xsd:element name="eventChanged"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<xsd:element name="eventGreaterThan" <xsd:element name="eventGreaterThan"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<xsd:element name="eventLessThan" <xsd:element name="eventLessThan"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<!-- Extension RFC XXXX --> <!-- Extension RFC 7408 -->
<xsd:element name="eventBecomesEqualTo" <xsd:element name="eventBecomesEqualTo"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<!-- /Extension RFC XXXX --> <!-- /Extension RFC 7408 -->
<xsd:complexType name="eventPathType"> <xsd:complexType name="eventPathType">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="eventPathPart" maxOccurs="unbounded"/> <xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<!-- the substitution group for the event path parts --> <!-- the substitution group for the event path parts -->
<xsd:element name="eventPathPart" type="xsd:string" <xsd:element name="eventPathPart" type="xsd:string"
abstract="true"/> abstract="true"/>
<xsd:element name="eventField" type="xsd:string" <xsd:element name="eventField" type="xsd:string"
substitutionGroup="eventPathPart"/> substitutionGroup="eventPathPart"/>
skipping to change at page 28, line 45 skipping to change at page 29, line 5
<xsd:simpleType name="booleanType"> <xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string"> <xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/> <xsd:enumeration value="0"/>
<xsd:enumeration value="1"/> <xsd:enumeration value="1"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
ForCES LFB XML Schema ForCES LFB XML Schema
4. Acknowledgements 4. IANA Considerations
The author would like to acknowledge Joel Halpern, Jamal Hadi Salim
and Dave Hood for their comments and discussion that helped shape
this document in a better way. 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 the following members of the IESG Stephen
Farrel, Barry Leiba and Ted Lemon for their reviews and comments that
shaped the final version of this document.
5. IANA Considerations
IANA has registered a new XML namespace, as per the guidelines in RFC IANA has registered a new XML namespace, as per the guidelines in RFC
3688 [RFC3688]. 3688 [RFC3688].
URI: The URI for this namespace is URI: The URI for this namespace is:
urn:ietf:params:xml:ns:forces:lfbmodel:1.1 urn:ietf:params:xml:ns:forces:lfbmodel:1.1
Registrant Contact: IESG Registrant Contact: IESG
XML: none, this is an XML namespace XML: none, this is an XML namespace
6. Security Considerations 5. Security Considerations
This specification adds only a few constructs to the initial model This specification adds only a few constructs to the initial model
defined in [RFC5812], namely namely a new event, some new properties defined in [RFC5812], namely, a new event, some new properties, and a
and a way to define optional access types and complex metadata. In way to define optional access types and complex metadata. In
addition this document addresses and clarifies an issue with the addition, this document addresses and clarifies an issue with the
inheritance model by introducing the version of the derivedFrom LFB inheritance model by introducing the version of the derivedFrom LFB
class. These constructs and the inheritance model change do not class. These constructs and the update to the inheritance model do
change the nature of the initial model. not change the nature of the initial model.
Thus the security considerations defined in [RFC5812] apply to this Thus, the security considerations defined in [RFC5812] apply to this
specification as well, as the changes proposed here are simply specification as well, as the changes proposed here are simply
constructs to write XML library definitions, as in [RFC5812]. These constructs to write XML library definitions, as [RFC5812] does.
changes, as well as the clarification of the inheritance issue of the These changes, as well as the clarification of the inheritance issue
initial model, have no effect on the security semantics of the of the initial model, have no effect on the security semantics of the
protocol. protocol.
In regards to pervasive monitoring (PM), as discussed in [RFC7258], In regard to pervasive monitoring (PM), as discussed in [RFC7258],
this specification defines ways to expose more complex information, this specification defines ways to expose more complex information
namely metadata, exchanged between LFBs and between CEs and FEs and a (namely, metadata) exchanged between LFBs and between CEs and FEs and
new event. These changes have very little or no effect in terms of 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 making PM simpler or more effective to an attacker who controls the
LFBs. The new metadata might make for slightly more elegant PM, but LFBs. The new metadata might make for slightly more elegant PM, but
does not enable any really new way to (ab)use LFBs for PM. The same does not enable any new ways to (ab)use LFBs for PM. The same
applies for the new event. applies for the new event.
Finally, this document does not provide any protocol specification Finally, this document does not provide any protocol specification
and as such does not specifies how information will be transmitted and, as such, does not specify how information will be transmitted
between respective entities, thus PM mitigation for a passive between respective entities. Thus, PM mitigation for a passive
attacker that simply wants to eavesdrop on the information exchanged attacker that simply wants to eavesdrop on the information exchanged
is out of scope. is out of the scope of this document.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010,
<http://www.rfc-editor.org/info/rfc5810>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", RFC Element Separation (ForCES) Forwarding Element Model", RFC
5812, March 2010. 5812, March 2010,
<http://www.rfc-editor.org/info/rfc5812>.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
"High Availability within a Forwarding and Control Element "High Availability within a Forwarding and Control Element
Separation (ForCES) Network Element", RFC 7121, February Separation (ForCES) Network Element", RFC 7121, February
2014. 2014, <http://www.rfc-editor.org/info/rfc7121>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014. Attack", BCP 188, RFC 7258, May 2014,
<http://www.rfc-editor.org/info/rfc7258>.
7.2. Informative References 6.2. Informative References
[OpenFlowSpec1.1] [OpenFlowSpec1.1]
http://www.OpenFlow.org/, "The OpenFlow 1.1 ONF, "OpenFlow Switch Specification", February 2011,
Specification.", <http://www.OpenFlow.org/documents/ <https://www.opennetworking.org/images/stories/downloads/
OpenFlow-spec-v1.1.0.pdf>. sdn-resources/onf-specifications/openflow/
openflow-spec-v1.1.0.pdf>.
Acknowledgements
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 Author's Address
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Department of Electrical and Computer Engineering Department of Electrical and Computer Engineering
Patras 26500 Patras 26500
Greece Greece
Email: ehalep@ece.upatras.gr EMail: ehalep@ece.upatras.gr
 End of changes. 131 change blocks. 
500 lines changed or deleted 519 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/