draft-ietf-forces-model-13.txt   draft-ietf-forces-model-14.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Expires: February 19, 2009 J. Hadi Salim Intended status: Standards Track J. Hadi Salim
Znyx Networks Expires: February 25, 2009 Znyx Networks
August 18, 2008 August 24, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-13.txt draft-ietf-forces-model-14.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 35 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 February 19, 2009. This Internet-Draft will expire on February 25, 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 2, line 28 skipping to change at page 2, line 28
3.1.1. FE Capability Model and State Model . . . . . . . . . 12 3.1.1. FE Capability Model and State Model . . . . . . . . . 12
3.1.2. Relating LFB and FE Capability and State Model . . . 13 3.1.2. Relating LFB and FE Capability and State Model . . . 13
3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14 3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14
3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20 3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Component Properties . . . . . . . . . . . . . . . . 28 3.2.6. Component Properties . . . . . . . . . . . . . . . . 28
3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 28 3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 28
3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 28 3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 29
3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 29 3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 30
3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31 3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31
3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32 3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32
3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32 3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32
3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36 3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36
4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40 4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40
4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41 4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41
4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 43 4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 43
4.4. <frameDefs> Element for Frame Type Declarations . . . . . 44 4.4. <frameDefs> Element for Frame Type Declarations . . . . . 44
4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44 4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44
skipping to change at page 11, line 25 skipping to change at page 11, line 25
The ForCES model allows for unique identification of the different The ForCES model allows for unique identification of the different
constructs it defines. This includes identification of the LFB constructs it defines. This includes identification of the LFB
classes, and of LFB instances within those classes, as well as classes, and of LFB instances within those classes, as well as
identification of components within those instances. identification of components within those instances.
The ForCES Protocol [2] encapsulates target address(es) to eventually The ForCES Protocol [2] encapsulates target address(es) to eventually
get to a fine-grained entity being referenced by the CE. The get to a fine-grained entity being referenced by the CE. The
addressing hierarchy is broken into the following: addressing hierarchy is broken into the following:
o An FE is uniqueuely identified by a 32 bit FEID. o An FE is uniquely identified by a 32 bit FEID.
o Each Class of LFB is uniquely identified by a 32 bit LFB ClassID. o Each Class of LFB is uniquely identified by a 32 bit LFB ClassID.
The LFB ClassIDs are global within the Network Element and may be The LFB ClassIDs are global within the Network Element and may be
issued by IANA. issued by IANA.
o Within an FE, there can be multiple instances of each LFB class. o Within an FE, there can be multiple instances of each LFB class.
Each LFB Class instance is identified by a 32 bit identifier which Each LFB Class instance is identified by a 32 bit identifier which
is unique within a particular LFB class on that FE. is unique within a particular LFB class on that FE.
o All the components within an LFB instance are further defined o All the components within an LFB instance are further defined
skipping to change at page 16, line 14 skipping to change at page 16, line 14
or there is effectively no input. (LFB operation generally may be or there is effectively no input. (LFB operation generally may be
triggered by input arrival, by timers, or by other system state. It triggered by input arrival, by timers, or by other system state. It
is only in the case where the goal is to have input drive operation is only in the case where the goal is to have input drive operation
that the input must be non-empty.) that the input must be non-empty.)
The LFB processes the input, and produces one or more outputs, each The LFB processes the input, and produces one or more outputs, each
of which is a pair of a packet and its associated metadata. Again, of which is a pair of a packet and its associated metadata. Again,
depending upon the LFB output port definition, either the packet or depending upon the LFB output port definition, either the packet or
the metadata may be allowed to be empty (or equivalently to be the metadata may be allowed to be empty (or equivalently to be
absent.) Metadata attached to packets on output may be metadata that absent.) Metadata attached to packets on output may be metadata that
was received, or may be information about the packet processsing that was received, or may be information about the packet processing that
may be used by later LFBs in the FEs packet processing. may be used by later LFBs in the FEs packet processing.
A namespace is used to associate a unique name and ID with each LFB A namespace is used to associate a unique name and ID with each LFB
class. The namespace MUST be extensible so that a new LFB class can class. The namespace MUST be extensible so that a new LFB class can
be added later to accommodate future innovation in the forwarding be added later to accommodate future innovation in the forwarding
plane. plane.
LFB operation is specified in the model to allow the CE to understand LFB operation is specified in the model to allow the CE to understand
the behavior of the forwarding datapath. For instance, the CE must the behavior of the forwarding datapath. For instance, the CE must
understand at what point in the datapath the IPv4 header TTL is understand at what point in the datapath the IPv4 header TTL is
skipping to change at page 20, line 44 skipping to change at page 20, line 44
o the frame type and set of metadata emitted on these outputs are o the frame type and set of metadata emitted on these outputs are
sufficiently similar or, ideally, identical, such they can share sufficiently similar or, ideally, identical, such they can share
the same output definition. the same output definition.
3.2.2. LFB Inputs 3.2.2. LFB Inputs
An LFB input is a conceptual port on an LFB on which the LFB can An LFB input is a conceptual port on an LFB on which the LFB can
receive information from other LFBs. The information is typically a receive information from other LFBs. The information is typically a
pair of a packet and its associated metadata. Either the packet, or pair of a packet and its associated metadata. Either the packet, or
the metadata, may for some LFBs and some situations be empty. They the metadata, may for some LFBs and some situations be empty. They
can not both be empty, as then there is no imput. can not both be empty, as then there is no input.
For LFB instances that receive packets from more than one other LFB For LFB instances that receive packets from more than one other LFB
instance (fan-in) there are three ways to model fan-in, all supported instance (fan-in) there are three ways to model fan-in, all supported
by the LFB model and can all be combined in the same LFB: by the LFB model and can all be combined in the same LFB:
o Implicit multiplexing via a single input o Implicit multiplexing via a single input
o Explicit multiplexing via multiple singleton inputs o Explicit multiplexing via multiple singleton inputs
o Explicit multiplexing via a group of inputs (input group) o Explicit multiplexing via a group of inputs (input group)
skipping to change at page 22, line 8 skipping to change at page 22, line 8
Layer 3 frames for encapsulation. This LFB type expects different Layer 3 frames for encapsulation. This LFB type expects different
frames (L2 vs. L3) at its inputs, each with different sets of frames (L2 vs. L3) at its inputs, each with different sets of
metadata, and would thus apply different processing on frames metadata, and would thus apply different processing on frames
arriving at these inputs. This model is capable of explicitly arriving at these inputs. This model is capable of explicitly
addressing packet contention by defining how the LFB class handles addressing packet contention by defining how the LFB class handles
the contending packets. the contending packets.
+--------------+ +------------------------+ +--------------+ +------------------------+
| LFB X +---+ | | | LFB X +---+ | |
+--------------+ | | | +--------------+ | | |
| | | | | | |
+--------------+ v | | +--------------+ v | |
| LFB Y +---+-->|input Meter LFB | | LFB Y +---+-->|input Meter LFB |
+--------------+ ^ | | +--------------+ ^ | |
| | | | | | |
+--------------+ | | | +--------------+ | | |
| LFB Z |---+ | | | LFB Z |---+ | |
+--------------+ +------------------------+ +--------------+ +------------------------+
(a) An LFB connects with multiple upstream LFBs via a single input. (a) An LFB connects with multiple upstream LFBs via a single input.
+--------------+ +------------------------+ +--------------+ +------------------------+
| LFB X +---+ | | | LFB X +---+ | |
+--------------+ +-->|layer2 | +--------------+ +-->|layer2 |
+--------------+ | | +--------------+ | |
skipping to change at page 25, line 19 skipping to change at page 25, line 19
involves multiple producers of the same metadata, then subsequent involves multiple producers of the same metadata, then subsequent
producers overwrite that metadata value. producers overwrite that metadata value.
The metadata that is produced by an LFB is specified by the LFB class The metadata that is produced by an LFB is specified by the LFB class
definition on a per-output-port-group basis. A producer may always definition on a per-output-port-group basis. A producer may always
generate the metadata on the port group, or may generate it only generate the metadata on the port group, or may generate it only
under certain conditions. We call the former an "unconditional" under certain conditions. We call the former an "unconditional"
metadata, whereas the latter is a "conditional" metadata. For metadata, whereas the latter is a "conditional" metadata. For
example, deep packet inspection LFB might produce several pieces of example, deep packet inspection LFB might produce several pieces of
metadata about the packet. The first metadatum might be the carried metadata about the packet. The first metadatum might be the carried
protocol (ICMP, TCP, UDP, SCTP, ...) For protocols that use port IP protocol (TCP, UDP, SCTP, ...), and two additional metadata items
numbers, the LFB might produce an additional metadatum carrying the might be the source and destination and destination port number.
source or destination port number. That would not be produced for These additional metadata items are conditional on the value of the
packets with no carried protocol, or that carry ICMP. In the case of first metadatum (IP carried protocol) as they are only produced for
conditional metadata, it should be possible to determine from the protocols which use port number. In the case of conditional
definition of the LFB when a "conditional" metadata is produced. The metadata, it should be possible to determine from the definition of
consumer behavior of an LFB, that is, the metadata that the LFB needs the LFB when a "conditional" metadata is produced. The consumer
for its operation, is defined in the LFB class definition on a per- behavior of an LFB, that is, the metadata that the LFB needs for its
input-port-group basis. An input port group may "require" a given operation, is defined in the LFB class definition on a per-input-
port-group basis. An input port group may "require" a given
metadata, or may treat it as "optional" information. In the latter metadata, or may treat it as "optional" information. In the latter
case, the LFB class definition MUST explicitly define what happens if case, the LFB class definition MUST explicitly define what happens if
an optional metadata is not provided. One approach is to specify a an optional metadata is not provided. One approach is to specify a
default value for each optional metadata, and assume that the default default value for each optional metadata, and assume that the default
value is used if the metadata is not provided with the packet. value is used if the metadata is not provided with the packet.
When specifying the metadata tags, some harmonization effort must be When specifying the metadata tags, some harmonization effort must be
made so that the producer LFB class uses the same tag as its intended made so that the producer LFB class uses the same tag as its intended
consumer(s), or vice versa. consumer(s), or vice versa.
skipping to change at page 28, line 7 skipping to change at page 28, line 11
3. checking (runtime set) event filters if they exist to see if the 3. checking (runtime set) event filters if they exist to see if the
event should be reported or suppressed. If the event is to be event should be reported or suppressed. If the event is to be
reported proceed to the next step. reported proceed to the next step.
4. Submitting of the declared report to the CE. 4. Submitting of the declared report to the CE.
Section 4.7.6 discusses events in more details. Section 4.7.6 discusses events in more details.
3.2.6. Component Properties 3.2.6. Component Properties
LFBs and structures are made up of components, containing the LFBs and structures are made up of Components, containing the
information that the CE needs to see and/or change about the information that the CE needs to see and/or change about the
functioning of the LFB. These Components, as described in detail in functioning of the LFB. These Components, as described in detail in
Section 4.7, may be basic values, complex structures (containing Section 4.7, may be basic values, complex structures (containing
multiple Components themselves, each of which can be values, multiple Components themselves, each of which can be values,
structures, or tables), or tables (which contain values, structures structures, or tables), or tables (which contain values, structures
or tables). Some of these Components are optional. Components may or tables). Components may be defined such that their appearence in
be readable or writeable at the discretion of the FE implementation. LFB instances is optional. Components may be readable or writeable
The CE needs to know these properties. Additionally, certain kinds at the discretion of the FE implementation. The CE needs to know
of Components (arrays / tables, aliases, and events as of this these properties. Additionally, certain kinds of Components (arrays
writing) have additional property information that the CE may need to / tables, aliases, and events) have additional property information
read or write. This model defines the structure of the property that the CE may need to read or write. This model defines the
information for all defined data types. structure of the property information for all defined data types.
Section 4.8 describes properties in more details. Section 4.8 describes properties in more details.
3.2.7. LFB Versioning 3.2.7. LFB Versioning
LFB class versioning is a method to enable incremental evolution of LFB class versioning is a method to enable incremental evolution of
LFB classes. In general, an FE is not allowed to contain an LFB LFB classes. In general, an FE is not allowed to contain an LFB
instance for more than one version of a particular class. instance for more than one version of a particular class.
Inheritance (discussed next in Section 3.2.8) has special rules. If Inheritance (discussed next in Section 3.2.8) has special rules. If
an FE datapath model containing an LFB instance of a particular class an FE datapath model containing an LFB instance of a particular class
skipping to change at page 31, line 45 skipping to change at page 31, line 45
1, 31, and 51. LFB ComponentID 51 is a complex structure 1, 31, and 51. LFB ComponentID 51 is a complex structure
encapsulating within it an entity with LFB ComponentID 89. LFB encapsulating within it an entity with LFB ComponentID 89. LFB
ComponentID 89 could be a complex structure itself but is restricted ComponentID 89 could be a complex structure itself but is restricted
in the example for the sake of clarity. in the example for the sake of clarity.
3.3.1. Addressing LFB Components: Paths and Keys 3.3.1. Addressing LFB Components: Paths and Keys
As mentioned above, LFB components could be complex structures, such As mentioned above, LFB components could be complex structures, such
as a table, or even more complex structures such as a table whose as a table, or even more complex structures such as a table whose
cells are further tables, etc. The ForCES model XML schema cells are further tables, etc. The ForCES model XML schema
(Figure 5) allows for uniquely identifying anything with such (Section 4) allows for uniquely identifying anything with such
complexity, utilizing the concept of dot-annotated static paths and complexity, utilizing the concept of dot-annotated static paths and
content addressing of paths as derived from keys. As an example, if content addressing of paths as derived from keys. As an example, if
the LFB Component 51 were a structure, then the path to LFB the LFB Component 51 were a structure, then the path to LFB
ComponentID 89 above will be 51.89. ComponentID 89 above will be 51.89.
LFB ComponentID 51 might represent a table (an array). In that case, LFB ComponentID 51 might represent a table (an array). In that case,
to select the LFB Component with ID 89 from within the 7th entry of to select the LFB Component with ID 89 from within the 7th entry of
the table, one would use the path 51.7.89 In addition to supporting the table, one would use the path 51.7.89. In addition to supporting
explicit table element selection by including and index in the dotted explicit table element selection by including an index in the dotted
path, the model supports identifying table elements by their path, the model supports identifying table elements by their
contents. This is referred to as using keys, or key indexing. So, contents. This is referred to as using keys, or key indexing. So,
as a further example, if ComponentID 51 was a table which was key as a further example, if ComponentID 51 was a table which was key
index-able, then a key describing content could also be passed by the index-able, then a key describing content could also be passed by the
CE, along with path 51 to select the table, and followed by the path CE, along with path 51 to select the table, and followed by the path
89 to select the table structure element, which upon computation by 89 to select the table structure element, which upon computation by
the FE would resolve to the LFB ComponentID 89 within the specified the FE would resolve to the LFB ComponentID 89 within the specified
table entry. table entry.
3.4. FE Datapath Modeling 3.4. FE Datapath Modeling
skipping to change at page 36, line 47 skipping to change at page 36, line 47
Why would the datapaths on an FE ever change dynamically? The Why would the datapaths on an FE ever change dynamically? The
datapaths on an FE are set up by the CE to provide certain data plane datapaths on an FE are set up by the CE to provide certain data plane
services (e.g., DiffServ, VPN, etc.) to the Network Element's (NE) services (e.g., DiffServ, VPN, etc.) to the Network Element's (NE)
customers. The purpose of reconfiguring the datapaths is to enable customers. The purpose of reconfiguring the datapaths is to enable
the CE to customize the services the NE is delivering at run time. the CE to customize the services the NE is delivering at run time.
The CE needs to change the datapaths when the service requirements The CE needs to change the datapaths when the service requirements
change, such as adding a new customer or when an existing customer change, such as adding a new customer or when an existing customer
changes their service. However, note that not all datapath changes changes their service. However, note that not all datapath changes
result in changes in the LFB topology graph. Changes in the graph result in changes in the LFB topology graph. Changes in the graph
are dependent on the approach used to map the datapaths into LFB are dependent on the approach used to map the datapaths into LFB
topology. As discussed in Section 3.3.1, the topological approach topology. As discussed in Section 3.4.1, the topological approach
and encoded state approach can result in very different looking LFB and encoded state approach can result in very different looking LFB
topologies for the same datapaths. In general, an LFB topology based topologies for the same datapaths. In general, an LFB topology based
on a pure topological approach is likely to experience more frequent on a pure topological approach is likely to experience more frequent
topology reconfiguration than one based on an encoded state approach. topology reconfiguration than one based on an encoded state approach.
However, even an LFB topology based entirely on an encoded state However, even an LFB topology based entirely on an encoded state
approach may have to change the topology at times, for example, to approach may have to change the topology at times, for example, to
bypass some LFBs or insert new LFBs. Since a mix of these two bypass some LFBs or insert new LFBs. Since a mix of these two
approaches is used to model the datapaths, LFB topology approaches is used to model the datapaths, LFB topology
reconfiguration is considered an important aspect of the FE model. reconfiguration is considered an important aspect of the FE model.
skipping to change at page 43, line 6 skipping to change at page 43, line 6
processing loaded elements is up to the implementor, as long as the processing loaded elements is up to the implementor, as long as the
total effect is as if all of the information from all the files were total effect is as if all of the information from all the files were
available for referencing when needed. Note that such computer available for referencing when needed. Note that such computer
processing of ForCES model library documents may be helpful for processing of ForCES model library documents may be helpful for
various implementations, but is not required to define the libraries, various implementations, but is not required to define the libraries,
or for the actual operation of the protocol itself. or for the actual operation of the protocol itself.
The following is a skeleton of a library document: The following is a skeleton of a library document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
provides="this_library"> provides="this_library">
<description> <description>
</description> </description>
<!-- Loading external libraries (optional) --> <!-- Loading external libraries (optional) -->
<load library="another_library"/> <load library="another_library"/>
... ...
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>
<contentKey keyID="1"> <contentKey contentKeyID="1">
<contentKeyField> address-prefix.ipv4addr </keyField> <contentKeyField> address-prefix.ipv4addr</contentKeyField>
<contentKeyField> address-prefix.prefixlen </keyField> <contentKeyField> address-prefix.prefixlen</contentKeyField>
<contentKeyField> source </keyField> <contentKeyField> source</contentKeyField>
</key> </contentKey>
</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
In order to use key declarations, one must refer to components that In order to use key declarations, one must refer to components that
skipping to change at page 55, line 17 skipping to change at page 55, line 17
It is sometimes necessary to have a component in an LFB or structure It is sometimes necessary to have a component in an LFB or structure
refer to information (a component) in other LFBs. This can, for refer to information (a component) in other LFBs. This can, for
example, allow an ARP LFB to share the IP->MAC Address table with the example, allow an ARP LFB to share the IP->MAC Address table with the
local transmission LFB, without duplicating information. Similarly, local transmission LFB, without duplicating information. Similarly,
it could allow a traffic measurement LFB to share information with a it could allow a traffic measurement LFB to share information with a
traffic enforcement LFB. The <alias> declaration creates the traffic enforcement LFB. The <alias> declaration creates the
constructs for this. This construct tells the CE and FE that any constructs for this. This construct tells the CE and FE that any
manipulation of the defined data is actually manipulation of data manipulation of the defined data is actually manipulation of data
defined to exist in some specified part of some other LFB instance. defined to exist in some specified part of some other LFB instance.
The content of an <alias> element MUST be a named type. Whatever The content of an <alias> element MUST be a named type. Whatever
component the alias references (whcih is determined by the alias component the alias references (which is determined by the alias
component properties, as described below) that component must be of component properties, as described below) that component must be of
the same type as that declared for the alias. Thus, when the CE or the same type as that declared for the alias. Thus, when the CE or
FE dereferences the alias component, the type of the information FE dereferences the alias component, the type of the information
returned is known. The type can be a base type or a derived type. returned is known. The type can be a base type or a derived type.
The actual value referenced by an alias is known as its target. When The actual value referenced by an alias is known as its target. When
a GET or SET operation references the alias element, the value of the a GET or SET operation references the alias element, the value of the
target is returned or replaced. Write access to an alias element is target is returned or replaced. Write access to an alias element is
permitted if write access to both the alias and the target are permitted if write access to both the alias and the target are
permitted. permitted.
skipping to change at page 65, line 22 skipping to change at page 65, line 22
CEs. Other variables that are internal to LFB implementation are not CEs. Other variables that are internal to LFB implementation are not
regarded as LFB components and hence are not covered. regarded as LFB components and hence are not covered.
Some examples for LFB components are: Some examples for LFB components are:
o Configurable flags and switches selecting between operational o Configurable flags and switches selecting between operational
modes of the LFB modes of the LFB
o Number of inputs or outputs in a port group o Number of inputs or outputs in a port group
o Metadata CONSUME vs.PROPAGATE mode selector
o Various configurable lookup tables, including interface tables, o Various configurable lookup tables, including interface tables,
prefix tables, classification tables, DSCP mapping tables, MAC prefix tables, classification tables, DSCP mapping tables, MAC
address tables, etc. address tables, etc.
o Packet and byte counters o Packet and byte counters
o Various event counters o Various event counters
o Number of current inputs or outputs for each input or output group o Number of current inputs or outputs for each input or output group
skipping to change at page 66, line 44 skipping to change at page 66, line 41
following elements can be used: <atomic>, <array>, <struct>, and following elements can be used: <atomic>, <array>, <struct>, and
<union>. Their usage is identical to how they are used inside <union>. Their usage is identical to how they are used inside
<dataTypeDef> elements (see Section 4.5). Some form of data type <dataTypeDef> elements (see Section 4.5). Some form of data type
definition MUST be included in the component definition. definition MUST be included in the component definition.
o The <defaultValue> element is optional, and if present is used to o The <defaultValue> element is optional, and if present is used to
specify a default value for a component. If a default value is specify a default value for a component. If a default value is
specified, the FE must ensure that the component has that value specified, the FE must ensure that the component has that value
when the LFB is initialized or reset. If a default value is not when the LFB is initialized or reset. If a default value is not
specified for a component, the CE may make no assumptions as to specified for a component, the CE may make no assumptions as to
what the value of the component will be upon intialization. The what the value of the component will be upon initalization. The
CE must either read the value, or set the value, if it needs to CE must either read the value, or set the value, if it needs to
know what it is. know what it is.
o The <description> element may also appear. If included, it o The <description> element may also appear. If included, it
provides a longer description of the meaning or usage of the provides a longer description of the meaning or usage of the
particular component being defined. particular component being defined.
The <component> element also MUST have an componentID attribute, The <component> element also MUST have an componentID attribute,
which is a numeric value used by the ForCES protocol. which is a numeric value used by the ForCES protocol.
skipping to change at page 75, line 39 skipping to change at page 75, line 39
High level view on the declaration and operation of LFB events is High level view on the declaration and operation of LFB events is
described in Section 3.2.5. described in Section 3.2.5.
The <eventTarget> provides additional components used in the path to The <eventTarget> provides additional components used in the path to
reference the event. The path constitutes the baseID for events, reference the event. The path constitutes the baseID for events,
followed by the ID for the specific event, followed by a value for followed by the ID for the specific event, followed by a value for
each <eventSubscript> element if it exists in the <eventTarget>. each <eventSubscript> element if it exists in the <eventTarget>.
The event path will uniquely identify a specific occurrence of the The event path will uniquely identify a specific occurrence of the
event in the event notification to the CE. In the example provided, event in the event notification to the CE. In the example provided
a notification with path of 7.7 uniquely identifies the event to be above, at the end of Section 4.7.6, a notification with path of 7.7
that caused by the change of foo; an event with path 7.9.100 uniquely uniquely identifies the event to be that caused by the change of foo;
identifies the event to be that caused by a creation of table bar an event with path 7.9.100 uniquely identifies the event to be that
entry with index/subscript 100. caused by a creation of table bar entry with index/subscript 100.
As described in the Section 4.8.5, event elements have properties As described in the Section 4.8.5, event elements have properties
associated with them. These properties include the subscription associated with them. These properties include the subscription
information indicating whether the CE wishes the FE to generate event information indicating whether the CE wishes the FE to generate event
reports for the event at all, thresholds for events related to level reports for the event at all, thresholds for events related to level
crossing, and filtering conditions that may reduce the set of event crossing, and filtering conditions that may reduce the set of event
notifications generated by the FE. Details of the filtering notifications generated by the FE. Details of the filtering
conditions that can be applied are given in that section. The conditions that can be applied are given in that section. The
filtering conditions allow the FE to suppress floods of events that filtering conditions allow the FE to suppress floods of events that
could result from oscillation around a condition value. For FEs that could result from oscillation around a condition value. For FEs that
skipping to change at page 106, line 32 skipping to change at page 106, line 32
[And a similar set of uniqueness constraints apply to the [And a similar set of uniqueness constraints apply to the
CanOccurBefore clauses, even though an LFB may occur both in CanOccurBefore clauses, even though an LFB may occur both in
CanOccurAfter and CanOccurBefore.] CanOccurAfter and CanOccurBefore.]
5.2.2.8. UseableParentLFBClasses 5.2.2.8. UseableParentLFBClasses
The UseableParentLFBClasses array, if present, i sued to hold a list The UseableParentLFBClasses array, if present, i sued to hold a list
of parent LFB class IDs. All the entries in the list must be IDs of of parent LFB class IDs. All the entries in the list must be IDs of
classes from which the SupportedLFB Class being described has classes from which the SupportedLFB Class being described has
inherited (either directly, or through an intermeidate parent.) (If inherited (either directly, or through an intermediate parent.) (If
an FE includes imporper values in this list, imporper manipulations an FE includes improper values in this list, improper manipulations
by the CE are likely, and operational failures are likely.) In by the CE are likely, and operational failures are likely.) In
addition, the FE, by including a given class in the last, is addition, the FE, by including a given class in the last, is
indicating to the CE that a given parent class may be used to indicating to the CE that a given parent class may be used to
manipulate an instance of this supported LFB class. manipulate an instance of this supported LFB class.
By allowing such substitution, the FE allows for the case where an By allowing such substitution, the FE allows for the case where an
instantiated LFB may be of a class not known to the CE, but could instantiated LFB may be of a class not known to the CE, but could
still be manipulated. While it is hoped that such situations are still be manipulated. While it is hoped that such situations are
rare, it is desirable for this to be supported. This can occur if an rare, it is desirable for this to be supported. This can occur if an
FE locally defines certain LFB instances, or if an earlier CE had FE locally defines certain LFB instances, or if an earlier CE had
skipping to change at page 107, line 39 skipping to change at page 107, line 39
5.3. FE Components 5.3. FE Components
The <components> element is included if the class definition contains The <components> element is included if the class definition contains
the definition of the components of the FE Object that are not the definition of the components of the FE Object that are not
considered "capabilities". Some of these components are writeable, considered "capabilities". Some of these components are writeable,
and some are read-only, which is determinable by examining the and some are read-only, which is determinable by examining the
property information of the components. property information of the components.
5.3.1. FEState 5.3.1. FEState
This component carries the overall state of the FE. For now, it is This component carries the overall state of the FE. The possible
restricted to the strings AdminDisable, OperDisable and OperEnable. values are the strings AdminDisable, OperDisable and OperEnable. The
starting state is OperDisable, and the transition to OperEnable is
controlled by the FE. The CE controls the transition from OperEnable
to/from AdminDisable. For details refer to the ForCES Protocol
document [2].
5.3.2. LFBSelectors and LFBSelectorType 5.3.2. LFBSelectors and LFBSelectorType
The LFBSelectors component is an array of information about the LFBs The LFBSelectors component is an array of information about the LFBs
currently accessible via ForCES in the FE. The structure of the LFB currently accessible via ForCES in the FE. The structure of the LFB
information is defined by the LFBSelectorType dataTypeDef. information is defined by the LFBSelectorType dataTypeDef.
Each entry in the array describes a single LFB instance in the FE. Each entry in the array describes a single LFB instance in the FE.
The array entry contains the numeric class ID of the class of the LFB The array entry contains the numeric class ID of the class of the LFB
instance and the numeric instance ID for this instance. instance and the numeric instance ID for this instance.
skipping to change at page 111, line 44 skipping to change at page 112, line 5
o The understanding of the type of information that must be o The understanding of the type of information that must be
exchanged between the FEs and CEs can help to select the exchanged between the FEs and CEs can help to select the
appropriate protocol format and the actual encoding method (such appropriate protocol format and the actual encoding method (such
as XML, TLVs). as XML, TLVs).
o Understanding the frequency of these types of messages should o Understanding the frequency of these types of messages should
influence the selection of the protocol format (efficiency influence the selection of the protocol format (efficiency
considerations). considerations).
An important part of the FE model is the port the FE uses for its
message exchanges to and from the CE. In the case that a dedicated
port is used for CE-FE communication, we propose to use a special
port LFB, called the CE-FE Port LFB (a subclass of the general Port
LFB in Section 6.1), to model this dedicated CE-FE port. The CE-FE
Port LFB acts as both a source and sink for the traffic from and to
the CE. Sometimes the CE-FE traffic does not have its own dedicated
port, instead the data fabric is shared for the data plane traffic
and the CE-FE traffic. A special processing LFB can be used to model
the ForCES packet encapsulation and decapsulation in such cases.
The remaining sub-sections of this section address each of the seven The remaining sub-sections of this section address each of the seven
message types. message types.
7.1. FE Topology Query 7.1. FE Topology Query
An FE may contain zero, one or more external ingress ports. An FE may contain zero, one or more external ingress ports.
Similarly, an FE may contain zero, one or more external egress ports. Similarly, an FE may contain zero, one or more external egress ports.
In other words, not every FE has to contain any external ingress or In other words, not every FE has to contain any external ingress or
egress interfaces. For example, Figure 13 shows two cascading FEs. egress interfaces. For example, Figure 13 shows two cascading FEs.
FE #1 contains one external ingress interface but no external egress FE #1 contains one external ingress interface but no external egress
skipping to change at page 116, line 42 skipping to change at page 116, line 42
properties of LFBs are shown by the FE Object LFB, this endeavors to properties of LFBs are shown by the FE Object LFB, this endeavors to
show how a data plane LFB might be build. This example is a show how a data plane LFB might be build. This example is a
fictional case of an interface supporting a coarse WDM optical fictional case of an interface supporting a coarse WDM optical
interface that carries Frame Relay traffic. The statistical interface that carries Frame Relay traffic. The statistical
information (including error statistics) is omitted. information (including error statistics) is omitted.
Later portions of this example include references to protocol Later portions of this example include references to protocol
operations. The operations described are operations the protocol operations. The operations described are operations the protocol
needs to support. The exact format and fields are purely needs to support. The exact format and fields are purely
informational here, as the ForCES Protocol [2] document defines the informational here, as the ForCES Protocol [2] document defines the
precise syntax and symantics of its operations. precise syntax and semantics of its operations.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="LaserFrameLFB"> provides="LaserFrameLFB">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>FRFrame</name> <name>FRFrame</name>
<synopsis> <synopsis>
A frame relay frame, with DLCI without A frame relay frame, with DLCI without
skipping to change at page 126, line 21 skipping to change at page 126, line 21
the LFB traffic is to be sent to. As mentioned above, the circuit the LFB traffic is to be sent to. As mentioned above, the circuit
index could, in some designs, be combined with the DLCI. index could, in some designs, be combined with the DLCI.
8.3. Capabilities 8.3. Capabilities
The capability information for this LFB includes whether the The capability information for this LFB includes whether the
underlying interface is operational, how many frequencies are underlying interface is operational, how many frequencies are
supported, and how many total circuits, across all channels, are supported, and how many total circuits, across all channels, are
permitted. The maximum number for a given laser channel can be permitted. The maximum number for a given laser channel can be
determined from the properties of the FrameRelayCircuits table. A determined from the properties of the FrameRelayCircuits table. A
GET-PROP on path 2.channel.4 will give the CE the properties of the GET-PROP on path 2.channel.4 will give the CE the properties of that
array which include the number of entries used, the first available FrameRelayCircuits array which include the number of entries used,
entry, and the maximum number of entries permitted. the first available entry, and the maximum number of entries
permitted.
8.4. Events 8.4. Events
This LFB is defined to be able to generate several events that the CE This LFB is defined to be able to generate several events that the CE
may be interested in. There are events to report changes in may be interested in. There are events to report changes in
operational state of frequencies, and the creation and deletion of operational state of frequencies, and the creation and deletion of
frequency entries. There is an event for changes in status of frequency entries. There is an event for changes in status of
individual frame relay circuits. So an event notification of individual frame relay circuits. So an event notification of
61.5.3.11 would indicate that there had been a circuit status change 61.5.3.11 would indicate that there had been a circuit status change
on subscript 11 of the circuit table in subscript 3 of the frequency on subscript 11 of the circuit table in subscript 3 of the frequency
 End of changes. 26 change blocks. 
67 lines changed or deleted 60 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/