draft-ietf-forces-model-07.txt   draft-ietf-forces-model-08.txt 
Internet Draft J. Halpern Working Group: ForCES J. Halpern
Expiration: April 2007 Self Internet-Draft Self
File: draft-ietf-forces-model-07.txt E. Deleganes Expires: April 9, 2008 E. Deleganes
Working Group: ForCES Intel Corp. Intel Corp.
October 2006 October 7, 2007
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-08.txt
draft-ietf-forces-model-07.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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than a "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.html. 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.
Comments are solicited and should be addressed to the working This Internet-Draft will expire on April 9, 2008.
group's mailing list at forces@peach.ease.lsoft.com and/or the
author(s). Copyright Notice
Copyright (C) The IETF Trust (2007).
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).
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. The Forwarding and Control Element Separation (ForCES) protocol. 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
that control elements (CEs) can control the FEs accordingly. More that control elements (CEs) can control the FEs accordingly. More
specifically, the model describes the logical functions that are specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected. This FE model is these functions are or can be interconnected. This FE model is
intended to satisfy the model requirements specified in the ForCES intended to satisfy the model requirements specified in the ForCES
requirements draft, RFC 3564 [1]. requirements draft,RFC3654 [2].
Table of Contents Table of Contents
Abstract...........................................................1 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Definitions.....................................................4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Introduction....................................................5 2.1. Requirements on the FE model . . . . . . . . . . . . . . 7
2.1. Requirements on the FE model...............................6 2.2. The FE Model in Relation to FE Implementations . . . . . 8
2.2. The FE Model in Relation to FE Implementations.............6 2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8
2.3. The FE Model in Relation to the ForCES Protocol............6 2.4. Modeling Language for the FE Model . . . . . . . . . . . 9
2.4. Modeling Language for the FE Model.........................7 2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9
2.5. Document Structure.........................................8 3. FE Model Concepts . . . . . . . . . . . . . . . . . . . . . . 10
3. FE Model Concepts...............................................8 3.1. FE Capability Model and State Model . . . . . . . . . . . 10
3.1. FE Capability Model and State Model........................8 3.2. LFB (Logical Functional Block) Modeling . . . . . . . . . 13
3.2. LFB (Logical Functional Block) Modeling...................11 3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 16
3.2.1. LFB Outputs..........................................13 3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 19
3.2.2. LFB Inputs...........................................16 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 21
3.2.3. Packet Type..........................................19 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4. Metadata.............................................19 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 29
3.2.5. LFB Events...........................................26 3.2.6. LFB Component Properties . . . . . . . . . . . . . . 29
3.2.6. LFB Element Properties...............................27 3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 30
3.2.7. LFB Versioning.......................................27 3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 30
3.2.8. LFB Inheritance......................................28 3.3. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 31
3.3. FE Datapath Modeling......................................29 3.3.1. Alternative Approaches for Modeling FE Datapaths . . 32
3.3.1. Alternative Approaches for Modeling FE Datapaths.....29 3.3.2. Configuring the LFB Topology . . . . . . . . . . . . 36
3.3.2. Configuring the LFB Topology.........................33 4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40
4. Model and Schema for LFB Classes...............................37 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1. Namespace.................................................37 4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 40
4.2. <LFBLibrary> Element......................................37 4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 42
4.3. <load> Element............................................39 4.4. <frameDefs> Element for Frame Type Declarations . . . . . 43
4.4. <frameDefs> Element for Frame Type Declarations...........39 4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 43
4.5. <dataTypeDefs> Element for Data Type Definitions..........40 4.5.1. <typeRef> Element for Aliasing Existing Data Types . 46
4.5.1. <typeRef> Element for Aliasing Existing Data Types...43 4.5.2. <atomic> Element for Deriving New Atomic Types . . . 47
4.5.2. <atomic> Element for Deriving New Atomic Types.......43 4.5.3. <array> Element to Define Arrays . . . . . . . . . . 47
4.5.3. <array> Element to Define Arrays.....................44 4.5.4. <struct> Element to Define Structures . . . . . . . . 51
4.5.4. <struct> Element to Define Structures................47 4.5.5. <union> Element to Define Union Types . . . . . . . . 52
4.5.5. <union> Element to Define Union Types................48 4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 52
4.5.6. Augmentations........................................49 4.5.7. Augmentationst . . . . . . . . . . . . . . . . . . . 53
4.6. <metadataDefs> Element for Metadata Definitions...........50 4.6. <metadataDefs> Element for Metadata Definitions . . . . . 54
4.7. <LFBClassDefs> Element for LFB Class Definitions..........51 4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 55
4.7.1. <derivedFrom> Element to Express LFB Inheritance.....52 4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 57
4.7.2. <inputPorts> Element to Define LFB Inputs............53 4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 58
4.7.3. <outputPorts> Element to Define LFB Outputs..........55 4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 60
4.7.4. <attributes> Element to Define LFB Operational 4.7.4. <components> Element to Define LFB Operational
Attributes..................................................57 Components . . . . . . . . . . . . . . . . . . . . . 63
4.7.5. <capabilities> Element to Define LFB Capability 4.7.5. <capabilities> Element to Define LFB Capability
Attributes..................................................59 Components . . . . . . . . . . . . . . . . . . . . . 65
4.7.6. <events> Element for LFB Notification Generation.....61 4.7.6. <events> Element for LFB Notification Generation . . 67
4.7.7. <description> Element for LFB Operational Specification 4.7.7. <description> Element for LFB Operational
............................................................64 Specification . . . . . . . . . . . . . . . . . . . . 70
4.8. Properties................................................64 4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 70
4.8.1. Basic Properties.....................................64 4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 71
4.8.2. Array Properties.....................................66 4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 73
4.8.3. String Properties....................................66 4.8.3. String Properties . . . . . . . . . . . . . . . . . . 73
4.8.4. Octetstring Properties...............................67 4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 74
4.8.5. Event Properties.....................................67 4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 75
4.8.6. Alias Properties.....................................70 4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 78
4.9. XML Schema for LFB Class Library Documents................71 4.9. XML Schema for LFB Class Library Documents . . . . . . . 79
5. FE Attributes and Capabilities.................................82 5. FE Components and Capabilities . . . . . . . . . . . . . . . 90
5.1. XML for FEObject Class definition.........................82 5.1. XML for FEObject Class definition . . . . . . . . . . . . 91
5.2. FE Capabilities...........................................89 5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 97
5.2.1. ModifiableLFBTopology................................89 5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 97
5.2.2. SupportedLFBs and SupportedLFBType...................89 5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 98
5.3. FEAttributes..............................................92 5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 100
5.3.1. FEStatus.............................................92 5.3.1. FEStatus . . . . . . . . . . . . . . . . . . . . . . 100
5.3.2. LFBSelectors and LFBSelectorType.....................92 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 100
5.3.3. LFBTopology and LFBLinkType..........................92 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 101
5.3.4. FENeighbors and FEConfiguredNeighborType.............93 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 101
6. Satisfying the Requirements on FE Model........................93 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 102
7. Using the FE model in the ForCES Protocol......................94 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 103
7.1. FE Topology Query.........................................96 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 105
7.2. FE Capability Declarations................................97 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 106
7.3. LFB Topology and Topology Configurability Query...........98 7.3. LFB Topology and Topology Configurability Query . . . . . 107
7.4. LFB Capability Declarations...............................98 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 107
7.5. State Query of LFB Attributes.............................99 7.5. State Query of LFB Attributes . . . . . . . . . . . . . . 108
7.6. LFB Attribute Manipulation................................99 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 109
7.7. LFB Topology Re-configuration............................100 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 109
8. Example.......................................................100 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.1. Data Handling............................................107 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 116
8.1.1. Setting up a DLCI...................................108 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 117
8.1.2. Error Handling......................................108 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 118
8.2. LFB Attributes...........................................109 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 118
8.3. Capabilities.............................................109 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 119
8.4. Events...................................................109 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 119
9. IANA Considerations...........................................111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120
10. Authors Emeritus.............................................111 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 121
11. Acknowledgments..............................................111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 121
12. Security Considerations......................................112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 121
13. Normative References.........................................112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 121
14. Informative References.......................................112 13.1. Normative References . . . . . . . . . . . . . . . . . . 121
15. Authors' Addresses...........................................113 13.2. Informative References . . . . . . . . . . . . . . . . . 122
16. Intellectual Property Right..................................113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
17. Copyright Statement..........................................113 Intellectual Property and Copyright Statements . . . . . . . . . 124
Conventions used in this document
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 [RFC-2119].
1. Definitions 1. Definitions
The use of compliance terminology (MUST, SHOULD, MAY) is used in
accordance with RFC2119 [1]. Such terminology is used in describing
the required behavior of ForCES forwarding elements or control
elements in supporting or manipulating information described in this
model.
Terminology associated with the ForCES requirements is defined in Terminology associated with the ForCES requirements is defined in
RFC 3564 [1] and is not copied here. The following list of RFC3654 [2] and is not copied here. The following list of
terminology relevant to the FE model is defined in this section. terminology relevant to the FE model is defined in this section.
FE Model -- The FE model is designed to model the logical processing FE Model -- The FE model is designed to model the logical processing
functions of an FE. The FE model proposed in this document includes functions of an FE. The FE model proposed in this document includes
three components: the modeling of individual logical functional three components: the modeling of individual logical functional
blocks (LFB model), the logical interconnection between LFBs (LFB blocks (LFB model), the logical interconnection between LFBs (LFB
topology) and the FE level attributes, including FE capabilities. topology) and the FE level attributes, including FE capabilities.
The FE model provides the basis to define the information elements The FE model provides the basis to define the information elements
exchanged between the CE and the FE in the ForCES protocol. exchanged between the CE and the FE in the ForCES protocol.
skipping to change at page 4, line 30 skipping to change at page 5, line 36
plane inside an FE. Note that more than one datapath can exist plane inside an FE. Note that more than one datapath can exist
within an FE. within an FE.
LFB (Logical Functional Block) Class (or type) -- A template that LFB (Logical Functional Block) Class (or type) -- A template that
representing a fine-grained, logically separable aspect of FE representing a fine-grained, logically separable aspect of FE
processing. Most LFBs relate to packet processing in the data path. processing. Most LFBs relate to packet processing in the data path.
LFB classes are the basic building blocks of the FE model. LFB classes are the basic building blocks of the FE model.
LFB Instance -- As a packet flows through an FE along a datapath, it LFB Instance -- As a packet flows through an FE along a datapath, it
flows through one or multiple LFB instances, where each LFB is an flows through one or multiple LFB instances, where each LFB is an
instance of a specific LFB class. Multiple instances of the same instance of a specific LFB class. Multiple instances of the same LFB
LFB class can be present in an FE's datapath. Note that we often class can be present in an FE's datapath. Note that we often refer
refer to LFBs without distinguishing between an LFB class and LFB to LFBs without distinguishing between an LFB class and LFB instance
instance when we believe the implied reference is obvious for the when we believe the implied reference is obvious for the given
given context. context.
LFB Model -- The LFB model describes the content and structures in LFB Model -- The LFB model describes the content and structures in an
an LFB, plus the associated data definition. Four types of LFB, plus the associated data definition. Four types of information
information are defined in the LFB model. The core part of the LFB are defined in the LFB model. The core part of the LFB model is the
model is the LFB class definitions; the other three types define the LFB class definitions; the other three types define the associated
associated data including common data types, supported frame formats data including common data types, supported frame formats and
and metadata. metadata.
LFB Metadata -- Metadata is used to communicate per-packet state LFB Metadata -- Metadata is used to communicate per-packet state from
from one LFB to another, but is not sent across the network. The FE one LFB to another, but is not sent across the network. The FE model
model defines how such metadata is identified, produced and consumed defines how such metadata is identified, produced and consumed by the
by the LFBs, but not how the per-packet state is implemented within LFBs, but not how the per-packet state is implemented within actual
actual hardware. Metadata is sent between the FE and the CE on hardware. Metadata is sent between the FE and the CE on redirect
redirect packets. packets.
LFB Attribute -- Operational parameters of the LFBs that must be LFB Component -- Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB visible to the CEs are conceptualized in the FE model as the LFB
attributes. The LFB attributes include: flags, single parameter components. The LFB components include: flags, single parameter
arguments, complex arguments, and tables that the CE can read or/and arguments, complex arguments, and tables that the CE can read or/and
write via the ForCES protocol. write via the ForCES protocol.
Structure Component -- Forces allows for complex data structures to
be used in its data definitions. Generally, these include tables and
Structures. The individual parts which make up a structured set of
data are referred to as Structure Components. These can themselves
be of any valid data type, including tables and structures.
Component -- Often in describing the forces model and its
operational, it is useful to refer to the parts of an LFB or
structure, without regard to what they are part of. The term
component by itself will be used to refer to these parts. If the
context is unclear, but it is necessary to refer explicitly to either
LFB Components or Structure Components, then the modifying word will
be present. When the correct prefix is clear from context, or when
no differentiation is needed, no modifier will be used.
Element -- Element is generally used in this document in accordance
with the XML usage of the term. It refers to an XML tagged part of
an XML document. For a precise definition, please see the full set
of XML specifications from the W3C. This term is included in this
list for completeness, and because earlier versions of this document
used the term element inconsistently. The other use of the term
element is in terms of the FE and CE (Forwarding Element and Control
Element.) As those are not textual or data structure items, context
provides sufficient clarity for this usage.
Attribute -- Attribute is used in the XML sense of attribute
information include in an XML tag.
LFB Topology -- A representation of the logical interconnection and LFB Topology -- A representation of the logical interconnection and
the placement of LFB instances along the datapath within one FE. the placement of LFB instances along the datapath within one FE.
Sometimes this representation is called intra-FE topology, to be Sometimes this representation is called intra-FE topology, to be
distinguished from inter-FE topology. LFB topology is outside of distinguished from inter-FE topology. LFB topology is outside of the
the LFB model, but is part of the FE model. LFB model, but is part of the FE model.
FE Topology -- A representation of how multiple FEs within a single FE Topology -- A representation of how multiple FEs within a single
NE are interconnected. Sometimes this is called inter-FE topology, NE are interconnected. Sometimes this is called inter-FE topology,
to be distinguished from intra-FE topology (i.e., LFB topology). An to be distinguished from intra-FE topology (i.e., LFB topology). An
individual FE might not have the global knowledge of the full FE individual FE might not have the global knowledge of the full FE
topology, but the local view of its connectivity with other FEs is topology, but the local view of its connectivity with other FEs is
considered to be part of the FE model. The FE topology is considered to be part of the FE model. The FE topology is discovered
discovered by the ForCES base protocol or by some other means. by the ForCES base protocol or by some other means.
Inter-FE Topology -- See FE Topology. Inter-FE Topology -- See FE Topology.
Intra-FE Topology -- See LFB Topology. Intra-FE Topology -- See LFB Topology.
LFB class library -- A set of LFB classes that has been identified LFB class library -- A set of LFB classes that has been identified as
as the most common functions found in most FEs and hence should be the most common functions found in most FEs and hence should be
defined first by the ForCES Working Group. defined first by the ForCES Working Group.
2. Introduction 2. Introduction
RFC 3746 [2] specifies a framework by which control elements (CEs) RFC3746 [3] specifies a framework by which control elements (CEs) can
can configure and manage one or more separate forwarding elements configure and manage one or more separate forwarding elements (FEs)
(FEs) within a networking element (NE) using the ForCES protocol. within a networking element (NE) using the ForCES protocol. The
The ForCES architecture allows Forwarding Elements of varying ForCES architecture allows Forwarding Elements of varying
functionality to participate in a ForCES network element. The functionality to participate in a ForCES network element. The
implication of this varying functionality is that CEs can make only implication of this varying functionality is that CEs can make only
minimal assumptions about the functionality provided by FEs in an minimal assumptions about the functionality provided by FEs in an NE.
NE. Before CEs can configure and control the forwarding behavior of Before CEs can configure and control the forwarding behavior of FEs,
FEs, CEs need to query and discover the capabilities and states of CEs need to query and discover the capabilities and states of their
their FEs. RFC 3654 [1] mandates that the capabilities, states and FEs.RFC3654 [2] mandates that the capabilities, states and
configuration information be expressed in the form of an FE model. configuration information be expressed in the form of an FE model.
RFC 3444 [11] observed that information models (IMs) and data models RFC3444 [8] observed that information models (IMs) and data models
(DMs) are different because they serve different purposes. "The (DMs) are different because they serve different purposes. "The main
main purpose of an IM is to model managed objects at a conceptual purpose of an IM is to model managed objects at a conceptual level,
level, independent of any specific implementations or protocols independent of any specific implementations or protocols used".
used". "DMs, conversely, are defined at a lower level of "DMs, conversely, are defined at a lower level of abstraction and
abstraction and include many details. They are intended for include many details. They are intended for implementors and include
implementors and include protocol-specific constructs." Sometimes protocol-specific constructs." Sometimes it is difficult to draw a
it is difficult to draw a clear line between the two. The FE model clear line between the two. The FE model described in this document
described in this document is primarily an information model, but is primarily an information model, but also includes some aspects of
also includes some aspects of a data model, such as explicit a data model, such as explicit definitions of the LFB class schema
definitions of the LFB class schema and FE schema. It is expected and FE schema. It is expected that this FE model will be used as the
that this FE model will be used as the basis to define the payload basis to define the payload for information exchange between the CE
for information exchange between the CE and FE in the ForCES and FE in the ForCES protocol.
protocol.
2.1. Requirements on the FE model 2.1. Requirements on the FE model
RFC 3654 [1] defines requirements that must be satisfied by a ForCES RFC3654 [2]defines requirements that must be satisfied by a ForCES FE
FE model. To summarize, an FE model must define: model. To summarize, an FE model must define:
. Logically separable and distinct packet forwarding operations
in an FE datapath (logical functional blocks or LFBs); o Logically separable and distinct packet forwarding operations in
. The possible topological relationships (and hence the sequence an FE datapath (logical functional blocks or LFBs);
of packet forwarding operations) between the various LFBs; o The possible topological relationships (and hence the sequence of
. The possible operational capabilities (e.g., capacity limits, packet forwarding operations) between the various LFBs;
constraints, optional features, granularity of configuration)
of each type of LFB; o The possible operational capabilities (e.g., capacity limits,
. The possible configurable parameters (i.e., attributes) of each constraints, optional features, granularity of configuration) of
each type of LFB;
o The possible configurable parameters (i.e., attributes) of each
type of LFB; type of LFB;
. Metadata that may be exchanged between LFBs.
o Metadata that may be exchanged between LFBs.
2.2. The FE Model in Relation to FE Implementations 2.2. The FE Model in Relation to FE Implementations
The FE model proposed here is based on an abstraction of distinct The FE model proposed here is based on an abstraction of distinct
logical functional blocks (LFBs), which are interconnected in a logical functional blocks (LFBs), which are interconnected in a
directed graph, and receive, process, modify, and transmit packets directed graph, and receive, process, modify, and transmit packets
along with metadata. The FE model should be designed such that along with metadata. The FE model should be designed such that
different implementations of the forwarding datapath can be different implementations of the forwarding datapath can be logically
logically mapped onto the model with the functionality and sequence mapped onto the model with the functionality and sequence of
of operations correctly captured. However, the model is not operations correctly captured. However, the model is not intended to
intended to directly address how a particular implementation maps to directly address how a particular implementation maps to an LFB
an LFB topology. It is left to the forwarding plane vendors to topology. It is left to the forwarding plane vendors to define how
define how the FE functionality is represented using the FE model. the FE functionality is represented using the FE model. Our goal is
Our goal is to design the FE model such that it is flexible enough to design the FE model such that it is flexible enough to accommodate
to accommodate most common implementations. most common implementations.
The LFB topology model for a particular datapath implementation must The LFB topology model for a particular datapath implementation must
correctly capture the sequence of operations on the packet. correctly capture the sequence of operations on the packet. Metadata
Metadata generation by certain LFBs MUST always precede any use of generation by certain LFBs MUST always precede any use of that
that metadata by subsequent LFBs in the topology graph; this is metadata by subsequent LFBs in the topology graph; this is required
required for logically consistent operation. Further, modification for logically consistent operation. Further, modification of packet
of packet fields that are subsequently used as inputs for further fields that are subsequently used as inputs for further processing
processing MUST occur in the order specified in the model for that MUST occur in the order specified in the model for that particular
particular implementation to ensure correctness. implementation to ensure correctness.
2.3. The FE Model in Relation to the ForCES Protocol 2.3. The FE Model in Relation to the ForCES Protocol
The ForCES base protocol is used by the CEs and FEs to maintain the The ForCES base protocol is used by the CEs and FEs to maintain the
communication channel between the CEs and FEs. The ForCES protocol communication channel between the CEs and FEs. The ForCES protocol
may be used to query and discover the inter-FE topology. The may be used to query and discover the inter-FE topology. The details
details of a particular datapath implementation inside an FE, of a particular datapath implementation inside an FE, including the
including the LFB topology, along with the operational capabilities LFB topology, along with the operational capabilities and attributes
and attributes of each individual LFB, are conveyed to the CE within of each individual LFB, are conveyed to the CE within information
information elements in the ForCES protocol. The model of an LFB elements in the ForCES protocol. The model of an LFB class should
class should define all of the information that needs to be define all of the information that needs to be exchanged between an
exchanged between an FE and a CE for the proper configuration and FE and a CE for the proper configuration and management of that LFB.
management of that LFB.
Specifying the various payloads of the ForCES messages in a Specifying the various payloads of the ForCES messages in a
systematic fashion is difficult without a formal definition of the systematic fashion is difficult without a formal definition of the
objects being configured and managed (the FE and the LFBs within). objects being configured and managed (the FE and the LFBs within).
The FE Model document defines a set of classes and attributes for The FE Model document defines a set of classes and components for
describing and manipulating the state of the LFBs within an FE. describing and manipulating the state of the LFBs within an FE.
These class definitions themselves will generally not appear in the These class definitions themselves will generally not appear in the
ForCES protocol. Rather, ForCES protocol operations will reference ForCES protocol. Rather, ForCES protocol operations will reference
classes defined in this model, including relevant attributes and the classes defined in this model, including relevant components and the
defined operations. defined operations.
Section 7 provides more detailed discussion on how the FE model Section 7 provides more detailed discussion on how the FE model
should be used by the ForCES protocol. should be used by the ForCES protocol.
2.4. Modeling Language for the FE Model 2.4. Modeling Language for the FE Model
Even though not absolutely required, it is beneficial to use a Even though not absolutely required, it is beneficial to use a formal
formal data modeling language to represent the conceptual FE model data modeling language to represent the conceptual FE model described
described in this document. Use of a formal language can help to in this document. Use of a formal language can help to enforce
enforce consistency and logical compatibility among LFBs. A full consistency and logical compatibility among LFBs. A full
specification will be written using such a data modeling language. specification will be written using such a data modeling language.
The formal definition of the LFB classes may facilitate the eventual The formal definition of the LFB classes may facilitate the eventual
automation of some of the code generation process and the functional automation of some of the code generation process and the functional
validation of arbitrary LFB topologies. These class definitions validation of arbitrary LFB topologies. These class definitions form
form the LFB Library. Documents which describe LFB Classes are the LFB Library. Documents which describe LFB Classes are therefore
therefore referred to as LFB Library documents. referred to as LFB Library documents.
Human readability was the most important factor considered when Human readability was the most important factor considered when
selecting the specification language, whereas encoding, decoding and selecting the specification language, whereas encoding, decoding and
transmission performance was not a selection factor. The encoding transmission performance was not a selection factor. The encoding
method for over the wire transport is not dependent on the method for over the wire transport is not dependent on the
specification language chosen and is outside the scope of this specification language chosen and is outside the scope of this
document and up to the ForCES protocol to define. document and up to the ForCES protocol to define.
XML was chosen as the specification language in this document, XML was chosen as the specification language in this document,
because XML has the advantage of being both human and machine because XML has the advantage of being both human and machine
readable with widely available tools support. This document uses XML readable with widely available tools support. This document uses XML
Schema to define the structure of the LFB Library documents, as Schema to define the structure of the LFB Library documents, as
defined in [12] and [13]. While these LFB Class definitions are not defined in [9] and [10]. While these LFB Class definitions are not
sent in the Forces protocol, these definitions comply with the sent in the Forces protocol, these definitions comply with the
recommendations in RFC 3470 [11] on the use of XML in IETF recommendations in RFC3470 [9] on the use of XML in IETF protocols.
protocols.
2.5. Document Structure 2.5. Document Structure
Section 3 provides a conceptual overview of the FE model, laying the Section 3 provides a conceptual overview of the FE model, laying the
foundation for the more detailed discussion and specifications in foundation for the more detailed discussion and specifications in the
the sections that follow. Section 4 and 5 constitute the core of sections that follow. Section 4 and Section 5 constitute the core of
the FE model, detailing the two major components in the FE model: the FE model, detailing the two major aspects of the FE model: a
LFB model and FE level attributes including capability and LFB general LFB model and a definition of the FE Object LFB, with its
topology. Section 6 directly addresses the model requirements components, including FE capabilities and LFB topology information.
imposed by the ForCES requirement draft [1] while Section 7 explains Section 6 directly addresses the model requirements imposed by the
how the FE model should be used in the ForCES protocol. ForCES requirement draft[1] while Section 7 explains how the FE model
should be used in the ForCES protocol.
3. FE Model Concepts 3. FE Model Concepts
Some of the important concepts used throughout this document are Some of the important concepts used throughout this document are
introduced in this section. Section 3.1 explains the difference introduced in this section. Section 3.1 explains the difference
between a state model and a capability model, and describes how the between a state model and a capability model, and describes how the
two can be combined in the FE model. Section 3.2 introduces the two can be combined in the FE model. Section 3.2 introduces the
concept of LFBs (Logical Functional Blocks) as the basic functional concept of LFBs (Logical Functional Blocks) as the basic functional
building blocks in the FE model. Section 3.3 discusses the logical building blocks in the FE model. Section 3.3 discusses the logical
inter-connection and ordering between LFB instances within an FE, inter-connection and ordering between LFB instances within an FE,
that is, the LFB topology. that is, the LFB topology.
The FE model proposed in this document is comprised of two major The FE model proposed in this document has two major aspects: the LFB
components: the LFB model and FE level attributes, including FE model and FE Object defintion whose components include FE capability
capabilities and LFB topology. The LFB model provides the content information and LFB topology information. The LFB model provides the
and data structures to define each individual LFB class. FE content and data structures to define each individual LFB class. The
attributes provide information at the FE level, particularly the FE Object class defines the components to provide information at the
capabilities of the FE at a coarse level. Part of the FE level FE level, particularly the capabilities of the FE at a coarse level.
information is the LFB topology, which expresses the logical inter- Part of the FE level information is the LFB topology, which expresses
connection between the LFB instances along the datapath(s) within the logical inter- connection between the LFB instances along the
the FE. Details of these components are described in Section 4 and datapath(s) within the FE. Details of these aspects are described in
5. The intent of this section is to discuss these concepts at the Section 4 and Section 5. The intent of this section is to discuss
high level and lay the foundation for the detailed description in these concepts at the high level and lay the foundation for the
the following sections. detailed description in the following sections.
3.1. FE Capability Model and State Model 3.1. FE Capability Model and State Model
The ForCES FE model includes both a capability and a state model. The ForCES FE model includes both a capability and a state model.
The FE capability model describes the capabilities and capacities of The FE capability model describes the capabilities and capacities of
an FE by specifying the variation in functions supported and any an FE by specifying the variation in functions supported and any
limitations. The FE state model describes the current state of the limitations. The FE state model describes the current state of the
FE, that is, the instantaneous values or operational behavior of the FE, that is, the instantaneous values or operational behavior of the
FE. FE. Equally, this concept applies to LFB classes, where the
capability information indicates what this FE is capable of providing
using the specific LFB Class, or even the specific component (such as
the table size limits.) Capability information is always read-only,
as it describes what the FE / LFB can provide, not what the CE has
requested.
Conceptually, the FE capability model tells the CE which states are Conceptually, the FE capability model tells the CE which states are
allowed on an FE, with capacity information indicating certain allowed on an FE, with capacity information indicating certain
quantitative limits or constraints. Thus, the CE has general quantitative limits or constraints. Thus, the CE has general
knowledge about configurations that are applicable to a particular knowledge about configurations that are applicable to a particular
FE. For example, an FE capability model may describe the FE at a FE. For example, an FE capability model may describe the FE at a
coarse level such as: coarse level such as:
. this FE can handle IPv4 and IPv6 forwarding; o this FE can handle IPv4 and IPv6 forwarding;
. this FE can perform classification on the following fields:
source IP address, destination IP address, source port number, o this FE can perform classification on the following fields: source
IP address, destination IP address, source port number,
destination port number, etc; destination port number, etc;
. this FE can perform metering;
. this FE can handle up to N queues (capacity); o this FE can perform metering;
. this FE can add and remove encapsulating headers of types
o this FE can handle up to N queues (capacity);
o this FE can add and remove encapsulating headers of types
including IPSec, GRE, L2TP. including IPSec, GRE, L2TP.
While one could try and build an object model to fully represent the While one could try and build an object model to fully represent the
FE capabilities, other efforts found this to be a significant FE capabilities, other efforts found this to be a significant
undertaking. The main difficulty arises in describing detailed undertaking. The main difficulty arises in describing detailed
limits, such as the maximum number of classifiers, queues, buffer limits, such as the maximum number of classifiers, queues, buffer
pools, and meters the FE can provide. We believe that a good pools, and meters the FE can provide. We believe that a good balance
balance between simplicity and flexibility can be achieved for the between simplicity and flexibility can be achieved for the FE model
FE model by combining coarse level capability reporting with an by combining coarse level capability reporting with an error
error reporting mechanism. That is, if the CE attempts to instruct reporting mechanism. That is, if the CE attempts to instruct the FE
the FE to set up some specific behavior it cannot support, the FE to set up some specific behavior it cannot support, the FE will
will return an error indicating the problem. Examples of similar return an error indicating the problem. Examples of similar
approaches include DiffServ PIB [4] and Framework PIB [5]. approaches include DiffServ PIB RFC3317 [4] and Framework PIB RFC3318
[5].
There is one common and shared aspect of capability that will be There is one common and shared aspect of capability that will be
handled in a separate fashion. For all elements of information, handled in a separate fashion. For all components (i.e. LFB
certain property information is needed. All elements need components and Structure components), certain property information is
information as to whether they are supported and if so whether the needed. All components need to provide information as to whether
element is readable or writeable. Based on their type, many they are supported and if so whether the components is readable or
elements have additional common properties (for example, arrays have writeable. Based on their type, many components have additional
their current size.) There is a specific model and protocol common properties (for example, arrays have their current size.)
mechanism for referencing this form of property information about There is a specific model and protocol mechanism for referencing this
elements of the model. form of property information about components of the model.
The FE state model presents the snapshot view of the FE to the CE. The FE state model presents the snapshot view of the FE to the CE.
For example, using an FE state model, an FE may be described to its For example, using an FE state model, an FE may be described to its
corresponding CE as the following: corresponding CE as the following:
. on a given port, the packets are classified using a given o on a given port, the packets are classified using a given
classification filter; classification filter;
. the given classifier results in packets being metered in a
certain way, and then marked in a certain way; o the given classifier results in packets being metered in a certain
. the packets coming from specific markers are delivered into a way, and then marked in a certain way;
shared queue for handling, while other packets are delivered to o the packets coming from specific markers are delivered into a
a different queue; shared queue for handling, while other packets are delivered to a
. a specific scheduler with specific behavior and parameters will different queue;
o a specific scheduler with specific behavior and parameters will
service these collected queues. service these collected queues.
Figure 1 shows the concepts of FE state, capabilities and Figure 1 shows the concepts of FE state, capabilities and
configuration in the context of CE-FE communication via the ForCES configuration in the context of CE-FE communication via the ForCES
protocol. protocol.
+-------+ +-------+ +-------+ +-------+
| | FE capabilities: what it can/cannot do. | | | | FE capabilities: what it can/cannot do. | |
| |<-----------------------------------------| | | |<-----------------------------------------| |
| | | | | | | |
| CE | FE state: what it is now. | FE | | CE | FE state: what it is now. | FE |
| |<-----------------------------------------| | | |<-----------------------------------------| |
| | | | | | | |
| | FE configuration: what it should be. | | | | FE configuration: what it should be. | |
| |----------------------------------------->| | | |----------------------------------------->| |
+-------+ +-------+ +-------+ +-------+
Figure 1. Illustration of FE state, capabilities and configuration Figure 1: Illustration of FE state, capabilities and configuration
exchange in the context of CE-FE communication via ForCES. exchange in the context of CE-FE communication via ForCES.
The concepts relating to LFBs, particularly capability at the LFB The concepts relating to LFBs, particularly capability at the LFB
level and LFB topology will be discussed in the rest of this level and LFB topology will be discussed in the rest of this section.
section.
Capability information at the LFB level is an integral part of the Capability information at the LFB level is an integral part of the
LFB model, and is modeled the same way as the other operational LFB model, and is modeled the same way as the other operational
parameters inside an LFB. For example, when certain features of an parameters inside an LFB. For example, when certain features of an
LFB class are optional, the CE MUST be able to determine whether LFB class are optional, the CE MUST be able to determine whether
those optional features are supported by a given LFB instance. Such those optional features are supported by a given LFB instance. Such
capability information can be modeled as a read-only attribute in capability information is modeled as either property information, or
the LFB instance, see Section 4.7.5 for details. for LFB information not provided by the defined properties, as
capability components which are inherently read-only. The schema for
the definition of LFB classes provides for identifying such
components.
Capability information at the FE level may describe the LFB classes Capability information at the FE level may describe the LFB classes
that the FE can instantiate; the number of instances of each that that the FE can instantiate; the number of instances of each that can
can be created; the topological (linkage) limitations between these be created; the topological (linkage) limitations between these LFB
LFB instances, etc. Section 5 defines the FE level attributes instances, etc. Section 5 defines the FE level components including
including capability information. capability information. Since all information is represented as
LFBs, this is provided by a single instance of the FE Object LFB
Class. By using a single instance with a known LFB Class and a known
instance identification, the Forces Protocol can allow a CE to access
this information whenever it needs to, including as part of
establishing the control of the FE by the CE.
Once the FE capability is described to the CE, the FE state Once the FE capability is described to the CE, the FE state
information can be represented by two levels. The first level is information can be represented by two levels. The first level is the
the logically separable and distinct packet processing functions, logically separable and distinct packet processing functions, called
called Logical Functional Blocks (LFBs). The second level of Logical Functional Blocks (LFBs). The second level of information
information describes how these individual LFBs are ordered and describes how these individual LFBs are ordered and placed along the
placed along the datapath to deliver a complete forwarding plane datapath to deliver a complete forwarding plane service. The
service. The interconnection and ordering of the LFBs is called LFB interconnection and ordering of the LFBs is called LFB Topology.
Topology. Section 3.2 discusses high level concepts around LFBs, Section 3.2 discusses high level concepts around LFBs, whereas
whereas Section 3.3 discusses LFB topology issues. Section 3.3 discusses LFB topology issues. This topology information
is represented as components of the FE Object LFB instance, to allow
the CE to fetch and manipulate this.
3.2. LFB (Logical Functional Block) Modeling 3.2. LFB (Logical Functional Block) Modeling
Each LFB performs a well-defined action or computation on the Each LFB performs a well-defined action or computation on the packets
packets passing through it. Upon completion of its prescribed passing through it. Upon completion of its prescribed function,
function, either the packets are modified in certain ways (e.g., either the packets are modified in certain ways (e.g., decapsulator,
decapsulator, marker), or some results are generated and stored, marker), or some results are generated and stored, often in the form
often in the form of metadata (e.g., classifier). Each LFB of metadata (e.g., classifier). Each LFB typically performs a single
typically performs a single action. Classifiers, shapers and meters action. Classifiers, shapers and meters are all examples of such
are all examples of such LFBs. Modeling LFBs at such a fine LFBs. Modeling LFBs at such a fine granularity allows us to use a
granularity allows us to use a small number of LFBs to express the small number of LFBs to express the higher-order FE functions (such
higher-order FE functions (such as an IPv4 forwarder) precisely, as an IPv4 forwarder) precisely, which in turn can describe more
which in turn can describe more complex networking functions and complex networking functions and vendor implementations of software
vendor implementations of software and hardware. These LFBs will be and hardware. These LFBs will be defined in detail in one or more
defined in detail in one or more documents. documents.
An LFB has one or more inputs, each of which takes a packet P, and An LFB has one or more inputs, each of which takes a packet P, and
optionally metadata M; and produces one or more outputs, each of optionally metadata M; and produces one or more outputs, each of
which carries a packet P', and optionally metadata M'. Metadata is which carries a packet P', and optionally metadata M'. Metadata is
data associated with the packet in the network processing device data associated with the packet in the network processing device
(router, switch, etc.) and is passed from one LFB to the next, but (router, switch, etc.) and is passed from one LFB to the next, but is
is not sent across the network. In general, multiple LFBs are not sent across the network. In general, multiple LFBs are contained
contained in one FE, as shown in Figure 2, and all the LFBs share in one FE, as shown in Figure 2, and all the LFBs share the same
the same ForCES protocol termination point that implements the ForCES protocol termination point that implements the ForCES protocol
ForCES protocol logic and maintains the communication channel to and logic and maintains the communication channel to and from the CE.
from the CE.
+-----------+ +-----------+
| CE | | CE |
+-----------+ +-----------+
^ ^
| Fp reference point | Fp reference point
| |
+--------------------------|-----------------------------------+ +--------------------------|-----------------------------------+
| FE | | | FE | |
| v | | v |
skipping to change at page 12, line 25 skipping to change at page 14, line 25
| | ForCES protocol | | | | ForCES protocol | |
| | termination point | | | | termination point | |
| +----------------------------------------------------------+ | | +----------------------------------------------------------+ |
| ^ ^ | | ^ ^ |
| : : Internal control | | : : Internal control |
| : : | | : : |
| +---:----------+ +---:----------| | | +---:----------+ +---:----------| |
| | :LFB1 | | : LFB2 | | | | :LFB1 | | : LFB2 | |
| =====>| v |============>| v |======>...| | =====>| v |============>| v |======>...|
| Inputs| +----------+ |Outputs | +----------+ | | | Inputs| +----------+ |Outputs | +----------+ | |
| (P,M) | |Attributes| |(P',M') | |Attributes| |(P",M") | | (P,M) | |Components| |(P',M') | |Components| |(P",M") |
| | +----------+ | | +----------+ | | | | +----------+ | | +----------+ | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 2. Generic LFB Diagram Figure 2: Generic LFB Diagram
An LFB, as shown in Figure 2, has inputs, outputs and attributes An LFB, as shown in Figure 2, has inputs, outputs and components that
that can be queried and manipulated by the CE indirectly via an Fp can be queried and manipulated by the CE via an Fp reference point
reference point (defined in RFC 3746 [2]) and the ForCES protocol (defined in RFC 3746 [2]) and the ForCES protocol termination point.
termination point. The horizontal axis is in the forwarding plane The horizontal axis is in the forwarding plane for connecting the
for connecting the inputs and outputs of LFBs within the same FE. inputs and outputs of LFBs within the same FE. The vertical axis
The vertical axis between the CE and the FE denotes the Fp reference between the CE and the FE denotes the Fp reference point where
point where bidirectional communication between the CE and FE bidirectional communication between the CE and FE occurs: the CE to
occurs: the CE to FE communication is for configuration, control and FE communication is for configuration, control and packet injection
packet injection while FE to CE communication is used for packet re- while FE to CE communication is used for packet re- direction to the
direction to the control plane, monitoring and accounting control plane, monitoring and accounting information, errors, etc.
information, errors, etc. Note that the interaction between the CE Note that the interaction between the CE and the LFB is only abstract
and the LFB is only abstract and indirect. The result of such an and indirect. The result of such an interaction is for the CE to
interaction is for the CE to indirectly manipulate the attributes of manipulate the components of the LFB instances.
the LFB instances.
A namespace is used to associate a unique name or ID with each LFB A namespace is used to associate a unique name or 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 LFB operation is specified in the model to allow the CE to understand
understand the behavior of the forwarding datapath. For instance, the behavior of the forwarding datapath. For instance, the CE must
the CE must understand at what point in the datapath the IPv4 header understand at what point in the datapath the IPv4 header TTL is
TTL is decremented. That is, the CE needs to know if a control decremented. That is, the CE needs to know if a control packet could
packet could be delivered to it either before or after this point in be delivered to it either before or after this point in the datapath.
the datapath. In addition, the CE MUST understand where and what In addition, the CE MUST understand where and what type of header
type of header modifications (e.g., tunnel header append or strip) modifications (e.g., tunnel header append or strip) are performed by
are performed by the FEs. Further, the CE MUST verify that the the FEs. Further, the CE MUST verify that the various LFBs along a
various LFBs along a datapath within an FE are compatible to link datapath within an FE are compatible to link together.
together.
There is value to vendors if the operation of LFB classes can be There is value to vendors if the operation of LFB classes can be
expressed in sufficient detail so that physical devices implementing expressed in sufficient detail so that physical devices implementing
different LFB functions can be integrated easily into an FE design. different LFB functions can be integrated easily into an FE design.
Therefore, a semi-formal specification is needed; that is, a text Therefore, a semi-formal specification is needed; that is, a text
description of the LFB operation (human readable), but sufficiently description of the LFB operation (human readable), but sufficiently
specific and unambiguous to allow conformance testing and efficient specific and unambiguous to allow conformance testing and efficient
design, so that interoperability between different CEs and FEs can design, so that interoperability between different CEs and FEs can be
be achieved. achieved.
The LFB class model specifies information such as: The LFB class model specifies information such as:
. number of inputs and outputs (and whether they are o number of inputs and outputs (and whether they are configurable)
configurable)
. metadata read/consumed from inputs; o metadata read/consumed from inputs;
. metadata produced at the outputs;
. packet type(s) accepted at the inputs and emitted at the o metadata produced at the outputs;
outputs;
. packet content modifications (including encapsulation or o packet type(s) accepted at the inputs and emitted at the outputs;
o packet content modifications (including encapsulation or
decapsulation); decapsulation);
. packet routing criteria (when multiple outputs on an LFB are
o packet routing criteria (when multiple outputs on an LFB are
present); present);
. packet timing modifications;
. packet flow ordering modifications; o packet timing modifications;
. LFB capability information;
. Events that can be detected by the LFB, with notification to o packet flow ordering modifications;
the CE;
. LFB operational attributes, etc. o LFB capability information components;
o Events that can be detected by the LFB, with notification to the
CE;
o LFB operational components, etc.
Section 4 of this document provides a detailed discussion of the LFB Section 4 of this document provides a detailed discussion of the LFB
model with a formal specification of LFB class schema. The rest of model with a formal specification of LFB class schema. The rest of
Section 3.2 only intends to provide a conceptual overview of some Section 3.2 only intends to provide a conceptual overview of some
important issues in LFB modeling, without covering all the specific important issues in LFB modeling, without covering all the specific
details. details.
3.2.1. LFB Outputs 3.2.1. LFB Outputs
An LFB output is a conceptual port on an LFB that can send An LFB output is a conceptual port on an LFB that can send
skipping to change at page 14, line 34 skipping to change at page 16, line 41
| | | EXCEPTIONOUT +--> | | | EXCEPTIONOUT +-->
| OUT:1 +--> | | | OUT:1 +--> | |
... OUT:2 +--> ... OUT:1 +--> ... OUT:2 +--> ... OUT:1 +-->
| ... +... | OUT:2 +--> | ... +... | OUT:2 +-->
| OUT:n +--> | ... +... | OUT:n +--> | ... +...
+---------------+ | OUT:n +--> +---------------+ | OUT:n +-->
+-----------------+ +-----------------+
c. One output group d. One output and one output group c. One output group d. One output and one output group
Figure 3. Examples of LFBs with various output combinations. Figure 3: Examples of LFBs with various output combinations.
To accommodate a non-trivial LFB topology, multiple LFB outputs are To accommodate a non-trivial LFB topology, multiple LFB outputs are
needed so that an LFB class can fork the datapath. Two mechanisms needed so that an LFB class can fork the datapath. Two mechanisms
are provided for forking: multiple singleton outputs and output are provided for forking: multiple singleton outputs and output
groups, which can be combined in the same LFB class. groups, which can be combined in the same LFB class.
Multiple separate singleton outputs are defined in an LFB class to Multiple separate singleton outputs are defined in an LFB class to
model a pre-determined number of semantically different outputs. model a pre-determined number of semantically different outputs.
That is, the LFB class definition MUST include the number of
outputs, implying the number of outputs is known when the LFB class That is, the LFB class definition MUST include the number of outputs,
is defined. Additional singleton outputs cannot be created at LFB implying the number of outputs is known when the LFB class is
defined. Additional singleton outputs cannot be created at LFB
instantiation time, nor can they be created on the fly after the LFB instantiation time, nor can they be created on the fly after the LFB
is instantiated. is instantiated.
For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one
output(OUT) to send those packets for which the LPM look-up was output(OUT) to send those packets for which the LPM look-up was
successful, passing a META_ROUTEID as metadata; and have another successful, passing a META_ROUTEID as metadata; and have another
output (EXCEPTIONOUT) for sending exception packets when the LPM output (EXCEPTIONOUT) for sending exception packets when the LPM
look-up failed. This example is depicted in Figure 3.b. Packets look-up failed. This example is depicted in Figure 3.b. Packets
emitted by these two outputs not only require different downstream emitted by these two outputs not only require different downstream
treatment, but they are a result of two different conditions in the treatment, but they are a result of two different conditions in the
LFB and each output carries different metadata. This concept LFB and each output carries different metadata. This concept assumes
assumes the number of distinct outputs is known when the LFB class the number of distinct outputs is known when the LFB class is
is defined. For each singleton output, the LFB class definition defined. For each singleton output, the LFB class definition defines
defines the types of frames and metadata the output emits. the types of frames and metadata the output emits.
An output group, on the other hand, is used to model the case where An output group, on the other hand, is used to model the case where a
a flow of similar packets with an identical set of metadata needs to flow of similar packets with an identical set of metadata needs to be
be split into multiple paths. In this case, the number of such paths split into multiple paths. In this case, the number of such paths is
is not known when the LFB class is defined because it is not an not known when the LFB class is defined because it is not an inherent
inherent property of the LFB class. An output group consists of a property of the LFB class. An output group consists of a number of
number of outputs, called the output instances of the group, where outputs, called the output instances of the group, where all output
all output instances share the same frame and metadata emission instances share the same frame and metadata emission definitions (see
definitions (see Figure 3.c). Each output instance can connect to a Figure 3.c). Each output instance can connect to a different
different downstream LFB, just as if they were separate singleton downstream LFB, just as if they were separate singleton outputs, but
outputs, but the number of output instances can differ between LFB the number of output instances can differ between LFB instances of
instances of the same LFB class. The class definition may include a the same LFB class. The class definition may include a lower and/or
lower and/or an upper limit on the number of outputs. In addition, an upper limit on the number of outputs. In addition, for
for configurable FEs, the FE capability information may define configurable FEs, the FE capability information may define further
further limits on the number of instances in specific output groups limits on the number of instances in specific output groups for
for certain LFBs. The actual number of output instances in a group certain LFBs. The actual number of output instances in a group is an
is an attribute of the LFB instance, which is read-only for static attribute of the LFB instance, which is read-only for static
topologies, and read-write for dynamic topologies. The output topologies, and read-write for dynamic topologies. The output
instances in a group are numbered sequentially, from 0 to N-1, and instances in a group are numbered sequentially, from 0 to N-1, and
are addressable from within the LFB. The LFB has a built-in are addressable from within the LFB. The LFB has a built-in
mechanism to select one specific output instance for each packet. mechanism to select one specific output instance for each packet.
This mechanism is described in the textual definition of the class This mechanism is described in the textual definition of the class
and is typically configurable via some attributes of the LFB. and is typically configurable via some attributes of the LFB.
For example, consider a re-director LFB, whose sole purpose is to For example, consider a re-director LFB, whose sole purpose is to
direct packets to one of N downstream paths based on one of the direct packets to one of N downstream paths based on one of the
metadata associated with each arriving packet. Such an LFB is metadata associated with each arriving packet. Such an LFB is fairly
fairly versatile and can be used in many different places in a versatile and can be used in many different places in a topology.
topology. For example, a redirector can be used to divide the data For example, a redirector can be used to divide the data path into an
path into an IPv4 and an IPv6 path based on a FRAMETYPE metadata IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork
(N=2), or to fork into color specific paths after metering using the into color specific paths after metering using the COLOR metadata
COLOR metadata (red, yellow, green; N=3), etc. (red, yellow, green; N=3), etc.
Using an output group in the above LFB class provides the desired Using an output group in the above LFB class provides the desired
flexibility to adapt each instance of this class to the required flexibility to adapt each instance of this class to the required
operation. The metadata to be used as a selector for the output operation. The metadata to be used as a selector for the output
instance is a property of the LFB. For each packet, the value of instance is a property of the LFB. For each packet, the value of the
the specified metadata may be used as a direct index to the output specified metadata may be used as a direct index to the output
instance. Alternatively, the LFB may have a configurable selector instance. Alternatively, the LFB may have a configurable selector
table that maps a metadata value to output instance. table that maps a metadata value to output instance.
Note that other LFBs may also use the output group concept to build Note that other LFBs may also use the output group concept to build
in similar adaptive forking capability. For example, a classifier in similar adaptive forking capability. For example, a classifier
LFB with one input and N outputs can be defined easily by using the LFB with one input and N outputs can be defined easily by using the
output group concept. Alternatively, a classifier LFB with one output group concept. Alternatively, a classifier LFB with one
singleton output in combination with an explicit N-output re- singleton output in combination with an explicit N-output re-
director LFB models the same processing behavior. The decision of director LFB models the same processing behavior. The decision of
whether to use the output group model for a certain LFB class is whether to use the output group model for a certain LFB class is left
left to the LFB class designers. to the LFB class designers.
The model allows the output group to be combined with other The model allows the output group to be combined with other singleton
singleton output(s) in the same class, as demonstrated in Figure output(s) in the same class, as demonstrated in Figure 3.d. The LFB
3.d. The LFB here has two types of outputs, OUT, for normal packet here has two types of outputs, OUT, for normal packet output, and
output, and EXCEPTIONOUT for packets that triggered some exception. EXCEPTIONOUT for packets that triggered some exception. The normal
The normal OUT has multiple instances, thus, it is an output group. OUT has multiple instances, thus, it is an output group.
In summary, the LFB class may define one output, multiple singleton In summary, the LFB class may define one output, multiple singleton
outputs, one or more output groups, or a combination thereof. outputs, one or more output groups, or a combination thereof.
Multiple singleton outputs should be used when the LFB must provide Multiple singleton outputs should be used when the LFB must provide
for forking the datapath, and at least one of the following for forking the datapath, and at least one of the following
conditions hold: conditions hold:
. the number of downstream directions are inherent from the o the number of downstream directions are inherent from the
definition of the class and hence fixed; definition of the class and hence fixed;
. the frame type and set of metadata emitted on any of the
outputs are substantially different from what is emitted on o the frame type and set of metadata emitted on any of the outputs
the other outputs (i.e., they cannot share frame-type and are substantially different from what is emitted on the other
metadata definitions); outputs (i.e., they cannot share frame-type and metadata
definitions);
An output group is appropriate when the LFB must provide for forking An output group is appropriate when the LFB must provide for forking
the datapath, and at least one of the following conditions hold: the datapath, and at least one of the following conditions hold:
. the number of downstream directions is not known when the LFB o the number of downstream directions is not known when the LFB
class is defined; class is defined;
. the frame type and set of metadata emitted on these outputs are
sufficiently similar or ideally identical, such they can share o the frame type and set of metadata emitted on these outputs are
the same output definition. sufficiently similar or ideally identical, such they can share the
same output definition.
3.2.2. LFB Inputs 3.2.2. LFB Inputs
An LFB input is a conceptual port on an LFB where the LFB can An LFB input is a conceptual port on an LFB where the LFB can receive
receive information from other LFBs. The information is typically a information from other LFBs. The information is typically a packet
packet and associated metadata, although in some cases it might and associated metadata, although in some cases it might consist of
consist of only metadata, without any packet data. only metadata, without any packet data.
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 instance (fan-in). There are three ways to model fan-in, all
supported by the LFB model and can be combined in the same LFB: supported by the LFB model and can be combined in the same LFB:
. Implicit multiplexing via a single input o Implicit multiplexing via a single input
. Explicit multiplexing via multiple singleton inputs
. Explicit multiplexing via a group of inputs (input group)
The simplest form of multiplexing uses a singleton input (Figure o Explicit multiplexing via multiple singleton inputs
4.a). Most LFBs will have only one singleton input. Multiplexing
o Explicit multiplexing via a group of inputs (input group)
The simplest form of multiplexing uses a singleton input (Figure 4
.a). Most LFBs will have only one singleton input. Multiplexing
into a single input is possible because the model allows more than into a single input is possible because the model allows more than
one LFB output to connect to the same LFB input. This property one LFB output to connect to the same LFB input. This property
applies to any LFB input without any special provisions in the LFB applies to any LFB input without any special provisions in the LFB
class. Multiplexing into a single input is applicable when the class. Multiplexing into a single input is applicable when the
packets from the upstream LFBs are similar in frame-type and packets from the upstream LFBs are similar in frame-type and
accompanying metadata, and require similar processing. Note that accompanying metadata, and require similar processing. Note that
this model does not address how potential contention is handled when this model does not address how potential contention is handled when
multiple packets arrive simultaneously. If contention handling multiple packets arrive simultaneously. If contention handling needs
needs to be explicitly modeled, one of the other two modeling to be explicitly modeled, one of the other two modeling solutions
solutions must be used. must be used.
The second method to model fan-in uses individually defined The second method to model fan-in uses individually defined singleton
singleton inputs (Figure 4.b). This model is meant for situations inputs (Figure 4.b). This model is meant for situations where the
where the LFB needs to handle distinct types of packet streams, LFB needs to handle distinct types of packet streams, requiring
requiring input-specific handling inside the LFB, and where the input-specific handling inside the LFB, and where the number of such
number of such distinct cases is known when the LFB class is distinct cases is known when the LFB class is defined. For example,
defined. For example, a Layer 2 Decapsulation/Encapsulation LFB may a Layer 2 Decapsulation/Encapsulation LFB may have two inputs, one
have two inputs, one for receiving Layer 2 frames for decapsulation, for receiving Layer 2 frames for decapsulation, and one for receiving
and one for receiving Layer 3 frames for encapsulation. This LFB Layer 3 frames for encapsulation. This LFB type expects different
type expects different frames (L2 vs. L3) at its inputs, each with frames (L2 vs. L3) at its inputs, each with different sets of
different sets of metadata, and would thus apply different metadata, and would thus apply different processing on frames
processing on frames arriving at these inputs. This model is arriving at these inputs. This model is capable of explicitly
capable of explicitly addressing packet contention by defining how addressing packet contention by defining how the LFB class handles
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 18, line 31 skipping to change at page 21, line 5
+--------------+ |... | | +--------------+ |... | |
+-->|in:N-1 / | +-->|in:N-1 / |
... | | | ... | | |
+--------------+ | | | +--------------+ | | |
| Queue LFB #N |---+ | Scheduler LFB | | Queue LFB #N |---+ | Scheduler LFB |
+--------------+ +------------------------+ +--------------+ +------------------------+
(c) A Scheduler LFB uses an input group to differentiate which queue (c) A Scheduler LFB uses an input group to differentiate which queue
LFB packets are coming from. LFB packets are coming from.
Figure 3. Input modeling concepts (examples). Figure 4: Input modeling concepts (examples).
The third method to model fan-in uses the concept of an input group. The third method to model fan-in uses the concept of an input group.
The concept is similar to the output group introduced in the The concept is similar to the output group introduced in the previous
previous section, and is depicted in Figure 4.c. An input group section, and is depicted in Figure 4.c. An input group consists of a
consists of a number of input instances, all sharing the properties number of input instances, all sharing the properties (same frame and
(same frame and metadata expectations). The input instances are metadata expectations). The input instances are numbered from 0 to
numbered from 0 to N-1. From the outside, these inputs appear as N-1. From the outside, these inputs appear as normal inputs, i.e.,
normal inputs, i.e., any compatible upstream LFB can connect its any compatible upstream LFB can connect its output to one of these
output to one of these inputs. When a packet is presented to the inputs. When a packet is presented to the LFB at a particular input
LFB at a particular input instance, the index of the input where the instance, the index of the input where the packet arrived is known to
packet arrived is known to the LFB and this information may be used the LFB and this information may be used in the internal processing.
in the internal processing. For example, the input index can be For example, the input index can be used as a table selector, or as
used as a table selector, or as an explicit precedence selector to an explicit precedence selector to resolve contention. As with
resolve contention. As with output groups, the number of input output groups, the number of input instances in an input group is not
instances in an input group is not defined in the LFB class. defined in the LFB class. However, the class definition may include
However, the class definition may include restrictions on the range restrictions on the range of possible values. In addition, if an FE
of possible values. In addition, if an FE supports configurable supports configurable topologies, it may impose further limitations
topologies, it may impose further limitations on the number of on the number of instances for a particular port group(s) of a
instances for a particular port group(s) of a particular LFB class. particular LFB class. Within these limitations, different instances
Within these limitations, different instances of the same class may of the same class may have a different number of input instances.
have a different number of input instances. The number of actual The number of actual input instances in the group is an component
input instances in the group is an attribute of the LFB class, which defined in the LFB class, which
is read-only for static topologies, and is read-write for is read-only for static topologies, and is read-write for
configurable topologies. configurable topologies.
As an example for the input group, consider the Scheduler LFB As an example for the input group, consider the Scheduler LFB
depicted in Figure 3.c. Such an LFB receives packets from a number depicted in Figure 3.c. Such an LFB receives packets from a number
of Queue LFBs via a number of input instances, and uses the input of Queue LFBs via a number of input instances, and uses the input
index information to control contention resolution and scheduling. index information to control contention resolution and scheduling.
In summary, the LFB class may define one input, multiple singleton In summary, the LFB class may define one input, multiple singleton
inputs, one or more input groups, or a combination thereof. Any inputs, one or more input groups, or a combination thereof. Any
input allows for implicit multiplexing of similar packet streams via input allows for implicit multiplexing of similar packet streams via
connecting multiple outputs to the same input. Explicit multiple connecting multiple outputs to the same input. Explicit multiple
singleton inputs are useful when either the contention handling must singleton inputs are useful when either the contention handling must
be handled explicitly, or when the LFB class must receive and be handled explicitly, or when the LFB class must receive and process
process a known number of distinct types of packet streams. An a known number of distinct types of packet streams. An input group
input group is suitable when contention handling must be modeled is suitable when contention handling must be modeled explicitly, but
explicitly, but the number of inputs are not inherent from the class the number of inputs are not inherent from the class (and hence is
(and hence is not known when the class is defined), or when it is not known when the class is defined), or when it is critical for LFB
critical for LFB operation to know exactly on which input the packet operation to know exactly on which input the packet was received.
was received.
3.2.3. Packet Type 3.2.3. Packet Type
When LFB classes are defined, the input and output packet formats When LFB classes are defined, the input and output packet formats
(e.g., IPv4, IPv6, Ethernet, etc.) MUST be specified. These are the (e.g., IPv4, IPv6, Ethernet, etc.) MUST be specified. These are the
types of packets a given LFB input is capable of receiving and types of packets a given LFB input is capable of receiving and
processing, or a given LFB output is capable of producing. This processing, or a given LFB output is capable of producing. This
requires distinct packet types be uniquely labeled with a symbolic requires distinct packet types be uniquely labeled with a symbolic
name and/or ID. name and/or ID.
Note that each LFB has a set of packet types that it operates on, Note that each LFB has a set of packet types that it operates on, but
but does not care whether the underlying implementation is passing a does not care whether the underlying implementation is passing a
greater portion of the packets. For example, an IPv4 LFB might only greater portion of the packets. For example, an IPv4 LFB might only
operate on IPv4 packets, but the underlying implementation may or operate on IPv4 packets, but the underlying implementation may or may
may not be stripping the L2 header before handing it over -- whether not be stripping the L2 header before handing it over -- whether that
that is happening or not is opaque to the CE. is happening or not is opaque to the CE.
3.2.4. Metadata 3.2.4. Metadata
Metadata is the per-packet state that is passed from one LFB to Metadata is the per-packet state that is passed from one LFB to
another. The metadata is passed with the packet to assist subsequent another. The metadata is passed with the packet to assist subsequent
LFBs to process that packet. The ForCES model captures how the per- LFBs to process that packet. The ForCES model captures how the per-
packet state information is propagated from one LFB to other LFBs. packet state information is propagated from one LFB to other LFBs.
Practically, such metadata propagation can happen within one FE, or Practically, such metadata propagation can happen within one FE, or
cross the FE boundary between two interconnected FEs. We believe cross the FE boundary between two interconnected FEs. We believe
that the same metadata model can be used for either situation; that the same metadata model can be used for either situation;
however, our focus here is for intra-FE metadata. however, our focus here is for intra-FE metadata.
3.2.4.1. Metadata Vocabulary 3.2.4.1. Metadata Vocabulary
Metadata has historically been understood to mean "data about data". Metadata has historically been understood to mean "data about data".
While this definition is a start, it is inadequate to describe the While this definition is a start, it is inadequate to describe the
multiple forms of metadata, which may appear within a complex multiple forms of metadata, which may appear within a complex network
network element. The discussion here categorizes forms of metadata element. The discussion here categorizes forms of metadata by two
by two orthogonal axes. orthogonal axes.
The first axis is "internal" versus "external", which describes The first axis is "internal" versus "external", which describes where
where the metadata exists in the network model or implementation. the metadata exists in the network model or implementation. For
For example, a particular vendor implementation of an IPv4 forwarder example, a particular vendor implementation of an IPv4 forwarder may
may make decisions inside of a chip that are not visible externally. make decisions inside of a chip that are not visible externally.
Those decisions are metadata for the packet that is "internal" to Those decisions are metadata for the packet that is "internal" to the
the chip. When a packet is forwarded out of the chip, it may be chip. When a packet is forwarded out of the chip, it may be marked
marked with a traffic management header. That header, which is with a traffic management header. That header, which is metadata for
metadata for the packet, is visible outside of the chip, and is the packet, is visible outside of the chip, and is therefore called
therefore called "external" metadata. "external" metadata.
The second axis is "implicit" versus "expressed", which specifies The second axis is "implicit" versus "expressed", which specifies
whether or not the metadata has a visible physical representation. whether or not the metadata has a visible physical representation.
For example, the traffic management header described in the previous For example, the traffic management header described in the previous
paragraph may be represented as a series of bits in some format, and paragraph may be represented as a series of bits in some format, and
that header is associated with the packet. Those bits have physical that header is associated with the packet. Those bits have physical
representation, and are therefore "expressed" metadata. If the representation, and are therefore "expressed" metadata. If the
metadata does not have a physical representation, it is called metadata does not have a physical representation, it is called
"implicit" metadata. This situation occurs, for example, when a "implicit" metadata. This situation occurs, for example, when a
particular path through a network device is intended to be traversed particular path through a network device is intended to be traversed
only by particular kinds of packets, such as an IPv4 router. An only by particular kinds of packets, such as an IPv4 router. An
implementation may not mark every packet along this path as being of implementation may not mark every packet along this path as being of
type "IPv4", but the intention of the designers is that every packet type "IPv4", but the intention of the designers is that every packet
is of that type. This understanding can be thought of as metadata is of that type. This understanding can be thought of as metadata
about the packet, which is implicitly attached to the packet through about the packet, which is implicitly attached to the packet through
the intent of the designers. the intent of the designers.
In the ForCES model, we do not discuss or represent metadata In the ForCES model, we do not discuss or represent metadata
"internal" to vendor implementations of LFBs. Our focus is solely "internal" to vendor implementations of LFBs. Our focus is solely on
on metadata "external" to the LFBs, and therefore visible in the metadata "external" to the LFBs, and therefore visible in the ForCES
ForCES model. The metadata discussed within this model may, or may model. The metadata discussed within this model may, or may not be
not be visible outside of the particular FE implementing the LFB visible outside of the particular FE implementing the LFB model. In
model. In this regard, the scope of the metadata within ForCES is this regard, the scope of the metadata within ForCES is very narrowly
very narrowly defined. defined.
Note also that while we define metadata within this model, it is Note also that while we define metadata within this model, it is only
only a model. There is no requirement that vendor implementations a model. There is no requirement that vendor implementations of
of ForCES use the exact metadata representations described in this ForCES use the exact metadata representations described in this
document. The only implementation requirement is that vendors document. The only implementation requirement is that vendors
implement the ForCES protocol, not the model. implement the ForCES protocol, not the model.
3.2.4.2. Metadata lifecycle within the ForCES model 3.2.4.2. Metadata lifecycle within the ForCES model
Each metadata can be conveniently modeled as a <label, value> pair, Each metadata can be conveniently modeled as a <label, value> pair,
where the label identifies the type of information, (e.g., "color"), where the label identifies the type of information, (e.g., "color"),
and its value holds the actual information (e.g., "red"). The tag and its value holds the actual information (e.g., "red"). The tag
here is shown as a textual label, but it can be replaced or here is shown as a textual label, but it can be replaced or
associated with a unique numeric value (identifier). associated with a unique numeric value (identifier).
The metadata life-cycle is defined in this model using three types The metadata life-cycle is defined in this model using three types of
of events: "write", "read" and "consume". The first "write" events: "write", "read" and "consume". The first "write" implicitly
implicitly creates and initializes the value of the metadata, and creates and initializes the value of the metadata, and hence starts
hence starts the life-cycle. The explicit "consume" event the life-cycle. The explicit "consume" event terminates the life-
terminates the life-cycle. Within the life-cycle, that is, after a cycle. Within the life-cycle, that is, after a "write" event, but
"write" event, but before the next "consume" event, there can be an before the next "consume" event, there can be an arbitrary number of
arbitrary number of "write" and "read" events. These "read" and "write" and "read" events. These "read" and "write" events can be
"write" events can be mixed in an arbitrary order within the life- mixed in an arbitrary order within the life- cycle. Outside of the
cycle. Outside of the life-cycle of the metadata, that is, before life-cycle of the metadata, that is, before the first "write" event,
the first "write" event, or between a "consume" event and the next or between a "consume" event and the next "write" event, the metadata
"write" event, the metadata should be regarded non-existent or non- should be regarded non-existent or non- initialized. Thus, reading a
initialized. Thus, reading a metadata outside of its life-cycle is metadata outside of its life-cycle is considered an error.
considered an error.
To ensure inter-operability between LFBs, the LFB class To ensure inter-operability between LFBs, the LFB class specification
specification must define what metadata the LFB class "reads" or must define what metadata the LFB class "reads" or "consumes" on its
"consumes" on its input(s) and what metadata it "produces" on its input(s) and what metadata it "produces" on its output(s). For
output(s). For maximum extensibility, this definition should maximum extensibility, this definition should neither specify which
neither specify which LFBs the metadata is expected to come from for LFBs the metadata is expected to come from for a consumer LFB, nor
a consumer LFB, nor which LFBs are expected to consume metadata for which LFBs are expected to consume metadata for a given producer LFB.
a given producer LFB.
While it is important to define the metadata types passing between While it is important to define the metadata types passing between
LFBs, it is not appropriate to define the exact encoding mechanism LFBs, it is not appropriate to define the exact encoding mechanism
used by LFBs for that metadata. Different implementations are used by LFBs for that metadata. Different implementations are
allowed to use different encoding mechanisms for metadata. For allowed to use different encoding mechanisms for metadata. For
example, one implementation may store metadata in registers or example, one implementation may store metadata in registers or shared
shared memory, while another implementation may encode metadata in- memory, while another implementation may encode metadata in- band as
band as a preamble in the packets. In order to allow the CE to a preamble in the packets. In order to allow the CE to understand
understand and control the meta-data related operations, the model and control the meta-data related operations, the model represents
represents each metadata tag as a 32-bit integer. Each LFB each metadata tag as a 32-bit integer. Each LFB definition indicates
definition indicates in its metadata declarations the 32-bit value in its metadata declarations the 32-bit value associated with a given
associated with a given metadata tag. Ensuring consistency of usage metadata tag. Ensuring consistency of usage of tags is important,
of tags is important, and outside the scope of the model. and outside the scope of the model.
At any link between two LFBs, the packet is marked with a finite set At any link between two LFBs, the packet is marked with a finite set
of active metadata, where active means the metadata is within its of active metadata, where active means the metadata is within its
life-cycle. There are two corollaries of this model: life-cycle. There are two corollaries of this model:
1. No un-initialized metadata exists in the model. 1. No un-initialized metadata exists in the model.
2. No more than one occurrence of each metadata tag can be 2. No more than one occurrence of each metadata tag can be
associated with a packet at any given time. associated with a packet at any given time.
3.2.4.3. LFB Operations on Metadata 3.2.4.3. LFB Operations on Metadata
When the packet is processed by an LFB (i.e., between the time it is When the packet is processed by an LFB (i.e., between the time it is
received and forwarded by the LFB), the LFB may perform read, write received and forwarded by the LFB), the LFB may perform read, write
and/or consume operations on any active metadata associated with the and/or consume operations on any active metadata associated with the
packet. If the LFB is considered to be a black box, one of the packet. If the LFB is considered to be a black box, one of the
following operations is performed on each active metadata. following operations is performed on each active metadata.
. IGNORE: ignores and forwards the metadata * IGNORE: ignores and forwards the metadata
. READ: reads and forwards the metadata
. READ/RE-WRITE: reads, over-writes and forwards the metadata * READ: reads and forwards the metadata
. WRITE: writes and forwards the metadata
(can also be used to create new metadata) * READ/RE-WRITE: reads, over-writes and forwards the metadata
. READ-AND-CONSUME: reads and consumes the metadata
. CONSUME consumes metadata without reading * WRITE: writes and forwards the metadata (can also be used to
create new metadata)
* READ-AND-CONSUME: reads and consumes the metadata
* CONSUME consumes metadata without reading
The last two operations terminate the life-cycle of the metadata, The last two operations terminate the life-cycle of the metadata,
meaning that the metadata is not forwarded with the packet when the meaning that the metadata is not forwarded with the packet when the
packet is sent to the next LFB. packet is sent to the next LFB.
In our model, a new metadata is generated by an LFB when the LFB In our model, a new metadata is generated by an LFB when the LFB
applies a WRITE operation to a metadata type that was not present applies a WRITE operation to a metadata type that was not present
when the packet was received by the LFB. Such implicit creation may when the packet was received by the LFB. Such implicit creation may
be unintentional by the LFB, that is, the LFB may apply the WRITE be unintentional by the LFB, that is, the LFB may apply the WRITE
operation without knowing or caring if the given metadata existed or operation without knowing or caring if the given metadata existed or
not. If it existed, the metadata gets over-written; if it did not not. If it existed, the metadata gets over-written; if it did not
exist, the metadata is created. exist, the metadata is created.
For LFBs that insert packets into the model, WRITE is the only For LFBs that insert packets into the model, WRITE is the only
meaningful metadata operation. meaningful metadata operation.
For LFBs that remove the packet from the model, they may either For LFBs that remove the packet from the model, they may either READ-
READ-AND-CONSUME (read) or CONSUME (ignore) each active metadata AND-CONSUME (read) or CONSUME (ignore) each active metadata
associated with the packet. associated with the packet.
3.2.4.4. Metadata Production and Consumption 3.2.4.4. Metadata Production and Consumption
For a given metadata on a given packet path, there MUST be at least For a given metadata on a given packet path, there MUST be at least
one producer LFB that creates that metadata and SHOULD be at least one producer LFB that creates that metadata and SHOULD be at least
one consumer LFB that needs that metadata. In this model, the one consumer LFB that needs that metadata. In this model, the
producer and consumer LFBs of a metadata are not required to be producer and consumer LFBs of a metadata are not required to be
adjacent. In addition, there may be multiple producers and adjacent. In addition, there may be multiple producers and consumers
consumers for the same metadata. When a packet path involves for the same metadata. When a packet path involves multiple
multiple producers of the same metadata, then subsequent producers producers of the same metadata, then subsequent producers overwrite
overwrite that metadata value. that metadata value.
The metadata that is produced by an LFB is specified by the LFB The metadata that is produced by an LFB is specified by the LFB class
class definition on a per output port group basis. A producer may definition on a per output port group basis. A producer may always
always generate the metadata on the port group, or may generate it generate the metadata on the port group, or may generate it only
only under certain conditions. We call the former an under certain conditions. We call the former an "unconditional"
"unconditional" metadata, whereas the latter is a "conditional" metadata, whereas the latter is a "conditional" metadata. In the
metadata. In the case of conditional metadata, it should be case of conditional metadata, it should be possible to determine from
possible to determine from the definition of the LFB when a the definition of the LFB when a "conditional" metadata is produced.
"conditional" metadata is produced.
The consumer behavior of an LFB, that is, the metadata that the LFB The consumer behavior of an LFB, that is, the metadata that the LFB
needs for its operation, is defined in the LFB class definition on a needs for its operation, is defined in the LFB class definition on a
per input port group basis. An input port group may "require" a per input port group basis. An input port group may "require" a
given metadata, or may treat it as "optional" information. In the given metadata, or may treat it as "optional" information. In the
latter case, the LFB class definition MUST explicitly define what latter case, the LFB class definition MUST explicitly define what
happens if an optional metadata is not provided. One approach is to happens if an optional metadata is not provided. One approach is to
specify a default value for each optional metadata, and assume that specify a default value for each optional metadata, and assume that
the default value is used if the metadata is not provided with the the default value is used if the metadata is not provided with the
packet. packet.
When a consumer LFB requires a given metadata, it has dependencies When a consumer LFB requires a given metadata, it has dependencies on
on its up-stream LFBs. That is, the consumer LFB can only function its up-stream LFBs. That is, the consumer LFB can only function if
if there is at least one producer of that metadata and no there is at least one producer of that metadata and no intermediate
intermediate LFB consumes the metadata. LFB consumes the metadata.
The model should expose these inter-dependencies. Furthermore, it The model should expose these inter-dependencies. Furthermore, it
should be possible to take inter-dependencies into consideration should be possible to take inter-dependencies into consideration when
when constructing LFB topologies, and also that the dependencies can constructing LFB topologies, and also that the dependencies can be
be verified when validating topologies. verified when validating topologies.
For extensibility reasons, the LFB specification SHOULD define what For extensibility reasons, the LFB specification SHOULD define what
metadata the LFB requires without specifying which LFB(s) it expects metadata the LFB requires without specifying which LFB(s) it expects
a certain metadata to come from. Similarly, LFBs SHOULD specify a certain metadata to come from. Similarly, LFBs SHOULD specify what
what metadata they produce without specifying which LFBs the metadata they produce without specifying which LFBs the metadata is
metadata is meant for. meant for.
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 made so that the producer LFB class uses the same tag as its intended
intended consumer(s), or vice versa. consumer(s), or vice versa.
3.2.4.5. Fixed, Variable and Configurable Tag 3.2.4.5. Fixed, Variable and Configurable Tag
When the produced metadata is defined for a given LFB class, most When the produced metadata is defined for a given LFB class, most
metadata will be specified with a fixed tag. For example, a Rate metadata will be specified with a fixed tag. For example, a Rate
Meter LFB will always produce the "Color" metadata. Meter LFB will always produce the "Color" metadata.
A small subset of LFBs need the capability to produce one or more of A small subset of LFBs need the capability to produce one or more of
their metadata with tags that are not fixed in the LFB class their metadata with tags that are not fixed in the LFB class
definition, but instead can be selected per LFB instance. An definition, but instead can be selected per LFB instance. An example
example of such an LFB class is a Generic Classifier LFB. We call of such an LFB class is a Generic Classifier LFB. We call this
this capability "variable tag metadata production". If an LFB capability "variable tag metadata production". If an LFB
produces metadata with a variable tag, the corresponding LFB produces metadata with a variable tag, the corresponding LFB
attribute, called the tag selector, specifies the tag for each such attribute, called the tag selector, specifies the tag for each such
metadata. This mechanism improves the versatility of certain multi- metadata. This mechanism improves the versatility of certain multi-
purpose LFB classes, since it allows the same LFB class to be used purpose LFB classes, since it allows the same LFB class to be used in
in different topologies, producing the right metadata tags according different topologies, producing the right metadata tags according to
to the needs of the topology. This selection of tags is variable in the needs of the topology. This selection of tags is variable in
that the produced output may have any number of different tags. The that the produced output may have any number of different tags. The
meaning of the various tags is still defined by the metadata meaning of the various tags is still defined by the metadata
declaration associated with the LFB class definition. This also declaration associated with the LFB class definition. This also
allows the CE to correctly set the tag values in the table to match allows the CE to correctly set the tag values in the table to match
the declared meanings of the metadata tag values. the declared meanings of the metadata tag values.
Depending on the capability of the FE, the tag selector can be Depending on the capability of the FE, the tag selector can be either
either a read-only or a read-write attribute. If the selector is a read-only or a read-write attribute. If the selector is read-only,
read-only, the tag cannot be modified by the CE. If the selector is the tag cannot be modified by the CE. If the selector is read-write,
read-write, the tag can be configured by the CE, hence we call this the tag can be configured by the CE, hence we call this "configurable
"configurable tag metadata production." Note that using this tag metadata production." Note that using this definition,
definition, configurable tag metadata production is a subset of configurable tag metadata production is a subset of variable tag
variable tag metadata production. metadata production.
Similar concepts can be introduced for the consumer LFBs to satisfy Similar concepts can be introduced for the consumer LFBs to satisfy
different metadata needs. Most LFB classes will specify their different metadata needs. Most LFB classes will specify their
metadata needs using fixed metadata tags. For example, a Next Hop metadata needs using fixed metadata tags. For example, a Next Hop
LFB may always require a "NextHopId" metadata; but the Redirector LFB may always require a "NextHopId" metadata; but the Redirector LFB
LFB may need a "ClassID" metadata in one instance, and a may need a "ClassID" metadata in one instance, and a "ProtocolType"
"ProtocolType" metadata in another instance as a basis for selecting metadata in another instance as a basis for selecting the right
the right output port. In this case, an LFB attribute is used to output port. In this case, an LFB attribute is used to provide the
provide the required metadata tag at run-time. This metadata tag required metadata tag at run-time. This metadata tag selector
selector attribute may be read-only or read-write, depending on the attribute may be read-only or read-write, depending on the
capabilities of the LFB instance and the FE. capabilities of the LFB instance and the FE.
3.2.4.6. Metadata Usage Categories 3.2.4.6. Metadata Usage Categories
Depending on the role and usage of a metadata, various amounts of Depending on the role and usage of a metadata, various amounts of
encoding information MUST be provided when the metadata is defined, encoding information MUST be provided when the metadata is defined,
where some cases offer less flexibility in the value selection than where some cases offer less flexibility in the value selection than
others. others.
There are three types of metadata related to metadata usage: There are three types of metadata related to metadata usage:
. Relational (or binding) metadata o Relational (or binding) metadata
. Enumerated metadata
. Explicit/external value metadata o Enumerated metadata
o Explicit/external value metadata
The purpose of the relational metadata is to refer in one LFB The purpose of the relational metadata is to refer in one LFB
instance (producer LFB) to a "thing" in another downstream LFB instance (producer LFB) to a "thing" in another downstream LFB
instance (consumer LFB), where the "thing" is typically an entry in instance (consumer LFB), where the "thing" is typically an entry in a
a table attribute of the consumer LFB. table attribute of the consumer LFB.
For example, the Prefix Lookup LFB executes an LPM search using its For example, the Prefix Lookup LFB executes an LPM search using its
prefix table and resolves to a next-hop reference. This reference prefix table and resolves to a next-hop reference. This reference
needs to be passed as metadata by the Prefix Lookup LFB (producer) needs to be passed as metadata by the Prefix Lookup LFB (producer) to
to the Next Hop LFB (consumer), and must refer to a specific entry the Next Hop LFB (consumer), and must refer to a specific entry in
in the next-hop table within the consumer. the next-hop table within the consumer.
Expressing and propagating such a binding relationship is probably Expressing and propagating such a binding relationship is probably
the most common usage of metadata. One or more objects in the the most common usage of metadata. One or more objects in the
producer LFB are bound to a specific object in the consumer LFB. producer LFB are bound to a specific object in the consumer LFB.
Such a relationship is established by the CE explicitly by properly Such a relationship is established by the CE explicitly by properly
configuring the attributes in both LFBs. Available methods include configuring the attributes in both LFBs. Available methods include
the following: the following:
The binding may be expressed by tagging the involved objects in both The binding may be expressed by tagging the involved objects in both
LFBs with the same unique, but otherwise arbitrary, identifier. The LFBs with the same unique, but otherwise arbitrary, identifier. The
value of the tag is explicitly configured by the CE by writing the value of the tag is explicitly configured by the CE by writing the
value into both LFBs, and this value is also carried by the metadata value into both LFBs, and this value is also carried by the metadata
between the LFBs. between the LFBs.
Another way of setting up binding relations is to use a naturally Another way of setting up binding relations is to use a naturally
occurring unique identifier of the consumer's object as a reference occurring unique identifier of the consumer's object as a reference
and as a value of the metadata (e.g., the array index of a table and as a value of the metadata (e.g., the array index of a table
entry). In this case, the index is either read or inferred by the entry). In this case, the index is either read or inferred by the CE
CE by communicating with the consumer LFB. Once the CE obtains the by communicating with the consumer LFB. Once the CE obtains the
index, it needs to write it into the producer LFB to establish the index, it needs to write it into the producer LFB to establish the
binding. binding.
Important characteristics of the binding usage of metadata are: Important characteristics of the binding usage of metadata are:
. The value of the metadata shows up in the CE-FE communication o The value of the metadata shows up in the CE-FE communication for
for both the consumer and the producer. That is, the metadata both the consumer and the producer. That is, the metadata value
value MUST be carried over the ForCES protocol. Using the MUST be carried over the ForCES protocol. Using the tagging
tagging technique, the value is written to both LFBs. Using technique, the value is written to both LFBs. Using the other
the other technique, the value is written to only the producer technique, the value is written to only the producer LFB and may
LFB and may be READ from the consumer LFB. be READ from the consumer LFB.
. The metadata value is irrelevant to the CE, the binding is o The metadata value is irrelevant to the CE, the binding is simply
simply expressed by using the same value at the consumer and expressed by using the same value at the consumer and producer
producer LFBs. LFBs.
. Hence the metadata definition is not required to include value o Hence the metadata definition is not required to include value
assignments. The only exception is when some special value(s) assignments. The only exception is when some special value(s) of
of the metadata must be reserved to convey special events. the metadata must be reserved to convey special events. Even
Even though these special cases must be defined with the though these special cases must be defined with the metadata
metadata specification, their encoded values can be selected specification, their encoded values can be selected arbitrarily.
arbitrarily. For example, for the Prefix Lookup LFB example, a For example, for the Prefix Lookup LFB example, a special value
special value may be reserved to signal the NO-MATCH case, and may be reserved to signal the NO-MATCH case, and the value of zero
the value of zero may be assigned for this purpose. may be assigned for this purpose.
The second class of metadata is the enumerated type. An example is The second class of metadata is the enumerated type. An example is
the "Color" metadata that is produced by a Meter LFB. As the name the "Color" metadata that is produced by a Meter LFB. As the name
suggests, enumerated metadata has a relatively small number of suggests, enumerated metadata has a relatively small number of
possible values, each with a specific meaning. All possible cases possible values, each with a specific meaning. All possible cases
must be enumerated when defining this class of metadata. Although a must be enumerated when defining this class of metadata. Although a
value encoding must be included in the specification, the actual value encoding must be included in the specification, the actual
values can be selected arbitrarily (e.g., <Red=0, Yellow=1, Green=2> values can be selected arbitrarily (e.g., <Red=0, Yellow=1, Green=2>
and <Red=3, Yellow=2, Green 1> would be both valid encodings, what and <Red=3, Yellow=2, Green 1> would be both valid encodings, what is
is important is that an encoding is specified). important is that an encoding is specified).
The value of the enumerated metadata may or may not be conveyed via The value of the enumerated metadata may or may not be conveyed via
the ForCES protocol between the CE and FE. the ForCES protocol between the CE and FE.
The third class of metadata is the explicit type. This refers to The third class of metadata is the explicit type. This refers to
cases where the metadata value is explicitly used by the consumer cases where the metadata value is explicitly used by the consumer LFB
LFB to change some packet header fields. In other words, the value to change some packet header fields. In other words, the value has a
has a direct and explicit impact on some field and will be visible direct and explicit impact on some field and will be visible
externally when the packet leaves the NE. Examples are: TTL externally when the packet leaves the NE. Examples are: TTL
increment given to a Header Modifier LFB, and DSCP value for a increment given to a Header Modifier LFB, and DSCP value for a
Remarker LFB. For explicit metadata, the value encoding MUST be Remarker LFB. For explicit metadata, the value encoding MUST be
explicitly provided in the metadata definition. The values cannot explicitly provided in the metadata definition. The values cannot be
be selected arbitrarily and should conform to what is commonly selected arbitrarily and should conform to what is commonly expected.
expected. For example, a TTL increment metadata should be encoded For example, a TTL increment metadata should be encoded as zero for
as zero for the no increment case, one for the single increment the no increment case, one for the single increment case, etc. A
case, etc. A DSCP metadata should use 0 to encode DSCP=0, 1 to DSCP metadata should use 0 to encode DSCP=0, 1 to encode DSCP=1, etc.
encode DSCP=1, etc.
3.2.5. LFB Events 3.2.5. LFB Events
During operation, various conditions may occur that can be detected During operation, various conditions may occur that can be detected
by LFBs. Examples range from link failure or restart to timer by LFBs. Examples range from link failure or restart to timer
expiration in special purpose LFBs. The CE may wish to be notified expiration in special purpose LFBs. The CE may wish to be notified
of the occurrence of such events. The PL protocol provides for such of the occurrence of such events. The PL protocol provides for such
notifications. The LFB definition includes the necessary notifications. The LFB definition includes the necessary
declarations of events. The declarations include identifiers declarations of events. The declarations include identifiers
necessary for subscribing to events (so that the CE can indicate to necessary for subscribing to events (so that the CE can indicate to
skipping to change at page 27, line 6 skipping to change at page 29, line 38
processing is split into triggering (the detection of the condition) processing is split into triggering (the detection of the condition)
and reporting (the generation of the notification of the event.) In and reporting (the generation of the notification of the event.) In
between these two conceptual points there is event filtering. between these two conceptual points there is event filtering.
Properties associated with the event in the LFB instance can define Properties associated with the event in the LFB instance can define
filtering conditions to suppress the reporting of that event. The filtering conditions to suppress the reporting of that event. The
model thus describes event processing as if events always occur, and model thus describes event processing as if events always occur, and
filtering may suppress reporting. Implementations may function in filtering may suppress reporting. Implementations may function in
this manner, or may have more complex logic that eliminates some this manner, or may have more complex logic that eliminates some
event processing if the reporting would be suppressed. Any event processing if the reporting would be suppressed. Any
implementation producing an effect equivalent to the model implementation producing an effect equivalent to the model
description is valid. description is valid
3.2.6. LFB Element Properties The reports with events are designed to allow for the common, closely
related information that the CE can be strongly expected to need to
react to the event. It is not intended to carry information the CE
already has, nor large volumes of information, nor information
related in complex fashions.
LFBs are made up of elements, containing the information that the CE 3.2.6. LFB Component Properties
needs to see and / or change about the functioning of the LFB.
These elements, as described in detail elsewhere, may be basic
values, complex structures, or tables (containing values,
structures, or tables.) Some of these elements are optional. Some
elements may be readable or writeable at the discretion of the FE
implementation. The CE needs to know these properties.
Additionally, certain kinds of elements (arrays, aliases, and events
as of this writing) have additional property information that the CE
may need to read or write. This model defines the structure of the
property information for all defined data types.
The reports with events are designed to allow for the common, LFBs are made up of components, containing the information that the
closely related information that the CE can be strongly expected to CE needs to see and / or change about the functioning of the LFB.
need to react to the event. It is not intended to carry information These components, as described in detail elsewhere, may be basic
the CE already has, nor large volumes of information, nor values, complex structures (containing multiple components
information related in complex fashions. themselves, each of which can be values, structures, or tables), or
tables (which contain values, structures or tables.) Some of these
components are optional. Some components may be readable or
writeable at the discretion of the FE implementation. The CE needs
to know these properties. Additionally, certain kinds of components
(arrays / tables, aliases, and events as of this writing) have
additional property information that the CE may need to read or
write. This model defines the structure of the property information
for all defined data types.
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.6) has special rules. If Inheritance (discussed next in Section 3.2.6) has special rules. If
an FE datapath model containing an LFB instance of a particular an FE datapath model containing an LFB instance of a particular class
class C also simultaneously contains an LFB instance of a class C' C also simultaneously contains an LFB instance of a class C'
inherited from class C; C could have a different version than C'. inherited from class C; C could have a different version than C'.
LFB class versioning is supported by requiring a version string in LFB class versioning is supported by requiring a version string in
the class definition. CEs may support multiple versions of a the class definition. CEs may support multiple versions of a
particular LFB class to provide backward compatibility, but FEs MUST particular LFB class to provide backward compatibility, but FEs MUST
NOT support more than one version of a particular class. NOT support more than one version of a particular class.
Versioning is not restricted to making backwards compatible changes. Versioning is not restricted to making backwards compatible changes.
It is specifically expected to be used to make changes that cannot It is specifically expected to be used to make changes that cannot be
be represented by inheritance. Often this will be to correct represented by inheritance. Often this will be to correct errors,
errors, and hence may not be backwards compatible. It may also be and hence may not be backwards compatible. It may also be used to
used to remove elements which are not considered useful remove components which are not considered useful (particularly if
(particularly if they were previously mandatory, and hence were an they were previously mandatory, and hence were an implementation
implementation impediment.) impediment.)
3.2.8. LFB Inheritance 3.2.8. LFB Inheritance
LFB class inheritance is supported in the FE model as a method to LFB class inheritance is supported in the FE model as a method to
define new LFB classes. This also allows FE vendors to add vendor- define new LFB classes. This also allows FE vendors to add vendor-
specific extensions to standardized LFBs. An LFB class specific extensions to standardized LFBs. An LFB class specification
specification MUST specify the base class and version number it MUST specify the base class and version number it inherits from (the
inherits from (the default is the base LFB class). Multiple- default is the base LFB class). Multiple- inheritance is not
inheritance is not allowed, however, to avoid unnecessary allowed, however, to avoid unnecessary complexity.
complexity.
Inheritance should be used only when there is significant reuse of Inheritance should be used only when there is significant reuse of
the base LFB class definition. A separate LFB class should be the base LFB class definition. A separate LFB class should be
defined if little or no reuse is possible between the derived and defined if little or no reuse is possible between the derived and the
the base LFB class. base LFB class.
An interesting issue related to class inheritance is backward An interesting issue related to class inheritance is backward
compatibility between a descendant and an ancestor class. Consider compatibility between a descendant and an ancestor class. Consider
the following hypothetical scenario where a standardized LFB class the following hypothetical scenario where a standardized LFB class
"L1" exists. Vendor A builds an FE that implements LFB "L1" and "L1" exists. Vendor A builds an FE that implements LFB "L1" and
vendor B builds a CE that can recognize and operate on LFB "L1". vendor B builds a CE that can recognize and operate on LFB "L1".
Suppose that a new LFB class, "L2", is defined based on the existing Suppose that a new LFB class, "L2", is defined based on the existing
"L1" class by extending its capabilities incrementally. Let us "L1" class by extending its capabilities incrementally. Let us
examine the FE backward compatibility issue by considering what examine the FE backward compatibility issue by considering what would
would happen if vendor B upgrades its FE from "L1" to "L2" and happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's
vendor C's CE is not changed. The old L1-based CE can interoperate CE is not changed. The old L1-based CE can interoperate with the new
with the new L2-based FE if the derived LFB class "L2" is indeed L2-based FE if the derived LFB class "L2" is indeed backward
backward compatible with the base class "L1". compatible with the base class "L1".
The reverse scenario is a much less problematic case, i.e., when CE The reverse scenario is a much less problematic case, i.e., when CE
vendor B upgrades to the new LFB class "L2", but the FE is not vendor B upgrades to the new LFB class "L2", but the FE is not
upgraded. Note that as long as the CE is capable of working with upgraded. Note that as long as the CE is capable of working with
older LFB classes, this problem does not affect the model; hence we older LFB classes, this problem does not affect the model; hence we
will use the term "backward compatibility" to refer to the first will use the term "backward compatibility" to refer to the first
scenario concerning FE backward compatibility. scenario concerning FE backward compatibility.
Backward compatibility can be designed into the inheritance model by Backward compatibility can be designed into the inheritance model by
constraining LFB inheritance to require the derived class be a constraining LFB inheritance to require the derived class be a
functional superset of the base class (i.e. the derived class can functional superset of the base class (i.e. the derived class can
only add functions to the base class, but not remove functions). only add functions to the base class, but not remove functions).
Additionally, the following mechanisms are required to support FE Additionally, the following mechanisms are required to support FE
backward compatibility: backward compatibility:
1. When detecting an LFB instance of an LFB type that is unknown 1. When detecting an LFB instance of an LFB type that is unknown to
to the CE, the CE MUST be able to query the base class of such the CE, the CE MUST be able to query the base class of such an
an LFB from the FE. LFB from the FE.
2. The LFB instance on the FE SHOULD support a backward 2. The LFB instance on the FE SHOULD support a backward
compatibility mode (meaning the LFB instance reverts itself compatibility mode (meaning the LFB instance reverts itself back
back to the base class instance), and the CE SHOULD be able to to the base class instance), and the CE SHOULD be able to
configure the LFB to run in such a mode. configure the LFB to run in such a mode.
3.3. FE Datapath Modeling 3.3. FE Datapath Modeling
Packets coming into the FE from ingress ports generally flow through Packets coming into the FE from ingress ports generally flow through
multiple LFBs before leaving out of the egress ports. How an FE multiple LFBs before leaving out of the egress ports. How an FE
treats a packet depends on many factors, such as type of the packet treats a packet depends on many factors, such as type of the packet
(e.g., IPv4, IPv6 or MPLS), actual header values, time of arrival, (e.g., IPv4, IPv6 or MPLS), actual header values, time of arrival,
etc. The result of LFB processing may have an impact on how the etc. The result of LFB processing may have an impact on how the
packet is to be treated in downstream LFBs. This differentiation of packet is to be treated in downstream LFBs. This differentiation of
packet treatment downstream can be conceptualized as having packet treatment downstream can be conceptualized as having
alternative datapaths in the FE. For example, the result of a 6- alternative datapaths in the FE. For example, the result of a 6-
tuple classification performed by a classifier LFB could control tuple classification performed by a classifier LFB could control
which rate meter is applied to the packet by a rate meter LFB in a which rate meter is applied to the packet by a rate meter LFB in a
later stage in the datapath. later stage in the datapath.
LFB topology is a directed graph representation of the logical LFB topology is a directed graph representation of the logical
datapaths within an FE, with the nodes representing the LFB datapaths within an FE, with the nodes representing the LFB instances
instances and the directed link depicting the packet flow direction and the directed link depicting the packet flow direction from one
from one LFB to the next. Section 3.3.1 discusses how the FE LFB to the next. Section 3.3.1 discusses how the FE datapaths can be
datapaths can be modeled as LFB topology; while Section 3.3.2 modeled as LFB topology; while Section 3.3.2 focuses on issues
focuses on issues related to LFB topology reconfiguration. related to LFB topology reconfiguration.
3.3.1. Alternative Approaches for Modeling FE Datapaths 3.3.1. Alternative Approaches for Modeling FE Datapaths
There are two basic ways to express the differentiation in packet There are two basic ways to express the differentiation in packet
treatment within an FE, one represents the datapath directly and treatment within an FE, one represents the datapath directly and
graphically (topological approach) and the other utilizes metadata graphically (topological approach) and the other utilizes metadata
(the encoded state approach). (the encoded state approach).
. Topological Approach o Topological Approach
Using this approach, differential packet treatment is expressed by Using this approach, differential packet treatment is expressed by
splitting the LFB topology into alternative paths. In other splitting the LFB topology into alternative paths. In other words,
words, if the result of an LFB operation controls how the packet if the result of an LFB operation controls how the packet is further
is further processed, then such an LFB will have separate output processed, then such an LFB will have separate output ports, one for
ports, one for each alternative treatment, connected to separate each alternative treatment, connected to separate sub-graphs, each
sub-graphs, each expressing the respective treatment downstream. expressing the respective treatment downstream.
. Encoded State Approach o Encoded State Approach
An alternate way of expressing differential treatment is by using An alternate way of expressing differential treatment is by using
metadata. The result of the operation of an LFB can be encoded in metadata. The result of the operation of an LFB can be encoded in a
a metadata, which is passed along with the packet to downstream metadata, which is passed along with the packet to downstream LFBs.
LFBs. A downstream LFB, in turn, can use the metadata and its A downstream LFB, in turn, can use the metadata and its value (e.g.,
value (e.g., as an index into some table) to determine how to as an index into some table) to determine how to treat the packet.
treat the packet.
Theoretically, either approach could substitute for the other, so Theoretically, either approach could substitute for the other, so one
one could consider using a single pure approach to describe all could consider using a single pure approach to describe all datapaths
datapaths in an FE. However, neither model by itself results in the in an FE. However, neither model by itself results in the best
best representation for all practically relevant cases. For a given representation for all practically relevant cases. For a given FE
FE with certain logical datapaths, applying the two different with certain logical datapaths, applying the two different modeling
modeling approaches will result in very different looking LFB approaches will result in very different looking LFB topology graphs.
topology graphs. A model using only the topological approach may A model using only the topological approach may require a very large
require a very large graph with many links or paths, and nodes graph with many links or paths, and nodes (i.e., LFB instances) to
(i.e., LFB instances) to express all alternative datapaths. On the express all alternative datapaths. On the other hand, a model using
other hand, a model using only the encoded state model would be only the encoded state model would be restricted to a string of LFBs,
restricted to a string of LFBs, which is not an intuitive way to which is not an intuitive way to describe different datapaths (such
describe different datapaths (such as MPLS and IPv4). Therefore, a as MPLS and IPv4). Therefore, a mix of these two approaches will
mix of these two approaches will likely be used for a practical likely be used for a practical model. In fact, as we illustrate
model. In fact, as we illustrate below, the two approaches can be below, the two approaches can be mixed even within the same LFB.
mixed even within the same LFB.
Using a simple example of a classifier with N classification outputs Using a simple example of a classifier with N classification outputs
followed by other LFBs, Figure 5(a) shows what the LFB topology followed by other LFBs, Figure 5(a) shows what the LFB topology looks
looks like when using the pure topological approach. Each output like when using the pure topological approach. Each output from the
from the classifier goes to one of the N LFBs where no metadata is classifier goes to one of the N LFBs where no metadata is needed.
needed. The topological approach is simple, straightforward and The topological approach is simple, straightforward and graphically
graphically intuitive. However, if N is large and the N nodes intuitive. However, if N is large and the N nodes following the
following the classifier (LFB#1, LFB#2, ..., LFB#N) all belong to classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type
the same LFB type (e.g., meter), but each has its own independent (e.g., meter), but each has its own independent components, the
attributes, the encoded state approach gives a much simpler topology encoded state approach gives a much simpler topology representation,
representation, as shown in Figure 5(b). The encoded state approach as shown in Figure 5(b). The encoded state approach requires that a
requires that a table of N rows of meter attributes is provided in table of N rows of meter components is provided in the Meter node
the Meter node itself, with each row representing the attributes for itself, with each row representing the attributes for one meter
one meter instance. A metadata M is also needed to pass along with instance. A metadata M is also needed to pass along with the packet
the packet P from the classifier to the meter, so that the meter can P from the classifier to the meter, so that the meter can use M as a
use M as a look-up key (index) to find the corresponding row of the look-up key (index) to find the corresponding row of the attributes
attributes that should be used for any particular packet P. that should be used for any particular packet P.
What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same
type? For example, if LFB#1 is a queue while the rest are all type? For example, if LFB#1 is a queue while the rest are all
meters, what is the best way to represent such datapaths? While it meters, what is the best way to represent such datapaths? While it
is still possible to use either the pure topological approach or the is still possible to use either the pure topological approach or the
pure encoded state approach, the natural combination of the two pure encoded state approach, the natural combination of the two
appears to be the best option. Figure 5(c) depicts two different appears to be the best option. Figure 5(c) depicts two different
functional datapaths using the topological approach while leaving functional datapaths using the topological approach while leaving the
the N-1 meter instances distinguished by metadata only, as shown in N-1 meter instances distinguished by metadata only, as shown in
Figure 5(c). Figure 5(c).
+----------+ +----------+
P | LFB#1 | P | LFB#1 |
+--------->|(Attrib-1)| +--------->|(Compon-1)|
+-------------+ | +----------+ +-------------+ | +----------+
| 1|------+ P +----------+ | 1|------+ P +----------+
| 2|---------------->| LFB#2 | | 2|---------------->| LFB#2 |
| classifier 3| |(Attrib-2)| | classifier 3| |(Compon-2)|
| ...|... +----------+ | ...|... +----------+
| N|------+ ... | N|------+ ...
+-------------+ | P +----------+ +-------------+ | P +----------+
+--------->| LFB#N | +--------->| LFB#N |
|(Attrib-N)| |(Compon-N)|
+----------+ +----------+
5(a) Using pure topological approach 5(a) Using pure topological approach
+-------------+ +-------------+ +-------------+ +-------------+
| 1| | Meter | | 1| | Meter |
| 2| (P, M) | (Attrib-1) | | 2| (P, M) | (Compon-1) |
| 3|---------------->| (Attrib-2) | | 3|---------------->| (Compon-2) |
| ...| | ... | | ...| | ... |
| N| | (Attrib-N) | | N| | (Compon-N) |
+-------------+ +-------------+ +-------------+ +-------------+
5(b) Using pure encoded state approach to represent the LFB 5(b) Using pure encoded state approach to represent the LFB
topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the
same type (e.g., meter). same type (e.g., meter).
+-------------+ +-------------+
+-------------+ (P, M) | queue | +-------------+ (P, M) | queue |
| 1|------------->| (Attrib-1) | | 1|------------->| (Compon-1) |
| 2| +-------------+ | 2| +-------------+
| 3| (P, M) +-------------+ | 3| (P, M) +-------------+
| ...|------------->| Meter | | ...|------------->| Meter |
| N| | (Attrib-2) | | N| | (Compon-2) |
+-------------+ | ... | +-------------+ | ... |
| (Attrib-N) | | (Compon-N) |
+-------------+ +-------------+
5(c) Using a combination of the two, if LFB#1, LFB#2, ..., and 5(c) Using a combination of the two, if LFB#1, LFB#2, ..., and
LFB#N are of different types (e.g., queue and meter). LFB#N are of different types (e.g., queue and meter).
Figure 5. An example of how to model FE datapaths Figure 5: An example of how to model FE datapaths
From this example, we demonstrate that each approach has a distinct From this example, we demonstrate that each approach has a distinct
advantage depending on the situation. Using the encoded state advantage depending on the situation. Using the encoded state
approach, fewer connections are typically needed between a fan-out approach, fewer connections are typically needed between a fan-out
node and its next LFB instances of the same type because each packet node and its next LFB instances of the same type because each packet
carries metadata the following nodes can interpret and hence invoke carries metadata the following nodes can interpret and hence invoke
a different packet treatment. For those cases, a pure topological a different packet treatment. For those cases, a pure topological
approach forces one to build elaborate graphs with many more approach forces one to build elaborate graphs with many more
connections and often results in an unwieldy graph. On the other connections and often results in an unwieldy graph. On the other
hand, a topological approach is the most intuitive for representing hand, a topological approach is the most intuitive for representing
functionally different datapaths. functionally different datapaths.
For complex topologies, a combination of the two is the most For complex topologies, a combination of the two is the most
flexible. A general design guideline is provided to indicate which flexible. A general design guideline is provided to indicate which
approach is best used for a particular situation. The topological approach is best used for a particular situation. The topological
approach should primarily be used when the packet datapath forks to approach should primarily be used when the packet datapath forks to
skipping to change at page 32, line 14 skipping to change at page 35, line 16
a different packet treatment. For those cases, a pure topological a different packet treatment. For those cases, a pure topological
approach forces one to build elaborate graphs with many more approach forces one to build elaborate graphs with many more
connections and often results in an unwieldy graph. On the other connections and often results in an unwieldy graph. On the other
hand, a topological approach is the most intuitive for representing hand, a topological approach is the most intuitive for representing
functionally different datapaths. functionally different datapaths.
For complex topologies, a combination of the two is the most For complex topologies, a combination of the two is the most
flexible. A general design guideline is provided to indicate which flexible. A general design guideline is provided to indicate which
approach is best used for a particular situation. The topological approach is best used for a particular situation. The topological
approach should primarily be used when the packet datapath forks to approach should primarily be used when the packet datapath forks to
distinct LFB classes (not just distinct parameterizations of the distinct LFB classes (not just distinct parameterizations of the same
same LFB class), and when the fan-outs do not require changes, such LFB class), and when the fan-outs do not require changes, such as
as adding/removing LFB outputs, or require only very infrequent adding/removing LFB outputs, or require only very infrequent changes.
changes. Configuration information that needs to change frequently Configuration information that needs to change frequently should be
should be expressed by using the internal attributes of one or more expressed by using the internal attributes of one or more LFBs (and
LFBs (and hence using the encoded state approach). hence using the encoded state approach).
+---------------------------------------------+ +---------------------------------------------+
| | | |
+----------+ V +----------+ +------+ | +----------+ V +----------+ +------+ |
| | | | |if IP-in-IP| | | | | | | |if IP-in-IP| | |
---->| ingress |->+----->|classifier|---------->|Decap.|---->---+ ---->| ingress |->+----->|classifier|---------->|Decap.|---->---+
| ports | | |----+ | | | ports | | |---+ | |
+----------+ +----------+ |others+------+ +----------+ +----------+ |others+------+
| |
V V
(a) The LFB topology with a logical loop (a) The LFB topology with a logical loop
+-------+ +-----------+ +------+ +-----------+ +-------+ +-----------+ +------+ +-----------+
| | | |if IP-in-IP | | | | | | | |if IP-in-IP | | | |
--->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|->
| ports | | |----+ | | | | | ports | | |----+ | | | |
+-------+ +-----------+ |others +------+ +-----------+ +-------+ +-----------+ |others +------+ +-----------+
skipping to change at page 32, line 39 skipping to change at page 35, line 41
V V
(a) The LFB topology with a logical loop (a) The LFB topology with a logical loop
+-------+ +-----------+ +------+ +-----------+ +-------+ +-----------+ +------+ +-----------+
| | | |if IP-in-IP | | | | | | | |if IP-in-IP | | | |
--->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|->
| ports | | |----+ | | | | | ports | | |----+ | | | |
+-------+ +-----------+ |others +------+ +-----------+ +-------+ +-----------+ |others +------+ +-----------+
| |
V V
The LFB topology without the loop utilizing two independent The LFB topology without the loop utilizing two independent
classifier instances. classifier instances.
Figure 6. An LFB topology example. Figure 6: An LFB topology example.
It is important to point out that the LFB topology described here is It is important to point out that the LFB topology described here is
the logical topology, not the physical topology of how the FE the logical topology, not the physical topology of how the FE
hardware is actually laid out. Nevertheless, the actual hardware is actually laid out. Nevertheless, the actual
implementation may still influence how the functionality is mapped implementation may still influence how the functionality is mapped to
to the LFB topology. Figure 6 shows one simple FE example. In this the LFB topology. Figure 6 shows one simple FE example. In this
example, an IP-in-IP packet from an IPSec application like VPN may example, an IP-in-IP packet from an IPSec application like VPN may go
go to the classifier first and have the classification done based on to the classifier first and have the classification done based on the
the outer IP header; upon being classified as an IP-in-IP packet, outer IP header; upon being classified as an IP-in-IP packet, the
the packet is then sent to a decapsulator to strip off the outer IP packet is then sent to a decapsulator to strip off the outer IP
header, followed by a classifier again to perform classification on header, followed by a classifier again to perform classification on
the inner IP header. If the same classifier hardware or software is the inner IP header. If the same classifier hardware or software is
used for both outer and inner IP header classification with the same used for both outer and inner IP header classification with the same
set of filtering rules, a logical loop is naturally present in the set of filtering rules, a logical loop is naturally present in the
LFB topology, as shown in Figure 6(a). However, if the LFB topology, as shown in Figure 6(a). However, if the
classification is implemented by two different pieces of hardware or classification is implemented by two different pieces of hardware or
software with different filters (i.e., one set of filters for the software with different filters (i.e., one set of filters for the
outer IP header and another set for the inner IP header), then it is outer IP header and another set for the inner IP header), then it is
more natural to model them as two different instances of classifier more natural to model them as two different instances of classifier
LFB, as shown in Figure 6(b). LFB, as shown in Figure 6(b).
To distinguish between multiple instances of the same LFB class, To distinguish between multiple instances of the same LFB class, each
each LFB instance has its own LFB instance ID. One way to encode LFB instance has its own LFB instance ID. One way to encode the LFB
the LFB instance ID is to encode it as x.y where x is the LFB class instance ID is to encode it as x.y where x is the LFB class ID and y
ID and y is the instance ID within each LFB class. is the instance ID within each LFB class.
3.3.2. Configuring the LFB Topology 3.3.2. Configuring the LFB Topology
While there is little doubt that an individual LFB must be While there is little doubt that an individual LFB must be
configurable, the configurability question is more complicated for configurable, the configurability question is more complicated for
LFB topology. Since the LFB topology is really the graphic LFB topology. Since the LFB topology is really the graphic
representation of the datapaths within an FE, configuring the LFB representation of the datapaths within an FE, configuring the LFB
topology means dynamically changing the datapaths, including topology means dynamically changing the datapaths, including changing
changing the LFBs along the datapaths on an FE (e.g., creating, the LFBs along the datapaths on an FE (e.g., creating, instantiating
instantiating or deleting LFBs) and setting up or deleting or deleting LFBs) and setting up or deleting interconnections between
interconnections between outputs of upstream LFBs to inputs of outputs of upstream LFBs to inputs of downstream LFBs.
downstream LFBs.
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 datapaths on an FE are set up by the CE to provide certain data plane
plane services (e.g., DiffServ, VPN, etc.) to the Network Element's services (e.g., DiffServ, VPN, etc.) to the Network Element's (NE)
(NE) customers. The purpose of reconfiguring the datapaths is to customers. The purpose of reconfiguring the datapaths is to enable
enable the CE to customize the services the NE is delivering at run the CE to customize the services the NE is delivering at run time.
time. The CE needs to change the datapaths when the service The CE needs to change the datapaths when the service requirements
requirements change, such as adding a new customer or when an change, such as adding a new customer or when an existing customer
existing customer changes their service. However, note that not all changes their service. However, note that not all datapath changes
datapath changes result in changes in the LFB topology graph. result in changes in the LFB topology graph. Changes in the graph
Changes in the graph are dependent on the approach used to map the are dependent on the approach used to map the datapaths into LFB
datapaths into LFB topology. As discussed in 3.3.1, the topological topology. As discussed in 3.3.1, the topological approach and
approach and encoded state approach can result in very different encoded state approach can result in very different looking LFB
looking LFB topologies for the same datapaths. In general, an LFB topologies for the same datapaths. In general, an LFB topology based
topology based on a pure topological approach is likely to on a pure topological approach is likely to experience more frequent
experience more frequent topology reconfiguration than one based on topology reconfiguration than one based on an encoded state approach.
an encoded state approach. However, even an LFB topology based However, even an LFB topology based entirely on an encoded state
entirely on an encoded state approach may have to change the approach may have to change the topology at times, for example, to
topology at times, for example, to bypass some LFBs or insert new bypass some LFBs or insert new LFBs. Since a mix of these two
LFBs. Since a mix of these two approaches is used to model the approaches is used to model the datapaths, LFB topology
datapaths, LFB topology reconfiguration is considered an important reconfiguration is considered an important aspect of the FE model.
aspect of the FE model.
We want to point out that allowing a configurable LFB topology in We want to point out that allowing a configurable LFB topology in the
the FE model does not mandate that all FEs are required to have this FE model does not mandate that all FEs are required to have this
capability. Even if an FE supports configurable LFB topology, the capability. Even if an FE supports configurable LFB topology, the FE
FE may impose limitations on what can actually be configured. may impose limitations on what can actually be configured.
Performance-optimized hardware implementations may have zero or very Performance-optimized hardware implementations may have zero or very
limited configurability, while FE implementations running on network limited configurability, while FE implementations running on network
processors may provide more flexibility and configurability. It is processors may provide more flexibility and configurability. It is
entirely up to the FE designers to decide whether or not the FE entirely up to the FE designers to decide whether or not the FE
actually implements reconfiguration and if so, how much. Whether a actually implements reconfiguration and if so, how much. Whether a
simple runtime switch is used to enable or disable (i.e., bypass) simple runtime switch is used to enable or disable (i.e., bypass)
certain LFBs, or more flexible software reconfiguration is used, is certain LFBs, or more flexible software reconfiguration is used, is
implementation detail internal to the FE and outside of the scope of implementation detail internal to the FE and outside of the scope of
FE model. In either case, the CE(s) MUST be able to learn the FE's FE model. In either case, the CE(s) MUST be able to learn the FE's
configuration capabilities. Therefore, the FE model MUST provide a configuration capabilities. Therefore, the FE model MUST provide a
mechanism for describing the LFB topology configuration capabilities mechanism for describing the LFB topology configuration capabilities
of an FE. These capabilities may include (see Section 5 for full of an FE. These capabilities may include (see Section 5 for full
details): details):
. Which LFB classes the FE can instantiate o Which LFB classes the FE can instantiate
. Maximum number of instances of the same LFB class that can be
o Maximum number of instances of the same LFB class that can be
created created
. Any topological limitations, For example:
o The maximum number of instances of the same class or any o Any topological limitations, For example:
class that can be created on any given branch of the graph
o Ordering restrictions on LFBs (e.g., any instance of LFB * The maximum number of instances of the same class or any class
class A must be always downstream of any instance of LFB that can be created on any given branch of the graph
class B).
* Ordering restrictions on LFBs (e.g., any instance of LFB class
A must be always downstream of any instance of LFB class B).
Note that even when the CE is allowed to configure LFB topology for Note that even when the CE is allowed to configure LFB topology for
the FE, the CE is not expected to be able to interpret an arbitrary the FE, the CE is not expected to be able to interpret an arbitrary
LFB topology and determine which specific service or application LFB topology and determine which specific service or application
(e.g. VPN, DiffServ, etc.) is supported by the FE. However, once (e.g. VPN, DiffServ, etc.) is supported by the FE. However, once
the CE understands the coarse capability of an FE, the CE MUST the CE understands the coarse capability of an FE, the CE MUST
configure the LFB topology to implement the network service the NE configure the LFB topology to implement the network service the NE is
is supposed to provide. Thus, the mapping the CE has to understand supposed to provide. Thus, the mapping the CE has to understand is
is from the high level NE service to a specific LFB topology, not from the high level NE service to a specific LFB topology, not the
the other way around. The CE is not expected to have the ultimate other way around. The CE is not expected to have the ultimate
intelligence to translate any high level service policy into the intelligence to translate any high level service policy into the
configuration data for the FEs. However, it is conceivable that configuration data for the FEs. However, it is conceivable that
within a given network service domain, a certain amount of within a given network service domain, a certain amount of
intelligence can be programmed into the CE to give the CE a general intelligence can be programmed into the CE to give the CE a general
understanding of the LFBs involved to allow the translation from a understanding of the LFBs involved to allow the translation from a
high level service policy to the low level FE configuration to be high level service policy to the low level FE configuration to be
done automatically. Note that this is considered an implementation done automatically. Note that this is considered an implementation
issue internal to the control plane and outside the scope of the FE issue internal to the control plane and outside the scope of the FE
model. Therefore, it is not discussed any further in this draft. model. Therefore, it is not discussed any further in this draft.
skipping to change at page 36, line 34 skipping to change at page 39, line 34
| Meter2 +->| |-+ | | Meter2 +->| |-+ |
| | | | | | | |
| +--+ Queue4 | | +--+ Queue4 |
| Marker1 +--+ | | Marker1 +--+ |
+---------------------------->| |----+ +---------------------------->| |----+
| | | |
+--+ +--+
(c) Another LFB topology as configured by the CE and (c) Another LFB topology as configured by the CE and
accepted by the FE accepted by the FE
Figure 7. An example of configuring LFB topology. Figure 7: An example of configuring LFB topology
Figure 7 shows an example where a QoS-enabled router has several Figure 7 shows an example where a QoS-enabled router has several line
line cards that have a few ingress ports and egress ports, a cards that have a few ingress ports and egress ports, a specialized
specialized classification chip, a network processor containing classification chip, a network processor containing codes for FE
codes for FE blocks like meter, marker, dropper, counter, queue, blocks like meter, marker, dropper, counter, queue, scheduler and
scheduler and Ipv4 forwarder. Some of the LFB topology is already Ipv4 forwarder. Some of the LFB topology is already fixed and has to
fixed and has to remain static due to the physical layout of the remain static due to the physical layout of the line cards. For
line cards. For example, all of the ingress ports might be hard- example, all of the ingress ports might be hard- wired into the
wired into the classification chip so all packets flow from the classification chip so all packets flow from the ingress port into
ingress port into the classification engine. On the other hand, the the classification engine. On the other hand, the LFBs on the
LFBs on the network processor and their execution order are network processor and their execution order are programmable.
programmable. However, certain capacity limits and linkage However, certain capacity limits and linkage constraints could exist
constraints could exist between these LFBs. Examples of the capacity between these LFBs. Examples of the capacity limits might be: 8
limits might be: 8 meters; 16 queues in one FE; the scheduler can meters; 16 queues in one FE; the scheduler can handle at most up to
handle at most up to 16 queues; etc. The linkage constraints might 16 queues; etc. The linkage constraints might dictate that the
dictate that the classification engine may be followed by a meter, classification engine may be followed by a meter, marker, dropper,
marker, dropper, counter, queue or IPv4 forwarder, but not a counter, queue or IPv4 forwarder, but not a scheduler; queues can
scheduler; queues can only be followed by a scheduler; a scheduler only be followed by a scheduler; a scheduler must be followed by the
must be followed by the IPv4 forwarder; the last LFB in the datapath IPv4 forwarder; the last LFB in the datapath before going into the
before going into the egress ports must be the IPv4 forwarder, etc. egress ports must be the IPv4 forwarder, etc.
Once the FE reports these capabilities and capacity limits to the Once the FE reports these capabilities and capacity limits to the CE,
CE, it is now up to the CE to translate the QoS policy into a it is now up to the CE to translate the QoS policy into a desirable
desirable configuration for the FE. Figure 7(a) depicts the FE configuration for the FE. Figure 7(a) depicts the FE capability
capability while 7(b) and 7(c) depict two different topologies that while 7(b) and 7(c) depict two different topologies that the CE may
the CE may request the FE to configure. Note that both the ingress request the FE to configure. Note that both the ingress and egress
and egress are omitted in (b) and (c) to simplify the are omitted in (b) and (c) to simplify the representation. The
representation. The topology in 7(c) is considerably more complex topology in 7(c) is considerably more complex than 7(b) but both are
than 7(b) but both are feasible within the FE capabilities, and so feasible within the FE capabilities, and so the FE should accept
the FE should accept either configuration request from the CE. either configuration request from the CE.
4. Model and Schema for LFB Classes 4. Model and Schema for LFB Classes
The main goal of the FE model is to provide an abstract, generic, The main goal of the FE model is to provide an abstract, generic,
modular, implementation-independent representation of the FEs. This modular, implementation-independent representation of the FEs. This
is facilitated using the concept of LFBs, which are instantiated is facilitated using the concept of LFBs, which are instantiated from
from LFB classes. LFB classes and associated definitions will be LFB classes. LFB classes and associated definitions will be provided
provided in a collection of XML documents. The collection of these in a collection of XML documents. The collection of these XML
XML documents is called a LFB class library, and each document is documents is called a LFB class library, and each document is called
called an LFB class library document (or library document, for an LFB class library document (or library document, for short). Each
short). Each of the library documents will conform to the schema of the library documents will conform to the schema presented in this
presented in this section. The root element of the library document section. The root element of the library document is the
is the <LFBLibrary> element. <LFBLibrary> element.
It is not expected that library documents will be exchanged between It is not expected that library documents will be exchanged between
FEs and CEs "over-the-wire". But the model will serve as an FEs and CEs "over-the-wire". But the model will serve as an
important reference for the design and development of the CEs important reference for the design and development of the CEs
(software) and FEs (mostly the software part). It will also serve (software) and FEs (mostly the software part). It will also serve as
as a design input when specifying the ForCES protocol elements for a design input when specifying the ForCES protocol elements for CE-FE
CE-FE communication. communication.
4.1. Namespace 4.1. Namespace
A namespace is needed to uniquely identify the LFB type in the LFB A namespace is needed to uniquely identify the LFB type in the LFB
class library. The reference to the namespace definition is class library. The reference to the namespace definition is
contained in Section 9, IANA Considerations. contained in Section 9, IANA Considerations.
4.2. <LFBLibrary> Element 4.2. <LFBLibrary> Element
The <LFBLibrary> element serves as a root element of all library The <LFBLibrary&#x3e element serves as a root element of all library
documents. It contains one or more of the following main blocks: documents. It contains one or more of the following main XML
elements:
. <frameTypeDefs> for the frame declarations; o <frameTypeDefs> for the frame declarations;
. <dataTypeDefs> for defining common data types;
. <metadataDefs> for defining metadata, and
. <LFBClassDefs> for defining LFB classes.
Each block is optional, that is, one library document may contain o <dataTypeDefs> for defining common data types;
o <metadataDefs> for defining metadata, and
o <LFBClassDefs> for defining LFB classes.
Each element is optional, that is, one library document may contain
only metadata definitions, another may contain only LFB class only metadata definitions, another may contain only LFB class
definitions, yet another may contain all of the above. definitions, yet another may contain all of the above.
In addition to the above main blocks, a library document can import In addition to the above main elements, a library document can import
other library documents if it needs to refer to definitions other library documents if it needs to refer to definitions contained
contained in the included document. This concept is similar to the in the included document. This concept is similar to the "#include"
"#include" directive in C. Importing is expressed by the <load> directive in C. Importing is expressed by the use of <load> elements,
elements, which must precede all the above elements in the document. which must precede all the above elements in the document. For
For unique referencing, each LFBLibrary instance document has a unique referencing, each LFBLibrary instance document has a unique
unique label defined in the "provide" attribute of the LFBLibrary label defined in the "provide" attribute of the LFBLibrary element.
element.
The <LFBLibrary> element also includes an optional <description> The <LFBLibrary> element also includes an optional <description>
element, which can be used to provide textual description about the element, which can be used to provide textual description about the
library document. library document.
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="http://ietf.org/forces/1.0/lfbmodel"
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"/>
... ...
<!-- FRAME TYPE DEFINITIONS (optional) --> <!-- FRAME TYPE DEFINITIONS (optional) -->
<frameTypeDefs> <frameTypeDefs>
... ...
</frameTypeDefs> </frameTypeDefs>
<!-- DATA TYPE DEFINITIONS (optional) --> <!-- DATA TYPE DEFINITIONS (optional) -->
<dataTypeDefs> <dataTypeDefs>
... ...
</dataTypeDefs> </dataTypeDefs>
<!-- METADATA DEFINITIONS (optional) --> <!-- METADATA DEFINITIONS (optional) -->
<metadataDefs> <metadataDefs>
... ...
</metadataDefs> </metadataDefs>
<!-- - - LFB CLASS DEFINITIONS (optional) -->
<!--
-
-
LFB CLASS DEFINITIONS (optional) -->
<LFBCLassDefs> <LFBCLassDefs>
...
</LFBCLassDefs> </LFBCLassDefs>
</LFBLibrary> </LFBLibrary>
4.3. <load> Element 4.3. <load> Element
This element is used to refer to another LFB library document. This element is used to refer to another LFB library document.
Similar to the "#include" directive in C, this makes the objects Similar to the "#include" directive in C, this makes the objects
(metadata types, data types, etc.) defined in the referred library (metadata types, data types, etc.) defined in the referred library
document available for referencing in the current document. document available for referencing in the current document.
The load element MUST contain the label of the library document to The load element MUST contain the label of the library document to be
be included and may contain a URL to specify where the library can included and may contain a URL to specify where the library can be
be retrieved. The load element can be repeated unlimited times. retrieved. The load element can be repeated unlimited times. Three
Three examples for the <load> elements: examples for the <load> elements:
<load library="a_library"/> <load library="a_library"/>
<load library="another_library" location="another_lib.xml"/> <load library="another_library" location="another_lib.xml"/>
<load library="yetanother_library" <load library="yetanother_library"
location="http://www.petrimeat.com/forces/1.0/lfbmodel/lpm.xml"/> location="http://www.petrimeat.com/forces/1.0/lfbmodel/lpm.xml"/>
4.4. <frameDefs> Element for Frame Type Declarations 4.4. <frameDefs> Element for Frame Type Declarations
Frame names are used in the LFB definition to define the types of Frame names are used in the LFB definition to define the types of
frames the LFB expects at its input port(s) and emits at its output frames the LFB expects at its input port(s) and emits at its output
port(s). The <frameDefs> optional element in the library document port(s). The <frameDefs> optional element in the library document
contains one or more <frameDef> elements, each declaring one frame contains one or more <frameDef> elements, each declaring one frame
type. type.
Each frame definition MUST contain a unique name (NMTOKEN) and a Each frame definition MUST contain a unique name (NMTOKEN) and a
brief synopsis. In addition, an optional detailed description may brief synopsis. In addition, an optional detailed description may be
be provided. provided.
Uniqueness of frame types MUST be ensured among frame types defined Uniqueness of frame types MUST be ensured among frame types defined
in the same library document and in all directly or indirectly in the same library document and in all directly or indirectly
included library documents. included library documents.
The following example defines two frame types: The following example defines two frame types:
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>ipv4</name> <name>ipv4</name>
skipping to change at page 40, line 24 skipping to change at page 44, line 5
... ...
</frameDefs> </frameDefs>
4.5. <dataTypeDefs> Element for Data Type Definitions 4.5. <dataTypeDefs> Element for Data Type Definitions
The (optional) <dataTypeDefs> element can be used to define commonly The (optional) <dataTypeDefs> element can be used to define commonly
used data types. It contains one or more <dataTypeDef> elements, used data types. It contains one or more <dataTypeDef> elements,
each defining a data type with a unique name. Such data types can be each defining a data type with a unique name. Such data types can be
used in several places in the library documents, including: used in several places in the library documents, including:
. Defining other data types o Defining other data types
. Defining attributes of LFB classes
o Defining attributes of LFB classes
This is similar to the concept of having a common header file for This is similar to the concept of having a common header file for
shared data types. shared data types.
Each <dataTypeDef> element MUST contain a unique name (NMTOKEN), a Each <dataTypeDef> element MUST contain a unique name (NMTOKEN), a
brief synopsis, an optional longer description, and a type brief synopsis, an optional longer description, and a type definition
definition element. The name MUST be unique among all data types element. The name MUST be unique among all data types defined in the
defined in the same library document and in any directly or same library document and in any directly or indirectly included
indirectly included library documents. For example: library documents. For example:
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>ieeemacaddr</name> <name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis> <synopsis>48-bit IEEE MAC address</synopsis>
... type definition ... ... type definition ...
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>ipv4addr</name> <name>ipv4addr</name>
<synopsis>IPv4 address</synopsis> <synopsis>IPv4 address</synopsis>
skipping to change at page 41, line 4 skipping to change at page 44, line 31
<synopsis>48-bit IEEE MAC address</synopsis> <synopsis>48-bit IEEE MAC address</synopsis>
... type definition ... ... type definition ...
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>ipv4addr</name> <name>ipv4addr</name>
<synopsis>IPv4 address</synopsis> <synopsis>IPv4 address</synopsis>
... type definition ... ... type definition ...
</dataTypeDef> </dataTypeDef>
... ...
</dataTypeDefs> </dataTypeDefs>
There are two kinds of data types: atomic and compound. Atomic data There are two kinds of data types: atomic and compound. Atomic data
types are appropriate for single-value variables (e.g. integer, types are appropriate for single-value variables (e.g. integer,
string, byte array). string, byte array).
The following built-in atomic data types are provided, but The following built-in atomic data types are provided, but additional
additional atomic data types can be defined with the <typeRef> and atomic data types can be defined with the <typeRef> and <atomic>
<atomic> elements: elements:
<name> Meaning <name> Meaning
---- ------- ---- -------
char 8-bit signed integer char 8-bit signed integer
uchar 8-bit unsigned integer uchar 8-bit unsigned integer
int16 16-bit signed integer int16 16-bit signed integer
uint16 16-bit unsigned integer uint16 16-bit unsigned integer
int32 32-bit signed integer int32 32-bit signed integer
uint32 32-bit unsigned integer uint32 32-bit unsigned integer
int64 64-bit signed integer int64 64-bit signed integer
skipping to change at page 41, line 38 skipping to change at page 45, line 31
byte[N] A byte array of N bytes byte[N] A byte array of N bytes
octetstring[N] A buffer of N octets, which may octetstring[N] A buffer of N octets, which may
contain fewer than N octets. Hence contain fewer than N octets. Hence
the encoded value will always have the encoded value will always have
a length. a length.
float16 16-bit floating point number float16 16-bit floating point number
float32 32-bit IEEE floating point number float32 32-bit IEEE floating point number
float64 64-bit IEEE floating point number float64 64-bit IEEE floating point number
These built-in data types can be readily used to define metadata or These built-in data types can be readily used to define metadata or
LFB attributes, but can also be used as building blocks when LFB attributes, but can also be used as building blocks when defining
defining new data types. The boolean data type is defined here new data types. The boolean data type is defined here because it is
because it is so common, even though it can be built by sub-ranging so common, even though it can be built by sub-ranging the uchar data
the uchar data type. type.
Compound data types can build on atomic data types and other Compound data types can build on atomic data types and other compound
compound data types. Compound data types can be defined in one of data types. Compound data types can be defined in one of four ways.
four ways. They may be defined as an array of elements of some They may be defined as an array of components of some compound or
compound or atomic data type. They may be a structure of named atomic data type. They may be a structure of named components of
elements of compound or atomic data types (ala C structures). They compound or atomic data types (ala C structures). They may be a
may be a union of named elements of compound or atomic data types union of named components of compound or atomic data types (ala C
(ala C unions). They may also be defined as augmentations unions). They may also be defined as augmentations (explained below
(explained below in 4.5.6) of existing compound data types. in 4.5.6) of existing compound data types.
Given that the FORCES protocol will be getting and setting attribute Given that the FORCES protocol will be getting and setting component
values, all atomic data types used here must be able to be conveyed values, all atomic data types used here must be able to be conveyed
in the FORCES protocol. Further, the FORCES protocol will need a in the FORCES protocol. Further, the FORCES protocol will need a
mechanism to convey compound data types. However, the details of mechanism to convey compound data types. However, the details of
such representations are for the protocol document to define, not such representations are for the protocol document to define, not the
the model document. Strings and octetstrings must be conveyed with model document. Strings and octetstrings must be conveyed with their
their length, as they are not delimited, and are variable length. length, as they are not delimited, and are variable length.
With regard to strings, this model defines a small set of With regard to strings, this model defines a small set of
restrictions and definitions on how they are structured. String and restrictions and definitions on how they are structured. String and
octetstring length limits can be specified in the LFB Class octetstring length limits can be specified in the LFB Class
definitions. The element properties for string and octetstring definitions. The component properties for string and octetstring
elements also contain actual lengths and length limits. This components also contain actual lengths and length limits. This
duplication of limits is to allow for implementations with smaller duplication of limits is to allow for implementations with smaller
limits than the maximum limits specified in the LFB Class limits than the maximum limits specified in the LFB Class definition.
definition. In all cases, these lengths are specified in octets, In all cases, these lengths are specified in octets, not in
not in characters. In terms of protocol operation, as long as the characters. In terms of protocol operation, as long as the specified
specified length is within the FE’s supported capabilities, the FE length is within the FE's supported capabilities, the FE stores the
stores the contents of a string exactly as provided by the CE, and contents of a string exactly as provided by the CE, and returns those
returns those contents when requested. No canonicalization, contents when requested. No canonicalization, transformations, or
transformations, or equivalences are performed by the FE. Elements equivalences are performed by the FE. components of type string (or
of type string (or string[n]) may be used to hold identifiers for string[n]) may be used to hold identifiers for correlation with
correlation with elements in other LFBs. In such cases, an exact components in other LFBs. In such cases, an exact octet for octet
octet for octet match is used. No equivalences are used by the FE match is used. No equivalences are used by the FE or CE in
or CE in performing that matching. The ForCES protocol does not performing that matching. The ForCES protocol does not perform or
perform or require validation of the content of UTF-8 strings. require validation of the content of UTF-8 strings. However, UTF-8
However, UTF-8 strings SHOULD be encoded in the shortest form to strings SHOULD be encoded in the shortest form to avoid potential
avoid potential security issues described in [15]. Any entity security issues described in [12]. Any entity displaying such
displaying such strings is expected to perform its own validation strings is expected to perform its own validation (for example for
(for example for correct multi-byte characters, and for ensuring correct multi-byte characters, and for ensuring that the string does
that the string does not end in the middle of a multi-byte not end in the middle of a multi-byte sequence.) Specific LFB class
sequence.) Specific LFB class definitions may restrict the valid definitions may restrict the valid contents of a string as suited to
contents of a string as suited to the particular usage (for example, the particular usage (for example, a component that holds a DNS name
an element that holds a DNS name would be restricted to hold only would be restricted to hold only octets valid in such a name.) FEs
octets valid in such a name.) FEs should validate the contents of should validate the contents of SET requests for such restricted
SET requests for such restricted elements at the time the set is components at the time the set is performed, just as range checks for
performed, just as range checks for range limited elements are range limited components are performed. The ForCES protocol behavior
performed. The ForCES protocol behavior defines the normative defines the normative processing for requests using that protocol.
processing for requests using that protocol.
For the definition of the actual type in the <dataTypeDef> element, For the definition of the actual type in the <dataTypeDef> element,
the following elements are available: <typeRef>, <atomic>, <array>, the following elements are available: <typeRef>, <atomic>, <array>,
<struct>, and <union>. <struct>, and <union>.
The predefined type alias is somewhere between the atomic and The predefined type alias is somewhere between the atomic and
compound data types. It behaves like a structure, one element of compound data types. It behaves like a structure, one component of
which has special behavior. Given that the special behavior is tied which has special behavior. Given that the special behavior is tied
to the other parts of the structure, the compound result is treated to the other parts of the structure, the compound result is treated
as a predefined construct. as a predefined construct.
4.5.1. <typeRef> Element for Aliasing Existing Data Types 4.5.1. <typeRef> Element for Aliasing Existing Data Types
The <typeRef> element refers to an existing data type by its name. The <typeRef> element refers to an existing data type by its name.
The referred data type MUST be defined either in the same library The referred data type MUST be defined either in the same library
document, or in one of the included library documents. If the document, or in one of the included library documents. If the
referred data type is an atomic data type, the newly defined type referred data type is an atomic data type, the newly defined type
skipping to change at page 43, line 32 skipping to change at page 47, line 21
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>ieeemacaddr</name> <name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis> <synopsis>48-bit IEEE MAC address</synopsis>
<typeRef>byte[6]</typeRef> <typeRef>byte[6]</typeRef>
</dataTypeDef> </dataTypeDef>
4.5.2. <atomic> Element for Deriving New Atomic Types 4.5.2. <atomic> Element for Deriving New Atomic Types
The <atomic> element allows the definition of a new atomic type from The <atomic> element allows the definition of a new atomic type from
an existing atomic type, applying range restrictions and/or an existing atomic type, applying range restrictions and/or providing
providing special enumerated values. Note that the <atomic> element special enumerated values. Note that the <atomic> element can only
can only use atomic types as base types, and its result MUST be use atomic types as base types, and its result MUST be another atomic
another atomic type. type.
For example, the following snippet defines a new "dscp" data type: For example, the following snippet defines a new "dscp" data type:
<dataTypeDef> <dataTypeDef>
<name>dscp</name> <name>dscp</name>
<synopsis>Diffserv code point.</synopsis> <synopsis>Diffserv code point.</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="63"/> <allowedRange min="0" max="63"/>
skipping to change at page 44, line 4 skipping to change at page 47, line 42
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="63"/> <allowedRange min="0" max="63"/>
</rangeRestriction> </rangeRestriction>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>DSCP-BE</name> <name>DSCP-BE</name>
<synopsis>Best Effort</synopsis> <synopsis>Best Effort</synopsis>
</specialValue> </specialValue>
... ...
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
4.5.3. <array> Element to Define Arrays 4.5.3. <array> Element to Define Arrays
The <array> element can be used to create a new compound data type The <array> element can be used to create a new compound data type as
as an array of a compound or an atomic data type. The type of the an array of a compound or an atomic data type. Depending upon
array entry can be specified either by referring to an existing type context, this document, and others, refer to such arrays as tables or
(using the <typeRef> element) or defining an unnamed type inside the arrays interchangeably, without semantic or syntactic implication.
<array> element using any of the <atomic>, <array>, <struct>, or
<union> elements. The type of the array entry can be specified either by referring to
an existing type (using the <typeRef> element) or defining an unnamed
type inside the <array> element using any of the <atomic>, <array>,
<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 "max-length"
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 attributes limitations. The latter should be handled by capability attributes
of LFB classes, and should never be included in data type of LFB classes, and should never be included in data type array is
definitions. If the "max-length" attribute is not provided, the regarded as of unlimited-size.
array 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
the array has a fixed size of 1. the array has a fixed size of 1.
Arrays MUST only be subscripted by integers, and will be presumed to Arrays MUST only be subscripted by integers, and will be presumed to
start with index 0. start with index 0.
In addition to their subscripts, arrays may be declared to have In addition to their subscripts, arrays may be declared to have
content keys. Such a declaration has several effects: content keys. Such a declaration has several effects:
. Any declared key can be used in the ForCES protocol to select o Any declared key can be used in the ForCES protocol to select a
an element for operations (for details, see the protocol). component for operations (for details, see the protocol).
. In any instance of the array, each declared key must be unique o In any instance of the array, each declared key must be unique
within that instance. No two elements of an array may have the within that instance. No two components of an array may have the
same values on all the fields which make up a key. same values on all the fields which make up a key.
Each key is declared with a keyID for use in the protocol, where the Each key is declared with a keyID for use in the protocol, where the
unique key is formed by combining one or more specified key fields. unique key is formed by combining one or more specified key fields.
To support the case where an array of an atomic type with unique To support the case where an array of an atomic type with unique
values can be referenced by those values, the key field identifier values can be referenced by those values, the key field identifier
may be "*" (i.e., the array entry is the key). If the value type of may be "*" (i.e., the array entry is the key). If the value type of
the array is a structure or an array, then the key is one or more the array is a structure or an array, then the key is one or more
fields, each identified by name. Since the field may be an element components of the value type, each identified by name. Since the
of the structure, the element of an element of a structure, or field may be a component of the contained structure, a component of a
further nested, the field name is actually a concatenated sequence component of a structure, or further nested, the field name is
of part identifiers, separated by decimal points ("."). The syntax actually a concatenated sequence of component identifiers, separated
for key field identification is given following the array examples. by decimal points ("."). The syntax for key field identification is
given following the array examples.
The following example shows the definition of a fixed size array The following example shows the definition of a fixed size array with
with a pre-defined data type as the array elements: a pre-defined data type as the array content type:
<dataTypeDef> <dataTypeDef>
<name>dscp-mapping-table</name> <name>dscp-mapping-table</name>
<synopsis> <synopsis>
A table of 64 DSCP values, used to re-map code space. A table of 64 DSCP values, used to re-map code space.
</synopsis> </synopsis>
<array type="fixed-size" length="64"> <array type="fixed-size" length="64">
<typeRef>dscp</typeRef> <typeRef>dscp</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
skipping to change at page 45, line 34 skipping to change at page 49, line 27
<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" max-length="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) type definition: (unnamed) content type definition:
<dataTypeDef> <dataTypeDef>
<name>classification-table</name> <name>classification-table</name>
<synopsis> <synopsis>
A table of classification rules and result opcodes. A table of classification rules and result opcodes.
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>rule</name> <name>rule</name>
<synopsis>The rule to match</synopsis> <synopsis>The rule to match</synopsis>
<typeRef>classrule</typeRef> <typeRef>classrule</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>opcode</name> <name>opcode</name>
<synopsis>The result code</synopsis> <synopsis>The result code</synopsis>
<typeRef>opcode</typeRef> <typeRef>opcode</typeRef>
</element> </component>
</struct> </struct>
</array> </array>
</dataTypeDef> </dataTypeDef>
In the above example, each entry of the array is a <struct> of two In the above example, each entry of the array is a <struct> of two
fields ("rule" and "opcode"). components ("rule" and "opcode").
The following example shows a table of IP Prefix information that The following example shows a table of IP Prefix information that can
can be accessed by a multi-field content key on the IP Address and be accessed by a multi-field content key on the IP Address and prefix
prefix length. This means that in any instance of this table, no length. This means that in any instance of this table, no two
two entries can have the same IP address and prefix length. entries can have the same IP address and prefix length.
<dataTypeDef> <dataTypeDef>
<name>ipPrefixInfo_table</name> <name>ipPrefixInfo_table</name>
<synopsis> <synopsis>
A table of information about known prefixes A table of information about known prefixes
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>address-prefix</name> <name>address-prefix</name>
<synopsis>the prefix being described</synopsis> <synopsis>the prefix being described</synopsis>
<typeRef>ipv4Prefix</typeRef> <typeRef>ipv4Prefix</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>source</name> <name>source</name>
<synopsis> <synopsis>
the protocol or process providing this information the protocol or process providing this information
</synopsis> </synopsis>
<typeRef>uint16</typeRef> <typeRef>uint16</typeRef>
</element> </component>
<element elementID="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>
</element> </component>
</struct> </struct>
<key keyID="1"> <key keyID="1">
<keyField> address-prefix.ipv4addr </keyField> <keyField> address-prefix.ipv4addr </keyField>
<keyField> address-prefix.prefixlen </keyField> <keyField> address-prefix.prefixlen </keyField>
<keyField> source </keyField> <keyField> 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
In order to use key declarations, one must refer to fields that are
potentially nested inside other fields in the array. If there are
nested arrays, one might even use an array element as a key (but
great care would be needed to ensure uniqueness.)
In order to use key declarations, one must refer to components that
are potentially nested inside other components in the array. If
there are nested arrays, one might even use an array element as a key
(but great care would be needed to ensure uniqueness.)
The key is the combination of the values of each field declared in a The key is the combination of the values of each field declared in a
keyField element. keyField element.
Therefore, the value of a keyField element MUST be a concatenated Therefore, the value of a keyField element MUST be a concatenated
Sequence of field identifiers, separated by a "." (period) Sequence of field identifiers, separated by a "." (period) character.
character. Whitespace is permitted and ignored. Whitespace is permitted and ignored.
A valid string for a single field identifier within a keyField A valid string for a single field identifier within a keyField
depends upon the current context. Initially, in an array key depends upon the current context. Initially, in an array key
declaration, the context is the type of the array. Progressively, declaration, the context is the type of the array. Progressively,
the context is whatever type is selected by the field identifiers the context is whatever type is selected by the field identifiers
processed so far in the current key field declaration. processed so far in the current key field declaration.
When the current context is an array, (e.g., when declaring a key When the current context is an array, (e.g., when declaring a key for
for an array whose content is an array) then the only valid value an array whose content is an array) then the only valid value for the
for the field identifier is an explicit number. field identifier is an explicit number.
When the current context is a structure, the valid values for the When the current context is a structure, the valid values for the
field identifiers are the names of the elements of the structure. field identifiers are the names of the components of the structure.
In the special case of declaring a key for an array containing an In the special case of declaring a key for an array containing an
atomic type, where that content is unique and is to be used as a atomic type, where that content is unique and is to be used as a key,
key, the value "*" can be used as the single key field identifier. the value "*" can be used as the single key field identifier.
4.5.4. <struct> Element to Define Structures 4.5.4. <struct> Element to Define Structures
A structure is comprised of a collection of data elements. Each A structure is comprised of a collection of data components. Each
data element has a data type (either an atomic type or an existing data components has a data type (either an atomic type or an existing
compound type) and is assigned a name unique within the scope of the compound type) and is assigned a name unique within the scope of the
compound data type being defined. These serve the same function as compound data type being defined. These serve the same function as
"struct" in C, etc. "struct" in C, etc.
The actual type of the field can be defined by referring to an The actual type of the component can be defined by referring to an
existing type (using the <typeDef> element), or can be a locally existing type (using the <typeDef> element), or can be a locally
defined (unnamed) type created by any of the <atomic>, <array>, defined (unnamed) type created by any of the <atomic>, <array>,
<struct>, or <union> elements. <struct>, or <union> elements.
A structure definition is a series of element declarations. Each A structure definition is a series of component declarations. Each
element carries an elementID for use by the ForCES protocol. In component carries a componentID for use by the ForCES protocol. In
addition, the element contains the name, a synopsis, an optional addition, the component declaration contains the name of the
description, an optional declaration that the element itself is component, a synopsis, an optional description, an optional
optional, and the typeRef declaration that specifies the element declaration that the component itself is optional, and the typeRef
type. declaration that specifies the component type.
For a dataTypeDef of a struct, the structure definition may be For a dataTypeDef of a struct, the structure definition may be
inherited from, and augment, a previously defined structured type. inherited from, and augment, a previously defined structured type.
This is indicated by including the derivedFrom attribute on the This is indicated by including the derivedFrom attribute on the
struct declaration. struct declaration.
The result of this construct MUST be a compound type, even when the The result of this construct MUST be a compound type, even when the
<struct> contains only one field. <struct> contains only one field.
An example: An example:
<dataTypeDef> <dataTypeDef>
<name>ipv4prefix</name> <name>ipv4prefix</name>
<synopsis> <synopsis>
IPv4 prefix defined by an address and a prefix length IPv4 prefix defined by an address and a prefix length
</synopsis> </synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>address</name> <name>address</name>
<synopsis>Address part</synopsis> <synopsis>Address part</synopsis>
<typeRef>ipv4addr</typeRef> <typeRef>ipv4addr</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>prefixlen</name> <name>prefixlen</name>
<synopsis>Prefix length part</synopsis> <synopsis>Prefix length part</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="32"/> <allowedRange min="0" max="32"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.5.5. <union> Element to Define Union Types 4.5.5. <union> Element to Define Union Types
Similar to the union declaration in C, this construct allows the Similar to the union declaration in C, this construct allows the
definition of overlay types. Its format is identical to the definition of overlay types. Its format is identical to the <struct>
<struct> element. element.
The result of this construct MUST be a compound type, even when the The result of this construct MUST be a compound type, even when the
union contains only one element. union contains only one element.
4.5.6 <alias> Element 4.5.6. <alias> Element
It is sometimes necessary to have an element in an LFB or structure It is sometimes necessary to have a component in an LFB or structure
refer to information in other LFBs. The <alias> declaration creates refer to information (a component) in other LFBs. The <alias>
the constructs for this. The content of an <alias> element MUST be a declaration creates the constructs for this. The content of an
named type. It can be a base type of a derived type. The actual <alias> element MUST be a named type. Whatever component the alias
value referenced by an alias is known as its target. When a GET or references (whcih is determined by the alias component properties, as
SET operation references the alias element, the value of the target described below) that component must be of the same type as that
is returned or replaced. Write access to an alias element is declared for the alias. Thus, when the CE or FE dereferences the
permitted if write access to both the alias and the target are alias component, the type of the information returned is known. The
permitted. type can be a base type or a derived type. 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 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.
The target of an <alias> element is determined by its properties. The target of a component declared by an >alias> element is
Like all elements, the properties MUST include the support / read / determined by it the components properties. Like all components, the
write permission for the alias. In addition, there are several properties MUST include the support / read / write permission for the
fields in the properties which define the target of the alias. alias. In addition, there are several fields (components) in the
These fields are the ID of the LFB class of the target, the ID of alias properties which define the target of the alias. These
the LFB instance of the target, and a sequence of integers components are the ID of the LFB class of the target, the ID of the
representing the path within the target LFB instance to the target LFB instance of the target, and a sequence of integers representing
element. The type of the target element must match the declared the path within the target LFB instance to the target component. The
type of the alias. Details of the alias property structure in the type of the target element must match the declared type of the alias.
section of this document on properties. Details of the alias property structure are described in the section
of this document on properties.
Note that the read / write property of the alias refers to the Note that the read / write property of the alias refers to the value.
value. The CE can only determine if it can write the target The CE can only determine if it can write the target selection
selection properties of the alias by attempting such a write properties of the alias by attempting such a write operation.
operation. (Property elements do not themselves have properties.) (Property components do not themselves have properties.)
4.5.6. Augmentations 4.5.7. Augmentationst
Compound types can also be defined as augmentations of existing Compound types can also be defined as augmentations of existing
compound types. If the existing compound type is a structure, compound types. If the existing compound type is a structure,
augmentation may add new elements to the type. The type of an augmentation may add new elements to the type. The type of an
existing element can only be replaced with an augmentation derived existing component can be replaced in the definition of an augmenting
from the current type, an existing element cannot be deleted. If structure, but only with an augmentation derived from the current
the existing compound type is an array, augmentation means type of the existing component. An existing component cannot be
augmentation of the array element type. deleted. If the existing compound type is an array, augmentation
means augmentation of the array element type.
One consequence of this is that augmentations are compatible with One consequence of this is that augmentations are backwards
the compound type from which they are derived. As such, compatible with the compound type from which they are derived. As
augmentations are useful in defining attributes for LFB subclasses such, augmentations are useful in defining components for LFB
with backward compatibility. In addition to adding new attributes subclasses with backward compatibility. In addition to adding new
to a class, the data type of an existing attribute may be replaced components to a class, the data type of an existing components may be
by an augmentation of that attribute, and still meet the replaced by an augmentation of that component, and still meet the
compatibility rules for subclasses. compatibility rules for subclasses.
For example, consider a simple base LFB class A that has only one For example, consider a simple base LFB class A that has only one
attribute (attr1) of type X. One way to derive class A1 from A can component (comp1) of type X. One way to derive class A1 from A can be
be by simply adding a second attribute (of any type). Another way by simply adding a second component (of any type). Another way to
to derive a class A2 from A can be by replacing the original derive a class A2 from A can be by replacing the original component
attribute (attr1) in A of type X with one of type Y, where Y is an (comp1) in A of type X with one of type Y, where Y is an augmentation
augmentation of X. Both classes A1 and A2 are backward compatible of X. Both classes A1 and A2 are backward compatible with class A.
with class A.
The syntax for augmentations is to include a derivedFrom element in The syntax for augmentations is to include a <derivedFrom> element in
a structure definition, indicating what structure type is being a structure definition, indicating what structure type is being
augmented. Element names and element IDs within the augmentation augmented. Component names and component IDs within the augmentation
must not be the same as those in the structure type being augmented. must not be the same as those in the structure type being augmented.
4.6. <metadataDefs> Element for Metadata Definitions 4.6. <metadataDefs> Element for Metadata Definitions
The (optional) <metadataDefs> element in the library document The (optional) <metadataDefs> element in the library document
contains one or more <metadataDef> elements. Each <metadataDef> contains one or more <metadataDef> elements. Each <metadataDef>
element defines a metadata. element defines a metadata.
Each <metadataDef> element MUST contain a unique name (NMTOKEN). Each <metadataDef> element MUST contain a unique name (NMTOKEN).
Uniqueness is defined to be over all metadata defined in this Uniqueness is defined to be over all metadata defined in this library
library document and in all directly or indirectly included library document and in all directly or indirectly included library
documents. The <metadataDef> element MUST also contain a brief documents. The <metadataDef> element MUST also contain a brief
synopsis, the mandatory tag value to be used for this metadata, an synopsis, the mandatory tag value to be used for this metadata, an
optional detailed description, and a mandatory type definition optional detailed description, and a mandatory type definition
information. Only atomic data types can be used as value types for information. Only atomic data types can be used as value types for
metadata. metadata.
Two forms of type definitions are allowed. The first form uses the Two forms of type definitions are allowed. The first form uses the
<typeRef> element to refer to an existing atomic data type defined <typeRef> element to refer to an existing atomic data type defined in
in the <dataTypeDefs> element of the same library document or in one the <dataTypeDefs> element of the same library document or in one of
of the included library documents. The usage of the <typeRef> the included library documents. The usage of the <typeRef> element
element is identical to how it is used in the <dataTypeDef> is identical to how it is used in the <dataTypeDef> elements, except
elements, except here it can only refer to atomic types. here it can only refer to atomic types. The latter restriction is
The latter restriction is not yet enforced by the XML schema. not yet enforced by the XML schema.
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>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>NOMATCH</name> <name>NOMATCH</name>
<synopsis> <synopsis>
Classification didn’t result in match. Classification didn't result in match.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
4.7. <LFBClassDefs> Element for LFB Class Definitions 4.7. <LFBClassDefs> Element for LFB Class Definitions
The (optional) <LFBClassDefs> element can be used to define one or The (optional) <LFBClassDefs> element can be used to define one or
more LFB classes using <LFBClassDef> elements. Each <LFBClassDef> more LFB classes using <LFBClassDef> elements. Each <LFBClassDef>
element MUST define an LFB class and include the following elements: element MUST define an LFB class and include the following elements:
. <name> provides the symbolic name of the LFB class. Example: o <name> provides the symbolic name of the LFB class. Example:
"ipv4lpm" "ipv4lpm"
. <synopsis> provides a short synopsis of the LFB class. Example:
o <synopsis> provides a short synopsis of the LFB class. Example:
"IPv4 Longest Prefix Match Lookup LFB" "IPv4 Longest Prefix Match Lookup LFB"
. <version> is the version indicator
. <derivedFrom> is the inheritance indicator
. <inputPorts> lists the input ports and their specifications
. <outputPorts> lists the output ports and their specifications
. <attributes> defines the operational attributes of the LFB
. <capabilities> defines the capability attributes of the LFB
. <description> contains the operational specification of the LFB
. The LFBClassID attribute of the LFBClassDef element defines the
ID for this class. These must be globally unique.
. <events> defines the events that can be generated by instances
of this LFB.
LFB Class Names must be unique, in order to enable other documents o <version> is the version indicator
to reference the classes by name, and to enable human readers to
o <derivedFrom> is the inheritance indicator
o <inputPorts> lists the input ports and their specifications
o <outputPorts> lists the output ports and their specifications
o <components> defines the operational components of the LFB
o <capabilities> defines the capability components of the LFB
o <description> contains the operational specification of the LFB
o The LFBClassID attribute of the LFBClassDef element defines the ID
for this class. These must be globally unique.
o <events> defines the events that can be generated by instances of
this LFB.
LFB Class Names must be unique, in order to enable other documents to
reference the classes by name, and to enable human readers to
understand references to class names. While a complex naming understand references to class names. While a complex naming
structure could be created, simplicity is preferred. As given in the structure could be created, simplicity is preferred. As given in the
IANA considerations section of this document, the IANA will maintain IANA considerations section of this document, the IANA will maintain
a registry of LFB Class names and Class identifiers, along with a a registry of LFB Class names and Class identifiers, along with a
reference to the document defining the class. reference to the document defining the class.
Here is a skeleton of an example LFB class definition: Here is a skeleton of an example LFB class definition:
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="12345"> <LFBClassDef LFBClassID="12345">
skipping to change at page 52, line 14 skipping to change at page 57, line 20
<derivedFrom>baseclass</derivedFrom> <derivedFrom>baseclass</derivedFrom>
<inputPorts> <inputPorts>
... ...
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
... ...
</outputPorts> </outputPorts>
<attributes> <components>
... ...
</attributes> </components>
<capabilities> <capabilities>
... ...
</capabilities> </capabilities>
<description> <description>
This LFB represents the IPv4 longest prefix match lookup This LFB represents the IPv4 longest prefix match lookup
operation. operation.
The modeled behavior is as follows: The modeled behavior is as follows:
Blah-blah-blah. Blah-blah-blah.
</description> </description>
</LFBClassDef> </LFBClassDef>
... ...
</LFBClassDefs> </LFBClassDefs>
The individual attributes and capabilities will have elementIDs for The individual components and capabilities will have componentIDs for
use by the ForCES protocol. These parallel the elementIDs used in use by the ForCES protocol. These parallel the componentIDs used in
structs, and are used the same way. Attribute and capability structs, and are used the same way. Component and capability
elementIDs must be unique within the LFB class definition. componentIDs must be unique within the LFB class definition.
Note that the <name>, <synopsis>, and <version> elements are Note that the <name>, <synopsis>, and <version> elements are
required, all other elements are optional in <LFBClassDef>. However, required, all other elements are optional in <LFBClassDef<. However,
when they are present, they must occur in the above order. when they are present, they must occur in the above order.
4.7.1. <derivedFrom> Element to Express LFB Inheritance 4.7.1. <derivedFrom> Element to Express LFB Inheritance
The optional <derivedFrom> element can be used to indicate that this The optional <derivedFrom> element can be used to indicate that this
class is a derivative of some other class. The content of this class is a derivative of some other class. The content of this
element MUST be the unique name (<name>) of another LFB class. The element MUST be the unique name (<name>) of another LFB class. The
referred LFB class MUST be defined in the same library document or referred LFB class MUST be defined in the same library document or in
in one of the included library documents. one of the included library documents.
It is assumed that the derived class is backwards compatible with It is assumed that the derived class is backwards compatible with the
the base class. base class.
4.7.2. <inputPorts> Element to Define LFB Inputs 4.7.2. <inputPorts> Element to Define LFB Inputs
The optional <inputPorts> element is used to define input ports. An The optional <inputPorts> element is used to define input ports. An
LFB class may have zero, one, or more inputs. If the LFB class has LFB class may have zero, one, or more inputs. If the LFB class has
no input ports, the <inputPorts> element MUST be omitted. The no input ports, the <inputPorts> element MUST be omitted. The
<inputPorts> element can contain one or more <inputPort> elements, <inputPorts> element can contain one or more <inputPort> elements,
one for each port or port-group. We assume that most LFBs will have one for each port or port-group. We assume that most LFBs will have
exactly one input. Multiple inputs with the same input type are exactly one input. Multiple inputs with the same input type are
modeled as one input group. Input groups are defined the same way modeled as one input group. Input groups are defined the same way as
as input ports by the <inputPort> element, differentiated only by an input ports by the <inputPort> element, differentiated only by an
optional "group" attribute. optional "group" attribute.
Multiple inputs with different input types should be avoided if Multiple inputs with different input types should be avoided if
possible (see discussion in Section 3.2.1). Some special LFBs will possible (see discussion in Section 4.7.3). Some special LFBs will
have no inputs at all. For example, a packet generator LFB does not have no inputs at all. For example, a packet generator LFB does not
need an input. need an input.
Single input ports and input port groups are both defined by the Single input ports and input port groups are both defined by the
<inputPort> element; they are differentiated by only an optional <inputPort> element; they are differentiated by only an optional
"group" attribute. "group" attribute.
The <inputPort> element MUST contain the following elements: The <inputPort> element MUST contain the following elements:
. <name> provides the symbolic name of the input. Example: "in". o <name> provides the symbolic name of the input. Example: "in".
Note that this symbolic name must be unique only within the scope Note that this symbolic name must be unique only within the scope
of the LFB class. of the LFB class.
. <synopsis> contains a brief description of the input. Example:
o <synopsis> contains a brief description of the input. Example:
"Normal packet input". "Normal packet input".
. <expectation> lists all allowed frame formats. Example: {"ipv4"
o <expectation> lists all allowed frame formats. Example: {"ipv4"
and "ipv6"}. Note that this list should refer to names specified and "ipv6"}. Note that this list should refer to names specified
in the <frameDefs> element of the same library document or in any in the <frameDefs> element of the same library document or in any
included library documents. The <expectation> element can also included library documents. The <expectation> element can also
provide a list of required metadata. Example: {"classid", provide a list of required metadata. Example: {"classid",
"vifid"}. This list should refer to names of metadata defined in "vifid"}. This list should refer to names of metadata defined in
the <metadataDefs> element in the same library document or in any the <metadataDefs> element in the same library document or in any
included library documents. For each metadata, it must be included library documents. For each metadata, it must be
specified whether the metadata is required or optional. For each specified whether the metadata is required or optional. For each
optional metadata, a default value must be specified, which is optional metadata, a default value must be specified, which is
used by the LFB if the metadata is not provided with a packet. used by the LFB if the metadata is not provided with a packet.
In addition, the optional "group" attribute of the <inputPort> In addition, the optional "group" attribute of the <inputPort>
element can specify if the port can behave as a port group, i.e., it element can specify if the port can behave as a port group, i.e., it
is allowed to be instantiated. This is indicated by a "yes" value is allowed to be instantiated. This is indicated by a "yes" value
(the default value is "no"). (the default value is "no").
An example <inputPorts> element, defining two input ports, the An example <inputPorts< element, defining two input ports, the second
second one being an input port group: one being an input port group:
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>in</name> <name>in</name>
<synopsis>Normal input</synopsis> <synopsis>Normal input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>ipv4</ref> <ref>ipv4</ref>
<ref>ipv6</ref> <ref>ipv6</ref>
</frameExpected> </frameExpected>
skipping to change at page 54, line 27 skipping to change at page 59, line 35
<ref dependency="optional" defaultValue="0">vrfid</ref> <ref dependency="optional" defaultValue="0">vrfid</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
<inputPort group="yes"> <inputPort group="yes">
... another input port ... ... another input port ...
</inputPort> </inputPort>
</inputPorts> </inputPorts>
For each <inputPort>, the frame type expectations are defined by the For each <inputPort>, the frame type expectations are defined by the
<frameExpected> element using one or more <ref> elements (see <frameExpected> element using one or more <ref> elements (see example
example above). When multiple frame types are listed, it means that above). When multiple frame types are listed, it means that "one of
"one of these" frame types is expected. A packet of any other frame these" frame types is expected. A packet of any other frame type is
type is regarded as incompatible with this input port of the LFB regarded as incompatible with this input port of the LFB class. The
class. The above example list two frames as expected frame types: above example list two frames as expected frame types: "ipv4" and
"ipv4" and "ipv6". "ipv6".
Metadata expectations are specified by the <metadataExpected> Metadata expectations are specified by the <metadataExpected>
element. In its simplest form, this element can contain a list of element. In its simplest form, this element can contain a list of
<ref> elements, each referring to a metadata. When multiple <ref> elements, each referring to a metadata. When multiple
instances of metadata are listed by <ref> elements, it means that instances of metadata are listed by <ref> elements, it means that
"all of these" metadata must be received with each packet (except "all of these" metadata must be received with each packet (except
metadata that are marked as "optional" by the "dependency" attribute metadata that are marked as "optional" by the "dependency" attribute
of the corresponding <ref> element). For a metadata that is ot the corresponding <ref> element). For a metadata that is
specified "optional", a default value MUST be provided using the specified "optional", a default value MUST be provided using the
"defaultValue" attribute. The above example lists three metadata as "defaultValue" attribute. The above example lists three metadata as
expected metadata, two of which are mandatory ("classid" and expected metadata, two of which are mandatory ("classid" and
"vifid"), and one being optional ("vrfid"). "vifid"), and one being optional ("vrfid").
The schema also allows for more complex definitions of metadata The schema also allows for more complex definitions of metadata
expectations. For example, using the <one-of> element, a list of expectations. For example, using the <one-of> element, a list of
metadata can be specified to express that at least one of the metadata can be specified to express that at least one of the
specified metadata must be present with any packet. For example: specified metadata must be present with any packet. For example:
skipping to change at page 55, line 47 skipping to change at page 61, line 5
one for each port or port-group. If there are multiple outputs with one for each port or port-group. If there are multiple outputs with
the same output type, we model them as an output port group. Some the same output type, we model them as an output port group. Some
special LFBs may have no outputs at all (e.g., Dropper). special LFBs may have no outputs at all (e.g., Dropper).
Single output ports and output port groups are both defined by the Single output ports and output port groups are both defined by the
<outputPort> element; they are differentiated by only an optional <outputPort> element; they are differentiated by only an optional
"group" attribute. "group" attribute.
The <outputPort> element MUST contain the following elements: The <outputPort> element MUST contain the following elements:
. <name> provides the symbolic name of the output. Example: "out". o <name> provides the symbolic name of the output. Example: "out".
Note that the symbolic name must be unique only within the scope Note that the symbolic name must be unique only within the scope
of the LFB class. of the LFB class.
. <synopsis> contains a brief description of the output port.
o <synopsis> contains a brief description of the output port.
Example: "Normal packet output". Example: "Normal packet output".
. <product> lists the allowed frame formats. Example: {"ipv4",
o <product> lists the allowed frame formats. Example: {"ipv4",
"ipv6"}. Note that this list should refer to symbols specified in "ipv6"}. Note that this list should refer to symbols specified in
the <frameDefs> element in the same library document or in any the <frameDefs> element in the same library document or in any
included library documents. The <product> element may also included library documents. The <product> element may also
contain the list of emitted (generated) metadata. Example: contain the list of emitted (generated) metadata. Example:
{"classid", "color"}. This list should refer to names of metadata {"classid", "color"}. This list should refer to names of metadata
specified in the <metadataDefs> element in the same library specified in the <metadataDefs> element in the same library
document or in any included library documents. For each generated document or in any included library documents. For each generated
metadata, it should be specified whether the metadata is always metadata, it should be specified whether the metadata is always
generated or generated only in certain conditions. This generated or generated only in certain conditions. This
information is important when assessing compatibility between information is important when assessing compatibility between
LFBs. LFBs.
In addition, the optional "group" attribute of the <outputPort> In addition, the optional "group" attribute of the <outputPort>
element can specify if the port can behave as a port group, i.e., it element can specify if the port can behave as a port group, i.e., it
is allowed to be instantiated. This is indicated by a "yes" value is allowed to be instantiated. This is indicated by a "yes" value
(the default value is "no"). (the default value is "no").
The following example specifies two output ports, the second being The following example specifies two output ports, the second being an
an output port group: output port group:
<outputPorts> <outputPorts>
<outputPort> <outputPort>
<name>out</name> <name>out</name>
<synopsis>Normal output</synopsis> <synopsis>Normal output</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>ipv4</ref> <ref>ipv4</ref>
<ref>ipv4bis</ref> <ref>ipv4bis</ref>
</frameProduced> </frameProduced>
skipping to change at page 57, line 4 skipping to change at page 62, line 34
<frameProduced> <frameProduced>
<ref>ipv4</ref> <ref>ipv4</ref>
<ref>ipv4bis</ref> <ref>ipv4bis</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref availability="conditional">errorid</ref> <ref availability="conditional">errorid</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
The types of frames and metadata the port produces are defined
inside the <product> element in each <outputPort>. Within the The types of frames and metadata the port produces are defined inside
<product> element, the list of frame types the port produces is the <product> element in each <outputPort>. Within the <product>
listed in the <frameProduced> element. When more than one frame is element, the list of frame types the port produces is listed in the
listed, it means that "one of" these frames will be produced. <frameProduced> element. When more than one frame is listed, it
means that "one of" these frames will be produced.
The list of metadata that is produced with each packet is listed in The list of metadata that is produced with each packet is listed in
the optional <metadataProduced> element of the <product>. In its the optional <metadataProduced> element of the <product>. In its
simplest form, this element can contain a list of <ref> elements, simplest form, this element can contain a list of <ref> elements,
each referring to a metadata type. The meaning of such a list is each referring to a metadata type. The meaning of such a list is
that "all of" these metadata are provided with each packet, except that "all of" these metadata are provided with each packet, except
those that are listed with the optional "availability" attribute set those that are listed with the optional "availability" attribute set
to "conditional". Similar to the <metadataExpected> element of the to "conditional". Similar to the <metadataExpected> element of the
<inputPort>, the <metadataProduced> element supports more complex <inputPort>, the <metadataProduced> element supports more complex
forms, which we do not discuss here further. forms, which we do not discuss here further.
4.7.4. <attributes> Element to Define LFB Operational Attributes 4.7.4. <components> Element to Define LFB Operational Components
Operational parameters of the LFBs that must be visible to the CEs Operational parameters of the LFBs that must be visible to the CEs
are conceptualized in the model as the LFB attributes. These are conceptualized in the model as the LFB components. These
include, for example, flags, single parameter arguments, complex include, for example, flags, single parameter arguments, complex
arguments, and tables. Note that the attributes here refer to only arguments, and tables. Note that the components here refer to only
those operational parameters of the LFBs that must be visible to the those operational parameters of the LFBs that must be visible to the
CEs. Other variables that are internal to LFB implementation are CEs. Other variables that are internal to LFB implementation are not
not regarded as LFB attributes and hence are not covered. regarded as LFB components and hence are not covered.
Some examples for LFB attributes are: Some examples for LFB components are:
. Configurable flags and switches selecting between operational o Configurable flags and switches selecting between operational
modes of the LFB modes of the LFB
. Number of inputs or outputs in a port group
. Metadata CONSUME vs.PROPAGATE mode selector o Number of inputs or outputs in a port group
. Various configurable lookup tables, including interface tables,
o Metadata CONSUME vs.PROPAGATE mode selector
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.
. Packet and byte counters
. Various event counters o Packet and byte counters
. Number of current inputs or outputs for each input or output
group o Various event counters
o Number of current inputs or outputs for each input or output group
There may be various access permission restrictions on what the CE There may be various access permission restrictions on what the CE
can do with an LFB attribute. The following categories may be can do with an LFB component. The following categories may be
supported: supported:
. No-access attributes. This is useful when multiple access o No-access components. This is useful when multiple access modes
modes may be defined for a given attribute to allow some may be defined for a given component to allow some flexibility for
flexibility for different implementations. different implementations.
. Read-only attributes.
. Read-write attributes.
. Write-only attributes. This could be any configurable data for o Read-only components.
o Read-write components.
o Write-only components. This could be any configurable data for
which read capability is not provided to the CEs. (e.g., the which read capability is not provided to the CEs. (e.g., the
security key information) security key information)
. Read-reset attributes. The CE can read and reset this
resource, but cannot set it to an arbitrary value. Example: o Read-reset components. The CE can read and reset this resource,
Counters. but cannot set it to an arbitrary value. Example: Counters.
. Firing-only attributes. A write attempt to this resource will
o Firing-only components. A write attempt to this resource will
trigger some specific actions in the LFB, but the actual value trigger some specific actions in the LFB, but the actual value
written is ignored. written is ignored.
The LFB class may define more than one possible access mode for a The LFB class may define more than one possible access mode for a
given attribute (for example, "write-only" and "read-write"), in given component (for example, "write-only" and "read-write"), in
which case it is left to the actual implementation to pick one of which case it is left to the actual implementation to pick one of the
the modes. In such cases, a corresponding capability attribute must modes. In such cases, a corresponding property component must inform
inform the CE about the access mode the actual LFB instance supports the CE about the access mode the actual LFB instance supports.
(see next subsection on capability attributes).
The attributes of the LFB class are listed in the <attributes> The components of the LFB class are listed in the <components>
element. Each attribute is defined by an <attribute> element. An element. Each component is defined by an <component> element. An
<attribute> element MUST contain the following elements: <component> element MUST contain the following elements:
. <name> defines the name of the attribute. This name must be o <name> defines the name of the component.This name must be unique
unique among the attributes of the LFB class. Example: among the components of the LFB class. Example: "version".
"version".
. <synopsis> should provide a brief description of the purpose of o <synopsis> should provide a brief description of the purpose of
the attribute. the component.
. <optional/> indicates that this attribute is optional.
. The data type of the attribute can be defined either via a o <optional/> indicates that this component is optional.
o The data type of the component can be defined either via a
reference to a predefined data type or providing a local reference to a predefined data type or providing a local
definition of the type. The former is provided by using the definition of the type. The former is provided by using the
<typeRef> element, which must refer to the unique name of an <typeRef> element, which must refer to the unique name of an
existing data type defined in the <dataTypeDefs> element in the existing data type defined in the <dataTypeDefs> element in the
same library document or in any of the included library same library document or in any of the included library documents.
documents. When the data type is defined locally (unnamed When the data type is defined locally (unnamed type), one of the
type), one of the following elements can be used: <atomic>, following elements can be used: <atomic>, <array>, <struct>, and
<array>, <struct>, and <union>. Their usage is identical to how <union>. Their usage is identical to how they are used inside
they are used inside <dataTypeDef> elements (see Section 4.5). <dataTypeDef> elements (see Section 4.5).
. The optional <defaultValue> element can specify a default value
for the attribute, which is applied when the LFB is initialized
or reset.
The attribute element also MUST have an elementID attribute, which o The optional <defaultValue> element can specify a default value
is a numeric value used by the ForCES protocol. for the component, which is applied when the LFB is initialized or
reset.
In addition to the above elements, the <attribute> element includes The <component> element also MUST have an componentID attribute,
which is a numeric value used by the ForCES protocol.
In addition to the above elements, the <component> element includes
an optional "access" attribute, which can take any of the following an optional "access" attribute, which can take any of the following
values or even a list of these values: "read-only", "read-write", values or even a list of these values: "read-only", "read-write",
"write-only", "read-reset", and "trigger-only". The default access "write-only", "read-reset", and "trigger-only". The default access
mode is "read-write". mode is "read-write".
Whether optional elements are supported, and whether elements Whether optional components are supported, and whether components
defined as read-write can actually be written can be determined for defined as read-write can actually be written can be determined for a
a given LFB instance by the CE by reading the property information given LFB instance by the CE by reading the property information of
of that element. that component.
The following example defines two attributes for an LFB: The following example defines two attributes for an LFB:
<attributes> <components>
<attribute access="read-only" elementID=’’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>
</attribute> </component>
<attribute access="read-write write-only" elementID=’’2’’> <component access="read-write write-only" 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>
</attribute> </component>
</attributes> </component>
The first attribute ("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 attribute ("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 attribute has element to provide additional range restrictions. This attribute has
two possible access modes, "read-write" or "write-only". A default two possible access modes, "read-write" or "write-only". A default
value of 10 is provided. value of 10 is provided.
Note that not all attributes are likely to exist at all times in a Note that not all components are likely to exist at all times in a
particular implementation. While the capabilities will frequently particular implementation. While the capabilities will frequently
indicate this non-existence, CEs may attempt to reference non- indicate this non-existence, CEs may attempt to reference non-
existent or non-permitted attributes anyway. The FORCES protocol existent or non-permitted attributes anyway. The FORCES protocol
mechanisms should include appropriate error indicators for this mechanisms should include appropriate error indicators for this case.
case.
The mechanism defined above for non-supported attributes can also The mechanism defined above for non-supported component can also
apply to attempts to reference non-existent array elements or to set apply to attempts to reference non-existent array elements or to set
read-only elements. read-only components.
4.7.5. <capabilities> Element to Define LFB Capability Attributes 4.7.5. <capabilities> Element to Define LFB Capability Components
The LFB class specification provides some flexibility for the FE The LFB class specification provides some flexibility for the FE
implementation regarding how the LFB class is implemented. For implementation regarding how the LFB class is implemented. For
example, the instance may have some limitations that are not example, the instance may have some limitations that are not inherent
inherent from the class definition, but rather the result of some from the class definition, but rather the result of some
implementation limitations. For example, an array attribute may be implementation limitations. Some of these limitations are captured
defined in the class definition as "unlimited" size, but the by the property information of the LFB components. The model allows
physical implementation may impose a hard limit on the size of the for the notion of additional capability information.
array.
Such capability related information is expressed by the capability Such capability related information is expressed by the capability
attributes of the LFB class. The capability attributes are always components of the LFB class. The capability components are always
read-only attributes, and they are listed in a separate read-only attributes, and they are listed in a separate
<capabilities> element in the <LFBClassDef>. The <capabilities> <capabilities> element in the <LFBClassDef>. The <capabilities>
element contains one or more <capability> elements, each defining element contains one or more <capability> elements, each defining one
one capability attribute. The format of the <capability> element is capability component. The format of the <capability> element is
almost the same as the <attribute> element, it differs in two almost the same as the <component> element, it differs in two
aspects: it lacks the access mode attribute (because it is always aspects: it lacks the access mode attribute (because it is always
read-only), and it lacks the <defaultValue> element (because default read-only), and it lacks the <defaultValue> element (because default
value is not applicable to read-only attributes). value is not applicable to read-only attributes).
Some examples of capability attributes follow: Some examples of capability components follow:
. The version of the LFB class that this LFB instance complies o The version of the LFB class that this LFB instance complies with;
with;
. Supported optional features of the LFB class; o Supported optional features of the LFB class;
. Maximum number of configurable outputs for an output group;
. Metadata pass-through limitations of the LFB; o Maximum number of configurable outputs for an output group;
. Maximum size of configurable attribute tables;
. Additional range restriction on operational attributes; o Metadata pass-through limitations of the LFB;
. Supported access modes of certain attributes (if the access
mode of an operational attribute is specified as a list of two o Additional range restriction on operational components;
or mode modes).
The following example lists two capability attributes: The following example lists two capability attributes:
<capabilities> <capabilities>
<capability elementID="3"> <capability componentID="3">
<name>version</name> <name>version</name>
<synopsis> <synopsis>
LFB class version this instance is compliant with. LFB class version this instance is compliant with.
</synopsis> </synopsis>
<typeRef>version</typeRef> <typeRef>version</typeRef>
</capability> </capability>
<capability elementID="4"> <capability componentID="4">
<name>limitBar</name> <name>limitBar</name>
<synopsis> <synopsis>
Maximum value of the "bar" attribute. Maximum value of the "bar" attribute.
</synopsis> </synopsis>
<typeRef>uint16</typeRef> <typeRef>uint16</typeRef>
</capability> </capability>
</capabilities> </capabilities>
4.7.6. <events> Element for LFB Notification Generation 4.7.6. <events> Element for LFB Notification Generation
The <events> element contains the information about the occurrences The <events> element contains the information about the occurrences
for which instances of this LFB class can generate notifications to for which instances of this LFB class can generate notifications to
the CE. the CE.
The <events> definition needs a baseID attributevalue, which is The <events> element has a baseID attribute value, which is normally
normally <events baseID=’’number’’>. The value of the baseID is the <events baseID="number">. The value of the baseID is the starting
starting element for the path which identifies events. It must not componentID for the path which identifies events. It must not be the
be the same as the elementID of any top level attribute or same as the componentID of any top level components (including
capability of the LFB class. In derived LFBs (i.e. ones with a capabilities) of the LFB class. In derived LFBs (i.e. ones with a
<derivedFrom> element) where the parent LFB class has an events <derivedFrom> element) where the parent LFB class has an events
declaration, the baseID must not be present. Instead, the value declaration, the baseID must not be present in the derived LFB
from the parent class is used. <events> element. Instead, the baseID value from the parent LFB
class is used.
The <events> element contains 0 or more <event> elements, each of The <events> element contains 0 or more <event> elements, each of
which declares a single event. The <event> element has an eventID which declares a single event. The <event> element has an eventID
attribute giving the unique ID of the event. The element will attribute giving the unique ID of the event. The element will
include: include:
. <eventTarget> element indicating which LFB field is tested to o <eventTarget> element indicating which LFB field (component) is
generate the event; tested to generate the event;
. condition element indicating what condition on the field will
o <condition> element indicating what condition on the field will
generate the event from a list of defined conditions; generate the event from a list of defined conditions;
. <eventReports> element indicating what values are to be
reported in the notification of the event.
4.7.6.1 <eventTarget> Element o <eventReports> element indicating what values are to be reported
in the notification of the event.
The <eventTarget> element contains information identifying a field 4.7.6.1. <eventTarget> Element
in the LFB. Specifically, the <target> element contains one or more
The <eventTarget> element contains information identifying a field in
the LFB. Specifically, the <target> element contains one or more
<eventField> or <eventSubscript> elements. These elements represent <eventField> or <eventSubscript> elements. These elements represent
the textual equivalent of a path select component of the LFB. The the textual equivalent of a path select component of the LFB. The
<eventField> element contains the name of an element in the LFB or <eventField> element contains the name of a component in the LFB or a
struct. The first element in a <target> MUST be an <eventField> component nested in an array or struct within the LFB. The first
element and MUST name a field in the LFB. The following element element in a <target> MUST be an <eventField> element and MUST name a
MUST identify a valid field within the containing context. If an componet in the LFB. The following element MUST identify a valid
<eventField> identifies an array, and is not the last element in the component within the containing context. If an <eventField>
target, then the next element MUST be an <eventSubscript>. identifies an array, and is not the last element in the target, then
the next element MUST be an < eventSubscript> element.
<eventSubscript> elements MUST occur only after <eventField> names <eventSubscript> elements MUST occur only after <eventField> names
that identifies an array. An <eventSubscript> may contain a numeric that identifies an array component. An <eventSubscript> may contain
value to indicate that this event applies to a specific element of a numeric value to indicate that this event applies to a specific
the array. More commonly, the event is being defined across all entry (by index) of the array. More commonly, the event is being
elements of the array. In that case, <eventSubscript> will contain defined across all elements of the array. In that case,
a name. The name in an <eventSubscript> element is not a field <eventSubscript> will contain a name. The name in an
name. It is a variable name for use in the <report> elements of <eventSubscript> element is not a component name. It is a variable
this LFB definition. This name MUST be distinct from any field name name for use in the <report> elements of this LFB definition. This
that can validly occur in the <eventReport> clause. Hence it SHOULD name MUST be distinct from any component name that can validly occur
be distinct from any field name used in the LFB or in structures in the <eventReport> clause. Hence it SHOULD be distinct from any
used within the LFB. component name used in the LFB or in structures used within the LFB.
The <eventTarget> provides additional components for the path used The <eventTarget> provides additional components for the path used to
to reference the event. The path will be the baseID for events, reference the event. The path will be 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 in the <eventTarget>. This will each <eventSubscript> element in the <eventTarget>. This will
identify a specific occurrence of the event. So, for example, it identify a specific occurrence of the event. So, for example, it
will appear in the event notification LFB. It is also used for the will appear in the event notification LFB. It is also used for the
SET-PROPERTY operation to subscribe to a specific event. A SET- SET-PROPERTY operation to subscribe to a specific event. A SET-
PROPERTY of the subscription property (but not of any other PROPERTY of the subscription property (but not of any other writeable
writeable properties) may be sent by the CE with any prefix of the properties) may be sent by the CE with any prefix of the path of the
path of the event. So, for an event defined on a table, a SET- event. So, for an event defined on a table, a SET- PROPERTY with a
PROPERTY with a path of the baseID and the eventID will subscribe path of the baseID and the eventID will subscribe the CE to all
the CE to all occurrences of that event on any element of the table. occurrences of that event on any entry of the table. This is
This is particularly useful for the <eventCreated/> and particularly useful for the <eventCreated/> and <eventDestroyed/>
<eventDestroyed/> conditions. Events using those conditions will conditions. Events using those conditions will generally be defined
generally be defined with a field / subscript sequence that with a field / subscript sequence that identifies an array and ends
identifies an array and ends with an <eventSubscript> element. with an <eventSubscript> element. Thus, the event notification will
Thus, the event notification will indicate which array entry has indicate which array entry has been created or destroyed. A typical
been created or destroyed. A typical subscriber will subscribe for subscriber will subscribe for the array, as opposed to a specific
the array, as opposed to a specific element in an array, so it will entry in an array, so it will use a shorter path.
use a shorter path.
Thus, if there is an LFB with an event baseID of 7, and a specific Thus, if there is an LFB with an event baseID of 7, and a specific
event with an event ID of 8, then one can subscribe to the event by event with an event ID of 8, then one can subscribe to the event by
referencing the properties of the LFB element with path 7.8. If the referencing the properties of the LFB component with path 7.8. If
event target has no subscripts (for example, it is a simple the event target has no subscripts (for example, it is a simple
attribute of the LFB) then one can also reference the event component of the LFB) then one can also reference the event threshold
threshold and filtering properties via the properties on element and filtering properties via the properties on element 7.8. If the
7.8. If the event target is defined as an element of an array, then event target is defined as a entry in an array, then the target
the target definition will include an <eventSubscript> element. In definition will include an <eventSubscript> element. In that case,
that case, one can subscribe to the event for the entire array by one can subscribe to the event for the entire array by referencing
referencing the properties of 7.8. One can also subscribe to a the properties of 7.8. One can also subscribe to a specific element,
specific element, x, of the array by referencing the subscription x, of the array by referencing the subscription property of 7.8.x and
property of 7.8.x and also access the threshold and filtering also access the threshold and filtering properties of 7.8.x. If the
properties of 7.8.x. If the event is targeting an element of an event is targeting an entry in an array within an array, then there
array within an array, then there will be two (or conceivably more) will be two (or conceivably more) <eventSubscript> elements in the
<eventSubscript> elements in the target. If so, for the case of two target description. If so, for the case of two elements, one would
elements, one would reference the properties of 7.8.x.y to get to reference the properties of 7.8.x.y to get to the threshold and
the threshold and filtering properties of an individual event. filtering properties of an individual event.
Threshold and filtering conditions can only be applied to individual Threshold and filtering conditions can only be applied to individual
events. For events defined on elements of an array, this events. For events defined on elements of an array, this
specification does not allow for defining a threshold or filtering specification does not allow for defining a threshold or filtering
condition on an event for all elements of an array. condition on an event for all elements of an array.
4.7.6.2 <events> Element Conditions 4.7.6.2. <events> Element Conditions
The condition element represents a condition that triggers a The condition element represents a condition that triggers a
notification. The list of conditions is: notification. The list of conditions is:
. <eventCreated/> the target must be an array, ending with a o <eventCreated/> the target must be an array, ending with a
subscript indication. The event is generated when an entry in subscript indication. The event is generated when an entry in the
the array is created. This occurs even if the entry is created array is created. This occurs even if the entry is created by CE
by CE direction. direction.
. <eventDeleted/> the target must be an array, ending with a
subscript indication. The event is generated when an entry in o <eventDeleted/> the target must be an array, ending with a
the array is destroyed. This occurs even if the entry is subscript indication. The event is generated when an entry in the
destroyed by CE direction. array is destroyed. This occurs even if the entry is destroyed by
. <eventChanged/> the event is generated whenever the target CE direction.
element changes in any way. For binary attributes such as
up/down, this reflects a change in state. It can also be used o <eventChanged/> the event is generated whenever the target
with numeric attributes, in which case any change in value component changes in any way. For binary components such as up/
results in a detected trigger. down, this reflects a change in state. It can also be used with
. <eventGreaterThan/> the event is generated whenever the target numeric attributes, in which case any change in value results in a
element becomes greater than the threshold. The threshold is detected trigger.
an event property.
. <eventLessThan/> the event is generated whenever the target o <eventGreaterThan/> the event is generated whenever the target
element becomes less than the threshold. The threshold is an component becomes greater than the threshold. The threshold is an
event property.
o <eventLessThan/> the event is generated whenever the target
component becomes less than the threshold. The threshold is an
event property. event property.
As described in the Event Properties section, event items have As described in the Event Properties section, event items have
properties associated with them. These properties include the properties associated with them. These properties include the
subscription information (indicating whether the CE wishes the FE to subscription information (indicating whether the CE wishes the FE to
generate event reports for the event at all, thresholds for events generate event reports for the event at all, thresholds for events
related to level crossing, and filtering conditions that may reduce related to level crossing, and filtering conditions that may reduce
the set of event notifications generated by the FE. Details of the the set of event notifications generated by the FE. Details of the
filtering conditions that can be applied are given in that section. filtering conditions that can be applied are given in that section.
The filtering conditions allow the FE to suppress floods of events The 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 do not wish to support filtering, the filter properties can that do not wish to support filtering, the filter properties can
either be read only or not supported. either be read only or not supported.
4.7.6.3 <eventReports> Element 4.7.6.3. <eventReports> Element
The <eventReports> element of an <event> describes the information The <eventReports> element of an <event> describes the information to
to be delivered by the FE along with the notification of the be delivered by the FE along with the notification of the occurrence
occurrence of the event. The <reports> element contains one or more of the event. The <reports> element contains one or more
<eventReport> elements. Each <report> element identifies a piece of <eventReport> elements. Each <report> element identifies a piece of
data from the LFB to be reported. The notification carries that data from the LFB to be reported. The notification carries that data
data as if the collection of <eventReport> elements had been defined as if the collection of <eventReport> elements had been defined in a
in a structure. Each <eventReport> element thus MUST identify a structure. Each <eventReport> element thus MUST identify a component
field in the LFB. The syntax is exactly the same as used in the in the LFB. The syntax is exactly the same as used in the
<eventTarget> element, using <eventField> and <eventSubscript> <eventTarget> element, using <eventField> and <eventSubscript>
elements. <eventSubcripts> may contain integers. If they contain elements. <eventSubcripts> may contain integers. If they contain
names, they MUST be names from <eventSubscript> elements of the names, they MUST be names from <eventSubscript> elements of the
<eventTarget>. The selection for the report will use the value for <eventTarget>. The selection for the report will use the value for
the subscript that identifies that specific element triggering the the subscript that identifies that specific element triggering the
event. This can be used to reference the structure / field causing event. This can be used to reference the Component causing the
the event, or to reference related information in parallel tables. event, or to reference related information in parallel tables. This
This event reporting structure is designed to allow the LFB designer event reporting structure is designed to allow the LFB designer to
to specify information that is likely not known a priori by the CE specify information that is likely not known a priori by the CE and
and is likely needed by the CE to process the event. While the is likely needed by the CE to process the event. While the structure
structure allows for pointing at large blocks of information (full allows for pointing at large blocks of information (full arrays or
arrays or complex structures) this is not recommended. Also, the complex structures) this is not recommended. Also, the variable
variable reference / subscripting in reporting only captures a small reference / subscripting in reporting only captures a small portion
portion of the kinds of related information. Chaining through index of the kinds of related information. Chaining through index fields
fields stored in a table, for example, is not supported. In stored in a table, for example, is not supported. In general, the
general, the <eventReports> mechanism is an optimization for cases <eventReports> mechanism is an optimization for cases that have been
that have been found to be common, saving the CE from having to found to be common, saving the CE from having to query for
query for information it needs to understand the event. It does not information it needs to understand the event. It does not represent
represent all possible information needs. all possible information needs.
If any elements referenced by the eventReport are optional, then the If any components referenced by the eventReport are optional, then
report MUST support optional elements. Any components which do not the report MUST support optional elements. Any components which do
exist are not reported. not exist are not reported.
4.7.7. <description> Element for LFB Operational Specification 4.7.7. <description> Element for LFB Operational Specification
The <description> element of the <LFBClass> provides unstructured The <description> element of the <LFBClass> provides unstructured
text (in XML sense) to verbally describe what the LFB does. text (in XML sense) to verbally describe what the LFB does.
4.8.Properties 4.8.Properties
Elements of LFBs have properties which are important to the CE. The Components of LFBs have properties which are important to the CE.
most important property is the existence / readability / The most important property is the existence / readability /
writeability of the element. Depending up the type of the element, writeability of the element. Depending up the type of the component,
other information may be of importance. other information may be of importance.
The model provides the definition of the structure of property The model provides the definition of the structure of property
information. There is a base class of property information. For information. There is a base class of property information. For the
the array, alias, and event elements there are subclasses of array, alias, and event components there are subclasses of property
property information providing additional fields. This information information providing additional fields. This information is
is accessed by the CE (and updated where applicable) via the PL accessed by the CE (and updated where applicable) via the PL
protocol. While some property information is writeable, there is no protocol. While some property information is writeable, there is no
mechanism currently provided for checking the properties of a mechanism currently provided for checking the properties of a
property element. Writeability can only be checked by attempting to property element. Writeability can only be checked by attempting to
modify the value. modify the value.
4.8.1. Basic Properties 4.8.1. Basic Properties
The basic property definition, along with the scalar for The basic property definition, along with the scalar for
accessibility is below. Note that this access permission accessibility is below. Note that this access permission information
information is generally read-only. is generally read-only.
<dataTypeDef> <dataTypeDef>
<name>accessPermissionValues</name> <name>accessPermissionValues</name>
<synopsis> <synopsis>
The possible values of attribute access permission The possible values of attribute access permission
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
skipping to change at page 65, line 36 skipping to change at page 72, line 36
</specialValue> </specialValue>
<specialValue value="3"> <specialValue value="3">
<name>Read-Write</name> <name>Read-Write</name>
<synopsis> <synopsis>
The attribute may be read or written The attribute may be read or written
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>baseElementProperties</name> <name>baseElementProperties</name>
<synopsis>basic properties, accessibility</synopsis> <synopsis>basic properties, accessibility</synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>accessibility</name> <name>accessibility</name>
<synopsis> <synopsis>
does the element exist, and does the element exist, and
can it be read or written can it be read or written
</synopsis> </synopsis>
<typeRef>accessPermissionValues</typeRef> <typeRef>accessPermissionValues</typeRef>
</element> </component>
</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>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’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>
</element> </component>
<element elementID=’’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>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID=’’4’’> <component componentID="4">
<name>firstUnusedSubscript</name> <name>firstUnusedSubscript</name>
<synopsis> <synopsis>
The subscript of the first unused array element The subscript of the first unused array element
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
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 maximum octet length for the element. The maximum length is included
included because an FE implementation may limit a string to be because an FE implementation may limit a string to be shorter than
shorter than the limit in the LFB Class definition. the limit in the LFB Class definition.
<dataTypeDef> <dataTypeDef>
<name>stringElementProperties</name> <name>stringElementProperties</name>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’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>
</element> </component>
<element elementID=’’3’’> <component componentID="3">
<name>maxStringLength</name> <name>maxStringLength</name>
<synopsis> <synopsis>
the maximum number of octets in the string the maximum number of octets in the string
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
</struct> </struct>
</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>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’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>
</element> </component>
<element elementID=’’3’’> <component componentID="3">
<name>maxOctetstringLength</name> <name>maxOctetstringLength</name>
<synopsis> <synopsis>
the maximum number of octets in the octetstring the maximum number of octets in the octetstring
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.8.5. Event Properties 4.8.5. Event Properties
The properties for an event add three (usually) writeable fields. The properties for an event add three (usually) writeable fields.
One is the subscription field. 0 means no notification is One is the subscription field. 0 means no notification is generated.
generated. Any non-zero value (typically 1 is used) means that a Any non-zero value (typically 1 is used) means that a notification is
notification is generated. The hysteresis field is used to suppress generated. The hysteresis field is used to suppress generation of
generation of notifications for oscillations around a condition notifications for oscillations around a condition value, and is
value, and is described in the text for events. The threshold field described in the text for events. The threshold field is used for
is used for the <eventGreaterThan/> and <eventLessThan/> conditions. the <eventGreaterThan/> and <eventLessThan/> conditions. It
It indicates the value to compare the event target against. Using indicates the value to compare the event target against. Using the
the properties allows the CE to set the level of interest. FEs properties allows the CE to set the level of interest. FEs which do
which do not supporting setting the threshold for events will make not supporting setting the threshold for events will make this field
this field read-only. read-only.
<dataTypeDef> <dataTypeDef>
<name>eventElementProperties</name> <name>eventElementProperties</name>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’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>
</element> </component>
<element elementID=’’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>
</element> </component>
<element elementID=’’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>
</element> </component>
<element elementID=’’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>
</element> </component>
<element elementID=’’6’’> <component componentID="6">
<name>eventHysteresis</name> <name>eventHysteresis</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>
</element> </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
to be subject to rapid occurrence or other concerns may not support to be subject to rapid occurrence or other concerns may not support
all filter conditions. all filter conditions.
skipping to change at page 69, line 22 skipping to change at page 77, line 23
trigger conditions are met, the event notification is generated. If trigger conditions are met, the event notification is generated. If
there are filter conditions, and no condition is met, then no event there are filter conditions, and no condition is met, then no event
notification is generated. Event filter conditions have reset notification is generated. Event filter conditions have reset
behavior when an event notification is generated. If any condition behavior when an event notification is generated. If any condition
is passed, and the notification is generated, the notification reset is passed, and the notification is generated, the notification reset
behavior is performed on all conditions, even those which had not behavior is performed on all conditions, even those which had not
passed. This provides a clean definition of the interaction of the passed. This provides a clean definition of the interaction of the
various event conditions. various event conditions.
An example of the interaction of conditions is an event with an An example of the interaction of conditions is an event with an
eventCount property set to 5 and an eventInterval property set to eventCount property set to 5 and an eventInterval property set to 500
500 milliseconds. Suppose that a burst of occurrences of this event milliseconds. Suppose that a burst of occurrences of this event is
is detected by the FE. The first occurrence will cause a detected by the FE. The first occurrence will cause a notification
notification to be sent to the CE. Then, if four more occurrences to be sent to the CE. Then, if four more occurrences are detected
are detected rapidly (less than 0.5 seconds) they will not result in rapidly (less than 0.5 seconds) they will not result in
notifications. If two more occurrences are detected, then the notifications. If two more occurrences are detected, then the second
second of those will result in a notification. Alternatively, if of those will result in a notification. Alternatively, if more than
more than 500 milliseconds has passed since the notification and an 500 milliseconds has passed since the notification and an occurrence
occurrence is detected, that will result in a notification. In is detected, that will result in a notification. In either case, the
either case, the count and time interval suppression is reset no count and time interval suppression is reset no matter which
matter which condition actually caused the notification. condition actually caused the notification.
4.8.5.2. Event Hysteresis Filtering 4.8.5.2. Event Hysteresis Filtering
Events with numeric conditions can have hysteresis filters applied Events with numeric conditions can have hysteresis filters applied to
to them. The hysteresis level is defined by a property of the them. The hysteresis level is defined by a property of the event.
event. This allows the FE to notify the CE of the hysteresis This allows the FE to notify the CE of the hysteresis applied, and if
applied, and if it chooses, the FE can allow the CE to modify the it chooses, the FE can allow the CE to modify the hysteresis. This
hysteresis. This applies to <eventChanged/> for a numeric field, applies to <eventChanged/> for a numeric field, and to
and to <eventGreaterThan/> and <eventLessThan/>. The content of a <eventGreaterThan/> and < eventLessThan/>. The content of a
<variance> element is a numeric value. When supporting hysteresis, <variance> element is a numeric value. When supporting hysteresis,
the FE MUST track the value of the element and make sure that the the FE MUST track the value of the element and make sure that the
condition has become untrue by at least the hysteresis from the condition has become untrue by at least the hysteresis from the event
event property. To be specific, if the hysteresis is V, then property. To be specific, if the hysteresis is V, then
. For a <eventChanged/> condition, if the last notification was o For a <eventChanged/> condition, if the last notification was for
for value X, then the <changed/> notification MUST NOT be value X, then the <changed/> notification MUST NOT be generated
generated until the value reaches X +/- V. until the value reaches X +/- V.
. For a <eventGreaterThan/> condition with threshold T, once the
o For a <eventGreaterThan/> condition with threshold T, once the
event has been generated at least once it MUST NOT be generated event has been generated at least once it MUST NOT be generated
again until the field first becomes less than or equal to T - - again until the field first becomes less than or equal to T - -V,
V, and then exceeds T. and then exceeds T.
. For a <eventLessThan/> condition with threshold T, once the
event has been generate at least once it MUST NOT be generated o For a <eventLessThan/> condition with threshold T, once the event
again until the field first becomes greater than or equal to T has been generate at least once it MUST NOT be generated again
+ V, and then becomes less than T. until the field first becomes greater than or equal to T + V, and
then becomes less than T.
4.8.5.3. Event Count Filtering 4.8.5.3. Event Count Filtering
Events may have a count filtering condition. This property, if set Events may have a count filtering condition. This property, if set
to a non-zero value, indicates the number of occurrences of the event to a non-zero value, indicates the number of occurrences of the event
that should be considered redundant and not result in a notification. that should be considered redundant and not result in a notification.
Thus, if this property is set to 1, and no other conditions apply, Thus, if this property is set to 1, and no other conditions apply,
then every other detected occurrence of the event will result in a then every other detected occurrence of the event will result in a
notification. This particular meaning is chosen so that the value 1 notification. This particular meaning is chosen so that the value 1
has a distinct meaning from the value 0. has a distinct meaning from the value 0.
skipping to change at page 70, line 32 skipping to change at page 78, line 36
internal suppression counter. Whenever an event is triggered, the internal suppression counter. Whenever an event is triggered, the
counter is checked. If the counter is 0, a notification is counter is checked. If the counter is 0, a notification is
generated. Whether a notification is generated or not, the counter generated. Whether a notification is generated or not, the counter
is incremented. If the counter exceeds the configured value, it is is incremented. If the counter exceeds the configured value, it is
reset to 0. In this conceptual implementation the reset behavior reset to 0. In this conceptual implementation the reset behavior
when a notification is generated can be thought of as setting the when a notification is generated can be thought of as setting the
counter to 1. counter to 1.
4.8.5.4. Event Time Filtering 4.8.5.4. Event Time Filtering
Events may have a time filtering condition. This property Events may have a time filtering condition. This property represents
represents the minimum time interval (in the absence of some other the minimum time interval (in the absence of some other filtering
filtering condition being passed) between generating notifications of condition being passed) between generating notifications of detected
detected events. This condition MUST only be passed if the time events. This condition MUST only be passed if the time since the
since the last notification of the event is longer than the last notification of the event is longer than the configured interval
configured interval in milliseconds. in milliseconds.
Conceptually, this can be thought of as a stored timestamp which is Conceptually, this can be thought of as a stored timestamp which is
compared with the detection time, or as a timer that is running that compared with the detection time, or as a timer that is running that
resets a suppression flag. In either case, if a notification is resets a suppression flag. In either case, if a notification is
generated due to passing any condition then the time interval generated due to passing any condition then the time interval
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 element 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>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’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>
</element> </component>
<element elementID=’’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>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID=’’4’’> <component componentID="4">
<name>targetElementPath</name> <name>targetComponentPath</name>
<synopsis> <synopsis>
the path to the element target the path to the component target
each 4 octets is read as one path element, each 4 octets is read as one path element,
using the path construction in the PL protocol. using the path construction in the PL protocol.
</synopsis> </synopsis>
<typeRef>octetstring[128]</typeRef> <typeRef>octetstring[128]</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.9. XML Schema for LFB Class Library Documents 4.9. XML Schema for LFB Class Library Documents
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://ietf.org/forces/1.0/lfbmodel" xmlns="http://ietf.org/forces/1.0/lfbmodel"
xmlns:lfb="http://ietf.org/forces/1.0/lfbmodel" xmlns:lfb="http://ietf.org/forces/1.0/lfbmodel"
targetNamespace="http://ietf.org/forces/1.0/lfbmodel" targetNamespace="http://ietf.org/forces/1.0/lfbmodel"
skipping to change at page 75, line 13 skipping to change at page 83, line 19
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
<xsd:attribute name="length" type="xsd:integer" use="optional"/> <xsd:attribute name="length" type="xsd:integer" use="optional"/>
<xsd:attribute name="maxLength" type="xsd:integer" <xsd:attribute name="maxLength" type="xsd:integer"
use="optional"/> use="optional"/>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="structType"> <xsd:complexType name="structType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN" <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="element" maxOccurs="unbounded"> <xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="optional" minOccurs="0"/> <xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="elementID" use="required" <xsd:attribute name="componentID" use="required"
type="xsd:integer"/> type="xsd:integer"/>
</xsd:complexType> </xsd:complexType>
<!-- key declaration to make elementIDs unique in a struct <!-- key declaration to make componentIDs unique in a struct
--> -->
<xsd:key name="structElementID"> <xsd:key name="structComponentID">
<xsd:selector xpath="lfb:element"/> <xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@elementID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="metadataDefsType"> <xsd:complexType name="metadataDefsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="metadataDef" maxOccurs="unbounded"> <xsd:element name="metadataDef" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
skipping to change at page 76, line 16 skipping to change at page 84, line 23
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="version" type="versionType"/> <xsd:element name="version" type="versionType"/>
<xsd:element name="derivedFrom" type="xsd:NMTOKEN" <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="inputPorts" type="inputPortsType" <xsd:element name="inputPorts" type="inputPortsType"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="outputPorts" type="outputPortsType" <xsd:element name="outputPorts" type="outputPortsType"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="attributes" type="LFBAttributesType" <xsd:element name="components" type="LFBComponentsType"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="capabilities" <xsd:element name="capabilities"
type="LFBCapabilitiesType" minOccurs="0"/> type="LFBCapabilitiesType" minOccurs="0"/>
<xsd:element name="events" <xsd:element name="events"
type="eventsType" minOccurs="0"/> type="eventsType" minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="LFBClassID" use="required" <xsd:attribute name="LFBClassID" use="required"
type="xsd:integer"/> type="xsd:integer"/>
</xsd:complexType> </xsd:complexType>
<!-- Key constraint to ensure unique attribute names within <!-- Key constraint to ensure unique attribute names within
a class: a class:
--> -->
<xsd:key name="attributes"> <xsd:key name="components">
<xsd:selector xpath="lfb:attributes/lfb:attribute"/> <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 <!-- does the above ensure that attributes and capabilities
have different names? have different names?
If so, the following is the elementID constraint If so, the following is the componentID constraint
--> -->
<xsd:key name="attributeIDs"> <xsd:key name="componentIDs">
<xsd:selector xpath="lfb:attributes/lfb:attribute"/> <xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="@elementID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
<xsd:key name="capabilityIDs"> <xsd:key name="capabilityIDs">
<xsd:selector xpath="lfb:attributes/lfb:capability"/> <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
<xsd:field xpath="@elementID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:simpleType name="versionType"> <xsd:simpleType name="versionType">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/> <xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:complexType name="inputPortsType"> <xsd:complexType name="inputPortsType">
skipping to change at page 80, line 4 skipping to change at page 88, line 15
<xsd:simpleType> <xsd:simpleType>
<xsd:restriction base="xsd:string"> <xsd:restriction base="xsd:string">
<xsd:enumeration value="unconditional"/> <xsd:enumeration value="unconditional"/>
<xsd:enumeration value="conditional"/> <xsd:enumeration value="conditional"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
</xsd:extension> </xsd:extension>
</xsd:simpleContent> </xsd:simpleContent>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="LFBAttributesType"> <xsd:complexType name="LFBComponentsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="attribute" maxOccurs="unbounded"> <xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/> <xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
<xsd:element name="defaultValue" type="xsd:token" <xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/> minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="access" use="optional" <xsd:attribute name="access" use="optional"
default="read-write"> default="read-write">
<xsd:simpleType> <xsd:simpleType>
<xsd:list itemType="accessModeType"/> <xsd:list itemType="accessModeType"/>
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
<xsd:attribute name="elementID" use="required" <xsd:attribute name="componentID" use="required"
type="xsd:integer"/> type="xsd:integer"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:simpleType name="accessModeType"> <xsd:simpleType name="accessModeType">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="read-only"/> <xsd:enumeration value="read-only"/>
<xsd:enumeration value="read-write"/> <xsd:enumeration value="read-write"/>
<xsd:enumeration value="write-only"/> <xsd:enumeration value="write-only"/>
skipping to change at page 80, line 49 skipping to change at page 89, line 12
<xsd:sequence> <xsd:sequence>
<xsd:element name="capability" maxOccurs="unbounded"> <xsd:element name="capability" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/> <xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="elementID" use="required" <xsd:attribute name="componentID" use="required"
type="xsd:integer"/> type="xsd:integer"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="eventsType"> <xsd:complexType name="eventsType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="event" maxOccurs="unbounded"> <xsd:element name="event" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
skipping to change at page 82, line 17 skipping to change at page 90, line 29
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:simpleType name="booleanType"> <xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string"> <xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/> <xsd:enumeration value="0"/>
<xsd:enumeration value="1"/> <xsd:enumeration value="1"/>
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
5. FE Attributes and Capabilities 5. FE Components and Capabilities
A ForCES forwarding element handles traffic on behalf of a ForCES A ForCES forwarding element handles traffic on behalf of a ForCES
control element. While the standards will describe the protocol and control element. While the standards will describe the protocol and
mechanisms for this control, different implementations and different mechanisms for this control, different implementations and different
instances will have different capabilities. The CE MUST be able to instances will have different capabilities. The CE MUST be able to
determine what each instance it is responsible for is actually determine what each instance it is responsible for is actually
capable of doing. As stated previously, this is an approximation. capable of doing. As stated previously, this is an approximation.
The CE is expected to be prepared to cope with errors in requests The CE is expected to be prepared to cope with errors in requests and
and variations in detail not captured by the capabilities variations in detail not captured by the capabilities information
information about an FE. about an FE.
In addition to its capabilities, an FE will have attribute In addition to its capabilities, an FE will have information that can
information that can be used in understanding and controlling the be used in understanding and controlling the forwarding operations.
forwarding operations. Some of the attributes will be read only, Some of this information will be read only, while others parts may
while others will also be writeable. also be writeable.
In order to make the FE attribute information easily accessible, the In order to make the FE information easily accessible, the
information will be stored in an LFB. This LFB will have a class, information is represented in an LFB. This LFB has a class,
FEObject. The LFBClassID for this class is 1. Only one instance of FEObject. The LFBClassID for this class is 1. Only one instance of
this class will ever be present, and the instance ID of that this class will ever be present, and the instance ID of that instance
instance in the protocol is 1. Thus, by referencing the elements of in the protocol is 1. Thus, by referencing the components of
class:1, instance:1 a CE can get all the information about the FE. class:1, instance:1 a CE can get the general information about the
For model completeness, this LFB Class is described in this section. FE. The FEObject LFB Class is described in this section.
There will also be an FEProtocol LFB Class. LFBClassID 2 is There will also be an FEProtocol LFB Class. LFBClassID 2 is reserved
reserved for that class. There will be only one instance of that for that class. There will be only one instance of that class as
class as well. Details of that class are defined in the ForCES well. Details of that class are defined in the ForCES protocol
protocol document. document.
5.1. XML for FEObject Class definition 5.1. XML for FEObject Class definition
<?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="http://ietf.org/forces/1.0/lfbmodel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ietf.org/forces/1.0/lfbmodel.xsd" xsi:schemaLocation="http://ietf.org/forces/1.0/lfbmodel.xsd"
provides="FEObject"> provides="FEObject">
<!-- - - xmlns and schemaLocation need to be fixed --> <!-- xmlns and schemaLocation need to be fixed -->
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>LFBAdjacencyLimitType</name> <name>LFBAdjacencyLimitType</name>
<synopsis>Describing the Adjacent LFB</synopsis> <synopsis>Describing the Adjacent LFB</synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>NeighborLFB</name> <name>NeighborLFB</name>
<synopsis>ID for that LFB Class</synopsis> <synopsis>ID for that LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>ViaPorts</name> <name>ViaPorts</name>
<synopsis> <synopsis>
the ports on which we can connect the ports on which we can connect
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>string</typeRef> <typeRef>string</typeRef>
</array> </array>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>PortGroupLimitType</name> <name>PortGroupLimitType</name>
<synopsis> <synopsis>
Limits on the number of ports in a given group Limits on the number of ports in a given group
</synopsis> </synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>PortGroupName</name> <name>PortGroupName</name>
<synopsis>Group Name</synopsis> <synopsis>Group Name</synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>MinPortCount</name> <name>MinPortCount</name>
<synopsis>Minimum Port Count</synopsis> <synopsis>Minimum Port Count</synopsis>
<optional/> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID="3"> <component componentID="3">
<name>MaxPortCount</name> <name>MaxPortCount</name>
<synopsis>Max Port Count</synopsis> <synopsis>Max Port Count</synopsis>
<optional/> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>SupportedLFBType</name> <name>SupportedLFBType</name>
<synopsis>table entry for supported LFB</synopsis> <synopsis>table entry for supported LFB</synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>LFBName</name> <name>LFBName</name>
<synopsis> <synopsis>
The name of a supported LFB Class The name of a supported LFB Class
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>LFBClassID</name> <name>LFBClassID</name>
<synopsis>the id of a supported LFB Class</synopsis> <synopsis>the id of a supported LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID=’’3’’> <component componentID=??3??>
<name>LFBVersion</name> <name>LFBVersion</name>
<synopsis> <synopsis>
The version of the LFB Class used The version of the LFB Class used
by this FE. by this FE.
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
<element elementID="4"> <component componentID="4">
<name>LFBOccurrenceLimit</name> <name>LFBOccurrenceLimit</name>
<synopsis> <synopsis>
the upper limit of instances of LFBs of this class the upper limit of instances of LFBs of this class
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<!-- For each port group, how many ports can exist <!-- For each port group, how many ports can exist
--> -->
<element elementID="5"> <component componentID="5">
<name>PortGroupLimits</name> <name>PortGroupLimits</name>
<synopsis>Table of Port Group Limits</synopsis> <synopsis>Table of Port Group Limits</synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>PortGroupLimitType</typeRef> <typeRef>PortGroupLimitType</typeRef>
</array> </array>
</element> </component>
<!-- for the named LFB Class, the LFB Classes it may follow --> <!-- for the named LFB Class, the LFB Classes it may follow -->
<element elementID="6"> <component componentID="6">
<name>CanOccurAfters</name> <name>CanOccurAfters</name>
<synopsis> <synopsis>
List of LFB Classes that this LFB class can follow List of LFB Classes that this LFB class can follow
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef> <typeRef>LFBAdjacencyLimitType</typeRef>
</array> </array>
</element> </component>
<!-- for the named LFB Class, the LFB Classes that may follow it <!-- for the named LFB Class, the LFB Classes that may follow it
--> -->
<element elementID="7"> <component componentID="7">
<name>CanOccurBefores</name> <name>CanOccurBefores</name>
<synopsis> <synopsis>
List of LFB Classes that can follow this LFB class List of LFB Classes that can follow this LFB class
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef> <typeRef>LFBAdjacencyLimitType</typeRef>
</array> </array>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEStatusValues</name> <name>FEStatusValues</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>
<specialValue value="0"> <specialValue value="0">
<name>AdminDisable</name> <name>AdminDisable</name>
skipping to change at page 85, line 47 skipping to change at page 94, line 16
<name>OperEnable</name> <name>OperEnable</name>
<synopsis>FE is operating</synopsis> <synopsis>FE is operating</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEConfiguredNeighborType</name> <name>FEConfiguredNeighborType</name>
<synopsis>Details of the FE's Neighbor</synopsis> <synopsis>Details of the FE's Neighbor</synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>NeighborID</name> <name>NeighborID</name>
<synopsis>Neighbors FEID</synopsis> <synopsis>Neighbors FEID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>InterfaceToNeighbor</name> <name>InterfaceToNeighbor</name>
<synopsis> <synopsis>
FE's interface that connects to this neighbor FE's interface that connects to this neighbor
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </component>
<element elementID=’’3’’> <component componentID=??3??>
<name>NeighborInterface</name> <name>NeighborInterface</name>
<synopsis> <synopsis>
The name of the interface on the neighbor to The name of the interface on the neighbor to
which this FE is adjacent. This is required which this FE is adjacent. This is required
In case two FE’s are adjacent on more than In case two FE?s are adjacent on more than
one interface. one interface.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>LFBSelectorType</name> <name>LFBSelectorType</name>
<synopsis> <synopsis>
Unique identification of an LFB class-instance Unique identification of an LFB class-instance
</synopsis> </synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>LFBClassID</name> <name>LFBClassID</name>
<synopsis>LFB Class Identifier</synopsis> <synopsis>LFB Class Identifier</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>LFBInstanceID</name> <name>LFBInstanceID</name>
<synopsis>LFB Instance ID</synopsis> <synopsis>LFB Instance ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>LFBLinkType</name> <name>LFBLinkType</name>
<synopsis> <synopsis>
Link between two LFB instances of topology Link between two LFB instances of topology
</synopsis> </synopsis>
<struct> <struct>
<element elementID="1"> <component componentID="1">
<name>FromLFBID</name> <name>FromLFBID</name>
<synopsis>LFB src</synopsis> <synopsis>LFB src</synopsis>
<typeRef>LFBSelectorType</typeRef> <typeRef>LFBSelectorType</typeRef>
</element> </component>
<element elementID="2"> <component componentID="2">
<name>FromPortGroup</name> <name>FromPortGroup</name>
<synopsis>src port group</synopsis> <synopsis>src port group</synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </component>
<element elementID="3"> <component componentID="3">
<name>FromPortIndex</name> <name>FromPortIndex</name>
<synopsis>src port index</synopsis> <synopsis>src port index</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
<element elementID="4"> <component componentID="4">
<name>ToLFBID</name> <name>ToLFBID</name>
<synopsis>dst LFBID</synopsis> <synopsis>dst LFBID</synopsis>
<typeRef>LFBSelectorType</typeRef> <typeRef>LFBSelectorType</typeRef>
</element> </component>
<element elementID="5"> <component componentID="5">
<name>ToPortGroup</name> <name>ToPortGroup</name>
<synopsis>dst port group</synopsis> <synopsis>dst port group</synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </component>
<element elementID="6"> <component componentID="6">
<name>ToPortIndex</name> <name>ToPortIndex</name>
<synopsis>dst port index</synopsis> <synopsis>dst port index</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="1"> <LFBClassDef LFBClassID="1">
<name>FEObject</name> <name>FEObject</name>
<synopsis>Core LFB: FE Object</synopsis> <synopsis>Core LFB: FE Object</synopsis>
<version>1.0</version> <version>1.0</version>
<attributes> <components>
<attribute access="read-write" elementID="1"> <component access="read-write" componentID="1">
<name>LFBTopology</name> <name>LFBTopology</name>
<synopsis>the table of known Topologies</synopsis> <synopsis>the table of known Topologies</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBLinkType</typeRef> <typeRef>LFBLinkType</typeRef>
</array> </array>
</attribute> </component>
<attribute access="read-write" elementID="2"> <component access="read-write" componentID="2">
<name>LFBSelectors</name> <name>LFBSelectors</name>
<synopsis> <synopsis>
table of known active LFB classes and table of known active LFB classes and
instances instances
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBSelectorType</typeRef> <typeRef>LFBSelectorType</typeRef>
</array> </array>
</attribute> </component>
<attribute access="read-write" elementID="3"> <component access="read-write" componentID="3">
<name>FEName</name> <name>FEName</name>
<synopsis>name of this FE</synopsis> <synopsis>name of this FE</synopsis>
<typeRef>string[40]</typeRef> <typeRef>string[40]</typeRef>
</attribute> </component>
<attribute access="read-write" elementID="4"> <component access="read-write" componentID="4">
<name>FEID</name> <name>FEID</name>
<synopsis>ID of this FE</synopsis> <synopsis>ID of this FE</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
<attribute access="read-only" elementID="5"> <component access="read-only" componentID="5">
<name>FEVendor</name> <name>FEVendor</name>
<synopsis>vendor of this FE</synopsis> <synopsis>vendor of this FE</synopsis>
<typeRef>string[40]</typeRef> <typeRef>string[40]</typeRef>
</attribute> </component>
<attribute access="read-only" elementID="6"> <component access="read-only" componentID="6">
<name>FEModel</name> <name>FEModel</name>
<synopsis>model of this FE</synopsis> <synopsis>model of this FE</synopsis>
<typeRef>string[40]</typeRef> <typeRef>string[40]</typeRef>
</attribute> </component>
<attribute access="read-only" elementID="7"> <component access="read-only" componentID="7">
<name>FEState</name> <name>FEState</name>
<synopsis>model of this FE</synopsis> <synopsis>model of this FE</synopsis>
<typeRef>FEStatusValues</typeRef> <typeRef>FEStatusValues</typeRef>
</attribute> </component>
<attribute access="read-write" elementID="8"> <component access="read-write" componentID="8">
<name>FENeighbors</name> <name>FENeighbors</name>
<synopsis>table of known neighbors</synopsis> <synopsis>table of known neighbors</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>FEConfiguredNeighborType</typeRef> <typeRef>FEConfiguredNeighborType</typeRef>
</array> </array>
</attribute> </component>
</attributes> </components>
<capabilities> <capabilities>
<capability elementID="30"> <capability componentID="30">
<name>ModifiableLFBTopology</name> <name>ModifiableLFBTopology</name>
<synopsis> <synopsis>
Whether Modifiable LFB is supported Whether Modifiable LFB is supported
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
</capability> </capability>
<capability elementID="31"> <capability componentID="31">
<name>SupportedLFBs</name> <name>SupportedLFBs</name>
<synopsis>List of all supported LFBs</synopsis> <synopsis>List of all supported LFBs</synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>SupportedLFBType</typeRef> <typeRef>SupportedLFBType</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
5.2. FE Capabilities 5.2. FE Capabilities
The FE Capability information is contained in the capabilities The FE Capability information is contained in the capabilities
element of the class definition. As described elsewhere, capability element of the class definition. As described elsewhere, capability
information is always considered to be read-only. information is always considered to be read-only.
The currently defined capabilities are ModifiableLFBTopology and The currently defined capabilities are ModifiableLFBTopology and
SupportedLFBs. Information as to which attributes of the FE LFB are SupportedLFBs. Information as to which components of the FEObject
supported is accessed by the properties information for those LFB are supported is accessed by the properties information for those
elements. components.
5.2.1. ModifiableLFBTopology 5.2.1. ModifiableLFBTopology
This element has a boolean value that indicates whether the LFB This component has a boolean value that indicates whether the LFB
topology of the FE may be changed by the CE. If the element is topology of the FE may be changed by the CE. If the component is
absent, the default value is assumed to be true, and the CE presumes absent, the default value is assumed to be true, and the CE presumes
the LFB topology may be changed. If the value is present and set to the LFB topology may be changed. If the value is present and set to
false, the LFB topology of the FE is fixed. If the topology is false, the LFB topology of the FE is fixed. If the topology is
fixed, the LFBs supported clause may be omitted, and the list of fixed, the LFBs supported clause may be omitted, and the list of
supported LFBs is inferred by the CE from the LFB topology supported LFBs is inferred by the CE from the LFB topology
information. If the list of supported LFBs is provided when information. If the list of supported LFBs is provided when
ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter
information should be omitted. information should be omitted.
5.2.2. SupportedLFBs and SupportedLFBType 5.2.2. SupportedLFBs and SupportedLFBType
One capability that the FE should include is the list of supported One capability that the FE should include is the list of supported
LFB classes. The SupportedLFBs element, is an array that contains LFB classes. The SupportedLFBs component, is an array that contains
the information about each supported LFB Class. The array structure the information about each supported LFB Class. The array structure
type is defined as the SupportedLFBType dataTypeDef. type is defined as the SupportedLFBType dataTypeDef.
Each occurrence of the SupportedLFBs array element describes an LFB Each entry in the SupportedLFBs array describes an LFB class that the
class that the FE supports. In addition to indicating that the FE FE supports. In addition to indicating that the FE supports the
supports the class, FEs with modifiable LFB topology should include class, FEs with modifiable LFB topology SHOULD include information
information about how LFBs of the specified class may be connected about how LFBs of the specified class may be connected to other LFBs.
to other LFBs. This information should describe which LFB classes This information SHOULD describe which LFB classes the specified LFB
the specified LFB class may succeed or precede in the LFB topology. class may succeed or precede in the LFB topology. The FE SHOULD
The FE should include information as to which port groups may be include information as to which port groups may be connected to the
connected to the given adjacent LFB class. If port group given adjacent LFB class. If port group information is omitted, it
information is omitted, it is assumed that all port groups may be is assumed that all port groups may be used. This capability
used. information on the acceptable ordering and connection of LFBs MAY be
omitted if the implementor concludes that the actual constraints are
such that the information would be misleading for the CE.
5.2.2.1. LFBName 5.2.2.1. LFBName
This element has as its value the name of the LFB Class being This component has as its value the name of the LFB Class being
described. described.
5.2.2.2. LFBClassID 5.2.2.2. LFBClassID
The numeric ID of the LFB Class being described. While conceptually The numeric ID of the LFB Class being described. While conceptually
redundant with the LFB Name, both are included for clarity and to redundant with the LFB Name, both are included for clarity and to
allow consistency checking. allow consistency checking.
5.2.2.3. LFBVersion 5.2.2.3. LFBVersion
The version string specifying the LFB Class version supported by The version string specifying the LFB Class version supported by this
this FE. As described above in versioning, an FE can support only a FE. As described above in versioning, an FE can support only a
single version of a given LFB Class. single version of a given LFB Class.
5.2.2.4. LFBOccurrenceLimit 5.2.2.4. LFBOccurrenceLimit
This element, if present, indicates the largest number of instances This component, if present, indicates the largest number of instances
of this LFB class the FE can support. For FEs that do not have the of this LFB class the FE can support. For FEs that do not have the
capability to create or destroy LFB instances, this can either be capability to create or destroy LFB instances, this can either be
omitted or be the same as the number of LFB instances of this class omitted or be the same as the number of LFB instances of this class
contained in the LFB list attribute. contained in the LFB list attribute.