draft-ietf-forces-model-08.txt   draft-ietf-forces-model-09.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Expires: April 9, 2008 E. Deleganes Expires: June 23, 2008 E. Deleganes
Intel Corp. Intel Corp.
October 7, 2007 J. Hadi Salim
Znyx Networks
December 21, 2007
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-08.txt draft-ietf-forces-model-09.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 37
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 April 9, 2008. This Internet-Draft will expire on June 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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. The Forwarding and Control Element Separation (ForCES) protocol. The
model represents the capabilities, state and configuration of model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so forwarding elements within the context of the ForCES protocol, so
that control elements (CEs) can control the FEs accordingly. More that control elements (CEs) can control the FEs accordingly. More
specifically, the model describes the logical functions that are specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected. This FE model is these functions are or can be interconnected. This FE model is
intended to satisfy the model requirements specified in the ForCES intended to satisfy the model requirements specified in the ForCES
requirements draft,RFC3654 [2]. requirements document, RFC3654 [2].
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements on the FE model . . . . . . . . . . . . . . 7 2.1. Requirements on the FE model . . . . . . . . . . . . . . 7
2.2. The FE Model in Relation to FE Implementations . . . . . 8 2.2. The FE Model in Relation to FE Implementations . . . . . 8
2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8 2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8
2.4. Modeling Language for the FE Model . . . . . . . . . . . 9 2.4. Modeling Language for the FE Model . . . . . . . . . . . 9
2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9 2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9
3. FE Model Concepts . . . . . . . . . . . . . . . . . . . . . . 10 3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 9
3.1. FE Capability Model and State Model . . . . . . . . . . . 10 3.1. ForCES Capability Model and State Model . . . . . . . . . 11
3.2. LFB (Logical Functional Block) Modeling . . . . . . . . . 13 3.1.1. FE Capability Model and State Model . . . . . . . . . 11
3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 16 3.1.2. Relating LFB and FE Capability and State Model . . . 13
3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 19 3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 13
3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 21 3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17
3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20
3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 29 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 22
3.2.6. LFB Component Properties . . . . . . . . . . . . . . 29 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 23
3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 30 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 25
3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 30 3.2.6. LFB Component Properties . . . . . . . . . . . . . . 26
3.3. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 31 3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 27
3.3.1. Alternative Approaches for Modeling FE Datapaths . . 32 3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 27
3.3.2. Configuring the LFB Topology . . . . . . . . . . . . 36 3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 28
4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40 3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 30
3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 31
3.4.1. Alternative Approaches for Modeling FE Datapaths . . 31
3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 35
4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 39
4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 40 4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 40
4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 42 4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 41
4.4. <frameDefs> Element for Frame Type Declarations . . . . . 43 4.4. <frameDefs> Element for Frame Type Declarations . . . . . 42
4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 43 4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 42
4.5.1. <typeRef> Element for Aliasing Existing Data Types . 46 4.5.1. <typeRef> Element for Aliasing Existing Data Types . 45
4.5.2. <atomic> Element for Deriving New Atomic Types . . . 47 4.5.2. <atomic> Element for Deriving New Atomic Types . . . 46
4.5.3. <array> Element to Define Arrays . . . . . . . . . . 47 4.5.3. <array> Element to Define Arrays . . . . . . . . . . 46
4.5.4. <struct> Element to Define Structures . . . . . . . . 51 4.5.4. <struct> Element to Define Structures . . . . . . . . 50
4.5.5. <union> Element to Define Union Types . . . . . . . . 52 4.5.5. <union> Element to Define Union Types . . . . . . . . 51
4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 52 4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 51
4.5.7. Augmentationst . . . . . . . . . . . . . . . . . . . 53 4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 52
4.6. <metadataDefs> Element for Metadata Definitions . . . . . 54 4.6. <metadataDefs> Element for Metadata Definitions . . . . . 53
4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 55 4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 54
4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 57 4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 56
4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 58 4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 57
4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 60 4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 59
4.7.4. <components> Element to Define LFB Operational 4.7.4. <components> Element to Define LFB Operational
Components . . . . . . . . . . . . . . . . . . . . . 63 Components . . . . . . . . . . . . . . . . . . . . . 62
4.7.5. <capabilities> Element to Define LFB Capability 4.7.5. <capabilities> Element to Define LFB Capability
Components . . . . . . . . . . . . . . . . . . . . . 65 Components . . . . . . . . . . . . . . . . . . . . . 64
4.7.6. <events> Element for LFB Notification Generation . . 67 4.7.6. <events> Element for LFB Notification Generation . . 66
4.7.7. <description> Element for LFB Operational 4.7.7. <description> Element for LFB Operational
Specification . . . . . . . . . . . . . . . . . . . . 70 Specification . . . . . . . . . . . . . . . . . . . . 73
4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 70 4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 73
4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 71 4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 73
4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 73 4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 75
4.8.3. String Properties . . . . . . . . . . . . . . . . . . 73 4.8.3. String Properties . . . . . . . . . . . . . . . . . . 75
4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 74 4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 76
4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 75 4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 77
4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 78 4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 80
4.9. XML Schema for LFB Class Library Documents . . . . . . . 79 4.9. XML Schema for LFB Class Library Documents . . . . . . . 81
5. FE Components and Capabilities . . . . . . . . . . . . . . . 90 5. FE Components and Capabilities . . . . . . . . . . . . . . . 92
5.1. XML for FEObject Class definition . . . . . . . . . . . . 91 5.1. XML for FEObject Class definition . . . . . . . . . . . . 93
5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 97 5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 99
5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 97 5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 99
5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 98 5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 100
5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 100 5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 102
5.3.1. FEStatus . . . . . . . . . . . . . . . . . . . . . . 100 5.3.1. FEStatus . . . . . . . . . . . . . . . . . . . . . . 102
5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 100 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 103
5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 101 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 103
5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 101 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 103
6. Satisfying the Requirements on FE Model . . . . . . . . . . . 102 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 104
7. Using the FE model in the ForCES Protocol . . . . . . . . . . 103 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 105
7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 105 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 107
7.2. FE Capability Declarations . . . . . . . . . . . . . . . 106 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 108
7.3. LFB Topology and Topology Configurability Query . . . . . 107 7.3. LFB Topology and Topology Configurability Query . . . . . 109
7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 107 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 109
7.5. State Query of LFB Attributes . . . . . . . . . . . . . . 108 7.5. State Query of LFB Attributes . . . . . . . . . . . . . . 110
7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 109 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 111
7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 109 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 111
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 111
8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 116 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 118
8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 117 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 119
8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 118 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 120
8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 118 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 120
8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 119 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 121
8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 119 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 121
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 121 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 123
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 121 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 123
12. Security Considerations . . . . . . . . . . . . . . . . . . . 121 12. Security Considerations . . . . . . . . . . . . . . . . . . . 124
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 124
13.1. Normative References . . . . . . . . . . . . . . . . . . 121 13.1. Normative References . . . . . . . . . . . . . . . . . . 124
13.2. Informative References . . . . . . . . . . . . . . . . . 122 13.2. Informative References . . . . . . . . . . . . . . . . . 124
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125
Intellectual Property and Copyright Statements . . . . . . . . . 124 Intellectual Property and Copyright Statements . . . . . . . . . 126
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
accordance with RFC2119 [1]. Such terminology is used in describing accordance with RFC2119 [1]. Such terminology is used in describing
the required behavior of ForCES forwarding elements or control the required behavior of ForCES forwarding elements or control
elements in supporting or manipulating information described in this elements in supporting or manipulating information described in this
model. model.
Terminology associated with the ForCES requirements is defined in Terminology associated with the ForCES requirements is defined in
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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. Four types of information LFB, plus the associated data definition. XML is used to provide a
are defined in the LFB model. The core part of the LFB model is the formal definition of the LFB model. Four types of information are
LFB class definitions; the other three types define the associated defined in the LFB model. The core part of the LFB model is the LFB
data including common data types, supported frame formats and class definitions; the other three types define the associated data
metadata. including common data types, supported frame formats and metadata.
Element -- Element is generally used in this document in accordance
with the XML usage of the term. It refers to an XML tagged part of
an XML document. For a precise definition, please see the full set
of XML specifications from the W3C. This term is included in this
list for completeness because ForCES formal model uses XML.
Attribute -- Attribute is used in the ForCES formal modelling in
accordance with standard XML usage of the term. i.e to provide
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.
LFB Component -- Operational parameters of the LFBs that must be ForCES Component -- a ForCES Component is a well defined, uniquely
visible to the CEs are conceptualized in the FE model as the LFB identifiable and addressable ForCES model building block. A
components. The LFB components include: flags, single parameter component has a 32-bit ID, name, type and an optional synopsis
arguments, complex arguments, and tables that the CE can read or/and description.
write via the ForCES protocol.
Structure Component -- Forces allows for complex data structures to
be used in its data definitions. Generally, these include tables and
Structures. The individual parts which make up a structured set of
data are referred to as Structure Components. These can themselves
be of any valid data type, including tables and structures.
Component -- Often in describing the forces model and its
operational, it is useful to refer to the parts of an LFB or
structure, without regard to what they are part of. The term
component by itself will be used to refer to these parts. If the
context is unclear, but it is necessary to refer explicitly to either
LFB Components or Structure Components, then the modifying word will
be present. When the correct prefix is clear from context, or when
no differentiation is needed, no modifier will be used.
Element -- Element is generally used in this document in accordance LFB Component -- A ForCES component that defines the Operational
with the XML usage of the term. It refers to an XML tagged part of parameters of the LFBs that must be visible to the CEs.
an XML document. For a precise definition, please see the full set
of XML specifications from the W3C. This term is included in this
list for completeness, and because earlier versions of this document
used the term element inconsistently. The other use of the term
element is in terms of the FE and CE (Forwarding Element and Control
Element.) As those are not textual or data structure items, context
provides sufficient clarity for this usage.
Attribute -- Attribute is used in the XML sense of attribute Structure Component -- A ForCES component that defines complex data
information include in an XML tag. structures to be used in LFB data definitions. Generally, these
include tables and Structures. The individual parts which make up a
structured set of data are referred to as Structure Components.
These can themselves be of any valid data type, including tables and
structures.
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 are interconnected. Sometimes this is called inter-FE topology,
to be distinguished from intra-FE topology (i.e., LFB topology). An to be distinguished from intra-FE topology (i.e., LFB topology). An
skipping to change at page 9, line 38 skipping to change at page 9, line 28
the LFB Library. Documents which describe LFB Classes are therefore the LFB Library. Documents which describe LFB Classes are therefore
referred to as LFB Library documents. referred to as LFB Library documents.
Human readability was the most important factor considered when Human readability was the most important factor considered when
selecting the specification language, whereas encoding, decoding and selecting the specification language, whereas encoding, decoding and
transmission performance was not a selection factor. The encoding transmission performance was not a selection factor. The encoding
method for over the wire transport is not dependent on the method for over the wire transport is not dependent on the
specification language chosen and is outside the scope of this specification language chosen and is outside the scope of this
document and up to the ForCES protocol to define. document and up to the ForCES protocol to define.
XML was chosen as the specification language in this document, XML is chosen as the specification language in this document, because
because XML has the advantage of being both human and machine XML has the advantage of being both human and machine readable with
readable with widely available tools support. This document uses XML widely available tools support. This document uses XML Schema to
Schema to define the structure of the LFB Library documents, as define the structure of the LFB Library documents, as defined in [9]
defined in [9] and [10]. While these LFB Class definitions are not and [10]. While these LFB Class definitions are not sent in the
sent in the Forces protocol, these definitions comply with the ForCES protocol, these definitions comply with the recommendations in
recommendations in RFC3470 [9] on the use of XML in IETF protocols. 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
the FE model, detailing the two major aspects of the FE model: a the FE model, detailing the two major aspects of the FE model: a
general LFB model and a definition of the FE Object LFB, with its general LFB model and a definition of the FE Object LFB, with its
components, including FE capabilities and LFB topology information. components, including FE capabilities and LFB topology information.
Section 6 directly addresses the model requirements imposed by the Section 6 directly addresses the model requirements imposed by the
ForCES requirement draft[1] while Section 7 explains how the FE model ForCES requirements defined in RFC3654 [2] while Section 7 explains
should be used in the ForCES protocol. how the FE model should be used in the ForCES protocol.
3. FE Model Concepts 3. ForCES Model Concepts
Some of the important concepts used throughout this document are Some of the important ForCES concepts used throughout this document
introduced in this section. Section 3.1 explains the difference are introduced in this section. These include the capability and
between a state model and a capability model, and describes how the state abstraction, the FE and LFB model construction, and the unique
two can be combined in the FE model.Section 3.2 introduces the addressing of the different model structures. Details of these
concept of LFBs (Logical Functional Blocks) as the basic functional aspects are described in Section 4 and Section 5. The intent of this
building blocks in the FE model.Section 3.3 discusses the logical section is to discuss these concepts at the high level and lay the
inter-connection and ordering between LFB instances within an FE, foundation for the detailed description in the following sections.
that is, the LFB topology.
The FE model proposed in this document has two major aspects: the LFB The ForCES FE model includes both a capability and a state
model and FE Object defintion whose components include FE capability abstraction.
information and LFB topology information. The LFB model provides the
content and data structures to define each individual LFB class. The
FE Object class defines the components to provide information at the
FE level, particularly the capabilities of the FE at a coarse level.
Part of the FE level information is the LFB topology, which expresses
the logical inter- connection between the LFB instances along the
datapath(s) within the FE. Details of these 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 foundation for the
detailed description in the following sections.
3.1. FE Capability Model and State Model o The FE/LFB capability model describes the capabilities and
capacities of an FE/LFB by specifying the variation in functions
supported and any limitations. Capacity describes the limits of
specific components (example would be a table size limit).
The ForCES FE model includes both a capability and a state model. o The state model describes the current state of the FE/LFB, that
The FE capability model describes the capabilities and capacities of is, the instantaneous values or operational behavior of the FE/
an FE by specifying the variation in functions supported and any LFB.
limitations. The FE state model describes the current state of the
FE, that is, the instantaneous values or operational behavior of the Section 3.1 explains the difference between a capability model and a
FE. Equally, this concept applies to LFB classes, where the state model, and describes how the two can be combined in the FE
capability information indicates what this FE is capable of providing model.
using the specific LFB Class, or even the specific component (such as
the table size limits.) Capability information is always read-only, The ForCES model construction proposed in this document has two major
as it describes what the FE / LFB can provide, not what the CE has hierarchies. At the lower layer, an individual LFB class definition
requested. models the distinct manageable feature of an FE. At a higher
abstraction, the FE is laid out to constitute many LFB abstractions.
o The LFB model provides the content and data structures to define
each individual LFB class. Each LFB model class formally defines
the operational LFB components, LFB capabilities, and LFB events.
Essentially, Section 3.2 introduces the concept of LFBs as the
basic functional building blocks in the ForCES model.
o The FE model provides a definition whose components include FE
capability information, the different LFBs and their topology
information. For consistency, the FE Object class is defined
using the LFB model. The FE Object class defines the components
to provide information at the FE level, particularly the
capabilities of the FE at a coarse level. Part of the FE level
information is the LFB topology, which expresses the logical
inter-connection between the LFB instances along the datapath(s)
within the FE. Section 3.3 discusses the LFB topology.
The ForCES model allows for unique addressing of the different
construct within its definition.
The ForCES protocol encapsulates target address(es) to eventually get
to a fine-grained entity being referenced by the CE. The addressing
hierarchy is broken into the following:
o An FE is uniqueuely identified by a 32 bit FEID.
o Each Class of LFB is uniquely identified by a 32 bit LFB ClassID.
The LFB ClassIDs are global within the Network Element and may be
issued by IANA.
o Within an FE, there can be multiple instances of each LFB class.
Each LFB Class instance is identified by a 32 bit identities which
are unique within a particular LFB class on that FE.
o All the components within an LFB instance are further defined
using 32 bit identifiers.
Refer to Section 3.3 for more details where we go into details on
addressing.
3.1. ForCES Capability Model and State Model
Capability and state modelling applies to both the FE and LFB
abstraction.
Figure 1 shows the concepts of FE state, capabilities and
configuration in the context of CE-FE communication via the ForCES
protocol.
+-------+ +-------+
| | FE capabilities: what it can/cannot do. | |
| |<-----------------------------------------| |
| | | |
| CE | FE state: what it is now. | FE |
| |<-----------------------------------------| |
| | | |
| | FE configuration: what it should be. | |
| |----------------------------------------->| |
+-------+ +-------+
Figure 1: Illustration of FE capabilities, state and configuration
exchange in the context of CE-FE communication via ForCES.
3.1.1. FE Capability Model and State Model
Conceptually, the FE capability model tells the CE which states are Conceptually, the FE capability model tells the CE which states are
allowed on an FE, with capacity information indicating certain allowed on an FE, with capacity information indicating certain
quantitative limits or constraints. Thus, the CE has general quantitative limits or constraints. Thus, the CE has general
knowledge about configurations that are applicable to a particular knowledge about configurations that are applicable to a particular
FE. For example, an FE capability model may describe the FE at a FE.
coarse level such as:
o this FE can handle IPv4 and IPv6 forwarding; 3.1.1.1. FE Capability Model
o this FE can perform classification on the following fields: source The FE capability model may be used to describe an FE at a coarse
IP address, destination IP address, source port number, level. For example, an FE may be defined as follows:
o the FE can handle IPv4 and IPv6 forwarding;
o the FE can perform classification based on the following fields:
source IP address, destination IP address, source port number,
destination port number, etc; destination port number, etc;
o this FE can perform metering; o the FE can perform metering;
o this FE can handle up to N queues (capacity); o the FE can handle up to N queues (capacity);
o this FE can add and remove encapsulating headers of types o the FE can add and remove encapsulating headers of types including
including IPSec, GRE, L2TP. IPsec, GRE, L2TP.
While one could try and 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 to be a significant FE capabilities, other efforts found this approach to be a
undertaking. The main difficulty arises in describing detailed significant undertaking. The main difficulty arises in describing
limits, such as the maximum number of classifiers, queues, buffer detailed limits, such as the maximum number of classifiers, queues,
pools, and meters the FE can provide. We believe that a good balance buffer pools, and meters that the FE can provide. We believe that a
between simplicity and flexibility can be achieved for the FE model good balance between simplicity and flexibility can be achieved for
by combining coarse level capability reporting with an error the FE model by combining coarse level capability reporting with an
reporting mechanism. That is, if the CE attempts to instruct the FE error reporting mechanism. That is, if the CE attempts to instruct
to set up some specific behavior it cannot support, the FE will the FE to set up some specific behavior it cannot support, the FE
return an error indicating the problem. Examples of similar will return an error indicating the problem. Examples of similar
approaches include DiffServ PIB RFC3317 [4] and Framework PIB RFC3318 approaches include DiffServ PIB RFC3317 [4] and Framework PIB RFC3318
[5]. [5].
There is one common and shared aspect of capability that will be 3.1.1.2. FE State Model
handled in a separate fashion. For all components (i.e. LFB
components and Structure components), certain property information is
needed. All components need to provide information as to whether
they are supported and if so whether the components is readable or
writeable. Based on their type, many components have additional
common properties (for example, arrays have their current size.)
There is a specific model and protocol mechanism for referencing this
form of property information about components of the model.
The FE state model presents the snapshot view of the FE to the CE. The FE state model presents the snapshot view of the FE to the CE.
For example, using an FE state model, an FE may be described to its For example, using an FE state model, an FE may be described to its
corresponding CE as the following: corresponding CE as the following:
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.
Figure 1 shows the concepts of FE state, capabilities and 3.1.1.3. LFB Capability and State Model
configuration in the context of CE-FE communication via the ForCES
protocol.
+-------+ +-------+ Both LFB Capability and State information is defined formally using
| | FE capabilities: what it can/cannot do. | | LFB modelling XML schema.
| |<-----------------------------------------| |
| | | |
| CE | FE state: what it is now. | FE |
| |<-----------------------------------------| |
| | | |
| | FE configuration: what it should be. | |
| |----------------------------------------->| |
+-------+ +-------+
Figure 1: Illustration of FE state, capabilities and configuration Capability information at the LFB level is an integral part of the
exchange in the context of CE-FE communication via ForCES. LFB model and provides for powerful semantics. For example, when
certain features of an LFB class are optional, the CE MUST be able to
determine whether those optional features are supported by a given
LFB instance. The schema for the definition of LFB classes provides
a means for identifying such components.
The concepts relating to LFBs, particularly capability at the LFB State information is defined formally using LFB components
level and LFB topology will be discussed in the rest of this section. constructs.
Capability information at the LFB level is an integral part of the 3.1.2. Relating LFB and FE Capability and State Model
LFB model, and is modeled the same way as the other operational
parameters inside an LFB. For example, when certain features of an
LFB class are optional, the CE MUST be able to determine whether
those optional features are supported by a given LFB instance. Such
capability information is modeled as either property information, or
for LFB information not provided by the defined properties, as
capability components which are inherently read-only. The schema for
the definition of LFB classes provides for identifying such
components.
Capability information at the FE level may describe the LFB classes Capability information at the FE level describes the LFB classes that
that the FE can instantiate; the number of instances of each that can the FE can instantiate, the number of instances of each that can be
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 as part of this information whenever it needs to, including while the CE is
establishing the control of the FE by the CE. 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 by two levels. The first level is the
logically separable and distinct packet processing functions, called logically separable and distinct packet processing functions, called
Logical Functional Blocks (LFBs). The second level of information LFBs. The second level of information describes how these individual
describes how these individual LFBs are ordered and placed along the LFBs are ordered and placed along the datapath to deliver a complete
datapath to deliver a complete forwarding plane service. The forwarding plane service. The interconnection and ordering of the
interconnection and ordering of the LFBs is called LFB Topology. LFBs is called LFB Topology. Section 3.2 discusses high level
Section 3.2 discusses high level concepts around LFBs, whereas concepts around LFBs, whereas Section 3.3 discusses LFB topology
Section 3.3 discusses LFB topology issues. This topology information issues. This topology information is represented as components of
is represented as components of the FE Object LFB instance, to allow the FE Object LFB instance, to allow the CE to fetch and manipulate
the CE to fetch and manipulate this. this.
3.2. LFB (Logical Functional Block) Modeling 3.2. Logical Functional Block (LFB) Modeling
Each LFB performs a well-defined action or computation on the packets Each LFB performs a well-defined action or computation on the packets
passing through it. Upon completion of its prescribed function, passing through it. Upon completion of its prescribed function,
either the packets are modified in certain ways (e.g., decapsulator, either the packets are modified in certain ways (e.g., decapsulator,
marker), or some results are generated and stored, often in the form marker), or some results are generated and stored, often in the form
of metadata (e.g., classifier). Each LFB typically performs a single of metadata (e.g., classifier). Each LFB typically performs a single
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 LFBs will be defined in detail in one or more and hardware. These LFBs will be defined in detail in one or more
documents. documents.
An LFB has one or more inputs, each of which takes a packet P, and It is also the case that LFBs may exist in order to provide a set of
optionally metadata M; and produces one or more outputs, each 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
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
allows the FE to control some aspects of the FE, such as the datapath
itself. Such FEs will not have the packet oriented properties
described in this section.
An LFB can have one or more inputs, each of which takes a packet P,
and optionally metadata M; and produces one or more outputs, each of
which carries a packet P', and optionally metadata M'. Metadata is which carries a packet P', and optionally metadata M'. Metadata is
data associated with the packet in the network processing device data associated with the packet in the network processing device
(router, switch, etc.) and is passed from one LFB to the next, but is (router, switch, etc.) and is passed from one LFB to the next, but is
not sent across the network. In general, multiple LFBs are contained not sent across the network. In general, multiple LFBs are contained
in one FE, as shown in Figure 2, and all the LFBs share the same in one FE, as shown in Figure 2, and all the LFBs share the same
ForCES protocol termination point that implements the ForCES protocol ForCES protocol termination point that implements the ForCES protocol
logic and maintains the communication channel to and from the CE. logic and maintains the communication channel to and from the CE.
+-----------+ +-----------+
| CE | | CE |
skipping to change at page 14, line 33 skipping to change at page 15, line 33
| =====>| v |============>| v |======>...| | =====>| v |============>| v |======>...|
| Inputs| +----------+ |Outputs | +----------+ | | | Inputs| +----------+ |Outputs | +----------+ | |
| (P,M) | |Components| |(P',M') | |Components| |(P",M") | | (P,M) | |Components| |(P',M') | |Components| |(P",M") |
| | +----------+ | | +----------+ | | | | +----------+ | | +----------+ | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 2: Generic LFB Diagram Figure 2: Generic LFB Diagram
An LFB, as shown in Figure 2, has inputs, outputs and components that An LFB, as shown in Figure 2, may have inputs, outputs and components
can be queried and manipulated by the CE via an Fp reference point that can be queried and manipulated by the CE via an Fp reference
(defined in RFC 3746 [2]) and the ForCES protocol termination point. point (defined in RFC3746 [3]) and the ForCES protocol termination
The horizontal axis is in the forwarding plane for connecting the point. The horizontal axis is in the forwarding plane for connecting
inputs and outputs of LFBs within the same FE. The vertical axis the inputs and outputs of LFBs within the same FE. The vertical axis
between the CE and the FE denotes the Fp reference point where between the CE and the FE denotes the Fp reference point where
bidirectional communication between the CE and FE occurs: the CE to bidirectional communication between the CE and FE occurs: the CE to
FE communication is for configuration, control and packet injection FE communication is for configuration, control, and packet injection,
while FE to CE communication is used for packet re- direction to the while FE to CE communication is used for packet redirection to the
control plane, monitoring and accounting information, errors, etc. control plane, reporting of monitoring and accounting information,
Note that the interaction between the CE and the LFB is only abstract reporting of errors, etc. Note that the interaction between the CE
and indirect. The result of such an interaction is for the CE to and the LFB is only abstract and indirect. The result of such an
manipulate the components of the LFB instances. interaction is for the CE to manipulate the components of the LFB
instances.
A namespace is used to associate a unique name or ID with each LFB A namespace is used to associate a unique name or ID with each LFB
class. The namespace MUST be extensible so that a new LFB class can class. The namespace MUST be extensible so that a new LFB class can
be added later to accommodate future innovation in the forwarding be added later to accommodate future innovation in the forwarding
plane. plane.
LFB operation is specified in the model to allow the CE to understand LFB operation is specified in the model to allow the CE to understand
the behavior of the forwarding datapath. For instance, the CE must the behavior of the forwarding datapath. For instance, the CE must
understand at what point in the datapath the IPv4 header TTL is understand at what point in the datapath the IPv4 header TTL is
decremented. That is, the CE needs to know if a control packet could decremented. That is, the CE needs to know if a control packet could
skipping to change at page 15, line 44 skipping to change at page 16, line 46
o packet routing criteria (when multiple outputs on an LFB are o packet routing criteria (when multiple outputs on an LFB are
present); present);
o packet timing modifications; o packet timing modifications;
o packet flow ordering modifications; o packet flow ordering modifications;
o LFB capability information components; o LFB capability information components;
o Events that can be detected by the LFB, with notification to the o events that can be detected by the LFB, with notification to the
CE; CE;
o LFB operational components, etc. o LFB operational components, etc.
Section 4 of this document provides a detailed discussion of the LFB Section 4 of this document provides a detailed discussion of the LFB
model with a formal specification of LFB class schema. The rest of model with a formal specification of LFB class schema. The rest of
Section 3.2 only intends to provide a conceptual overview of some Section 3.2 only intends to provide a conceptual overview of some
important issues in LFB modeling, without covering all the specific important issues in LFB modeling, without covering all the specific
details. details.
3.2.1. LFB Outputs 3.2.1. LFB Outputs
An LFB output is a conceptual port on an LFB that can send An LFB output is a conceptual port on an LFB that can send
information to another LFB. The information is typically a packet information to another LFB. The information is typically a packet
and its associated metadata, although in some cases it might consist and its associated metadata, although in some cases it might consist
of only metadata, i.e., with no packet data. of only metadata.
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. unambiguously.
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 +-->
skipping to change at page 17, line 46 skipping to change at page 18, line 46
limits on the number of instances in specific output groups for limits on the number of instances in specific output groups for
certain LFBs. The actual number of output instances in a group is an certain LFBs. The actual number of output instances in a group is an
attribute of the LFB instance, which is read-only for static attribute of the LFB instance, which is read-only for static
topologies, and read-write for dynamic topologies. The output topologies, and read-write for dynamic topologies. The output
instances in a group are numbered sequentially, from 0 to N-1, and instances in a group are numbered sequentially, from 0 to N-1, and
are addressable from within the LFB. The LFB has a built-in are addressable from within the LFB. The LFB has a built-in
mechanism to select one specific output instance for each packet. mechanism to select one specific output instance for each packet.
This mechanism is described in the textual definition of the class This mechanism is described in the textual definition of the class
and is typically configurable via some attributes of the LFB. and is typically configurable via some attributes of the LFB.
For example, consider a re-director LFB, whose sole purpose is to For example, consider a 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, a redirector can be used to divide the data path into an
IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork
into color specific paths after metering using the COLOR metadata into color specific paths after metering using the COLOR metadata
(red, yellow, green; N=3), etc. (red, yellow, green; N=3), etc.
Using an output group in the above LFB class provides the desired Using an output group in the above LFB class provides the desired
flexibility to adapt each instance of this class to the required flexibility to adapt each instance of this class to the required
skipping to change at page 18, line 32 skipping to change at page 19, line 33
The model allows the output group to be combined with other singleton The model allows the output group to be combined with other singleton
output(s) in the same class, as demonstrated in Figure 3.d. The LFB output(s) in the same class, as demonstrated in Figure 3.d. The LFB
here has two types of outputs, OUT, for normal packet output, and here has two types of outputs, OUT, for normal packet output, and
EXCEPTIONOUT for packets that triggered some exception. The normal EXCEPTIONOUT for packets that triggered some exception. The normal
OUT has multiple instances, thus, it is an output group. OUT has multiple instances, thus, it is an output group.
In summary, the LFB class may define one output, multiple singleton In summary, the LFB class may define one output, multiple singleton
outputs, one or more output groups, or a combination thereof. outputs, one or more output groups, or a combination thereof.
Multiple singleton outputs should be used when the LFB must provide Multiple singleton outputs should be used when the LFB must provide
for forking the datapath, and at least one of the following for forking the datapath and at least one of the following conditions
conditions hold: hold:
o the number of downstream directions are 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 metadata emitted on any of the outputs o the frame type and set of metadata emitted on any of the outputs
are substantially different from what is emitted on the other are substantially different from what is emitted on the other
outputs (i.e., they cannot share frame-type and metadata outputs (i.e., they cannot share frame-type and 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 the sufficiently similar or, ideally, identical, such they can share
same output definition. the same output definition.
3.2.2. LFB Inputs 3.2.2. LFB Inputs
An LFB input is a conceptual port on an LFB where the LFB can receive An LFB input is a conceptual port on an LFB on which the LFB can
information from other LFBs. The information is typically a packet receive information from other LFBs. The information is typically a
and associated metadata, although in some cases it might consist of packet and associated metadata, although in some cases it might
only metadata, without any packet data. consist of only metadata.
For LFB instances that receive packets from more than one other LFB For LFB instances that receive packets from more than one other LFB
instance (fan-in). There are three ways to model fan-in, all instance (fan-in) there are three ways to model fan-in, all supported
supported by the LFB model and can 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 (Figure 4
.a). Most LFBs will have only one singleton input. Multiplexing .a). Most LFBs will have only one singleton input. Multiplexing
into a single input is possible because the model allows more than into a single input is possible because the model allows more than
skipping to change at page 21, line 5 skipping to change at page 22, line 5
+--------------+ |... | | +--------------+ |... | |
+-->|in:N-1 / | +-->|in:N-1 / |
... | | | ... | | |
+--------------+ | | | +--------------+ | | |
| Queue LFB #N |---+ | Scheduler LFB | | Queue LFB #N |---+ | Scheduler LFB |
+--------------+ +------------------------+ +--------------+ +------------------------+
(c) A Scheduler LFB uses an input group to differentiate which queue (c) A Scheduler LFB uses an input group to differentiate which queue
LFB packets are coming from. LFB packets are coming from.
Figure 4: Input modeling concepts (examples). Figure 4: Examples of LFBs with various input combinations.
The third method to model fan-in uses the concept of an input group. The third method to model fan-in uses the concept of an input group.
The concept is similar to the output group introduced in the previous The concept is similar to the output group introduced in the previous
section, and is depicted in Figure 4.c. An input group consists of a section and is depicted in Figure 4.c. An input group consists of a
number of input instances, all sharing the properties (same frame and number of input instances, all sharing the properties (same frame and
metadata expectations). The input instances are numbered from 0 to metadata expectations). The input instances are numbered from 0 to
N-1. From the outside, these inputs appear as normal inputs, i.e., N-1. From the outside, these inputs appear as normal inputs, i.e.,
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 a 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 an component The number of actual input instances in the group is a component
defined in the LFB class, which defined in the LFB class, which is read-only for static topologies,
and is read-write for configurable topologies.
is read-only for static 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 3.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.
In summary, the LFB class may define one input, multiple singleton In summary, the LFB class may define one input, multiple singleton
inputs, one or more input groups, or a combination thereof. Any inputs, one or more input groups, or a combination thereof. Any
input allows for implicit multiplexing of similar packet streams via input allows for implicit multiplexing of similar packet streams via
connecting multiple outputs to the same input. Explicit multiple connecting multiple outputs to the same input. Explicit multiple
singleton inputs are useful when either the contention handling must singleton inputs are useful when either the contention handling must
be handled explicitly, or when the LFB class must receive and process be handled explicitly, or when the LFB class must receive and process
a known number of distinct types of packet streams. An input group a known number of distinct types of packet streams. An input group
is suitable when contention handling must be modeled explicitly, but is suitable when contention handling must be modeled explicitly, but
the number of inputs are not inherent from the class (and hence is the number of inputs is not inherent from the class (and hence is not
not known when the class is defined), or when it is critical for LFB known when the class is defined), or when it is critical for LFB
operation to know exactly on which input the packet was received. operation to know exactly on which input the packet was received.
3.2.3. Packet Type 3.2.3. Packet Type
When LFB classes are defined, the input and output packet formats When LFB classes are defined, the input and output packet formats
(e.g., IPv4, IPv6, Ethernet, etc.) MUST be specified. These are the (e.g., IPv4, IPv6, Ethernet, etc.) MUST be specified. These are the
types of packets a given LFB input is capable of receiving and types of packets that a given LFB input is capable of receiving and
processing, or a given LFB output is capable of producing. This processing, or that a given LFB output is capable of producing. This
requires distinct packet types be uniquely labeled with a symbolic model requires that distinct packet types be uniquely labeled with a
name and/or ID. symbolic name and/or ID.
Note that each LFB has a set of packet types that it operates on, but Note that each LFB has a set of packet types that it operates on, but
does not care whether the underlying implementation is passing a does not care whether the underlying implementation is passing a
greater portion of the packets. For example, an IPv4 LFB might only greater portion of the packets. For example, an IPv4 LFB might only
operate on IPv4 packets, but the underlying implementation may or may operate on IPv4 packets, but the underlying implementation may or may
not be stripping the L2 header before handing it over -- whether that not be stripping the L2 header before handing it over. Whether such
is happening or not is opaque to the CE. processing is happening or not is opaque to the CE.
3.2.4. Metadata 3.2.4. Metadata
Metadata is the per-packet state that is passed from one LFB to Metadata is state that is passed from one LFB to another alongside a
another. The metadata is passed with the packet to assist subsequent packet. The metadata passed with the packet assists subsequent LFBs
LFBs to process that packet. The ForCES model captures how the per- to process that packet.
packet state information is propagated from one LFB to other LFBs.
Practically, such metadata propagation can happen within one FE, or
cross the FE boundary between two interconnected FEs. We believe
that the same metadata model can be used for either situation;
however, our focus here is for intra-FE metadata.
3.2.4.1. Metadata Vocabulary
Metadata has historically been understood to mean "data about data".
While this definition is a start, it is inadequate to describe the
multiple forms of metadata, which may appear within a complex network
element. The discussion here categorizes forms of metadata by two
orthogonal axes.
The first axis is "internal" versus "external", which describes where
the metadata exists in the network model or implementation. For
example, a particular vendor implementation of an IPv4 forwarder may
make decisions inside of a chip that are not visible externally.
Those decisions are metadata for the packet that is "internal" to the
chip. When a packet is forwarded out of the chip, it may be marked
with a traffic management header. That header, which is metadata for
the packet, is visible outside of the chip, and is therefore called
"external" metadata.
The second axis is "implicit" versus "expressed", which specifies The ForCES model defines metadata as precise atomic definitions in
whether or not the metadata has a visible physical representation. the form of label, value pairs.
For example, the traffic management header described in the previous
paragraph may be represented as a series of bits in some format, and
that header is associated with the packet. Those bits have physical
representation, and are therefore "expressed" metadata. If the
metadata does not have a physical representation, it is called
"implicit" metadata. This situation occurs, for example, when a
particular path through a network device is intended to be traversed
only by particular kinds of packets, such as an IPv4 router. An
implementation may not mark every packet along this path as being of
type "IPv4", but the intention of the designers is that every packet
is of that type. This understanding can be thought of as metadata
about the packet, which is implicitly attached to the packet through
the intent of the designers.
In the ForCES model, we do not discuss or represent metadata The ForCES model provides to the authors of LFB classes a way to
"internal" to vendor implementations of LFBs. Our focus is solely on formally define how to achieve metadata creation, modification,
metadata "external" to the LFBs, and therefore visible in the ForCES reading, as well as consumption(deletion).
model. The metadata discussed within this model may, or may not be
visible outside of the particular FE implementing the LFB model. In
this regard, the scope of the metadata within ForCES is very narrowly
defined.
Note also that while we define metadata within this model, it is only Inter-FE metadata, i.e, metadata crossing FEs, while likely
a model. There is no requirement that vendor implementations of semantically similar to this metadata, is out of scope for this
ForCES use the exact metadata representations described in this document.
document. The only implementation requirement is that vendors
implement the ForCES protocol, not the model.
3.2.4.2. Metadata lifecycle within the ForCES model Section 4 has informal details on metadata.
Each metadata can be conveniently modeled as a <label, value> pair, 3.2.4.1. Metadata lifecycle within the ForCES model
where the label identifies the type of information, (e.g., "color"),
and its value holds the actual information (e.g., "red"). The tag
here is shown as a textual label, but it can be replaced or
associated with a unique numeric value (identifier).
The metadata life-cycle is defined in this model using three types of Each metadata is modeled as a <label, value> pair, where the label
events: "write", "read" and "consume". The first "write" implicitly identifies the type of information, (e.g., "color"), and its value
creates and initializes the value of the metadata, and hence starts holds the actual information (e.g., "red"). The tag here is shown as
the life-cycle. The explicit "consume" event terminates the life- a textual label, but it can be replaced or associated with a unique
cycle. Within the life-cycle, that is, after a "write" event, but numeric value (identifier).
before the next "consume" event, there can be an arbitrary number of
"write" and "read" events. These "read" and "write" events can be
mixed in an arbitrary order within the life- cycle. Outside of the
life-cycle of the metadata, that is, before the first "write" event,
or between a "consume" event and the next "write" event, the metadata
should be regarded non-existent or non- initialized. Thus, reading a
metadata outside of its life-cycle is considered an error.
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.
While it is important to define the metadata types passing between 3.2.4.2. Metadata Production and Consumption
LFBs, it is not appropriate to define the exact encoding mechanism
used by LFBs for that metadata. Different implementations are
allowed to use different encoding mechanisms for metadata. For
example, one implementation may store metadata in registers or shared
memory, while another implementation may encode metadata in- band as
a preamble in the packets. In order to allow the CE to understand
and control the meta-data related operations, the model represents
each metadata tag as a 32-bit integer. Each LFB definition indicates
in its metadata declarations the 32-bit value associated with a given
metadata tag. Ensuring consistency of usage of tags is important,
and outside the scope of the model.
At any link between two LFBs, the packet is marked with a finite set For a given metadata on a given packet path, there MUST be at least
of active metadata, where active means the metadata is within its one producer LFB that creates that metadata and SHOULD be at least
life-cycle. There are two corollaries of this model: one consumer LFB that needs that metadata.
1. No un-initialized metadata exists in the model. In the ForCES model, the producer and consumer LFBs of a metadata are
not required to be adjacent. In addition, there may be multiple
producers and consumers for the same metadata. When a packet path
involves multiple producers of the same metadata, then subsequent
producers overwrite that metadata value.
2. No more than one occurrence of each metadata tag can be The metadata that is produced by an LFB is specified by the LFB class
associated with a packet at any given time. definition on a per-output-port-group basis. A producer may always
generate the metadata on the port group, or may generate it only
under certain conditions. We call the former an "unconditional"
metadata, whereas the latter is a "conditional" metadata. In the
case of conditional metadata, it should be possible to determine from
the definition of the LFB when a "conditional" metadata is produced.
The consumer behavior of an LFB, that is, the metadata that the LFB
needs for its operation, is defined in the LFB class definition on a
per-input-port-group basis. An input port group may "require" a
given metadata, or may treat it as "optional" information. In the
latter case, the LFB class definition MUST explicitly define what
happens if an optional metadata is not provided. One approach is to
specify a default value for each optional metadata, and assume that
the default value is used if the metadata is not provided with the
packet.
When specifying the metadata tags, some harmonization effort must be
made so that the producer LFB class uses the same tag as its intended
consumer(s), or vice versa.
3.2.4.3. LFB Operations on Metadata 3.2.4.3. LFB Operations on Metadata
When the packet is processed by an LFB (i.e., between the time it is When the packet is processed by an LFB (i.e., between the time it is
received and forwarded by the LFB), the LFB may perform read, write received and forwarded by the LFB), the LFB may perform read, write,
and/or consume operations on any active metadata associated with the and/or consume operations on any active metadata associated with the
packet. If the LFB is considered to be a black box, one of the packet. If the LFB is considered to be a black box, one of the
following operations is performed on each active metadata. following operations is performed on each active metadata.
* IGNORE: ignores and forwards the metadata * IGNORE: ignores and forwards the metadata
* READ: reads and forwards the metadata * READ: reads and forwards the metadata
* READ/RE-WRITE: reads, over-writes and forwards the metadata * READ/RE-WRITE: reads, over-writes and forwards the metadata
skipping to change at page 24, line 47 skipping to change at page 25, line 4
* IGNORE: ignores and forwards the metadata * IGNORE: ignores and forwards the metadata
* READ: reads and forwards the metadata * READ: reads and forwards the metadata
* READ/RE-WRITE: reads, over-writes and forwards the metadata * READ/RE-WRITE: reads, over-writes and forwards the metadata
* WRITE: writes and forwards the metadata (can also be used to * WRITE: writes and forwards the metadata (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 metadata
* CONSUME consumes metadata without reading * CONSUME consumes metadata without reading
The last two operations terminate the life-cycle of the metadata, The last two operations terminate the life-cycle of the metadata,
meaning that the metadata is not forwarded with the packet when the meaning that the metadata is not forwarded with the packet when the
packet is sent to the next LFB. packet is sent to the next LFB.
In our model, a new metadata is generated by an LFB when the LFB In the ForCES model, a new metadata is generated by an LFB when the
applies a WRITE operation to a metadata type that was not present LFB applies a WRITE operation to a metadata type that was not present
when the packet was received by the LFB. Such implicit creation may when the packet was received by the LFB. Such implicit creation may
be unintentional by the LFB, that is, the LFB may apply the WRITE be unintentional by the LFB, that is, the LFB may apply the WRITE
operation without knowing or caring if the given metadata existed or operation without knowing or caring if the given metadata existed or
not. If it existed, the metadata gets over-written; if it did not not. If it existed, the metadata gets over-written; if it did not
exist, the metadata is created. exist, the metadata is created.
For LFBs that insert packets into the model, WRITE is the only For LFBs that insert packets into the model, WRITE is the only
meaningful metadata operation. meaningful metadata operation.
For LFBs that remove the packet from the model, they may either 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 metadata
associated with the packet. associated with the packet.
3.2.4.4. Metadata Production and Consumption 3.2.5. LFB Events
For a given metadata on a given packet path, there MUST be at least
one producer LFB that creates that metadata and SHOULD be at least
one consumer LFB that needs that metadata. In this model, the
producer and consumer LFBs of a metadata are not required to be
adjacent. In addition, there may be multiple producers and consumers
for the same metadata. When a packet path involves multiple
producers of the same metadata, then subsequent producers overwrite
that metadata value.
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
generate the metadata on the port group, or may generate it only
under certain conditions. We call the former an "unconditional"
metadata, whereas the latter is a "conditional" metadata. In the
case of conditional metadata, it should be possible to determine from
the definition of the LFB when a "conditional" metadata is produced.
The consumer behavior of an LFB, that is, the metadata that the LFB
needs for its operation, is defined in the LFB class definition on a
per input port group basis. An input port group may "require" a
given metadata, or may treat it as "optional" information. In the
latter case, the LFB class definition MUST explicitly define what
happens if an optional metadata is not provided. One approach is to
specify a default value for each optional metadata, and assume that
the default value is used if the metadata is not provided with the
packet.
When a consumer LFB requires a given metadata, it has dependencies on
its up-stream LFBs. That is, the consumer LFB can only function if
there is at least one producer of that metadata and no intermediate
LFB consumes the metadata.
The model should expose these inter-dependencies. Furthermore, it
should be possible to take inter-dependencies into consideration when
constructing LFB topologies, and also that the dependencies can be
verified when validating topologies.
For extensibility reasons, the LFB specification SHOULD define what
metadata the LFB requires without specifying which LFB(s) it expects
a certain metadata to come from. Similarly, LFBs SHOULD specify what
metadata they produce without specifying which LFBs the metadata is
meant for.
When specifying the metadata tags, some harmonization effort must be
made so that the producer LFB class uses the same tag as its intended
consumer(s), or vice versa.
3.2.4.5. Fixed, Variable and Configurable Tag
When the produced metadata is defined for a given LFB class, most
metadata will be specified with a fixed tag. For example, a Rate
Meter LFB will always produce the "Color" metadata.
A small subset of LFBs need the capability to produce one or more of
their metadata with tags that are not fixed in the LFB class
definition, but instead can be selected per LFB instance. An example
of such an LFB class is a Generic Classifier LFB. We call this
capability "variable tag metadata production". If an LFB
produces metadata with a variable tag, the corresponding LFB
attribute, called the tag selector, specifies the tag for each such
metadata. This mechanism improves the versatility of certain multi-
purpose LFB classes, since it allows the same LFB class to be used in
different topologies, producing the right metadata tags according to
the needs of the topology. This selection of tags is variable in
that the produced output may have any number of different tags. The
meaning of the various tags is still defined by the metadata
declaration associated with the LFB class definition. This also
allows the CE to correctly set the tag values in the table to match
the declared meanings of the metadata tag values.
Depending on the capability of the FE, the tag selector can be either
a read-only or a read-write attribute. If the selector is read-only,
the tag cannot be modified by the CE. If the selector is read-write,
the tag can be configured by the CE, hence we call this "configurable
tag metadata production." Note that using this definition,
configurable tag metadata production is a subset of variable tag
metadata production.
Similar concepts can be introduced for the consumer LFBs to satisfy
different metadata needs. Most LFB classes will specify their
metadata needs using fixed metadata tags. For example, a Next Hop
LFB may always require a "NextHopId" metadata; but the Redirector LFB
may need a "ClassID" metadata in one instance, and a "ProtocolType"
metadata in another instance as a basis for selecting the right
output port. In this case, an LFB attribute is used to provide the
required metadata tag at run-time. This metadata tag selector
attribute may be read-only or read-write, depending on the
capabilities of the LFB instance and the FE.
3.2.4.6. Metadata Usage Categories
Depending on the role and usage of a metadata, various amounts of
encoding information MUST be provided when the metadata is defined,
where some cases offer less flexibility in the value selection than
others.
There are three types of metadata related to metadata usage:
o Relational (or binding) metadata
o Enumerated metadata
o Explicit/external value metadata
The purpose of the relational metadata is to refer in one LFB During operation, various conditions may occur that can be detected
instance (producer LFB) to a "thing" in another downstream LFB by LFBs. Examples range from link failure or restart to timer
instance (consumer LFB), where the "thing" is typically an entry in a expiration in special purpose LFBs. The CE may wish to be notified
table attribute of the consumer LFB. of the occurrence of such events. The PL protocol provides for such
notifications.
For example, the Prefix Lookup LFB executes an LPM search using its Events are declared in the LFB class definition. The LFB event
prefix table and resolves to a next-hop reference. This reference declaration constitutes:
needs to be passed as metadata by the Prefix Lookup LFB (producer) to
the Next Hop LFB (consumer), and must refer to a specific entry in
the next-hop table within the consumer.
Expressing and propagating such a binding relationship is probably o a unique 32 bit identifier.
the most common usage of metadata. One or more objects in the
producer LFB are bound to a specific object in the consumer LFB.
Such a relationship is established by the CE explicitly by properly
configuring the attributes in both LFBs. Available methods include
the following:
The binding may be expressed by tagging the involved objects in both o An LFB component which is used to trigger the event. This entity
LFBs with the same unique, but otherwise arbitrary, identifier. The is known as the event target.
value of the tag is explicitly configured by the CE by writing the
value into both LFBs, and this value is also carried by the metadata
between the LFBs.
Another way of setting up binding relations is to use a naturally o A condition that will happen to the event target that will result
occurring unique identifier of the consumer's object as a reference in a generation of an event to the CE. Example of a condition
and as a value of the metadata (e.g., the array index of a table include something getting created, deleted, config change, etc.
entry). In this case, the index is either read or inferred by the CE
by communicating with the consumer LFB. Once the CE obtains the
index, it needs to write it into the producer LFB to establish the
binding.
Important characteristics of the binding usage of metadata are: o What should be reported to the CE by the FE if the declared
condition is met.
o The value of the metadata shows up in the CE-FE communication for The declaration of an event within an LFB class essentially defines
both the consumer and the producer. That is, the metadata value what part of the LFB component(s) need to be monitored for events,
MUST be carried over the ForCES protocol. Using the tagging what condition on the LFB monitored LFB component an FE should detect
technique, the value is written to both LFBs. Using the other to trigger such an event, and what to report to the CE when the event
technique, the value is written to only the producer LFB and may is triggered.
be READ from the consumer LFB.
o The metadata value is irrelevant to the CE, the binding is simply While events may be declared by the LFB class definition, runtime
expressed by using the same value at the consumer and producer activity is controlled using built-in event properties using LFB
LFBs. component Properties (discussed in Section 3.2.6). A CE subscribes
to the events on an LFB class instance by setting an event property
for subscription. Each event has a subscription property which is by
default off. A CE wishing to receive a specific event needs to turn
on the subscription property at runtime.
o Hence the metadata definition is not required to include value Event properties also provide semantics for runtime event filtering.
assignments. The only exception is when some special value(s) of A CE may set an event property to further suppress subscribed to
the metadata must be reserved to convey special events. Even events. The LFB model defines such filters to include threshold
though these special cases must be defined with the metadata values, hysteris, time intervals, number of events, etc.
specification, their encoded values can be selected arbitrarily.
For example, for the Prefix Lookup LFB example, a special value
may be reserved to signal the NO-MATCH case, and the value of zero
may be assigned for this purpose.
The second class of metadata is the enumerated type. An example is The reports with events are designed to allow for the common, closely
the "Color" metadata that is produced by a Meter LFB. As the name related information that the CE can be strongly expected to need to
suggests, enumerated metadata has a relatively small number of react to the event. It is not intended to carry information the CE
possible values, each with a specific meaning. All possible cases already has, nor large volumes of information, nor information
must be enumerated when defining this class of metadata. Although a related in complex fashions.
value encoding must be included in the specification, the actual
values can be selected arbitrarily (e.g., <Red=0, Yellow=1, Green=2>
and <Red=3, Yellow=2, Green 1> would be both valid encodings, what is
important is that an encoding is specified).
The value of the enumerated metadata may or may not be conveyed via From a conceptual point of view, at runtime, event processing is
the ForCES protocol between the CE and FE. split into:
The third class of metadata is the explicit type. This refers to 1. detection of something happening to the (declared during LFB
cases where the metadata value is explicitly used by the consumer LFB class definition) event target. Processing the next step happens
to change some packet header fields. In other words, the value has a if the CE subscribed (at runtime) to the event.
direct and explicit impact on some field and will be visible
externally when the packet leaves the NE. Examples are: TTL
increment given to a Header Modifier LFB, and DSCP value for a
Remarker LFB. For explicit metadata, the value encoding MUST be
explicitly provided in the metadata definition. The values cannot be
selected arbitrarily and should conform to what is commonly expected.
For example, a TTL increment metadata should be encoded as zero for
the no increment case, one for the single increment case, etc. A
DSCP metadata should use 0 to encode DSCP=0, 1 to encode DSCP=1, etc.
3.2.5. LFB Events 2. checking of the (declared during LFB class definition) condition
on the LFB event target. If the condition is met, proceed with
the next step.
During operation, various conditions may occur that can be detected 3. checking (runtime set) event filters if they exist to see if the
by LFBs. Examples range from link failure or restart to timer event should be reported or suppressed. If the event is to be
expiration in special purpose LFBs. The CE may wish to be notified reported proceed to the next step.
of the occurrence of such events. The PL protocol provides for such
notifications. The LFB definition includes the necessary
declarations of events. The declarations include identifiers
necessary for subscribing to events (so that the CE can indicate to
the FE which events it wishes to receive) and to indicate in event
notification messages which event is being reported.
The declaration of an event defines a condition that an FE can 4. Submitting of the declared report to the CE.
detect, and may report. From a conceptual point of view, event
processing is split into triggering (the detection of the condition)
and reporting (the generation of the notification of the event.) In
between these two conceptual points there is event filtering.
Properties associated with the event in the LFB instance can define
filtering conditions to suppress the reporting of that event. The
model thus describes event processing as if events always occur, and
filtering may suppress reporting. Implementations may function in
this manner, or may have more complex logic that eliminates some
event processing if the reporting would be suppressed. Any
implementation producing an effect equivalent to the model
description is valid
The reports with events are designed to allow for the common, closely Section 4.7.6 discusses events in more details.
related information that the CE can be strongly expected to need to
react to the event. It is not intended to carry information the CE
already has, nor large volumes of information, nor information
related in complex fashions.
3.2.6. LFB Component Properties 3.2.6. LFB Component Properties
LFBs are made up of components, containing the information that the LFBs are made up of components, containing the information that the
CE needs to see and / or change about the functioning of the LFB. CE needs to see and / or change about the functioning of the LFB.
These components, as described in detail elsewhere, may be basic These components, as described in detail in Section 4.7, may be basic
values, complex structures (containing multiple components values, complex structures (containing multiple components
themselves, each of which can be values, structures, or tables), or themselves, each of which can be values, structures, or tables), or
tables (which contain values, structures or tables.) Some of these tables (which contain values, structures or tables). Some of these
components are optional. Some components may be readable or components are optional. Components may be readable or writeable at
writeable at the discretion of the FE implementation. The CE needs the discretion of the FE implementation. The CE needs to know these
to know these properties. Additionally, certain kinds of components properties. Additionally, certain kinds of components (arrays /
(arrays / tables, aliases, and events as of this writing) have tables, aliases, and events as of this writing) have additional
additional property information that the CE may need to read or property information that the CE may need to read or write. This
write. This model defines the structure of the property information model defines the structure of the property information for all
for all defined data types. defined data types.
Section 4.8 describes properties in more details.
3.2.7. LFB Versioning 3.2.7. LFB Versioning
LFB class versioning is a method to enable incremental evolution of LFB class versioning is a method to enable incremental evolution of
LFB classes. In general, an FE is not allowed to contain an LFB LFB classes. In general, an FE is not allowed to contain an LFB
instance for more than one version of a particular class. instance for more than one version of a particular class.
Inheritance (discussed next in Section 3.2.6) has special rules. If Inheritance (discussed next in Section 3.2.6) has special rules. If
an FE datapath model containing an LFB instance of a particular class an FE datapath model containing an LFB instance of a particular class
C also simultaneously contains an LFB instance of a class C' C also simultaneously contains an LFB instance of a class C'
inherited from class C; C could have a different version than C'. inherited from class C; C could have a different version than C'.
skipping to change at page 30, line 43 skipping to change at page 27, line 43
remove components which are not considered useful (particularly if remove components which are not considered useful (particularly if
they were previously mandatory, and hence were an implementation they were previously mandatory, and hence were an implementation
impediment.) impediment.)
3.2.8. LFB Inheritance 3.2.8. LFB Inheritance
LFB class inheritance is supported in the FE model as a method to LFB class inheritance is supported in the FE model as a method to
define new LFB classes. This also allows FE vendors to add vendor- define new LFB classes. This also allows FE vendors to add vendor-
specific extensions to standardized LFBs. An LFB class specification specific extensions to standardized LFBs. An LFB class specification
MUST specify the base class and version number it inherits from (the MUST specify the base class and version number it inherits from (the
default is the base LFB class). Multiple- inheritance is not default is the base LFB class). Multiple inheritance is not allowed,
allowed, however, to avoid unnecessary complexity. however, to avoid unnecessary complexity.
Inheritance should be used only when there is significant reuse of Inheritance should be used only when there is significant reuse of
the base LFB class definition. A separate LFB class should be the base LFB class definition. A separate LFB class should be
defined if little or no reuse is possible between the derived and the defined if little or no reuse is possible between the derived and the
base LFB class. base LFB class.
An interesting issue related to class inheritance is backward An interesting issue related to class inheritance is backward
compatibility between a descendant and an ancestor class. Consider compatibility between a descendant and an ancestor class. Consider
the following hypothetical scenario where a standardized LFB class the following hypothetical scenario where a standardized LFB class
"L1" exists. Vendor A builds an FE that implements LFB "L1" and "L1" exists. Vendor A builds an FE that implements LFB "L1" and
skipping to change at page 31, line 39 skipping to change at page 28, line 39
1. When detecting an LFB instance of an LFB type that is unknown to 1. When detecting an LFB instance of an LFB type that is unknown to
the CE, the CE MUST be able to query the base class of such an the CE, the CE MUST be able to query the base class of such an
LFB from the FE. LFB from the FE.
2. The LFB instance on the FE SHOULD support a backward 2. The LFB instance on the FE SHOULD support a backward
compatibility mode (meaning the LFB instance reverts itself back compatibility mode (meaning the LFB instance reverts itself back
to the base class instance), and the CE SHOULD be able to to the base class instance), and the CE SHOULD be able to
configure the LFB to run in such a mode. configure the LFB to run in such a mode.
3.3. FE Datapath Modeling 3.3. ForCES Model Addressing
Figure 5 demonstrates the abstraction of the different ForCES model
entities. The ForCES protocol provides the mechanism to uniquely
identify any of the LFB Class instance components.
FE Address = FE01
+--------------------------------------------------------------+
| |
| +--------------+ +--------------+ |
| | LFB ClassID 1| |LFB ClassID 91| |
| | InstanceID 3 |============>|InstanceID 3 |======>... |
| | +----------+ | | +----------+ | |
| | |Components| | | |Components| | |
| | +----------+ | | +----------+ | |
| +--------------+ +--------------+ |
| |
+--------------------------------------------------------------+
Figure 5: FE Entity Hierarchy
At the top of the addressing hierachy is the FE identifier. In the
example above, the 32-bit FE identifier is illustrated with the
mnemonic FE01. The next 32-bit entity selector is the LFB ClassID.
In the illustration above, two LFB classes with identifiers 1 and 91
are demonstrated. The example above further illustrates one instance
of each of the two classes. The scope of the 32-bit LFB class
instance identifier is valid only within the LFB class. To emphasize
that point, each of class 1 and 91 has an instance of 3.
Using the described addressing scheme, a message could be sent to
address FE01, LFB ClassID 1, LFB InstanceID 3, utilizing the ForCES
protocol. However, to be effective, such a message would have to
target entities within an LFB. These entities could be carrying
state, capability, etc. These are further illustrated in Figure 6
below.
LFB Class ID 1,InstanceID 3 Components
+-------------------------------------+
| |
| LFB ComponentID 1 |
| +----------------------+ |
| | | |
| +----------------------+ |
| |
| LFB ComponentID 31 |
| +----------------------+ |
| | | |
| +----------------------+ |
| |
| LFB ComponentID 51 |
| +----------------------+ |
| | LFB ComponentID 89 | |
| | +-----------------+ | |
| | | | | |
| | +-----------------+ | |
| +----------------------+ |
| |
| |
+-------------------------------------+
Figure 6: LFB Hierarchy
Figure 6 zooms into the components carried by LFB Class ID 1, LFB
InstanceID 3 from Figure 5.
The example shows three components with 32-bit component identifiers
1, 31, and 51. LFB ComponentID 51 is a complex structure
encapsulating within it an entity with LFB ComponentID 89. LFB
ComponentID 89 could be a complex structure itself but is restricted
in the example for the sake of clarity.
3.3.1. Addressing LFB Components: Paths and Keys
As mentioned above, LFB components could be complex structures, such
as a table, or even more complex structures such as a table whose
cells are further tables, etc. The ForCES model XML schema
(Figure 5) allows for uniquely identifying anything with such
complexity, utilizing the concept of dot-annotated static paths and
content addressing of paths as derived from keys. As an example, the
path to LFB ComponentID 89 above will be 51.89. If ComponentID 51
was a table which was key index-able, then a key describing content
could also be passed by the CE which upon computation by the FE would
resolve to LFB ComponentID 89.
3.4. FE Datapath Modeling
Packets coming into the FE from ingress ports generally flow through Packets coming into the FE from ingress ports generally flow through
multiple LFBs before leaving out of the egress ports. How an FE one or more LFBs before leaving out of the egress ports. How an FE
treats a packet depends on many factors, such as type of the packet treats a packet depends on many factors, such as type of the packet
(e.g., IPv4, IPv6 or MPLS), actual header values, time of arrival, (e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc.
etc. The result of LFB processing may have an impact on how the The result of LFB processing may have an impact on how the packet is
packet is to be treated in downstream LFBs. This differentiation of to be treated in downstream LFBs. This differentiation of packet
packet treatment downstream can be conceptualized as having treatment downstream can be conceptualized as having alternative
alternative datapaths in the FE. For example, the result of a 6- datapaths in the FE. For example, the result of a 6- tuple
tuple classification performed by a classifier LFB could control classification performed by a classifier LFB could control which rate
which rate meter is applied to the packet by a rate meter LFB in a meter is applied to the packet by a rate meter LFB in a later stage
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.3.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.3.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.3.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
(the encoded state approach). (the encoded state approach).
o Topological Approach o Topological Approach
Using this approach, differential packet treatment is expressed by Using this approach, differential packet treatment is expressed by
splitting the LFB topology into alternative paths. In other words, splitting the LFB topology into alternative paths. In other words,
skipping to change at page 32, line 52 skipping to change at page 32, line 17
A model using only the topological approach may require a very large A model using only the topological approach may require a very large
graph with many links or paths, and nodes (i.e., LFB instances) to graph with many links or paths, and nodes (i.e., LFB instances) to
express all alternative datapaths. On the other hand, a model using express all alternative datapaths. On the other hand, a model using
only the encoded state model would be restricted to a string of LFBs, only the encoded state model would be restricted to a string of LFBs,
which is not an intuitive way to describe different datapaths (such which is not an intuitive way to describe different datapaths (such
as MPLS and IPv4). Therefore, a mix of these two approaches will as MPLS and IPv4). Therefore, a mix of these two approaches will
likely be used for a practical model. In fact, as we illustrate likely be used for a practical model. In fact, as we illustrate
below, the two approaches can be mixed even within the same LFB. below, the two approaches can be mixed even within the same LFB.
Using a simple example of a classifier with N classification outputs Using a simple example of a classifier with N classification outputs
followed by other LFBs, Figure 5(a) shows what the LFB topology looks followed by other LFBs, Figure 7.a shows what the LFB topology looks
like when using the pure topological approach. Each output from the like when using the pure topological approach. Each output from the
classifier goes to one of the N LFBs where no metadata is needed. classifier goes to one of the N LFBs where no metadata is needed.
The topological approach is simple, straightforward and graphically The topological approach is simple, straightforward and graphically
intuitive. However, if N is large and the N nodes following the intuitive. However, if N is large and the N nodes following the
classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type
(e.g., meter), but each has its own independent components, the (e.g., meter), but each has its own independent components, the
encoded state approach gives a much simpler topology representation, encoded state approach gives a much simpler topology representation,
as shown in Figure 5(b). The encoded state approach requires that a as shown in Figure 7.b. The encoded state approach requires that a
table of N rows of meter components is provided in the Meter node table of N rows of meter components is provided in the Meter node
itself, with each row representing the attributes for one meter itself, with each row representing the attributes for one meter
instance. A metadata M is also needed to pass along with the packet instance. A metadata M is also needed to pass along with the packet
P from the classifier to the meter, so that the meter can use M as a P from the classifier to the meter, so that the meter can use M as a
look-up key (index) to find the corresponding row of the attributes look-up key (index) to find the corresponding row of the attributes
that should be used for any particular packet P. that should be used for any particular packet P.
What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same
type? For example, if LFB#1 is a queue while the rest are all type? For example, if LFB#1 is a queue while the rest are all
meters, what is the best way to represent such datapaths? While it meters, what is the best way to represent such datapaths? While it
is still possible to use either the pure topological approach or the is still possible to use either the pure topological approach or the
pure encoded state approach, the natural combination of the two pure encoded state approach, the natural combination of the two
appears to be the best option. Figure 5(c) depicts two different appears to be the best option. Figure 7.c depicts two different
functional datapaths using the topological approach while leaving the functional datapaths using the topological approach while leaving the
N-1 meter instances distinguished by metadata only, as shown in N-1 meter instances distinguished by metadata only, as shown in
Figure 5(c). Figure 7.c.
+----------+ +----------+
P | LFB#1 | P | LFB#1 |
+--------->|(Compon-1)| +--------->|(Compon-1)|
+-------------+ | +----------+ +-------------+ | +----------+
| 1|------+ P +----------+ | 1|------+ P +----------+
| 2|---------------->| LFB#2 | | 2|---------------->| LFB#2 |
| classifier 3| |(Compon-2)| | classifier 3| |(Compon-2)|
| ...|... +----------+ | ...|... +----------+
| N|------+ ... | N|------+ ...
+-------------+ | P +----------+ +-------------+ | P +----------+
+--------->| LFB#N | +--------->| LFB#N |
|(Compon-N)| |(Compon-N)|
+----------+ +----------+
5(a) Using pure topological approach (a) Using pure topological approach
+-------------+ +-------------+ +-------------+ +-------------+
| 1| | Meter | | 1| | Meter |
| 2| (P, M) | (Compon-1) | | 2| (P, M) | (Compon-1) |
| 3|---------------->| (Compon-2) | | 3|---------------->| (Compon-2) |
| ...| | ... | | ...| | ... |
| N| | (Compon-N) | | N| | (Compon-N) |
+-------------+ +-------------+ +-------------+ +-------------+
5(b) Using pure encoded state approach to represent the LFB (b) Using pure encoded state approach to represent the LFB
topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the
same type (e.g., meter). same type (e.g., meter).
+-------------+ +-------------+
+-------------+ (P, M) | queue | +-------------+ (P, M) | queue |
| 1|------------->| (Compon-1) | | 1|------------->| (Compon-1) |
| 2| +-------------+ | 2| +-------------+
| 3| (P, M) +-------------+ | 3| (P, M) +-------------+
| ...|------------->| Meter | | ...|------------->| Meter |
| N| | (Compon-2) | | N| | (Compon-2) |
+-------------+ | ... | +-------------+ | ... |
| (Compon-N) | | (Compon-N) |
+-------------+ +-------------+
5(c) Using a combination of the two, if LFB#1, LFB#2, ..., and (c) Using a combination of the two, if LFB#1, LFB#2, ..., and
LFB#N are of different types (e.g., queue and meter). LFB#N are of different types (e.g., queue and meter).
Figure 5: An example of how to model FE datapaths Figure 7: An example of how to model FE datapaths
From this example, we demonstrate that each approach has a distinct From this example, we demonstrate that each approach has a distinct
advantage depending on the situation. Using the encoded state advantage depending on the situation. Using the encoded state
approach, fewer connections are typically needed between a fan-out approach, fewer connections are typically needed between a fan-out
node and its next LFB instances of the same type because each packet node and its next LFB instances of the same type because each packet
carries metadata the following nodes can interpret and hence invoke carries metadata the following nodes can interpret and hence invoke a
different packet treatment. For those cases, a pure topological
a different packet treatment. For those cases, a pure topological
approach forces one to build elaborate graphs with many more approach forces one to build elaborate graphs with many more
connections and often results in an unwieldy graph. On the other connections and often results in an unwieldy graph. On the other
hand, a topological approach is the most intuitive for representing hand, a topological approach is the most intuitive for representing
functionally different datapaths. functionally different datapaths.
For complex topologies, a combination of the two is the most For complex topologies, a combination of the two is the most
flexible. A general design guideline is provided to indicate which flexible. A general design guideline is provided to indicate which
approach is best used for a particular situation. The topological approach is best used for a particular situation. The topological
approach should primarily be used when the packet datapath forks to approach should primarily be used when the packet datapath forks to
distinct LFB classes (not just distinct parameterizations of the same distinct LFB classes (not just distinct parameterizations of the same
skipping to change at page 35, line 41 skipping to change at page 34, line 40
V V
(a) The LFB topology with a logical loop (a) The LFB topology with a logical loop
+-------+ +-----------+ +------+ +-----------+ +-------+ +-----------+ +------+ +-----------+
| | | |if IP-in-IP | | | | | | | |if IP-in-IP | | | |
--->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|->
| ports | | |----+ | | | | | ports | | |----+ | | | |
+-------+ +-----------+ |others +------+ +-----------+ +-------+ +-----------+ |others +------+ +-----------+
| |
V V
(b)The LFB topology without the loop utilizing two independent
The LFB topology without the loop utilizing two independent
classifier instances. classifier instances.
Figure 6: An LFB topology example. Figure 8: An LFB topology example.
It is important to point out that the LFB topology described here is It is important to point out that the LFB topology described here is
the logical topology, not the physical topology of how the FE the logical topology, not the physical topology of how the FE
hardware is actually laid out. Nevertheless, the actual hardware is actually laid out. Nevertheless, the actual
implementation may still influence how the functionality is mapped to implementation may still influence how the functionality is mapped to
the LFB topology. Figure 6 shows one simple FE example. In this the LFB topology. Figure 8 shows one simple FE example. In this
example, an IP-in-IP packet from an IPSec application like VPN may go example, an IP-in-IP packet from an IPSec application like VPN may go
to the classifier first and have the classification done based on the to the classifier first and have the classification done based on the
outer IP header; upon being classified as an IP-in-IP packet, the outer IP header; upon being classified as an IP-in-IP packet, the
packet is then sent to a decapsulator to strip off the outer IP packet is then sent to a decapsulator to strip off the outer IP
header, followed by a classifier again to perform classification on header, followed by a classifier again to perform classification on
the inner IP header. If the same classifier hardware or software is the inner IP header. If the same classifier hardware or software is
used for both outer and inner IP header classification with the same used for both outer and inner IP header classification with the same
set of filtering rules, a logical loop is naturally present in the set of filtering rules, a logical loop is naturally present in the
LFB topology, as shown in Figure 6(a). However, if the LFB topology, as shown in Figure 8.a. However, if the classification
classification is implemented by two different pieces of hardware or is implemented by two different pieces of hardware or software with
software with different filters (i.e., one set of filters for the different filters (i.e., one set of filters for the outer IP header
outer IP header and another set for the inner IP header), then it is and another set for the inner IP header), then it is more natural to
more natural to model them as two different instances of classifier model them as two different instances of classifier LFB, as shown in
LFB, as shown in Figure 6(b). Figure 8.b.
To distinguish between multiple instances of the same LFB class, each
LFB instance has its own LFB instance ID. One way to encode the LFB
instance ID is to encode it as x.y where x is the LFB class ID and y
is the instance ID within each LFB class.
3.3.2. Configuring the LFB Topology 3.4.2. Configuring the LFB Topology
While there is little doubt that an individual LFB must be While there is little doubt that an individual LFB must be
configurable, the configurability question is more complicated for configurable, the configurability question is more complicated for
LFB topology. Since the LFB topology is really the graphic LFB topology. Since the LFB topology is really the graphic
representation of the datapaths within an FE, configuring the LFB representation of the datapaths within an FE, configuring the LFB
topology means dynamically changing the datapaths, including changing topology means dynamically changing the datapaths, including changing
the LFBs along the datapaths on an FE (e.g., creating, instantiating the LFBs along the datapaths on an FE (e.g., creating/instantiating,
or deleting LFBs) and setting up or deleting interconnections between updating or deleting LFBs) and setting up or deleting
outputs of upstream LFBs to inputs of downstream LFBs. interconnections between outputs of upstream LFBs to inputs of
downstream LFBs.
Why would the datapaths on an FE ever change dynamically? The Why would the datapaths on an FE ever change dynamically? The
datapaths on an FE are set up by the CE to provide certain data plane datapaths on an FE are set up by the CE to provide certain data plane
services (e.g., DiffServ, VPN, etc.) to the Network Element's (NE) services (e.g., DiffServ, VPN, etc.) to the Network Element's (NE)
customers. The purpose of reconfiguring the datapaths is to enable customers. The purpose of reconfiguring the datapaths is to enable
the CE to customize the services the NE is delivering at run time. the CE to customize the services the NE is delivering at run time.
The CE needs to change the datapaths when the service requirements The CE needs to change the datapaths when the service requirements
change, such as adding a new customer or when an existing customer change, such as adding a new customer or when an existing customer
changes their service. However, note that not all datapath changes changes their service. However, note that not all datapath changes
result in changes in the LFB topology graph. Changes in the graph result in changes in the LFB topology graph. Changes in the graph
are dependent on the approach used to map the datapaths into LFB are dependent on the approach used to map the datapaths into LFB
topology. As discussed in 3.3.1, the topological approach and topology. As discussed in Section 3.3.1, the topological approach
encoded state approach can result in very different looking LFB and encoded state approach can result in very different looking LFB
topologies for the same datapaths. In general, an LFB topology based topologies for the same datapaths. In general, an LFB topology based
on a pure topological approach is likely to experience more frequent on a pure topological approach is likely to experience more frequent
topology reconfiguration than one based on an encoded state approach. topology reconfiguration than one based on an encoded state approach.
However, even an LFB topology based entirely on an encoded state However, even an LFB topology based entirely on an encoded state
approach may have to change the topology at times, for example, to approach may have to change the topology at times, for example, to
bypass some LFBs or insert new LFBs. Since a mix of these two bypass some LFBs or insert new LFBs. Since a mix of these two
approaches is used to model the datapaths, LFB topology approaches is used to model the datapaths, LFB topology
reconfiguration is considered an important aspect of the FE model. reconfiguration is considered an important aspect of the FE model.
We want to point out that allowing a configurable LFB topology in the We want to point out that allowing a configurable LFB topology in the
FE model does not mandate that all FEs are required to have this FE model does not mandate that all FEs are required to have this
capability. Even if an FE supports configurable LFB topology, the FE capability. Even if an FE supports configurable LFB topology, the FE
may impose limitations on what can actually be configured. may impose limitations on what can actually be configured.
Performance-optimized hardware implementations may have zero or very Performance-optimized hardware implementations may have zero or very
limited configurability, while FE implementations running on network limited configurability, while FE implementations running on network
processors may provide more flexibility and configurability. It is processors may provide more flexibility and configurability. It is
entirely up to the FE designers to decide whether or not the FE entirely up to the FE designers to decide whether or not the FE
actually implements reconfiguration and if so, how much. Whether a actually implements reconfiguration and if so, how much. Whether a
simple runtime switch is used to enable or disable (i.e., bypass) simple runtime switch is used to enable or disable (i.e., bypass)
certain LFBs, or more flexible software reconfiguration is used, is certain LFBs, or more flexible software reconfiguration is used, is
implementation detail internal to the FE and outside of the scope of an implementation detail internal to the FE and outside of the scope
FE model. In either case, the CE(s) MUST be able to learn the FE's of FE model. In either case, the CE(s) MUST be able to learn the
configuration capabilities. Therefore, the FE model MUST provide a FE's configuration capabilities. Therefore, the FE model MUST
mechanism for describing the LFB topology configuration capabilities provide a mechanism for describing the LFB topology configuration
of an FE. These capabilities may include (see Section 5 for full capabilities of an FE. These capabilities may include (see Section 5
details): for full details):
o Which LFB classes the FE can instantiate o Which LFB classes the FE can instantiate
o Maximum number of instances of the same LFB class that can be o The maximum number of instances of the same LFB class that can be
created created
o Any topological limitations, For example: o Any topological limitations, for example:
* The maximum number of instances of the same class or any class * The maximum number of instances of the same class or any class
that can be created on any given branch of the graph that can be created on any given branch of the graph
* Ordering restrictions on LFBs (e.g., any instance of LFB class * Ordering restrictions on LFBs (e.g., any instance of LFB class
A must be always downstream of any instance of LFB class B). A must be always downstream of any instance of LFB class B).
Note that even when the CE is allowed to configure LFB topology for The CE needs some programming help in order to cope with the range of
the FE, the CE is not expected to be able to interpret an arbitrary complexity. In other words, even when the CE is allowed to configure
LFB topology and determine which specific service or application LFB topology for the FE, the CE is not expected to be able to
(e.g. VPN, DiffServ, etc.) is supported by the FE. However, once interpret an arbitrary LFB topology and determine which specific
the CE understands the coarse capability of an FE, the CE MUST service or application (e.g. VPN, DiffServ, etc.) is supported by
configure the LFB topology to implement the network service the NE is the FE. However, once the CE understands the coarse capability of an
supposed to provide. Thus, the mapping the CE has to understand is FE, the CE MUST configure the LFB topology to implement the network
from the high level NE service to a specific LFB topology, not the service the NE is supposed to provide. Thus, the mapping the CE has
other way around. The CE is not expected to have the ultimate to understand is from the high level NE service to a specific LFB
intelligence to translate any high level service policy into the topology, not the other way around. The CE is not expected to have
configuration data for the FEs. However, it is conceivable that the ultimate intelligence to translate any high level service policy
within a given network service domain, a certain amount of into the configuration data for the FEs. However, it is conceivable
that within a given network service domain, a certain amount of
intelligence can be programmed into the CE to give the CE a general intelligence can be programmed into the CE to give the CE a general
understanding of the LFBs involved to allow the translation from a understanding of the LFBs involved to allow the translation from a
high level service policy to the low level FE configuration to be high level service policy to the low level FE configuration to be
done automatically. Note that this is considered an implementation done automatically. Note that this is considered an implementation
issue internal to the control plane and outside the scope of the FE issue internal to the control plane and outside the scope of the FE
model. Therefore, it is not discussed any further in this draft. model. Therefore, it is not discussed any further in this draft.
+----------+ +-----------+ +----------+ +-----------+
---->| Ingress |---->|classifier |--------------+ ---->| Ingress |---->|classifier |--------------+
| | |chip | | | | |chip | |
skipping to change at page 38, line 31 skipping to change at page 37, line 25
+--------+ | Network Processor | +--------+ | Network Processor |
<----| Egress | | +------+ +------+ +-------+ | <----| Egress | | +------+ +------+ +-------+ |
+--------+ | |Meter | |Marker| |Dropper| | +--------+ | |Meter | |Marker| |Dropper| |
^ | +------+ +------+ +-------+ | ^ | +------+ +------+ +-------+ |
| | | | | |
+----------+-------+ | +----------+-------+ |
| | | | | |
| +---------+ +---------+ +------+ +---------+ | | +---------+ +---------+ +------+ +---------+ |
| |Forwarder|<------|Scheduler|<--|Queue | |Counter | | | |Forwarder|<------|Scheduler|<--|Queue | |Counter | |
| +---------+ +---------+ +------+ +---------+ | | +---------+ +---------+ +------+ +---------+ |
|--------------------------------------------------------------+ +--------------------------------------------------------------+
(a) The Capability of the FE, 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
cards that have a few ingress ports and egress ports, a specialized
classification chip, and a network processor containing codes for FE
blocks like meter, marker, dropper, counter, queue, scheduler, and
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
example, all of the ingress ports might be hardwired into the
classification chip so all packets flow from the ingress port into
the classification engine. On the other hand, the LFBs on the
network processor and their execution order are programmable.
However, certain capacity limits and linkage constraints could exist
between these LFBs. Examples of the capacity limits might be:
o 8 meters
o 16 queues in one FE
o the scheduler can handle at most up to 16 queues
o The linkage constraints might dictate that:
* the classification engine may be followed by:
+ a meter
+ marker
+ dropper
+ counter
+ queue or IPv4 forwarder, but not a scheduler
* queues can only be followed by a scheduler
* a scheduler must be followed by the IPv4 forwarder
* the last LFB in the datapath before going into the egress ports
must be the IPv4 forwarder
+-----+ +-------+ +---+ +-----+ +-------+ +---+
| A|--->|Queue1 |--------------------->| | | A|--->|Queue1 |--------------------->| |
------>| | +-------+ | | +---+ ------>| | +-------+ | | +---+
| | | | | | | | | | | |
| | +-------+ +-------+ | | | | | | +-------+ +-------+ | | | |
| B|--->|Meter1 |----->|Queue2 |------>| |->| | | B|--->|Meter1 |----->|Queue2 |------>| |->| |
| | | | +-------+ | | | | | | | | +-------+ | | | |
| | | |--+ | | | | | | | |--+ | | | |
+-----+ +-------+ | +-------+ | | +---+ +-----+ +-------+ | +-------+ | | +---+
classifier +-->|Dropper| | | IPv4 classifier +-->|Dropper| | | IPv4
+-------+ +---+ Fwd. +-------+ +---+ Fwd.
Scheduler Scheduler
(b) One LFB topology as configured by the CE and Figure 10: An LFB topology as configured by the CE and accepted by
accepted by the FE the FE
Once the FE reports these capabilities and capacity limits to the CE,
it is now up to the CE to translate the QoS policy into a desirable
configuration for the FE. Figure 9 depicts the FE capability while
Figure 10 and Figure 11 depict two different topologies that the CE
may request the FE to configure.
Queue1 Queue1
+---+ +--+ +---+ +--+
| A|------------------->| |--+ | A|------------------->| |--+
+->| | | | | +->| | | | |
| | B|--+ +--+ +--+ +--+ | | | B|--+ +--+ +--+ +--+ |
| +---+ | | | | | | | +---+ | | | | | |
| Meter1 +->| |-->| | | | Meter1 +->| |-->| | |
| | | | | | | | | | | |
| +--+ +--+ | Ipv4 | +--+ +--+ | Ipv4
| Counter1 Dropper1 Queue2| +--+ Fwd. | Counter1 Dropper1 Queue2| +--+ Fwd.
skipping to change at page 39, line 31 skipping to change at page 39, line 32
| +->| | | |--+ | | +->| | | |--+ |
| | B|--+ +--+ +-------->| | | | | B|--+ +--+ +-------->| | |
| +---+ | | | | +--+ | | +---+ | | | | +--+ |
| Meter2 +->| |-+ | | Meter2 +->| |-+ |
| | | | | | | |
| +--+ Queue4 | | +--+ Queue4 |
| Marker1 +--+ | | Marker1 +--+ |
+---------------------------->| |----+ +---------------------------->| |----+
| | | |
+--+ +--+
(c) Another LFB topology as configured by the CE and
accepted by the FE
Figure 7: An example of configuring LFB topology
Figure 7 shows an example where a QoS-enabled router has several line Figure 11: Another LFB topology as configured by the CE and accepted
cards that have a few ingress ports and egress ports, a specialized by the FE
classification chip, a network processor containing codes for FE
blocks like meter, marker, dropper, counter, queue, scheduler and
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
example, all of the ingress ports might be hard- wired into the
classification chip so all packets flow from the ingress port into
the classification engine. On the other hand, the LFBs on the
network processor and their execution order are programmable.
However, certain capacity limits and linkage constraints could exist
between these LFBs. Examples of the capacity limits might be: 8
meters; 16 queues in one FE; the scheduler can handle at most up to
16 queues; etc. The linkage constraints might dictate that the
classification engine may be followed by a meter, marker, dropper,
counter, queue or IPv4 forwarder, but not a scheduler; queues can
only be followed by a scheduler; a scheduler must be followed by the
IPv4 forwarder; the last LFB in the datapath before going into the
egress ports must be the IPv4 forwarder, etc.
Once the FE reports these capabilities and capacity limits to the CE, Note that both the ingress and egress are omitted in Figure 10 and
it is now up to the CE to translate the QoS policy into a desirable Figure 11 to simplify the representation. The topology in Figure 11
configuration for the FE. Figure 7(a) depicts the FE capability is considerably more complex than Figure 10 but both are feasible
while 7(b) and 7(c) depict two different topologies that the CE may within the FE capabilities, and so the FE should accept either
request the FE to configure. Note that both the ingress and egress configuration request from the CE.
are omitted in (b) and (c) to simplify the representation. The
topology in 7(c) is considerably more complex than 7(b) but both are
feasible within the FE capabilities, and so the FE should accept
either configuration request from the CE.
4. Model and Schema for LFB Classes 4. Model and Schema for LFB Classes
The main goal of the FE model is to provide an abstract, generic, The main goal of the FE model is to provide an abstract, generic,
modular, implementation-independent representation of the FEs. This modular, implementation-independent representation of the FEs. This
is facilitated using the concept of LFBs, which are instantiated from is facilitated using the concept of LFBs, which are instantiated from
LFB classes. LFB classes and associated definitions will be provided LFB classes. LFB classes and associated definitions will be provided
in a collection of XML documents. The collection of these XML in a collection of XML documents. The collection of these XML
documents is called a LFB class library, and each document is called documents is called a LFB class library, and each document is called
an LFB class library document (or library document, for short). Each an LFB class library document (or library document, for short). Each
skipping to change at page 40, line 47 skipping to change at page 40, line 23
communication. communication.
4.1. Namespace 4.1. Namespace
A namespace is needed to uniquely identify the LFB type in the LFB A namespace is needed to uniquely identify the LFB type in the LFB
class library. The reference to the namespace definition is class library. The reference to the namespace definition is
contained in Section 9, IANA Considerations. contained in Section 9, IANA Considerations.
4.2. <LFBLibrary> Element 4.2. <LFBLibrary> Element
The <LFBLibrary&amp;#x3e element serves as a root element of all library The <LFBLibrary&gt; element serves as a root element of all library
documents. It contains one or more of the following main XML documents. It contains one or more of the following main XML
elements: elements:
o <frameTypeDefs> for the frame declarations; o <frameTypeDefs> for the frame declarations;
o <dataTypeDefs> for defining common data types; o <dataTypeDefs> for defining common data types;
o <metadataDefs> for defining metadata, and o <metadataDefs> for defining metadata, and
o <LFBClassDefs> for defining LFB classes. o <LFBClassDefs> for defining LFB classes.
skipping to change at page 43, line 8 skipping to change at page 42, line 8
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.petrimeat.com/forces/1.0/lfbmodel/lpm.xml"/> location="http://www.exmplae.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
skipping to change at page 45, line 42 skipping to change at page 44, line 42
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.
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 (ala 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 (ala C
unions). They may also be defined as augmentations (explained below unions). They may also be defined as augmentations (explained in
in 4.5.6) 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 protocol document to define, not the such representations are for the protocol document to define, not the
model document. Strings and octetstrings must be conveyed with their model document. Strings and octetstrings must be conveyed with their
length, as they are not delimited, and are variable length. length, as they are not delimited, and are variable length.
With regard to strings, this model defines a small set of With regard to strings, this model defines a small set of
skipping to change at page 53, line 27 skipping to change at page 52, line 27
the path within the target LFB instance to the target component. The the path within the target LFB instance to the target component. The
type of the target element must match the declared type of the alias. type of the target element must match the declared type of the alias.
Details of the alias property structure are described in the section Details of the alias property structure are described in the section
of this document on properties. 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. Augmentationst 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 can be replaced in the definition of an augmenting
structure, but only with an augmentation derived from the current structure, but only with an augmentation derived from the current
type of the existing component. An existing component cannot be type of the existing component. An existing component cannot be
deleted. If the existing compound type is an array, augmentation deleted. If the existing compound type is an array, augmentation
means augmentation of the array element type. means augmentation of the array element type.
skipping to change at page 54, line 37 skipping to change at page 53, line 37
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 yet enforced by the XML schema. not yet enforced by the XML schema.
The second form is an explicit type definition using the <atomic> The second form is an explicit type definition using the <atomic>
element. This element is used here in the same way as in the element. This element is used here in the same way as in the
<dataTypeDef> elements. <dataTypeDef> elements.
. The following example shows both usages: The following example shows both usages:
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>NEXTHOPID</name> <name>NEXTHOPID</name>
<synopsis>Refers to a Next Hop entry in NH LFB</synopsis> <synopsis>Refers to a Next Hop entry in NH LFB</synopsis>
<metadataID>17</metaDataID> <metadataID>17</metaDataID>
<typeRef>int32</typeRef> <typeRef>int32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>CLASSID</name> <name>CLASSID</name>
skipping to change at page 64, line 9 skipping to change at page 63, line 9
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 more than one possible access mode for a The LFB class may define only one possible access mode for a given
given component (for example, "write-only" and "read-write"), in component.
which case it is left to the actual implementation to pick one of the
modes. In such cases, a corresponding property component must inform
the CE about the access mode the actual LFB instance supports.
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. An
<component> element MUST contain the following elements: <component> element MUST contain the following elements:
o <name> defines the name of the component.This name must be unique o <name> defines the name of the component.This name must be unique
among the components of the LFB class. Example: "version". among the components of the LFB class. Example: "version".
o <synopsis> should provide a brief description of the purpose of o <synopsis> should provide a brief description of the purpose of
the component. the component.
skipping to change at page 64, line 47 skipping to change at page 63, line 44
o The optional <defaultValue> element can specify a default value o The optional <defaultValue> element can specify a default value
for the component, which is applied when the LFB is initialized or for the component, which is applied when the LFB is initialized or
reset. reset.
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 or even a list of these values: "read-only", "read-write", values: "read-only", "read-write", "write-only", "read-reset", and
"write-only", "read-reset", and "trigger-only". The default access "trigger-only". The default access mode is "read-write".
mode is "read-write".
Whether optional components are supported, and whether components Whether optional components are supported, and whether components
defined as read-write can actually be written can be determined for a defined as read-write can actually be written can be determined for a
given LFB instance by the CE by reading the property information of given LFB instance by the CE by reading the property information of
that component. that component. An access control setting of "trigger-only" means
that this component is included only for use in event detection.
The following example defines two attributes for an LFB: The following example defines two attributes for an LFB:
<components> <components>
<component access="read-only" componentID=1> <component access="read-only" componentID=1>
<name>foo</name> <name>foo</name>
<synopsis>number of things</synopsis> <synopsis>number of things</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component access="read-write write-only" componentID=2> <component access="read-write" componentID=2>
<name>bar</name> <name>bar</name>
<synopsis>number of this other thing</synopsis> <synopsis>number of this other thing</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="10" max="2000"/> <allowedRange min="10" max="2000"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
<defaultValue>10</defaultValue> <defaultValue>10</defaultValue>
</component> </component>
</component> </component>
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 attribute has element to provide additional range restrictions. This component has
two possible access modes, "read-write" or "write-only". A default access mode of read-write allowing it to be both read and written. A
value of 10 is provided. default value of 10 is provided for bar. although the access for bar
is read-write, some implementations may offer only more restrictive
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 attributes anyway. The FORCES protocol existent or non-permitted attributes 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 component can also
apply to attempts to reference non-existent array elements or to set apply to attempts to reference non-existent array elements or to set
read-only components. read-only components.
skipping to change at page 67, line 9 skipping to change at page 66, line 9
Maximum value of the "bar" attribute. Maximum value of the "bar" attribute.
</synopsis> </synopsis>
<typeRef>uint16</typeRef> <typeRef>uint16</typeRef>
</capability> </capability>
</capabilities> </capabilities>
4.7.6. <events> Element for LFB Notification Generation 4.7.6. <events> Element for LFB Notification Generation
The <events> element contains the information about the occurrences The <events> element contains the information about the occurrences
for which instances of this LFB class can generate notifications to for which instances of this LFB class can generate notifications to
the CE. the CE. High level view on the declaration and operation of LFB
events is described in Section 3.2.5.
The <events> element contains 0 or more <event> elements, each of
which declares a single event. The <event> element has an eventID
attribute giving the unique (per LFB class) ID of the event. The
element will include:
o <eventTarget> element indicating which LFB field (component) is
tested to generate the event;
o <condition> element indicating what condition on the field will
generate the event from a list of defined conditions;
o <eventReports> element indicating what values are to be reported
in the notification of the event.
The example below demonstrates the different constructs.
The <events> element has a baseID attribute value, which is normally The <events> element has a baseID attribute value, which is normally
<events baseID="number">. The value of the baseID is the starting <events baseID="number">. The value of the baseID is the starting
componentID for the path which identifies events. It must not be the componentID for the path which identifies events. It must not be the
same as the componentID of any top level components (including same as the componentID of any top level components (including
capabilities) of the LFB class. In derived LFBs (i.e. ones with a capabilities) of the LFB class. In derived LFBs (i.e. ones with a
<derivedFrom> element) where the parent LFB class has an events <derivedFrom> element) where the parent LFB class has an events
declaration, the baseID must not be present in the derived LFB declaration, the baseID must not be present in the derived LFB
<events> element. Instead, the baseID value from the parent LFB <events> element. Instead, the baseID value from the parent LFB
class is used. class is used. In the example shown the baseID is 7.
The <events> element contains 0 or more <event> elements, each of <events baseID="7">
which declares a single event. The <event> element has an eventID <event eventID="7">
attribute giving the unique ID of the event. The element will <name>Foochanged</name>
include: <synopsis>
An example event for a scalar
</synopsis>
<eventTarget>
<eventField>foo</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state -->
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
o <eventTarget> element indicating which LFB field (component) is <event eventID="8">
tested to generate the event; <name>Goof1changed</name>
<synopsis>
An example event for a complex structure
</synopsis>
<eventTarget>
<!-- target is goo.f1 -->
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<!-- report the new state of goo.f1 -->
<eventReport>
<eventField>goo</eventField>
<eventField>f1</eventField>
</eventReport>
</eventReports>
</event>
o <condition> element indicating what condition on the field will <event eventID="9">
generate the event from a list of defined conditions; <name>NewbarEntry</name>
<synopsis>
Event for a new entry created on table bar
</synopsis>
<eventTarget>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>bar</eventField>
<eventSubscript>_barIndex_</eventSubscript>
</eventReport>
<eventReport>
<eventField>foo</eventField>
</eventReport>
</eventReports>
</event>
o <eventReports> element indicating what values are to be reported <event eventID="10">
in the notification of the event. <name>Gah11changed</name>
<synopsis>
Event for table gah, entry index 11 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>11</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="11">
<name>Gah10field1</name>
<synopsis>
Event for table gah, entry index 10, column field1 changing
</synopsis>
<eventTarget>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
<eventField>field1</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>gah</eventField>
<eventSubscript>10</eventSubscript>
</eventReport>
</eventReports>
</event>
<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. Specifically, the <target> element contains one or more the LFB that is to be monitored for events.
<eventField> or <eventSubscript> elements. These elements represent
the textual equivalent of a path select component of the LFB. The
<eventField> element contains the name of a component in the LFB or a
component nested in an array or struct within the LFB. The first
element in a <target> MUST be an <eventField> element and MUST name a
componet in the LFB. The following element MUST identify a valid
component within the containing context. If an <eventField>
identifies an array, and is not the last element in the target, then
the next element MUST be an < eventSubscript> element.
<eventSubscript> elements MUST occur only after <eventField> names
that identifies an array component. An <eventSubscript> may contain
a numeric value to indicate that this event applies to a specific
entry (by index) of the array. More commonly, the event is being
defined across all elements of the array. In that case,
<eventSubscript> will contain a name. The name in an
<eventSubscript> element is not a component name. It is a variable
name for use in the <report> elements of this LFB definition. This
name MUST be distinct from any component name that can validly occur
in the <eventReport> clause. Hence it SHOULD be distinct from any
component name used in the LFB or in structures used within the LFB.
The <eventTarget> provides additional components for the path used to The <eventTarget> element contains one or more <eventField> each of
reference the event. The path will be the baseID for events, which may be followed by one or more <eventSubscript> elements. Each
followed by the ID for the specific event, followed by a value for of these two elements represent the textual equivalent of a path
each <eventSubscript> element in the <eventTarget>. This will select component of the LFB.
identify a specific occurrence of the event. So, for example, it
will appear in the event notification LFB. It is also used for the
SET-PROPERTY operation to subscribe to a specific event. A SET-
PROPERTY of the subscription property (but not of any other writeable
properties) may be sent by the CE with any prefix of the path of the
event. So, for an event defined on a table, a SET- PROPERTY with a
path of the baseID and the eventID will subscribe the CE to all
occurrences of that event on any entry of the table. This is
particularly useful for the <eventCreated/> and <eventDestroyed/>
conditions. Events using those conditions will generally be defined
with a field / subscript sequence that identifies an array and ends
with an <eventSubscript> element. Thus, the event notification will
indicate which array entry has been created or destroyed. A typical
subscriber will subscribe for the array, as opposed to a specific
entry in an array, so it will use a shorter path.
Thus, if there is an LFB with an event baseID of 7, and a specific The <eventField> element contains the name of a component in the LFB
event with an event ID of 8, then one can subscribe to the event by or a component nested in an array or structure within the LFB. The
referencing the properties of the LFB component with path 7.8. If name used in <eventField> MUST identify a valid component within the
the event target has no subscripts (for example, it is a simple containing LFB context. The first element in a <eventTarget> MUST be
component of the LFB) then one can also reference the event threshold an <eventField> element. In the example shown, four LFB components
and filtering properties via the properties on element 7.8. If the foo, goo, bar and gah are used as <eventField>s.
event target is defined as a entry in an array, then the target
definition will include an <eventSubscript> element. In that case,
one can subscribe to the event for the entire array by referencing
the properties of 7.8. One can also subscribe to a specific element,
x, of the array by referencing the subscription property of 7.8.x and
also access the threshold and filtering properties of 7.8.x. If the
event is targeting an entry in an array within an array, then there
will be two (or conceivably more) <eventSubscript> elements in the
target description. If so, for the case of two elements, one would
reference the properties of 7.8.x.y to get to the threshold and
filtering properties of an individual event.
Threshold and filtering conditions can only be applied to individual In the simple case, an <eventField> identifies an atomic component.
events. For events defined on elements of an array, this This is the case illustrated in the event named Foochanged.
specification does not allow for defining a threshold or filtering <eventField> is also used to address complex components such as
condition on an event for all elements of an array. arrays or structures.
4.7.6.2. <events> Element Conditions The first defined event, Foochanged, demonstrates how a scalar LFB
component, foo, could be monitored to trigger an event.
The condition element represents a condition that triggers a The second event, Goof1changed, demonstrates how a member of the
complex structure goo could be monitored to trigger an event.
The events named NewbarEntry, Gah11changed and Gah10field1
represent monitoring of arrays bar and gah in differing details.
If an <eventField> identifies a complex component then a further
<eventField> may be used to refine the path to the target element.
Defined event Goof1changed demonstrates how a second <eventField> is
used to point to member f1 of the structure goo.
If an <eventField> identifies an array then the following rules
apply:
o <eventSubscript> elements MUST be present as the next XML element
after an <eventField> which identifies an array component.
<eventSubscript> MUST not occur other than after an array
reference, as it is only meaningful in that context.
o An <eventSubscript> may contain:
* A numeric value to indicate that the event applies to a
specific entry (by index) of the array. As an example, event
Gah11changed shows how table gah's index 11 is being targeted
for monitoring.
* 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
for all indices). In that case, the value of the
<eventSubscript> MUST be a name rather than a numeric value.
That same name can then be used as the value of
<eventSubscript> in <eventReport> elements as described below.
An example of a wild card table index is shown in event
NewBarentry where the <eventSubscript> value is named
_barIndex_
o An <eventField> may follow an <eventSubscript> to further refine
the path to the target element (Note: this is in the same spirit
as the case where <eventField> is used to further refine
<eventField> in the ealier example of a complex structure example
of Goof1changed). The example event Gah10field1 illustrates the
how the column field1 of table gah is monitored for changes.
It should be emphasized that the name in an <eventSubscript> element
in defined event NewbarEntry is not a component name. It is a
variable name for use in the <eventReport> elements (described in
Section 4.7.6.3) of the given LFB definition. This name MUST be
distinct from any component name that can validly occur in the
<eventReport> clause.
4.7.6.2. <eventCondition> Element
The event condition element represents a condition that triggers a
notification. The list of conditions is: notification. The list of conditions is:
o <eventCreated/> the target must be an array, ending with a o <eventCreated/> the target must be an array, ending with a
subscript indication. The event is generated when an entry in the subscript indication. The event is generated when an entry in the
array is created. This occurs even if the entry is created by CE array is created. This occurs even if the entry is created by CE
direction. direction. The event example NewbarEntry demonstrates the
<eventCreated/> condition.
o <eventDeleted/> the target must be an array, ending with a o <eventDeleted/> the target must be an array, ending with a
subscript indication. The event is generated when an entry in the subscript indication. The event is generated when an entry in the
array is destroyed. This occurs even if the entry is destroyed by array is destroyed. This occurs even if the entry is destroyed by
CE direction. CE direction.
o <eventChanged/> the event is generated whenever the target o <eventChanged/> the event is generated whenever the target
component changes in any way. For binary components such as up/ component changes in any way. For binary components such as up/
down, this reflects a change in state. It can also be used with down, this reflects a change in state. It can also be used with
numeric attributes, in which case any change in value results in a numeric attributes, in which case any change in value results in a
detected trigger. detected trigger. Event examples Foochanged, Gah11changed, and
Gah10field1 illustrate the <eventChanged/> condition.
o <eventGreaterThan/> the event is generated whenever the target o <eventGreaterThan/> the event is generated whenever the target
component becomes greater than the threshold. The threshold is an component becomes greater than the threshold. The threshold is an
event property. event property.
o <eventLessThan/> the event is generated whenever the target o <eventLessThan/> the event is generated whenever the target
component becomes less than the threshold. The threshold is an component becomes less than the threshold. The threshold is an
event property. event property.
As described in the Event Properties section, event items have
properties associated with them. These properties include the
subscription information (indicating whether the CE wishes the FE to
generate event reports for the event at all, thresholds for events
related to level crossing, and filtering conditions that may reduce
the set of event notifications generated by the FE. Details of the
filtering conditions that can be applied are given in that section.
The filtering conditions allow the FE to suppress floods of events
that could result from oscillation around a condition value. For FEs
that do not wish to support filtering, the filter properties can
either be read only or not supported.
4.7.6.3. <eventReports> Element 4.7.6.3. <eventReports> Element
The <eventReports> element of an <event> describes the information to The <eventReports> element of an <event> declare the information to
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. The <reports> element contains one or more of the event.
<eventReport> elements. Each <report> element identifies a piece of
data from the LFB to be reported. The notification carries that data The <eventReports> element contains one or more <eventReport>
as if the collection of <eventReport> elements had been defined in a elements. Each <eventReport> element identifies a piece of data from
structure. Each <eventReport> element thus MUST identify a component the LFB class to be reported. The notification carries that data as
in the LFB. The syntax is exactly the same as used in the if the collection of <eventReport> elements had been defined in a
structure. The syntax is exactly the same as used in the
<eventTarget> element, using <eventField> and <eventSubscript> <eventTarget> element, using <eventField> and <eventSubscript>
elements. <eventSubcripts> may contain integers. If they contain elements and so the same rules apply. Each <eventReport> element
names, they MUST be names from <eventSubscript> elements of the thus MUST identify a component in the LFB class. <eventSubcript> may
<eventTarget>. The selection for the report will use the value for contain integers. If they contain names, they MUST be names from
the subscript that identifies that specific element triggering the <eventSubscript> elements of the <eventTarget> in the event. The
event. This can be used to reference the Component causing the selection for the report will use the value for the subscript that
event, or to reference related information in parallel tables. This identifies that specific element triggering the event. This can be
event reporting structure is designed to allow the LFB designer to used to reference the component causing the event, or to reference
specify information that is likely not known a priori by the CE and related information in parallel tables.
is likely needed by the CE to process the event. While the structure
allows for pointing at large blocks of information (full arrays or In the example shown, in the case of the event Foochanged, the report
complex structures) this is not recommended. Also, the variable will carry the value of foo; in the case of the defined event
reference / subscripting in reporting only captures a small portion NewbarEntry acting on LFB component bar, which is an array, there are
of the kinds of related information. Chaining through index fields two items that are reported as indicated by the two <eventReport>
stored in a table, for example, is not supported. In general, the declarations:
<eventReports> mechanism is an optimization for cases that have been
found to be common, saving the CE from having to query for o The first <eventReport> details what new entry was added in the
table bar. Recall that _barIndex_ is declared as the event's
<eventTarget> <eventSubcript> and that by virtue of using a name
instead of a numeric value, the <eventSubcript> is implied to be a
wildcard and will carry whatever index of the new entry.
o The second <eventReport> includes the value of LFB component foo
at the time the new entry was created in bar. Reporting foo in
this case is provided to demonstrate the flexibility of event
reporting.
This event reporting structure is designed to allow the LFB designer
to specify information that is likely not known a priori by the CE
and is likely needed by the CE to process the event. While the
structure allows for pointing at large blocks of information (full
arrays or complex structures) this is not recommended. Also, the
variable reference/subscripting in reporting only captures a small
portion of the kinds of related information. Chaining through index
fields stored in a table, for example, is not supported. In general,
the <eventReports> mechanism is an optimization for cases that have
been found to be common, saving the CE from having to query for
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 support optional elements. Any components which do the The report MUST use a protocol format that supports optional
not exist are not reported. elements and allows for the non-existence of such elements. Any
components which do not exist are not reported.
4.7.6.4. Runtime control of events
High level view on the declaration and operation of LFB events is
described in Section 3.2.5.
The <eventTarget> provides additional components used in the path to
reference the event. The path constitutes the baseID for events,
followed by the ID for the specific event, followed by a value for
each <eventSubscript> element if it exists in the <eventTarget>.
The event path will uniquely identify a specific occurrence of the
event in the event notification to the CE. In the example provided,
a notification with path of 7.7 uniquely identifies the event to be
that caused by the change of foo; an event with path 7.9.100 uniquely
identifies the event to be that caused by a creation of table bar
entry with index/subscript 100.
As described in the Section 4.8.5, event elements have properties
associated with them. These properties include the subscription
information indicating whether the CE wishes the FE to generate event
reports for the event at all, thresholds for events related to level
crossing, and filtering conditions that may reduce the set of event
notifications generated by the FE. Details of the filtering
conditions that can be applied are given in that section. The
filtering conditions allow the FE to suppress floods of events that
could result from oscillation around a condition value. For FEs that
do not wish to support filtering, the filter properties can either be
read only or not supported.
In addition to identifying the event sources, the CE also uses the
event path to activate runtime control of the event via the event
properties (defined in Section 4.8.5) utilizing SET-PROP protocol
operation.
To activate event generation on the FE, a SET-PROP message
referencing the event and registration property of the event is
issued to the FE by the CE with any prefix of the path of the event.
So, for an event defined on the example table bar, a SET-PROP with a
path of 7.9 will subscribe the CE to all occurrences of that event on
any entry of the table. This is particularly useful for the
<eventCreated/> and <eventDestroyed/> conditions on tables. Events
using those conditions will generally be defined with a field/
subscript sequence that identifies an array and ends with an
<eventSubscript> element. Thus, the event notification will indicate
which array entry has been created or destroyed. A typical
subscriber will subscribe for the array, as opposed to a specific
entry in an array, so it will use a shorter path.
In the example provided, subscribing to 7.8 implies receiving all
declared events from table bar. Subscribing to 7.8.100 implies
receiving an event when subscript/index 100 table entry is created.
Threshold and filtering conditions can only be applied to individual
events. For events defined on elements of an array, this
specification does not allow for defining a threshold or filtering
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 verbally describe what the LFB does.
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 up 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 PL
protocol. While some property information is writeable, there is no protocol. While some property information is writeable, there is no
mechanism currently provided for checking the properties of a mechanism currently provided for checking the properties of a
property element. Writeability can only be checked by attempting to property element. Writeability can only be checked by attempting to
skipping to change at page 76, line 38 skipping to change at page 78, line 38
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>eventCount</name> <name>eventCount</name>
<synopsis> number of occurrences to suppress <synopsis> number of occurrences to suppress
</synopsis> </synopsis>
</optional> </optional>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>eventHysteresis</name> <name>eventInterval</name>
<synopsis> time interval in ms between notifications <synopsis> time interval in ms between notifications
</synopsis> </synopsis>
</optional> </optional>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
<dataTypeDef> <dataTypeDef>
4.8.5.1. Common Event Filtering 4.8.5.1. Common Event Filtering
skipping to change at page 85, line 31 skipping to change at page 87, line 31
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="inputPortType"> <xsd:complexType name="inputPortType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="expectation" type="portExpectationType"/> <xsd:element name="expectation" type="portExpectationType"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="group" type="booleanType" use="optional" <xsd:attribute name="group" type="booleanType" use="optional"
default="no"/> default="0"/>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="portExpectationType"> <xsd:complexType name="portExpectationType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="frameExpected" minOccurs="0"> <xsd:element name="frameExpected" minOccurs="0">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<!-- ref must refer to a name of a defined frame type --> <!-- ref must refer to a name of a defined frame type -->
<xsd:element name="ref" type="xsd:string" <xsd:element name="ref" type="xsd:string"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
skipping to change at page 87, line 6 skipping to change at page 89, line 6
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="outputPortType"> <xsd:complexType name="outputPortType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="product" type="portProductType"/> <xsd:element name="product" type="portProductType"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="group" type="booleanType" use="optional" <xsd:attribute name="group" type="booleanType" use="optional"
default="no"/> default="0"/>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="portProductType"> <xsd:complexType name="portProductType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="frameProduced"> <xsd:element name="frameProduced">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<!-- ref must refer to a name of a defined frame type <!-- ref must refer to a name of a defined frame type
--> -->
<xsd:element name="ref" type="xsd:NMTOKEN" <xsd:element name="ref" type="xsd:NMTOKEN"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
skipping to change at page 92, line 35 skipping to change at page 94, line 35
<synopsis> <synopsis>
The name of a supported LFB Class The name of a supported LFB Class
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>LFBClassID</name> <name>LFBClassID</name>
<synopsis>the id of a supported LFB Class</synopsis> <synopsis>the id of a supported LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID=??3??> <component componentID="3">
<name>LFBVersion</name> <name>LFBVersion</name>
<synopsis> <synopsis>
The version of the LFB Class used The version of the LFB Class used
by this FE. by this FE.
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component>
<component componentID="4"> <component componentID="4">
<name>LFBOccurrenceLimit</name> <name>LFBOccurrenceLimit</name>
<synopsis> <synopsis>
the upper limit of instances of LFBs of this class the upper limit of instances of LFBs of this class
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<!-- For each port group, how many ports can exist <!-- For each port group, how many ports can exist
--> -->
skipping to change at page 94, line 29 skipping to change at page 96, line 30
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>InterfaceToNeighbor</name> <name>InterfaceToNeighbor</name>
<synopsis> <synopsis>
FE's interface that connects to this neighbor FE's interface that connects to this neighbor
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
<component componentID=??3??> <component componentID="3">
<name>NeighborInterface</name> <name>NeighborInterface</name>
<synopsis> <synopsis>
The name of the interface on the neighbor to The name of the interface on the neighbor to
which this FE is adjacent. This is required which this FE is adjacent. This is required
In case two FE?s are adjacent on more than In case two FEs are adjacent on more than
one interface. one interface.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>LFBSelectorType</name> <name>LFBSelectorType</name>
<synopsis> <synopsis>
skipping to change at page 97, line 6 skipping to change at page 99, line 7
<typeRef>string[40]</typeRef> <typeRef>string[40]</typeRef>
</component> </component>
<component access="read-only" componentID="7"> <component access="read-only" componentID="7">
<name>FEState</name> <name>FEState</name>
<synopsis>model of this FE</synopsis> <synopsis>model of this FE</synopsis>
<typeRef>FEStatusValues</typeRef> <typeRef>FEStatusValues</typeRef>
</component> </component>
<component access="read-write" componentID="8"> <component access="read-write" componentID="8">
<name>FENeighbors</name> <name>FENeighbors</name>
<synopsis>table of known neighbors</synopsis> <synopsis>table of known neighbors</synopsis>
<optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>FEConfiguredNeighborType</typeRef> <typeRef>FEConfiguredNeighborType</typeRef>
</array> </array>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>ModifiableLFBTopology</name> <name>ModifiableLFBTopology</name>
<synopsis> <synopsis>
Whether Modifiable LFB is supported Whether Modifiable LFB is supported
skipping to change at page 100, line 16 skipping to change at page 102, line 17
precede in the topology. In this component, the entries in the precede in the topology. In this component, the entries in the
viaPort component of the array value represent the output port groups viaPort component of the array value represent the output port groups
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. LFBClassCapabilitiese 5.2.2.8. LFBClassCapabilities
While it would be desirable to include class capability level While it would be desirable to include class capability level
information, this is not included in the model. While such information, this is not included in the model. While such
information belongs in the FE Object in the supported class table, information belongs in the FE Object in the supported class table,
the contents of that information would be class specific. The the contents of that information would be class specific. The
currently expected encoding structures for transferring information currently expected encoding structures for transferring information
between the CE and FE are such that allowing completely unspecified between the CE and FE are such that allowing completely unspecified
information would be likely to induce parse errors. We could specify information would be likely to induce parse errors. We could specify
that the information is encoded in an octetstring, but then we would that the information is encoded in an octetstring, but then we would
have to define the internal format of that octet string. have to define the internal format of that octet string.
skipping to change at page 101, line 37 skipping to change at page 103, line 42
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
represent the results of any discovery protocols, as those will have represent the results of any discovery protocols, as those will have
their own LFBs. their own LFBs. This component is optional.
While there may be many ways to configure neighbors, the FE-ID is the While there may be many ways to configure neighbors, the FE-ID is the
best way for the CE to correlate entities. And the interface best way for the CE to correlate entities. And the interface
identifier (name string) is the best correlator. The CE will be able identifier (name string) is the best correlator. The CE will be able
to determine the IP address and media level information about the to determine the IP address and media level information about the
neighbor from the neighbor directly. Omitting that information from neighbor from the neighbor directly. Omitting that information from
this table avoids the risk of incorrect double configuration. this table avoids the risk of incorrect double configuration.
Information about the intended forms of exchange with a given Information about the intended forms of exchange with a given
neighbor is not captured here, only the adjacency information is neighbor is not captured here, only the adjacency information is
included. included.
5.3.4.1. NeighborID 5.3.4.1. NeighborID
This is the ID in some space meaningful to the CE for the neighbor. This is the ID in some space meaningful to the CE for the neighbor.
If this table remains, we probably should add an FEID from the same
space as an attribute of the FE.
5.3.4.2. InterfaceToNeighbor 5.3.4.2. InterfaceToNeighbor
This identifies the interface through which the neighbor is reached. This identifies the interface through which the neighbor is reached.
5.3.4.3. NeighborInterface 5.3.4.3. NeighborInterface
This identifies the interface on the neighbor through which the This identifies the interface on the neighbor through which the
neighbor is reached. The interface identification is needed when neighbor is reached. The interface identification is needed when
either only one side of the adjacency has configuration information, either only one side of the adjacency has configuration information,
or the two FEs are adjacent on more than one interface. or the two FEs are adjacent on more than one interface.
6. Satisfying the Requirements on FE Model 6. Satisfying the Requirements on FE Model
This section describes how the proposed FE model meets the This section describes how the proposed FE model meets the
requirements outlined in Section 5 of [2]. The requirements can be requirements outlined in Section 5 of RFC3654 [2]. The requirements
separated into general requirements (Section 5, 5.1 - 5.4) and the can be separated into general requirements (Section 5, 5.1 - 5.4) and
specification of the minimal set of logical functions that the FE the specification of the minimal set of logical functions that the FE
model must support (Section 5.5). model must support (Section 5.5).
The general requirement on the FE model is that it be able to express The general requirement on the FE model is that it be able to express
the logical packet processing capability of the FE, through both a the logical packet processing capability of the FE, through both a
capability and a state model. In addition, the FE model is expected capability and a state model. In addition, the FE model is expected
to allow flexible implementations and be extensible to allow defining to allow flexible implementations and be extensible to allow defining
new logical functions. new logical functions.
A major component of the proposed FE model is the Logical Function A major component of the proposed FE model is the Logical Function
Block (LFB) model. Each distinct logical function in an FE is Block (LFB) model. Each distinct logical function in an FE is
skipping to change at page 104, line 10 skipping to change at page 106, line 10
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 mandates a many ways. Neither this document nor the ForCES protocol mandates a
specific mechanism. The LFB Class definition does include the specific mechanism. The LFB Class definition does include the
capability for an FE to be configured with, and provides to the CE in capability for an FE to be configured with, and provides to the CE in
response to a query, the identity of its neighbors. There may also response to a query, the identity of its neighbors. There may also
be defined specific LFB classes and protocols for neighbor discovery. be defined specific LFB classes and protocols for neighbor discovery.
Routing protocols may be used by the CE for adjacency determination. Routing protocols may be used by the CE for adjacency determination.
The CE may be configured with the relevant information. The CE may be configured with 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 8: messages are visualized in Figure 12:
+--------+ +--------+
..........-->| CE | ..........-->| CE |
/----\ . +--------+ /----\ . +--------+
\____/ FE Model . ^ | \____/ FE Model . ^ |
| |................ (1),2 | | 6, 7 | |................ (1),2 | | 6, 7
| | (off-line) . 3, 4, 5 | | | | (off-line) . 3, 4, 5 | |
\____/ . | v \____/ . | v
. +--------+ . +--------+
e.g. RFCs ..........-->| FE | e.g. RFCs ..........-->| FE |
+--------+ +--------+
Figure 8: Relationship between the FE model and the ForCES protocol Figure 12: Relationship between the FE model and the ForCES protocol
messages, where (1) is part of the ForCES base protocol, and the messages, where (1) is part of the ForCES base protocol, and the
rest are defined by the FE model. rest are defined by the FE model.
The actual encoding of these messages is defined by the ForCES The actual encoding of these messages is defined by the ForCES
protocol and beyond the scope of the FE model. Their discussion is protocol and beyond the scope of the FE model. Their discussion is
nevertheless important here for the following reasons: nevertheless important here for the following reasons:
o These PA model components have considerable impact on the FE o These PA model components have considerable impact on the FE
model. For example, some of the above information can be model. For example, some of the above information can be
represented as attributes of the LFBs, in which case such represented as attributes of the LFBs, in which case such
skipping to change at page 105, line 29 skipping to change at page 107, line 29
the ForCES packet encapsulation and decapsulation in such cases. the ForCES packet encapsulation and decapsulation in such cases.
The remaining sub-sections of this section address each of the seven The remaining sub-sections of this section address each of the seven
message types. message types.
7.1. FE Topology Query 7.1. FE Topology Query
An FE may contain zero, one or more external ingress ports. An FE may contain zero, one or more external ingress ports.
Similarly, an FE may contain zero, one or more external egress ports. Similarly, an FE may contain zero, one or more external egress ports.
In other words, not every FE has to contain any external ingress or In other words, not every FE has to contain any external ingress or
egress interfaces. For example, Figure 9 shows two cascading FEs. egress interfaces. For example, Figure 13 shows two cascading FEs.
FE #1 contains one external ingress interface but no external egress FE #1 contains one external ingress interface but no external egress
interface, while FE #2 contains one external egress interface but no interface, while FE #2 contains one external egress interface but no
ingress interface. It is possible to connect these two FEs together ingress interface. It is possible to connect these two FEs together
via their internal interfaces to achieve the complete ingress-to- via their internal interfaces to achieve the complete ingress-to-
egress packet processing function. This provides the flexibility to egress packet processing function. This provides the flexibility to
spread the functions across multiple FEs and interconnect them spread the functions across multiple FEs and interconnect them
together later for certain applications. together later for certain applications.
While the inter-FE communication protocol is out of scope for ForCES, While the inter-FE communication protocol is out of scope for ForCES,
it is up to the CE to query and understand how multiple FEs are it is up to the CE to query and understand how multiple FEs are
inter-connected to perform a complete ingress-egress packet inter-connected to perform a complete ingress-egress packet
processing function, such as the one described in Figure 9. The processing function, such as the one described in Figure 13. The
inter-FE topology information may be provided by FEs, may be hard- inter-FE topology information may be provided by FEs, may be hard-
coded into CE, or may be provided by some other entity (e.g., a bus coded into CE, or may be provided by some other entity (e.g., a bus
manager) independent of the FEs. So while the ForCES protocol manager) independent of the FEs. So while the ForCES protocol
supports FE topology query from FEs, it is optional for the CE to use supports FE topology query from FEs, it is optional for the CE to use
it, assuming the CE has other means to gather such topology it, assuming the CE has other means to gather such topology
information. information.
+-----------------------------------------------------+ +-----------------------------------------------------+
| +---------+ +------------+ +---------+ | | +---------+ +------------+ +---------+ |
input| | | | | | output | input| | | | | | output |
skipping to change at page 106, line 23 skipping to change at page 108, line 23
+-----------------------<-----------------------------+ +-----------------------<-----------------------------+
| |
| +----------------------------------------+ | +----------------------------------------+
V | +------------+ +----------+ | V | +------------+ +----------+ |
| input | | | | output | | input | | | | output |
+->--+->|Header |-->| Egress |---------+--> +->--+->|Header |-->| Egress |---------+-->
| |Compressor | | port | FE | | |Compressor | | port | FE |
| +------------+ +----------+ #2 | | +------------+ +----------+ #2 |
+----------------------------------------+ +----------------------------------------+
Figure 9: An example of two FEs connected together Figure 13: An example of two FEs connected together
Once the inter-FE topology is discovered by the CE after this query, Once the inter-FE topology is discovered by the CE after this query,
it is assumed that the inter-FE topology remains static. However, it it is assumed that the inter-FE topology remains static. However, it
is possible that an FE may go down during the NE operation, or a is possible that an FE may go down during the NE operation, or a
board may be inserted and a new FE activated, so the inter-FE board may be inserted and a new FE activated, so the inter-FE
topology will be affected. It is up to the ForCES protocol to topology will be affected. It is up to the ForCES protocol to
provide a mechanism for the CE to detect such events and deal with provide a mechanism for the CE to detect such events and deal with
the change in FE topology. FE topology is outside the scope of the the change in FE topology. FE topology is outside the scope of the
FE model. FE model.
skipping to change at page 109, line 29 skipping to change at page 111, line 29
o Create a new instance of a given LFB class on a given FE. o Create a new instance of a given LFB class on a given FE.
o Connect a given output of LFB x to the given input of LFB y. o Connect a given output of LFB x to the given input of LFB y.
o Disconnect: remove a link between a given output of an LFB and a o Disconnect: remove a link between a given output of an LFB and a
given input of another LFB. given input of another LFB.
o Delete a given LFB (automatically removing all interconnects to/ o Delete a given LFB (automatically removing all interconnects to/
from the LFB). from the LFB).
8. Example 8. Example LFB Definition
This section contains an example LFB definition. While some This section contains an example LFB definition. While some
properties of LFBs are shown by the FE Object LFB, this endeavors to properties of LFBs are shown by the FE Object LFB, this endeavors to
show how a data plain LFB might be build. This example is a show how a data plain LFB might be build. This example is a
fictional case of an interface supporting a coarse WDM optical fictional case of an interface supporting a coarse WDM optical
interface carry Frame Relay traffic. The statistical information interface carry Frame Relay traffic. The statistical information
(including error statistics) is omitted. (including error statistics) is omitted.
Later portions of this example include references to protocol Later portions of this example include references to protocol
operations. The operations described are operations the protocol operations. The operations described are operations the protocol
skipping to change at page 117, line 37 skipping to change at page 119, line 37
data would be needed. This would however be quite complex and noisy. data would be needed. This would however be quite complex and noisy.
The intermediate level of structure here allows parallelism between The intermediate level of structure here allows parallelism between
input and output, without requiring excessive ports. input and output, without requiring excessive ports.
8.1.1. Setting up a DLCI 8.1.1. Setting up a DLCI
When a CE chooses to establish a DLCI on a specific laser channel, it When a CE chooses to establish a DLCI on a specific laser channel, it
sends a SET request directed to this LFB. The request might look sends a SET request directed to this LFB. The request might look
like like
T = SET-OPERATION T = SET
T = PATH-DATA T = PATH-DATA
Path: flags = none, length = 4, path = 2, channel, 4, entryIdx Path: flags = none, length = 4, path = 2, channel, 4, entryIdx
DataRaw: DLCI, Enable(1), false, out-idx DataRaw: DLCI, Enable(1), false, out-idx
Which would establish the DLCI as enabled, with traffic going to a Which would establish the DLCI as enabled, with traffic going to a
specific entry of the output port group DatatoFE. (The CE would specific entry of the output port group DatatoFE. (The CE would
ensure that output port is connected to the right place before ensure that output port is connected to the right place before
issuing this request.) issuing this request.)
The response would confirm the creation of the specified entry. This The response would confirm the creation of the specified entry. This
skipping to change at page 119, line 21 skipping to change at page 121, line 21
the LFB traffic is to be sent to. As mentioned above, the circuit the LFB traffic is to be sent to. As mentioned above, the circuit
index could, in some designs, be combined with the DLCI. index could, in some designs, be combined with the DLCI.
8.3. Capabilities 8.3. Capabilities
The capability information for this LFB includes whether the The capability information for this LFB includes whether the
underlying interface is operational, how many frequencies are underlying interface is operational, how many frequencies are
supported, and how many total circuits, across all channels, are supported, and how many total circuits, across all channels, are
permitted. The maximum number for a given laser channel can be permitted. The maximum number for a given laser channel can be
determined from the properties of the FrameRelayCircuits table. A determined from the properties of the FrameRelayCircuits table. A
GET-Properties on path 2.channel.4 will give the CE the properties of GET-PROP on path 2.channel.4 will give the CE the properties of the
the array which include the number of entries used, the first array which include the number of entries used, the first available
available entry, and the maximum number of entries permitted. entry, and the maximum number of entries permitted.
8.4. Events 8.4. Events
This LFB is defined to be able to generate several events that the CE This LFB is defined to be able to generate several events that the CE
may be interested in. There are events to report changes in may be interested in. There are events to report changes in
operational state of frequencies, and the creation and deletion of operational state of frequencies, and the creation and deletion of
frequency entries. There is an event for changes in status of frequency entries. There is an event for changes in status of
individual frame relay circuits. So an event notification of individual frame relay circuits. So an event notification of
61.5.3.11 would indicate that there had been a circuit status change 61.5.3.11 would indicate that there had been a circuit status change
on subscript 11 of the circuit table in subscript 3 of the frequency on subscript 11 of the circuit table in subscript 3 of the frequency
skipping to change at page 120, line 5 skipping to change at page 122, line 5
the event condition, and the event report content. The event the event condition, and the event report content. The event
properties indicate whether the CE is subscribed to the event, the properties indicate whether the CE is subscribed to the event, the
specific threshold for the event, and any filter conditions for the specific threshold for the event, and any filter conditions for the
event. event.
Another event shown is a laser power problem. This event is Another event shown is a laser power problem. This event is
generated whenever the laser falls below the specified threshold. generated whenever the laser falls below the specified threshold.
Thus, a CE can register for the event of laser power loss on all Thus, a CE can register for the event of laser power loss on all
circuits. It would do this by: circuits. It would do this by:
T = SET-Properties T = SET-PROP
Path-TLV: flags=0, length = 2, path = 61.4 Path-TLV: flags=0, length = 2, path = 61.4
Path-TLV: flags = property-field, length = 1, path = 2 Path-TLV: flags = property-field, length = 1, path = 2
Content = 1 (register) Content = 1 (register)
Path-TLV: flags = property-field, length = 1, path = 3 Path-TLV: flags = property-field, length = 1, path = 3
Content = 15 (threshold) Content = 15 (threshold)
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 9 and 10, each of notifications. (If it flips back and forth between 9 and 10, each
flip down will generate an event.) Suppose that the CE decides to flip down will generate an event.) Suppose that the CE decides to
suppress this oscillation somewhat on laser channel 5. It can do 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 variance property on that event. The request
would look like: would look like:
T = SET-Properties 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. Once common 12 and fall back below 10 to generate another event. Once 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 variance level of 1 will suppress
this sort of condition. Many other events have oscillations that are this sort of condition. Many other events have oscillations that are
somewhat wider, so larger variance settings can be used with those. somewhat wider, so larger variance settings can be used with those.
9. IANA Considerations 9. IANA Considerations
This model creates the need for unique class names and numeric class The Forces model creates the need for unique class names and numeric
identifiers. To meet that goal, IANA will maintain a registry of LFB class identifiers. To meet that goal, IANA will maintain a registry
Class names, corresponding class identifiers, and the document which of LFB Class names, corresponding class identifiers, and the document
defines the LFB Class. The registry policy is simply first come which defines the LFB Class. The registry policy is simply first
first served with regard to LFB Class names. With regard to LFB come first served(FCFS) with regard to LFB Class names. With regard
Class identifiers, identifiers less than 65536 are reserved for to LFB Class identifiers, identifiers less than 65536 are reserved
assignment by RFCs. Identifiers above 65536 are available for for assignment by IETF RFCs. Identifiers above 65536 are available
assignment on a first come, first served basis. Registry entries for assignment on a first come, first served basis. Registry entries
must be documented in a stable, publicly available form. must be documented in a stable, publicly available form.
Since this registry provides for FCFS allocation of a portion of the
class identifier space, it is necessary to define rules for naming
classes that are using that space. As these can be defined by
anyone, the needed rule is to keep the FCFS class names from
colliding with IETF defined class names. Therefore, all FCFS class
names MUST start with the string "Ext-".
The LFBLibrary element and all of its sub-elements are defined in the The LFBLibrary element and all of its sub-elements are defined in the
following namespace: following namespace:
<http://ietf.org/forces/1.0/lfbmodel> <http://ietf.org/forces/1.0/lfbmodel>
[Editor's Note: A registry template registry name, and other parts Table 1 tabulates the above information.
required for a new IANA registry are still needed here.]
+----------+------------+---------------------+---------------------+
| LFB | LFB Class | Place Defined | Description |
| Class | Identifier | | |
| Name | | | |
+----------+------------+---------------------+---------------------+
| Reserved | 0 | This document | Reserved |
| FE | 1 | This document | Defines ForCES |
| Object | | | Forwarding Element |
| | | | information |
| FE | 2 | Editors Note: | Defines parameters |
| Protocol | | Update with | for the ForCES |
| Object | | protocol RFC ref | protocol operation |
| | | here .. | |
+----------+------------+---------------------+---------------------+
Table 1
10. Authors Emeritus 10. Authors Emeritus
The following are the authors who were instrumental in the creation The following are the authors who were instrumental in the creation
of earlier releases of this document. of earlier releases of this document.
Lily Yang, Intel Corp. Lily Yang, Intel Corp.
Ram Gopal, Nokia Research Center Ram Gopal, Nokia Research Center
Alan DeKok, Infoblox, Inc. Alan DeKok, Infoblox, Inc.
Zsolt Haraszti, Clovis Solutions Zsolt Haraszti, Clovis Solutions
11. Acknowledgments 11. Acknowledgments
Many of the colleagues in our companies and participants in the Many of the colleagues in our companies and participants in the
ForCES mailing list have provided invaluable input into this work. ForCES mailing list have provided invaluable input into this work.
Particular thanks to Jamal Hadi Salim for both his direct efforts on
this documents, and his energy in ensuring that work on this
continued.
12. Security Considerations 12. Security Considerations
The FE model describes the representation and organization of data The FE model describes the representation and organization of data
sets and components in the FEs. The ForCES framework document [2] sets and components in the FEs. The ForCES framework document [2]
provides a comprehensive security analysis for the overall ForCES provides a comprehensive security analysis for the overall ForCES
architecture. For example, the ForCES protocol entities must be architecture. For example, the ForCES protocol entities must be
authenticated per the ForCES requirements before they can access the authenticated per the ForCES requirements before they can access the
information elements described in this document via ForCES. Access information elements described in this document via ForCES. Access
to the information contained in the FE model is accomplished via the to the information contained in the FE model is accomplished via the
skipping to change at page 124, line 5 skipping to change at page 125, line 34
Email: jmh@joelhalpern.com Email: jmh@joelhalpern.com
Ellen Deleganes Ellen Deleganes
Intel Corp. Intel Corp.
Mail Stop: CO5-156 15400 NW Greenbrier Parkway Mail Stop: CO5-156 15400 NW Greenbrier Parkway
Beaverton,, OR 97006 Beaverton,, OR 97006
Phone: +1 503 677-4996 Phone: +1 503 677-4996
Email: ellen.m.deleganes@intel.com Email: ellen.m.deleganes@intel.com
Jamal Hadi Salim
Znyx Networks
Ottawa, Ontario
Canada
Email: hadi@znyx.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 185 change blocks. 
858 lines changed or deleted 1011 lines changed or added

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