draft-ietf-forces-model-12.txt   draft-ietf-forces-model-13.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Expires: January 15, 2009 E. Deleganes Expires: February 19, 2009 J. Hadi Salim
Intel Corp.
J. Hadi Salim
Znyx Networks Znyx Networks
July 14, 2008 August 18, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-12.txt draft-ietf-forces-model-13.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on February 19, 2009.
Comments are solicited and should be addressed to the working group's Comments are solicited and should be addressed to the working group's
mailing list at forces@peach.ease.lsoft.com and/or the author(s). mailing list at forces@peach.ease.lsoft.com and/or the author(s).
Abstract Abstract
This document defines the forwarding element (FE) model used in the This document defines the forwarding element (FE) model used in the
Forwarding and Control Element Separation (ForCES) protocol [2]. The Forwarding and Control Element Separation (ForCES) protocol [2]. The
model represents the capabilities, state and configuration of model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so forwarding elements within the context of the ForCES protocol, so
skipping to change at page 49, line 18 skipping to change at page 49, line 18
an array of a compound or an atomic data type. Depending upon an array of a compound or an atomic data type. Depending upon
context, this document, and others, refer to such arrays as tables or context, this document, and others, refer to such arrays as tables or
arrays interchangeably, without semantic or syntactic implication. arrays interchangeably, without semantic or syntactic implication.
The type of the array entry can be specified either by referring to The type of the array entry can be specified either by referring to
an existing type (using the <typeRef> element) or defining an unnamed an existing type (using the <typeRef> element) or defining an unnamed
type inside the <array> element using any of the <atomic>, <array>, type inside the <array> element using any of the <atomic>, <array>,
<struct>, or <union> elements. <struct>, or <union> elements.
The array can be "fixed-size" or "variable-size", which is specified The array can be "fixed-size" or "variable-size", which is specified
by the "type" attribute of the <array> element. The default is by the "type" attribute of the <array> element. The default is
"variable-size". For variable size arrays, an optional "max-length" "variable-size". For variable size arrays, an optional "maxlength"
attribute specifies the maximum allowed length. This attribute attribute specifies the maximum allowed length. This attribute
should be used to encode semantic limitations, not implementation should be used to encode semantic limitations, not implementation
limitations. The latter should be handled by capability components limitations. The latter should be handled by capability components
of LFB classes, and should never be included in a data type array of LFB classes, and should never be included in a data type array
which is regarded as of unlimited-size. which is regarded as of unlimited-size.
For fixed-size arrays, a "length" attribute MUST be provided that For fixed-size arrays, a "length" attribute MUST be provided that
specifies the constant size of the array. specifies the constant size of the array.
The result of this construct MUST always be a compound type, even if The result of this construct MUST always be a compound type, even if
skipping to change at page 51, line 21 skipping to change at page 51, line 21
<typeRef>dscp</typeRef> <typeRef>dscp</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
The following example defines a variable size array with an upper The following example defines a variable size array with an upper
limit on its size: limit on its size:
<dataTypeDef> <dataTypeDef>
<name>mac-alias-table</name> <name>mac-alias-table</name>
<synopsis>A table with up to 8 IEEE MAC addresses</synopsis> <synopsis>A table with up to 8 IEEE MAC addresses</synopsis>
<array type="variable-size" max-length="8"> <array type="variable-size" maxlength="8">
<typeRef>ieeemacaddr</typeRef> <typeRef>ieeemacaddr</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
The following example shows the definition of an array with a local The following example shows the definition of an array with a local
(unnamed) content type definition: (unnamed) content type definition:
<dataTypeDef> <dataTypeDef>
<name>classification-table</name> <name>classification-table</name>
<synopsis> <synopsis>
skipping to change at page 52, line 36 skipping to change at page 52, line 36
the protocol or process providing this information the protocol or process providing this information
</synopsis> </synopsis>
<typeRef>uint16</typeRef> <typeRef>uint16</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>prefInfo</name> <name>prefInfo</name>
<synopsis>the information we care about</synopsis> <synopsis>the information we care about</synopsis>
<typeRef>hypothetical-info-type</typeRef> <typeRef>hypothetical-info-type</typeRef>
</component> </component>
</struct> </struct>
<key keyID="1"> <contentKey keyID="1">
<keyField> address-prefix.ipv4addr </keyField> <contentKeyField> address-prefix.ipv4addr </keyField>
<keyField> address-prefix.prefixlen </keyField> <contentKeyField> address-prefix.prefixlen </keyField>
<keyField> source </keyField> <contentKeyField> source </keyField>
</key> </key>
</array> </array>
</dataTypeDef> </dataTypeDef>
Note that the keyField elements could also have been simply address- Note that the keyField elements could also have been simply address-
prefix and source, since all of the fields of address-prefix are prefix and source, since all of the fields of address-prefix are
being used. being used.
4.5.3.1. Key Field References 4.5.3.1. Key Field References
skipping to change at page 57, line 16 skipping to change at page 57, line 16
The second form is an explicit type definition using the <atomic> The second form is an explicit type definition using the <atomic>
element. This element is used here in the same way as in the element. This element is used here in the same way as in the
<dataTypeDef> elements. <dataTypeDef> elements.
The following example shows both usages: The following example shows both usages:
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>NEXTHOPID</name> <name>NEXTHOPID</name>
<synopsis>Refers to a Next Hop entry in NH LFB</synopsis> <synopsis>Refers to a Next Hop entry in NH LFB</synopsis>
<metadataID>17</metaDataID> <metadataID>17</metadataID>
<typeRef>int32</typeRef> <typeRef>int32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>CLASSID</name> <name>CLASSID</name>
<synopsis> <synopsis>
Result of classification (0 means no match). Result of classification (0 means no match).
</synopsis> </synopsis>
<metadataID>21</metadataID> <metadataID>21</metadataID>
<atomic> <atomic>
<baseType>int32</baseType> <baseType>int32</baseType>
skipping to change at page 67, line 20 skipping to change at page 67, line 20
Whether optional components are supported, and whether components Whether optional components are supported, and whether components
defined as read-write can actually be written can be determined for a defined as read-write can actually be written can be determined for a
given LFB instance by the CE by reading the property information of given LFB instance by the CE by reading the property information of
that component. An access control setting of "trigger-only" means that component. An access control setting of "trigger-only" means
that this component is included only for use in event detection. that this component is included only for use in event detection.
The following example defines two components for an LFB: The following example defines two components for an LFB:
<components> <components>
<component access="read-only" componentID=1> <component access="read-only" componentID="1">
<name>foo</name> <name>foo</name>
<synopsis>number of things</synopsis> <synopsis>number of things</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component access="read-write" componentID=2> <component access="read-write" componentID="2">
<name>bar</name> <name>bar</name>
<synopsis>number of this other thing</synopsis> <synopsis>number of this other thing</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="10" max="2000"/> <allowedRange min="10" max="2000"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
<defaultValue>10</defaultValue> <defaultValue>10</defaultValue>
</component> </component>
</component> </components>
The first component ("foo") is a read-only 32-bit unsigned integer, The first component ("foo") is a read-only 32-bit unsigned integer,
defined by referring to the built-in "uint32" atomic type. The defined by referring to the built-in "uint32" atomic type. The
second component ("bar") is also an integer, but uses the <atomic> second component ("bar") is also an integer, but uses the <atomic>
element to provide additional range restrictions. This component has element to provide additional range restrictions. This component has
access mode of read-write allowing it to be both read and written. A access mode of read-write allowing it to be both read and written. A
default value of 10 is provided for bar. although the access for bar default value of 10 is provided for bar. although the access for bar
is read-write, some implementations may offer only more restrictive is read-write, some implementations may offer only more restrictive
access, and this would be reported in the component properties. access, and this would be reported in the component properties.
skipping to change at page 72, line 6 skipping to change at page 72, line 6
<eventField>field1</eventField> <eventField>field1</eventField>
</eventTarget> </eventTarget>
<eventChanged/> <eventChanged/>
<eventReports> <eventReports>
<eventReport> <eventReport>
<eventField>gah</eventField> <eventField>gah</eventField>
<eventSubscript>10</eventSubscript> <eventSubscript>10</eventSubscript>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
<events> </events>
4.7.6.1. <eventTarget> Element 4.7.6.1. <eventTarget> Element
The <eventTarget> element contains information identifying a field in The <eventTarget> element contains information identifying a field in
the LFB that is to be monitored for events. the LFB that is to be monitored for events.
The <eventTarget> element contains one or more <eventField> each of The <eventTarget> element contains one or more <eventField> each of
which may be followed by one or more <eventSubscript> elements. Each which may be followed by one or more <eventSubscript> elements. Each
of these two elements represent the textual equivalent of a path of these two elements represent the textual equivalent of a path
select component of the LFB. select component of the LFB.
skipping to change at page 79, line 12 skipping to change at page 79, line 12
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.8.2. Array Properties 4.8.2. Array Properties
The properties for an array add a number of important pieces of The properties for an array add a number of important pieces of
information. These properties are also read-only. information. These properties are also read-only.
<dataTypeDef> <dataTypeDef>
<name>arrayElementProperties</name> <name>arrayElementProperties</name>
<synopsis>Array Element Properties definition</synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>entryCount</name> <name>entryCount</name>
<synopsis>the number of entries in the array</synopsis> <synopsis>the number of entries in the array</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>highestUsedSubscript</name> <name>highestUsedSubscript</name>
<synopsis>the last used subscript in the array</synopsis> <synopsis>the last used subscript in the array</synopsis>
skipping to change at page 80, line 7 skipping to change at page 80, line 7
4.8.3. String Properties 4.8.3. String Properties
The properties of a string specify the actual octet length and the The properties of a string specify the actual octet length and the
maximum octet length for the element. The maximum length is included maximum octet length for the element. The maximum length is included
because an FE implementation may limit a string to be shorter than because an FE implementation may limit a string to be shorter than
the limit in the LFB Class definition. the limit in the LFB Class definition.
<dataTypeDef> <dataTypeDef>
<name>stringElementProperties</name> <name>stringElementProperties</name>
<synopsis>string Element Properties definition </synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>stringLength</name> <name>stringLength</name>
<synopsis>the number of octets in the string</synopsis> <synopsis>the number of octets in the string</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>maxStringLength</name> <name>maxStringLength</name>
<synopsis> <synopsis>
skipping to change at page 80, line 32 skipping to change at page 80, line 33
</dataTypeDef> </dataTypeDef>
4.8.4. Octetstring Properties 4.8.4. Octetstring Properties
The properties of an octetstring specify the actual length and the The properties of an octetstring specify the actual length and the
maximum length, since the FE implementation may limit an octetstring maximum length, since the FE implementation may limit an octetstring
to be shorter than the LFB Class definition. to be shorter than the LFB Class definition.
<dataTypeDef> <dataTypeDef>
<name>octetstringElementProperties</name> <name>octetstringElementProperties</name>
<synopsis>octetstring Element Properties definition
</synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>octetstringLength</name> <name>octetstringLength</name>
<synopsis> <synopsis>
the number of octets in the octetstring the number of octets in the octetstring
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
skipping to change at page 82, line 7 skipping to change at page 82, line 7
notifications for oscillations around a condition value, and is notifications for oscillations around a condition value, and is
described in the text for events. The threshold field is used for described in the text for events. The threshold field is used for
the <eventGreaterThan/> and <eventLessThan/> conditions. It the <eventGreaterThan/> and <eventLessThan/> conditions. It
indicates the value to compare the event target against. Using the indicates the value to compare the event target against. Using the
properties allows the CE to set the level of interest. FEs which do properties allows the CE to set the level of interest. FEs which do
not supporting setting the threshold for events will make this field not supporting setting the threshold for events will make this field
read-only. read-only.
<dataTypeDef> <dataTypeDef>
<name>eventElementProperties</name> <name>eventElementProperties</name>
<synopsis>event Element Properties definition</synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>registration</name> <name>registration</name>
<synopsis> <synopsis>
has the CE registered to be notified of this event has the CE registered to be notified of this event
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>threshold</name> <name>threshold</name>
<synopsis> comparison value for level crossing events <synopsis> comparison value for level crossing events
</synopsis> </synopsis>
</optional <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>eventHysteresis</name> <name>eventHysteresis</name>
<synopsis> region to suppress event recurrence notices <synopsis> region to suppress event recurrence notices
</synopsis> </synopsis>
</optional> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>eventCount</name> <name>eventCount</name>
<synopsis> number of occurrences to suppress <synopsis> number of occurrences to suppress
</synopsis> </synopsis>
</optional> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>eventInterval</name> <name>eventInterval</name>
<synopsis> time interval in ms between notifications <synopsis> time interval in ms between notifications
</synopsis> </synopsis>
</optional> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
<dataTypeDef> <dataTypeDef>
4.8.5.1. Common Event Filtering 4.8.5.1. Common Event Filtering
The event properties have values for controlling several filter The event properties have values for controlling several filter
conditions. Support of these conditions is optional, but all conditions. Support of these conditions is optional, but all
conditions SHOULD be supported. Events which are reliably known not conditions SHOULD be supported. Events which are reliably known not
skipping to change at page 85, line 8 skipping to change at page 85, line 8
detection MUST be restarted. detection MUST be restarted.
4.8.6. Alias Properties 4.8.6. Alias Properties
The properties for an alias add three (usually) writeable fields. The properties for an alias add three (usually) writeable fields.
These combine to identify the target component the subject alias These combine to identify the target component the subject alias
refers to. refers to.
<dataTypeDef> <dataTypeDef>
<name>aliasElementProperties</name> <name>aliasElementProperties</name>
<synopsis>alias Element Properties defintion</synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>targetLFBClass</name> <name>targetLFBClass</name>
<synopsis>the class ID of the alias target</synopsis> <synopsis>the class ID of the alias target</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>targetLFBInstance</name> <name>targetLFBInstance</name>
<synopsis>the instance ID of the alias target</synopsis> <synopsis>the instance ID of the alias target</synopsis>
skipping to change at page 90, line 47 skipping to change at page 90, line 48
a class: a class:
--> -->
<xsd:key name="components"> <xsd:key name="components">
<xsd:selector xpath="lfb:components/lfb:component"/> <xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="lfb:name"/> <xsd:field xpath="lfb:name"/>
</xsd:key> </xsd:key>
<xsd:key name="capabilities"> <xsd:key name="capabilities">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/> <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="lfb:name"/> <xsd:field xpath="lfb:name"/>
</xsd:key> </xsd:key>
<!-- does the above ensure that attributes and capabilities
have different names?
If so, the following is the componentID constraint
-->
<xsd:key name="componentIDs"> <xsd:key name="componentIDs">
<xsd:selector xpath="lfb:components/lfb:component"/> <xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="@componentID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
<xsd:key name="capabilityIDs"> <xsd:key name="capabilityIDs">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/> <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="@componentID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
skipping to change at page 99, line 45 skipping to change at page 99, line 42
</component> </component>
<component componentID="8"> <component componentID="8">
<name>UseableParentLFBClasses</name> <name>UseableParentLFBClasses</name>
<synopsis> <synopsis>
List of LFB Classes from which this class has List of LFB Classes from which this class has
inherited, and which the FE is willing to allow inherited, and which the FE is willing to allow
for references to instances of this class. for references to instances of this class.
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>uint32</typeref> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEStateValues</name> <name>FEStateValues</name>
<synopsis>The possible values of status</synopsis> <synopsis>The possible values of status</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
skipping to change at page 129, line 36 skipping to change at page 129, line 36
Table 1 Table 1
[Note to RFC Editor, RFCxxxx above is to be changed to the RFC number [Note to RFC Editor, RFCxxxx above is to be changed to the RFC number
assigned to this document for publication.] assigned to this document for publication.]
10. Authors Emeritus 10. Authors Emeritus
The following are the authors who were instrumental in the creation The following are the authors who were instrumental in the creation
of earlier releases of this document. of earlier releases of this document.
Ellen Delganes, Intel Corp.
Lily Yang, Intel Corp. Lily Yang, Intel Corp.
Ram Gopal, Nokia Research Center Ram Gopal, Nokia Research Center
Alan DeKok, Infoblox, Inc. Alan DeKok, Infoblox, Inc.
Zsolt Haraszti, Clovis Solutions Zsolt Haraszti, Clovis Solutions
11. Acknowledgments 11. Acknowledgments
Many of the colleagues in our companies and participants in the Many of the colleagues in our companies and participants in the
ForCES mailing list have provided invaluable input into this work. ForCES mailing list have provided invaluable input into this work.
Particular thanks to Evangelos Haleplidis for help getting the XML Particular thanks to Evangelos Haleplidis for help getting the XML
skipping to change at page 131, line 27 skipping to change at page 131, line 27
Authors' Addresses Authors' Addresses
Joel Halpern Joel Halpern
Self Self
P.O. Box 6049 P.O. Box 6049
Leesburg,, VA 20178 Leesburg,, VA 20178
Phone: +1 703 371 3043 Phone: +1 703 371 3043
Email: jmh@joelhalpern.com Email: jmh@joelhalpern.com
Ellen Deleganes
Intel Corp.
Mail Stop: CO5-156 15400 NW Greenbrier Parkway
Beaverton,, OR 97006
Phone: +1 503 677-4996
Email: ellen.m.deleganes@intel.com
Jamal Hadi Salim Jamal Hadi Salim
Znyx Networks Znyx Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@znyx.com Email: hadi@znyx.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
 End of changes. 25 change blocks. 
34 lines changed or deleted 27 lines changed or added

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