Internet Engineering Task Force E.H. Haleplidis
Internet-Draft University of Patras
Intended status: Informational April 01, 2013
Expires: October 03, 2013
ForCES Model Extension
draft-haleplidis-forces-model-extension-03
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 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 an 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 extends the model to allow complex datatypes for
metadata, optional default values for datatypes and optional access
types for structures. The document also introduces two new features,
bitmap as a new datatype and a new event condition BecomesEqualTo.
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."
This Internet-Draft will expire on October 03, 2013.
Haleplidis Expires October 03, 2013 [Page 1]
Internet-Draft ForCES Model Extension April 2013
Copyright Notice
Copyright (c) 2013 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. Terminology and Conventions . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ForCES Model Extension overview . . . . . . . . . . . . . . . 4
4. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Complex datatypes for Metadata . . . . . . . . . . . . . 5
4.2. Optional Default Value for Datatypes . . . . . . . . . . 6
4.3. Optional Access Type for Structs . . . . . . . . . . . . 7
4.4. New datatype: Bitmap . . . . . . . . . . . . . . . . . . 9
4.5. New Event Condition: BecomesEqualTo . . . . . . . . . . . 10
4.6. Enhancing XML Validation . . . . . . . . . . . . . . . . 10
5. XML Extension Schema for LFB Class Library Documents . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Terminology and Conventions
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
Haleplidis Expires October 03, 2013 [Page 2]
Internet-Draft ForCES Model Extension April 2013
This document follows the terminology defined by the ForCES Model in
[RFC5812]. The required definitions are repeated below for clarity.
FE Model - The FE model is designed to model the logical
processing functions of an FE. The FE model proposed in this
document includes three components; the LFB modeling of individual
Logical Functional Block (LFB model), the logical interconnection
between LFBs (LFB topology), and the FE-level attributes,
including FE capabilities. The FE model provides the basis to
define the information elements exchanged between the CE and the
FE in the ForCES protocol [RFC5810].
LFB (Logical Functional Block) Class (or type) - A template that
represents a fine-grained, logically separable aspect of FE
processing. Most LFBs relate to packet processing in the data
path. LFB classes are the basic building blocks of the FE model.
LFB Instance - As a packet flows through an FE along a data path,
it flows through one or multiple LFB instances, where each LFB is
an instance of a specific LFB class. Multiple instances of the
same LFB class can be present in an FE's data path. Note that we
often refer to LFBs without distinguishing between an LFB class
and LFB instance when we believe the implied reference is obvious
for the given context.
LFB Model - The LFB model describes the content and structures in
an LFB, plus the associated data definition. XML is used to
provide a formal definition of the necessary structures for the
modeling. Four types of information are defined in the LFB model.
The core part of the LFB model is the LFB class definitions; the
other three types of information define constructs associated with
and used by the class definition. These are reusable data types,
supported frame (packet) formats, and metadata.
Element - Element is generally used in this document in accordance
with the XML usage of the term. It refers to an XML tagged part
of an XML document. For a precise definition, please see the full
set of XML specifications from the W3C. This term is included in
this list for completeness because the ForCES formal model uses
XML.
Attribute - Attribute is used in the ForCES formal modeling in
accordance with standard XML usage of the term, i.e., to provide
attribute information included in an XML tag.
LFB Metadata - Metadata is used to communicate per-packet state
from one LFB to another, but is not sent across the network. The
FE model defines how such metadata is identified, produced, and
Haleplidis Expires October 03, 2013 [Page 3]
Internet-Draft ForCES Model Extension April 2013
consumed by the LFBs, but not how the per-packet state is
implemented within actual hardware. Metadata is sent between the
FE and the CE on redirect packets.
ForCES Component - A ForCES Component is a well-defined, uniquely
identifiable and addressable ForCES model building block. A
component has a 32-bit ID, name, type, and an optional synopsis
description. These are often referred to simply as components.
LFB Component - An LFB component is a ForCES component that
defines the Operational parameters of the LFBs that must be
visible to the CEs.
LFB Class Library - The LFB class library is a set of LFB classes
that has been identified as the most common functions found in
most FEs and hence should be defined first by the ForCES Working
Group.
2. Introduction
The ForCES Model [RFC5812] presents a formal way to define FEs
Logical Function Blocks (LFBs) using XML. [RFC5812] has been
published a litlte more than two years and current experience in its
use has shown some room for adding new and changing existing modeling
concepts.
This document extends the ForCES Model to allow complex datatypes for
metadata, optional default values for datatypes and optional access
types for structures. Additionally the document introduces two new
features, bitmap as a new datatype and a new event condition
BecomesEqualTo. These extensions are an addendum 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.
3. ForCES Model Extension overview
The folowing extensions are considered:
1. Allow complex metadata.
2. Allow optional default values for datatypes.
3. Allow optional access type for struct datatypes.
4. New datatype: Bitmap.
5. New Event Condition: BecomesEqualTo.
Haleplidis Expires October 03, 2013 [Page 4]
Internet-Draft ForCES Model Extension April 2013
Additionally this document is also enhancing the XML validation.
4. Extensions
Some of these extensions were product of the work done on the
OpenFlow library [I-D.haleplidis-forces-openflow-lib] document.
4.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.
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.
Figure 1: Initial MetadataDefType Defintion in the schema
Haleplidis Expires October 03, 2013 [Page 5]
Internet-Draft ForCES Model Extension April 2013
Figure 2: New MetadataDefType Defintion for the schema
Two simple use cases can be seen in the OpenFlow switch
[OpenFlowSpec1.1]:
1. The Action Set metadata follows a packet inside the Flow Tables.
The Action Set metadata is an array of actions to be performed at
the end of the pipeline.
2. When a packet is received from a controller it may be accompanied
by a list of actions to be performed on it prior to be sent on
the flow table pipeline which is also an array.
4.2. Optional Default Value for Datatypes
In the original schema, default values can be defined only in
datatypes defined inside LFB components. However when it's a complex
datatype or it's a refered datatype, using the default value field is
difficult to be used. Additionally there is no option in a complex
datatype to use the default value field for only one component in the
complex datatype.
Haleplidis Expires October 03, 2013 [Page 6]
Internet-Draft ForCES Model Extension April 2013
This extension allows optionally 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.
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 Defintion in the
schema
Figure 4: New Excerpt of typeDeclarationGroup Defintion in the schema
Additionally it appends to the declaration of the AtomicType this xml
(Figure 5) to allow default values to Atomic datatypes.
Figure 5: Appending xml in of AtomicType Defintion in the schema
4.3. Optional Access Type for Structs
In the original schema, the access type can be only be defined on
components of LFB. However when it's a struct datatype it is not
possible to fine-tune access type per component in the struct. With
this extension is it allowed to define the access type for a struct
component either in the datatype definitions or in the LFB component
definitions.
This extension allows to optionally specify access type for struct
components. 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.
When the optional access type for a struct component is defined it
MUST override the access type of the struct. If by accident an
access type for a component in a capability is defined, the access
type MUST NOT be taken into account.
Haleplidis Expires October 03, 2013 [Page 7]
Internet-Draft ForCES Model Extension April 2013
This extension alters the definition of the struct in the xml schema
from Figure 6 to Figure 7.
Figure 6: Initial xml for the struct definition in the schema
Haleplidis Expires October 03, 2013 [Page 8]
Internet-Draft ForCES Model Extension April 2013
Figure 7: New xml for the struct definition in the schema
4.4. New datatype: Bitmap
With the current schema it is valid to create a struct of booleans in
order to simulate a bitmap value. However each boolean is sent as
4bytes. This extension adds the bitmap, a set of sequential named
bits. The goal is to accompany the bitmap with a TLV for
transporting it in a more compact format. A first approach would be
to define it as T-L followed by a 16bits that would specify the
number of bits, followed by the actual bits and the necessary padding
for the 32-bit alignment.
In the new schema, bits are named followed an optional bit value. An
example:
Bitmap example
A bitmap field example
Figure 8: Example of bitmap Defintion
The ordering of the bits MUST be implemented in the order that are
defined in the xml library.
The bitmap is defined in the model extension schema is as follows:
Haleplidis Expires October 03, 2013 [Page 9]
Internet-Draft ForCES Model Extension April 2013
Figure 9: New Excerpt of bitmap Defintion in the schema
Along with the needed addition to the typeDeclarationGroup
Definition:
Figure 10: New Excerpt of typeDeclarationGroup Defintion in the
schema
4.5. 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 is exactly that of the BecomesEqualTo,
the event is triggered. This event condition is particular useful
when there is a need to monitor one or more states of an LFB or the
FE. For example in the CEHA [I-D.ietf-forces-ceha] document 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 and MUST NOT
generate continuous events while the targeted component's value is
equal to the event condition value. Additionally subscribers to this
event SHOULD always set the Event Hysterisis Filtering for the
BecomeEqualTo event condition in order to avoid getting a large
amount of generated events in the case of oscillation between states.
The BecomesEqualTo is appended to the schema as follows:
Figure 11: New Excerpt of BecomesEqualTo event condition definition
in the schema
4.6. Enhancing XML Validation
Haleplidis Expires October 03, 2013 [Page 10]
Internet-Draft ForCES Model Extension April 2013
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 deinfed by the
ForCES Model [RFC5812]. Such validations work only on within the
same xml file.
The following validation rules have been appended 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.
5. XML Extension Schema for LFB Class Library Documents
Schema for Defining LFB Classes and associated types (frames,
data types for LFB attributes, and metadata).
Haleplidis Expires October 03, 2013 [Page 11]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 12]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 13]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 14]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 15]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 16]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 18]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 19]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 20]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 21]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 22]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 23]
Internet-Draft ForCES Model Extension April 2013
OpenFlow XML Library
6. Acknowledgements
The author would like to acknowledge Joel Halpern, Jamal Hadi and
Dave Hood for their comments and discussion that helped shape this
document in a better way.
7. IANA Considerations
This memo includes no request to IANA.
Haleplidis Expires October 03, 2013 [Page 24]
Internet-Draft ForCES Model Extension April 2013
8. Security Considerations
The security considerations that have been described in the ForCES
Model RFC [RFC5812] apply to this document as well.
9. References
9.1. Normative References
[I-D.haleplidis-forces-openflow-lib]
Haleplidis, E., Cherkaoui, O., Hares, S., and W. Wang,
"Forwarding and Control Element Separation (ForCES)
OpenFlow Model Library", draft-haleplidis-forces-openflow-
lib-02 (work in progress), October 2012.
[I-D.ietf-forces-ceha]
Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
Intra-NE High Availability", draft-ietf-forces-ceha-06
(work in progress), February 2013.
[OpenFlowSpec1.1]
http://www.OpenFlow.org/, "The OpenFlow 1.1
Specification.", , .
[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.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Evangelos Haleplidis
University of Patras
Department of Electrical and Computer Engineering
Patras 26500
Greece
Email: ehalep@ece.upatras.gr
Haleplidis Expires October 03, 2013 [Page 25]
Internet-Draft ForCES Model Extension April 2013
Haleplidis Expires October 03, 2013 [Page 26]