Internet Engineering Task Force E. Haleplidis Internet-Draft University of Patras Intended status: Standards Track May 20, 2014 Expires: November 21, 2014 ForCES Model Extension draft-ietf-forces-model-extension-02 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, 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 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 November 21, 2014. Haleplidis Expires November 21, 2014 [Page 1] Internet-Draft ForCES Model Extension May 2014 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. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ForCES Model Extension proposal . . . . . . . . . . . . . . . 4 3.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4 3.2. Optional Default Value for Datatypes . . . . . . . . . . 6 3.3. Optional Access Type for Structs . . . . . . . . . . . . 8 3.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 10 3.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 11 3.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 12 3.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 13 4. XML Extension Schema for LFB Class Library Documents . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 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]. Haleplidis Expires November 21, 2014 [Page 2] Internet-Draft ForCES Model Extension May 2014 1.2. Definitions 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. Haleplidis Expires November 21, 2014 [Page 3] Internet-Draft ForCES Model Extension May 2014 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 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 more than two years and current experience in its use has demonstrated need for adding new and changing existing modeling concepts. Specifically this document extends the ForCES Model to allow complex datatypes for metadata, optional default values for datatypes, optional access types for structures and fixes an issue with the LFB inheritance. Additionally the document introduces two new features a new event condition BecomesEqualTo and LFB properties. 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 proposal 3.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. Haleplidis Expires November 21, 2014 [Page 4] Internet-Draft ForCES Model Extension May 2014 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 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. 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 Definition in the schema Haleplidis Expires November 21, 2014 [Page 5] Internet-Draft ForCES Model Extension May 2014 Figure 2: New MetadataDefType Definition for the schema 3.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 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. Haleplidis Expires November 21, 2014 [Page 6] Internet-Draft ForCES Model Extension May 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 Defintion in the schema Figure 4: New Excerpt of typeDeclarationGroup Definition 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 Definition in the schema Counter Values Example default values in struct GoodPacketCoutner A counter for good packets uint32 0 BadPacketCoutner A counter for bad packets uint32 0 Figure 6: Example of optional default values Haleplidis Expires November 21, 2014 [Page 7] Internet-Draft ForCES Model Extension May 2014 3.3. Optional Access Type for Structs In the original schema, the access type can be only be defined on components of LFB and not on components in structs or arrays. However when it's a struct datatype it is not possible to fine-tune access type per component in 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. 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. 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 and MUST always be considered as read-only. This extension alters the definition of the struct in the xml schema from Figure 7 to Figure 8. Figure 7: Initial xml for the struct definition in the schema Haleplidis Expires November 21, 2014 [Page 8] Internet-Draft ForCES Model Extension May 2014 Figure 8: New xml for the struct definition in the schema PacketFlows Packet Flows, match and counter FlowMatch Flow Match MatchType MatchCounter Packets matching the flow match uint32 0 Figure 9: Example of optional access types for struct Haleplidis Expires November 21, 2014 [Page 9] Internet-Draft ForCES Model Extension May 2014 3.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 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 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 10: New Excerpt of BecomesEqualTo event condition definition in the schema 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 must also take into account to use count or time filtering to avoid being overrun by messages, e.g. in the case of rapid state changes. Haleplidis Expires November 21, 2014 [Page 10] Internet-Draft ForCES Model Extension May 2014 3.5. LFB Properties The current model definition specifies properties for components of LFBs. Experience however has proven valuable at least for debug reasons, to have statistics per LFB instance to monitor sent/received messages and errors for communication between CE and FE. These properties are read-only. In order to avoid ambiguity on protocol path semantics, this document reserves LFB component 0 for LFB properties. This reservation is backwards compatible as no LFB definition uses LFB component 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 11: Initial xml for LFB Component IDs Figure 12: New xml for the disallowing 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 Haleplidis Expires November 21, 2014 [Page 11] Internet-Draft ForCES Model Extension May 2014 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 BytesReceivedFromCE Bytesreceived from CE uint32 ReceivedErrorBytesFromCE Error Bytes received from CE uint32 Properties for LFB instances 3.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 may inherit. Recent implementations have identified an issue where ambiguity rises when different versions of an LFB class exists. This document augments the derivedFrom part of the LFB class definition with a mandatory version attribute when the derivedFrom field is used. Haleplidis Expires November 21, 2014 [Page 12] Internet-Draft ForCES Model Extension May 2014 This extension alters the definition of the derivedFrom in the xml schema from Figure 13 to Figure 14. Figure 13: Initial xml for the LFB class inheritance Figure 14: New xml for the LFB class inheritance EtherPHYCop Figure 15: Example of use of new xml for LFB class Inheritance 3.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. 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. Haleplidis Expires November 21, 2014 [Page 13] Internet-Draft ForCES Model Extension May 2014 4. 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 November 21, 2014 [Page 14] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 15] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 16] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 17] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 18] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 19] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 20] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 21] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 22] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 23] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 24] Internet-Draft ForCES Model Extension May 2014 Haleplidis Expires November 21, 2014 [Page 25] Internet-Draft ForCES Model Extension May 2014 OpenFlow XML Library Haleplidis Expires November 21, 2014 [Page 26] Internet-Draft ForCES Model Extension May 2014 5. 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. 6. IANA Considerations This specification requests that LFB Component ID 0 to be reserved. 7. Security Considerations The security considerations that have been described in the ForCES Model RFC [RFC5812] apply to this document as well. 8. References 8.1. Normative References [I-D.ietf-forces-ceha] Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES Intra-NE High Availability", draft-ietf-forces-ceha-08 (work in progress), October 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. 8.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 Haleplidis Expires November 21, 2014 [Page 27] Internet-Draft ForCES Model Extension May 2014 Evangelos Haleplidis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece Email: ehalep@ece.upatras.gr Haleplidis Expires November 21, 2014 [Page 28]