draft-ietf-forces-model-11.txt   draft-ietf-forces-model-12.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Expires: August 28, 2008 E. Deleganes Expires: January 15, 2009 E. Deleganes
Intel Corp. Intel Corp.
J. Hadi Salim J. Hadi Salim
Znyx Networks Znyx Networks
February 25, 2008 July 14, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-11.txt draft-ietf-forces-model-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 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 August 28, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Comments are solicited and should be addressed to the working group's Comments are solicited and should be addressed to the working group's
mailing list at forces@peach.ease.lsoft.com and/or the author(s). mailing list at forces@peach.ease.lsoft.com and/or the author(s).
Abstract Abstract
This document defines the forwarding element (FE) model used in the This document defines the forwarding element (FE) model used in the
Forwarding and Control Element Separation (ForCES) protocol [2]. The Forwarding and Control Element Separation (ForCES) protocol [2]. The
model represents the capabilities, state and configuration of model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so forwarding elements within the context of the ForCES protocol, so
skipping to change at page 2, line 32 skipping to change at page 2, line 28
3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 10 3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 10
3.1. ForCES Capability Model and State Model . . . . . . . . . 11 3.1. ForCES Capability Model and State Model . . . . . . . . . 11
3.1.1. FE Capability Model and State Model . . . . . . . . . 12 3.1.1. FE Capability Model and State Model . . . . . . . . . 12
3.1.2. Relating LFB and FE Capability and State Model . . . 13 3.1.2. Relating LFB and FE Capability and State Model . . . 13
3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14 3.2. Logical Functional Block (LFB) Modeling . . . . . . . . . 14
3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. LFB Outputs . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20 3.2.2. LFB Inputs . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Component Properties . . . . . . . . . . . . . . . . 27 3.2.6. Component Properties . . . . . . . . . . . . . . . . 28
3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 28 3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 28
3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 28 3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 28
3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 29 3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 29
3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31 3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31
3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32 3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32
3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32 3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32
3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36 3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36
4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40 4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40
4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41 4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41
4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 42 4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 43
4.4. <frameDefs> Element for Frame Type Declarations . . . . . 43 4.4. <frameDefs> Element for Frame Type Declarations . . . . . 44
4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44 4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44
4.5.1. <typeRef> Element for Aliasing Existing Data Types . 46 4.5.1. <typeRef> Element for Renaming Existing Data Types . 47
4.5.2. <atomic> Element for Deriving New Atomic Types . . . 47 4.5.2. <atomic> Element for Deriving New Atomic Types . . . 48
4.5.3. <array> Element to Define Arrays . . . . . . . . . . 47 4.5.3. <array> Element to Define Arrays . . . . . . . . . . 49
4.5.4. <struct> Element to Define Structures . . . . . . . . 52 4.5.4. <struct> Element to Define Structures . . . . . . . . 53
4.5.5. <union> Element to Define Union Types . . . . . . . . 53 4.5.5. <union> Element to Define Union Types . . . . . . . . 54
4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 53 4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 55
4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 54 4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 55
4.6. <metadataDefs> Element for Metadata Definitions . . . . . 55 4.6. <metadataDefs> Element for Metadata Definitions . . . . . 56
4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 56 4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 57
4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 58 4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 60
4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 59 4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 60
4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 61 4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 62
4.7.4. <components> Element to Define LFB Operational 4.7.4. <components> Element to Define LFB Operational
Components . . . . . . . . . . . . . . . . . . . . . 64 Components . . . . . . . . . . . . . . . . . . . . . 65
4.7.5. <capabilities> Element to Define LFB Capability 4.7.5. <capabilities> Element to Define LFB Capability
Components . . . . . . . . . . . . . . . . . . . . . 66 Components . . . . . . . . . . . . . . . . . . . . . 68
4.7.6. <events> Element for LFB Notification Generation . . 68 4.7.6. <events> Element for LFB Notification Generation . . 69
4.7.7. <description> Element for LFB Operational 4.7.7. <description> Element for LFB Operational
Specification . . . . . . . . . . . . . . . . . . . . 75 Specification . . . . . . . . . . . . . . . . . . . . 76
4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 75 4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 76
4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 75 4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 77
4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 77 4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 79
4.8.3. String Properties . . . . . . . . . . . . . . . . . . 77 4.8.3. String Properties . . . . . . . . . . . . . . . . . . 79
4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 78 4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 80
4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 79 4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 81
4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 82 4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 84
4.9. XML Schema for LFB Class Library Documents . . . . . . . 83 4.9. XML Schema for LFB Class Library Documents . . . . . . . 85
5. FE Components and Capabilities . . . . . . . . . . . . . . . 94 5. FE Components and Capabilities . . . . . . . . . . . . . . . 96
5.1. XML for FEObject Class definition . . . . . . . . . . . . 95 5.1. XML for FEObject Class definition . . . . . . . . . . . . 97
5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 101 5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 103
5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 101 5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 104
5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 102 5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 104
5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 104 5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 107
5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 104 5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 105 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 107
5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 105 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 108
5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 105 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 108
6. Satisfying the Requirements on FE Model . . . . . . . . . . . 106 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 109
7. Using the FE model in the ForCES Protocol . . . . . . . . . . 107 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 110
7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 109 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 112
7.2. FE Capability Declarations . . . . . . . . . . . . . . . 110 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 113
7.3. LFB Topology and Topology Configurability Query . . . . . 111 7.3. LFB Topology and Topology Configurability Query . . . . . 114
7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 111 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 114
7.5. State Query of LFB Components . . . . . . . . . . . . . . 112 7.5. State Query of LFB Components . . . . . . . . . . . . . . 115
7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 113 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 116
7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 113 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 116
8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 113 8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 116
8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 120 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 123
8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 121 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 124
8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 122 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 125
8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 122 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 125
8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 123 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 126
8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 123 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 126
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 127
9.1. URN Namespace Registration . . . . . . . . . . . . . . . 124 9.1. URN Namespace Registration . . . . . . . . . . . . . . . 127
9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 125 9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 128
10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 126 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 129
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 129
12. Security Considerations . . . . . . . . . . . . . . . . . . . 127 12. Security Considerations . . . . . . . . . . . . . . . . . . . 130
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.1. Normative References . . . . . . . . . . . . . . . . . . 127 13.1. Normative References . . . . . . . . . . . . . . . . . . 130
13.2. Informative References . . . . . . . . . . . . . . . . . 127 13.2. Informative References . . . . . . . . . . . . . . . . . 130
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131
Intellectual Property and Copyright Statements . . . . . . . . . 129 Intellectual Property and Copyright Statements . . . . . . . . . 132
1. Definitions 1. Definitions
The use of compliance terminology (MUST, SHOULD, MAY) is used in The use of compliance terminology (MUST, SHOULD, MAY) is used in
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 11, line 38 skipping to change at page 11, line 38
The LFB ClassIDs are global within the Network Element and may be The LFB ClassIDs are global within the Network Element and may be
issued by IANA. issued by IANA.
o Within an FE, there can be multiple instances of each LFB class. o Within an FE, there can be multiple instances of each LFB class.
Each LFB Class instance is identified by a 32 bit identifier which Each LFB Class instance is identified by a 32 bit identifier which
is unique within a particular LFB class on that FE. is unique within a particular LFB class on that FE.
o All the components within an LFB instance are further defined o All the components within an LFB instance are further defined
using 32 bit identifiers. using 32 bit identifiers.
Refer to Section 3.3 for more details where we go into details on Refer to Section 3.3 for more details on addressing.
addressing.
3.1. ForCES Capability Model and State Model 3.1. ForCES Capability Model and State Model
Capability and state modelling applies to both the FE and LFB Capability and state modelling applies to both the FE and LFB
abstraction. abstraction.
Figure 1 shows the concepts of FE state, capabilities and Figure 1 shows the concepts of FE state, capabilities and
configuration in the context of CE-FE communication via the ForCES configuration in the context of CE-FE communication via the ForCES
protocol. protocol.
skipping to change at page 14, line 33 skipping to change at page 14, line 33
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 fine grained LFBs will be defined in detail in
documents. one or more documents to be published separately, using the material
in this model.
It is also the case that LFBs may exist in order to provide a set of It is also the case that LFBs may exist in order to provide a set of
components for control of FE operation by the CE (i.e. a locus of components for control of FE operation by the CE (i.e. a locus of
control), without tying that control to specific packets or specific control), without tying that control to specific packets or specific
parts of the data path. An example of such an LFB is the FE Object parts of the data path. An example of such an LFB is the FE Object
which provides the CE with information about the FE as a whole, and which provides the CE with information about the FE as a whole, and
allows the FE to control some aspects of the FE, such as the datapath allows the FE to control some aspects of the FE, such as the datapath
itself. Such FEs will not have the packet oriented properties itself. Such LFBs will not have the packet oriented properties
described in this section. described in this section.
An LFB can have one or more inputs. Each input takes a pair of a In general, multiple LFBs are contained in one FE, as shown in
packet and its associated metadata. Depending upon the LFB input Figure 2, and all the LFBs share the same ForCES protocol termination
port definition, the packet or the metadata may be allowed to be point that implements the ForCES protocol logic and maintains the
empty (or equivalently to not be provided.) At least one of the two communication channel to and from the CE.
must be non-empty, or there is no input. The LFB processes the
input, and produces one or more outputs, each of which is a pair of a
packet and its associated metadata. Again, depending upon the LFB
output port definition, either the packet or the metadata may be
allowed to be empty (or equivalently to be absent.) Metadata is
control information, typically associated with a packet, used in the
network processing device (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 in one FE, as shown in Figure 2, and all
the LFBs share the same ForCES protocol termination point that
implements the ForCES protocol logic and maintains the communication
channel to and from the CE.
+-----------+ +-----------+
| CE | | CE |
+-----------+ +-----------+
^ ^
| Fp reference point | Fp reference point
| |
+--------------------------|-----------------------------------+ +--------------------------|-----------------------------------+
| FE | | | FE | |
| v | | v |
skipping to change at page 16, line 10 skipping to change at page 15, line 48
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 redirection to the while FE to CE communication is used for packet redirection to the
control plane, reporting of monitoring and accounting information, control plane, reporting of monitoring and accounting information,
reporting of errors, etc. Note that the interaction between the CE reporting of errors, etc. Note that the interaction between the CE
and the LFB is only abstract and indirect. The result of such an and the LFB is only abstract and indirect. The result of such an
interaction is for the CE to manipulate the components of the LFB interaction is for the CE to manipulate the components of the LFB
instances. instances.
An LFB can have one or more inputs. Each input takes a pair of a
packet and its associated metadata. Depending upon the LFB input
port definition, the packet or the metadata may be allowed to be
empty (or equivalently to not be provided.) When input arrives at an
LFB, either the packet or its associated metadata must be non-empty
or there is effectively no input. (LFB operation generally may be
triggered by input arrival, by timers, or by other system state. It
is only in the case where the goal is to have input drive operation
that the input must be non-empty.)
The LFB processes the input, and produces one or more outputs, each
of which is a pair of a packet and its associated metadata. Again,
depending upon the LFB output port definition, either the packet or
the metadata may be allowed to be empty (or equivalently to be
absent.) Metadata attached to packets on output may be metadata that
was received, or may be information about the packet processsing that
may be used by later LFBs in the FEs packet processing.
A namespace is used to associate a unique name and ID with each LFB A namespace is used to associate a unique name and ID with each LFB
class. The namespace MUST be extensible so that a new LFB class can class. The namespace MUST be extensible so that a new LFB class can
be added later to accommodate future innovation in the forwarding be added later to accommodate future innovation in the forwarding
plane. plane.
LFB operation is specified in the model to allow the CE to understand LFB operation is specified in the model to allow the CE to understand
the behavior of the forwarding datapath. For instance, the CE must the behavior of the forwarding datapath. For instance, the CE must
understand at what point in the datapath the IPv4 header TTL is understand at what point in the datapath the IPv4 header TTL is
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
be delivered to it either before or after this point in the datapath. be delivered to it either before or after this point in the datapath.
In addition, the CE MUST understand where and what type of header In addition, the CE MUST understand where and what type of header
modifications (e.g., tunnel header append or strip) are performed by modifications (e.g., tunnel header append or strip) are performed by
the FEs. Further, the CE MUST verify that the various LFBs along a the FEs. Further, the CE MUST verify that the various LFBs along a
datapath within an FE are compatible to link together. datapath within an FE are compatible to link together.
There is value to vendors if the operation of LFB classes can be Selecting the right granularity for describing the functions of the
expressed in sufficient detail so that physical devices implementing LFBs is an important aspect of this model. There is value to vendors
different LFB functions can be integrated easily into an FE design. if the operation of LFB classes can be expressed in sufficient detail
Therefore, a semi-formal specification is needed; that is, a text so that physical devices implementing different LFB functions can be
description of the LFB operation (human readable), but sufficiently integrated easily into an FE design. However, the model, and the
specific and unambiguous to allow conformance testing and efficient associated library of LFBs, must not be so detailed and so specific
design, so that interoperability between different CEs and FEs can be as to significantly constrain implementations. Therefore, a semi-
achieved. formal specification is needed; that is, a text description of the
LFB operation (human readable), but sufficiently specific and
unambiguous to allow conformance testing and efficient design, so
that interoperability between different CEs and FEs can be achieved.
The LFB class model specifies information such as: The LFB class model specifies information such as:
o number of inputs and outputs (and whether they are configurable) o number of inputs and outputs (and whether they are configurable)
o metadata read/consumed from inputs; o metadata read/consumed from inputs;
o metadata produced at the outputs; o metadata produced at the outputs;
o packet type(s) accepted at the inputs and emitted at the outputs; o packet type(s) accepted at the inputs and emitted at the outputs;
o packet content modifications (including encapsulation or o packet content modifications (including encapsulation or
decapsulation); decapsulation);
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;
o 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 sent on that port is a
and its associated metadata, although in some cases it might consist pair of a packet and associated metadata, one of which may be empty.
of only metadata. (If both were empty, there would be no output.)
A single LFB output can be connected to only one LFB input. This is A single LFB output can be connected to only one LFB input. This is
required to make the packet flow through the LFB topology required to make the packet flow through the LFB topology
unambiguously. 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 19, line 7 skipping to change at page 19, line 7
output (EXCEPTIONOUT) for sending exception packets when the LPM output (EXCEPTIONOUT) for sending exception packets when the LPM
look-up failed. This example is depicted in Figure 3.b. Packets look-up failed. This example is depicted in Figure 3.b. Packets
emitted by these two outputs not only require different downstream emitted by these two outputs not only require different downstream
treatment, but they are a result of two different conditions in the treatment, but they are a result of two different conditions in the
LFB and each output carries different metadata. This concept assumes LFB and each output carries different metadata. This concept assumes
the number of distinct outputs is known when the LFB class is the number of distinct outputs is known when the LFB class is
defined. For each singleton output, the LFB class definition defines defined. For each singleton output, the LFB class definition defines
the types of frames and metadata the output emits. the types of frames and metadata the output emits.
An output group, on the other hand, is used to model the case where a An output group, on the other hand, is used to model the case where a
flow of similar packets with an identical set of metadata needs to be flow of similar packets with an identical set of permitted metadata
split into multiple paths. In this case, the number of such paths is needs to be split into multiple paths. In this case, the number of
not known when the LFB class is defined because it is not an inherent such paths is not known when the LFB class is defined because it is
property of the LFB class. An output group consists of a number of not an inherent property of the LFB class. An output group consists
outputs, called the output instances of the group, where all output of a number of outputs, called the output instances of the group,
instances share the same frame and metadata emission definitions (see where all output instances share the same frame and metadata emission
Figure 3.c). Each output instance can connect to a different definitions (see Figure 3.c). Each output instance can connect to a
downstream LFB, just as if they were separate singleton outputs, but different downstream LFB, just as if they were separate singleton
the number of output instances can differ between LFB instances of outputs, but the number of output instances can differ between LFB
the same LFB class. The class definition may include a lower and/or instances of the same LFB class. The class definition may include a
an upper limit on the number of outputs. In addition, for lower and/or an upper limit on the number of outputs. In addition,
configurable FEs, the FE capability information may define further for configurable FEs, the FE capability information may define
limits on the number of instances in specific output groups for further limits on the number of instances in specific output groups
certain LFBs. The actual number of output instances in a group is an for certain LFBs. The actual number of output instances in a group
component of the LFB instance, which is read-only for static is an component 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. To use Output Port groups, the
mechanism to select one specific output instance for each packet. LFB has to have a built-in mechanism to select one specific output
This mechanism is described in the textual definition of the class instance for each packet. This mechanism is described in the textual
and is typically configurable via some attributes of the LFB. definition of the class and is typically configurable via some
attributes of the LFB.
For example, consider a redirector LFB, whose sole purpose is to For example, consider a redirector LFB, whose sole purpose is to
direct packets to one of N downstream paths based on one of the direct packets to one of N downstream paths based on one of the
metadata associated with each arriving packet. Such an LFB is fairly metadata associated with each arriving packet. Such an LFB is fairly
versatile and can be used in many different places in a topology. versatile and can be used in many different places in a topology.
For example, a redirector can be used to divide the data path into an For example, 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.
skipping to change at page 20, line 22 skipping to change at page 20, line 23
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 conditions for forking the datapath and at least one of the following conditions
hold: hold:
o the number of downstream directions is inherent from the o the number of downstream directions is inherent from the
definition of the class and hence fixed; definition of the class and hence fixed;
o the frame type and set of metadata emitted on any of the outputs o the frame type and set of permitted metadata emitted on any of the
are substantially different from what is emitted on the other outputs are different from what is emitted on the other outputs
outputs (i.e., they cannot share frame-type and metadata (i.e., they cannot share their frame-type and permitted metadata
definitions). definitions).
An output group is appropriate when the LFB must provide for forking An output group is appropriate when the LFB must provide for forking
the datapath and at least one of the following conditions hold: the datapath and at least one of the following conditions hold:
o the number of downstream directions is not known when the LFB o the number of downstream directions is not known when the LFB
class is defined; class is defined;
o the frame type and set of metadata emitted on these outputs are o the frame type and set of metadata emitted on these outputs are
sufficiently similar or, ideally, identical, such they can share sufficiently similar or, ideally, identical, such they can share
the same output definition. the same output definition.
3.2.2. LFB Inputs 3.2.2. LFB Inputs
An LFB input is a conceptual port on an LFB on which the LFB can An LFB input is a conceptual port on an LFB on which the LFB can
receive information from other LFBs. The information is typically a receive information from other LFBs. The information is typically a
packet and associated metadata, although in some cases it might pair of a packet and its associated metadata. Either the packet, or
consist of only metadata. the metadata, may for some LFBs and some situations be empty. They
can not both be empty, as then there is no imput.
For LFB instances that receive packets from more than one other LFB For LFB instances that receive packets from more than one other LFB
instance (fan-in) there are three ways to model fan-in, all supported instance (fan-in) there are three ways to model fan-in, all supported
by the LFB model and can all be combined in the same LFB: by the LFB model and can all be combined in the same LFB:
o Implicit multiplexing via a single input o Implicit multiplexing via a single input
o Explicit multiplexing via multiple singleton inputs o Explicit multiplexing via multiple singleton inputs
o Explicit multiplexing via a group of inputs (input group) o Explicit multiplexing via a group of inputs (input group)
The simplest form of multiplexing uses a singleton input (Figure 4 The simplest form of multiplexing uses a singleton input (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
one LFB output to connect to the same LFB input. This property one LFB output to connect to the same LFB input. This property
applies to any LFB input without any special provisions in the LFB applies to any LFB input without any special provisions in the LFB
class. Multiplexing into a single input is applicable when the class. Multiplexing into a single input is applicable when the
packets from the upstream LFBs are similar in frame-type and packets from the upstream LFBs are similar in frame-type and
accompanying metadata, and require similar processing. Note that accompanying metadata, and require similar processing. Note that
skipping to change at page 24, line 37 skipping to change at page 24, line 37
Inter-FE metadata, i.e, metadata crossing FEs, while likely Inter-FE metadata, i.e, metadata crossing FEs, while likely
semantically similar to this metadata, is out of scope for this semantically similar to this metadata, is out of scope for this
document. document.
Section 4 has informal details on metadata. Section 4 has informal details on metadata.
3.2.4.1. Metadata lifecycle within the ForCES model 3.2.4.1. Metadata lifecycle within the ForCES model
Each metadata is modeled as a <label, value> pair, where the label Each metadata is modeled as a <label, value> pair, where the label
identifies the type of information, (e.g., "color"), and its value identifies the type of information, (e.g., "color"), and its value
holds the actual information (e.g., "red"). The tag here is shown as holds the actual information (e.g., "red"). The label here is shown
a textual label, but it can be replaced or associated with a unique as a textual label, but for protocol processing it is associated with
numeric value (identifier). a unique numeric value (identifier).
To ensure inter-operability between LFBs, the LFB class specification To ensure inter-operability between LFBs, the LFB class specification
must define what metadata the LFB class "reads" or "consumes" on its must define what metadata the LFB class "reads" or "consumes" on its
input(s) and what metadata it "produces" on its output(s). For input(s) and what metadata it "produces" on its output(s). For
maximum extensibility, this definition should neither specify which maximum extensibility, this definition should neither specify which
LFBs the metadata is expected to come from for a consumer LFB, nor LFBs the metadata is expected to come from for a consumer LFB, nor
which LFBs are expected to consume metadata for a given producer LFB. which LFBs are expected to consume metadata for a given producer LFB.
3.2.4.2. Metadata Production and Consumption 3.2.4.2. Metadata Production and Consumption
skipping to change at page 25, line 16 skipping to change at page 25, line 16
In the ForCES model, the producer and consumer LFBs of a metadatum In the ForCES model, the producer and consumer LFBs of a metadatum
are not required to be adjacent. In addition, there may be multiple are not required to be adjacent. In addition, there may be multiple
producers and consumers for the same metadata. When a packet path producers and consumers for the same metadata. When a packet path
involves multiple producers of the same metadata, then subsequent involves multiple producers of the same metadata, then subsequent
producers overwrite that metadata value. producers overwrite that metadata value.
The metadata that is produced by an LFB is specified by the LFB class The metadata that is produced by an LFB is specified by the LFB class
definition on a per-output-port-group basis. A producer may always definition on a per-output-port-group basis. A producer may always
generate the metadata on the port group, or may generate it only generate the metadata on the port group, or may generate it only
under certain conditions. We call the former an "unconditional" under certain conditions. We call the former an "unconditional"
metadata, whereas the latter is a "conditional" metadata. In the metadata, whereas the latter is a "conditional" metadata. For
case of conditional metadata, it should be possible to determine from example, deep packet inspection LFB might produce several pieces of
the definition of the LFB when a "conditional" metadata is produced. metadata about the packet. The first metadatum might be the carried
The consumer behavior of an LFB, that is, the metadata that the LFB protocol (ICMP, TCP, UDP, SCTP, ...) For protocols that use port
needs for its operation, is defined in the LFB class definition on a numbers, the LFB might produce an additional metadatum carrying the
per-input-port-group basis. An input port group may "require" a source or destination port number. That would not be produced for
given metadata, or may treat it as "optional" information. In the packets with no carried protocol, or that carry ICMP. In the case of
latter case, the LFB class definition MUST explicitly define what conditional metadata, it should be possible to determine from the
happens if an optional metadata is not provided. One approach is to definition of the LFB when a "conditional" metadata is produced. The
specify a default value for each optional metadata, and assume that consumer behavior of an LFB, that is, the metadata that the LFB needs
the default value is used if the metadata is not provided with the for its operation, is defined in the LFB class definition on a per-
packet. 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 When specifying the metadata tags, some harmonization effort must be
made so that the producer LFB class uses the same tag as its intended made so that the producer LFB class uses the same tag as its intended
consumer(s), or vice versa. consumer(s), or vice versa.
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
skipping to change at page 26, line 30 skipping to change at page 26, line 35
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.5. LFB Events 3.2.5. LFB Events
During operation, various conditions may occur that can be detected During operation, various conditions may occur that can be detected
by LFBs. Examples range from link failure or restart to timer by LFBs. Examples range from link failure or restart to timer
expiration in special purpose LFBs. The CE may wish to be notified expiration in special purpose LFBs. The CE may wish to be notified
of the occurrence of such events. The PL protocol provides for such of the occurrence of such events. The description of how such
notifications. messages are sent, and their format, is part of the Forwarding and
Control Element Separation (ForCES) protocol [2] document.
Indicating how such conditions are understood is part of the job of
this model.
Events are declared in the LFB class definition. The LFB event Events are declared in the LFB class definition. The LFB event
declaration constitutes: declaration constitutes:
o a unique 32 bit identifier. o a unique 32 bit identifier.
o An LFB component which is used to trigger the event. This entity o An LFB component which is used to trigger the event. This entity
is known as the event target. is known as the event target.
o A condition that will happen to the event target that will result o A condition that will happen to the event target that will result
skipping to change at page 28, line 19 skipping to change at page 28, line 28
read or write. This model defines the structure of the property read or write. This model defines the structure of the property
information for all defined data types. information for all defined data types.
Section 4.8 describes properties in more details. Section 4.8 describes properties in more details.
3.2.7. LFB Versioning 3.2.7. LFB Versioning
LFB class versioning is a method to enable incremental evolution of LFB class versioning is a method to enable incremental evolution of
LFB classes. In general, an FE is not allowed to contain an LFB LFB classes. In general, an FE is not allowed to contain an LFB
instance for more than one version of a particular class. instance for more than one version of a particular class.
Inheritance (discussed next in Section 3.2.6) has special rules. If Inheritance (discussed next in Section 3.2.8) has special rules. If
an FE datapath model containing an LFB instance of a particular class an FE datapath model containing an LFB instance of a particular class
C also simultaneously contains an LFB instance of a class C' C also simultaneously contains an LFB instance of a class C'
inherited from class C; C could have a different version than C'. inherited from class C; C could have a different version than C'.
LFB class versioning is supported by requiring a version string in LFB class versioning is supported by requiring a version string in
the class definition. CEs may support multiple versions of a the class definition. CEs may support multiple versions of a
particular LFB class to provide backward compatibility, but FEs MUST particular LFB class to provide backward compatibility, but FEs MUST
NOT support more than one version of a particular class. NOT support more than one version of a particular class.
Versioning is not restricted to making backwards compatible changes. Versioning is not restricted to making backwards compatible changes.
skipping to change at page 31, line 47 skipping to change at page 31, line 47
ComponentID 89 could be a complex structure itself but is restricted ComponentID 89 could be a complex structure itself but is restricted
in the example for the sake of clarity. in the example for the sake of clarity.
3.3.1. Addressing LFB Components: Paths and Keys 3.3.1. Addressing LFB Components: Paths and Keys
As mentioned above, LFB components could be complex structures, such As mentioned above, LFB components could be complex structures, such
as a table, or even more complex structures such as a table whose as a table, or even more complex structures such as a table whose
cells are further tables, etc. The ForCES model XML schema cells are further tables, etc. The ForCES model XML schema
(Figure 5) allows for uniquely identifying anything with such (Figure 5) allows for uniquely identifying anything with such
complexity, utilizing the concept of dot-annotated static paths and complexity, utilizing the concept of dot-annotated static paths and
content addressing of paths as derived from keys. As an example, the content addressing of paths as derived from keys. As an example, if
path to LFB ComponentID 89 above will be 51.89. If ComponentID 51 the LFB Component 51 were a structure, then the path to LFB
was a table which was key index-able, then a key describing content ComponentID 89 above will be 51.89.
could also be passed by the CE which upon computation by the FE would
resolve to LFB ComponentID 89. LFB ComponentID 51 might represent a table (an array). In that case,
to select the LFB Component with ID 89 from within the 7th entry of
the table, one would use the path 51.7.89 In addition to supporting
explicit table element selection by including and index in the dotted
path, the model supports identifying table elements by their
contents. This is referred to as using keys, or key indexing. So,
as a further example, if ComponentID 51 was a table which was key
index-able, then a key describing content could also be passed by the
CE, along with path 51 to select the table, and followed by the path
89 to select the table structure element, which upon computation by
the FE would resolve to the LFB ComponentID 89 within the specified
table entry.
3.4. FE Datapath Modeling 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
one or more 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), header values, time of arrival, etc. (e.g., IPv4, IPv6, or MPLS), header values, time of arrival, etc.
The result of LFB processing may have an impact on how the packet is The result of LFB processing may have an impact on how the packet is
to be treated in downstream LFBs. This differentiation of packet to be treated in downstream LFBs. This differentiation of packet
treatment downstream can be conceptualized as having alternative treatment downstream can be conceptualized as having alternative
skipping to change at page 39, line 44 skipping to change at page 39, line 45
+-------+ +---+ Fwd. +-------+ +---+ Fwd.
Scheduler Scheduler
Figure 10: An LFB topology as configured by the CE and accepted by Figure 10: An LFB topology as configured by the CE and accepted by
the FE the FE
Once the FE reports these capabilities and capacity limits to the CE, 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 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 configuration for the FE. Figure 9 depicts the FE capability while
Figure 10 and Figure 11 depict two different topologies that the CE Figure 10 and Figure 11 depict two different topologies that the CE
may request the FE to configure. may request the FE to configure. Note that Figure 11 is not fully
drawn, as inter-LFB links are included to suggest potential
complexity, without drawing in the endpoints of all such links.
Queue1 Queue1
+---+ +--+ +---+ +--+
| A|------------------->| |--+ | A|------------------->| |--+
+->| | | | | +->| | | | |
| | B|--+ +--+ +--+ +--+ | | | B|--+ +--+ +--+ +--+ |
| +---+ | | | | | | | +---+ | | | | | |
| Meter1 +->| |-->| | | | Meter1 +->| |-->| | |
| | | | | | | | | | | |
| +--+ +--+ | Ipv4 | +--+ +--+ | Ipv4
| Counter1 Dropper1 Queue2| +--+ Fwd. | Counter1 Dropper1 Queue2| +--+ Fwd.
+---+ | +--+ +--->|A | +-+ +---+ | +--+ +--->|A | +-+
| A|---+ | |------>|B | | | | A|---+ | |------>|B | | |
------>| B|------------------------------>| | +--->|C |->| |-> ------>| B|------------------------------>| | +-->|C |->| |->
| C|---+ +--+ | +->|D | | | | C|---+ +--+ | +>|D | | |
| D|-+ | | | +--+ +-+ | D|-+ | | | +--+ +-+
+---+ | | +---+ Queue3| | Scheduler +---+ | | +---+ Queue3| | Scheduler
Classifier1 | | | A|------------> +--+ | | Classifier1 | | | A|------------> +--+ | |
| +->| | | |--+ | | +->| | | |-+ |
| | B|--+ +--+ +-------->| | | | | B|--+ +--+ +-------->| | |
| +---+ | | | | +--+ | | +---+ | | | | +--+ |
| Meter2 +->| |-+ | | Meter2 +->| |-+ |
| | | | | | | |
| +--+ Queue4 | | +--+ Queue4 |
| Marker1 +--+ | | Marker1 +--+ |
+---------------------------->| |----+ +---------------------------->| |---+
| | | |
+--+ +--+
Figure 11: Another LFB topology as configured by the CE and accepted Figure 11: Another LFB topology as configured by the CE and accepted
by the FE by the FE
Note that both the ingress and egress are omitted in Figure 10 and Note that both the ingress and egress are omitted in Figure 10 and
Figure 11 to simplify the representation. The topology in Figure 11 Figure 11 to simplify the representation. The topology in Figure 11
is considerably more complex than Figure 10 but both are feasible is considerably more complex than Figure 10 but both are feasible
within the FE capabilities, and so the FE should accept either within the FE capabilities, and so the FE should accept either
skipping to change at page 41, line 15 skipping to change at page 41, line 15
section. The root element of the library document is the section. The root element of the library document is the
<LFBLibrary> element. <LFBLibrary> element.
It is not expected that library documents will be exchanged between It is not expected that library documents will be exchanged between
FEs and CEs "over-the-wire". But the model will serve as an FEs and CEs "over-the-wire". But the model will serve as an
important reference for the design and development of the CEs important reference for the design and development of the CEs
(software) and FEs (mostly the software part). It will also serve as (software) and FEs (mostly the software part). It will also serve as
a design input when specifying the ForCES protocol elements for CE-FE a design input when specifying the ForCES protocol elements for CE-FE
communication. communication.
The following sections describe the portions of an LFBLibrary XML
Document. The descriptions primarily provide the necessary semantic
information to understand the meaning and uses of the XML elements.
The XML Schema below provides the final definition on what elements
are permitted, and their base syntax. Unfortunately, due to the
limitations of english and XML, there are constraints described in
the semantic sections which are not fully captured in the XML Schema,
so both sets of information need to be used to build a compliant
library document.
4.1. Namespace 4.1. Namespace
A namespace is needed to uniquely identify the LFB type in the LFB A namespace is needed to uniquely identify the LFB type in the LFB
class library. The reference to the namespace definition is class library. The reference to the namespace definition is
contained in Section 9, IANA Considerations. contained in Section 9, IANA Considerations.
4.2. <LFBLibrary> Element 4.2. <LFBLibrary> Element
The <LFBLibrary> element serves as a root element of all library The <LFBLibrary> element serves as a root element of all library
documents. It contains one or more of the following main XML documents. A library document contains a sequence of top level
elements: elements. The following is a list of all the elements which can
occur directly in the <LFBLibrary> element. If they occur, they must
occur in the order listed.
o <frameTypeDefs> for the frame declarations; o <description> providing a text description of the purpose of the
library document.
o <load> for loading information from other library documents.
o <frameDefs> 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.
Each element is optional, that is, one library document may contain Each element is optional. One library document may contain only
only metadata definitions, another may contain only LFB class metadata definitions, another may contain only LFB class definitions,
definitions, yet another may contain all of the above. yet another may contain all of the above.
In addition to the above main elements, a library document can import
other library documents if it needs to refer to definitions contained
in the included document. This concept is similar to the "#include"
directive in C. Importing is expressed by the use of <load> elements,
which must precede all the above elements in the document. For
unique referencing, each LFBLibrary instance document has a unique
label defined in the "provide" attribute of the LFBLibrary element.
Note that what this performs is a ForCES inclusion, not an XML
inclusion. The semantic content of the library referenced by the
<load> element is included, not the xml content.
The <LFBLibrary> element also includes an optional <description> A library document can import other library documents if it needs to
element, which can be used to provide textual description about the refer to definitions contained in the included document. This
library document. concept is similar to the "#include" directive in C. Importing is
expressed by the use of <load> elements, which must precede all the
above elements in the document. For unique referencing, each
LFBLibrary instance document has a unique label defined in the
"provide" attribute of the LFBLibrary element. Note that what this
performs is a ForCES inclusion, not an XML inclusion. The semantic
content of the library referenced by the <load> element is included,
not the xml content. Also, in terms of the conceptual processing
<load> elements, the total set of documents loaded are considered to
form a single document for processing. A given document is included
in this set only once, even if it is referenced by <load> elements
several times, even from several different files. As the processing
of LFBLibrary information is not order dependent, the order for
processing loaded elements is up to the implementor, as long as the
total effect is as if all of the information from all the files were
available for referencing when needed. Note that such computer
processing of ForCES model library documents may be helpful for
various implementations, but is not required to define the libraries,
or for the actual operation of the protocol itself.
The following is a skeleton of a library document: The following is a skeleton of a library document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel" <LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel"
provides="this_library"> provides="this_library">
<description> <description>
</description> </description>
<!-- Loading external libraries (optional) --> <!-- Loading external libraries (optional) -->
<load library="another_library"/> <load library="another_library"/>
... ...
<!-- FRAME TYPE DEFINITIONS (optional) --> <!-- FRAME TYPE DEFINITIONS (optional) -->
<frameTypeDefs> <frameDefs>
... ...
</frameTypeDefs> </frameDefs>
<!-- DATA TYPE DEFINITIONS (optional) --> <!-- DATA TYPE DEFINITIONS (optional) -->
<dataTypeDefs> <dataTypeDefs>
... ...
</dataTypeDefs> </dataTypeDefs>
<!-- METADATA DEFINITIONS (optional) --> <!-- METADATA DEFINITIONS (optional) -->
<metadataDefs> <metadataDefs>
... ...
</metadataDefs> </metadataDefs>
skipping to change at page 44, line 20 skipping to change at page 45, line 13
used in several places in the library documents, including: used in several places in the library documents, including:
o Defining other data types o Defining other data types
o Defining components of LFB classes o Defining components of LFB classes
This is similar to the concept of having a common header file for This is similar to the concept of having a common header file for
shared data types. shared data types.
Each <dataTypeDef> element MUST contain a unique name (NMTOKEN), a Each <dataTypeDef> element MUST contain a unique name (NMTOKEN), a
brief synopsis, an optional longer description, and a type definition brief synopsis, and a type definition element. The name MUST be
element. The name MUST be unique among all data types defined in the unique among all data types defined in the same library document and
same library document and in any directly or indirectly included in any directly or indirectly included library documents. The
library documents. For example: <dataTypeDef> element may also include an optional longer
description, For example:
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>ieeemacaddr</name> <name>ieeemacaddr</name>
<synopsis>48-bit IEEE MAC address</synopsis> <synopsis>48-bit IEEE MAC address</synopsis>
... type definition ... ... type definition ...
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>ipv4addr</name> <name>ipv4addr</name>
<synopsis>IPv4 address</synopsis> <synopsis>IPv4 address</synopsis>
skipping to change at page 45, line 51 skipping to change at page 46, line 51
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 in unions). They may also be defined as augmentations (explained in
Section 4.5.7) of existing compound data types. Section 4.5.7) of existing compound data types.
Given that the FORCES protocol will be getting and setting component Given that the FORCES protocol will be getting and setting component
values, all atomic data types used here must be able to be conveyed values, all atomic data types used here must be able to be conveyed
in the FORCES protocol. Further, the FORCES protocol will need a in the FORCES protocol. Further, the FORCES protocol will need a
mechanism to convey compound data types. However, the details of mechanism to convey compound data types. However, the details of
such representations are for the ForCES Protocol [2] document to such representations are for the ForCES Protocol [2] document to
define, not the model document. Strings and octetstrings must be define, not the model document. Strings and octetstrings must be
conveyed with their length, as they are not delimited, and are conveyed by the protocol with their length, as they are not
variable length. delimited, the value does not itself include the length, and these
items are variable length.
With regard to strings, this model defines a small set of With regard to strings, this model defines a small set of
restrictions and definitions on how they are structured. String and restrictions and definitions on how they are structured. String and
octetstring length limits can be specified in the LFB Class octetstring length limits can be specified in the LFB Class
definitions. The component properties for string and octetstring definitions. The component properties for string and octetstring
components also contain actual lengths and length limits. This components also contain actual lengths and length limits. This
duplication of limits is to allow for implementations with smaller duplication of limits is to allow for implementations with smaller
limits than the maximum limits specified in the LFB Class definition. limits than the maximum limits specified in the LFB Class definition.
In all cases, these lengths are specified in octets, not in In all cases, these lengths are specified in octets, not in
characters. In terms of protocol operation, as long as the specified characters. In terms of protocol operation, as long as the specified
skipping to change at page 46, line 47 skipping to change at page 47, line 48
For the definition of the actual type in the <dataTypeDef> element, For the definition of the actual type in the <dataTypeDef> element,
the following elements are available: <typeRef>, <atomic>, <array>, the following elements are available: <typeRef>, <atomic>, <array>,
<struct>, and <union>. <struct>, and <union>.
The predefined type alias is somewhere between the atomic and The predefined type alias is somewhere between the atomic and
compound data types. It behaves like a structure, one component of compound data types. It behaves like a structure, one component of
which has special behavior. Given that the special behavior is tied which has special behavior. Given that the special behavior is tied
to the other parts of the structure, the compound result is treated to the other parts of the structure, the compound result is treated
as a predefined construct. as a predefined construct.
4.5.1. <typeRef> Element for Aliasing Existing Data Types 4.5.1. <typeRef> Element for Renaming Existing Data Types
The <typeRef> element refers to an existing data type by its name. The <typeRef> element refers to an existing data type by its name.
The referred data type MUST be defined either in the same library The referred data type MUST be defined either in the same library
document, or in one of the included library documents. If the document, or in one of the included library documents. If the
referred data type is an atomic data type, the newly defined type referred data type is an atomic data type, the newly defined type
will also be regarded as atomic. If the referred data type is a will also be regarded as atomic. If the referred data type is a
compound type, the new type will also be compound. Some usage compound type, the new type will also be compound. Some usage
examples follow: examples follow:
<dataTypeDef> <dataTypeDef>
skipping to change at page 51, line 6 skipping to change at page 52, line 6
<typeRef>opcode</typeRef> <typeRef>opcode</typeRef>
</component> </component>
</struct> </struct>
</array> </array>
</dataTypeDef> </dataTypeDef>
In the above example, each entry of the array is a <struct> of two In the above example, each entry of the array is a <struct> of two
components ("rule" and "opcode"). components ("rule" and "opcode").
The following example shows a table of IP Prefix information that can The following example shows a table of IP Prefix information that can
be accessed by a multi-field content key on the IP Address and prefix be accessed by a multi-field content key on the IP Address, prefix
length. This means that in any instance of this table, no two length, and information source. This means that in any instance of
entries can have the same IP address and prefix length. this table, no two entries can have the same IP address, prefix
length, and information source.
<dataTypeDef> <dataTypeDef>
<name>ipPrefixInfo_table</name> <name>ipPrefixInfo_table</name>
<synopsis> <synopsis>
A table of information about known prefixes A table of information about known prefixes
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>address-prefix</name> <name>address-prefix</name>
skipping to change at page 52, line 33 skipping to change at page 53, line 35
In the special case of declaring a key for an array containing an In the special case of declaring a key for an array containing an
atomic type, where that content is unique and is to be used as a key, atomic type, where that content is unique and is to be used as a key,
the value "*" can be used as the single key field identifier. the value "*" can be used as the single key field identifier.
4.5.4. <struct> Element to Define Structures 4.5.4. <struct> Element to Define Structures
A structure is comprised of a collection of data components. Each A structure is comprised of a collection of data components. Each
data components has a data type (either an atomic type or an existing data components has a data type (either an atomic type or an existing
compound type) and is assigned a name unique within the scope of the compound type) and is assigned a name unique within the scope of the
compound data type being defined. These serve the same function as compound data type being defined. These serve the same function as
"struct" in C, etc. "struct" in C, etc. These components are defined using <component>
elements. A <struct> element may contain an optional derivation
indication, a <derivedFrom> element. The structure definition MUST
contain a sequence of one or more <component> elements.
The actual type of the component can be defined by referring to an The actual type of the component can be defined by referring to an
existing type (using the <typeDef> element), or can be a locally existing type (using the <typeRef> element), or can be a locally
defined (unnamed) type created by any of the <atomic>, <array>, defined (unnamed) type created by any of the <atomic>, <array>,
<struct>, or <union> elements. <struct>, or <union> elements.
A structure definition is a series of component declarations. Each The <component> element must include a componentID attribute. This
component carries a componentID for use by the ForCES protocol. In provides the numeric ID for this component, for use by the protocol.
addition, the component declaration contains the name of the The <component> MUST contain a component name and a synopsis. It may
component, a synopsis, an optional description, an optional contain a =description> element giving a textual description of the
declaration that the component itself is optional, and the typeRef component. The definition may also include a <optional> element,
declaration that specifies the component type. which indicates that the component being defined is optional. The
definition MUST contain elements to define the data type of the
component, as described above.
For a dataTypeDef of a struct, the structure definition may be For a dataTypeDef of a struct, the structure definition may be
inherited from, and augment, a previously defined structured type. inherited from, and augment, a previously defined structured type.
This is indicated by including the derivedFrom attribute on the This is indicated by including the optional derivedFrom attribute in
struct declaration. the struct declaration before the definition of the augmenting or
replacing components.
The result of this construct MUST be a compound type, even when the The result of this construct MUST be a compound type, even when the
<struct> contains only one field. <struct> contains only one field.
An example: An example:
<dataTypeDef> <dataTypeDef>
<name>ipv4prefix</name> <name>ipv4prefix</name>
<synopsis> <synopsis>
IPv4 prefix defined by an address and a prefix length IPv4 prefix defined by an address and a prefix length
skipping to change at page 53, line 46 skipping to change at page 55, line 8
Similar to the union declaration in C, this construct allows the Similar to the union declaration in C, this construct allows the
definition of overlay types. Its format is identical to the <struct> definition of overlay types. Its format is identical to the <struct>
element. element.
The result of this construct MUST be a compound type, even when the The result of this construct MUST be a compound type, even when the
union contains only one element. union contains only one element.
4.5.6. <alias> Element 4.5.6. <alias> Element
It is sometimes necessary to have a component in an LFB or structure It is sometimes necessary to have a component in an LFB or structure
refer to information (a component) in other LFBs. The <alias> refer to information (a component) in other LFBs. This can, for
declaration creates the constructs for this. The content of an example, allow an ARP LFB to share the IP->MAC Address table with the
<alias> element MUST be a named type. Whatever component the alias local transmission LFB, without duplicating information. Similarly,
references (whcih is determined by the alias component properties, as it could allow a traffic measurement LFB to share information with a
described below) that component must be of the same type as that traffic enforcement LFB. The <alias> declaration creates the
declared for the alias. Thus, when the CE or FE dereferences the constructs for this. This construct tells the CE and FE that any
alias component, the type of the information returned is known. The manipulation of the defined data is actually manipulation of data
type can be a base type or a derived type. The actual value defined to exist in some specified part of some other LFB instance.
referenced by an alias is known as its target. When a GET or SET The content of an <alias> element MUST be a named type. Whatever
operation references the alias element, the value of the target is component the alias references (whcih is determined by the alias
returned or replaced. Write access to an alias element is permitted component properties, as described below) that component must be of
if write access to both the alias and the target are permitted. the same type as that declared for the alias. Thus, when the CE or
FE dereferences the alias component, the type of the information
returned is known. The type can be a base type or a derived type.
The actual value referenced by an alias is known as its target. When
a GET or SET operation references the alias element, the value of the
target is returned or replaced. Write access to an alias element is
permitted if write access to both the alias and the target are
permitted.
The target of a component declared by an <alias> element is The target of a component declared by an <alias> element is
determined by it the components properties. Like all components, the determined by it the components properties. Like all components, the
properties MUST include the support / read / write permission for the properties MUST include the support / read / write permission for the
alias. In addition, there are several fields (components) in the alias. In addition, there are several fields (components) in the
alias properties which define the target of the alias. These alias properties which define the target of the alias. These
components are the ID of the LFB class of the target, the ID of the components are the ID of the LFB class of the target, the ID of the
LFB instance of the target, and a sequence of integers representing LFB instance of the target, and a sequence of integers representing
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.
skipping to change at page 55, line 7 skipping to change at page 56, line 24
For example, consider a simple base LFB class A that has only one For example, consider a simple base LFB class A that has only one
component (comp1) of type X. One way to derive class A1 from A can be component (comp1) of type X. One way to derive class A1 from A can be
by simply adding a second component (of any type). Another way to by simply adding a second component (of any type). Another way to
derive a class A2 from A can be by replacing the original component derive a class A2 from A can be by replacing the original component
(comp1) in A of type X with one of type Y, where Y is an augmentation (comp1) in A of type X with one of type Y, where Y is an augmentation
of X. Both classes A1 and A2 are backward compatible with class A. of X. Both classes A1 and A2 are backward compatible with class A.
The syntax for augmentations is to include a <derivedFrom> element in The syntax for augmentations is to include a <derivedFrom> element in
a structure definition, indicating what structure type is being a structure definition, indicating what structure type is being
augmented. Component names and component IDs within the augmentation augmented. Component names and component IDs for new components
must not be the same as those in the structure type being augmented. within the augmentation must not be the same as those in the
structure type being augmented. For those components where the data
type of an existing component is being replaced with a suitable
augmenting data type, the existing Component name and component ID
must be used in the augmentation.
4.6. <metadataDefs> Element for Metadata Definitions 4.6. <metadataDefs> Element for Metadata Definitions
The (optional) <metadataDefs> element in the library document The (optional) <metadataDefs> element in the library document
contains one or more <metadataDef> elements. Each <metadataDef> contains one or more <metadataDef> elements. Each <metadataDef>
element defines a metadatum. element defines a metadatum.
Each <metadataDef> element MUST contain a unique name (NMTOKEN). Each <metadataDef> element MUST contain a unique name (NMTOKEN).
Uniqueness is defined to be over all metadata defined in this library Uniqueness is defined to be over all metadata defined in this library
document and in all directly or indirectly included library document and in all directly or indirectly included library
documents. The <metadataDef> element MUST also contain a brief documents. The <metadataDef> element MUST also contain a brief
synopsis, the mandatory tag value to be used for this metadata, an synopsis, the tag value to be used for this metadata, and value type
optional detailed description, and a mandatory type definition definition information. Only atomic data types can be used as value
information. Only atomic data types can be used as value types for types for metadata. The <metadataDef> element may contain a detailed
metadata. description element.
Two forms of type definitions are allowed. The first form uses the Two forms of type definitions are allowed. The first form uses the
<typeRef> element to refer to an existing atomic data type defined in <typeRef> element to refer to an existing atomic data type defined in
the <dataTypeDefs> element of the same library document or in one of the <dataTypeDefs> element of the same library document or in one of
the included library documents. The usage of the <typeRef> element the included library documents. The usage of the <typeRef> element
is identical to how it is used in the <dataTypeDef> elements, except is identical to how it is used in the <dataTypeDef> elements, except
here it can only refer to atomic types. The latter restriction is here it can only refer to atomic types. The latter restriction is
not yet enforced by the XML schema. not 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>
skipping to change at page 57, line 24 skipping to change at page 58, line 32
this LFB. this LFB.
LFB Class Names must be unique, in order to enable other documents to LFB Class Names must be unique, in order to enable other documents to
reference the classes by name, and to enable human readers to reference the classes by name, and to enable human readers to
understand references to class names. While a complex naming understand references to class names. While a complex naming
structure could be created, simplicity is preferred. As given in the structure could be created, simplicity is preferred. As given in the
IANA considerations section of this document, the IANA will maintain IANA considerations section of this document, the IANA will maintain
a registry of LFB Class names and Class identifiers, along with a a registry of LFB Class names and Class identifiers, along with a
reference to the document defining the class. reference to the document defining the class.
Here is a skeleton of an example LFB class definition: Below is a skeleton of an example LFB class definition. Note that in
order to keep from complicating the XML Schema, the order of elements
in the class definition is fixed. Elements, if they appear, must
appear in the order shown.
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="12345"> <LFBClassDef LFBClassID="12345">
<name>ipv4lpm</name> <name>ipv4lpm</name>
<synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis> <synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
<version>1.0</version> <version>1.0</version>
<derivedFrom>baseclass</derivedFrom> <derivedFrom>baseclass</derivedFrom>
<inputPorts> <inputPorts>
... ...
skipping to change at page 58, line 28 skipping to change at page 59, line 28
</outputPorts> </outputPorts>
<components> <components>
... ...
</components> </components>
<capabilities> <capabilities>
... ...
</capabilities> </capabilities>
<events>
...
</events>
<description> <description>
This LFB represents the IPv4 longest prefix match lookup This LFB represents the IPv4 longest prefix match lookup
operation. operation.
The modeled behavior is as follows: The modeled behavior is as follows:
Blah-blah-blah. Blah-blah-blah.
</description> </description>
</LFBClassDef> </LFBClassDef>
... ...
</LFBClassDefs> </LFBClassDefs>
skipping to change at page 59, line 5 skipping to change at page 60, line 11
Note that the <name>, <synopsis>, and <version> elements are Note that the <name>, <synopsis>, and <version> elements are
required, all other elements are optional in <LFBClassDef>. However, required, all other elements are optional in <LFBClassDef>. However,
when they are present, they must occur in the above order. when they are present, they must occur in the above order.
4.7.1. <derivedFrom> Element to Express LFB Inheritance 4.7.1. <derivedFrom> Element to Express LFB Inheritance
The optional <derivedFrom> element can be used to indicate that this The optional <derivedFrom> element can be used to indicate that this
class is a derivative of some other class. The content of this class is a derivative of some other class. The content of this
element MUST be the unique name (<name>) of another LFB class. The element MUST be the unique name (<name>) of another LFB class. The
referred LFB class MUST be defined in the same library document or in referred LFB class MUST be defined in the same library document or in
one of the included library documents. one of the included library documents. In the absence of a
<derivedFrom> the class is conceptually derived from the common,
empty, base class.
It is assumed that the derived class is backwards compatible with the It is assumed that a derived class is backwards compatible with its
base class. base class.
4.7.2. <inputPorts> Element to Define LFB Inputs 4.7.2. <inputPorts> Element to Define LFB Inputs
The optional <inputPorts> element is used to define input ports. An The optional <inputPorts> element is used to define input ports. An
LFB class may have zero, one, or more inputs. If the LFB class has LFB class may have zero, one, or more inputs. If the LFB class has
no input ports, the <inputPorts> element MUST be omitted. The no input ports, the <inputPorts> element MUST be omitted. The
<inputPorts> element can contain one or more <inputPort> elements, <inputPorts> element can contain one or more <inputPort> elements,
one for each port or port-group. We assume that most LFBs will have one for each port or port-group. We assume that most LFBs will have
exactly one input. Multiple inputs with the same input type are exactly one input. Multiple inputs with the same input type are
skipping to change at page 65, line 14 skipping to change at page 66, line 14
o Firing-only components. A write attempt to this resource will o Firing-only components. A write attempt to this resource will
trigger some specific actions in the LFB, but the actual value trigger some specific actions in the LFB, but the actual value
written is ignored. written is ignored.
The LFB class may define only one possible access mode for a given The LFB class may define only one possible access mode for a given
component. component.
The components of the LFB class are listed in the <components> The components of the LFB class are listed in the <components>
element. Each component is defined by an <component> element. An element. Each component is defined by an <component> element. An
<component> element MUST contain the following elements: <component> element may contain any of the following elements, some
of which are mandatory:
o <name> defines the name of the component.This name must be unique o <name> MUST occur, and defines the name of the component. This
among the components of the LFB class. Example: "version". name must be unique among the components of the LFB class.
Example: "version".
o <synopsis> should provide a brief description of the purpose of o <synopsis> is also mandatory, and provides a brief description of
the component. the purpose of the component.
o <optional/> indicates that this component is optional. o <optional/> is an optional element, and if present indicates that
this component is optional.
o The data type of the component can be defined either via a o The data type of the component can be defined either via a
reference to a predefined data type or providing a local reference to a predefined data type or providing a local
definition of the type. The former is provided by using the definition of the type. The former is provided by using the
<typeRef> element, which must refer to the unique name of an <typeRef> element, which must refer to the unique name of an
existing data type defined in the <dataTypeDefs> element in the existing data type defined in the <dataTypeDefs> element in the
same library document or in any of the included library documents. same library document or in any of the included library documents.
When the data type is defined locally (unnamed type), one of the When the data type is defined locally (unnamed type), one of the
following elements can be used: <atomic>, <array>, <struct>, and following elements can be used: <atomic>, <array>, <struct>, and
<union>. Their usage is identical to how they are used inside <union>. Their usage is identical to how they are used inside
<dataTypeDef> elements (see Section 4.5). <dataTypeDef> elements (see Section 4.5). Some form of data type
definition MUST be included in the component definition.
o The optional <defaultValue> element can specify a default value o The <defaultValue> element is optional, and if present is used to
for the component, which is applied when the LFB is initialized or specify a default value for a component. If a default value is
reset. specified, the FE must ensure that the component has that value
when the LFB is initialized or reset. If a default value is not
specified for a component, the CE may make no assumptions as to
what the value of the component will be upon intialization. The
CE must either read the value, or set the value, if it needs to
know what it is.
o The <description> element may also appear. If included, it
provides a longer description of the meaning or usage of the
particular component being defined.
The <component> element also MUST have an componentID attribute, The <component> element also MUST have an componentID attribute,
which is a numeric value used by the ForCES protocol. which is a numeric value used by the ForCES protocol.
In addition to the above elements, the <component> element includes In addition to the above elements, the <component> element includes
an optional "access" attribute, which can take any of the following an optional "access" attribute, which can take any of the following
values: "read-only", "read-write", "write-only", "read-reset", and values: "read-only", "read-write", "write-only", "read-reset", and
"trigger-only". The default access mode is "read-write". "trigger-only". The default access mode is "read-write".
Whether optional components are supported, and whether components Whether optional components are supported, and whether components
skipping to change at page 74, line 8 skipping to change at page 75, line 24
arrays or complex structures) this is not recommended. Also, the arrays or complex structures) this is not recommended. Also, the
variable reference/subscripting in reporting only captures a small variable reference/subscripting in reporting only captures a small
portion of the kinds of related information. Chaining through index portion of the kinds of related information. Chaining through index
fields stored in a table, for example, is not supported. In general, fields stored in a table, for example, is not supported. In general,
the <eventReports> mechanism is an optimization for cases that have the <eventReports> mechanism is an optimization for cases that have
been found to be common, saving the CE from having to query for 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 The report MUST use a protocol format that supports optional the report MUST use a protocol format that supports optional elements
elements and allows for the non-existence of such elements. Any and allows for the non-existence of such elements. Any components
components which do not exist are not reported. which do not exist are not reported.
4.7.6.4. Runtime control of events 4.7.6.4. Runtime control of events
High level view on the declaration and operation of LFB events is High level view on the declaration and operation of LFB events is
described in Section 3.2.5. described in Section 3.2.5.
The <eventTarget> provides additional components used in the path to The <eventTarget> provides additional components used in the path to
reference the event. The path constitutes the baseID for events, reference the event. The path constitutes the baseID for events,
followed by the ID for the specific event, followed by a value for followed by the ID for the specific event, followed by a value for
each <eventSubscript> element if it exists in the <eventTarget>. each <eventSubscript> element if it exists in the <eventTarget>.
skipping to change at page 97, line 36 skipping to change at page 99, line 36
<component componentID="7"> <component componentID="7">
<name>CanOccurBefores</name> <name>CanOccurBefores</name>
<synopsis> <synopsis>
List of LFB Classes that can follow this LFB class List of LFB Classes that can follow this LFB class
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef> <typeRef>LFBAdjacencyLimitType</typeRef>
</array> </array>
</component> </component>
<component componentID="8">
<name>UseableParentLFBClasses</name>
<synopsis>
List of LFB Classes from which this class has
inherited, and which the FE is willing to allow
for references to instances of this class.
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>uint32</typeref>
</array>
</component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEStateValues</name> <name>FEStateValues</name>
<synopsis>The possible values of status</synopsis> <synopsis>The possible values of status</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>AdminDisable</name> <name>AdminDisable</name>
skipping to change at page 103, line 45 skipping to change at page 106, line 7
the CanOccurAfters array entry. If this neighbor can only be the CanOccurAfters array entry. If this neighbor can only be
connected to a specific set of input port groups, then the viaPort connected to a specific set of input port groups, then the viaPort
component is included. This component is an array, with one entry component is included. This component is an array, with one entry
for each input port group of the SupportedLFB that can be connected for each input port group of the SupportedLFB that can be connected
to an output port of the NeighborLFB. to an output port of the NeighborLFB.
[e.g., Within a SupportedLFBs entry, each array entry of the [e.g., Within a SupportedLFBs entry, each array entry of the
CanOccurAfters array must have a unique NeighborLFB, and within each CanOccurAfters array must have a unique NeighborLFB, and within each
such array entry each viaPort must represent a distinct and valid such array entry each viaPort must represent a distinct and valid
input port group of the SupportedLFB. The LFB Class definition input port group of the SupportedLFB. The LFB Class definition
schema does not yet support these uniqueness constraints.] schema does not include these uniqueness constraints.]
5.2.2.7. CanOccurBefores and LFBAdjacencyLimitType 5.2.2.7. CanOccurBefores and LFBAdjacencyLimitType
The CanOccurBefores array holds the information about which LFB The CanOccurBefores array holds the information about which LFB
classes can follow the described class. Structurally this element classes can follow the described class. Structurally this element
parallels CanOccurAfters, and uses the same type definition for the parallels CanOccurAfters, and uses the same type definition for the
array entries. array entries.
The array entries list those LFB classes that the SupportedLFB may The array entries list those LFB classes that the SupportedLFB may
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. LFBClassCapabilities 5.2.2.8. UseableParentLFBClasses
The UseableParentLFBClasses array, if present, i sued to hold a list
of parent LFB class IDs. All the entries in the list must be IDs of
classes from which the SupportedLFB Class being described has
inherited (either directly, or through an intermeidate parent.) (If
an FE includes imporper values in this list, imporper manipulations
by the CE are likely, and operational failures are likely.) In
addition, the FE, by including a given class in the last, is
indicating to the CE that a given parent class may be used to
manipulate an instance of this supported LFB class.
By allowing such substitution, the FE allows for the case where an
instantiated LFB may be of a class not known to the CE, but could
still be manipulated. While it is hoped that such situations are
rare, it is desirable for this to be supported. This can occur if an
FE locally defines certain LFB instances, or if an earlier CE had
configured some LFB instances. It can also occur if the FE would
prefer to instantiate a more recent, more specific and suitable, LFB
class rather than a common parent.
In order to permit this, the FE MUST be more restrained in assigning
LFB Instance IDs. Normally, instance IDs are qualified by the LFB
class. However, if two LFB classes share a parent, and if that
parent is listed in the UseableParentLFBClasses for both specific LFB
classes, then all the instances of both (or any, if multiple classes
are listing the common parent) MUST use distinct instances. This
permits the FE to determine which LFB Instance is intended by CE
manipulation operations even when a parent class is used.
5.2.2.9. 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 120, line 48 skipping to change at page 123, line 48
</events> </events>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
8.1. Data Handling 8.1. Data Handling
This LFB is designed to handle data packets coming in from or going This LFB is designed to handle data packets coming in from or going
out to the external world. It is not a full port, and it lacks many out to the external world. It is not a full port, and it lacks many
useful statistics, but it serves to show many of the relevant useful statistics, but it serves to show many of the relevant
behaviors. behaviors. The following paragraphs describe a potential operational
device and how it might use this LFB definition.
Packets arriving without error from the physical interface come in on Packets arriving without error from the physical interface come in on
a Frame Relay DLCI on a laser channel. These two values are used by a Frame Relay DLCI on a laser channel. These two values are used by
the LFB to look up the handling for the packet. If the handling the LFB to look up the handling for the packet. If the handling
indicates that the packet is LMI, then the output index is used to indicates that the packet is LMI, then the output index is used to
select an LFB port from the LMItoFE port group. The packet is sent select an LFB port from the LMItoFE port group. The packet is sent
as a full Frame Relay frame (without any bit or byte stuffing) on the as a full Frame Relay frame (without any bit or byte stuffing) on the
selected port. The laser channel and DLCI are sent as meta-data, selected port. The laser channel and DLCI are sent as meta-data,
even though the DLCI is also still in the packet. even though the DLCI is also still in the packet.
skipping to change at page 126, line 11 skipping to change at page 129, line 11
the corresponding ForCES LFB Class Identifiers, with the location of the corresponding ForCES LFB Class Identifiers, with the location of
the definition of the ForCES LFB Class, in accordance with the rules the definition of the ForCES LFB Class, in accordance with the rules
in the following table. in the following table.
+----------------+------------+---------------+---------------------+ +----------------+------------+---------------+---------------------+
| LFB Class Name | LFB Class | Place Defined | Description | | LFB Class Name | LFB Class | Place Defined | Description |
| | Identifier | | | | | Identifier | | |
+----------------+------------+---------------+---------------------+ +----------------+------------+---------------+---------------------+
| Reserved | 0 | RFCxxxx | Reserved | | Reserved | 0 | RFCxxxx | Reserved |
| | | | -------- | | | | | -------- |
| FE Object | 1 | RFXxxxx | Defines ForCES | | FE Object | 1 | RFCxxxx | Defines ForCES |
| | | | Forwarding Element | | | | | Forwarding Element |
| | | | information | | | | | information |
| FE Protocol | 2 | [2] | Defines parameters | | FE Protocol | 2 | [2] | Defines parameters |
| Object | | | for the ForCES | | Object | | | for the ForCES |
| | | | protocol operation | | | | | protocol operation |
| | | | -------- | | | | | -------- |
| IETF defined | 3-65535 | Standards | Reserved for IETF | | IETF defined | 3-65535 | Standards | Reserved for IETF |
| LFBs | | Track RFCs | defined RFCs | | LFBs | | Track RFCs | defined RFCs |
| | | | -------- | | | | | -------- |
| Forces LFB | >65535 | Any Publicly | First Come, First | | Forces LFB | >65535 | Any Publicly | First Come, First |
skipping to change at page 126, line 45 skipping to change at page 129, line 45
Lily Yang, Intel Corp. Lily Yang, Intel Corp.
Ram Gopal, Nokia Research Center Ram Gopal, Nokia Research Center
Alan DeKok, Infoblox, Inc. Alan DeKok, Infoblox, Inc.
Zsolt Haraszti, Clovis Solutions Zsolt Haraszti, Clovis Solutions
11. Acknowledgments 11. Acknowledgments
Many of the colleagues in our companies and participants in the Many of the colleagues in our companies and participants in the
ForCES mailing list have provided invaluable input into this work. ForCES mailing list have provided invaluable input into this work.
Particular thanks to Evangelos Haleplidis for held getting the XML Particular thanks to Evangelos Haleplidis for help getting the XML
right. right.
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
skipping to change at page 129, line 44 skipping to change at line 5957
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 72 change blocks. 
241 lines changed or deleted 380 lines changed or added

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