draft-ietf-forces-model-14.txt   draft-ietf-forces-model-15.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Intended status: Standards Track J. Hadi Salim Intended status: Standards Track J. Hadi Salim
Expires: February 25, 2009 Znyx Networks Expires: March 15, 2009 Znyx Networks
August 24, 2008 September 11, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-14.txt draft-ietf-forces-model-15.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2009. This Internet-Draft will expire on March 15, 2009.
Comments are solicited and should be addressed to the working group's Comments are solicited and should be addressed to the working group's
mailing list at forces@peach.ease.lsoft.com and/or the author(s). mailing list at forces@peach.ease.lsoft.com and/or the author(s).
Abstract Abstract
This document defines the forwarding element (FE) model used in the This document defines the forwarding element (FE) model used in the
Forwarding and Control Element Separation (ForCES) protocol [2]. The Forwarding and Control Element Separation (ForCES) protocol [2]. The
model represents the capabilities, state and configuration of model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so forwarding elements within the context of the ForCES protocol, so
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31 3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31
3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32 3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32
3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32 3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32
3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36 3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36
4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40 4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40
4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41 4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41
4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 43 4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 43
4.4. <frameDefs> Element for Frame Type Declarations . . . . . 44 4.4. <frameDefs> Element for Frame Type Declarations . . . . . 44
4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44 4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44
4.5.1. <typeRef> Element for Renaming Existing Data Types . 47 4.5.1. <typeRef> Element for Renaming Existing Data Types . 48
4.5.2. <atomic> Element for Deriving New Atomic Types . . . 48 4.5.2. <atomic> Element for Deriving New Atomic Types . . . 48
4.5.3. <array> Element to Define Arrays . . . . . . . . . . 49 4.5.3. <array> Element to Define Arrays . . . . . . . . . . 49
4.5.4. <struct> Element to Define Structures . . . . . . . . 53 4.5.4. <struct> Element to Define Structures . . . . . . . . 53
4.5.5. <union> Element to Define Union Types . . . . . . . . 54 4.5.5. <union> Element to Define Union Types . . . . . . . . 55
4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 55 4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 55
4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 55 4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 56
4.6. <metadataDefs> Element for Metadata Definitions . . . . . 56 4.6. <metadataDefs> Element for Metadata Definitions . . . . . 57
4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 57 4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 58
4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 60 4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 61
4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 60 4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 61
4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 62 4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 64
4.7.4. <components> Element to Define LFB Operational 4.7.4. <components> Element to Define LFB Operational
Components . . . . . . . . . . . . . . . . . . . . . 65 Components . . . . . . . . . . . . . . . . . . . . . 66
4.7.5. <capabilities> Element to Define LFB Capability 4.7.5. <capabilities> Element to Define LFB Capability
Components . . . . . . . . . . . . . . . . . . . . . 68 Components . . . . . . . . . . . . . . . . . . . . . 69
4.7.6. <events> Element for LFB Notification Generation . . 69 4.7.6. <events> Element for LFB Notification Generation . . 70
4.7.7. <description> Element for LFB Operational 4.7.7. <description> Element for LFB Operational
Specification . . . . . . . . . . . . . . . . . . . . 76 Specification . . . . . . . . . . . . . . . . . . . . 77
4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 76 4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 77
4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 77 4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 78
4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 79 4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 80
4.8.3. String Properties . . . . . . . . . . . . . . . . . . 79 4.8.3. String Properties . . . . . . . . . . . . . . . . . . 80
4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 80 4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 81
4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 81 4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 82
4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 84 4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 85
4.9. XML Schema for LFB Class Library Documents . . . . . . . 85 4.9. XML Schema for LFB Class Library Documents . . . . . . . 86
5. FE Components and Capabilities . . . . . . . . . . . . . . . 96 5. FE Components and Capabilities . . . . . . . . . . . . . . . 97
5.1. XML for FEObject Class definition . . . . . . . . . . . . 97 5.1. XML for FEObject Class definition . . . . . . . . . . . . 98
5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 103 5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 104
5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 104 5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 105
5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 104 5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 105
5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 107 5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 108
5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 107 5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 108
5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 107 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 108
5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 108 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 109
5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 108 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 109
6. Satisfying the Requirements on FE Model . . . . . . . . . . . 109 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 110
7. Using the FE model in the ForCES Protocol . . . . . . . . . . 110 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 111
7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 112 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 113
7.2. FE Capability Declarations . . . . . . . . . . . . . . . 113 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 114
7.3. LFB Topology and Topology Configurability Query . . . . . 114 7.3. LFB Topology and Topology Configurability Query . . . . . 114
7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 114 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 114
7.5. State Query of LFB Components . . . . . . . . . . . . . . 115 7.5. State Query of LFB Components . . . . . . . . . . . . . . 116
7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 116 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 116
7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 116 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 116
8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 116 8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 117
8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 123 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 124
8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 124 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 125
8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 125 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 125
8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 125 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 126
8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 126 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 126
8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 126 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 127
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 127 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128
9.1. URN Namespace Registration . . . . . . . . . . . . . . . 127 9.1. URN Namespace Registration . . . . . . . . . . . . . . . 128
9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 128 9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 128
10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 129 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 129
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 129 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130
12. Security Considerations . . . . . . . . . . . . . . . . . . . 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 130
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.1. Normative References . . . . . . . . . . . . . . . . . . 130 13.1. Normative References . . . . . . . . . . . . . . . . . . 130
13.2. Informative References . . . . . . . . . . . . . . . . . 130 13.2. Informative References . . . . . . . . . . . . . . . . . 130
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131
Intellectual Property and Copyright Statements . . . . . . . . . 132 Intellectual Property and Copyright Statements . . . . . . . . . 132
1. Definitions 1. Definitions
The use of compliance terminology (MUST, SHOULD, MAY) is used in The use of compliance terminology (MUST, SHOULD, MAY) is used in
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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 [2]. exchanged between the CE and the FE in the ForCES Protocol [2].
Datapath -- A conceptual path taken by packets within the forwarding Datapath -- A conceptual path taken by packets within the forwarding
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 represents 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 LFB instance of a specific LFB class. Multiple instances of the same LFB
class can be present in an FE's datapath. Note that we often refer class can be present in an FE's datapath. Note that we often refer
to LFBs without distinguishing between an LFB class and LFB instance to LFBs without distinguishing between an LFB class and LFB instance
when we believe the implied reference is obvious for the given when we believe the implied reference is obvious for the given
context. context.
LFB Model -- The LFB model describes the content and structures in an LFB Model -- The LFB model describes the content and structures in an
LFB, plus the associated data definition. XML is used to provide a LFB, plus the associated data definition. XML is used to provide a
formal definition of the necessary structures for the modeling. Four formal definition of the necessary structures for the modeling. Four
types of information are defined in the LFB model. The core part of types of information are defined in the LFB model. The core part of
the LFB model is the LFB class definitions; the other three types of the LFB model is the LFB class definitions; the other three types of
information define constructs associated with and used by the class information define constructs associated with and used by the class
definition. These are reusable data types, supported frame formats, definition. These are reusable data types, supported frame (packet)
and metadata. formats, and metadata.
Element -- Element is generally used in this document in accordance 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 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 an XML document. For a precise definition, please see the full set
of XML specifications from the W3C. This term is included in this of XML specifications from the W3C. This term is included in this
list for completeness because ForCES formal model uses XML. list for completeness because the ForCES formal model uses XML.
Attribute -- Attribute is used in the ForCES formal modelling in Attribute -- Attribute is used in the ForCES formal modelling in
accordance with standard XML usage of the term. i.e to provide accordance with standard XML usage of the term. i.e, to provide
attribute information include in an XML tag. attribute information include in an XML tag.
LFB Metadata -- Metadata is used to communicate per-packet state from LFB Metadata -- Metadata is used to communicate per-packet state from
one LFB to another, but is not sent across the network. The FE model one LFB to another, but is not sent across the network. The FE model
defines how such metadata is identified, produced and consumed by the defines how such metadata is identified, produced and consumed by the
LFBs, but not how the per-packet state is implemented within actual LFBs, but not how the per-packet state is implemented within actual
hardware. Metadata is sent between the FE and the CE on redirect hardware. Metadata is sent between the FE and the CE on redirect
packets. packets.
ForCES Component -- a ForCES Component is a well defined, uniquely ForCES Component -- a ForCES Component is a well-defined, uniquely
identifiable and addressable ForCES model building block. A identifiable and addressable ForCES model building block. A
component has a 32-bit ID, name, type and an optional synopsis component has a 32-bit ID, name, type and an optional synopsis
description. These are often referred to simply as components. description. These are often referred to simply as components.
LFB Component -- A ForCES component that defines the Operational LFB Component -- A ForCES component that defines the Operational
parameters of the LFBs that must be visible to the CEs. parameters of the LFBs that must be visible to the CEs.
Structure Component -- A ForCES component that is part of a complex Structure Component -- A ForCES component that is part of a complex
data structure to be used in LFB data definitions. The individual data structure to be used in LFB data definitions. The individual
parts which make up a structured set of data are referred to as parts which make up a structured set of data are referred to as
skipping to change at page 6, line 46 skipping to change at page 6, line 46
(or, where appropriate, writing.) Details on the ForCES properties (or, where appropriate, writing.) Details on the ForCES properties
are found in section 4.8. are found in section 4.8.
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 the distinguished from inter-FE topology. LFB topology is outside of 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 (Network Element) are interconnected. Sometimes this is called
to be distinguished from intra-FE topology (i.e., LFB topology). An inter-FE topology, to be distinguished from intra-FE topology (i.e.,
individual FE might not have the global knowledge of the full FE LFB topology). An individual FE might not have the global knowledge
topology, but the local view of its connectivity with other FEs is of the full FE topology, but the local view of its connectivity with
considered to be part of the FE model. The FE topology is discovered other FEs is considered to be part of the FE model. The FE topology
by the ForCES base protocol or by some other means. is discovered 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 as LFB class library -- A set of LFB classes that has been identified 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
skipping to change at page 8, line 42 skipping to change at page 8, line 42
metadata by subsequent LFBs in the topology graph; this is required metadata by subsequent LFBs in the topology graph; this is required
for logically consistent operation. Further, modification of packet for logically consistent operation. Further, modification of packet
fields that are subsequently used as inputs for further processing fields that are subsequently used as inputs for further processing
MUST occur in the order specified in the model for that particular MUST occur in the order specified in the model for that 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 [2] is used by the CEs and FEs to maintain The ForCES base Protocol [2] is used by the CEs and FEs to maintain
the communication channel between the CEs and FEs. The ForCES the communication channel between the CEs and FEs. The ForCES
protocol may be used to query and discover the inter-FE topology. protocol may be used to query and discover the intra-FE topology.
The details of a particular datapath implementation inside an FE, The details of a particular datapath implementation inside an FE,
including the LFB topology, along with the operational capabilities including the LFB topology, along with the operational capabilities
and attributes of each individual LFB, are conveyed to the CE within and attributes of each individual LFB, are conveyed to the CE within
information elements in the ForCES protocol. The model of an LFB information elements in the ForCES protocol. The model of an LFB
class should define all of the information that needs to be exchanged class should define all of the information that needs to be exchanged
between an FE and a CE for the proper configuration and management of between an FE and a CE for the proper configuration and management of
that LFB. 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
skipping to change at page 9, line 38 skipping to change at page 9, line 38
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 is chosen as the specification language in this document, because XML is chosen as the specification language in this document, because
XML has the advantage of being both human and machine readable with XML has the advantage of being both human and machine readable with
widely available tools support. This document uses XML Schema to widely available tools support. This document uses an XML Schema to
define the structure of the LFB Library documents, as defined in [9] define the structure of the LFB Library documents, as defined in [9]
and [10] and [11]. While these LFB Class definitions are not sent in and [10] and [11]. While these LFB Class definitions are not sent in
the ForCES protocol, these definitions comply with the the ForCES protocol, these definitions comply with the
recommendations in RFC3470 [9] on the use of XML in IETF protocols. recommendations in RFC3470 [9] on the use of XML in IETF 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 the foundation for the more detailed discussion and specifications in the
sections that follow. Section 4 and Section 5 constitute the core of sections that follow. Section 4 and Section 5 constitute the core of
skipping to change at page 10, line 25 skipping to change at page 10, line 25
aspects are described in Section 4 and Section 5. The intent of this aspects are described in Section 4 and Section 5. The intent of this
section is to discuss these concepts at the high level and lay the section is to discuss these concepts at the high level and lay the
foundation for the detailed description in the following sections. foundation for the detailed description in the following sections.
The ForCES FE model includes both a capability and a state The ForCES FE model includes both a capability and a state
abstraction. abstraction.
o The FE/LFB capability model describes the capabilities and o The FE/LFB capability model describes the capabilities and
capacities of an FE/LFB by specifying the variation in functions capacities of an FE/LFB by specifying the variation in functions
supported and any limitations. Capacity describes the limits of supported and any limitations. Capacity describes the limits of
specific components (example would be a table size limit). specific components (an example would be a table size limit).
o The state model describes the current state of the FE/LFB, that o The state model describes the current state of the FE/LFB, that
is, the instantaneous values or operational behavior of the FE/ is, the instantaneous values or operational behavior of the FE/
LFB. LFB.
Section 3.1 explains the difference between a capability model and a Section 3.1 explains the difference between a capability model and a
state model, and describes how the two can be combined in the FE state model, and describes how the two can be combined in the FE
model. model.
The ForCES model construction laid out in this document allows an FE The ForCES model construction laid out in this document allows an FE
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Section 3.2 introduces the concept of LFBs as the basic functional Section 3.2 introduces the concept of LFBs as the basic functional
building blocks in the ForCES model. building blocks in the ForCES model.
o The FE model also provides the construction necessary to monitor o The FE model also provides the construction necessary to monitor
and control the FE as a whole for ForCES purposes. For and control the FE as a whole for ForCES purposes. For
consistency of operation and simplicity, this information is consistency of operation and simplicity, this information is
represented as an LFB, the FE Object LFB class and a singular LFB represented as an LFB, the FE Object LFB class and a singular LFB
instance of that class, defined using the LFB model. The FE instance of that class, defined using the LFB model. The FE
Object class defines the components to provide information at the Object class defines the components to provide information at the
FE level, particularly the capabilities of the FE at a coarse FE level, particularly the capabilities of the FE at a coarse
level, i.e. not all possible capabilities nor all details about level, i.e., not all possible capabilities nor all details about
the capabilities of the FE. Part of the FE level information is the capabilities of the FE. Part of the FE level information is
the LFB topology, which expresses the logical inter-connection the LFB topology, which expresses the logical inter-connection
between the LFB instances along the datapath(s) within the FE. between the LFB instances along the datapath(s) within the FE.
Section 3.3 discusses the LFB topology. The FE Object also Section 3.3 discusses the LFB topology. The FE Object also
includes information about what LFB classes the FE can support. includes information about what LFB classes the FE can support.
The ForCES model allows for unique identification of the different The ForCES model allows for unique identification of the different
constructs it defines. This includes identification of the LFB constructs it defines. This includes identification of the LFB
classes, and of LFB instances within those classes, as well as classes, and of LFB instances within those classes, as well as
identification of components within those instances. identification of components within those instances.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
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. FE.
3.1.1.1. FE Capability Model 3.1.1.1. FE Capability Model
The FE capability model may be used to describe an FE at a coarse The FE capability model may be used to describe an FE at a coarse
level. For example, an FE may be defined as follows: level. For example, an FE might be defined as follows:
o the FE can handle IPv4 and IPv6 forwarding; o the FE can handle IPv4 and IPv6 forwarding;
o the FE can perform classification based on the following fields: o the FE can perform classification based on the following fields:
source IP address, destination IP address, source port number, source IP address, destination IP address, source port number,
destination port number, etc; destination port number, etc.;
o the FE can perform metering; o the FE can perform metering;
o the FE can handle up to N queues (capacity); o the FE can handle up to N queues (capacity);
o the FE can add and remove encapsulating headers of types including o the FE can add and remove encapsulating headers of types including
IPsec, GRE, L2TP. IPsec, GRE, L2TP.
While one could try to build an object model to fully represent the While one could try to build an object model to fully represent the
FE capabilities, other efforts found this approach to be a FE capabilities, other efforts found this approach to be a
skipping to change at page 13, line 13 skipping to change at page 13, line 13
the FE model by combining coarse level capability reporting with an the FE model by combining coarse level capability reporting with an
error reporting mechanism. That is, if the CE attempts to instruct error reporting mechanism. That is, if the CE attempts to instruct
the FE to set up some specific behavior it cannot support, the FE the FE to set up some specific behavior it cannot support, the FE
will return an error indicating the problem. Examples of similar will return an error indicating the problem. Examples of similar
approaches include DiffServ PIB RFC3317 [6] and Framework PIB RFC3318 approaches include DiffServ PIB RFC3317 [6] and Framework PIB RFC3318
[7]. [7].
3.1.1.2. FE State Model 3.1.1.2. FE State 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 might be described to its
corresponding CE as the following: corresponding CE as the following:
o 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;
o the given classifier results in packets being metered in a certain o the given classifier results in packets being metered in a certain
way and then marked in a certain way; way and then marked in a certain way;
o the packets coming from specific markers are delivered into a o the packets coming from specific markers are delivered into a
shared queue for handling, while other packets are delivered to a shared queue for handling, while other packets are delivered to a
different queue; different queue;
o a specific scheduler with specific behavior and parameters will o a specific scheduler with specific behavior and parameters will
service these collected queues. service these collected queues.
3.1.1.3. LFB Capability and State Model 3.1.1.3. LFB Capability and State Model
Both LFB Capability and State information is defined formally using Both LFB Capability and State information are defined formally using
LFB modelling XML schema. the LFB modelling XML schema.
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 provides for powerful semantics. For example, when LFB model and provides for powerful semantics. For example, when
certain features of an LFB class are optional, the CE MUST be able to certain features of an LFB class are optional, the CE needs to be
determine whether those optional features are supported by a given able to determine whether those optional features are supported by a
LFB instance. The schema for the definition of LFB classes provides given LFB instance. The schema for the definition of LFB classes
a means for identifying such components. provides a means for identifying such components.
State information is defined formally using LFB components State information is defined formally using LFB component constructs.
constructs.
3.1.2. Relating LFB and FE Capability and State Model 3.1.2. Relating LFB and FE Capability and State Model
Capability information at the FE level describes the LFB classes that Capability information at the FE level describes the LFB classes that
the FE can instantiate, the number of instances of each that can be the FE can instantiate, the number of instances of each that can be
created, the topological (linkage) limitations between these LFB created, the topological (linkage) limitations between these LFB
instances, etc. Section 5 defines the FE level components including instances, etc. Section 5 defines the FE level components including
capability information. Since all information is represented as capability information. Since all information is represented as
LFBs, this is provided by a single instance of the FE Object LFB 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 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 instance identification, the ForCES protocol can allow a CE to access
this information whenever it needs to, including while the CE is this information whenever it needs to, including while the CE is
establishing the control of the FE. establishing the control of the FE.
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 the information can be represented at two levels. The first level is the
logically separable and distinct packet processing functions, called logically separable and distinct packet processing functions, called
LFBs. The second level of information describes how these individual LFBs. The second level of information describes how these individual
LFBs are ordered and placed along the datapath to deliver a complete LFBs are ordered and placed along the datapath to deliver a complete
forwarding plane service. The interconnection and ordering of the forwarding plane service. The interconnection and ordering of the
LFBs is called LFB Topology. Section 3.2 discusses high level LFBs is called LFB Topology. Section 3.2 discusses high level
concepts around LFBs, whereas Section 3.3 discusses LFB topology concepts around LFBs, whereas Section 3.3 discusses LFB topology
issues. This topology information is represented as components of issues. This topology information is represented as components of
the FE Object LFB instance, to allow the CE to fetch and manipulate the FE Object LFB instance, to allow the CE to fetch and manipulate
this. this.
skipping to change at page 14, line 38 skipping to change at page 14, line 37
action. Classifiers, shapers and meters are all examples of such action. Classifiers, shapers and meters are all examples of such
LFBs. Modeling LFBs at such a fine granularity allows us to use a LFBs. Modeling LFBs at such a fine granularity allows us to use a
small number of LFBs to express the higher-order FE functions (such small number of LFBs to express the higher-order FE functions (such
as an IPv4 forwarder) precisely, which in turn can describe more as an IPv4 forwarder) precisely, which in turn can describe more
complex networking functions and vendor implementations of software complex networking functions and vendor implementations of software
and hardware. These fine grained LFBs will be defined in detail in and hardware. These fine grained LFBs will be defined in detail in
one or more documents to be published separately, using the material one or more documents to be published separately, using the material
in this model. in this model.
It is also the case that LFBs may exist in order to provide a set of It is also the case that LFBs may exist in order to provide a set of
components for control of FE operation by the CE (i.e. a locus of components for control of FE operation by the CE (i.e., a locus of
control), without tying that control to specific packets or specific control), without tying that control to specific packets or specific
parts of the data path. An example of such an LFB is the FE Object parts of the data path. An example of such an LFB is the FE Object
which provides the CE with information about the FE as a whole, and which provides the CE with information about the FE as a whole, and
allows the FE to control some aspects of the FE, such as the datapath allows the FE to control some aspects of the FE, such as the datapath
itself. Such LFBs will not have the packet oriented properties itself. Such LFBs will not have the packet oriented properties
described in this section. described in this section.
In general, multiple LFBs are contained in one FE, as shown in In general, multiple LFBs are contained in one FE, as shown in
Figure 2, and all the LFBs share the same ForCES protocol termination Figure 2, and all the LFBs share the same ForCES protocol (Fp)
point that implements the ForCES protocol logic and maintains the termination point that implements the ForCES protocol logic and
communication channel to and from the CE. maintains the communication channel to and from the CE.
+-----------+ +-----------+
| CE | | CE |
+-----------+ +-----------+
^ ^
| Fp reference point | Fp reference point
| |
+--------------------------|-----------------------------------+ +--------------------------|-----------------------------------+
| FE | | | FE | |
| v | | v |
skipping to change at page 15, line 37 skipping to change at page 15, line 37
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 2: Generic LFB Diagram Figure 2: Generic LFB Diagram
An LFB, as shown in Figure 2, may have inputs, outputs and components An LFB, as shown in Figure 2, may have inputs, outputs and components
that can be queried and manipulated by the CE via an Fp reference that can be queried and manipulated by the CE via an Fp reference
point (defined in RFC3746 [5]) and the ForCES protocol termination point (defined in RFC3746 [5]) and the ForCES protocol termination
point. The horizontal axis is in the forwarding plane for connecting point. The horizontal axis is in the forwarding plane for connecting
the inputs and outputs of LFBs within the same FE. The vertical axis the inputs and outputs of LFBs within the same FE. P (with marks to
between the CE and the FE denotes the Fp reference point where indicate modification) indicates a data packet, while M (with marks
bidirectional communication between the CE and FE occurs: the CE to to indicate modification) indicates the metadata associated with a
FE communication is for configuration, control, and packet injection, packet. The vertical axis between the CE and the FE denotes the Fp
while FE to CE communication is used for packet redirection to the reference point where bidirectional communication between the CE and
control plane, reporting of monitoring and accounting information, FE occurs: the CE to FE communication is for configuration, control,
reporting of errors, etc. Note that the interaction between the CE and packet injection, while FE to CE communication is used for packet
and the LFB is only abstract and indirect. The result of such an redirection to the control plane, reporting of monitoring and
interaction is for the CE to manipulate the components of the LFB accounting information, reporting of errors, etc. Note that the
instances. interaction between the CE and the LFB is only abstract and indirect.
The result of such an interaction is for the CE to manipulate the
components of the LFB instances.
An LFB can have one or more inputs. Each input takes a pair of a An LFB can have one or more inputs. Each input takes a pair of a
packet and its associated metadata. Depending upon the LFB input packet and its associated metadata. Depending upon the LFB input
port definition, the packet or the metadata may be allowed to be port definition, the packet or the metadata may be allowed to be
empty (or equivalently to not be provided.) When input arrives at an empty (or equivalently to not be provided.) When input arrives at an
LFB, either the packet or its associated metadata must be non-empty LFB, either the packet or its associated metadata must be non-empty
or there is effectively no input. (LFB operation generally may be or there is effectively no input. (LFB operation generally may be
triggered by input arrival, by timers, or by other system state. It triggered by input arrival, by timers, or by other system state. It
is only in the case where the goal is to have input drive operation is only in the case where the goal is to have input drive operation
that the input must be non-empty.) that the input must be non-empty.)
skipping to change at page 16, line 23 skipping to change at page 16, line 25
absent.) Metadata attached to packets on output may be metadata that absent.) Metadata attached to packets on output may be metadata that
was received, or may be information about the packet processing that was received, or may be information about the packet processing that
may be used by later LFBs in the FEs packet processing. may be used by later LFBs in the FEs packet processing.
A namespace is used to associate a unique name and ID with each LFB A namespace is used to associate a unique name and ID with each LFB
class. The namespace MUST be extensible so that a new LFB class can class. The namespace MUST be extensible so that a new LFB class can
be added later to accommodate future innovation in the forwarding be added later to accommodate future innovation in the forwarding
plane. plane.
LFB operation is specified in the model to allow the CE to understand LFB operation is specified in the model to allow the CE to understand
the behavior of the forwarding datapath. For instance, the CE must the behavior of the forwarding datapath. For instance, the CE needs
understand at what point in the datapath the IPv4 header TTL is to understand at what point in the datapath the IPv4 header TTL is
decremented. That is, the CE needs to know if a control packet could decremented by the FE. That is, the CE needs to know if a control
be delivered to it either before or after this point in the datapath. packet could be delivered to it either before or after this point in
In addition, the CE MUST understand where and what type of header the datapath. In addition, the CE needs to understand where and what
modifications (e.g., tunnel header append or strip) are performed by type of header modifications (e.g., tunnel header append or strip)
the FEs. Further, the CE MUST verify that the various LFBs along a are performed by the FEs. Further, the CE works to verify that the
datapath within an FE are compatible to link together. various LFBs along a datapath within an FE are compatible to link
together. Connecting incompatible LFB instances will produce a non-
working data path. So the model is designed to provide sufficient
information for the CE to make this determination.
Selecting the right granularity for describing the functions of the Selecting the right granularity for describing the functions of the
LFBs is an important aspect of this model. There is value to vendors LFBs is an important aspect of this model. There is value to vendors
if the operation of LFB classes can be expressed in sufficient detail if the operation of LFB classes can be expressed in sufficient detail
so that physical devices implementing different LFB functions can be so that physical devices implementing different LFB functions can be
integrated easily into an FE design. However, the model, and the integrated easily into an FE design. However, the model, and the
associated library of LFBs, must not be so detailed and so specific associated library of LFBs, must not be so detailed and so specific
as to significantly constrain implementations. Therefore, a semi- as to significantly constrain implementations. Therefore, a semi-
formal specification is needed; that is, a text description of the formal specification is needed; that is, a text description of the
LFB operation (human readable), but sufficiently specific and LFB operation (human readable), but sufficiently specific and
skipping to change at page 17, line 40 skipping to change at page 17, line 47
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
information to another LFB. The information sent on that port is a information to another LFB. The information sent on that port is a
pair of a packet and associated metadata, one of which may be empty. pair of a packet and associated metadata, one of which may be empty.
(If both were empty, there would be no output.) (If both were empty, there would be no output.)
A single LFB output can be connected to only one LFB input. This is A single LFB output can be connected to only one LFB input. This is
required to make the packet flow through the LFB topology required to make the packet flow through the LFB topology
unambiguously. unambiguous.
Some LFBs will have a single output, as depicted in Figure 3.a. Some LFBs will have a single output, as depicted in Figure 3.a.
+---------------+ +-----------------+ +---------------+ +-----------------+
| | | | | | | |
| | | OUT +--> | | | OUT +-->
... OUT +--> ... | ... OUT +--> ... |
| | | EXCEPTIONOUT +--> | | | EXCEPTIONOUT +-->
| | | | | | | |
+---------------+ +-----------------+ +---------------+ +-----------------+
skipping to change at page 19, line 4 skipping to change at page 19, line 4
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 assumes LFB and each output carries different metadata. This concept assumes
the number of distinct outputs is known when the LFB class is the number of distinct outputs is known when the LFB class is
defined. For each singleton output, the LFB class definition defines defined. For each singleton output, the LFB class definition defines
the types of frames and metadata the output emits. the types of frames (packets) and metadata the output emits.
An output group, on the other hand, is used to model the case where a An output group, on the other hand, is used to model the case where a
flow of similar packets with an identical set of permitted metadata flow of similar packets with an identical set of permitted metadata
needs to be split into multiple paths. In this case, the number of needs to be split into multiple paths. In this case, the number of
such paths is not known when the LFB class is defined because it is such paths is not known when the LFB class is defined because it is
not an inherent property of the LFB class. An output group consists not an inherent property of the LFB class. An output group consists
of a number of outputs, called the output instances of the group, of a number of outputs, called the output instances of the group,
where all output instances share the same frame and metadata emission where all output instances share the same frame (packet) and metadata
definitions (see Figure 3.c). Each output instance can connect to a emission definitions (see Figure 3.c). Each output instance can
different downstream LFB, just as if they were separate singleton connect to a different downstream LFB, just as if they were separate
outputs, but the number of output instances can differ between LFB singleton outputs, but the number of output instances can differ
instances of the same LFB class. The class definition may include a between LFB instances of the same LFB class. The class definition
lower and/or an upper limit on the number of outputs. In addition, may include a lower and/or an upper limit on the number of outputs.
for configurable FEs, the FE capability information may define In addition, for configurable FEs, the FE capability information may
further limits on the number of instances in specific output groups define further limits on the number of instances in specific output
for certain LFBs. The actual number of output instances in a group groups for certain LFBs. The actual number of output instances in a
is an component of the LFB instance, which is read-only for static group is an component of the LFB instance, which is read-only for
topologies, and read-write for dynamic topologies. The output static 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. To use Output Port groups, the are addressable from within the LFB. To use Output Port groups, the
LFB has to have a built-in mechanism to select one specific output LFB has to have a built-in mechanism to select one specific output
instance for each packet. This mechanism is described in the textual instance for each packet. This mechanism is described in the textual
definition of the class and is typically configurable via some definition of the class and is typically configurable via some
attributes of the LFB. attributes of the LFB.
For example, consider a redirector LFB, whose sole purpose is to For example, consider a redirector 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 fairly metadata associated with each arriving packet. Such an LFB is fairly
versatile and can be used in many different places in a topology. versatile and can be used in many different places in a topology.
For example, a redirector can be used to divide the data path into an For example, given LFBs which record the type of packet in a
IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork FRAMETYPE metadatum, or a packet rate class in a COLOR metadatum, one
into color specific paths after metering using the COLOR metadata may uses these metadata for branching. A redirector can be used to
(red, yellow, green; N=3), etc. divide the data path into an IPv4 and an IPv6 path based on a
FRAMETYPE metadatum (N=2), or to fork into rate specific paths after
metering using the COLOR metadatum (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 the instance is a property of the LFB. For each packet, the value of 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 metadatum value to output instance. table that maps a metadatum 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
skipping to change at page 20, line 25 skipping to change at page 20, line 27
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 conditions for forking the datapath and at least one of the following conditions
hold: hold:
o the number of downstream directions is inherent from the o the number of downstream directions is inherent from the
definition of the class and hence fixed; definition of the class and hence fixed;
o the frame type and set of permitted metadata emitted on any of the o the frame type and set of permitted metadata emitted on any of the
outputs are different from what is emitted on the other outputs outputs are different from what is emitted on the other outputs
(i.e., they cannot share their frame-type and permitted metadata (i.e., they cannot share their frametype and permitted metadata
definitions). 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:
o 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;
o the frame type and set of metadata emitted on these outputs are o the frame type and set of metadata emitted on these outputs are
sufficiently similar or, ideally, identical, such they can share sufficiently similar or, ideally, identical, such they can share
skipping to change at page 21, line 4 skipping to change at page 21, line 6
receive information from other LFBs. The information is typically a receive information from other LFBs. The information is typically a
pair of a packet and its associated metadata. Either the packet, or pair of a packet and its associated metadata. Either the packet, or
the metadata, may for some LFBs and some situations be empty. They the metadata, may for some LFBs and some situations be empty. They
can not both be empty, as then there is no input. can not both be empty, as then there is no input.
For LFB instances that receive packets from more than one other LFB For LFB instances that receive packets from more than one other LFB
instance (fan-in) there are three ways to model fan-in, all supported instance (fan-in) there are three ways to model fan-in, all supported
by the LFB model and can all be combined in the same LFB: by the LFB model and can all be combined in the same LFB:
o Implicit multiplexing via a single input o Implicit multiplexing via a single input
o Explicit multiplexing via multiple singleton inputs o Explicit multiplexing via multiple singleton inputs
o Explicit multiplexing via a group of inputs (input group) o Explicit multiplexing via a group of inputs (input group)
The simplest form of multiplexing uses a singleton input (Figure 4 The simplest form of multiplexing uses a singleton input
.a). Most LFBs will have only one singleton input. Multiplexing (Figure 4.a). Most LFBs will have only one singleton input.
into a single input is possible because the model allows more than Multiplexing into a single input is possible because the model allows
one LFB output to connect to the same LFB input. This property more than one LFB output to connect to the same LFB input. This
applies to any LFB input without any special provisions in the LFB property applies to any LFB input without any special provisions in
class. Multiplexing into a single input is applicable when the the LFB class. Multiplexing into a single input is applicable when
packets from the upstream LFBs are similar in frame-type and the packets from the upstream LFBs are similar in frametype 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 needs multiple packets arrive simultaneously. If contention handling needs
to be explicitly modeled, one of the other two modeling solutions to be explicitly modeled, one of the other two modeling solutions
must be used. must be used.
The second method to model fan-in uses individually defined singleton The second method to model fan-in uses individually defined singleton
inputs (Figure 4.b). This model is meant for situations where the inputs (Figure 4.b). This model is meant for situations where the
LFB needs to handle distinct types of packet streams, requiring LFB needs to handle distinct types of packet streams, requiring
input-specific handling inside the LFB, and where the number of such input-specific handling inside the LFB, and where the number of such
distinct cases is known when the LFB class is defined. For example, distinct cases is known when the LFB class is defined. For example,
a Layer 2 Decapsulation/Encapsulation LFB may have two inputs, one an LFB which can perform both Layer 2 decapsulation (to Layer 3) and
for receiving Layer 2 frames for decapsulation, and one for receiving Layer 3 encapsulation (to Layer 2) may have two inputs, one for
receiving Layer 2 frames for decapsulation, and one for receiving
Layer 3 frames for encapsulation. This LFB type expects different Layer 3 frames for encapsulation. This LFB type expects different
frames (L2 vs. L3) at its inputs, each with different sets of frames (L2 vs. L3) at its inputs, each with different sets of
metadata, and would thus apply different processing on frames metadata, and would thus apply different processing on frames
arriving at these inputs. This model is capable of explicitly arriving at these inputs. This model is capable of explicitly
addressing packet contention by defining how the LFB class handles addressing packet contention by defining how the LFB class handles
the contending packets. the contending packets.
+--------------+ +------------------------+ +--------------+ +------------------------+
| LFB X +---+ | | | LFB X +---+ | |
+--------------+ | | | +--------------+ | | |
skipping to change at page 23, line 23 skipping to change at page 23, line 23
any compatible upstream LFB can connect its output to one of these any compatible upstream LFB can connect its output to one of these
inputs. When a packet is presented to the LFB at a particular input inputs. When a packet is presented to the LFB at a particular input
instance, the index of the input where the packet arrived is known to instance, the index of the input where the packet arrived is known to
the LFB and this information may be used in the internal processing. the LFB and this information may be used in the internal processing.
For example, the input index can be used as a table selector, or as For example, the input index can be used as a table selector, or as
an explicit precedence selector to resolve contention. As with an explicit precedence selector to resolve contention. As with
output groups, the number of input instances in an input group is not output groups, the number of input instances in an input group is not
defined in the LFB class. However, the class definition may include defined in the LFB class. However, the class definition may include
restrictions on the range of possible values. In addition, if an FE restrictions on the range of possible values. In addition, if an FE
supports configurable topologies, it may impose further limitations supports configurable topologies, it may impose further limitations
on the number of instances for a particular port group(s) of a on the number of instances for particular port group(s) of a
particular LFB class. Within these limitations, different instances particular LFB class. Within these limitations, different instances
of the same class may have a different number of input instances. of the same class may have a different number of input instances.
The number of actual input instances in the group is a component The number of actual input instances in the group is a component
defined in the LFB class, which is read-only for static topologies, defined in the LFB class, which is read-only for static topologies,
and is read-write for configurable topologies. and is read-write for 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 4.c. Such an LFB receives packets from a number depicted in Figure 4.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.
skipping to change at page 24, line 27 skipping to change at page 24, line 27
packet. The metadata passed with the packet assists subsequent LFBs packet. The metadata passed with the packet assists subsequent LFBs
to process that packet. to process that packet.
The ForCES model defines metadata as precise atomic definitions in The ForCES model defines metadata as precise atomic definitions in
the form of label, value pairs. the form of label, value pairs.
The ForCES model provides to the authors of LFB classes a way to The ForCES model provides to the authors of LFB classes a way to
formally define how to achieve metadata creation, modification, formally define how to achieve metadata creation, modification,
reading, as well as consumption(deletion). reading, as well as consumption(deletion).
Inter-FE metadata, i.e, metadata crossing FEs, while likely Inter-FE metadata, i.e, metadata crossing FEs, while it is likely to
semantically similar to this metadata, is out of scope for this be semantically similar to this metadata, is out of scope for this
document. document.
Section 4 has informal details on metadata. Section 4 has informal details on metadata.
3.2.4.1. Metadata lifecycle within the ForCES model 3.2.4.1. Metadata Lifecycle Within the ForCES Model
Each metadata is modeled as a <label, value> pair, where the label Each metadatum is modeled as a <label, value> pair, where the label
identifies the type of information, (e.g., "color"), and its value identifies the type of information, (e.g., "color"), and its value
holds the actual information (e.g., "red"). The label here is shown holds the actual information (e.g., "red"). The label here is shown
as a textual label, but for protocol processing it is associated with as a textual label, but for protocol processing it is associated with
a unique numeric value (identifier). a unique numeric value (identifier).
To ensure inter-operability between LFBs, the LFB class specification To ensure inter-operability between LFBs, the LFB class specification
must define what metadata the LFB class "reads" or "consumes" on its must define what metadata the LFB class "reads" or "consumes" on its
input(s) and what metadata it "produces" on its output(s). For input(s) and what metadata it "produces" on its output(s). For
maximum extensibility, this definition should neither specify which maximum extensibility, this definition should neither specify which
LFBs the metadata is expected to come from for a consumer LFB, nor LFBs the metadata is expected to come from for a consumer LFB, nor
which LFBs are expected to consume metadata for a given producer LFB. which LFBs are expected to consume metadata for a given producer LFB.
3.2.4.2. Metadata Production and Consumption 3.2.4.2. Metadata Production and Consumption
For a given metadata on a given packet path, there MUST be at least For a given metadatum 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 metadatum and SHOULD be at least
one consumer LFB that needs that metadata. one consumer LFB that needs that metadatum.
In the ForCES model, the producer and consumer LFBs of a metadatum In the ForCES model, the producer and consumer LFBs of a metadatum
are not required to be adjacent. In addition, there may be multiple are not required to be adjacent. In addition, there may be multiple
producers and consumers for the same metadata. When a packet path producers and consumers for the same metadatum. When a packet path
involves multiple producers of the same metadata, then subsequent involves multiple producers of the same metadatum, then subsequent
producers overwrite that metadata value. producers overwrite that metadatum value.
The metadata that is produced by an LFB is specified by the LFB class The metadata that is produced by an LFB is specified by the LFB class
definition on a per-output-port-group basis. A producer may always definition on a per-output-port-group basis. A producer may always
generate the metadata on the port group, or may generate it only generate the metadata on the port group, or may generate it only
under certain conditions. We call the former an "unconditional" under certain conditions. We call the former "unconditional"
metadata, whereas the latter is a "conditional" metadata. For metadata, whereas the latter is a "conditional" metadata. For
example, deep packet inspection LFB might produce several pieces of example, deep packet inspection LFB might produce several pieces of
metadata about the packet. The first metadatum might be the carried metadata about the packet. The first metadatum might be the IP
IP protocol (TCP, UDP, SCTP, ...), and two additional metadata items protocol (TCP, UDP, SCTP, ...) being carried, and two additional
might be the source and destination and destination port number. metadata items might be the source and destination port number.
These additional metadata items are conditional on the value of the These additional metadata items are conditional on the value of the
first metadatum (IP carried protocol) as they are only produced for first metadatum (IP carried protocol) as they are only produced for
protocols which use port number. In the case of conditional protocols which use port numbers. In the case of conditional
metadata, it should be possible to determine from the definition of metadata, it should be possible to determine from the definition of
the LFB when a "conditional" metadata is produced. The consumer the LFB when "conditional" metadata is produced. The consumer
behavior of an LFB, that is, the metadata that the LFB needs for its behavior of an LFB, that is, the metadata that the LFB needs for its
operation, is defined in the LFB class definition on a per-input- operation, is defined in the LFB class definition on a per-input-
port-group basis. An input port group may "require" a given port-group basis. An input port group may "require" a given
metadata, or may treat it as "optional" information. In the latter metadatum, or may treat it as "optional" information. In the latter
case, the LFB class definition MUST explicitly define what happens if case, the LFB class definition MUST explicitly define what happens if
an optional metadata is not provided. One approach is to specify a any optional metadata is not provided. One approach is to specify a
default value for each optional metadata, and assume that the default default value for each optional metadatum, and assume that the
value is used if the metadata is not provided with the packet. default value is used for any metadata which is not provided with the
packet.
When specifying the metadata tags, some harmonization effort must be When specifying the metadata tags, some harmonization effort must be
made so that the producer LFB class uses the same tag as its intended made so that the producer LFB class uses the same tag as its intended
consumer(s), or vice versa. consumer(s).
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 metadatum.
* IGNORE: ignores and forwards the metadata * IGNORE: ignores and forwards the metadatum
* READ: reads and forwards the metadata * READ: reads and forwards the metadatum
* READ/RE-WRITE: reads, over-writes and forwards the metadata * READ/RE-WRITE: reads, over-writes and forwards the metadatum
* WRITE: writes and forwards the metadata (can also be used to * WRITE: writes and forwards the metadatum (can also be used to
create new metadata) create new metadata)
* READ-AND-CONSUME: reads and consumes the metadata * READ-AND-CONSUME: reads and consumes the metadatum
* CONSUME consumes metadata without reading * CONSUME consumes metadatum without reading
The last two operations terminate the life-cycle of the metadata, The last two operations terminate the life-cycle of the metadatum,
meaning that the metadata is not forwarded with the packet when the meaning that the metadatum is not forwarded with the packet when the
packet is sent to the next LFB. packet is sent to the next LFB.
In the ForCES model, a new metadata is generated by an LFB when the In the ForCES model, a new metadatum is generated by an LFB when the
LFB applies a WRITE operation to a metadatum type that was not LFB applies a WRITE operation to a metadatum type that was not
present when the packet was received by the LFB. Such implicit present when the packet was received by the LFB. Such implicit
creation may be unintentional by the LFB, that is, the LFB may apply creation may be unintentional by the LFB, that is, the LFB may apply
the WRITE operation without knowing or caring if the given metadata the WRITE operation without knowing or caring if the given metadatum
existed or not. If it existed, the metadata gets over-written; if it existed or not. If it existed, the metadatum gets over-written; if
did not exist, the metadata is created. it did not exist, the metadatum 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 READ- For LFBs that remove the packet from the model, they may either READ-
AND-CONSUME (read) or CONSUME (ignore) each active metadata AND-CONSUME (read) or CONSUME (ignore) each active metadatum
associated with the packet. associated with the packet.
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 description of how such of the occurrence of such events. The description of how such
messages are sent, and their format, is part of the Forwarding and messages are sent, and their format, is part of the Forwarding and
Control Element Separation (ForCES) protocol [2] document. Control Element Separation (ForCES) protocol [2] document.
skipping to change at page 27, line 6 skipping to change at page 27, line 6
Events are declared in the LFB class definition. The LFB event Events are declared in the LFB class definition. The LFB event
declaration constitutes: declaration constitutes:
o a unique 32 bit identifier. o a unique 32 bit identifier.
o An LFB component which is used to trigger the event. This entity o An LFB component which is used to trigger the event. This entity
is known as the event target. is known as the event target.
o A condition that will happen to the event target that will result o A condition that will happen to the event target that will result
in a generation of an event to the CE. Example of a condition in a generation of an event to the CE. Examples of a condition
include something getting created, deleted, config change, etc. include something getting created, deleted, config change, etc.
o What should be reported to the CE by the FE if the declared o What should be reported to the CE by the FE if the declared
condition is met. condition is met.
The declaration of an event within an LFB class essentially defines The declaration of an event within an LFB class essentially defines
what part of the LFB component(s) need to be monitored for events, what part of the LFB component(s) need to be monitored for events,
what condition on the LFB monitored LFB component an FE should detect what condition on the LFB monitored LFB component an FE should detect
to trigger such an event, and what to report to the CE when the event to trigger such an event, and what to report to the CE when the event
is triggered. is triggered.
While events may be declared by the LFB class definition, runtime While events may be declared by the LFB class definition, runtime
activity is controlled using built-in event properties using LFB activity is controlled using built-in event properties using LFB
component Properties (discussed in Section 3.2.6). A CE subscribes component Properties (discussed in Section 3.2.6). A CE subscribes
to the events on an LFB class instance by setting an event property to the events on an LFB class instance by setting an event property
for subscription. Each event has a subscription property which is by for subscription. Each event has a subscription property which is by
default off. A CE wishing to receive a specific event needs to turn default off. A CE wishing to receive a specific event needs to turn
on the subscription property at runtime. on the subscription property at runtime.
Event properties also provide semantics for runtime event filtering. Event properties also provide semantics for runtime event filtering.
A CE may set an event property to further suppress subscribed to A CE may set an event property to further suppress events to which it
events. The LFB model defines such filters to include threshold has already subscribed. The LFB model defines such filters to
values, hysteris, time intervals, number of events, etc. include threshold values, hysteresis, time intervals, number of
events, etc.
The reports with events are designed to allow for the common, closely The contents of reports with events are designed to allow for the
related information that the CE can be strongly expected to need to common, closely related information that the CE can be strongly
react to the event. It is not intended to carry information the CE expected to need to react to the event. It is not intended to carry
already has, nor large volumes of information, nor information information that the CE already has, nor large volumes of
related in complex fashions. information, nor information related in complex fashions.
From a conceptual point of view, at runtime, event processing is From a conceptual point of view, at runtime, event processing is
split into: split into:
1. detection of something happening to the (declared during LFB 1. detection of something happening to the (declared during LFB
class definition) event target. Processing the next step happens class definition) event target. Processing the next step happens
if the CE subscribed (at runtime) to the event. if the CE subscribed (at runtime) to the event.
2. checking of the (declared during LFB class definition) condition 2. checking of the (declared during LFB class definition) condition
on the LFB event target. If the condition is met, proceed with on the LFB event target. If the condition is met, proceed with
skipping to change at page 28, line 18 skipping to change at page 28, line 18
3.2.6. Component Properties 3.2.6. Component Properties
LFBs and structures are made up of Components, containing the LFBs and structures are made up of Components, containing the
information that the CE needs to see and/or change about the information that the CE needs to see and/or change about the
functioning of the LFB. These Components, as described in detail in functioning of the LFB. These Components, as described in detail in
Section 4.7, may be basic values, complex structures (containing Section 4.7, may be basic values, complex structures (containing
multiple Components themselves, each of which can be values, multiple Components themselves, each of which can be values,
structures, or tables), or tables (which contain values, structures structures, or tables), or tables (which contain values, structures
or tables). Components may be defined such that their appearence in or tables). Components may be defined such that their appearence in
LFB instances is optional. Components may be readable or writeable LFB instances is optional. Components may be readable or writable at
at the discretion of the FE implementation. The CE needs to know the discretion of the FE implementation. The CE needs to know these
these properties. Additionally, certain kinds of Components (arrays properties. Additionally, certain kinds of Components (arrays /
/ tables, aliases, and events) have additional property information tables, aliases, and events) have additional property information
that the CE may need to read or write. This model defines the that the CE may need to read or write. This model defines the
structure of the property information for all defined data types. structure of the property information for all defined data types.
Section 4.8 describes properties in more details. Section 4.8 describes properties in more details.
3.2.7. LFB Versioning 3.2.7. LFB Versioning
LFB class versioning is a method to enable incremental evolution of LFB class versioning is a method to enable incremental evolution of
LFB classes. In general, an FE is not allowed to contain an LFB LFB classes. In general, an FE is not allowed to contain an LFB
instance for more than one version of a particular class. instance for more than one version of a particular class.
skipping to change at page 32, line 30 skipping to change at page 32, line 30
(e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc. (e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc.
The result of LFB processing may have an impact on how the packet is The result of LFB processing may have an impact on how the packet is
to be treated in downstream LFBs. This differentiation of packet to be treated in downstream LFBs. This differentiation of packet
treatment downstream can be conceptualized as having alternative treatment downstream can be conceptualized as having alternative
datapaths in the FE. For example, the result of a 6- tuple datapaths in the FE. For example, the result of a 6- tuple
classification performed by a classifier LFB could control which rate classification performed by a classifier LFB could control which rate
meter is applied to the packet by a rate meter LFB in a later stage meter is applied to the packet by a rate meter LFB in a later stage
in the datapath. 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 instances datapaths within an FE, with the nodes representing the LFB instances
and the directed link depicting the packet flow direction from one and the directed link depicting the packet flow direction from one
LFB to the next. Section 3.4.1 discusses how the FE datapaths can be LFB to the next. Section 3.4.1 discusses how the FE datapaths can be
modeled as LFB topology; while Section 3.4.2 focuses on issues modeled as LFB topology; while Section 3.4.2 focuses on issues
related to LFB topology reconfiguration. related to LFB topology reconfiguration.
3.4.1. Alternative Approaches for Modeling FE Datapaths 3.4.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
skipping to change at page 38, line 36 skipping to change at page 38, line 36
| |Forwarder|<------|Scheduler|<--|Queue | |Counter | | | |Forwarder|<------|Scheduler|<--|Queue | |Counter | |
| +---------+ +---------+ +------+ +---------+ | | +---------+ +---------+ +------+ +---------+ |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 9: The Capability of an FE as reported to the CE Figure 9: The Capability of an FE as reported to the CE
Figure 9 shows an example where a QoS-enabled router has several line Figure 9 shows an example where a QoS-enabled router has several line
cards that have a few ingress ports and egress ports, a specialized cards that have a few ingress ports and egress ports, a specialized
classification chip, and a network processor containing codes for FE classification chip, and a network processor containing codes for FE
blocks like meter, marker, dropper, counter, queue, scheduler, and blocks like meter, marker, dropper, counter, queue, scheduler, and
Ipv4 forwarder. Some of the LFB topology is already fixed and has to IPv4 forwarder. Some of the LFB topology is already fixed and has to
remain static due to the physical layout of the line cards. For remain static due to the physical layout of the line cards. For
example, all of the ingress ports might be hardwired into the example, all of the ingress ports might be hardwired into the
classification chip so all packets flow from the ingress port into classification chip so all packets flow from the ingress port into
the classification engine. On the other hand, the LFBs on the the classification engine. On the other hand, the LFBs on the
network processor and their execution order are programmable. network processor and their execution order are programmable.
However, certain capacity limits and linkage constraints could exist However, certain capacity limits and linkage constraints could exist
between these LFBs. Examples of the capacity limits might be: between these LFBs. Examples of the capacity limits might be:
o 8 meters o 8 meters
skipping to change at page 42, line 18 skipping to change at page 42, line 18
A library document can import other library documents if it needs to A library document can import other library documents if it needs to
refer to definitions contained in the included document. This refer to definitions contained in the included document. This
concept is similar to the "#include" directive in C. Importing is concept is similar to the "#include" directive in C. Importing is
expressed by the use of <load> elements, which must precede all the expressed by the use of <load> elements, which must precede all the
above elements in the document. For unique referencing, each above elements in the document. For unique referencing, each
LFBLibrary instance document has a unique label defined in the LFBLibrary instance document has a unique label defined in the
"provide" attribute of the LFBLibrary element. Note that what this "provide" attribute of the LFBLibrary element. Note that what this
performs is a ForCES inclusion, not an XML inclusion. The semantic performs is a ForCES inclusion, not an XML inclusion. The semantic
content of the library referenced by the <load> element is included, content of the library referenced by the <load> element is included,
not the xml content. Also, in terms of the conceptual processing not the xml content. Also, in terms of the conceptual processing of
<load> elements, the total set of documents loaded are considered to <load> elements, the total set of documents loaded are considered to
form a single document for processing. A given document is included form a single document for processing. A given document is included
in this set only once, even if it is referenced by <load> elements in this set only once, even if it is referenced by <load> elements
several times, even from several different files. As the processing several times, even from several different files. As the processing
of LFBLibrary information is not order dependent, the order for of LFBLibrary information is not order dependent, the order for
processing loaded elements is up to the implementor, as long as the processing loaded elements is up to the implementor, as long as the
total effect is as if all of the information from all the files were total effect is as if all of the information from all the files were
available for referencing when needed. Note that such computer available for referencing when needed. Note that such computer
processing of ForCES model library documents may be helpful for processing of ForCES model library documents may be helpful for
various implementations, but is not required to define the libraries, various implementations, but is not required to define the libraries,
skipping to change at page 43, line 49 skipping to change at page 43, line 49
</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 be The load element MUST contain the label of the library document to be
included and may contain a URL to specify where the library can be included and MAY contain a URL to specify where the library can be
retrieved. The load element can be repeated unlimited times. Three retrieved. The load element can be repeated unlimited times. 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.exmplae.com/forces/1.0/lfbmodel/lpm.xml"/> location="http://www.example.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 be brief synopsis. In addition, an optional detailed description MAY 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>
skipping to change at page 45, line 16 skipping to change at page 45, line 16
o Defining components of LFB classes o Defining components 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, and a type definition element. The name MUST be brief synopsis, and a type definition element. The name MUST be
unique among all data types defined in the same library document and unique among all data types defined in the same library document and
in any directly or indirectly included library documents. The in any directly or indirectly included library documents. The
<dataTypeDef> element may also include an optional longer <dataTypeDef> element MAY also include an optional longer
description, For example: description, 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>
skipping to change at page 46, line 22 skipping to change at page 46, line 22
uint32 32-bit unsigned integer uint32 32-bit unsigned integer
int64 64-bit signed integer int64 64-bit signed integer
uint64 64-bit unsigned integer uint64 64-bit unsigned integer
boolean A true / false value where boolean A true / false value where
0 = false, 1 = true 0 = false, 1 = true
string[N] A UTF-8 string represented in at most string[N] A UTF-8 string represented in at most
N Octets. N Octets.
string A UTF-8 string without a configured string A UTF-8 string without a configured
storage length limit. storage length limit.
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 defining LFB attributes, but can also be used as building blocks when defining
new data types. The boolean data type is defined here because it is new data types. The boolean data type is defined here because it is
so common, even though it can be built by sub-ranging the uchar data so common, even though it can be built by sub-ranging the uchar data
type. type, as defined under atomic types (Section 4.5.2).
Compound data types can build on atomic data types and other compound Compound data types can build on atomic data types and other compound
data types. Compound data types can be defined in one of four ways. data types. Compound data types can be defined in one of four ways.
They may be defined as an array of components of some compound or They may be defined as an array of components of some compound or
atomic data type. They may be a structure of named components of atomic data type. They may be a structure of named components of
compound or atomic data types (ala C structures). They may be a compound or atomic data types (c.f. C structures). They may be a
union of named components of compound or atomic data types (ala C union of named components of compound or atomic data types (c.f. C
unions). They may also be defined as augmentations (explained in unions). They may also be defined as augmentations (explained in
Section 4.5.7) of existing compound data types. Section 4.5.7) of existing compound data types.
Given that the FORCES protocol will be getting and setting component 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 ForCES Protocol [2] document to such representations are for the ForCES Protocol [2] document to
define, not the model document. Strings and octetstrings must be define, not the model document. Strings and octetstrings must be
conveyed by the protocol with their length, as they are not conveyed by the protocol with their length, as they are not
delimited, the value does not itself include the length, and these delimited, the value does not itself include the length, and these
items are variable length. items 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 component properties for string and octetstring definitions. The component properties for string and octetstring
components 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 definition. limits than the maximum limits specified in the LFB Class definition.
In all cases, these lengths are specified in octets, not in In all cases, these lengths are specified in octets, not in
characters. In terms of protocol operation, as long as the specified characters. In terms of protocol operation, as long as the specified
length is within the FE's supported capabilities, the FE stores the length is within the FE's supported capabilities, the FE stores the
contents of a string exactly as provided by the CE, and returns those contents of a string exactly as provided by the CE, and returns those
contents when requested. No canonicalization, transformations, or contents when requested. No canonicalization, transformations, or
equivalences are performed by the FE. components of type string (or equivalences are performed by the FE. Components of type string (or
string[n]) may be used to hold identifiers for correlation with string[n]) MAY be used to hold identifiers for correlation with
components in other LFBs. In such cases, an exact octet for octet components in other LFBs. In such cases, an exact octet for octet
match is used. No equivalences are used by the FE or CE in match is used. No equivalences are used by the FE or CE in
performing that matching. The ForCES Protocol [2] does not perform performing that matching. The ForCES Protocol [2] does not perform
or require validation of the content of UTF-8 strings. However, or require validation of the content of UTF-8 strings. However,
UTF-8 strings SHOULD be encoded in the shortest form to avoid UTF-8 strings SHOULD be encoded in the shortest form to avoid
potential security issues described in [12]. Any entity displaying potential security issues described in [12]. Any entity displaying
such strings is expected to perform its own validation (for example such strings is expected to perform its own validation (for example
for correct multi-byte characters, and for ensuring that the string for correct multi-byte characters, and for ensuring that the string
does not end in the middle of a multi-byte sequence.) Specific LFB does not end in the middle of a multi-byte sequence.) Specific LFB
class definitions may restrict the valid contents of a string as class definitions MAY restrict the valid contents of a string as
suited to the particular usage (for example, a component that holds a suited to the particular usage (for example, a component that holds a
DNS name would be restricted to hold only octets valid in such a DNS name would be restricted to hold only octets valid in such a
name.) FEs should validate the contents of SET requests for such name.) FEs should validate the contents of SET requests for such
restricted components at the time the set is performed, just as range restricted components at the time the set is performed, just as range
checks for range limited components are performed. The ForCES checks for range limited components are performed. The ForCES
protocol behavior defines the normative processing for requests using protocol behavior defines the normative processing for requests using
that protocol. 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 component of compound data types. Alias is used to allow a component inside an
which has special behavior. Given that the special behavior is tied LFB to be an indirect reference to another component inside the same
to the other parts of the structure, the compound result is treated or a different LFB class or instance. The alias component behaves
as a predefined construct. like a structure, one component of which has special behavior. Given
that the special behavior is tied to the other parts of the
structure, the compound result is treated as a predefined construct.
4.5.1. <typeRef> Element for Renaming Existing Data Types 4.5.1. <typeRef> Element for Renaming 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
will also be regarded as atomic. If the referred data type is a will also be regarded as atomic. If the referred data type is a
compound type, the new type will also be compound. Some usage compound type, the new type will also be compound. Some usage
examples follow: examples follow:
skipping to change at page 49, line 21 skipping to change at page 49, line 21
The type of the array entry can be specified either by referring to The type of the array entry can be specified either by referring to
an existing type (using the <typeRef> element) or defining an unnamed an existing type (using the <typeRef> element) or defining an unnamed
type inside the <array> element using any of the <atomic>, <array>, type inside the <array> element using any of the <atomic>, <array>,
<struct>, or <union> elements. <struct>, or <union> elements.
The array can be "fixed-size" or "variable-size", which is specified The array can be "fixed-size" or "variable-size", which is specified
by the "type" attribute of the <array> element. The default is by the "type" attribute of the <array> element. The default is
"variable-size". For variable size arrays, an optional "maxlength" "variable-size". For variable size arrays, an optional "maxlength"
attribute specifies the maximum allowed length. This attribute attribute specifies the maximum allowed length. This attribute
should be used to encode semantic limitations, not implementation should be used to encode semantic limitations, not implementation
limitations. The latter should be handled by capability components limitations. The latter (support for implementation constraints)
of LFB classes, and should never be included in a data type array should be handled by capability components of LFB classes, and should
which is regarded as of unlimited-size. never be included as the maxlength in a data type array which is
regarded as being 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 is always a compound type, even if the
the array has a fixed size of 1. 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:
o Any declared key can be used in the ForCES protocol to select a o Any declared key can be used in the ForCES protocol to select a
component for operations (for details, see the ForCES Protocol component for operations (for details, see the ForCES Protocol
[2]). [2]).
o 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 components of an array may have the within that instance. That is, no two components of an array may
same values on all the fields which make up a key. have the same values on all the fields which make up a key.
Each key is declared with a keyID for use in the ForCES Protocol [2], Each key is declared with a keyID for use in the ForCES Protocol [2],
where the unique key is formed by combining one or more specified key where the unique key is formed by combining one or more specified key
fields. To support the case where an array of an atomic type with fields. To support the case where an array of an atomic type with
unique values can be referenced by those values, the key field unique values can be referenced by those values, the key field
identifier may be "*" (i.e., the array entry is the key). If the identifier 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 value type of the array is a structure or an array, then the key is
one or more components of the value type, each identified by name. one or more components of the value type, each identified by name.
Since the field may be a component of the contained structure, a
Since the field MAY be a component of the contained structure, a
component of a component of a structure, or further nested, the field component of a component of a structure, or further nested, the field
name is actually a concatenated sequence of component identifiers, name is actually a concatenated sequence of component identifiers,
separated by decimal points ("."). The syntax for key field separated by decimal points ("."). The syntax for key field
identification is given following the array examples. identification is given following the array examples.
The following example shows the definition of a fixed size array with The following example shows the definition of a fixed size array with
a pre-defined data type as the array content type: a pre-defined data type as the array content type:
<dataTypeDef> <dataTypeDef>
<name>dscp-mapping-table</name> <name>dscp-mapping-table</name>
skipping to change at page 53, line 27 skipping to change at page 53, line 27
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 for When the current context is an array, (e.g., when declaring a key for
an array whose content is an array) then the only valid value for the an array whose content is an array) then the only valid value 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 components 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 key, atomic type, where that content is unique and is to be used as a key,
the value "*" can be used as the single key field identifier. the value "*" MUST be used as the single key field identifier.
In reference array or structure elements, it is possible to construct
keyFields that do not exist. keyField references SHOULD never
reference optional structure components. For references to array
elements, care must be taken to ensure that the necessary array
elements exist when creating or modifying the overall array element.
Failure to do so will result in FEs returning errors on the creation
attempt.
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 components. Each A structure is comprised of a collection of data components. Each
data components 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. These components are defined using <component> "struct" in C, etc. These components are defined using <component>
elements. A <struct> element may contain an optional derivation elements. A <struct> element MAY contain an optional derivation
indication, a <derivedFrom> element. The structure definition MUST indication, a <derivedFrom> element. The structure definition MUST
contain a sequence of one or more <component> elements. contain a sequence of one or more <component> elements.
The actual type of the component can be defined by referring to an The actual type of the component can be defined by referring to an
existing type (using the <typeRef> element), or can be a locally existing type (using the <typeRef> 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.
The <component> element must include a componentID attribute. This The <component> element MUST include a componentID attribute. This
provides the numeric ID for this component, for use by the protocol. provides the numeric ID for this component, for use by the protocol.
The <component> MUST contain a component name and a synopsis. It may The <component> MUST contain a component name and a synopsis. It MAY
contain a =description> element giving a textual description of the contain a <description> element giving a textual description of the
component. The definition may also include a <optional> element, component. The definition MAY also include a <optional> element,
which indicates that the component being defined is optional. The which indicates that the component being defined is optional. The
definition MUST contain elements to define the data type of the definition MUST contain elements to define the data type of the
component, as described above. component, as described above.
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 optional derivedFrom attribute in This is indicated by including the optional derivedFrom attribute in
the struct declaration before the definition of the augmenting or the struct declaration before the definition of the augmenting or
replacing components. replacing components. The augmentation (Section 4.5.7) section
describes how this is done in more detail.
The result of this construct MUST be a compound type, even when the The componentID attribute for different components in a structure (or
in an LFB) MUST be distinct. They do not need to be in order, nor do
they need to be sequential. For clarity of human readability, and
ease of maintanence, it is usual to define at least sequential sets
of values. But this is for human ease, not a model or protocol
requirement.
The result of this construct is always 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>
skipping to change at page 54, line 47 skipping to change at page 55, line 40
</component> </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 <struct> definition of overlay types. Its format is identical to the <struct>
element. element.
The result of this construct MUST be a compound type, even when the The result of this construct is always 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 a component in an LFB or structure It is sometimes necessary to have a component in an LFB or structure
refer to information (a component) in other LFBs. This can, for refer to information (a component) in other LFBs. This can, for
example, allow an ARP LFB to share the IP->MAC Address table with the example, allow an ARP LFB to share the IP->MAC Address table with the
local transmission LFB, without duplicating information. Similarly, local transmission LFB, without duplicating information. Similarly,
it could allow a traffic measurement LFB to share information with a it could allow a traffic measurement LFB to share information with a
traffic enforcement LFB. The <alias> declaration creates the traffic enforcement LFB. The <alias> declaration creates the
skipping to change at page 55, line 29 skipping to change at page 56, line 18
the same type as that declared for the alias. Thus, when the CE or the same type as that declared for the alias. Thus, when the CE or
FE dereferences the alias component, the type of the information FE dereferences the alias component, the type of the information
returned is known. The type can be a base type or a derived type. returned is known. The type can be a base type or a derived type.
The actual value referenced by an alias is known as its target. When The actual value referenced by an alias is known as its target. When
a GET or SET operation references the alias element, the value of the a GET or SET operation references the alias element, the value of the
target is returned or replaced. Write access to an alias element is target is returned or replaced. Write access to an alias element is
permitted if write access to both the alias and the target are permitted if write access to both the alias and the target are
permitted. permitted.
The target of a component declared by an <alias> element is The target of a component declared by an <alias> element is
determined by it the components properties. Like all components, the determined by the information in the component's properties. Like
properties MUST include the support / read / write permission for the all components, the properties include the support / read / write
alias. In addition, there are several fields (components) in the permission for the alias. In addition, there are several fields
alias properties which define the target of the alias. These (components) in the alias properties which define the target of the
components are the ID of the LFB class of the target, the ID of the alias. These components are the ID of the LFB class of the target,
LFB instance of the target, and a sequence of integers representing the ID of the LFB instance of the target, and a sequence of integers
the path within the target LFB instance to the target component. The representing the path within the target LFB instance to the target
type of the target element must match the declared type of the alias. component. The type of the target element must match the declared
Details of the alias property structure are described in Section 4.8 type of the alias. Details of the alias property structure are
of this document on properties. described in Section 4.8 of this document on properties.
Note that the read / write property of the alias refers to the value. Note that the read / write property of the alias refers to the value.
The CE can only determine if it can write the target selection The CE can only determine if it can write the target selection
properties of the alias by attempting such a write operation. properties of the alias by attempting such a write operation.
(Property components do not themselves have properties.) (Property components do not themselves have properties.)
4.5.7. Augmentations 4.5.7. Augmentations
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 component can be replaced in the definition of an augmenting existing component MAY be replaced in the definition of an augmenting
structure, but only with an augmentation derived from the current structure, but MAY only be replaced with an augmentation derived from
type of the existing component. An existing component cannot be the current type of the existing component. An existing component
deleted. If the existing compound type is an array, augmentation cannot be deleted. If the existing compound type is an array,
means augmentation of the array element type. augmentation means augmentation of the array element type.
Augmentation MUST NOT be applied to unions.
One consequence of this is that augmentations are backwards One consequence of this is that augmentations are backwards
compatible with the compound type from which they are derived. As compatible with the compound type from which they are derived. As
such, augmentations are useful in defining components for LFB such, augmentations are useful in defining components for LFB
subclasses with backward compatibility. In addition to adding new subclasses with backward compatibility. In addition to adding new
components to a class, the data type of an existing components may be components to a class, the data type of an existing component MAY be
replaced by an augmentation of that component, and still meet the replaced by an augmentation of that component, and still meet the
compatibility rules for subclasses. compatibility rules for subclasses. This compatibility constraint is
why augmentations can not be applied to unions.
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
component (comp1) of type X. One way to derive class A1 from A can be component (comp1) of type X. One way to derive class A1 from A can be
by simply adding a second component (of any type). Another way to by simply adding a second component (of any type). Another way to
derive a class A2 from A can be by replacing the original component derive a class A2 from A can be by replacing the original component
(comp1) in A of type X with one of type Y, where Y is an augmentation (comp1) in A of type X with one of type Y, where Y is an augmentation
of X. Both classes A1 and A2 are backward compatible with class A. of X. Both classes A1 and A2 are backward compatible 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. Component names and component IDs for new components augmented. Component names and component IDs for new components
within the augmentation must not be the same as those in the within the augmentation MUST NOT be the same as those in the
structure type being augmented. For those components where the data structure type being augmented. For those components where the data
type of an existing component is being replaced with a suitable type of an existing component is being replaced with a suitable
augmenting data type, the existing Component name and component ID augmenting data type, the existing Component name and component ID
must be used in the augmentation. MUST be used in the augmentation. Other than the constraint on
existing elements, there is no requirement that the new component IDs
be sequential with, greater than, or in any other specific
relationship to the existing component IDs except different. It is
expected that using values sequential within an augmentation, and
distinct from the previously used values, will be a common method to
enhance human readability.
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 metadatum. element defines a metadatum.
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 library Uniqueness is defined to be over all metadata defined in this 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 tag value to be used for this metadata, and value type synopsis, the tag value to be used for this metadata, and value type
definition information. Only atomic data types can be used as value definition information. Only atomic data types can be used as value
types for metadata. The <metadataDef> element may contain a detailed types for metadata. The <metadataDef> element MAY contain a detailed
description element. description element.
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 in <typeRef> element to refer to an existing atomic data type defined in
the <dataTypeDefs> element of the same library document or in one of the <dataTypeDefs> element of the same library document or in one of
the included library documents. The usage of the <typeRef> element the included library documents. The usage of the <typeRef> element
is identical to how it is used in the <dataTypeDef> elements, except is identical to how it is used in the <dataTypeDef> elements, except
here it can only refer to atomic types. The latter restriction is here it can only refer to atomic types. The latter restriction is
not enforced by the XML schema. not enforced by the XML schema.
skipping to change at page 58, line 4 skipping to change at page 58, line 49
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:
o <name> provides the symbolic name of the LFB class. Example: o <name> provides the symbolic name of the LFB class. Example:
"ipv4lpm" "ipv4lpm"
o <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"
o <version> is the version indicator
o <version> is the version indicator
o <derivedFrom> is the inheritance indicator o <derivedFrom> is the inheritance indicator
o <inputPorts> lists the input ports and their specifications o <inputPorts> lists the input ports and their specifications
o <outputPorts> lists the output ports and their specifications o <outputPorts> lists the output ports and their specifications
o <components> defines the operational components of the LFB o <components> defines the operational components of the LFB
o <capabilities> defines the capability components of the LFB o <capabilities> defines the capability components of the LFB
skipping to change at page 60, line 5 skipping to change at page 60, line 52
The individual components and capabilities will have componentIDs for The individual components and capabilities will have componentIDs for
use by the ForCES protocol. These parallel the componentIDs used in use by the ForCES protocol. These parallel the componentIDs used in
structs, and are used the same way. Component and capability structs, and are used the same way. Component and capability
componentIDs 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.
The componentID attribute for different items in an LFB class
definition (or components in a struct) MUST be distinct. They do not
need to be in order, nor do they need to be sequential. For clarity
of human readability, and ease of maintanence, it is usual to define
at least sequential sets of values. But this is for human ease, not
a model or protocol requirement.
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 in referred LFB class MUST be defined in the same library document or in
one of the included library documents. In the absence of a one of the included library documents. In the absence of a
<derivedFrom> the class is conceptually derived from the common, <derivedFrom> the class is conceptually derived from the common,
empty, base class. empty, base class.
It is assumed that a derived class is backwards compatible with its It is assumed that a derived class is backwards compatible with its
base class. base class. A derived class MAY add compoents to a parent class, but
can not delete components. This also applies to input and output
ports, events, and to capabilities.
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 as modeled as one input group. Input groups are defined the same way 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 4.7.3). Some special LFBs will possible (see discussion in Section 4.7.3). Some special LFBs will
skipping to change at page 61, line 4 skipping to change at page 62, line 13
of the LFB class. of the LFB class.
o <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".
o <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 "vpnid"}. 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 metadatum, it must be
specified whether the metadata is required or optional. For each specified whether the metadatum is required or optional. For each
optional metadata, a default value must be specified, which is optional metadatum, 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 metadatum 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 "true" value is allowed to be instantiated. This is indicated by a "true" value
(the default value is "false"). (the default value is "false").
An example <inputPorts> element, defining two input ports, the second An example <inputPorts> element, defining two input ports, the second
one being an input port group: one being an input port group:
<inputPorts> <inputPorts>
skipping to change at page 62, line 46 skipping to change at page 64, line 8
<ref>prefixlen</ref> <ref>prefixlen</ref>
</one-of> </one-of>
</metadataExpected> </metadataExpected>
Although the schema is constructed to allow even more complex Although the schema is constructed to allow even more complex
definitions of metadata expectations, we do not discuss those here. definitions of metadata expectations, we do not discuss those here.
4.7.3. <outputPorts> Element to Define LFB Outputs 4.7.3. <outputPorts> Element to Define LFB Outputs
The optional <outputPorts> element is used to define output ports. The optional <outputPorts> element is used to define output ports.
An LFB class may have zero, one, or more outputs. If the LFB class An LFB class MAY have zero, one, or more outputs. If the LFB class
has no output ports, the <outputPorts> element MUST be omitted. The has no output ports, the <outputPorts> element MUST be omitted. The
<outputPorts> element can contain one or more <outputPort> elements, <outputPorts> element MUST contain one or more <outputPort> elements,
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 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:
o <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.
o <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".
o <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 metadatum, it should be specified whether the metadatum 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 "true" value is allowed to be instantiated. This is indicated by a "true" value
(the default value is "false"). (the default value is "false").
The following example specifies two output ports, the second being an The following example specifies two output ports, the second being an
skipping to change at page 65, line 32 skipping to change at page 66, line 32
o Various configurable lookup tables, including interface tables, o Various configurable lookup tables, including interface tables,
prefix tables, classification tables, DSCP mapping tables, MAC prefix tables, classification tables, DSCP mapping tables, MAC
address tables, etc. address tables, etc.
o Packet and byte counters o Packet and byte counters
o Various event counters o Various event counters
o Number of current inputs or outputs for each input or output group o Number of current inputs or outputs for each input or output group
There may be various access permission restrictions on what the CE The ForCES model supports the definition of access permission
can do with an LFB component. The following categories may be restrictions on what the CE can do with an LFB component. The
supported: following categories are supported by the model:
o No-access components. This is useful when multiple access modes o No-access components. This is useful for completeness, and to
may be defined for a given component to allow some flexibility for allow for defining objects which are used by other things, but not
different implementations. directly referencable by the CE. It is also useful for an FE
which is reporting that certain defined, and typically accessible,
Components are not supported for CE access by a reporting FE.
o Read-only components. o Read-only components.
o Read-write components. o Read-write components.
o Write-only components. This could be any configurable data for 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)
o Read-reset components. The CE can read and reset this resource, o Read-reset components. The CE can read and reset this resource,
but cannot set it to an arbitrary value. Example: Counters. but cannot set it to an arbitrary value. Example: Counters.
o Firing-only components. 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 only one possible access mode for a given The LFB class MUST define only one possible access mode for a given
component. component.
The components of the LFB class are listed in the <components> The components of the LFB class are listed in the <components>
element. Each component is defined by an <component> element. An element. Each component is defined by an <component> element. A
<component> element may contain any of the following elements, some <component> element contains some or all of the following elements,
of which are mandatory: some of which are mandatory:
o <name> MUST occur, and defines the name of the component. This o <name> MUST occur, and defines the name of the component. This
name must be unique among the components of the LFB class. name must be unique among the components of the LFB class.
Example: "version". Example: "version".
o <synopsis> is also mandatory, and provides a brief description of o <synopsis> is also mandatory, and provides a brief description of
the purpose of the component. the purpose of the component.
o <optional/> is an optional element, and if present indicates that o <optional/> is an optional element, and if present indicates that
this component is optional. this component is optional.
skipping to change at page 66, line 40 skipping to change at page 67, line 43
When the data type is defined locally (unnamed type), one of the When the data type is defined locally (unnamed type), one of the
following elements can be used: <atomic>, <array>, <struct>, and following elements can be used: <atomic>, <array>, <struct>, and
<union>. Their usage is identical to how they are used inside <union>. Their usage is identical to how they are used inside
<dataTypeDef> elements (see Section 4.5). Some form of data type <dataTypeDef> elements (see Section 4.5). Some form of data type
definition MUST be included in the component definition. definition MUST be included in the component definition.
o The <defaultValue> element is optional, and if present is used to o The <defaultValue> element is optional, and if present is used to
specify a default value for a component. If a default value is specify a default value for a component. If a default value is
specified, the FE must ensure that the component has that value specified, the FE must ensure that the component has that value
when the LFB is initialized or reset. If a default value is not when the LFB is initialized or reset. If a default value is not
specified for a component, the CE may make no assumptions as to specified for a component, the CE MUST make no assumptions as to
what the value of the component will be upon initalization. The what the value of the component will be upon initalization. The
CE must either read the value, or set the value, if it needs to CE must either read the value, or set the value, if it needs to
know what it is. know what it is.
o The <description> element may also appear. If included, it o The <description> element MAY also appear. If included, it
provides a longer description of the meaning or usage of the provides a longer description of the meaning or usage of the
particular component being defined. particular component being defined.
The <component> element also MUST have an componentID attribute, The <component> element also MUST have an componentID attribute,
which is a numeric value used by the ForCES protocol. which is a numeric value used by the ForCES protocol.
In addition to the above elements, the <component> element includes 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: "read-only", "read-write", "write-only", "read-reset", and values: "read-only", "read-write", "write-only", "read-reset", and
"trigger-only". The default access mode is "read-write". "trigger-only". The default access mode is "read-write".
skipping to change at page 67, line 43 skipping to change at page 68, line 44
<defaultValue>10</defaultValue> <defaultValue>10</defaultValue>
</component> </component>
</components> </components>
The first component ("foo") is a read-only 32-bit unsigned integer, The first component ("foo") is a read-only 32-bit unsigned integer,
defined by referring to the built-in "uint32" atomic type. The defined by referring to the built-in "uint32" atomic type. The
second component ("bar") is also an integer, but uses the <atomic> second component ("bar") is also an integer, but uses the <atomic>
element to provide additional range restrictions. This component has element to provide additional range restrictions. This component has
access mode of read-write allowing it to be both read and written. A access mode of read-write allowing it to be both read and written. A
default value of 10 is provided for bar. although the access for bar default value of 10 is provided for bar. although the access for bar
is read-write, some implementations may offer only more restrictive is read-write, some implementations MAY offer only more restrictive
access, and this would be reported in the component properties. access, and this would be reported in the component properties.
Note that not all components 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 components anyway. The FORCES protocol existent or non-permitted components anyway. The ForCES protocol
mechanisms should include appropriate error indicators for this case. mechanisms should include appropriate error indicators for this case.
The mechanism defined above for non-supported component can also The mechanism defined above for non-supported components 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 components. read-only components.
4.7.5. <capabilities> Element to Define LFB Capability Components 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 inherent example, the instance may have some limitations that are not inherent
from the class definition, but rather the result of some from the class definition, but rather the result of some
implementation limitations. Some of these limitations are captured implementation limitations. Some of these limitations are captured
skipping to change at page 72, line 14 skipping to change at page 73, line 14
</eventReports> </eventReports>
</event> </event>
</events> </events>
4.7.6.1. <eventTarget> Element 4.7.6.1. <eventTarget> Element
The <eventTarget> element contains information identifying a field in The <eventTarget> element contains information identifying a field in
the LFB that is to be monitored for events. the LFB that is to be monitored for events.
The <eventTarget> element contains one or more <eventField> each of The <eventTarget> element contains one or more <eventField> each of
which may be followed by one or more <eventSubscript> elements. Each which MAY be followed by one or more <eventSubscript> elements. Each
of these two elements represent the textual equivalent of a path of these two elements represent the textual equivalent of a path
select component of the LFB. select component of the LFB.
The <eventField> element contains the name of a component in the LFB The <eventField> element contains the name of a component in the LFB
or a component nested in an array or structure within the LFB. The or a component nested in an array or structure within the LFB. The
name used in <eventField> MUST identify a valid component within the name used in <eventField> MUST identify a valid component within the
containing LFB context. The first element in a <eventTarget> MUST be containing LFB context. The first element in a <eventTarget> MUST be
an <eventField> element. In the example shown, four LFB components an <eventField> element. In the example shown, four LFB components
foo, goo, bar and gah are used as <eventField>s. foo, goo, bar and gah are used as <eventField>s.
skipping to change at page 72, line 40 skipping to change at page 73, line 40
The first defined event, Foochanged, demonstrates how a scalar LFB The first defined event, Foochanged, demonstrates how a scalar LFB
component, foo, could be monitored to trigger an event. component, foo, could be monitored to trigger an event.
The second event, Goof1changed, demonstrates how a member of the The second event, Goof1changed, demonstrates how a member of the
complex structure goo could be monitored to trigger an event. complex structure goo could be monitored to trigger an event.
The events named NewbarEntry, Gah11changed and Gah10field1 The events named NewbarEntry, Gah11changed and Gah10field1
represent monitoring of arrays bar and gah in differing details. represent monitoring of arrays bar and gah in differing details.
If an <eventField> identifies a complex component then a further If an <eventField> identifies a complex component then a further
<eventField> may be used to refine the path to the target element. <eventField> MAY be used to refine the path to the target element.
Defined event Goof1changed demonstrates how a second <eventField> is Defined event Goof1changed demonstrates how a second <eventField> is
used to point to member f1 of the structure goo. used to point to member f1 of the structure goo.
If an <eventField> identifies an array then the following rules If an <eventField> identifies an array then the following rules
apply: apply:
o <eventSubscript> elements MUST be present as the next XML element o <eventSubscript> elements MUST be present as the next XML element
after an <eventField> which identifies an array component. after an <eventField> which identifies an array component.
<eventSubscript> MUST NOT occur other than after an array <eventSubscript> MUST NOT occur other than after an array
reference, as it is only meaningful in that context. reference, as it is only meaningful in that context.
o An <eventSubscript> may contain: o An <eventSubscript> contains either:
* A numeric value to indicate that the event applies to a * A numeric value to indicate that the event applies to a
specific entry (by index) of the array. As an example, event specific entry (by index) of the array. As an example, event
Gah11changed shows how table gah's index 11 is being targeted Gah11changed shows how table gah's index 11 is being targeted
for monitoring. for monitoring.
* It is expected that the more common usage is to have the event * It is expected that the more common usage is to have the event
being defined across all elements of the array (i.e a wildcard being defined across all elements of the array (i.e a wildcard
for all indices). In that case, the value of the for all indices). In that case, the value of the
<eventSubscript> MUST be a name rather than a numeric value. <eventSubscript> MUST be a name rather than a numeric value.
That same name can then be used as the value of That same name can then be used as the value of
<eventSubscript> in <eventReport> elements as described below. <eventSubscript> in <eventReport> elements as described below.
An example of a wild card table index is shown in event An example of a wild card table index is shown in event
NewBarentry where the <eventSubscript> value is named NewBarentry where the <eventSubscript> value is named
_barIndex_ _barIndex_
o An <eventField> may follow an <eventSubscript> to further refine o An <eventField> MAY follow an <eventSubscript> to further refine
the path to the target element (Note: this is in the same spirit the path to the target element (Note: this is in the same spirit
as the case where <eventField> is used to further refine as the case where <eventField> is used to further refine
<eventField> in the earlier example of a complex structure example <eventField> in the earlier example of a complex structure example
of Goof1changed). The example event Gah10field1 illustrates how of Goof1changed). The example event Gah10field1 illustrates how
the column field1 of table gah is monitored for changes. the column field1 of table gah is monitored for changes.
It should be emphasized that the name in an <eventSubscript> element It should be emphasized that the name in an <eventSubscript> element
in defined event NewbarEntry is not a component name. It is a in defined event NewbarEntry is not a component name. It is a
variable name for use in the <eventReport> elements (described in variable name for use in the <eventReport> elements (described in
Section 4.7.6.3) of the given LFB definition. This name MUST be Section 4.7.6.3) of the given LFB definition. This name MUST be
skipping to change at page 74, line 33 skipping to change at page 75, line 33
be delivered by the FE along with the notification of the occurrence be delivered by the FE along with the notification of the occurrence
of the event. of the event.
The <eventReports> element contains one or more <eventReport> The <eventReports> element contains one or more <eventReport>
elements. Each <eventReport> element identifies a piece of data from elements. Each <eventReport> element identifies a piece of data from
the LFB class to be reported. The notification carries that data as the LFB class to be reported. The notification carries that data as
if the collection of <eventReport> elements had been defined in a if the collection of <eventReport> elements had been defined in a
structure. The syntax is exactly the same as used in the structure. The syntax is exactly the same as used in the
<eventTarget> element, using <eventField> and <eventSubscript> <eventTarget> element, using <eventField> and <eventSubscript>
elements and so the same rules apply. Each <eventReport> element elements and so the same rules apply. Each <eventReport> element
thus MUST identify a component in the LFB class. <eventSubcript> may thus MUST identify a component in the LFB class. <eventSubcript> MAY
contain integers. If they contain names, they MUST be names from contain integers. If they contain names, they MUST be names from
<eventSubscript> elements of the <eventTarget> in the event. The <eventSubscript> elements of the <eventTarget> in the event. The
selection for the report will use the value for the subscript that selection for the report will use the value for the subscript that
identifies that specific element triggering the event. This can be identifies that specific element triggering the event. This can be
used to reference the component causing the event, or to reference used to reference the component causing the event, or to reference
related information in parallel tables. related information in parallel tables.
In the example shown, in the case of the event Foochanged, the report In the example shown, in the case of the event Foochanged, the report
will carry the value of foo; in the case of the defined event will carry the value of foo; in the case of the defined event
NewbarEntry acting on LFB component bar, which is an array, there are NewbarEntry acting on LFB component bar, which is an array, there are
skipping to change at page 75, line 30 skipping to change at page 76, line 30
information it needs to understand the event. It does not represent information it needs to understand the event. It does not represent
all possible information needs. all possible information needs.
If any components referenced by the eventReport are optional, then If any components referenced by the eventReport are optional, then
the report MUST use a protocol format that supports optional elements the report MUST use a protocol format that supports optional elements
and allows for the non-existence of such elements. Any components and allows for the non-existence of such elements. Any components
which do not exist are not reported. which do not exist are not reported.
4.7.6.4. Runtime control of events 4.7.6.4. Runtime control of events
High level view on the declaration and operation of LFB events is The high level view of the declaration and operation of LFB events is
described in Section 3.2.5. described in Section 3.2.5.
The <eventTarget> provides additional components used in the path to The <eventTarget> provides additional components used in the path to
reference the event. The path constitutes the baseID for events, reference the event. The path constitutes the baseID for events,
followed by the ID for the specific event, followed by a value for followed by the ID for the specific event, followed by a value for
each <eventSubscript> element if it exists in the <eventTarget>. each <eventSubscript> element if it exists in the <eventTarget>.
The event path will uniquely identify a specific occurrence of the The event path will uniquely identify a specific occurrence of the
event in the event notification to the CE. In the example provided event in the event notification to the CE. In the example provided
above, at the end of Section 4.7.6, a notification with path of 7.7 above, at the end of Section 4.7.6, a notification with path of 7.7
skipping to change at page 76, line 39 skipping to change at page 77, line 39
receiving an event when subscript/index 100 table entry is created. receiving an event when subscript/index 100 table entry is created.
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.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 explain what the LFB does to a human user.
4.8. Properties 4.8. Properties
Components of LFBs have properties which are important to the CE. Components of LFBs have properties which are important to the CE.
The most important property is the existence / readability / The most important property is the existence / readability /
writeability of the element. Depending on the type of the component, writeability of the element. Depending on 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 the information. There is a base class of property information. For the
array, alias, and event components there are subclasses of property array, alias, and event components there are subclasses of property
information providing additional fields. This information is information providing additional fields. This information is
accessed by the CE (and updated where applicable) via the PL accessed by the CE (and updated where applicable) via the ForCES
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 dataTypeDef for The basic property definition, along with the scalar dataTypeDef for
accessibility is below. Note that this access permission information accessibility is below. Note that this access permission information
is generally read-only. is generally read-only.
skipping to change at page 78, line 26 skipping to change at page 79, line 26
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name> Read-Only </name> <name> Read-Only </name>
<synopsis> <synopsis>
Access to the component is read only Access to the component is read only
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>Write-Only</name> <name>Write-Only</name>
<synopsis> <synopsis>
The component may be written, but not read The component MAY be written, but not read
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="3"> <specialValue value="3">
<name>Read-Write</name> <name>Read-Write</name>
<synopsis> <synopsis>
The component may be read or written The component 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>
<component componentID="1"> <component componentID="1">
skipping to change at page 79, line 39 skipping to change at page 80, line 39
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </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 included maximum octet length for the element. The maximum length is included
because an FE implementation may limit a string to be shorter than because an FE implementation MAY limit a string to be shorter than
the limit in the LFB Class definition. the limit in the LFB Class definition.
<dataTypeDef> <dataTypeDef>
<name>stringElementProperties</name> <name>stringElementProperties</name>
<synopsis>string Element Properties definition </synopsis> <synopsis>string Element Properties definition </synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>stringLength</name> <name>stringLength</name>
<synopsis>the number of octets in the string</synopsis> <synopsis>the number of octets in the string</synopsis>
skipping to change at page 80, line 28 skipping to change at page 81, line 28
the maximum number of octets in the string the maximum number of octets in the string
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </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>
<synopsis>octetstring Element Properties definition <synopsis>octetstring Element Properties definition
</synopsis> </synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>octetstringLength</name> <name>octetstringLength</name>
skipping to change at page 81, line 12 skipping to change at page 82, line 12
</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 generated. One is the subscription field. 0 means no notification is generated.
Any non-zero value (typically 1 is used) means that a notification is Any non-zero value (typically 1 is used) means that a notification is
generated. The hysteresis field is used to suppress generation of generated. The hysteresis field is used to suppress generation of
notifications for oscillations around a condition value, and is notifications for oscillations around a condition value, and is
described in the text for events. The threshold field is used for described below (Section 4.8.5.2). The threshold field is used for
the <eventGreaterThan/> and <eventLessThan/> conditions. It the <eventGreaterThan/> and <eventLessThan/> conditions. It
indicates the value to compare the event target against. Using the indicates the value to compare the event target against. Using the
properties allows the CE to set the level of interest. FEs which do properties allows the CE to set the level of interest. FEs which do
not supporting setting the threshold for events will make this field not support setting the threshold for events will make this field
read-only. read-only.
<dataTypeDef> <dataTypeDef>
<name>eventElementProperties</name> <name>eventElementProperties</name>
<synopsis>event Element Properties definition</synopsis> <synopsis>event Element Properties definition</synopsis>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<component componentID="2"> <component componentID="2">
<name>registration</name> <name>registration</name>
<synopsis> <synopsis>
skipping to change at page 83, line 4 skipping to change at page 84, line 4
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
<dataTypeDef> <dataTypeDef>
4.8.5.1. Common Event Filtering 4.8.5.1. Common Event Filtering
The event properties have values for controlling several filter The event properties have values for controlling several filter
conditions. Support of these conditions is optional, but all conditions. Support of these conditions is optional, but all
conditions SHOULD be supported. Events which are reliably known not conditions SHOULD be supported. Events which are reliably known not
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.
Currently, three different filter condition variables are defined. Currently, three different filter condition variables are defined.
These are eventCount, eventInterval, and eventHysteresis. Setting These are eventCount, eventInterval, and eventHysteresis. Setting
the condition variables to 0 (their default value) means that the the condition variables to 0 (their default value) means that the
condition is not checked. condition is not checked.
Conceptually, when an event is triggered, all configured conditions Conceptually, when an event is triggered, all configured conditions
are checked. If no filter conditions are triggered, or if any are checked. If no filter conditions are triggered, or if any
trigger conditions are met, the event notification is generated. If trigger conditions are met, the event notification is generated. If
skipping to change at page 84, line 17 skipping to change at page 85, line 17
again until the field first becomes less than or equal to T - V, again until the field first becomes less than or equal to T - V,
and then exceeds T. and then exceeds T.
o For a <eventLessThan/> condition with threshold T, once the event o For a <eventLessThan/> condition with threshold T, once the event
has been generate at least once it MUST NOT be generated again has been generate at least once it MUST NOT be generated again
until the field first becomes greater than or equal to T + V, and until the field first becomes greater than or equal to T + V, and
then becomes less than T. 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.
A conceptual implementation (not required) for this might be an A conceptual implementation (not required) for this might be an
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 set to 0.
when a notification is generated can be thought of as setting the
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 represents Events MAY have a time filtering condition. This property represents
the minimum time interval (in the absence of some other filtering the minimum time interval (in the absence of some other filtering
condition being passed) between generating notifications of detected condition being passed) between generating notifications of detected
events. This condition MUST only be passed if the time since the events. This condition MUST only be passed if the time since the
last notification of the event is longer than the configured interval last notification of the event is longer than the 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
skipping to change at page 85, line 26 skipping to change at page 86, line 25
<component componentID="3"> <component componentID="3">
<name>targetLFBInstance</name> <name>targetLFBInstance</name>
<synopsis>the instance ID of the alias target</synopsis> <synopsis>the instance ID of the alias target</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>targetComponentPath</name> <name>targetComponentPath</name>
<synopsis> <synopsis>
the path to the component 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 ForCES protocol,
[2]. [2].
</synopsis> </synopsis>
<typeRef>octetstring[128]</typeRef> <typeRef>octetstring[128]</typeRef>
</component> </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"?>
skipping to change at page 106, line 29 skipping to change at page 107, line 25
of the SupportedLFB that may be connected to the NeighborLFB. As of the SupportedLFB that may be connected to the NeighborLFB. As
with CanOccurAfters, viaPort may have multiple entries if multiple with CanOccurAfters, viaPort may have multiple entries if multiple
output ports may legitimately connect to the given NeighborLFB class. output ports may legitimately connect to the given NeighborLFB class.
[And a similar set of uniqueness constraints apply to the [And a similar set of uniqueness constraints apply to the
CanOccurBefore clauses, even though an LFB may occur both in CanOccurBefore clauses, even though an LFB may occur both in
CanOccurAfter and CanOccurBefore.] CanOccurAfter and CanOccurBefore.]
5.2.2.8. UseableParentLFBClasses 5.2.2.8. UseableParentLFBClasses
The UseableParentLFBClasses array, if present, i sued to hold a list The UseableParentLFBClasses array, if present, is used to hold a list
of parent LFB class IDs. All the entries in the list must be IDs of of parent LFB class IDs. All the entries in the list must be IDs of
classes from which the SupportedLFB Class being described has classes from which the SupportedLFB Class being described has
inherited (either directly, or through an intermediate parent.) (If inherited (either directly, or through an intermediate parent.) (If
an FE includes improper values in this list, improper manipulations an FE includes improper values in this list, improper manipulations
by the CE are likely, and operational failures are likely.) In by the CE are likely, and operational failures are likely.) In
addition, the FE, by including a given class in the last, is addition, the FE, by including a given class in the last, is
indicating to the CE that a given parent class may be used to indicating to the CE that a given parent class may be used to
manipulate an instance of this supported LFB class. manipulate an instance of this supported LFB class.
By allowing such substitution, the FE allows for the case where an By allowing such substitution, the FE allows for the case where an
skipping to change at page 108, line 24 skipping to change at page 109, line 20
sufficient information to identify precisely the end points of a sufficient information to identify precisely the end points of a
link. The FromLFBID and ToLFBID components specify the LFB instances link. The FromLFBID and ToLFBID components specify the LFB instances
at each end of the link, and MUST reference LFBs in the LFB instance at each end of the link, and MUST reference LFBs in the LFB instance
table. The FromPortGroup and ToPortGroup MUST identify output and table. The FromPortGroup and ToPortGroup MUST identify output and
input port groups defined in the LFB classes of the LFB instances input port groups defined in the LFB classes of the LFB instances
identified by FromLFBID and ToLFBID. The FromPortIndex and identified by FromLFBID and ToLFBID. The FromPortIndex and
ToPortIndex components select the entries from the port groups that ToPortIndex components select the entries from the port groups that
this link connects. All links are uniquely identified by the this link connects. All links are uniquely identified by the
FromLFBID, FromPortGroup, and FromPortIndex fields. Multiple links FromLFBID, FromPortGroup, and FromPortIndex fields. Multiple links
may have the same ToLFBID, ToPortGroup, and ToPortIndex as this model may have the same ToLFBID, ToPortGroup, and ToPortIndex as this model
supports fan in of inter- LFB links but not fan out. supports fan-in of inter- LFB links but not fan-out.
5.3.4. FENeighbors and FEConfiguredNeighborType 5.3.4. FENeighbors and FEConfiguredNeighborType
The FENeighbors component is an array of information about manually The FENeighbors component is an array of information about manually
configured adjacencies between this FE and other FEs. The content of configured adjacencies between this FE and other FEs. The content of
the array is defined by the FEConfiguredNeighborType dataTypeDef. the array is defined by the FEConfiguredNeighborType dataTypeDef.
This array is intended to capture information that may be configured This array is intended to capture information that may be configured
on the FE and is needed by the CE, where one array entry corresponds on the FE and is needed by the CE, where one array entry corresponds
to each configured neighbor. Note that this array is not intended to to each configured neighbor. Note that this array is not intended to
skipping to change at page 111, line 5 skipping to change at page 111, line 48
Items 6) and 7) are "command" types of exchanges, where the main flow Items 6) and 7) are "command" types of exchanges, where the main flow
of information is from the CEs to the FEs. Messages in Item 6) (the of information is from the CEs to the FEs. Messages in Item 6) (the
LFB re-configuration commands) are expected to be used frequently. LFB re-configuration commands) are expected to be used frequently.
Item 7) (LFB topology re-configuration) is needed only if dynamic LFB Item 7) (LFB topology re-configuration) is needed only if dynamic LFB
topologies are supported by the FEs and it is expected to be used topologies are supported by the FEs and it is expected to be used
infrequently. infrequently.
The inter-FE topology (item 1 above) can be determined by the CE in The inter-FE topology (item 1 above) can be determined by the CE in
many ways. Neither this document nor the ForCES Protocol [2] many ways. Neither this document nor the ForCES Protocol [2]
document mandates a specific mechanism. The LFB Class definition document mandates a specific mechanism. The LFB Class definition
does include the capability for an FE to be configured with, and does include the capability for an FE to be configured with, and to
provides to the CE in response to a query, the identity of its provide to the CE in response to a query, the identity of its
neighbors. There may also be defined specific LFB classes and neighbors. There may also be defined specific LFB classes and
protocols for neighbor discovery. Routing protocols may be used by protocols for neighbor discovery. Routing protocols may be used by
the CE for adjacency determination. The CE may be configured with the CE for adjacency determination. The CE may be configured with
the relevant information. the relevant information.
The relationship between the FE model and the seven post-association The relationship between the FE model and the seven post-association
messages are visualized in Figure 12: messages are visualized in Figure 12:
+--------+ +--------+
..........-->| CE | ..........-->| CE |
skipping to change at page 127, line 22 skipping to change at page 127, line 48
This would set the registration for the event on all entries in the This would set the registration for the event on all entries in the
table. It would also set the threshold for the event, causing table. It would also set the threshold for the event, causing
reporting if the power falls below 15. (Presumably, the CE knows reporting if the power falls below 15. (Presumably, the CE knows
what the scale is for power, and has chosen 15 as a meaningful what the scale is for power, and has chosen 15 as a meaningful
problem level.) problem level.)
If a laser oscillates in power near the 15 mark, one could get a lot If a laser oscillates in power near the 15 mark, one could get a lot
of notifications. (If it flips back and forth between 14 and 15, of notifications. (If it flips back and forth between 14 and 15,
each flip down will generate an event.) Suppose that the CE decides each flip down will generate an event.) Suppose that the CE decides
to suppress this oscillation somewhat on laser channel 5. It can do to suppress this oscillation somewhat on laser channel 5. It can do
this by setting the variance property on that event. The request this by setting the hysteresis property on that event. The request
would look like: would look like:
T = SET-PROP T = SET-PROP
Path-TLV: flags=0, length = 3, path = 61.4.5 Path-TLV: flags=0, length = 3, path = 61.4.5
Path-TLV: flags = property-field, length = 1, path = 4 Path-TLV: flags = property-field, length = 1, path = 4
Content = 2 (hysteresis) Content = 2 (hysteresis)
Setting the hysteresis to 2 suppress a lot of spurious notifications. Setting the hysteresis to 2 suppress a lot of spurious notifications.
When the level first falls below 10, a notification is generated. If When the level first falls below 10, a notification is generated. If
the power level increases to 10 or 11, and then falls back below 10, the power level increases to 10 or 11, and then falls back below 10,
an event will not be generated. The power has to recover to at least an event will not be generated. The power has to recover to at least
12 and fall back below 10 to generate another event. One common 12 and fall back below 10 to generate another event. One common
cause of this form of oscillation is when the actual value is right cause of this form of oscillation is when the actual value is right
near the border. If it is really 9.5, tiny changes might flip it near the border. If it is really 9.5, tiny changes might flip it
back and forth between 9 and 10. A variance level of 1 will suppress back and forth between 9 and 10. A hysteresis level of 1 will
this sort of condition. Many other events have oscillations that are suppress this sort of condition. Many other events have oscillations
somewhat wider, so larger variance settings can be used with those. that are somewhat wider, so larger hysteresis settings can be used
with those.
9. IANA Considerations 9. IANA Considerations
The ForCES model creates the need for a unique XML namespace for The ForCES model creates the need for a unique XML namespace for
ForCES library definition usage, and unique class names and numeric ForCES library definition usage, and unique class names and numeric
class identifiers. class identifiers.
9.1. URN Namespace Registration 9.1. URN Namespace Registration
IANA is requested to register a new XML namespace, as per the IANA is requested to register a new XML namespace, as per the
skipping to change at page 128, line 20 skipping to change at page 128, line 48
XML: none, this is an XML namespace XML: none, this is an XML namespace
9.2. LFB Class Names and LFB Class Identifiers 9.2. LFB Class Names and LFB Class Identifiers
In order to have well defined ForCES LFB Classes, and well defined In order to have well defined ForCES LFB Classes, and well defined
identifiers for those classes, a registry of LFB Class names, identifiers for those classes, a registry of LFB Class names,
corresponding class identifiers, and the document which defines the corresponding class identifiers, and the document which defines the
LFB Class is needed. The registry policy is simply first come first LFB Class is needed. The registry policy is simply first come first
served(FCFS) with regard to LFB Class names. With regard to LFB served(FCFS) with regard to LFB Class names. With regard to LFB
Class identifiers, identifiers less than 65536 are reserved for Class identifiers, identifiers less than 65536 are reserved for
assignment by IETF Standards Track RFCs. Identifiers above 65536 are assignment by IETF Standards Track RFCs. Identifiers above 65536, in
available for assignment on a first come, first served basis. All the 32 bit class ID space, are available for assignment on a first
Registry entries must be documented in a stable, publicly available come, first served basis. All Registry entries must be documented in
form. a stable, publicly available form.
Since this registry provides for FCFS allocation of a portion of the Since this registry provides for FCFS allocation of a portion of the
class identifier space, it is necessary to define rules for naming class identifier space, it is necessary to define rules for naming
classes that are using that space. As these can be defined by classes that are using that space. As these can be defined by
anyone, the needed rule is to keep the FCFS class names from anyone, the needed rule is to keep the FCFS class names from
colliding with IETF defined class names. Therefore, all FCFS class colliding with IETF defined class names. Therefore, all FCFS class
names MUST start with the string "Ext-". names MUST start with the string "Ext-".
Table 1 tabulates the above information. Table 1 tabulates the above information.
 End of changes. 152 change blocks. 
296 lines changed or deleted 345 lines changed or added

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