Internet Engineering Task Force (IETF)                     E. Haleplidis
Internet-Draft
Request for Comments: 7408                          University of Patras
Updates: 5812 (if approved)                           September 11,                                              November 2014
Intended status:
Category: Standards Track
Expires: March 15, 2015

                         ForCES
ISSN: 2070-1721

   Forwarding and Control Element Separation (ForCES) Model Extension
                  draft-ietf-forces-model-extension-05

Abstract

   This memo extends the Forwarding and Control Element Separation
   (ForCES) model defined in RFC 5812 and updates RFC5812 that RFC to allow
   complex datatypes data types for metadata, optional default values for
   datatypes, data
   types, and optional access types for structures.  It also fixes an
   issue with Logical Functional Block (LFB) inheritance.  It also inheritance and introduces
   two new features features: a new event condition BecomesEqualTo called eventBecomesEqualTo
   and LFB properties.  The changes introduced in this memo do not alter
   the protocol and retain backward compatibility with older LFB models.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 March 15, 2015.
   http://www.rfc-editor.org/info/rfc7408.

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 ....................................................2
      1.1. Requirements Language . . . . . . . . . . . . . . . . . .   3 ......................................3
      1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3 Terminology ................................................3
   2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . .   3 .........................................3
      2.1. Complex datatypes Data Types for Metadata  . . . . . . . . . . . . .   3 ............................3
      2.2. Optional Default Value Values for Datatypes  . . . . . . . . . .   5 Data Types .....................5
      2.3. Optional Access Type Types for Structs  . . . . . . . . . . . .   8 ..........................8
      2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . .  11 eventBecomesEqualTo ..................11
      2.5. LFB Properties  . . . . . . . . . . . . . . . . . . . . .  12 ............................................12
      2.6. LFB class inheritance . . . . . . . . . . . . . . . . . .  14 Class Inheritance .....................................14
      2.7. Enhancing XML Validation  . . . . . . . . . . . . . . . .  15 ..................................15
   3. XML Extension Schema for LFB Class Library Documents  . . . .  15 ...........15
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
   6. ............................................29
   5. Security Considerations . . . . . . . . . . . . . . . . . . .  29
   7. ........................................29
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     7.1. .....................................................30
      6.1. Normative References  . . . . . . . . . . . . . . . . . .  30
     7.2. ......................................30
      6.2. Informative References  . . . . . . . . . . . . . . . . .  30 ....................................30
   Acknowledgements ..................................................31
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  30 ..................................................31

