< draft-ietf-forces-model-extension-03.txt   draft-ietf-forces-model-extension-05.txt >
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force E. Haleplidis
Internet-Draft University of Patras Internet-Draft University of Patras
Updates: 5812 (if approved) July 4, 2014 Updates: 5812 (if approved) September 11, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: January 5, 2015 Expires: March 15, 2015
ForCES Model Extension ForCES Model Extension
draft-ietf-forces-model-extension-03 draft-ietf-forces-model-extension-05
Abstract Abstract
Forwarding and Control Element Separation (ForCES) defines an This memo extends the Forwarding and Control Element Separation
architectural framework and associated protocols to standardize (ForCES) model defined in RFC 5812 and updates RFC5812 to allow
information exchange between the control plane and the forwarding complex datatypes for metadata, optional default values for
plane in a ForCES Network Element (ForCES NE). RFC5812 has defined datatypes, optional access types for structures. It fixes an issue
the ForCES Model that provides a formal way to represent the with Logical Functional Block (LFB) inheritance. It also introduces
capabilities, state, and configuration of forwarding elements within two new features a new event condition BecomesEqualTo and LFB
the context of the ForCES protocol, so that control elements (CEs) properties. The changes introduced in this memo do not alter the
can control the FEs accordingly. More specifically, the model protocol and retain backward compatibility with older LFB models.
describes the logical functions that are present in a forwarding
element (FE), what capabilities these functions support, and how
these functions are or can be interconnected.
RFC5812 has been around for two years and experience in its use has
shown room for small extensions without a need to alter the protocol
while retaining backward compatibility with older xml libraries.
This document update RFC5812 and extends the model to allow complex
datatypes for metadata, optional default values for datatypes,
optional access types for structures and fixes an issue with LFB
inheritance. The document also introduces two new features a new
event condition BecomesEqualTo and LFB properties.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
This Internet-Draft will expire on March 15, 2015.
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
skipping to change at page 2, line 26 skipping to change at page 2, line 14
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. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 4 2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 3
2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4 2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 3
2.2. Optional Default Value for Datatypes . . . . . . . . . . 5 2.2. Optional Default Value for Datatypes . . . . . . . . . . 5
2.3. Optional Access Type for Structs . . . . . . . . . . . . 8 2.3. Optional Access Type for Structs . . . . . . . . . . . . 8
2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 10 2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 11
2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 11 2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 12
2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 13 2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 14
2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 14 2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 15
3. XML Extension Schema for LFB Class Library Documents . . . . 14 3. XML Extension Schema for LFB Class Library Documents . . . . 15
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The ForCES Model [RFC5812] presents a formal way to define FEs The ForCES Model [RFC5812] presents a formal way to define Forwarding
Logical Function Blocks (LFBs) using the eXtensible Markup Language Elements (FE) Logical Function Blocks (LFBs) using the eXtensible
(XML). [RFC5812] has been published a more than two years and Markup Language (XML). [RFC5812] has been published a more than two
current experience in its use has demonstrated need for adding new years and current experience in its use has demonstrated need for
and changing existing modeling concepts. adding new and changing existing modeling concepts.
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 datatypes for metadata (Section 2.1), optional default
values for datatypes (Section 2.2), optional access types for values for datatypes (Section 2.2), optional access types for
structures (Section 2.3) and fixes an issue with LFB class structures (Section 2.3) and 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 BecomesEqualTo (Section 2.4) and
LFB properties (Section 2.5). 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 on the ForCES protocol [RFC5810] as they are
simply changes of the schema definition. Additionally backward simply changes of 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, else the old implementation will features described in this document.
be unable to parse the XML library.
Extensions to the schema and excerpts of the schema include the tags
<!-- Extension RFC XXXX --> and <!-- /Extension RFC XXXX --> which
designates the beginning and ending of extension text specified by
this document in respect to the original ForCES Model [RFC5812]
schema.
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. Definitions
This document uses the terminology defined in the ForCES Model in This document uses the terminology defined in the ForCES Model in
skipping to change at page 4, line 11 skipping to change at page 3, line 50
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 datatypes for Metadata
Section 4.6. (Element for Metadata Definitions) in the ForCES Model Section 4.6. (Element for Metadata Definitions) in the ForCES Model
[RFC5812] limits the datatype use in metadata to only atomic types. [RFC5812] limits the datatype use in metadata to only atomic types.
Figure 1 shows the xml schema excerpt where ony typeRef and atomic Figure 1 shows the xml schema excerpt where only typeRef and atomic
are allowed for a metadata definition. are allowed for a metadata definition.
However there are cases where complex metadata are used in the
datapath, for example two simple use cases can be seen in the
OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond:
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 this extension (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.
<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 MetadataDefType Definition in the schema
However there are cases where complex metadata are used in the
datapath, for example two simple use cases can be seen in the
OpenFlow 1.1 specification [OpenFlowSpec1.1] and beyond:
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 this extension (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.
<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 -->
<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 -->
</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 MetadataDefType Definition for the schema
2.2. Optional Default Value for Datatypes 2.2. Optional Default Value for Datatypes
In the original schema, default values can only be defined for In the original schema, default values can only be defined for
datatypes defined inside LFB components and not inside structures or datatypes defined inside LFB components and not inside structures or
arrays. Therefore default values of datatypes that are constantly arrays. Therefore default values of datatypes 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, datatypes inside complex
datatypes cannot be defined with a default value, e.g. a counter datatypes cannot be defined with a default value, e.g. a counter
inside a struct that has a default value of 0. inside a struct that has a default value of 0.
This extension allows optionally to add default values to atomic and This extension allows the option to add default values to datatypes.
typeref types, whether they are as simple or complex datatypes. A These datatypes can then be referenced as simple components or within
simple use case would be to have a struct component where one of the complex datatypes such as structs. A simple use case would be to
components is a counter which the default value would be zero. have a struct component where one of the components is a counter
which the default value would be zero. To achieve that the counter
This extension alters the definition of the typeDeclarationGroup in must first be defined as a datatype with the required default value
the XML schema from Figure 3 to Figure 4 to allow default values to and then referenced in the struct. Default values MUST adhere the
TypeRef. following formal restrictions:
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> 1. Default Values MUST be ignored if the data type is not an atomic
or a base data type.
Figure 3: Initial Excerpt of typeDeclarationGroup Defintion in the 2. When a datatype X with default value A is referenced from a
schema datatype Y with a default value B, the default value of the
datatype that references overrides the referenced default value,
e.g. in this case Y's default value will be B.
<xsd:sequence> 3. Default Values of LFB components overrides any default value
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> specified from the dataTypeDef definition.
<xsd:element name="DefaultValue" type="xsd:token"
minOccurs="0"/>
</xsd:sequence>
Figure 4: New Excerpt of typeDeclarationGroup Definition in the 4. Default Values of datatypes reference in capabilities or metadata
schema MUST be ignored.
Additionally this document appends to the declaration of the This extension simply appends to the definition of the
AtomicType from Figure 5 to Figure 6 to allow default values to dataTypeDefsType in the XML schema from Figure 3 to Figure 4 to allow
Atomic datatypes. Note that both declarations include the new default values to dataTypeDefsType.
special value validation described in Section 2.7
<xsd:complexType name="atomicType"> <xsd:complexType name="dataTypeDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/> <xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:element name="rangeRestriction" type="rangeRestrictionType" <xsd:complexType>
minOccurs="0"/> <xsd:sequence>
<xsd:element name="specialValues" type="specialValuesType" <xsd:element name="name" type="xsd:NMTOKEN"/>
minOccurs="0"> <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
<!-- Extension --> minOccurs="0"/>
<xsd:key name="SpecialValue"> <xsd:element ref="synopsis"/>
<xsd:selector xpath="specialValue"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:field xpath="@value"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:key> </xsd:sequence>
<!-- /Extension --> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType>
Figure 5: Initial Excerpt of AtomicType Definition in the schema Figure 3: Initial Excerpt of dataTypeDefsType Definition in the
schema
<xsd:complexType name="atomicType"> <xsd:complexType name="dataTypeDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="baseType" type="typeRefNMTOKEN"/> <xsd:element name="dataTypeDef" maxOccurs="unbounded">
<xsd:element name="rangeRestriction" type="rangeRestrictionType" <xsd:complexType>
minOccurs="0"/> <xsd:sequence>
<xsd:element name="specialValues" type="specialValuesType" <xsd:element name="name" type="xsd:NMTOKEN"/>
minOccurs="0"> <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
<!-- Extension --> minOccurs="0"/>
<xsd:key name="SpecialValue"> <xsd:element ref="synopsis"/>
<xsd:selector xpath="specialValue"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:field xpath="@value"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:key> <!-- Extension RFC XXXX -->
<!-- /Extension --> <xsd:element name="defaultValue" type="xsd:token"
</xsd:element> minOccurs="0"/>
<!-- Extension --> <!-- /Extension RFC XXXX -->
<xsd:element name="defaultValue" type="xsd:token" </xsd:sequence>
minOccurs="0"/> </xsd:complexType>
<!-- /Extension --> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType>
Figure 6: New Excerpt of AtomicType Definition in the schema Figure 4: New Excerpt of dataTypeDefsType Definition in the schema
Examples of using default values is depicted in Figure 7. Examples of using default values is depicted in Figure 5.
<dataTypeDef> <dataTypeDef>
<name>Counter Values</name> <name>ZeroCounter</name>
<synopsis>A counter with default 0</synopsis>
<typeRef>uint32</typeRef>
<defaultValue>0</defaultValue>
</dataTypeDef>
<dataTypeDef>
<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>GoodPacketCoutner</name>
<synopsis>A counter for good packets</synopsis> <synopsis>A counter for good packets</synopsis>
<typeRef>uint32</typeRef> <typeRef>ZeroCounter</typeRef>
<DefaultValue>0</DefaultValue>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>BadPacketCoutner</name> <name>BadPacketCoutner</name>
<synopsis>A counter for bad packets</synopsis> <synopsis>A counter for bad packets</synopsis>
<typeRef>uint32</typeRef> <typeRef>ZeroCounter</typeRef>
<DefaultValue>0</DefaultValue>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
Figure 7: Example of optional default values Figure 5: Example of optional default values
2.3. Optional Access Type for Structs 2.3. Optional Access Type 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 in structs or arrays. components of an LFB and not on components within structs or arrays.
However when it's a struct datatype it is not possible to fine-tune That means that when it is a struct datatype it is not possible to
access type per component in the struct. A simple use case would be fine-tune access type per component within the struct. A simple use
to have a read-write struct component where one of the components is case would be to have a read-write struct component where one of the
a counter where the access-type could be read-reset or read-only, components is a counter where the access-type could be read-reset or
e.g. a read-reset or a read-only counter inside a struct. read-only, e.g. a read-reset or a read-only counter inside a struct.
With this extension is it allowed to define the access type for a This extension allows the definition of the access type for a struct
struct component either in the datatype definitions or in the LFB component either in the datatype definitions or in the LFB component
component definitions. definitions.
When the optional access type for a struct component is defined it When optional access type for components within a struct are defined,
MUST override the access type of the struct. The access type for a these components's access type MUST override the access type of the
component in a capability is always read-only per [RFC5812]. If an struct. For example if a struct has an access type of read-write but
access type is provided for a component in a capability it MUST be has a component that is a read-only counter, the counter's access
ignored. Similarly if an access type is provided for a struct in a type MUST be read-only.
metadata it MUST be ignored.
The access type for a component in a capability is always read-only
per [RFC5812]. 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 This extension alters the definition of the struct in the xml schema
from Figure 8 to Figure 9. from Figure 6 to 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"/>
skipping to change at page 8, line 49 skipping to change at page 9, line 30
<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"/> use="required"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
Figure 8: Initial xml for the struct definition in the schema Figure 6: Initial xml for the struct definition in the schema
<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>
<!-- Extension RFC XXXX -->
<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 -->
<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>
Figure 9: New xml for the struct definition in the schema Figure 7: New xml for the struct definition in the schema
An example of using optional access types for structs can be depicted An example of using optional access types for structs can be depicted
in Figure 10 in Figure 8
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>PacketFlows</name> <name>PacketFlows</name>
<synopsis>Packet Flows, match and counter</synopsis> <synopsis>Packet Flows, match and counter</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>FlowMatch</name> <name>FlowMatch</name>
<synopsis>Flow Match</synopsis> <synopsis>Flow Match</synopsis>
<typeRef>MatchType</typeRef> <typeRef>MatchType</typeRef>
</component> </component>
<component componentID="2" access="read-only"> <component componentID="2" access="read-only">
<name>MatchCounter</name> <name>MatchCounter</name>
<synopsis>Packets matching the flow match</synopsis> <synopsis>Packets matching the flow match</synopsis>
<typeRef>uint32</typeRef> <typeRef>ZeroCounter</typeRef>
<DefaultValue>0</DefaultValue>
</component> </component>
</struct> </struct>
</component> </component>
Figure 10: 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: BecomesEqualTo
This extensions adds one more event condition in the model schema, This extensions adds one more event condition in the model schema,
that of BecomesEqualTo. The difference between Greater Than and Less that of BecomesEqualTo. The difference between Greater Than and Less
Than, is that when the value is exactly that of the BecomesEqualTo, Than, is that when the value becomes exactly that of the
the event is triggered. This event condition is particularly useful BecomesEqualTo, the event is triggered. This event condition is
when there is a need to monitor one or more states of an LFB or the particularly useful when there is a need to monitor one or more
FE. For example in the CE High Availability (CEHA) [RFC7121] RFC it states of an LFB or the FE. For example in the CE High Availability
may be useful for the master CE to know which backup CEs have just (CEHA) [RFC7121] RFC it may be useful for the master CE to know which
become associated in order to connect to them and begin synchronizing backup CEs have just become associated in order to connect to them
the state of the FE. The master CE could always poll for such and begin synchronizing the state of the FE. The master CE could
information but getting such an event will speed up the process and always poll for such information but getting such an event will speed
the event may be useful in other cases as well for monitoring state. 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 The event MUST be triggered only when the value of the targeted
component becomes equal to the event condition value and MUST NOT component becomes equal to the event condition value.
generate events while the targeted component's value remains equal to Implementations MUST NOT generate subsequent events while the
the event condition's value. targeted component's value remains equal to the event condition's
value.
The BecomesEqualTo is appended to the schema as follows: The BecomesEqualTo is appended to the schema as follows:
<xsd:element name="eventBecomesEqualTo" <xsd:element name="eventBecomesEqualTo"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
Figure 11: New Excerpt of BecomesEqualTo event condition definition Figure 9: New Excerpt of BecomesEqualTo event condition definition in
in the schema 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 BecomesEqualTo event has been triggered, e.g. the CE
may need to know when a backup CE has lost association. Such an 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 event can be generated either by defining a second event on the same
component, namely an Event Changed, or by simply reusing component, namely an Event Changed, or by simply reusing
BecomesEqualTo and use event properties, in particular event BecomesEqualTo and use event properties, in particular event
hysteresis. We append the following definition for the event hysteresis. We append the following definition for the event
hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the
hysteresis value: hysteresis value:
o For an <eventBecomesEqualTo/> condition, after the last o For an <eventBecomesEqualTo/> condition, after the last
notification a new <eventBecomesEqualTo/> notification MUST be notification a new <eventBecomesEqualTo/> notification MUST be
generated only one time once the value has changed by +/- V. 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 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 must also take into account to use count or time A developer of a CE should consider using count or time filtering to
filtering to avoid being overrun by messages, e.g. in the case of avoid being overrun by messages, e.g. in the case of rapid state
rapid state changes. changes.
2.5. LFB Properties 2.5. LFB Properties
The current 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
received messages and errors in communication between CE and FE. and received messages and errors in communication between CE and FE.
These properties are read-only. 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
defines that the LFB component with ID 0 specifically MUST target LFB specifies that the LFB component with ID 0 specifically MUST refer to
properties and ID 0 MUST NOT be used for any component definition. LFB properties and ID 0 MUST NOT be used for any component
This disallowment is backwards compatible as no known LFB definition definition. This disallowment is backwards compatible as no known
uses LFB component with ID 0. Any command with a path starting from LFB definition uses LFB component with ID 0. Any command with a path
LFB component 0 refers to LFB properties. The following change in starting from LFB component 0 refers to LFB properties. The
the xml schema disallows usage of LFB component 0: following change in the xml schema disallows usage of LFB component
0:
<xsd:attribute name="componentID" type="xsd:unsignedInt" <xsd:attribute name="componentID" type="xsd:unsignedInt"
use="required"> use="required">
Figure 12: Initial xml for LFB Component IDs Figure 10: Initial xml for LFB Component IDs
<!-- Extension Added restriction to component ID --> <!-- Extension Added restriction to component ID -->
<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 -->
Figure 13: New xml for the disallowing usage of 0 as LFB Component Figure 11: New xml to disallow usage of 0 as LFB Component
The following datatype definitions are to be used as properties for The following datatype 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>
skipping to change at page 13, line 25 skipping to change at page 14, line 25
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
Properties for LFB instances 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 may inherit. Recent implementations have identified an issue class inherits. Recent implementations have identified an issue
where ambiguity rises when different versions of an LFB class exists. where ambiguity rises when different versions of the parent LFB class
This document augments the derivedFrom part of the LFB class exists. 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 backwards compatibility with the XML schema defined
in [RFC5812]. However if the version is omitted, then in the in [RFC5812]. However if the version is omitted then the derivedFrom
presence of multiple versions of the same LFB class, the derivedFrom will always specify the first version of the parent LFB class, which
will always select the latest version. usually is version 1.0.
This extension alters the definition of the derivedFrom in the xml This extension alters the definition of the derivedFrom in the xml
schema from Figure 14 to Figure 15. schema from Figure 12 to Figure 13.
<xsd:element name="derivedFrom" minOccurs="0"/> <xsd:element name="derivedFrom" minOccurs="0"/>
Figure 14: Initial xml for the LFB class inheritance Figure 12: Initial xml for the LFB class inheritance
<xsd:element name="derivedFrom" minOccurs="0"> <xsd:element name="derivedFrom" minOccurs="0">
<xsd:complexType> <xsd:complexType>
<xsd:simpleContent> <xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN"> <xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="version" <xsd:attribute name="version"
type="versionType" use="optional"/> type="versionType" use="optional"/>
</xsd:extension> </xsd:extension>
</xsd:simpleContent> </xsd:simpleContent>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
Figure 15: New xml for the LFB class inheritance Figure 13: New xml for the LFB class inheritance
An example of the use of the version attribute is given in Figure 16 An example of the use of the version attribute is given in Figure 14
<derivedFrom version="1.0">EtherPHYCop</derivedFrom> <derivedFrom version="1.0">EtherPHYCop</derivedFrom>
Figure 16: Example of use of new xml for LFB class Inheritance Figure 14: 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 on within the
same xml file. same xml file.
The following validation rules have been introduced 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 metadata ID must be unique.
2. LFB Class IDs must be unique. 2. LFB Class IDs must be unique.
3. Component ID, Capability ID and Event Base ID must be unique per 3. Component ID, Capability ID and Event Base ID must be unique per
LFB. LFB.
4. Event IDs must be unique per LFB. 4. Event IDs must be unique per LFB.
skipping to change at page 16, line 46 skipping to change at page 17, line 46
<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 -->
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
<!-- /Extension RFC XXXX -->
</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>
<!-- Extension --> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:sequence>
<!-- /Extension -->
<xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<!-- Extension -->
<xsd:element name="DefaultValue" type="xsd:token"
minOccurs="0"/>
</xsd:sequence>
<!-- /Extension -->
<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 --> <!-- Extension RFC XXXX -->
<!--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 --> <!-- /Extension RFC XXXX -->
</xsd:element> </xsd:element>
<xsd:element name="struct" type="structType"> <xsd:element name="struct" type="structType">
<!-- Extension --> <!-- Extension RFC XXXX -->
<!-- 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 --> <!-- /Extension RFC XXXX -->
</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 --> <!-- Extension RFC XXXX -->
<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 --> <!-- /Extension RFC XXXX -->
</xsd:element> </xsd:element>
<!-- Extension -->
<xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/>
<!-- /Extension -->
</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"
use="required"/> use="required"/>
skipping to change at page 19, line 39 skipping to change at page 20, line 31
<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 -->
<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 -->
<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"
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 --> <!-- Extension RFC XXXX -->
<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 --> <!-- /Extension RFC XXXX -->
</xsd:element> </xsd:element>
<xsd:element name="struct" type="structType"> <xsd:element name="struct" type="structType">
<!-- Extension --> <!-- Extension RFC XXXX -->
<!-- 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 --> <!-- /Extension RFC XXXX -->
</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 27, line 10 skipping to change at page 28, line 4
</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 --> <!-- Extension RFC XXXX -->
<xsd:element name="eventBecomesEqualTo" <xsd:element name="eventBecomesEqualTo"
substitutionGroup="eventCondition"/> substitutionGroup="eventCondition"/>
<!-- /Extension --> <!-- /Extension RFC XXXX -->
<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 9 skipping to change at page 28, line 49
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
ForCES LFB XML Schema ForCES LFB XML Schema
4. Acknowledgements 4. Acknowledgements
The author would like to acknowledge Joel Halpern, Jamal Hadi Salim The author would like to acknowledge Joel Halpern, Jamal Hadi Salim
and Dave Hood for their comments and discussion that helped shape and Dave Hood for their comments and discussion that helped shape
this document in a better way. 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 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 6. Security Considerations
The changes described in this document have no effect on security as This specification adds only a few constructs to the initial model
they are simply constructs to write XML library definitions. Thus defined in [RFC5812], namely namely a new event, some new properties
they have no effect on security semantics with the protocol and as and a way to define optional access types and complex metadata. In
such the security considerations that have been described in the addition this document addresses and clarifies an issue with the
ForCES Model RFC [RFC5812] apply to this document as well. inheritance model by introducing the version of the derivedFrom LFB
class. These constructs and the inheritance model change 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 in [RFC5812]. 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 regards 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 really new way 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 specifies 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 scope.
7. References 7. References
7.1. Normative References 7.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.
[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.
skipping to change at page 29, line 10 skipping to change at page 30, line 29
[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.
[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.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014.
7.2. Informative References 7.2. Informative References
[OpenFlowSpec1.1] [OpenFlowSpec1.1]
http://www.OpenFlow.org/, "The OpenFlow 1.1 http://www.OpenFlow.org/, "The OpenFlow 1.1
Specification.", <http://www.OpenFlow.org/documents/ Specification.", <http://www.OpenFlow.org/documents/
OpenFlow-spec-v1.1.0.pdf>. OpenFlow-spec-v1.1.0.pdf>.
Author's Address Author's Address
Evangelos Haleplidis Evangelos Haleplidis
 End of changes. 81 change blocks. 
223 lines changed or deleted 264 lines changed or added

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