Internet Engineering Task Force E. Haleplidis
Internet-Draft University of Patras
Updates: 5812 (if approved) August 21, 2014
Intended status: Standards Track
Expires: February 22, 2015
ForCES Model Extension
draft-ietf-forces-model-extension-04
Abstract
Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC5812 has defined
the ForCES Model that provides a formal way to represent the
capabilities, state, and configuration of forwarding elements within
the context of the ForCES protocol, so that control elements (CEs)
can control the FEs accordingly. More specifically, the model
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 updates 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 Logical
Functional Block (LFB) inheritance. The document also introduces two
new features a new event condition BecomesEqualTo and LFB properties.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Haleplidis Expires February 22, 2015 [Page 1]
Internet-Draft ForCES Model Extension August 2014
This Internet-Draft will expire on February 22, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 4
2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4
2.2. Optional Default Value for Datatypes . . . . . . . . . . 5
2.3. Optional Access Type for Structs . . . . . . . . . . . . 8
2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 11
2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 12
2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 14
2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 15
3. XML Extension Schema for LFB Class Library Documents . . . . 15
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
The ForCES Model [RFC5812] presents a formal way to define Forwarding
Elements (FE) Logical Function Blocks (LFBs) using the eXtensible
Markup Language (XML). [RFC5812] has been published a more than two
years and current experience in its use has demonstrated need for
adding new and changing existing modeling concepts.
Haleplidis Expires February 22, 2015 [Page 2]
Internet-Draft ForCES Model Extension August 2014
Specifically this document updates the ForCES Model [RFC5812] to
allow complex datatypes for metadata (Section 2.1), optional default
values for datatypes (Section 2.2), optional access types for
structures (Section 2.3) and fixes an issue with LFB class
inheritance (Section 2.6). Additionally the document introduces two
new features, a new event condition BecomesEqualTo (Section 2.4) and
LFB properties (Section 2.5).
These extensions are an update to the ForCES model [RFC5812] and do
not require any changes on the ForCES protocol [RFC5810] as they are
simply changes of the schema definition. Additionally backward
compatibility is ensured as XML libraries produced with the earlier
schema are still valid with the new one. In order for XML libraries
produced by the new schema to be compatible with existing ForCES
implementations, the XML Libraries MUST NOT include any of the
features described in this document, else the old implementation will
be unable to parse the XML library.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Definitions
This document uses the terminology defined in the ForCES Model in
[RFC5812]. In particular, the reader is expected to be familiar with
the following terms:
FE Model
LFB (Logical Functional Block) Class (or type)
LFB Instance
LFB Model
Element
Attribute
LFB Metadata
ForCES Component
LFB Class Library
Haleplidis Expires February 22, 2015 [Page 3]
Internet-Draft ForCES Model Extension August 2014
2. ForCES Model Extensions
2.1. Complex datatypes for Metadata
Section 4.6. (Element for Metadata Definitions) in the ForCES Model
[RFC5812] limits the datatype use in metadata to only atomic types.
Figure 1 shows the xml schema excerpt where ony typeRef and atomic
are allowed for a metadata definition.
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.
Haleplidis Expires February 22, 2015 [Page 4]
Internet-Draft ForCES Model Extension August 2014
Figure 2: New MetadataDefType Definition for the schema
2.2. Optional Default Value for Datatypes
In the original schema, default values can only be defined for
datatypes defined inside LFB components and not inside structures or
arrays. Therefore default values of datatypes that are constantly
being reused, e.g. counters with default value of 0, have to be
constantly respecified. Additionally, datatypes inside complex
datatypes cannot be defined with a default value, e.g. a counter
inside a struct that has a default value of 0.
This extension allows the option to add default values to atomic and
typeref types, whether they are as simple or complex datatypes. A
simple use case would be to have a struct component where one of the
components is a counter which the default value would be zero.
Haleplidis Expires February 22, 2015 [Page 5]
Internet-Draft ForCES Model Extension August 2014
This extension alters the definition of the typeDeclarationGroup in
the XML schema from Figure 3 to Figure 4 to allow default values to
TypeRef.
Figure 3: Initial Excerpt of typeDeclarationGroup Definition in the
schema
Figure 4: New Excerpt of typeDeclarationGroup Definition in the
schema
Additionally this document appends to the initial declaration of the
AtomicType, Figure 5, an optional defaultValue, Figure 6, to allow
default values to Atomic datatypes. Note that both declarations
include the new special value validation described in Section 2.7
Figure 5: Initial Excerpt of AtomicType Definition in the schema
Haleplidis Expires February 22, 2015 [Page 6]
Internet-Draft ForCES Model Extension August 2014
Figure 6: New Excerpt of AtomicType Definition in the schema
Examples of using default values is depicted in Figure 7.
Counter Values
Example default values in struct
GoodPacketCoutner
A counter for good packets
uint32
0
BadPacketCoutner
A counter for bad packets
uint32
0
Figure 7: Example of optional default values
Haleplidis Expires February 22, 2015 [Page 7]
Internet-Draft ForCES Model Extension August 2014
2.3. Optional Access Type for Structs
In the original schema, the access type can only be defined on
components of an LFB and not on components within structs or arrays.
That means that when it is a struct datatype it is not possible to
fine-tune access type per component within the struct. A simple use
case would be to have a read-write struct component where one of the
components is a counter where the access-type could be read-reset or
read-only, e.g. a read-reset or a read-only counter inside a struct.
This extension allows the definition of the access type for a struct
component either in the datatype definitions or in the LFB component
definitions.
When optional access type for components within a struct are defined,
these components's access type MUST override the access type of the
struct. For example if a struct has an access type of read-write but
has a component that is a read-only counter, the counter's access
type MUST be read-only.
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
from Figure 8 to Figure 9.
Haleplidis Expires February 22, 2015 [Page 8]
Internet-Draft ForCES Model Extension August 2014
Figure 8: Initial xml for the struct definition in the schema
Haleplidis Expires February 22, 2015 [Page 9]
Internet-Draft ForCES Model Extension August 2014
Figure 9: New xml for the struct definition in the schema
An example of using optional access types for structs can be depicted
in Figure 10
Haleplidis Expires February 22, 2015 [Page 10]
Internet-Draft ForCES Model Extension August 2014
PacketFlows
Packet Flows, match and counter
FlowMatch
Flow Match
MatchType
MatchCounter
Packets matching the flow match
uint32
0
Figure 10: Example of optional access types for struct
2.4. New Event Condition: BecomesEqualTo
This extensions adds one more event condition in the model schema,
that of BecomesEqualTo. The difference between Greater Than and Less
Than, is that when the value becomes exactly that of the
BecomesEqualTo, the event is triggered. This event condition is
particularly useful when there is a need to monitor one or more
states of an LFB or the FE. For example in the CE High Availability
(CEHA) [RFC7121] RFC it may be useful for the master CE to know which
backup CEs have just become associated in order to connect to them
and begin synchronizing the state of the FE. The master CE could
always poll for such information but getting such an event will speed
up the process and the event may be useful in other cases as well for
monitoring state.
The event MUST be triggered only when the value of the targeted
component becomes equal to the event condition value.
Implementations MUST NOT generate subsequent events while the
targeted component's value remains equal to the event condition's
value.
The BecomesEqualTo is appended to the schema as follows:
Figure 11: New Excerpt of BecomesEqualTo event condition definition
in the schema
Haleplidis Expires February 22, 2015 [Page 11]
Internet-Draft ForCES Model Extension August 2014
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
may need to know when a backup CE has lost association. Such an
event can be generated either by defining a second event on the same
component, namely an Event Changed, or by simply reusing
BecomesEqualTo and use event properties, in particular 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 value:
o For an condition, after the last
notification a new notification MUST be
generated only one time once the value has changed by +/- V.
For example using the value of 1 for V, will in effect create a
singular event that will notify the CE that the value has changed by
at least 1.
A developer of a CE should consider using count or time filtering to
avoid being overrun by messages, e.g. in the case of rapid state
changes.
2.5. LFB Properties
The previous model definition specifies properties for components of
LFBs. Experience has shown that, at least for debug reasons, it
would be useful to have statistics per LFB instance to monitor sent
and received messages and errors in communication between CE and FE.
These properties are read-only.
In order to avoid ambiguity on protocol path semantics, this document
specifies that the LFB component with ID 0 specifically MUST refer to
LFB properties and ID 0 MUST NOT be used for any component
definition. This disallowment is backwards compatible as no known
LFB definition uses LFB component with ID 0. Any command with a path
starting from LFB component 0 refers to LFB properties. The
following change in the xml schema disallows usage of LFB component
0:
Figure 12: Initial xml for LFB Component IDs
Haleplidis Expires February 22, 2015 [Page 12]
Internet-Draft ForCES Model Extension August 2014
Figure 13: New xml to disallow usage of 0 as LFB Component
The following datatype definitions are to be used as properties for
LFB instances.
LFBProperties
LFB Properties definition
PacketsSentToCE
Packets sent to CE
uint32
SentErrorPacketsToCE
Error Packets sent to CE
uint32
BytesSentToCE
Bytes sent to CE
uint32
SentErrorBytesToCE
Error Bytes sent to CE
uint32
PacketsReceivedFromCE
Packets received from CE
uint32
ReceivedErrorPacketsFromCE
Error Packets received from CE
uint32
Haleplidis Expires February 22, 2015 [Page 13]
Internet-Draft ForCES Model Extension August 2014
BytesReceivedFromCE
Bytesreceived from CE
uint32
ReceivedErrorBytesFromCE
Error Bytes received from CE
uint32
Properties for LFB instances
2.6. LFB class inheritance
The ForCES model [RFC5812] allows inheritance for LFB classes.
However the xml schema defines only the LFB class from which an LFB
class inherits. Recent implementations have identified an issue
where ambiguity rises when different versions of the parent LFB class
exists. This document augments the derivedFrom part of the LFB class
definition with an optional version attribute when the derivedFrom
field is used.
Having the version attribute as optional was a decision based on the
need to maintain backwards compatibility with the XML schema defined
in [RFC5812]. However if the version is omitted then the derivedFrom
will always specify the first version of the parent LFB class, which
usually is version 1.0.
This extension alters the definition of the derivedFrom in the xml
schema from Figure 14 to Figure 15.
Figure 14: Initial xml for the LFB class inheritance
Haleplidis Expires February 22, 2015 [Page 14]
Internet-Draft ForCES Model Extension August 2014
Figure 15: New xml for the LFB class inheritance
An example of the use of the version attribute is given in Figure 16
EtherPHYCop
Figure 16: Example of use of new xml for LFB class Inheritance
2.7. Enhancing XML Validation
As specified earlier this is not an extension but an enhancement of
the schema to provide additional validation rules. This includes
adding new key declarations to provide uniqueness as defined by the
ForCES Model [RFC5812]. Such validations work only on within the
same xml file.
This document introduces the following validation rules that did not
exist in the original schema in [RFC5812]:
1. Each metadata ID must be unique.
2. LFB Class IDs must be unique.
3. Component ID, Capability ID and Event Base ID must be unique per
LFB.
4. Event IDs must be unique per LFB.
5. Special Values in Atomic datatypes must be unique per atomic
datatype.
3. XML Extension Schema for LFB Class Library Documents
This section includes the new XML Schema. Note that the namespace
number has been updated from 1.0 to 1.1
Haleplidis Expires February 22, 2015 [Page 15]
Internet-Draft ForCES Model Extension August 2014
Schema for Defining LFB Classes and associated types
(frames, data types for LFB attributes, and metadata).
Haleplidis Expires February 22, 2015 [Page 16]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 19]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 20]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 21]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 22]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 23]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 24]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 25]
Internet-Draft ForCES Model Extension August 2014
Haleplidis Expires February 22, 2015 [Page 26]
Internet-Draft ForCES Model Extension August 2014
ForCES LFB XML Schema
Haleplidis Expires February 22, 2015 [Page 28]
Internet-Draft ForCES Model Extension August 2014
4. 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 in a better way. Adrian Farrel for his AD review and
Ben Campbell for his Gen-ART review which both improved the quality
of this document.
5. IANA Considerations
IANA has registered a new XML namespace, as per the guidelines in RFC
3688 [RFC3688].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:forces:lfbmodel:1.1
Registrant Contact: IESG
XML: none, this is an XML namespace
6. Security Considerations
This document adds only a few constructs to the initial model defined
in [RFC5812], namely namely a new event, some new properties and a
way to define optional access types and complex metadata. In
addition this document addresses and clarifies an issue with the
inheritance model by introducing the version of the derivedFrom LFB
class. These constructs and the inheritance model change do not
change the nature of the initial model.
Thus the security considerations defined in [RFC5812] applies to this
document as well as the changes proposed here are simply constructs
to write XML library definitions, as where in [RFC5812] and clarifies
the inheritance issue of the initial model and both have no effect on
security semantics with the protocol.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
Haleplidis Expires February 22, 2015 [Page 29]
Internet-Draft ForCES Model Extension August 2014
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", RFC
5812, March 2010.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
"High Availability within a Forwarding and Control Element
Separation (ForCES) Network Element", RFC 7121, February
2014.
7.2. Informative References
[OpenFlowSpec1.1]
http://www.OpenFlow.org/, "The OpenFlow 1.1
Specification.", .
Author's Address
Evangelos Haleplidis
University of Patras
Department of Electrical and Computer Engineering
Patras 26500
Greece
Email: ehalep@ece.upatras.gr
Haleplidis Expires February 22, 2015 [Page 30]