1.  Introduction

   The ForCES Model model [RFC5812] presents a formal way to define Forwarding
   Elements
   Element (FE) Logical Function Functional Blocks (LFBs) using the eXtensible
   Markup Language (XML).  [RFC5812] has been was published a more than two several years before
   this document, and current experience in with its use has demonstrated the need for
   adding
   to add new modeling concepts and changing change existing modeling concepts.

   Specifically ones.

   Specifically, this document updates the ForCES Model model [RFC5812] to
   allow complex datatypes data types for metadata (Section 2.1), optional default
   values for datatypes data types (Section 2.2), and optional access types for
   structures (Section 2.3) and 2.3).  It also fixes an issue with LFB class
   inheritance (Section 2.6).  Additionally  Additionally, the document introduces two
   new features, features: a new event condition BecomesEqualTo named eventBecomesEqualTo
   (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 to the ForCES protocol [RFC5810] as they are
   simply changes of to the schema definition.  Additionally  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.

   Extensions to the schema and excerpts of the schema include the tags
   <!-- Extension RFC XXXX 7408 --> and <!-- /Extension RFC XXXX --> 7408 -->, which
   designates
   designate the beginning and ending of extension text specified by
   this document in respect to the schema in the original ForCES Model [RFC5812]
   schema. model
   [RFC5812].

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  Terminology

   This document uses the terminology defined in the ForCES Model in model
   [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

2.  ForCES Model Extensions

2.1.  Complex datatypes Data Types for Metadata

   Section 4.6.  (Element 4.6 ("<metadataDefs> Element for Metadata Definitions) in Definitions") of
   the ForCES Model model [RFC5812] limits the datatype data type use in metadata to
   only atomic types.  Figure 1 shows the xml XML schema excerpt where only
   typeRef and atomic are allowed for a metadata definition.

     <xsd:complexType name="metadataDefsType">
       <xsd:sequence>
         <xsd:element name="metadataDef" maxOccurs="unbounded">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="name" type="xsd:NMTOKEN"/>
               <xsd:element ref="synopsis"/>
               <xsd:element name="metadataID" type="xsd:integer"/>
               <xsd:element ref="description" minOccurs="0"/>
               <xsd:choice>
                 <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
                 <xsd:element name="atomic" type="atomicType"/>
               </xsd:choice>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
     </xsd:complexType>

        Figure 1: Initial MetadataDefType metadataDefsType Definition in the schema

   However Schema

   However, there are cases where complex metadata are used in the
   datapath,
   datapath: for example example, two simple use cases can be seen are described in version
   1.1.0 (and subsequent versions) of the OpenFlow 1.1 specification [OpenFlowSpec1.1] and beyond: Switch Specification
   [OpenFlowSpec1.1]:

   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 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 the extension (Figure 2), shown in 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:sequence>
         <xsd:element name="metadataDef" maxOccurs="unbounded">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="name" type="xsd:NMTOKEN"/>
               <xsd:element ref="synopsis"/>
               <xsd:element name="metadataID" type="xsd:integer"/>
               <xsd:element ref="description" minOccurs="0"/>
               <xsd:choice>
                 <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
                 <xsd:element name="atomic" type="atomicType"/>
                 <!-- Extension RFC XXXX 7408 -->
                 <xsd:element name="array" type="arrayType">
                   <xsd:key name="contentKeyID1">
                     <xsd:selector xpath="lfb:contentKey"/>
                     <xsd:field xpath="@contentKeyID"/>
                   </xsd:key>
                 </xsd:element>
                 <xsd:element name="struct" type="structType">
                   <xsd:key name="structComponentID1">
                     <xsd:selector xpath="lfb:component"/>
                     <xsd:field xpath="@componentID"/>
                   </xsd:key>
                 </xsd:element>
                 <!-- /Extension RFC XXXX 7408 -->
               </xsd:choice>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
     </xsd:complexType>

          Figure 2: New MetadataDefType metadataDefsType Definition for in the schema Schema

2.2.  Optional Default Value Values for Datatypes Data Types

   In the original schema, default values can only be defined for
   datatypes data
   types defined inside LFB components and not inside structures or
   arrays.  Therefore  Therefore, default values of datatypes for data types that are constantly
   being reused, e.g. e.g., counters with default value of 0, have to be
   constantly respecified.  Additionally, datatypes data types inside complex
   datatypes data
   types cannot be defined with a default value, e.g. e.g., a counter inside
   a struct that has a default value of 0.

   This extension allows the option to add default values to datatypes. data types.
   These datatypes data types can then be referenced as simple components or
   within complex datatypes data types such as structs.  A simple use case would
   be to have a struct component where one of the components is a
   counter
   which the with a default value would be of zero.  To achieve that that, the counter
   must first be defined as a datatype data type with the required default value
   and then referenced in the struct.  Default values MUST adhere the
   following formal restrictions:

   1.  Default Values values MUST be ignored if the data type is not an atomic
       or a base data type.

   2.  When a datatype data type X with default value A is referenced from a
       datatype data
       type Y with a default value B, the default value of the
       datatype data type
       that references overrides the referenced default value,
       e.g. e.g., in
       this case case, Y's default value will be B.

   3.  Default Values values of LFB components overrides override any default value
       specified from the dataTypeDef definition.

   4.  Default Values values of datatypes reference data types referenced in capabilities or
       metadata MUST be ignored.

   This extension simply appends adds to the definition of the dataTypeDefsType in
   the XML schema from shown in Figure 3 to Figure 4 to allow default values to for
   dataTypeDefsType.  The new definition is shown in Figure 4.

     <xsd:complexType name="dataTypeDefsType">
       <xsd:sequence>
         <xsd:element name="dataTypeDef" maxOccurs="unbounded">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="name" type="xsd:NMTOKEN"/>
               <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
                  minOccurs="0"/>
               <xsd:element ref="synopsis"/>
               <xsd:element ref="description" minOccurs="0"/>
               <xsd:group ref="typeDeclarationGroup"/>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
     </xsd:complexType>

      Figure 3: Initial Excerpt of dataTypeDefsType Definition in the
                                  schema
                                  Schema
     <xsd:complexType name="dataTypeDefsType">
       <xsd:sequence>
         <xsd:element name="dataTypeDef" maxOccurs="unbounded">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="name" type="xsd:NMTOKEN"/>
               <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
                  minOccurs="0"/>
               <xsd:element ref="synopsis"/>
               <xsd:element ref="description" minOccurs="0"/>
               <xsd:group ref="typeDeclarationGroup"/>
               <!-- Extension RFC XXXX 7408 -->
               <xsd:element name="defaultValue" type="xsd:token"
                  minOccurs="0"/>
               <!-- /Extension RFC XXXX 7408 -->
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
     </xsd:complexType>

    Figure 4: New Excerpt of dataTypeDefsType Definition in the schema Schema
   Examples of using default values is depicted in Figure 5.

     <dataTypeDef>
       <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>
       <struct>
         <component componentID="1">
                  <name>GoodPacketCoutner</name>
           <name>GoodPacketCounter</name>
           <synopsis>A counter for good packets</synopsis>
           <typeRef>ZeroCounter</typeRef>
         </component>
         <component componentID="2">
                  <name>BadPacketCoutner</name>
           <name>BadPacketCounter</name>
           <synopsis>A counter for bad packets</synopsis>
           <typeRef>ZeroCounter</typeRef>
         </component>
       </struct>
     </dataTypeDef>

               Figure 5: Example of optional default values Optional Default Values

2.3.  Optional Access Type Types 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 data type, 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 with an access type that could be read-reset
   or read-only, e.g. 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 data type definitions or in the LFB component
   definitions.

   When optional access type types for components within a struct are
   defined,
   these components's the access type types for these components MUST override the
   access type of the struct.  For example 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

   Per [RFC5812], the access type for a component in a capability is
   always read-only
   per [RFC5812]. read-only.  If an access type is provided for a component in a
   capability, the access type MUST be ignored.  Similarly  Similarly, if an access
   type is provided for a struct in a metadata metadata, the access type MUST be
   ignored.

   This extension alters the definition of the struct in the xml XML schema
   from the initial definition shown in Figure 6 to the new shown in
   Figure 7.

     <xsd:complexType name="structType">
       <xsd:sequence>
         <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
           minOccurs="0"/>
         <xsd:element name="component" maxOccurs="unbounded">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="name" type="xsd:NMTOKEN"/>
               <xsd:element ref="synopsis"/>
               <xsd:element ref="description" minOccurs="0"/>
               <xsd:element name="optional" minOccurs="0"/>
               <xsd:group ref="typeDeclarationGroup"/>
             </xsd:sequence>
             <xsd:attribute name="componentID" type="xsd:unsignedInt"
              use="required"/>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
     </xsd:complexType>

       Figure 6: Initial xml XML for the struct definition Struct Definition in the schema Schema
     <xsd:complexType name="structType">
       <xsd:sequence>
         <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
           minOccurs="0"/>
         <xsd:element name="component" maxOccurs="unbounded">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="name" type="xsd:NMTOKEN"/>
               <xsd:element ref="synopsis"/>
               <xsd:element ref="description" minOccurs="0"/>
               <xsd:element name="optional" minOccurs="0"/>
               <xsd:group ref="typeDeclarationGroup"/>
             </xsd:sequence>
             <!-- Extension RFC XXXX 7408 -->
             <xsd:attribute name="access" use="optional"
               default="read-write">
               <xsd:simpleType>
                 <xsd:list itemType="accessModeType"/>
               </xsd:simpleType>
             </xsd:attribute>
             <!-- /Extension RFC XXXX 7408 -->
             <xsd:attribute name="componentID" type="xsd:unsignedInt"
               use="required"/>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
     </xsd:complexType>

         Figure 7: New xml XML for the struct definition Struct Definition in the schema Schema
   An example of using optional access types for structs can be is depicted in
   Figure 8 8.

      <component componentID="1" access="read-write">
         <name>PacketFlows</name>
         <synopsis>Packet Flows, match and counter</synopsis>
         <struct>
          <component componentID="1">
            <name>FlowMatch</name>
            <synopsis>Flow Match</synopsis>
            <typeRef>MatchType</typeRef>
          </component>
          <component componentID="2" access="read-only">
            <name>MatchCounter</name>
            <synopsis>Packets matching the flow match</synopsis>
            <typeRef>ZeroCounter</typeRef>
          </component>
        </struct>
      </component>

           Figure 8: Example of optional access types Optional Access Types for struct Struct

2.4.  New Event Condition: BecomesEqualTo eventBecomesEqualTo

   This extensions extension adds one more event condition in the model schema,
   that of BecomesEqualTo.  The difference between Greater Than
   eventBecomesEqualTo.  eventBecomesEqualTo is different from
   eventGreaterThan and Less
   Than, eventLessThan because the event is that triggered
   when the value becomes is exactly that of the
   BecomesEqualTo, the event is triggered. eventBecomesEqualTo threshold.
   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 example, in the CE
   Control Element High Availability (CEHA) [RFC7121] RFC document [RFC7121], 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
   information, but getting such an event will speed up the process 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

   eventBecomesEqualTo is appended to the schema as follows: shown in Figure 9.

     <xsd:element name="eventBecomesEqualTo"
       substitutionGroup="eventCondition"/>

       Figure 9: New Excerpt of BecomesEqualTo event condition definition eventBecomesEqualTo Event Condition
                         Definition in the schema Schema

   It can become useful for the CE to be notified when the state has
   changed once the BecomesEqualTo eventBecomesEqualTo event has been triggered, e.g. 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 component (namely, an Event Changed, eventChanged) or by simply reusing
   BecomesEqualTo
   eventBecomesEqualTo and use event properties, in particular using event
   hysteresis. properties (in particular,
   eventHysteresis).  We append the following definition for to the event
   hysteresis
   eventHysteresis defined in section Section 4.8.5.2 in of [RFC5812], with V being
   the hysteresis value:

   o  For an <eventBecomesEqualTo/> eventBecomesEqualTo condition, after the last
      notification notification,
      a new <eventBecomesEqualTo/> eventBecomesEqualTo notification MUST be generated only one
      time once the value has changed by +/- V.

   For example example, using the value of 1 for V, will V will, in effect 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. 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 a 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 componentID 0 specifically MUST refer to LFB
   properties and ID 0 MUST NOT be used for any component definition.
   This disallowment disallowance is backwards backward compatible as no known LFB definition
   uses an LFB component with ID componentID 0.  Any command with a path starting from LFB component
   componentID 0 refers to LFB properties.  The
   following  Figures 10 and 11 illustrate
   the change in the xml XML schema that disallows usage of LFB component componentID
   0:

      <xsd:attribute name="componentID" type="xsd:unsignedInt"
       use="required">

                Figure 10: Initial xml XML for LFB Component IDs componentIDs

      <!-- Extension Added added restriction to component ID componentID -->
      <xsd:attribute name="componentID" use="required">
        <xsd:simpleType>
          <xsd:restriction base="xsd:unsignedInt">
            <xsd:minExclusive value="0"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:attribute>
      <!-- End of extension -->

         Figure 11: New xml XML to disallow usage Disallow Usage of 0 as LFB Component componentID 0

   The following datatype data type definitions are to be used as properties for
   LFB instances.

      <dataTypeDef>
         <name>LFBProperties</name>
         <synopsis>LFB Properties definition</synopsis>
         <struct>
            <component componentID="1">
               <name>PacketsSentToCE</name>
               <synopsis>Packets sent to CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>SentErrorPacketsToCE</name>
               <synopsis>Error Packets sent to CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>BytesSentToCE</name>
               <synopsis>Bytes sent to CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="4">
               <name>SentErrorBytesToCE</name>
               <synopsis>Error Bytes sent to CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="5">
               <name>PacketsReceivedFromCE</name>
               <synopsis>Packets received from CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="6">
               <name>ReceivedErrorPacketsFromCE</name>
               <synopsis>Error Packets received from CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="7">
               <name>BytesReceivedFromCE</name>
                  <synopsis>Bytesreceived
               <synopsis>Bytes received from CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="8">
               <name>ReceivedErrorBytesFromCE</name>
               <synopsis>Error Bytes received from CE</synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>

                  Figure 12: Properties for LFB instances Instances

2.6.  LFB class inheritance Class Inheritance

   The ForCES model [RFC5812] allows inheritance for LFB classes.
   However
   However, the xml 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.
   exist.  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 backward compatibility with the XML schema defined
   in [RFC5812].  However  However, if the version is omitted 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 XML schema
   from the initial definition shown in Figure 12 13 to the new shown in
   Figure 13. 14.

      <xsd:element name="derivedFrom" minOccurs="0"/>

             Figure 12: 13: Initial xml XML for the LFB class inheritance Class Inheritance
      <xsd:element name="derivedFrom" minOccurs="0">
        <xsd:complexType>
          <xsd:simpleContent>
            <xsd:extension base="xsd:NMTOKEN">
              <xsd:attribute name="version"
                type="versionType" use="optional"/>
            </xsd:extension>
          </xsd:simpleContent>
        </xsd:complexType>
      </xsd:element>

               Figure 13: 14: New xml XML for the LFB class inheritance Class Inheritance

   An example of the use of the version attribute is given in Figure 14 15.

      <derivedFrom version="1.0">EtherPHYCop</derivedFrom>

      Figure 14: 15: Example of use Use of new xml New XML for LFB class Class Inheritance

2.7.  Enhancing XML Validation

   As specified earlier 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 model [RFC5812].  Such validations work only on within the same xml
   XML file.

   This document introduces the following validation rules that did not
   exist in the original schema in [RFC5812]:

   1.  Each metadata ID metadataID must be unique.

   2.  LFB Class IDs  LFBClassIDs must be unique.

   3.  Component ID, Capability ID  componentID, capabilityID, and Event Base ID baseID must be unique per
       LFB.

   4.  Event IDs  eventIDs must be unique per LFB.

   5.  Special Values values in Atomic datatypes atomic data types must be unique per atomic
       datatype.
       data type.

3.  XML Extension Schema for LFB Class Library Documents

   This section includes the new XML Schema. schema.  Note that the namespace
   number has been updated from 1.0 to 1.1 1.1.

   The extensions described in this document are backwards compatible in
   terms of the operation of the ForCES protocol.  In terms of the XML,
   any definitions that were valid under the old namespace are valid
   under the new namespace.  It is to be noted that any auxiliary tools
   that are processing XML definitions written under both namespaces
   will need to be able to understand both.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
   xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
   targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
   elementFormDefault="qualified" attributeFormDefault="unqualified">
   <xsd:annotation>
      <xsd:documentation xml:lang="en">
         Schema for Defining LFB Classes and associated types
         (frames, data types for LFB attributes, and metadata).
      </xsd:documentation>
   </xsd:annotation>
   <xsd:element name="description" type="xsd:string"/>
   <xsd:element name="synopsis" type="xsd:string"/>
   <!-- Document root element: LFBLibrary -->
   <xsd:element name="LFBLibrary">
      <xsd:complexType>
         <xsd:sequence>
            <xsd:element ref="description" minOccurs="0"/>
            <xsd:element name="load" type="loadType"
               minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="frameDefs" type="frameDefsType"
               minOccurs="0"/>
            <xsd:element name="dataTypeDefs" type="dataTypeDefsType"
               minOccurs="0"/>
            <xsd:element name="metadataDefs" type="metadataDefsType"
               minOccurs="0"/>
            <xsd:element name="LFBClassDefs" type="LFBClassDefsType"
               minOccurs="0"/>
         </xsd:sequence>
         <xsd:attribute name="provides" type="xsd:Name"
            use="required"/>
      </xsd:complexType>
      <!-- Uniqueness constraints -->
      <xsd:key name="frame">
         <xsd:selector xpath="lfb:frameDefs/lfb:frameDef"/>
         <xsd:field xpath="lfb:name"/>
      </xsd:key>
      <xsd:key name="dataType">
         <xsd:selector xpath="lfb:dataTypeDefs/lfb:dataTypeDef"/>
         <xsd:field xpath="lfb:name"/>
      </xsd:key>
      <xsd:key name="metadataDef">
         <xsd:selector xpath="lfb:metadataDefs/lfb:metadataDef"/>
         <xsd:field xpath="lfb:name"/>
      </xsd:key>
      <xsd:key name="metadataDefID">
         <xsd:selector xpath="lfb:metadataDefs/lfb:metadataDef"/>
         <xsd:field xpath="lfb:metadataID"/>
      </xsd:key>
      <xsd:key name="LFBClassDef">
         <xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
         <xsd:field xpath="lfb:name"/>
      </xsd:key>
      <xsd:key name="LFBClassDefID">
         <xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
         <xsd:field xpath="@LFBClassID"/>
      </xsd:key>
   </xsd:element>
   <xsd:complexType name="loadType">
      <xsd:attribute name="library" type="xsd:Name" use="required"/>
      <xsd:attribute name="location" type="xsd:anyURI"
         use="optional"/>
   </xsd:complexType>
   <xsd:complexType name="frameDefsType">
      <xsd:sequence>
         <xsd:element name="frameDef" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="dataTypeDefsType">
      <xsd:sequence>
         <xsd:element name="dataTypeDef" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
                     minOccurs="0"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
                  <xsd:group ref="typeDeclarationGroup"/>
                  <!-- Extension RFC XXXX 7408 -->
                  <xsd:element name="defaultValue" type="xsd:token"
                     minOccurs="0"/>
                  <!-- /Extension RFC XXXX 7408 -->
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <!-- Predefined (built-in) atomic data-types are: char, uchar,
   int16, uint16, int32, uint32, int64, uint64, string[N], string,
   byte[N], boolean, octetstring[N], float32, float64 -->
   <xsd:group name="typeDeclarationGroup">
      <xsd:choice>
         <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
         <xsd:element name="atomic" type="atomicType"/>
         <xsd:element name="array" type="arrayType">
            <!-- Extension RFC XXXX 7408 -->
            <!--declare
            <!-- declare keys to have unique IDs -->
            <xsd:key name="contentKeyID">
               <xsd:selector xpath="lfb:contentKey"/>
               <xsd:field xpath="@contentKeyID"/>
            </xsd:key>
            <!-- /Extension RFC XXXX 7408 -->
         </xsd:element>
         <xsd:element name="struct" type="structType">
            <!-- Extension RFC XXXX 7408 -->
            <!-- key declaration to make componentIDs
              unique in a struct -->
            <xsd:key name="structComponentID">
               <xsd:selector xpath="lfb:component"/>
               <xsd:field xpath="@componentID"/>
            </xsd:key>
            <!-- /Extension RFC XXXX 7408 -->
         </xsd:element>
         <xsd:element name="union" type="structType"/>
         <xsd:element name="alias" type="typeRefNMTOKEN"/>
      </xsd:choice>
   </xsd:group>
   <xsd:simpleType name="typeRefNMTOKEN">
      <xsd:restriction base="xsd:token">
         <xsd:pattern value="\c+"/>
         <xsd:pattern value="string\[\d+\]"/>
         <xsd:pattern value="byte\[\d+\]"/>
         <xsd:pattern value="octetstring\[\d+\]"/>
      </xsd:restriction>
   </xsd:simpleType>
   <xsd:complexType name="atomicType">
      <xsd:sequence>
         <xsd:element name="baseType" type="typeRefNMTOKEN"/>
         <xsd:element name="rangeRestriction"
           type="rangeRestrictionType" minOccurs="0"/>
         <xsd:element name="specialValues" type="specialValuesType"
            minOccurs="0">
            <!-- Extension RFC XXXX 7408 -->
            <xsd:key name="SpecialValue">
               <xsd:selector xpath="specialValue"/>
               <xsd:field xpath="@value"/>
            </xsd:key>
            <!-- /Extension RFC XXXX 7408 -->
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="rangeRestrictionType">
      <xsd:sequence>
         <xsd:element name="allowedRange" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:attribute name="min" type="xsd:integer"
                  use="required"/>
               <xsd:attribute name="max" type="xsd:integer"
                  use="required"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="specialValuesType">
      <xsd:sequence>
         <xsd:element name="specialValue" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
               </xsd:sequence>
               <xsd:attribute name="value" type="xsd:token"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="arrayType">
      <xsd:sequence>
         <xsd:group ref="typeDeclarationGroup"/>
         <xsd:element name="contentKey" minOccurs="0"
            maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="contentKeyField"
                     type="xsd:string" maxOccurs="unbounded"/>
               </xsd:sequence>
               <xsd:attribute name="contentKeyID" type="xsd:integer"
                  use="required"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="type" use="optional" default="variable-size">
         <xsd:simpleType>
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="fixed-size"/>
               <xsd:enumeration value="variable-size"/>
            </xsd:restriction>
         </xsd:simpleType>
      </xsd:attribute>
      <xsd:attribute name="length" type="xsd:integer"
         use="optional"/>
      <xsd:attribute name="maxLength" type="xsd:integer"
         use="optional"/>
   </xsd:complexType>
   <xsd:complexType name="structType">
      <xsd:sequence>
         <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
            minOccurs="0"/>
         <xsd:element name="component" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
                  <xsd:element name="optional" minOccurs="0"/>
                  <xsd:group ref="typeDeclarationGroup"/>
               </xsd:sequence>
               <!-- Extension RFC XXXX 7408 -->
               <xsd:attribute name="access" use="optional"
                  default="read-write">
                  <xsd:simpleType>
                     <xsd:list itemType="accessModeType"/>
                  </xsd:simpleType>
               </xsd:attribute>
               <!-- Extension RFC XXXX 7408 -->
               <xsd:attribute name="componentID" type="xsd:unsignedInt"
                  use="required"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="metadataDefsType">
      <xsd:sequence>
         <xsd:element name="metadataDef" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element name="metadataID" type="xsd:integer"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
                  <xsd:choice>
                     <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
                     <xsd:element name="atomic" type="atomicType"/>
                     <!-- Extension RFC XXXX 7408 -->
                     <xsd:element name="array" type="arrayType">
                        <!--declare keys to have unique IDs -->
                        <xsd:key name="contentKeyID1">
                           <xsd:selector xpath="lfb:contentKey"/>
                           <xsd:field xpath="@contentKeyID"/>
                        </xsd:key>
                        <!-- /Extension RFC XXXX 7408 -->
                     </xsd:element>
                     <xsd:element name="struct" type="structType">
                        <!-- Extension RFC XXXX 7408 -->
                        <!-- key declaration to make componentIDs
                           unique in a struct -->
                        <xsd:key name="structComponentID1">
                           <xsd:selector xpath="lfb:component"/>
                           <xsd:field xpath="@componentID"/>
                        </xsd:key>
                        <!-- /Extension RFC XXXX 7408 -->
                     </xsd:element>
                  </xsd:choice>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="LFBClassDefsType">
      <xsd:sequence>
         <xsd:element name="LFBClassDef" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element name="version" type="versionType"/>
                  <xsd:element name="derivedFrom" minOccurs="0">
                    <xsd:complexType>
                      <xsd:simpleContent>
                        <xsd:extension base="xsd:NMTOKEN">
                          <xsd:attribute name="version"
                            type="versionType" use="optional"/>
                        </xsd:extension>
                      </xsd:simpleContent>
                    </xsd:complexType>
                  </xsd:element>
                  <xsd:element name="inputPorts"
                   type="inputPortsType" minOccurs="0"/>
                  <xsd:element name="outputPorts"
                   type="outputPortsType" minOccurs="0"/>
                  <xsd:element name="components"
                   type="LFBComponentsType" minOccurs="0"/>
                  <xsd:element name="capabilities"
                   type="LFBCapabilitiesType" minOccurs="0"/>
                  <xsd:element name="events" type="eventsType"
                     minOccurs="0"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
               </xsd:sequence>
               <xsd:attribute name="LFBClassID" type="xsd:unsignedInt"
                  use="required"/>
            </xsd:complexType>
            <!-- Key constraint to ensure unique attribute names
            within a class: -->
            <xsd:key name="components">
               <xsd:selector xpath="lfb:components/lfb:component"/>
               <xsd:field xpath="lfb:name"/>
            </xsd:key>
            <xsd:key name="capabilities">
               <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
               <xsd:field xpath="lfb:name"/>
            </xsd:key>
            <xsd:key name="events">
               <xsd:selector xpath="lfb:events/lfb:event"/>
               <xsd:field xpath="lfb:name"/>
            </xsd:key>
            <xsd:key name="eventsIDs">
               <xsd:selector xpath="lfb:events/lfb:event"/>
               <xsd:field xpath="@eventID"/>
            </xsd:key>
            <xsd:key name="componentIDs">
               <xsd:selector xpath="lfb:components/lfb:component"/>
               <xsd:field xpath="@componentID"/>
            </xsd:key>
            <xsd:key name="capabilityIDs">
               <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
               <xsd:field xpath="@componentID"/>
            </xsd:key>
            <xsd:key name="ComponentCapabilityComponentIDUniqueness">
               <xsd:selector
                  xpath="lfb:components/lfb:component|
                  lfb:capabilities/lfb:capability|lfb:events"/>
               <xsd:field xpath="@componentID|@baseID"/>
            </xsd:key>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:simpleType name="versionType">
      <xsd:restriction base="xsd:NMTOKEN">
         <xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
      </xsd:restriction>
   </xsd:simpleType>
   <xsd:complexType name="inputPortsType">
      <xsd:sequence>
         <xsd:element name="inputPort" type="inputPortType"
            maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="inputPortType">
      <xsd:sequence>
         <xsd:element name="name" type="xsd:NMTOKEN"/>
         <xsd:element ref="synopsis"/>
         <xsd:element name="expectation" type="portExpectationType"/>
         <xsd:element ref="description" minOccurs="0"/>
      </xsd:sequence>
      <xsd:attribute name="group" type="xsd:boolean"
         use="optional" default="0"/>
   </xsd:complexType>
   <xsd:complexType name="portExpectationType">
      <xsd:sequence>
         <xsd:element name="frameExpected" minOccurs="0">
            <xsd:complexType>
               <xsd:sequence>
                  <!-- ref must refer to a name of a defined
                    frame type -->
                  <xsd:element name="ref" type="xsd:string"
                     maxOccurs="unbounded"/>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
         <xsd:element name="metadataExpected" minOccurs="0">
            <xsd:complexType>
               <xsd:choice maxOccurs="unbounded">
                  <!--ref must refer to a name of a defined metadata-->
                  <xsd:element name="ref" type="metadataInputRefType"/>
                  <xsd:element name="one-of"
                     type="metadataInputChoiceType"/>
               </xsd:choice>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="metadataInputChoiceType">
      <xsd:choice minOccurs="2" maxOccurs="unbounded">
         <!-- ref must refer to a name of a defined metadata -->
         <xsd:element name="ref" type="xsd:NMTOKEN"/>
         <xsd:element name="one-of" type="metadataInputChoiceType"/>
         <xsd:element name="metadataSet" type="metadataInputSetType"/>
      </xsd:choice>
   </xsd:complexType>
   <xsd:complexType name="metadataInputSetType">
      <xsd:choice minOccurs="2" maxOccurs="unbounded">
         <!-- ref must refer to a name of a defined metadata -->
         <xsd:element name="ref" type="metadataInputRefType"/>
         <xsd:element name="one-of" type="metadataInputChoiceType"/>
      </xsd:choice>
   </xsd:complexType>
   <xsd:complexType name="metadataInputRefType">
      <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKEN">
            <xsd:attribute name="dependency" use="optional"
               default="required">
               <xsd:simpleType>
                  <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="required"/>
                     <xsd:enumeration value="optional"/>
                  </xsd:restriction>
               </xsd:simpleType>
            </xsd:attribute>
            <xsd:attribute name="defaultValue" type="xsd:token"
               use="optional"/>
         </xsd:extension>
      </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="outputPortsType">
      <xsd:sequence>
         <xsd:element name="outputPort" type="outputPortType"
            maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="outputPortType">
      <xsd:sequence>
         <xsd:element name="name" type="xsd:NMTOKEN"/>
         <xsd:element ref="synopsis"/>
         <xsd:element name="product" type="portProductType"/>
         <xsd:element ref="description" minOccurs="0"/>
      </xsd:sequence>
      <xsd:attribute name="group" type="xsd:boolean"
         use="optional" default="0"/>
   </xsd:complexType>
   <xsd:complexType name="portProductType">
      <xsd:sequence>
         <xsd:element name="frameProduced" minOccurs="0">
            <xsd:complexType>
               <xsd:sequence>
                  <!-- ref must refer to a name of a defined
                     frame type -->
                  <xsd:element name="ref" type="xsd:NMTOKEN"
                     maxOccurs="unbounded"/>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
         <xsd:element name="metadataProduced" minOccurs="0">
            <xsd:complexType>
               <xsd:choice maxOccurs="unbounded">
                  <!-- ref must refer to a name of a
                     defined metadata -->
                  <xsd:element name="ref"
                     type="metadataOutputRefType"/>
                  <xsd:element name="one-of"
                     type="metadataOutputChoiceType"/>
               </xsd:choice>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="metadataOutputChoiceType">
      <xsd:choice minOccurs="2" maxOccurs="unbounded">
         <!-- ref must refer to a name of a defined metadata -->
         <xsd:element name="ref" type="xsd:NMTOKEN"/>
         <xsd:element name="one-of" type="metadataOutputChoiceType"/>
         <xsd:element name="metadataSet" type="metadataOutputSetType"/>
      </xsd:choice>
   </xsd:complexType>
   <xsd:complexType name="metadataOutputSetType">
      <xsd:choice minOccurs="2" maxOccurs="unbounded">
         <!-- ref must refer to a name of a defined metadata -->
         <xsd:element name="ref" type="metadataOutputRefType"/>
         <xsd:element name="one-of" type="metadataOutputChoiceType"/>
      </xsd:choice>
   </xsd:complexType>
   <xsd:complexType name="metadataOutputRefType">
      <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKEN">
            <xsd:attribute name="availability" use="optional"
               default="unconditional">
               <xsd:simpleType>
                  <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="unconditional"/>
                     <xsd:enumeration value="conditional"/>
                  </xsd:restriction>
               </xsd:simpleType>
            </xsd:attribute>
         </xsd:extension>
      </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="LFBComponentsType">
      <xsd:sequence>
         <xsd:element name="component" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
                  <xsd:element name="optional" minOccurs="0"/>
                  <xsd:group ref="typeDeclarationGroup"/>
                  <xsd:element name="defaultValue" type="xsd:token"
                     minOccurs="0"/>
               </xsd:sequence>
               <xsd:attribute name="access" use="optional"
                  default="read-write">
                  <xsd:simpleType>
                     <xsd:list itemType="accessModeType"/>
                  </xsd:simpleType>
               </xsd:attribute>
               <!-- Extension Added added restriction to component ID componentID -->
               <xsd:attribute name="componentID" use="required">
                  <xsd:simpleType>
                     <xsd:restriction base="xsd:unsignedInt">
                        <xsd:minExclusive value="0"/>
                     </xsd:restriction>
                  </xsd:simpleType>
               </xsd:attribute>
               <!-- End of extension -->
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:simpleType name="accessModeType">
      <xsd:restriction base="xsd:NMTOKEN">
         <xsd:enumeration value="read-only"/>
         <xsd:enumeration value="read-write"/>
         <xsd:enumeration value="write-only"/>
         <xsd:enumeration value="read-reset"/>
         <xsd:enumeration value="trigger-only"/>
      </xsd:restriction>
   </xsd:simpleType>
   <xsd:complexType name="LFBCapabilitiesType">
      <xsd:sequence>
         <xsd:element name="capability" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
                  <xsd:element name="optional" minOccurs="0"/>
                  <xsd:group ref="typeDeclarationGroup"/>
               </xsd:sequence>
               <xsd:attribute name="componentID" type="xsd:integer"
                  use="required"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="eventsType">
      <xsd:sequence>
         <xsd:element name="event" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="name" type="xsd:NMTOKEN"/>
                  <xsd:element ref="synopsis"/>
                  <xsd:element name="eventTarget"
                    type="eventPathType"/>
                  <xsd:element ref="eventCondition"/>
                  <xsd:element name="eventReports"
                   type="eventReportsType" minOccurs="0"/>
                  <xsd:element ref="description"
                     minOccurs="0"/>
               </xsd:sequence>
               <xsd:attribute name="eventID" type="xsd:integer"
                  use="required"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="baseID" type="xsd:integer"
         use="optional"/>
   </xsd:complexType>
   <!-- the substitution group for the event conditions -->
   <xsd:element name="eventCondition" abstract="true"/>
   <xsd:element name="eventCreated"
    substitutionGroup="eventCondition"/>
   <xsd:element name="eventDeleted"
    substitutionGroup="eventCondition"/>
   <xsd:element name="eventChanged"
    substitutionGroup="eventCondition"/>
   <xsd:element name="eventGreaterThan"
    substitutionGroup="eventCondition"/>
   <xsd:element name="eventLessThan"
    substitutionGroup="eventCondition"/>
   <!-- Extension RFC XXXX 7408 -->
   <xsd:element name="eventBecomesEqualTo"
      substitutionGroup="eventCondition"/>
   <!-- /Extension RFC XXXX 7408 -->
   <xsd:complexType name="eventPathType">
      <xsd:sequence>
         <xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
   <!-- the substitution group for the event path parts -->
   <xsd:element name="eventPathPart" type="xsd:string"
      abstract="true"/>
   <xsd:element name="eventField" type="xsd:string"
      substitutionGroup="eventPathPart"/>
   <xsd:element name="eventSubscript" type="xsd:string"
      substitutionGroup="eventPathPart"/>
   <xsd:complexType name="eventReportsType">
      <xsd:sequence>
         <xsd:element name="eventReport" type="eventPathType"
            maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:simpleType name="booleanType">
      <xsd:restriction base="xsd:string">
         <xsd:enumeration value="0"/>
         <xsd:enumeration value="1"/>
      </xsd:restriction>
   </xsd:simpleType>
</xsd:schema>

                           ForCES LFB XML Schema

5.

4.  IANA Considerations

   IANA has registered a new XML namespace, as per the guidelines in RFC
   3688 [RFC3688].

   URI: The URI for this namespace is is:

      urn:ietf:params:xml:ns:forces:lfbmodel:1.1

   Registrant Contact: IESG

   XML: none, this is an XML namespace

6.

5.  Security Considerations

   This specification adds only a few constructs to the initial model
   defined in [RFC5812], namely namely namely, a new event, some new properties properties, and a
   way to define optional access types and complex metadata.  In
   addition
   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 update to the inheritance model change do
   not change the nature of the initial model.

   Thus

   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]. [RFC5812] does.
   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 regard to pervasive monitoring (PM), as discussed in [RFC7258],
   this specification defines ways to expose more complex information,
   namely metadata, 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 ways to (ab)use LFBs for PM.  The same
   applies for the new event.

   Finally, this document does not provide any protocol specification
   and
   and, as such such, does not specifies specify how information will be transmitted
   between respective entities, thus entities.  Thus, PM mitigation for a passive
   attacker that simply wants to eavesdrop on the information exchanged
   is out of scope.

7. the scope of this document.

6.  References

7.1.

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004. 2004, <http://www.rfc-editor.org/info/rfc3688>.

   [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. 2010,
              <http://www.rfc-editor.org/info/rfc5810>.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model", RFC
              5812, March 2010. 2010,
              <http://www.rfc-editor.org/info/rfc5812>.

   [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.
              2014, <http://www.rfc-editor.org/info/rfc7121>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014.

7.2. 2014,
              <http://www.rfc-editor.org/info/rfc7258>.

6.2.  Informative References

   [OpenFlowSpec1.1]
              http://www.OpenFlow.org/, "The OpenFlow 1.1
              Specification.", <http://www.OpenFlow.org/documents/
              OpenFlow-spec-v1.1.0.pdf>.

4.
              ONF, "OpenFlow Switch Specification", February 2011,
              <https://www.opennetworking.org/images/stories/downloads/
              sdn-resources/onf-specifications/openflow/openflow-spec-
              v1.1.0.pdf>.

Acknowledgements

   The author would like to acknowledge Joel Halpern, Jamal Hadi Salim Salim,
   and Dave Hood for their comments and discussion that helped shape
   this document in a better way. for the better.  Special acknowledgements to Joel
   Halpern for resolving the issue with the default values. values, Adrian
   Farrel for his AD review, Ben Campbell for his Gen-ART review review, and
   Tom Yu for his security review, all of which improved the quality of
   this document.  Additionally  Additionally, reviews and comments by the following
   members of the IESG shaped the final version of this document:
   Stephen Farrel, Barry Leiba Leiba, and Ted Lemon Lemon.  Finally, the author
   would like to acknowledge Julian Reschke for their reviews and comments that
   shaped input regarding the final version of this document.
   namespace change issue and Joel Halpern for helping to resolve it.

Author's Address

   Evangelos Haleplidis
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500
   Greece

   Email:

   EMail: ehalep@ece.upatras.gr